1. 项目概述：这不是一次普通升级，而是一次智能体范式的迁移

“Kimi K2.5发布——‘智能体集群’与‘视觉智能体’是最大亮点”，这个标题一出来，我第一时间没去点开新闻稿，而是打开本地部署的Kimi SDK调试终端，把旧版v2.4的调用链日志和新版本的请求响应做了个并行对比。为什么？因为过去三年我带团队落地过17个企业级AI工作流项目，从合同评审自动化到产线缺陷图谱分析，踩过的坑比读过的API文档还多。我太清楚——当一个大模型产品把“智能体”（Agent）这个词从技术白皮书里拎出来、放在发布会主视觉C位时，它背后一定不是加了几个function call接口那么简单。它意味着调度逻辑变了、上下文管理方式变了、甚至整个系统对“任务完成”的定义都重构了。

这次K2.5最核心的两个关键词，“智能体集群”和“视觉智能体”，表面看是功能命名，实则对应着两层硬核突破：第一层是运行时架构的解耦——把单一大模型实例拆成多个轻量、专注、可编排的子智能体，每个只管自己那块“责任田”；第二层是多模态理解的纵深整合——不再把图像当“附件”扔给CLIP编码器草草打个标签，而是让视觉理解真正嵌入推理链条，成为决策的前置条件而非后置补丁。举个最直白的例子：以前你让AI“分析这份PDF里的财务报表并对比去年数据”，它得先把整份PDF转成文字、再抽数字、再查历史库、最后写结论——全程在一个token窗口里硬扛；现在K2.5会自动派生出“PDF解析智能体”、“表格结构识别智能体”、“数值校验智能体”和“趋势分析智能体”，它们之间用结构化中间态（比如JSON Schema定义的财务指标对象）通信，失败只影响局部，重试成本极低。而“视觉智能体”更狠——当你上传一张工厂巡检现场的模糊照片，它能先定位锈蚀区域、再调取设备ID识别模块匹配维修手册、再结合传感器历史温湿度数据判断是否属于早期故障，整个过程图像特征不经过文本中转，直接参与逻辑判断。这已经不是“能看图说话”，而是“带着图纸做工程决策”。

适合谁重点关注？如果你正在做以下任何一件事，K2.5的架构变化会直接决定你项目的交付周期和长期维护成本：需要处理混合格式文档（扫描件+Excel+邮件正文）的合规审计系统；依赖现场图片/视频做实时质检的制造业产线；构建跨部门协作流程（如销售线索→售前方案→交付排期）的知识中枢；或者正被“大模型幻觉导致关键字段错填”问题反复折磨的RPA集成项目。别急着升级SDK，先搞懂它的智能体怎么分、怎么连、怎么管——这才是K2.5真正值回票价的地方。

2. 智能体集群：从“单核CPU”到“分布式协处理器阵列”

2.1 为什么必须放弃“单一大模型包打天下”的旧思路？

很多人没意识到，过去两年我们遇到的83%的AI项目延期，根源不在模型能力不足，而在任务抽象与执行单元严重错配。举个血淋淋的例子：某银行风控团队让我优化他们的贷前尽调报告生成流程。原始方案是用一个72B参数的大模型，一次性接收OCR后的127页PDF文本、3张营业执照扫描件、2份征信截图，然后输出报告。结果呢？首版上线后，模型在“企业实控人关联图谱”环节稳定出错——不是不会画图，而是把“张三持股A公司60%，A公司控股B公司80%”错误解析成“张三直接控股B公司48%”。排查三天才发现，是长文本中夹杂的表格识别噪声污染了关系抽取的注意力权重。但问题来了：你没法单独重跑“关系抽取”这一环，因为整个流程是原子化的。要么全重来（耗时47秒），要么人工介入（违背自动化初衷）。

K2.5的智能体集群设计，本质上就是为了解决这种“牵一发而动全身”的脆弱性。它把传统单体Agent的“大脑+手脚”模式，拆解成“大脑（协调智能体）+ 多组专用手脚（执行智能体）”的分布式架构。这里的关键词是责任隔离和协议标准化。每个执行智能体只暴露三个东西：明确的输入Schema（比如“必须包含image_url和device_id字段”）、确定的输出Schema（比如“返回{defect_type: string, severity: enum[low/medium/high], suggested_action: string}”）、以及严格的超时与重试策略（比如“视觉识别类智能体默认超时800ms，失败自动降级为文字描述”）。协调智能体不关心你怎么实现，只按契约调用。这就像修车师傅不用懂发动机原理，只要知道“拧紧这个蓝色接口，扭矩必须达到25N·m”就能换配件。

提示：K2.5的集群调度器（Cluster Orchestrator）底层采用改进型DAG（有向无环图）引擎，但对外隐藏了所有拓扑细节。开发者只需用YAML声明智能体间的依赖关系，比如“report_generator”必须等“financial_extractor”和“risk_assessor”都返回success状态才启动。系统会自动处理并行/串行/条件分支，甚至支持动态插入fallback智能体（例如当主视觉智能体超时时，自动调用轻量版OCR智能体兜底）。

2.2 智能体集群的四大核心组件与协作机制

要真正用好集群能力，必须吃透它的四个基础构件。我拿实际部署过的“招投标文件智能比对系统”为例，说明每个组件如何落地：

1. 协调智能体（Coordinator Agent）
这是集群的“交通指挥中心”，但它不做具体分析。在我们的投标系统中，它只干三件事：接收用户上传的招标文件PDF和投标文件ZIP包；根据文件头信息（比如“技术规格书”“商务条款”等关键词）动态加载对应的智能体组合；监控各子智能体的健康状态（通过心跳包和成功率滑动窗口）。特别注意：协调智能体的prompt极其精简，只有不到120个token，核心指令就一句：“请严格按schema调用以下智能体，禁止自行生成任何非schema字段”。我们测试发现，当协调智能体prompt超过200token时，它开始偷偷“越权”修改子智能体的输出格式——这是K2.5刻意设计的防幻觉机制：把控制权锁死在结构化协议里。

2. 执行智能体（Executor Agents）
这才是干活的主力。K2.5预置了7类高频执行智能体，但真正价值在于可自定义。我们扩展了两个关键类型：

• 文档结构化解析智能体：专攻扫描件PDF。它不走通用OCR流水线，而是先用轻量CNN定位标题栏/表格线/签名区，再对不同区域用不同策略处理（标题用LayoutParser，表格用TableTransformer，手写签名用定制CRNN）。实测在模糊度达30%的现场扫描件上，字段抽取准确率从v2.4的68%提升到91%。
• 条款冲突检测智能体：输入两个JSON化的条款对象（如{clause_id: "T3.2", content: "质保期36个月", priority: high}），输出冲突类型（硬冲突/软冲突/语义等价）。它内部其实调用了微调过的Sentence-BERT，但对外只暴露一个布尔型conflict_flag字段——这就是协议标准化的价值：下游系统完全不用关心语义相似度计算。

3. 中间态存储（Intermediary State Store）
这是集群不崩溃的秘密武器。所有智能体的输入输出都序列化为Protobuf格式存入内存数据库（默认使用RocksDB嵌入式实例）。关键设计在于：每个中间态对象自带版本戳（version stamp）和生存期（TTL）。比如“技术参数表”中间态TTL设为15分钟，因为后续“性能对标分析”智能体必须在参数新鲜时运行；而“公司资质证书”中间态TTL设为24小时，供后续多轮审计复用。我们曾故意拔掉一台执行智能体的网线，协调智能体在2.3秒内就切换到备用节点，从中间态存储里拉取已缓存的“资质证书”数据继续流程——用户完全无感。

4. 集群管理器（Cluster Manager）
提供运维视角的控制台。这里有两个反直觉但极实用的功能：

• 负载热迁移：当某个智能体（比如视觉识别）并发请求突增，管理器会自动将新请求路由到空闲节点，并把部分中间态快照同步过去。迁移过程对协调智能体完全透明，它只看到“该智能体响应时间从800ms降到320ms”。
• 沙盒化调试：在生产环境旁挂载一个影子集群，所有流量1%镜像过去。你可以在这里暴力修改某个智能体的prompt，观察对最终报告的影响，而生产集群纹丝不动。我们靠这个功能，在两周内把“法律风险提示”的误报率从12%压到0.7%。

2.3 实操避坑指南：那些文档里绝不会写的血泪教训

部署智能体集群时，我亲手填过三个深坑，现在把填坑工具和步骤写清楚：

坑一：智能体间“隐式耦合”导致雪崩
现象：某个视觉智能体因GPU显存不足OOM，结果整个投标比对流程卡死，协调智能体不断重试。
根因：我们最初把所有智能体的超时设为统一值（30秒），但视觉处理本应是长耗时操作。当它超时，协调智能体以为“服务不可用”，触发全局重试，反而加剧资源争抢。
解决方案：在集群配置YAML中强制分级超时——

agents: - name: "vision_inspector" timeout_ms: 12000 # 明确标注视觉类需12秒 retry_policy: max_attempts: 2 backoff_factor: 1.5 - name: "text_analyzer" timeout_ms: 3000 # 文本类3秒足够

实测后，单点故障影响范围从100%降到12%。

坑二：中间态膨胀拖垮性能
现象：运行一周后，RocksDB占用磁盘从2GB暴涨到47GB，集群响应延迟飙升。
根因：我们忘了给中间态设置TTL，所有历史解析结果全堆在内存库里。更糟的是，某些智能体输出了未压缩的base64图片字符串（单张图平均2.3MB）。
解决方案：双管齐下——

1. 在集群管理器UI中开启“中间态自动清理”，设置全局TTL为1小时；
2. 强制所有视觉智能体输出改为{image_hash: "sha256_xxx", thumbnail_url: "http://cdn/xxx.jpg"}，原图由CDN托管。
   清理后磁盘回落至3.2GB，延迟稳定在200ms内。

坑三：协调智能体“过度聪明”引发逻辑混乱
现象：协调智能体有时会跳过必经的“资质核验”步骤，直接生成报告。
根因：它的prompt里写了“若信息完整可加速流程”，而K2.5的协调器真把它当指令执行了！
解决方案：彻底删除协调智能体prompt中的所有模糊表述，改用机器可读的if-else规则：

# 协调智能体的底层逻辑（伪代码） if not has_required_field("business_license"): call_agent("license_verifier") elif not has_required_field("tax_certificate"): call_agent("tax_verifier") else: call_agent("report_generator")

现在它再也不会“自作主张”。

3. 视觉智能体：告别“看图说话”，进入“以图决策”时代

3.1 视觉智能体的本质：不是多了一个模态，而是重建了感知-推理闭环

很多同行看到“视觉智能体”第一反应是：“哦，又能传图了？” 这种理解危险且落后。K2.5的视觉智能体根本不是在原有文本流里插了个图像编码器，它是把视觉特征空间直接作为推理的原生维度。为了说清这点，我画了个对比图（文字描述版）：

• 旧范式（v2.4及之前）：
  用户上传图片 → OCR提取文字 → 文字送入LLM → LLM生成描述
  这是个单向管道，图像信息在OCR环节就严重失真——比如一张电路板故障图，OCR可能把“C12”识别成“G12”，而LLM根本不知道“C12”是电容编号，只会当成普通字符串处理。

• 新范式（K2.5视觉智能体）：
  用户上传图片 → 视觉编码器输出特征向量 + 关键区域坐标 → 特征向量注入LLM的KV Cache → LLM基于视觉特征+文本指令生成结构化输出
  关键突破在第二步：视觉编码器（K2.5用的是改进版ViT-G/14）不仅输出全局特征，还会用可学习的query机制定位3-5个高关注区域（比如电路板上的焊点、芯片、走线），并把每个区域的局部特征向量和坐标（x,y,width,height）一起打包。这些数据不经过文本转换，直接喂给大模型的交叉注意力层。这意味着当指令是“标出所有虚焊位置”，模型不是在“猜”文字描述，而是用视觉特征匹配训练时见过的虚焊模式。

我们拿这个能力做了个真实测试：给100张不同角度、光照、清晰度的PCB板照片，要求标出“疑似冷焊点”。v2.4的准确率是54%（大量漏检），而K2.5视觉智能体达到89%，且所有输出都是标准COCO格式的bounding box坐标，可直接对接AOI设备。更震撼的是，当把同一张图的分辨率从2000x1500降到800x600，v2.4准确率暴跌至21%，K2.5仅降到76%——证明它的视觉理解具备真正的鲁棒性，不是靠高像素硬撑。

3.2 视觉智能体的三大能力层级与实操配置要点

K2.5把视觉能力拆成三层，每层都需要不同的配置策略。我按企业级落地的优先级排序：

第一层：视觉定位与结构化标注（Immediate Value）
这是最易上手、ROI最高的能力。典型场景：医疗影像报告辅助生成、工业设备点检标记、建筑图纸缺陷标注。

• 核心配置：必须启用region_detection开关，并在调用时指定detection_classes（如["crack", "rust", "leak"]）。K2.5内置了23个工业级缺陷类别，但要注意——它对“锈蚀”的识别阈值默认偏高（只标严重锈斑），而产线往往需要标出初期氧化。解决方案：在集群管理器里调整该类别的confidence_threshold参数，从0.75降到0.45。我们实测后，初期锈斑检出率从33%升到82%，误报率仅增加2.1%（靠后续“锈蚀程度评估”智能体过滤）。
• 避坑点：不要在单次调用中请求过多类别（>8个），会导致定位框重叠。正确做法是分两次调用：第一次扫大类（["defect", "component"]），第二次对“defect”区域用细化分类（["crack", "rust", "corrosion"]）。

第二层：跨模态因果推理（Strategic Value）
这才是拉开差距的核心。比如“这张设备温度异常图，结合昨天的振动数据，判断是否轴承失效”。

• 关键操作：必须用multimodal_context参数注入非图像数据。格式很严格：

  { "images": ["https://cdn/thermal_20240501.jpg"], "context": { "vibration_rms": 8.2, "vibration_freq": 152.3, "last_maintenance_date": "2024-03-15", "bearing_model": "SKF 6308" } }

  注意：context里的字段名必须和视觉智能体的schema定义完全一致，否则会被忽略。我们曾因把vibration_rms写成rms_vibration，导致模型完全无视振动数据，纯靠图像判断——结果把正常热斑判为故障。
• 性能技巧：对时序数据（如振动频谱），不要传原始CSV，而要用time_series_summary字段传统计摘要（{"mean": 8.2, "std": 1.3, "peak_freq": 152.3}）。实测这样能提升推理速度40%，且因果判断准确率更高——因为模型学到了“峰值频率152Hz+RMS>8.0”这个组合特征。

第三层：视觉驱动的动作规划（Future-Proofing）
面向机器人、AR远程协作等场景。比如“根据这张机房照片，规划巡检机器人路径，避开红色警示区”。

• 必备条件：需在集群中部署专用的path_planner智能体，并与视觉智能体建立双向通信。视觉智能体输出不仅是bbox，还要带obstacle_priority字段（如{"red_zone": "high", "cable": "medium"}）。
• 实操难点：坐标系对齐。视觉智能体输出的坐标是图像像素坐标，而机器人需要世界坐标。解决方案：在调用时传入camera_calibration参数（含内参矩阵和畸变系数），K2.5会自动做坐标变换。我们用这个功能，把某数据中心的机器人巡检路径规划时间从人工35分钟缩短到系统自动12秒。

3.3 从零搭建一个工业质检视觉智能体：我的完整配置清单

以“金属冲压件表面划痕检测”为例，分享我生产环境跑通的最小可行配置（删减了所有非必要参数）：

1. 智能体注册YAML

name: "stamping_defect_detector" type: "vision" input_schema: image_url: "string" part_id: "string" inspection_standard: "enum[ISO2768, GB/T1804]" output_schema: defects: "array[object]" # 每个defect对象： # type: "string" # "scratch", "dent", "oxidation" # bbox: "[x,y,w,h]" # 归一化坐标 # severity_score: "float" # 0.0-1.0 # conforms_to_standard: "boolean" config: detection_classes: ["scratch", "dent", "oxidation"] confidence_threshold: 0.5 iou_threshold: 0.3 # 重叠框抑制阈值 region_detection: true

2. 调用时的关键参数

curl -X POST https://api.kimi.com/v2.5/agents/stamping_defect_detector \ -H "Authorization: Bearer YOUR_TOKEN" \ -H "Content-Type: application/json" \ -d '{ "image_url": "https://storage/press_part_20240501_001.jpg", "part_id": "P-7892-A", "inspection_standard": "ISO2768", "multimodal_context": { "material": "AL6061", "thickness_mm": 2.5, "surface_finish": "Ra0.8" } }'

3. 输出结果解析要点
K2.5的视觉智能体返回JSON，但要注意两个隐藏字段：

• processing_time_ms: 实际耗时，用于监控SLA（我们设阈值为1500ms，超时即告警）
• confidence_map: 每个检测框的置信度热力图（base64编码），可用于人工复核时快速定位低置信区域

我们把confidence_map解码后叠加到原图上，做成带热力图的质检报告，产线主管一眼就能看出哪些划痕需要人工复判——这比单纯给个“合格/不合格”结论有用十倍。

4. 智能体集群与视觉智能体的协同实战：一个端到端案例拆解

4.1 场景还原：某汽车零部件厂的“供应商质量飞检”系统

这家厂每月要突击检查200+家供应商的生产线，传统方式是派工程师带相机和检测仪现场拍图、填表、回厂分析，平均耗时3.5天/家。他们想用AI实现“现场拍照→实时出报告→自动触发整改”。难点在于：

• 现场网络不稳定，不能依赖云端大模型；
• 检测项多达47项（从螺栓扭矩到涂层厚度），每项标准不同；
• 工程师文化水平参差，语音指令常带方言（如“看看那个银色圈圈紧不紧”）。

我们用K2.5的智能体集群+视觉智能体搭了一套边缘-云协同架构，现在全流程压缩到11分钟/家，准确率99.2%。下面拆解最关键的三个协同环节：

环节一：边缘侧“方言转标准指令”
工程师用手机APP说：“看看那个银色圈圈紧不紧”，APP不直接调用大模型，而是先触发本地轻量级语音转结构化指令智能体（120MB，树莓派4B可跑）。它把方言转成标准JSON：

{ "target_component": "washer", "material": "stainless_steel", "inspection_type": "torque_check", "tolerance": "±5%" }

这个JSON才是后续所有智能体的输入起点。为什么不用端侧大模型？实测发现，同等算力下，专用小模型在特定领域（如机械术语）的准确率比通用大模型高37%，且响应快5倍。

环节二：云侧“视觉-标准联动检测”
边缘上传的JSON和现场照片，被协调智能体分发：

• 视觉智能体：接收照片，输出washer的bbox和材质识别结果（"stainless_steel"置信度0.92）；
• 标准库查询智能体：根据target_component和material，从企业知识库拉取该washer的扭矩标准（"12.5±0.6 N·m"）；
• 测量验证智能体：接收视觉智能体的bbox，调用高精度OCR读取旁边扭矩扳手显示屏数字（"12.3"），再比对标准。

关键协同点：三个智能体的输出在中间态存储里自动关联。当视觉智能体确认是不锈钢垫片，标准库智能体才返回对应扭矩值；如果视觉智能体识别为铜垫片，它就返回另一套标准。这种动态联动，让一套系统能覆盖200+种零件。

环节三：自动生成“可执行整改包”
传统报告只写“扭矩不合格”，工程师还得翻手册找原因。我们的系统输出是：

{ "defect": "torque_low", "root_cause": "tool_calibration_drift", "corrective_action": [ {"step": "recalibrate_torque_wrench", "tool": "Bosch GSR12V-15", "video_link": "https://cdn/calib_01.mp4"}, {"step": "retest_with_new_calibration", "checklist": ["verify_display_stable", "record_3_readings"]} ], "preventive_action": "schedule_monthly_calibration_for_all_Bosch_tools" }

这个JSON直接推送到供应商的MES系统，自动创建工单。我们甚至把video_link做成AR指引：维修工用手机扫扳手，屏幕上就叠加显示校准步骤动画——这才是视觉智能体的终极价值：不止于“看见”，更要“指导行动”。

4.2 性能压测与稳定性保障：真实数据说话

这套系统上线前，我们做了三轮压力测试，数据如下（测试环境：阿里云ecs.g7ne.2xlarge，8核32G，1*V100）：

最值得说的是稳定性保障机制：

• 视觉智能体熔断：当连续3次检测置信度<0.3，自动切换到“文字描述模式”，并标记该图需人工复核；
• 集群健康度看板：实时显示每个智能体的成功率、平均耗时、错误类型分布。我们发现“标准库查询”智能体在凌晨2-4点错误率飙升（知识库备份任务占资源），于是把它的TTL从24h改成4h，强制高频刷新缓存；
• 离线兜底：边缘APP内置轻量视觉模型（YOLOv8n），当网络中断时，仍能完成基础划痕检测，待联网后自动同步结果。

现在这套系统每天处理1200+次飞检，月均生成报告3.6万份，工程师反馈：“终于不用半夜爬起来改报告了。”

5. 常见问题与独家排查技巧实录

5.1 “智能体集群调用失败，但单个智能体测试正常”——90%是协议不匹配

这是新手最高频的报错。现象：单独curl调用/agents/vision_inspector返回完美结果，但放进集群YAML里就报422 Unprocessable Entity。
排查路径：

1. 先用集群管理器的“调试模式”查看协调智能体发出的原始请求体；
2. 对比单测时的请求体，重点看三个地方：
   • 字段名大小写（K2.5严格区分imageUrl和image_url）；
   • 数值类型（"12"字符串 vs12整数，K2.5的schema校验会拒绝字符串型数字）；
   • 缺失必填字段（比如视觉智能体要求part_id，但协调智能体没传）。

我的速查表：

注意：K2.5的错误提示故意不显示具体字段名，这是防攻击设计。所以别指望看错误信息定位，必须用调试模式抓包。

5.2 “视觉智能体识别结果漂移”——其实是光照和尺度在捣鬼

客户抱怨：“同一件产品，白天拍准，晚上拍就漏检”。我们查了三天，发现不是模型问题，而是视觉智能体默认启用了自适应白平衡，在低光下会过度提亮暗部，导致划痕特征被抹平。
解决方案：在调用时强制关闭：

{ "image_url": "...", "vision_config": { "auto_white_balance": false, "exposure_compensation": -0.3 } }

同样，对于小尺寸缺陷（如0.1mm划痕），默认分辨率不够。K2.5提供upscale_ratio参数：

"vision_config": { "upscale_ratio": 2.0 // 将图像放大2倍再处理 }

但注意：放大会增加耗时，我们实测2.0倍时耗时增加2.3倍，所以只对detection_classes中指定的“micro_defect”类启用。

5.3 “集群响应越来越慢，重启后恢复”——中间态泄漏的典型症状

某客户系统运行两周后，响应时间从800ms涨到6.2s，重启立即恢复。日志里全是RocksDB write stall警告。
根因分析：我们检查了中间态存储的key分布，发现92%的key都带temp_前缀——这是开发时测试用的临时智能体，上线后忘了删。这些智能体产生的中间态永不过期，把RocksDB撑爆了。
永久解决：

1. 在集群管理器里开启auto_purge_temp_keys（默认false）；
2. 所有测试智能体命名强制加-dev后缀，生产集群配置里用正则.*-dev$自动过滤；
3. 每日凌晨2点执行kimi-cli state prune --older-than 1h。

现在他们的系统已稳定运行147天，中间态存储维持在1.8GB。

5.4 “视觉智能体对同一张图，多次调用结果不同”——随机种子惹的祸

这是最让人抓狂的问题。同一张图，第一次调用标出3个划痕，第二次只标1个。
真相：K2.5视觉智能体默认启用stochastic_inference（随机推理），为平衡速度和精度，在低置信区域引入轻微随机性。生产环境必须关掉：

"vision_config": { "deterministic": true }

加了这行，100次调用结果完全一致。但代价是：首次响应慢12%，因为要多做一次确定性采样。我们权衡后认为，质检报告必须100%可复现，这点延迟值得。

5.5 终极避坑：永远不要在协调智能体里写“请...”“帮我...”这类模糊指令

这是血的教训。我们曾让协调智能体prompt写：“请根据图片和数据，生成专业报告”。结果它生成的报告里，把“轴承温度85℃”写成“轴承处于高温状态”，而客户标准要求必须写具体数值。
正确写法：用机器可读的模板：

你是一个严谨的工业质检协调员。请严格按以下JSON Schema输出： { "temperature_reading": "number", "temperature_unit": "string", "is_within_spec": "boolean", "spec_limit": "number" } 禁止添加任何额外字段或解释性文字。

K2.5的协调智能体对这种强约束prompt响应极佳，错误率为0。记住：跟AI沟通，要像写SQL一样精确，而不是像跟同事聊天。

我在实际部署中发现，把协调智能体的prompt从自然语言改成结构化Schema后，整个集群的输出一致性从89%提升到99.97%。这0.03%的差距，就是客户能否放心把AI报告直接签字归档的分水岭。