Critic 如何判断 Executor 输出合格，不通过后如何处理？

核心回答

Critic 应依据事先定义的验收标准和可核对的证据判断 Executor 是否合格。可以把验证分成程序检查、证据检查和语义评审三层；不通过时返回具体失败项，再由调度逻辑选择修复、补信息、重规划或退出，并限制重试次数与预算。

这里的 Critic 是工作流中的评审角色，其职责是审查执行结果；强化学习里估计状态价值的 Critic 是另一种概念。

怎样定义“合格”

先把任务要求变成检查项，而不是让 Critic 自由给一个总分：

1. 结构与硬约束。 必填字段、类型、枚举、文件是否存在、工具是否真正成功、结果是否越权等，优先由程序验证。代码任务可以运行测试，数据库任务可以核对查询结果。
2. 事实与证据。 输出中的关键结论必须能追溯到工具结果、原始文档或视频片段。证据是否存在、是否真的支持结论、有没有遗漏或矛盾，需要分开检查。把 Executor 自己写的“已验证”当作依据会形成循环证明。
3. 任务完成与表达质量。 是否回答了用户问题、覆盖了必要子任务、保留不确定性，语言是否清晰。开放式语义项可以交给模型评审，但要给出明确 rubric、正反例和判定理由。

例如视频分析任务，Executor 输出“某人在会议中同意延期”。Critic 应定位对应片段，核对时间戳、说话人和实际语义；仅有一条格式正确的摘要，不能证明事实成立。ASR、OCR 和画面证据冲突时，应标记待核查，而不是用流畅程度决定通过。

评审结果可以包含 pass、失败类别、证据位置、具体违反的规则和建议动作。硬约束失败时，不能被其他维度的高分平均掉；证据不足也应允许“无法判断”，不要强行二选一。

不通过后如何处理

• 局部可修复： 将失败字段和原因交回 Executor，只修改相关部分，并重新验证受影响内容。
• 缺证据或信息： 补检索、重新读取工具结果；确实需要用户决定时进入澄清分支。
• 计划本身有问题： 交回 Planner 调整步骤或工具，再从合适的检查点执行。
• 工具瞬时故障： 按错误类型做有限重试；确定性参数错误不能原样重试。
• 达到次数、时间或费用上限： 返回当前可确认的结果和未完成原因，进入约定的备用流程或人工处理。

调度器维护轮次、预算与状态，Critic 负责提供判定依据。外部写入、发送和扣费等动作还要有幂等标识与执行记录，避免质量修复时重复产生副作用。不能每次失败都把整条流程从头重跑。

Critic 自己如何验收

用人工复核的样本校准，分别统计“错误结果被放行”和“正确结果被拒绝”，并检查错误类型、证据引用和不同轮次的表现。保留 Executor 输出、Critic 判定、修改过程与最终结果，观察修复是否提高真实任务完成率，而非只提高自评分。

同一模型可以承担执行和评审，但容易共享盲点。可以通过隔离评审上下文、隐藏答案来源、采用独立证据和程序 oracle 减少偏差；换一个模型也仍然需要校准。最终应以可验证结果和实际业务验收为准，不能把“Critic 说通过”当作正确性的充分证明。

对应教程

参考资料