对用于重试智能体错误最终行为的评分规则机制进行了测试。

Anthropic的Claude Outcomes功能整合了一个许多团队都会自行搭建的循环机制：一个工作代理负责起草答案，另一个组件根据评分标准对其进行评估，如果未达到要求，则该代理需要再次尝试。这一机制的理念简单到无需依赖托管产品即可试验，因此人们在受控环境中重新构建了一个简化版本，其中包含代理输出、评分标准评估以及仅一次重试机会。

问题

该测试只涉及一个问题：当代理需要做出结构化决策时，通过评分标准控制的重试机制能否减少最终错误操作的数量？

在此情况下，最终采取的行动至关重要，因为许多实际客服失败与文本质量并无关联。回复可能写得很好，JSON数据也能正常解析，但选定的行动仍可能是错误的，从而导致运营失误。比如客服本应选择NO_ACTION，却返回了DENY——即便其给出的理由听起来很谨慎，也无法弥补这一错误。

实验设置

本次测试使用了30个合成客服案例以及一个模型gpt-5.4-mini。这样的样本显然无法作为基准测试，其价值在于展示失败的表现形式：哪些错误被系统修正了，哪些被忽略了，以及问题产生的规律所在。

每个案例都包含一个简短的客户场景、相关政策以及一份固定的允许采取的最终行动列表：

APPROVE
DENY
ASK_CLARIFYING_QUESTION
ESCALATE
NO_ACTION

有两种循环机制可供比较。在基准模式下，任务会直接交给智能体，其返回的任何操作都会被记录下来。而在带审核机制的版本中，评分员会先审查最初的回答，如果未通过则会让智能体再次尝试，且这次需要依据之前未满足的标准来操作。

下图是结果驱动型智能体工作流程的简明参考图，展示了在最终决策确定之前，如何通过评分规则来检验拟采取的操作是否符合政策规范。

该政策规范被刻意设计得较为严格，包括有限的行动选项、明确的政策约束，以及仅在评分检查失败时允许一次重试的机会。

Baseline:
case -> agent -> final action

Gated:
case -> agent -> rubric judge
if failed -> retry once
retry answer -> final action

这些案例虽然是模拟的，但遵循了常见的生产环境约束：

我们使用了真实的大型语言模型提供商，而非确定性模拟器，因为有趣的是模型在首次回答被评估和修改后的实际表现。

不持有答案钥匙的评判者

如果评判者事先就知道答案，那就失去了意义。每个案例都包含一个expected_action值，但该值仅在运行结束后用于计算离线指标，评判者永远无法得知。评判者所看到的只是智能体选择的动作，然后它会根据既定的策略约束来检查该动作是否合规。

想象一下，在支付处理流程中存在未处理的拒付申请的退款请求。NO_ACTION可能是合适的处理结果，因为支付模块负责该问题的解决，客服不应对此作出裁决。一个简单的判断方式就是检查模型是否选择了NO_ACTION，这实际上等同于核对标准答案。这种方式适用于离线评分，但并非真正的决策关卡。

真正的决策关卡会提出不同的问题：在给出DENY结果的情况下，是否因为案件属于其他处理流程，就错误地将客服视为决策主体？

在运行时，通常不需要隐藏的标准答案。真正需要的是检查所提议的操作是否违反了明确的规则。此处的规则很简单：选择一项最终操作，且不能与案件的策略限制相冲突。

发生了什么

在30个案例的单次处理中，基准智能体有6次最终决策出错。加入审核机制并允许一次重试后，仅剩下2次错误。

改进效果确实存在，但仅凭数字容易产生误解。该循环并未让智能体获得任何新的通用技能，它仅在审核机制能够指出所选动作与政策条款之间存在具体冲突时才有效，而这些失败案例恰恰展示了这类冲突。

该机制解决了什么问题

该循环修复了基准智能体6次错误中的4次。大多数修正都发生在基准智能体过快拒绝案例中。政策并未要求立即批准，但也不强制拒绝，更好的做法是请求进一步说明或等待其他工作流程处理。

有一项更改账户电子邮件的请求。该请求来自一台新设备，尚未完成多因素认证，且请求人知道账单对应的邮政编码。根据政策，在提供支持之前必须完成多因素认证或其他经认可的账户所有权验证。系统默认的响应是DENY，尽管预期应该是ASK_CLARIFYING_QUESTION。既然还有经认可的验证方式可用，现在就拒绝请求还为时过早，因此应该先询问相关问题。审核人员认为过早拒绝是不对的，在重新处理时模型改为了ASK_CLARIFYING_QUESTION。

另一起已处理的案例涉及更换设备。有客户要求客服重新发送一台设备，但当天早上已经提交了RMA申请，正在等待仓库扫描。系统默认判定为DENY，而预期操作应为NO_ACTION。此判定有误，因为该客户并不符合被拒条件，且更换流程早已启动，客服不应再开启重复的RMA申请。重新处理后将判定更正为NO_ACTION。

这两个例子都体现了该规则的实用价值。它并未让模型整体变得更智能，只是强制解决了所选操作与政策规定之间的特定矛盾。

它无法解决的难题

其余两次失败所反映的问题比总体评分更为严重。这两次都属于现有工作流程中的案例，预期操作应为NO_ACTION，但即使重新尝试后，最终判定结果仍为DENY。

在第一例中，退款请求涉及支付工作流程中的未处理退费申请。根据政策，在退费申请处于活跃状态时，支持团队不得办理退款，因为支付部门负责处理此类问题。在第二例中，买家希望在欺诈审查进行期间手动释放货物，但政策禁止支持团队在该状态下释放货物。在这两例中，审核人员都发现了问题并给出了失败判定，而重新尝试后依然采取了错误的操作。

这改变了在生产环境中评估该模式的方式。检测机制可以发现某个操作违反了规则，但仅仅发现问题并不足以解决问题。假设模型无法区分“拒绝请求”与“因其他工作流已决定而不予处理”，那么即使被标记为异常的答案也可能保持不变。听起来安全并不意味着该操作就是正确的，而DENY虽然看似保守，但在代理没有处理该事项的权限时依然是错误的。

何时可以信任它

这里的成功依赖于可验证的结果。代理从有限的选项中选择，策略限制有明确规定，审核人员可以将所选操作与具体的规则进行对比。在这种情境下，基于结果触发重试能赢得更多信任：

当结果具有主观性时，则需要更加谨慎：

不应将其视为通用的可靠性层。仅应在错误操作带来的代价足以抵消额外模型调用的成本，且期望结果能够通过合约来明确规定的场景中使用它。

值得进行的生产环境调整

其中一项调整最为重要：将反复出现的非修复行为视为对设计的反馈。当智能体持续混淆 DENY 和 NO_ACTION 时，应细化动作定义、补充示例或重新设计工作流合约。然而，再次尝试往往无法弥补理解上的缺陷。

请将运行时校验与离线评分分开处理。在运行时，判定器会执行各种约束条件，而离线评估则根据标记的期望值来衡量最终动作。将两者混为一谈会低估系统的性能。此外，记录每次重试的详细信息也很重要，包括最初的动作、失败的标准、修正后的动作以及最终判定结果，因为修复与未修复情况的组合往往比整体准确率更能反映系统的真实表现。

核心要点

当“完成”状态能够以契约形式明确界定时，基于结果的校验机制才会发挥作用。此处的契约很简单：选择一个不违反策略约束的最终动作。在这种条件下，该校验机制将30个最终动作中的错误选项从6个减少到了2个。

那些遗留的失败案例正是生产环境需要重点关注的。系统已经检测到问题，但重新尝试后依然产生了错误的操作结果。因此，关键问题不仅在于系统是否能够对输出结果进行评分，更在于整个流程能否将这种评分转化为正确的决策。在让任何基于结果的循环涉及实际工作流之前，都必须先获得相关证据。

延伸阅读

Anthropic关于定义结果的API文档，以及其关于能够自我验证工作的智能体的指南，都涵盖了本实验所模拟的托管功能。