最近看一个合同与法务工作台的智能体项目，最扎心的地方不是它出现了中断，而是很多中断一开始被大家归因成“平台能力不够”。
这当然可能是真的。平台运行时、长任务调度、异常恢复、死循环保护，都可能有问题，也必须修。但一层层往下拆，情况很快变得复杂：有的中断来自平台访问凭证的限流，有的来自 Skill 自身设计让同一个问题反复发生，有的来自模型在长任务里没有被明确要求收束，有的才是平台代码质量本身的问题。
真正刺痛人的地方在这里：这些问题并不隐蔽。它们只是没有被正确的评测方式暴露出来。
很多 AI 产品的评测，还停留在把用例整理成脚本，丢给接口批量跑，最后看成功、失败、耗时、报错。这个动作有价值，它是稳定性回归的基线；但它只能证明系统在一个被切薄的入口上返回了结果，不能单独证明用户在真实工作台里能顺畅完成任务。
合同和法务场景尤其如此。真实用户不会只调用一次接口。他会上传附件、选择模板、切换工作台、等待长任务、查看过程状态、补充材料、处理中断、重新发起、追问原因，最后把结果交给法务、业务或管理者判断。任何一个环节不稳，都会被用户感知为“不可靠”。
一、把接口跑通，不等于把产品测过
接口评测能告诉你“入口和输出是否稳定”，真实动线评测才能告诉你“中间哪里开始变坏”。
很多团队做 AI 评测时，会把任务压缩成一个输入和一个输出：给一份合同，返回审查意见；给一个问题，返回分析结论；给一批附件，返回报告。这样做效率很高，适合做回归，也适合做模型版本对比。
但问题是，智能体产品的失败往往不只发生在输入和输出之间。它可能发生在任务排队时，发生在用户上传附件后，发生在长任务中途等待时，发生在模型重复追问同一件事时，发生在 Skill 进入错误分支时，发生在平台访问凭证被限流时，发生在异常恢复没有把上下文接回来的瞬间。
如果评测只看最后报错，团队会很自然地做出一个粗糙判断：模型不行、平台不稳、运行时有问题。这个判断看似合理，其实太省事了。省事的归因，往往带来低效的修复。
这个判断也不是孤立经验。NIST AI 风险管理框架把 AI 产品、服务和系统的设计、开发、使用、评估放在同一个风险管理视角里；OpenAI 的评估文档也把 evals 视为理解大模型应用表现、构建可靠应用的重要组件；NN/g 的可用性测试方法强调，让参与者完成现实任务，并观察行为与反馈。放到企业 Agent 里，结论很直接：评测不能只像测接口，要像观察一段工作。
二、真正的 Agent 评测，要先复刻用户动线
如果评测没有模仿用户真实动作，它测到的稳定性很可能是假的。
真实动线评测不是让测试同学辛苦一点，多点几下页面。它的本质是把用户完成任务的整个链路还原出来：谁在什么页面发起任务，上传什么材料，选择什么能力，等待多长时间，看到哪些状态，什么时候需要人工判断，失败后是否知道该怎么办。
这也不是说动线评测只能永远人工执行。更合理的节奏是：第一轮由人按真实任务观察，先把状态、断点和异常摸清楚；等路径稳定后，再把高频路径固化成自动化回放和回归用例。接口脚本、端到端自动化、人工观察，各自回答不同问题，不能互相替代。
比如合同审查工作台，一个真实评测用例不能只写“审查合同并输出风险意见”。它至少要写清楚：合同文件从哪里来，是否有补充附件，是否要引用企业条款库，是否涉及付款、违约、交付、数据合规等多类风险，用户希望得到的是红黄绿风险清单、修改建议，还是可直接发给业务的审查意见。
这时评测对象就不再只是模型输出，而是一个完整工作过程：入口是否清楚，材料是否被正确识别，长任务是否持续，过程状态是否可解释，异常是否可恢复，结果是否能被业务使用。
很多问题只有在这种动线里才会出现。接口脚本不会因为等得太久而焦虑，不会因为页面状态不明而重复点击，不会因为上一步没提示清楚而上传错误材料，也不会在任务中断后追问“我刚才做的还在不在”。真实用户会。
三、长任务中断，不一定是平台能力不够
AI 产品的问题，最怕一上来就找“唯一责任方”。长任务失败通常是多因素叠加。
长任务看起来像平台运行时问题，因为中断发生在平台里。但从工程和业务视角看，一次中断至少要拆成四层原因。
第一层是平台本身。任务调度有没有超时保护，是否支持断点恢复，是否能发现重复循环，是否能把异常状态明确展示给用户。第二层是运行配置。平台访问凭证、调用额度、并发限制、网络波动、依赖服务异常，都会让任务表现得像“智能体突然不干了”。
第三层是模型与任务边界。模型有没有被要求在信息不足时停止并询问，有没有被限制重复尝试，有没有清楚知道什么时候应该交付阶段性结果。第四层是 Skill。一个 Skill 如果把流程写成无限追问、模糊判断、重复校验，平台再稳定，也会被拖进循环。
这也是为什么一次真实复测之后，常常会发现“平台有问题”只是结论的一部分。该修平台就修平台，该调模型策略就调模型策略，该改 Skill 就改 Skill，该换运行配置就换运行配置。把问题摊开，修复才会快。
四、Skill 写不好，会把运行时推向异常边界
Skill 不是一段更长的提示词，它是一段可复用工作的运行说明书。
这个判断在很多企业 AI 项目里反复出现。大家以为平台能力上线了，模型能力接进来了，剩下就是把业务提示词写进去。可真正运行后才发现，Skill 的质量直接决定智能体能不能稳定工作。
一个合格的合同审查 Skill，不能只写“你是资深法务，请审查合同风险”。在业务建设语境里，它要说明输入材料有哪些，缺材料时怎么问，先提取哪些合同要素，如何区分风险等级，哪些条款必须引用依据，哪些情况要转人工，输出物应该给谁看，失败时如何收束。
更重要的是，它要避免把智能体推入重复问题。比如已经识别到缺少补充协议，就不要在后续步骤里反复要求同一份材料；如果企业规则库没有命中，就要清楚标注“依据不足，建议人工确认”，而不是继续猜测。长任务中很多看似平台中断的现象，背后其实是 Skill 没有设计终止条件。
所以，评测一个 Agent，不能只测模型答案，也要测 Skill 行为。它有没有调对能力，有没有按顺序执行，有没有在异常时停下来，有没有把结果交给人判断，有没有留下可追踪的过程记录。没有这些，平台越强，越容易把一个坏 Skill 跑得更快、更远。
五、评测要变成归因系统，而不是报错收集器
一个只统计失败率的评测系统，救不了复杂 AI 产品。
失败率当然要看。任务完成率、耗时、输出质量、人工接管次数、中断次数，都要看。但这些指标只能告诉你“病得重不重”，不能告诉你“病在哪里”。
更有效的做法，是把每一次失败都打上原因标签。至少要分成几类：用户动线问题、平台运行问题、运行配置问题、模型行为问题、Skill 设计问题、材料质量问题、外部系统问题。每个失败 Case 都要能回放，能看到关键状态，能定位它从哪一步开始偏离。
这时评测的价值会变得完全不同。它不再是上线前的盖章动作，而是产品、研发、算法、业务专家、Skill 设计者一起工作的事实底座。大家不用争“到底是谁的问题”，因为真实 Case 会把问题摆出来。
AI 产品经理在这里的职责，不是替每一层写技术修复方案，而是把评测资产产品化：任务包、成功标准、过程观测点、失败标签、复测规则。研发要把链路打稳，模型团队要把策略调准，业务专家要确认结果能不能用；产品经理要定义什么叫“业务上完成”、哪里必须人工接管、哪类问题进入哪条修复队列。
我更建议把 Agent 评测成熟度分成五层：L0 是人工试用，靠个人感觉判断好不好；L1 是接口脚本，只看输入输出；L2 是任务回放，能复现典型用户路径；L3 是过程观测，能记录状态变化、调用链路、人工介入和异常原因；L4 是迭代闭环，评测结果直接进入修复、AB 对比和再次回归。
多数团队不是没有评测，而是卡在 L1。能跑脚本，但看不见过程；能看到报错，但没有归因；能修一个点，但不知道同类问题还会不会复发。
六、最有效的修复方式，是拿真实 Case 做 AB Test
别急着争论谁对谁错，把同一个 Case 跑给对方看。
企业协作里有一个很现实的细节：很少有人愿意听你说“你这里也有问题”。平台团队不想被说能力不足，业务团队不想被说用法不对，Skill 设计者不想被说写得不稳，模型团队也不想被一句“模型不行”概括。
最好的办法不是讲道理，而是拿真实 Case 做对比。原来的 Skill 跑一次，调整后的 Skill 跑一次；原来的模型策略跑一次，收束条件明确后的策略跑一次；原来的运行配置跑一次，去掉限流干扰后的配置跑一次。过程录下来，结果摆出来。
当对方看到同一份合同、同一套附件、同一个任务，在不同版本下中断率、重复追问、耗时和输出质量明显变化，很多争论会自然消失。不是谁承认自己有问题，而是大家终于看见了问题在哪里。
这也是 AI 产品迭代里最重要的沟通技巧：不要用抽象判断说服人，要用可复现的任务说服系统。真实 Case 比任何会议纪要都有力量。
七、AI 产品的评测，不是验收动作，而是迭代起点
传统软件可以把很多验收放在后面，AI 产品更需要把评测放在前面。
传统软件里，很多功能的输入、路径和输出相对确定。按钮点了，字段校验了，流程流转了，验收更像上线前的门禁。AI 产品不一样。模型会变，任务会变，材料会变，用户问法会变，Skill 会被不断改写，外部系统也会波动。
所以 AI 产品的评测不能只服务于“能不能上线”。它要服务于“下一轮该改哪里”。评测越早进入，团队越容易建立共同语言：这个 Case 是模型问题，那个 Case 是 Skill 终止条件问题，另一个 Case 是运行配置问题，还有一个 Case 是用户动线设计问题。
对合同和法务这类高风险工作台来说，这一点更关键。你不能只问“最终审查意见对不对”，还要问“依据从哪里来、过程能不能回放、异常有没有提示、人工复核在什么位置、系统有没有越过授权边界”。这些问题本质上不是技术洁癖，而是让业务敢用、持续用、出了问题能追踪。
明天就能做的动作并不复杂。先选十个真实任务，不要选演示材料；每个任务打包原始附件、用户目标、期望输出和业务判断标准；再让测试人员按真实工作台路径执行，不只记录最后结果，也记录等待、重复、失败、补充材料和人工接管；最后把每个问题分到平台、运行配置、模型、Skill、用户动线和外部系统六类里。
做完这一轮，你会发现很多争论没有必要。该改代码的改代码，该改 Skill 的改 Skill，该调整模型策略的调整模型策略，该补工作台状态提示的补提示。评测不是为了证明某个团队没问题，而是为了让整个系统更快变好。
企业 AI 真正进入深水区以后，谁的模型更强只是一部分问题。更大的分水岭，是谁能把真实工作拆成可评测、可归因、可修复、可复跑的任务闭环。只有这样，智能体才不是一次次碰运气的演示，而是能在业务现场持续变稳的生产系统。