智能体验收规则错了，怎样完成一次真正的纠正

Google 于 2026 年 10 月 28 日发布的 Agents CLI 指南，建议分别管理评估输入与预期结果的版本。这项建议来自 Google，而非本文首创。原文

我们追问的是发现另一个问题之后该怎么办：如果验收规则本身错了呢？团队可能一直在奖励智能体完成某种业务不应允许的动作。修正规则，可以让昨天的分数下降，却不会改变昨天的行为；它还可能暴露新分数本身无法解决的后续问题。

Open Market Notes 以一个假设性的设备维修流程讨论这个问题。以下是独立的操作设计建议，不是实测实验，也不是对 Google 已部署系统的描述。

一次纠正，面对两类读者

假设一个助手负责准备设备维修工单。最初的测试把“工单完整”视为成功，后来业务人员意识到，涉及特定受限区域的工作必须先获得批准。及时完成这类工单的智能体，可能通过了旧测试，却越过了业务原本希望保留的操作边界。

第一类读者是决定下一个版本的工程团队；第二类是对已经处理的工作负责的业务负责人。前者需要一条面向未来的验收规则，后者需要知道过去的输出有没有越界。如果把两件事都当成修改提示词的任务，第二个问题就可能始终没有答案。

这一发现并不等于真实事故已经发生。准备好的工单也许从未提交，也许被人工驳回，或者它本来只是没有外部影响的模拟测试。首先应查明证据支持哪一种状态，而不是把评估失败直接写成已经造成业务损害的指控。

保留历史结果，补上新的判断

CLI 文档允许不重新运行智能体，直接对保存的轨迹再次评分。评估文档

我们建议的纠正记录，应保留原结果及其当时的含义，附上修订后的判断，并说明修改理由。不要覆盖过去，仿佛正确规则一直存在。读者应看得出：旧的“通过”，可以准确反映旧测试的结果，却不足以证明相关行为在业务上合格。

这个区分与责任有关。开发者不一定忽略了书面要求，要求可能原本就不存在或含糊不清。反过来，测试遗漏一项检查，也不代表有权忽视已经明确的业务限制。记录应区分产品要求什么、测试实际检查什么，以及操作者做了什么。仅凭一个标签改变，不能推断责任归属。

只问记录能够回答的反事实问题

有效的衔接有两部分。重新判断保存的交互，回答的是：新规则是否接受这段已经发生的行为？用修改后的智能体重放案例，回答的是另一个问题：在重建条件下，拟议修复能否产生合格的下一步动作？

这两者不能互换。新版智能体请求批准，不能证明旧版当时也问过；也不能证明批准最终一定会获得。如果历史轨迹只留下最终工单摘要，缺少权限记录可能意味着没有检查，也可能只是日志漏记。在其他有权使用的记录解决疑问之前，应把这种差异标为未确定。

因此，这个例子中的修复目标应受到约束：在审批边界停下，并指出缺少的授权。不能拿想象中的批准结果为它评分。案例可以检查一个系统能够控制的下一步，而无需虚构后续业务决定。

重建本身也要说明边界。现在的设备记录，可能包含原始请求之后才发生的修改。用它重放有助于测试今天的流程，却没有复原旧智能体当时掌握的信息。如果历史输入无法取得，就明确说明，让追溯结论保持较窄范围，而不是用听起来合理的故事补空白。

技术修复，不等于业务问题结案

更好的提示词可以改变未来行为，却无法撤回已经提交的工单、通知受影响的主管，或者确定维修是否已经开始。这些动作属于经过授权的业务处理程序，而不是评估脚本可以自行决定的事情。

对于假设中的维修团队，纠正记录可以关联一项独立处理状态：没有发生外部动作；有权审核的人确认工单适当；工单已经撤回；或状态仍未解决。这些是建议使用的分类，不是实际发生的事件。目的在于防止把“下一版已经修复”误认为“历史后果已经处理完毕”。

另一个风险同样存在：过度追溯可能消耗本该用于紧急修复的资源。适度的做法，是优先限定新发现的限制、相关时间窗口和可观察的外部动作，不默认每个历史失败都需要同等调查。应由明确的负责人解释这个范围为何合理，以及哪些不确定性仍被保留。

先定义何谓完成，再追求更高分

在这项建议流程里，完成纠正不只是通过修订后的测试。业务负责人认可正确规则，工程团队证明系统能够执行获准的下一步，而有权处理历史案例的人则解决问题，或明确继续承担未结事项。每一种确认回答的都是不同问题。

这种设计有局限。它需要对业务记录设置访问权限、制定合理的保存政策，并投入时间复核含糊证据。工具或模型变化之后，精确重放也可能根本做不到。这些限制应促使团队限定结论，而不是把近似重建说成确定事实。

实际价值在于，组织可以更清楚地区分改善系统与纠正过去对系统的判断。评分规则可以立即修好；要恢复信任，还必须说明纠正确认了什么、哪些内容仍不知道，以及谁负责尚未完成的工作。