AI Agent 每一步都像做对了，为什么整个流程仍然失败

一个 Agent 打开了正确的记录，找到了正确的规则，生成了看起来正确的文件，也在正确的界面里完成了一连串点击。执行轨迹相当专业，大多数子任务都能得分，但整个工作最后仍停在错误的状态。

两项近期医疗 Agent 基准给出了这个令人不安的信号。HealthAdminBench 中，最佳完整任务成功率只有 36.3%，而最高子任务得分达到 82.8%；CHI-Bench 的最佳任务解决率为 28.0%，在更严格的三次重复可靠性指标下，没有任何受测配置超过 20%。这些结果来自模拟医疗环境，不是生产部署数据，不能外推成所有 Agent 的通用失败率。但它揭示的模式远不限于医疗：一连串局部合理的动作，不等于一项工作已经真正完成。

对小型产品团队来说，今天就该改变一件事：不要再用步骤完成率、漂亮的最终回复或一次成功演示来决定是否发布。先定义这项工作的“终态”——也就是流程结束时系统必须共同满足的状态——再从已知起点重复跑完整流程，并拿出证据证明预期状态确实出现，而不只是对话看起来完成了。

下面这份现场笔记把这个原则整理成一套发布门禁。它是建议执行的实验协议，不是我们已经跑过的测试报告。你可以把它改造成退款、用户入驻、客服升级、账号变更、采购、合规审核，或任何需要 Agent 读取规则并修改真实系统状态的流程。

两项新基准究竟证明了什么

HealthAdminBench 在四套模拟界面里评估电脑操作型 Agent，包括一套电子病历系统、两个保险方门户和一套传真系统。135 个专家定义的任务覆盖事前授权、拒付与申诉、耐用医疗设备订单，并被拆成 1,698 个可验证子任务。最佳端到端配置只能完成 36.3% 的完整任务；取得最高子任务分数 82.8% 的则是另一套配置。

CHI-Bench 使用了不同的执行环境。Agent 会收到一份临床案例、一套大型管理式医疗操作手册，以及跨多个医疗应用和 MCP 工具的模拟系统。它必须通过工具调用和不同角色产出的文件，把案例推进到明确终态。在论文报告的 30 种 Agent 运行框架（harness）与模型组合中，最佳配置解决了 28.0% 的任务；用三次重复衡量可靠性时，没有任何配置超过 20%；把全部工作放在同一个持续会话里执行时，论文报告的表现降到 3.8%。

这些结果确认了四个有边界的事实：

1. 测试环境包含长流程、密集规则和多个系统。
2. 子任务得分可以远高于完整流程成功率。
3. Harness 和交互设计会影响结果，所以这不是单纯比较模型。
4. 重复执行同一流程，会暴露单次成功掩盖的脆弱性。

但它们没有证明每个 Agent 产品的成功率都是 28% 或 36.3%，没有证明医疗自动化不可行，也没有给任何具体模型一个可跨场景使用的“通用可靠性分数”。CHI-Bench 是新预印本，并公开了代码仓库和数据集；HealthAdminBench 同样是一篇近期基准论文。两者的模拟环境都省略了真实运营的一部分，而且它们的任务分布不等于你的用户分布。目前也缺少独立的生产环境复现。

真正能迁移到产品团队的结论更窄，也更有用：如果你的指标奖励“过程”，而用户依赖的是“结果”，那发布门禁测错了对象。

先分清三个概念，避免评审从一开始就失真

团队经常说“Agent 完成了任务”，但这句话可能混合了三件不同的事。写评测前，先把它们分开。

子任务成功，指某个中间要求已经满足：找到了记录，提取了字段，检索到规则，或者生成了草稿。子任务指标非常适合定位故障，能告诉团队流程在哪里断了；它不是工作已经办完的证据。

终态成功，指流程结束时，环境处于明确可接受的状态。数据库字段、外部系统状态、用户看到的结果、审计记录和后续队列都要与预期一致。一个流程可以有多个合格终态，例如“完成”“正确升级给人工”或“依据规则安全拒绝”；但“Agent 停止运行”本身不算终态。

重复可靠性，衡量同一场景在多次独立执行中，能否持续进入合格终态。最初的 τ-bench 论文提出用 pass^k 呈现这种差异：一个偶尔成功的系统，在用户要求同一件事稳定办成时仍然可能不可用。你的具体指标可以不同，但必须把单次任务成功与多次重复成功分开报告。

还有一个容易混淆的边界：检查终态，不等于强迫 Agent 走唯一一条标准路径。正确路径可以有多条。评估器应约束结果、必要证据和禁止动作，而不是要求 Agent 按预先写死的顺序逐个点击。

一个小团队真正会遇到的场景

假设一家 SaaS 公司上线了一个 Agent，负责处理客户请求：“取消我今天早上购买的年度升级，并恢复原来的月付方案。”Agent 可以读取计费规则，检查账号，调用计费工具，更新 CRM 备注，再给客户发邮件。

一个按步骤评分的演示，可能检查：

• 是否识别出取消意图；
• 是否找到正确客户；
• 是否检索到退款规则；
• 是否调用退款函数；
• 是否生成确认邮件。

这五步里即使通过四步，系统仍可能留下代价很高的烂摊子。退款可能退到了错误的扣款记录；年度订阅可能仍在生效；原来的月付方案没有恢复；CRM 写着“已解决”，支付服务商却仍显示“处理中”；邮件承诺已经退款，但没有任何系统真的退钱；重试一次还可能造成重复退款。

终态定义应该完全不同：

• 目标年度扣款只有一笔退款，并处于允许的状态；
• 年度订阅已取消，不会再次续费；
• 原月付方案已恢复，续费日期正确；
• 账号中只有一条审计记录，能够关联请求、决策、工具调用和最终生成的各类 ID；
• 客户消息描述的是已观察到的状态，而不是假设未来会发生的状态；
• 任何必要状态转换失败时，案例必须标记为未解决并交给人工；
• 重跑保持幂等，不会重复移动资金，也不会重复发送消息。

这就是 Build Lab 视角的关键动作：在评估 prompt、模型或 Agent 框架之前，先把“处理取消请求”翻译成可观察的系统状态。

为什么子任务得分很高，整件事仍会失败

长流程的失败方式与做选择题不同。错误会与系统状态相互影响。

第一，小错误会叠加。假设十个必要阶段各有 95% 的成功率，而且失败彼此独立，那么十个阶段全部成功的概率也只有约 60%。现实中的 Agent 错误并不独立，因此这只是解释机制的算术示例，不是可靠性预测。一次错误的身份匹配足以污染后面所有动作；选错一版规则，也能让其余执行再完美都失去意义。

第二，有些动作会真正改变世界。读取一条记录和发起退款，不是风险相同的两个步骤。SABER 论文区分了会改变环境的动作与只读动作，并研究“决定性偏差”——最早让成功轨迹转成失败结果的动作级分叉。在会修改状态的步骤里，一个看起来很小的参数错误，可能比十次正确检索更重要。

第三，角色交接隐藏着接口契约。前一个角色生成文件，后一个角色根据文件继续工作。前者可能在自己的评分里“完成”，却漏掉后者必需的字段。CHI-Bench 特意加入多角色和角色专属产物，因为交接本身就是任务的一部分，不是附带的行政工作。

第四，漂亮的回复可能与后台状态矛盾。语言模型擅长生成连贯文字，所以一句自信的“已经完成”证据力很弱。评估器必须读取权威系统，而不是给最终话术的语气打分。

最后，重试会改变问题本身。如果第一次执行已经修改状态，那么第二次运行不只是“再采一个样本”。没有重置或幂等保护时，一次重试可能把可恢复的小故障变成重复扣款、重复工单、冲突审批或重复通知。

终态发布卡：先把验收对象写成一页

构造测试用例前，先为每条工作流写一张卡。这是发布评审最核心、可复用的模板。

能写成机器断言的地方尽量不要写模糊描述。“CRM 看起来没问题”很弱；“案例 C-1042 的状态为 escalated、原因非空、没有退款 ID，且审核队列中恰好有一条记录”才可测试。

如果产品本来就允许合理的安全退出，就不要强行把结果压成“完成/失败”两类。正确交给人工可以是合格终态，悄悄丢掉任务不是；规则禁止操作时，正确拒绝可以通过，但证据足够时泛泛拒绝仍应失败。

这张卡同时也是一次产品设计评审。如果团队说不清哪个系统才是权威来源、哪些最终状态有效、重试时应该发生什么，那么无论模型看起来多聪明，这条工作流都还不适合自主执行。

用真实工作流形状构造测试用例

先做 5 到 12 个测试用例，不要一开始就生成上百个合成变体。每个用例应代表一种不同的状态转换或故障边界。

建议覆盖以下组合：

1. **正常路径：**证据完整、规则普通、所有依赖可用。
2. **缺少事实：**Agent 必须追问或升级人工，不能猜。
3. **系统冲突：**CRM、数据库与外部服务商对当前状态的记录不一致。
4. **规则边界：**请求刚好落在资格窗口内或窗口外。
5. **部分变更：**一个系统修改成功，下一次调用失败。
6. **重复请求：**同一用户意图出现两次，或 worker 自动重试。
7. **不安全请求：**身份、权限或授权范围不足。
8. **过期产物：**交接文件反映的是旧版案例状态。

如果从生产轨迹生成用例，必须先删除或转换敏感数据，并取得必要授权。没有生产轨迹时，可以让领域专家设计场景，但要明确标记为“设计用例”；在真实流量证据出现前，不要声称它们代表实际用户分布。

每个用例都要把初始快照与预期快照分开保存，重置过程必须确定。如果外部沙盒无法真正重置，就使用唯一测试账号和幂等键，并把清理结果也写成断言。会留下残余状态的测试用例，会污染下一轮执行并制造错误结论。

AppWorld展示了可控评测环境的工程成本：论文描述了一个跨应用模拟世界、大型执行引擎、数百个 API 和大量测试。小团队不需要重建 AppWorld，但至少要能确定初态、观察终态，并在没有隐藏残留的情况下重跑用例。它的开源实现可以作为参考，帮助理解如何显式组织应用状态和任务评估。

把发布门禁跑成可重复、可追溯的实验

一次绿色结果只是演示。发布门禁需要重复试验。

每个用例至少独立执行三次，每次都从同一个已知初态开始。除非持久上下文本身就是被测产品的一部分，否则每次试验都使用新的 Agent 上下文。记录所有组件版本和预算，不要悄悄给候选版本更多重试、时间或 token。

最小实验包含两组：

• **当前生产版：**已经上线的模型、prompt、工具、规则包和编排方式。
• **候选版：**条件允许时，只声明并改变一个变量。

如果多个组件必须一起改，就给整个组合命名，并承认实验只能识别这个组合的效果，不能区分每个组件的贡献。至少保留一小组不参与 prompt 和 harness 调优的用例。否则团队会针对评审集反复优化，把记住这些案例误当成产品能力提升。

至少计算并报告：

• 单次终态成功率；
• 每个用例三次全部成功的可靠性；
• 禁止状态出现率；
• 安全升级人工的正确率；
• 重试时的重复变更率；
• 工具调用、延迟和成本的中位数与尾部值；
• 注入部分故障后的恢复成功率。

不要用平均分掩盖禁止状态。候选版即使总成功率更高，只要出现一次重复退款，也可能比当前版本更不适合发布。必须在看结果之前定义硬阻塞项。

当前的 τ-bench 代码仓库还提供了一个很实用的版本管理警告：2026 年 7 月的评分更新指出，部分银行任务在修复前后的结果不能直接比较，除非严格锁定版本或重新评分。你的评估器、用例和预期状态都是产品依赖，也要像代码一样版本化。

先给系统状态打分，再用执行轨迹诊断

最强的评估方式通常是对权威系统做确定性断言。如果任务是“创建一笔经过批准的退款”，就查询退款和订阅记录；如果任务是“把案例送去复核”，就查询队列、负责人、原因和通知状态。

有些结果无法化成精确的数据库对比。例如，给客户的消息需要准确、完整、措辞谨慎，但可以存在多种正确写法。这时应分层评估：

1. 用确定性断言检查 ID、数量、状态、权限和禁止动作；
2. 用 schema 检查必要字段和证据引用；
3. 对无法用确定性规则编码的语义质量使用明确评分规则（rubric）；
4. 对高影响或不确定案例进行抽样人工复核。

如果使用 LLM 评审器（LLM judge），不要让它只根据 Agent 的最终回复推断整件事是否成功。应同时提供场景、已观察到的相关状态、明确评分规则和执行证据。再用人工审过的案例做校准，并长期保留评审器与人工意见不一致的样本。

Proxy State-Based Evaluation为无力建设完整确定性后端的团队提出了一个中间方案：从完整交互轨迹中推断结构化的“代理状态”，再根据明确的场景约束评分。论文在其测试环境中报告了较好的人工一致性和排名稳定性，但边界必须说清：代理状态仍然是推断结果。无法直接访问真实状态时，可以用它加速评估；一旦存在权威记录，就不能让推断覆盖事实。

结果评分完成后，再把执行轨迹用于诊断。标记最早的决定性偏差、最后一个确认正确的状态、偏离后第一次修改状态的动作，以及当时是否能用门禁阻止错误扩散。这样，一个失败用例会变成明确的修复计划，而不是一句模糊的“Agent 糊涂了”。

恢复能力也属于成功的一部分

一个 Agent 只有在所有依赖都健康时才能成功，就还没有准备好处理真实工作流。要主动注入故障：

• 工具已经成功修改状态，但在返回响应前超时；
• 规则服务返回旧版本；
• 附件上传成功，但案例更新失败；
• 下游系统停留在 pending 的时间超出预期；
• worker 在两个状态变更步骤之间重启；
• 用户迟迟没收到确认，于是重复发出同一请求。

每种故障都要预先定义安全终态。有时是对账后完成；有时是停止进一步变更，把案例连同完整证据交给人工并标记为未解决。如果系统仍然互相矛盾，那么“Agent 生成了一段道歉”不算恢复。

保存一份恢复证据包：原请求 ID、幂等键、尝试过的状态变更、服务商响应、对账查询、最终状态、通知记录和人工负责人。审稿人应该能用这份材料回答“什么发生了变化、什么没有变化、接下来必须做什么”，而不需要重放隐藏的思维链。

小团队经常会在这里发现最有价值的产品工作。更好的幂等设计、明确的处理中状态、对账任务和类型严格的工具响应，往往比再往 prompt 里塞一段说明更能提升可靠性。

在看到分数之前，先写下发布决定规则

使用一张简短明确的决策表。下面只是示例，实际阈值应根据产品风险调整，不能当成通用标准。

目的不是制造一张绿色成绩单，而是在团队被新模型或新 prompt 的新鲜感影响之前，就把取舍写明白。

灰度阶段同时限制用户范围和可执行动作。先从只读辅助或生成草稿开始，再开放低风险状态修改；只有证据逐步积累后，才允许更高影响的动作。人工门禁必须真的有人处理：一个把所有边界案例扔进无人队列的灰度，不会因为自动化比例低就变得安全。

NIST AI RMF Core要求记录测试集、指标和工具，在真实条件下测试，并持续跟踪部署后的风险。小团队不需要先建立一整套合规项目，也可以借用这种纪律。发布卡、用例版本、决策表和生产对账指标，已经构成一条五人团队也能维护的轻量证据链。

上线后继续观察相同的终态

离线用例必不可少，但不完整。生产环境会带来测试集没有覆盖的用户表达、状态组合、延迟、权限和依赖故障。

监控结果信号，而不只是 Agent 活动量：

• 必要外部状态仍在等待，却被标记为完成的案例；
• 已向用户确认完成，却没有对应服务商 ID；
• 同一意图或幂等键下出现重复状态变更；
• 流程被放弃，但没有进入任何有效终态；
• 升级人工后缺少负责人、原因或证据包；
• 工具返回含糊结果后发生自动重试；
• 按模型、prompt、工具 schema、规则、语言和客户群拆分后的表现漂移。

成功案例也要抽样，而不能只看报错。处于错误终态的静默失败未必会触发异常。根据业务影响，定期把权威系统状态与 Agent 的完成声明做对账。保留紧急开关，在停止状态变更功能时仍可继续提供只读或草稿能力。

生产环境出现漏网案例后，只有当它代表稳定的产品要求时，才应脱敏后加入测试集。不要把每个一次性异常都变成脆弱用例。记录这个用例为什么存在、对应哪次事故或用户需求，以及谁有权在未来将它移除。

这套协议适合什么，又不适合什么

终态发布门禁适合跨工具、跨规则、跨人员或会修改系统状态的多步 Agent。尤其适合“局部动作正确，但整体仍可能没办完”的流程，例如客服、财务运营、账号管理、用户入驻、采购、安全审核和内部审批。

如果只是生成一条可逆建议，且不会改变外部状态，这套方法的重要性会降低。写作助手生成草稿时，更需要事实准确性、可用性和文风评估，而不是数据库终态断言；完全不调用模型的确定性流程，应使用普通集成测试和属性测试；没有已知正确终点的研究型 Agent，可能更需要证据覆盖与认知不确定性评估，而不是单一预期终态。

这套协议也有明确限制：

• 设计用例可能遗漏真实用户变化。
• 干净的最终状态可能掩盖执行路径中的规则违规，所以仍需检查禁止动作。
• 结果正确，也可能带来有害或令人困惑的用户体验。
• LLM judge 和代理状态评估器都有自己的模型与 prompt 依赖。
• 三次重复能暴露一部分不稳定性，却不能估计低概率事故。
• 医疗基准的数字不能迁移到其他行业。
• 高影响工作流可能还需要法律、安全、隐私、临床或合规评审，技术门禁不能替代它们。

目标不是证明某个 Agent “绝对安全”，而是用一个有边界、可复现的陈述替换“演示成功了”：在这些版本、用例、预算和重复次数下，系统进入了这些可接受终态，而且没有出现这些禁止结果。

小团队可以在 48 小时内完成的改变

不要从购买评测平台或重建研究级 benchmark 开始。

第一天，选择一条至少包含一个状态变更动作的生产工作流。写出终态发布卡，并准备五个用例：正常路径、缺少事实、规则边界、部分变更、重复请求。对权威系统加入直接断言，并锁定当前模型、prompt、工具 schema、规则包和评估器版本。

第二天，从干净状态开始，让当前生产配置对每个用例独立运行三次。测基线时不要调优。记录终态成功、禁止状态、安全升级、恢复、成本，以及最早的决定性偏差。完成基线后，再决定下一轮只值得改变哪个变量。

下次发布评审时，先展示终态矩阵，再展示最漂亮的执行记录。如果团队无法复现初态、观察终态，或解释一次重试会发生什么，就让 Agent 继续停留在草稿、只读或人工批准模式。

两项新医疗基准带来的实际教训，不是 Agent 毫无价值，而是局部能力再亮眼，也可能与最终交付的可靠性同时存在巨大落差。围绕工作的真实终态设计产品，让执行轨迹解释“为什么到达或没到达”，而不是让它决定“是否已经到达”。

参考来源

1. CHI-Bench：端到端、长流程、规则密集型医疗工作流 Agent 基准
2. CHI-Bench 开源代码仓库
3. CHI-Bench 数据集
4. HealthAdminBench：医疗行政电脑操作型 Agent 评估
5. τ-bench：真实领域中的工具—Agent—用户交互基准
6. τ-bench / τ²-bench 开源代码仓库
7. SABER：小动作、大错误——保护 LLM Agent 的状态变更步骤
8. Proxy State-Based Evaluation：多轮工具调用 Agent 的可验证奖励
9. AppWorld：用于评估交互式编程 Agent 的可控应用世界
10. AppWorld 开源代码仓库
11. NIST AI 风险管理框架核心