Agent 下一关：结果必须可复现

AI Agent 正在从“会不会做事”进入“能不能稳定做事”的阶段。

过去评价一个 Agent，常见问题是：它能不能把任务做完？代码能不能跑起来？报告能不能生成？网页能不能搭出来？但在真实生产环境里，这些问题还不够。一个 Agent 第一次成功，可能只是采样、上下文和工具状态共同作用下的偶然结果；当用户第二次提交同样的任务，或者团队把同一套流程交给另一个 Agent，它未必还能做出同样可靠的交付物。

Agent 结果可复现性，是指在输入、工具、环境和约束基本一致时，系统能够稳定地产出相同或等价结果，并保留足够的过程信息供验证和恢复。

这正是 IBM Research 最近在 Hugging Face 发布的文章《Your Agent Aced the Task. Will It Do It Again?》所指向的问题：Agent 不应该只因为“这次做对了”就被判定为可靠，它还需要证明自己能够再次做对。这个变化看似只是评测标准调整，实际上会影响 Agent 的架构、数据记录、测试方法和商业落地方式。

“做对一次”为什么远远不够

一次成功只能证明 Agent 找到过一条可行路径，不能证明这条路径稳定、可解释、可迁移。

传统软件通常是确定性系统。给定相同输入、相同代码和相同依赖版本，程序大概率会返回相同结果；即使程序包含随机性，也可以通过固定随机种子、锁定环境和保存输入来复现问题。Agent 则不同，它把大模型放进了一个持续观察和行动的循环中。

一个典型的 Agent 任务会经历以下过程：

1. 用户提出目标，系统识别任务边界、约束条件和交付格式。
2. Agent 重新组装上下文，把历史对话、文件、规则、工具说明和外部信息放在一起。
3. 模型决定下一步动作，例如读取文件、搜索资料、修改代码或调用数据库。
4. 工具执行动作并返回结果。
5. Agent 根据新的观察结果继续规划，必要时纠错、回滚或重新尝试。
6. 系统执行测试、审批和权限检查。
7. Agent 输出最终结果，或者把任务交给另一个执行单元继续处理。

这套循环中，每一步都可能引入变化。模型采样参数会改变，检索结果会更新，网页内容会变化，工具返回顺序可能不同，上下文压缩也可能丢失关键细节。即使用户输入完全相同，Agent 仍可能选择不同的工具、采取不同的步骤，最后得到不同质量的答案。

Agent Loop 是让模型根据工具反馈反复决策的控制循环，也是 Agent 不稳定性的主要来源之一。

聊天机器人回答错一次，用户通常可以重新提问；软件工程 Agent 修改错一个配置，却可能让构建失败、数据损坏或权限扩大。越是长链路、跨工具、跨时间的任务，越不能把“最终看起来不错”当成质量证明。

可复现不等于每个字都一样

Agent 的可复现性不应该被简单理解为每次输出完全相同。

对于代码修复任务，两个不同的补丁可能都能通过测试；对于数据分析任务，两份报告可能使用不同的图表，但结论和关键数字一致；对于网页设计任务，布局细节可以变化，只要满足组件结构、响应式要求和视觉规范。因此，Agent 评测更需要关注“等价结果”，而不是机械比较字符串。

可以把可复现性拆成四个层级：

| 层级 | 关注问题 | 典型判定方式 | | --- | --- | --- | | 结果可复现 | 最终交付物是否满足要求 | 单元测试、结构检查、规则校验 | | 行为可复现 | 是否选择了稳定且合理的执行路径 | 工具调用轨迹、步骤序列、状态转移 | | 环境可复现 | 相同任务是否运行在相同条件下 | 模型版本、依赖、数据快照、权限记录 | | 过程可复现 | 失败后能否定位并恢复 | 事件日志、检查点、工件、重放机制 |

结果等价性，是判断 Agent 是否稳定的核心，而不是要求每次生成完全相同的文本。

这一区分很重要。如果只比较最终文本，系统可能掩盖了危险行为：一个 Agent 生成的代码最终通过测试，但中间曾经读取了不应访问的文件；另一个 Agent 最后交付了正确报告，却在过程中调用了未经批准的外部工具。相反，如果只比较步骤轨迹，也可能惩罚那些找到更短、更高效路径的 Agent。

因此，成熟的评测应该同时检查最终结果和过程约束。最终结果回答“交付物对不对”，过程记录回答“它是怎么做到的”，权限与审计则回答“它有没有越界”。

随机性不是唯一问题，上下文才是隐形变量

很多团队一提到复现，第一反应是把 temperature 调低，甚至设置为零。但降低采样随机性只能解决一部分问题。

Agent 的有效输入，不只是用户消息，还包括动态上下文、工具状态、环境版本和历史执行记录。

同一句“修复这个项目里的测试失败”，可能对应完全不同的任务：

• 项目依赖已经被更新，昨天能通过的测试今天失败；
• Agent 上一轮已经修改了文件，但用户没有在对话中明确说明；
• 检索工具返回了新版文档，模型因此采用了不同的接口；
• 上下文窗口不足，系统压缩掉了最初的约束；
• 某个工具的返回结果包含当前时间、临时路径或随机排序；
• 多个 Agent 并发修改同一目录，导致观察到的文件状态不同。

这些变化都可能让“相同任务”变成不同任务。若系统只保存用户提示，却没有保存执行时的模型版本、系统指令、工具参数、文件快照和环境依赖，那么所谓复现通常只是重新运行一次，无法真正重建当时发生了什么。

这也是长程 Agent 最容易暴露问题的地方。任务持续十分钟时，人类可以回忆大致步骤；任务持续数小时甚至跨天时，如果没有检查点和工件记录，系统就很难判断 Agent 是从哪里开始偏离的。

Agent 需要一份“飞行记录黑匣子”

要让 Agent 可复现，第一步不是继续堆更大的模型，而是把执行过程变成可观察、可记录的状态机。

Agent 状态机，是把任务拆成可记录的状态、动作、观察结果和转移条件的执行框架。

至少应该记录以下信息：

• 任务输入：用户原始要求、结构化参数和最终验收标准；
• 模型信息：模型名称、版本、推理配置和系统提示；
• 上下文快照：实际发送给模型的内容，而不是事后猜测的拼接结果；
• 工具调用：工具名称、参数、返回值、耗时和错误信息；
• 文件工件：每次修改前后的差异、生成文件和版本标识；
• 环境信息：依赖版本、操作系统、运行容器和权限范围；
• 状态变化：规划、执行、等待、失败、重试、审批和完成；
• 检查点：哪些阶段已经完成，哪些结果可以安全恢复。

这套记录机制类似飞机的飞行数据记录器，也像软件工程里的持续集成日志。它不要求每次都人工阅读全部轨迹，但必须允许系统在失败后回答三个问题：Agent 当时看到了什么？它为什么选择这个动作？下一次运行怎样避免重复犯错？

对于长任务，检查点尤其关键。Agent 不应该把一次持续数小时的工作视为一个不可拆分的黑盒，而应该在“需求理解完成”“代码修改完成”“测试通过”“交付物生成”等阶段保存中间状态。这样一来，任务失败时可以从最近的安全状态继续，而不是从头重新生成一遍。

确定性验证，比让模型自我打分更可靠

Agent 评测的难点在于，最终结果往往不是简单的对错题。

让另一个大模型给结果打分，是目前常见的方法，但它存在评判漂移、偏好不一致和“看起来合理”的问题。模型可能因为措辞流畅而给出高分，也可能对同一份结果在不同时间做出不同评价。对于关键任务，仅靠模型评审很难构成稳定的质量门槛。

确定性验证，是使用规则、测试、类型检查或结构约束判断结果是否合格的方法。

例如：

• 代码任务检查测试是否通过、类型是否正确、静态扫描是否出现高风险问题；
• 数据任务检查字段数量、数值范围、聚合结果和来源是否匹配；
• 文档任务检查必填章节、链接格式、字数和引用完整性；
• 浏览器任务检查页面元素、跳转结果、表单状态和截图差异；
• 运维任务检查服务健康状态、配置差异和回滚结果。

确定性验证的优势是成本低、结果稳定，可以纳入持续集成，也方便在不同模型之间横向比较。它的局限同样明显：它更擅长判断“最终结果是否符合规则”，不一定能判断 Agent 是否采用了最佳策略，或者是否在边界条件下仍然可靠。

比较现实的做法是组合两类评测：用确定性测试守住硬门槛，用模型评审处理开放式质量，再用人工抽样检查风险较高的执行轨迹。三者分工比让一个评分器包打天下更稳妥。

从“成功率”转向“稳定成功率”

Agent 评测指标也需要升级。

传统的任务成功率只回答一次运行是否完成，例如 100 个任务中有 80 个最终通过，成功率就是 80%。但对于存在随机性的 Agent，这个数字可能不够。一个任务第一次通过、第二次失败，和连续十次都通过，不应该被视为同样可靠。

稳定成功率，是在同一任务或同一任务分布上重复运行后，持续达到验收标准的比例。

可以引入以下指标：

1. 重复通过率：同一输入运行多次，所有运行都通过的比例。
2. 结果一致性：多次运行得到的结构化结果或关键结论的一致程度。
3. 轨迹偏差：不同运行之间工具调用数量、顺序和关键决策的差异。
4. 恢复成功率：故意注入工具失败、网络中断或上下文压缩后，Agent 能否继续完成任务。
5. 首次通过率：不依赖人工干预和重复尝试时，任务第一次就通过的比例。
6. 单位任务成本：完成任务所需的模型调用次数、工具调用次数、时间和计算资源。

假设两个 Agent 的单次成功率都是 90%，甲在每次运行中都稳定使用相似路径，乙则有 10% 的概率进入完全不同的工具链路，那么甲更适合接入生产系统。对用户来说，稳定性不仅意味着“平均表现不错”，还意味着系统不会突然改变行为。

评测任务也不能全部来自精心整理的基准集。真实环境中会出现模糊需求、缺失文件、权限不足、工具超时和互相冲突的约束。一个只在干净环境里通过测试的 Agent，未必能处理真实世界里的脏数据和异常状态。

这会改变 Agent 的工程架构

可复现性不是评测团队最后加上的一个分数，而应该从系统设计开始。

首先，任务输入需要结构化。不要把所有约束都埋在一段自然语言里，可以把目标、禁止操作、验收标准、时间范围和输出格式拆开保存。这样做不是为了让 Agent 失去灵活性，而是为了让系统知道哪些内容必须保持不变。

其次，工具需要有稳定的接口和明确的副作用。读取工具、写入工具、删除工具和外部提交工具不应该拥有相同的权限。每个动作都应当返回结构化结果，并标明是否成功、是否改变了状态、是否可以安全重试。

再次，系统需要区分可重试动作和不可重试动作。查询、读取和纯计算通常可以重新执行；发送邮件、提交订单、修改线上配置则可能产生不可逆影响。Agent 在重试之前，必须知道上一次动作是否已经生效，否则重试可能造成重复提交。

最后，模型决策与系统控制要分层。模型负责提出下一步计划，系统负责检查权限、执行边界、停止条件和回滚策略。换句话说，模型可以决定“我想做什么”，但不应该单独决定“我是否有权做这件事”。

多 Agent 不会自动带来更高可靠性

多 Agent 协作经常被描述为提升复杂任务质量的方法，但更多角色也意味着更多不确定性。

一个 Agent 负责规划，另一个负责搜索，第三个负责执行，第四个负责审查，看起来像一支团队；但如果它们之间没有明确的输入输出契约，问题可能只是从一个模型内部转移到了多个模型之间。规划 Agent 误解需求，执行 Agent 忽略约束，审查 Agent 又只看最终文本，整个系统仍然可能稳定地产出错误结果。

多 Agent 系统，是由多个具有不同职责的决策或执行单元组成的协作系统，其可靠性取决于交接协议，而不只是单个模型能力。

要让多 Agent 真正可控，需要明确：

• 每个角色负责什么，不负责什么；
• 交接时传递哪些结构化字段；
• 哪些结果必须经过验证才能被下一个角色采用；
• 一个角色失败时由谁重试、降级或接管；
• 多个角色产生冲突时，谁拥有最终决策权；
• 整条链路如何保存统一的任务 ID 和工件版本。

否则，多 Agent 可能只是把一次不可复现的调用变成多次不可复现的调用，成本更高，排查更难。

开发者现在应该怎么做

对于正在搭建 Agent 的团队，最值得优先投入的不是再增加一个“自我反思”提示词，而是建立一套可重复的测试和记录流程。

可以从下面的最小闭环开始：

1. 为每个任务写出明确的验收标准，能自动检查的尽量自动检查。
2. 固定模型版本、工具版本和关键依赖，保存每次运行的环境信息。
3. 给任务分配唯一 ID，记录完整的输入、上下文、工具调用和输出工件。
4. 对同一任务重复运行多次，区分偶然成功和稳定成功。
5. 为网络失败、工具返回空值、权限不足和上下文截断设计故障注入测试。
6. 在高风险动作前设置审批点，在关键阶段保存可恢复检查点。
7. 用版本控制保存提示词、工作流和验证规则的变化。
8. 线上出现问题时，保留完整轨迹，并把失败样本加入回归测试集。

这套方法可能让 Agent 在早期看起来“没那么自动化”：它需要更多日志、检查和人工确认。但这是从演示系统走向生产系统必须付出的成本。没有验证和审计的自动化，本质上只是把风险隐藏得更深。

真正的竞争点，是可靠的任务交付

Agent 行业正在经历一个评价标准的转移：从“模型能不能完成任务”，转向“系统能不能持续交付可信结果”。

模型能力仍然重要。更强的模型通常拥有更好的规划、工具使用和错误修复能力。但模型能力解决的是上限问题，系统工程解决的是下限问题。一个能力很强、但每次执行轨迹都大幅漂移的 Agent，可能不如一个能力稍弱、却能稳定通过验收并且方便恢复的 Agent。

IBM Research 这篇文章的价值，正在于把一个经常被演示视频掩盖的问题摆到台面上：一次成功不是终点，而是可重复验证的起点。未来的 Agent 基准不会只展示“最好的那次运行”，还会关注重复执行、异常恢复、长程记忆、工具状态和交付成本。

可复现性不是 Agent 的附加功能，而是它从聊天工具变成生产系统的入场券。

如果一个 Agent 不能解释自己看到了什么、做过什么、为什么这样做，也不能在相同条件下稳定重现结果，那么它更像一次性演示，而不是可以被团队信任的执行系统。反过来，当任务状态、工具行为、验证规则和恢复机制都被纳入设计，Agent 才真正具备进入软件开发、数据分析、运维和企业流程的基础。

下一阶段的 Agent 竞赛，拼的不会只是“谁更聪明”，还会是“谁更稳定、谁更容易调试、谁更能被验证”。