最近做一个智能体开发平台的上线接入，最典型的场面又出现了：对方报了一堆问题过来，语气里隐含着一个前提，只要 Agent 没跑成，那大概率就是平台的问题。
这个判断不能说完全错。平台运行时当然要负责，任务调度、超时控制、异常恢复、长任务状态、下一步唤醒，这些地方任何一个不稳，都会让用户感知成“系统坏了”。但如果你只听问题反馈，不沿着真实动线复测一遍，很容易被第一层现象带偏。
真正麻烦的地方在这里：一个 Agent 能不能成功，不只由平台决定。它还取决于输入材料、模型能力、Skill 设计、任务边界、上游数据、检索质量、校验逻辑和多轮执行衔接。只要其中一层没被评测看见，最后所有失败都会挤到平台头上。
所以这次我没有急着写脚本批量跑。更快的办法当然有，把几百个用例扔进去，自动收集结果，最后汇总成功率、失败率和耗时。但这一次我选择先做一件看起来很笨的事：让项目组按用户真实动线，一条一条跑。
打开界面，输入问题，上传材料，观察执行过程，等待长任务，登记运行会话，记录输出结果，再把失败逐项归因。合同生成和审查这种场景，一条任务跑三四十分钟并不稀奇，因为它背后有材料识别、条款提取、规则检索、风险判断、格式生成和多轮校验。
这个苦活值得干。因为跑完之后，很多“平台不行”的反馈，开始变成可以讨论的证据。
一、你听到的“平台有问题”，很多时候只是第一层现象
复杂 Agent 的失败，不能用一句“平台异常”收口。
用户感知到的是结果：没有生成合同、没有审查意见、页面停住了、任务没有继续触发、上传图片后模型拒绝分析。站在用户角度，他当然会说系统异常，因为他不需要理解平台、模型和 Skill 的边界。
但交付团队不能停在这一步。你必须把“没跑成”拆开：是输入材料不适合当前模型，还是模型根本不具备图片理解能力；是 Skill 没有写清楚异常分支，还是平台在唤醒下一个执行任务时没有成功；是检索结果为空，还是合同任务本身超出了既定边界。
这次复测里，一个很典型的现象是：标准合同生成任务基本稳定，单纯生成合同的链路表现符合预期。真正容易失败的地方，集中在大图片、非相关任务、模型能力配置不匹配，以及长任务执行后的下一步衔接异常。
这也是为什么 AI 产品的评测不能只看最终状态。OpenAI 的评估实践强调，评测是理解大模型应用是否符合预期、构建可靠应用的重要组成部分；NIST AI 风险管理框架也把设计、开发、使用和评估放在同一个风险治理链条里。放到企业 Agent 上，意思很简单：可靠性不是上线时喊出来的，是一条条真实任务跑出来的。
二、Agent 不是交付软件，而是在交付一段确定结果
传统软件交付的是功能入口，Agent 交付的是一段可被信任的完成过程。
软件时代，很多验收可以围绕功能点展开：按钮能不能点，字段能不能校验，流程能不能流转，报表能不能展示。AI Agent 不一样。你给它一个目标，它要自己走完一段过程，期间还可能调用工具、读取材料、检索规则、生成内容、校验结果、触发下一个任务。
这就意味着，Agent 的“成功”不是页面最终出现一段文字那么简单。合同生成场景里，真正的成功至少包含几件事：输入材料被正确理解，合同类型被识别，关键条款没有遗漏，企业规则被引用，输出格式能被业务使用，高风险位置有人复核，失败时能说明卡在哪里。
如果只测最后有没有文本，你会得到一种很危险的稳定感。看起来系统有输出，实际上中间的依据、边界、异常和人工接管都没有被检查。这样的 Agent 很适合演示，不适合上线。
尤其是合同生成和审查这种高精度场景，用户不是来体验“AI 很聪明”的。他要的是一份能交给业务、法务或管理层继续判断的结果。只要过程不可解释，结果不可回放，异常不可归因，再炫的模型也会变成一次冒险。
三、合同场景最能暴露假评测，因为它又长又重又高风险
越是复杂任务，越不能只用一个输入和一个输出来定义评测。
合同类 Agent 很容易让团队误判难度。表面看，任务只是“生成合同”或“审查合同”，实际上它需要处理上游材料、合同类型、交易结构、付款条件、违约责任、交付边界、数据合规、争议解决和企业模板规范。很多时候，它不是一次回答，而是一段工作链。
这也是为什么一条用例可能跑三十分钟到五十分钟。不是系统慢一点那么简单，而是任务本来就重。它要读取资料，要比对条款，要检索规则，要反复校验，还要在输出前尽量减少明显错误。你如果用一句“接口超时”概括它，就会错过真正的问题。
更关键的是，合同任务的失败不一定来自“专业能力不足”。有时是模型配置不支持图片输入，却收到了大图或扫描件；有时是用户输入的任务和当前 Skill 无关，系统没有正确拒绝或转向；有时是前一个 Skill 跑完了，但没有成功唤醒后续任务，用户看到的就是“没结果”。
一旦你把链路画出来，就会发现修复方向完全不一样。模型不支持图片，就要换模型或调整文件处理策略；任务不相关，就要设计边界识别和友好拒绝；后续任务没有唤醒，就要查运行编排和触发机制；Skill 没有终止条件，就要重写流程控制。
四、最笨的办法最有效：沿着用户动线一条条跑
第一次评测不要急着自动化，先用人的眼睛把真实过程看清楚。
我知道这句话听起来不够“AI”。大家都想自动化，最好几百个用例一键跑完，系统自动分析结果，最后生成一张漂亮报表。这个方向当然对，但它不是第一步。
第一步更像一次现场观察。你要像用户一样打开界面，输入同样的问题，上传同样的材料，等待同样的过程，看到同样的状态。你要记录每条任务的运行会话编号、输入内容、材料类型、执行耗时、过程状态、最终结果和异常表现。
这个过程很烦，但它能暴露脚本看不见的问题。脚本不会因为页面没有进度提示而焦虑，不会因为等太久而重复点击，不会因为任务结束后没有下一步而误以为系统卡死。真实用户会。
这次我们把每个项目组分到二十个左右的用例，让大家亲自跑。跑完以后，团队对问题的理解变了。以前是“对方报了很多问题”，现在是“哪一类输入导致失败、哪一类任务稳定、哪一步衔接异常、哪条日志可以复查”。
五、失败要分层归因：模型、Skill、平台、输入材料都要看
评测最大的价值，不是统计失败率，而是把失败拆成可修复的类型。
这次最典型的两类失败，一类来自模型与输入不匹配。比如用户上传了图片材料，但当前选用的模型或通道没有处理图片的能力，模型拒绝分析就是正常行为。这个时候继续优化平台性能没有意义，正确动作是调整模型配置、文件处理策略，或者在产品入口提前提醒。
另一类来自任务执行衔接。前一个 Skill 跑完之后，后一个任务没有被成功唤醒，用户看到的就是没有最终结果。对用户来说，这是失败；对平台方来说，这可能是运行编排、任务调度、状态传递或异常重试的问题。它必须修，但不能和模型拒绝图片分析混在一起。
还有一些失败来自 Skill 本身。复杂 Skill 如果没有清楚的边界、终止条件和异常分支，就会把任务带入错误路径。比如材料不足时该追问一次还是继续生成，规则库无命中时该标注风险还是继续猜测，非相关任务出现时该拒绝还是硬接，这些都不是模型自己能长期稳定解决的。
我更建议把 Agent 评测成熟度分成五层。L0 是凭感觉试用，谁试谁说了算；L1 是接口脚本，只看输入输出；L2 是用户动线复测，能复刻真实操作；L3 是过程观测，能记录执行状态、工具调用、异常和人工接管；L4 是归因闭环，评测结果直接进入修复、AB 对比和回归。
很多团队不是没有评测，而是卡在 L1。能跑批量脚本，但看不见过程；能看到失败率，但说不清失败原因；能改一个 bug，但不知道同类问题会不会再发生。
六、自动化该做，但不要替代第一次亲眼观察
该下笨功夫的时候偷懒，后面一定会在扯皮里还债。
人工一条条跑，不代表反自动化。恰恰相反，人工评测之后，更应该把高频排查动作自动化。比如这次我们把运行排查做成一条诊断 Skill，它能根据运行会话编号读取日志，梳理执行过程，分析失败原因，再把判断结果交给团队复核。
这个动作很关键。因为人工复测解决的是“看见问题”，日志诊断 Skill 解决的是“提高归因效率”。前者让你不被片面反馈带偏，后者让你不用在海量日志里一条条翻。两者配合，才是更现实的 AI 产品评测方式。
但顺序不能倒。你不能还没理解用户怎么失败，就先相信自动化分析能告诉你全部答案。自动化只能放大你已经定义清楚的观察点。观察点没定义清楚，自动化会把模糊判断放大成更快的误判。
这也是我对很多 AI 团队的提醒：不要迷信“一句话生成一个 demo，两天做出一个产品”。Demo 可以快，交付不能只快。第一次做出来不完美很正常，但一直不愿意评测、不愿意打磨、不愿意把失败拆清楚，那就不是产品问题了，是工作方式问题。
七、评测驱动开发：每一次复测都是下一轮迭代起点
AI Agent 的开发，不应该由感觉驱动，而应该由评测驱动。
在传统软件里，需求、开发、测试、上线像一条相对清楚的流水线。到了 AI Agent，这条线会变成一个循环。你先把任务跑起来，再拿真实用例评测，再把失败归因，再改模型、改 Skill、改平台、改产品入口，再用同一批 Case 复测。
这个循环越早建立，团队越不容易陷入争论。平台团队不用被所有失败淹没，模型团队不用背所有输出问题，Skill 设计者也不能把流程边界写得模糊还期待系统自动变稳。每一层都有自己的责任，每一次失败都应该能进入下一轮修复。
明天就能做的动作并不复杂。先选十到二十个真实任务，不要选演示材料；每个任务打包原始附件、用户目标、期望输出和业务判断标准；再让团队按真实页面路径执行，记录输入、等待、状态、追问、中断、恢复和最终结果；最后把失败分到输入材料、模型能力、Skill 设计、平台运行、任务衔接、用户动线和外部系统几类里。
跑完第一轮之后，再做自动化。把高频路径做成回放，把常见失败做成诊断规则，把日志排查封装成 Skill，把同一个 Case 的新旧版本做 AB 对比。每一次修复都要回到用例里复测，不要靠会议判断“应该好了”。
AI 时代交付的不是一个看起来会说话的软件，而是一段可被信任、可被追踪、可被持续改善的结果链。这个结果链不会因为模型更强就自动稳定，它需要人亲自观察，需要团队分层归因，需要一轮轮复测，也需要承认有些笨功夫必须下。
真正能把 Agent 做进业务现场的团队，最后拼的不是谁更会讲概念，而是谁能把失败变成证据，把证据变成修复，把修复变成下一次更稳定的结果。