验证者子代理
与执行者隔离上下文、只根据产出物和评分标准判定是否达标的独立评估 Agent。
简介
验证者子代理是多智能体系统中的一种关键角色：它不负责生成方案或实现任务，而是对执行者的产出进行独立评估。本文素材强调，在 Fable 5 和自我改进代理系统中，验证者子代理往往胜过“让同一个模型自我批评”。原因不是模型不够努力，而是结构性偏差：一个模型评估自己刚刚生成的内容时，会受到自身推理轨迹、已有结论和“保持一致”的倾向影响；另一个隔离上下文的代理，只看到结果和标准，更像真正的审稿人、QA 或 code reviewer。
验证者子代理的价值在于把“我觉得差不多”变成“是否满足评分标准”。它可以检查测试是否通过、UI 截图是否符合目标、文档是否覆盖所有验收项、迁移是否保留行为一致性、Skill 是否在 eval suite 上退化。对自我改进系统而言，验证者不只是质量检查员，还是循环是否继续的裁判：未达标则把差距反馈给执行者，达标才允许停止。
关键信息
- 类型：Agent 角色 / 多智能体架构模式
- 核心职责：独立评估产出，不参与生成过程
- 关键原则：执行者和验证者分离；验证者只看产出与评分标准
- 适用场景：代码审查、测试验收、UI 视觉检查、eval 打分、文档完整性检查、Skill 回归验证
- 相关概念：自我改进代理系统、Fable 5、Loop Engineering、子智能体 Brief、文件交接协议
核心特性
隔离上下文，减少自我偏好
验证者子代理最重要的设计要求是上下文隔离。执行者可以拥有完整的任务推理、尝试记录和中间判断；验证者不应继承这些推理轨迹，而应只读取最终产出、任务目标和评分标准。
这种隔离让验证者不会因为“我知道当时为什么这么做”而替产出找理由。它的判断对象是证据，不是努力程度。这一点和人类工程流程中的 code review、QA、同行评审类似：自己不能判自己的卷子。
作为循环停止条件
在 Loop Engineering 和 /goal / Outcomes 这类循环里，验证者子代理通常承担停止条件判断：
- 执行者生成产出。
- 验证者按 rubric 或测试结果评分。
- 如果未达标，验证者输出具体差距与修复建议。
- 执行者根据反馈迭代。
- 验证者通过后，循环退出。
这使循环不再停在“处理得差不多了”，而是停在“独立验证通过”。
支持视觉验证
本文素材特别强调，UI、仪表盘、图表、设计还原度等任务不能只靠文本评估。验证者子代理可以读取截图、曲线图或视觉产物，对照目标描述、design tokens、历史截图和验收标准，判断布局、层级、颜色、数据趋势或异常是否符合要求。
视觉验证让 Agent 系统能够覆盖过去必须由人类肉眼确认的一部分验收工作，但前提是验证标准足够明确，且验证者能把差距结构化反馈给执行者。
可以用低成本模型承担
验证者不一定总要使用最强模型。本文的模型路由建议是：Fable 5 作为重型编排者，Haiku 4.5 可作为独立评分者或廉价分类器。验证任务如果标准清晰、输出结构化、证据充分，低成本模型就能承担大量重复评估。
这让自我改进系统在经济上可持续：昂贵模型负责少量高层判断，便宜验证者负责大量“是否通过”的独立裁决。
不同素材中的观点
- 2026-07-06-blocktempo-fable-5-self-improving-agent：Anthropic 工程团队的经验是，Fable 5 使用独立验证者子代理往往胜过自我批评。Parameter Golf 实验中，Fable 5 搭配验证者会探索更大的结构性假设空间，并能穿过一次负向中间结果继续调查；没有验证者时，同一模型更容易停在第一个“够好了”的结果。文章还把对抗式验证列为动态工作流中最适合自我改进系统的模式之一。
实用信息
验证者 prompt / brief 应包含什么
- 任务目标：最终产出要解决什么问题。
- 评分标准：可判定的通过/不通过条件。
- 输入材料：最终产出物、测试结果、截图、日志、diff 或文档。
- 禁止事项：不要根据执行者的解释放宽标准；不确定时列为风险或未通过。
- 输出格式：通过/未通过、关键证据、主要问题、建议下一步。
典型输出结构
STATUS: pass | fail | blocked
Evidence:
- ...
Issues:
1. ...
2. ...
Required fixes before pass:
- ...常见误区
- 让同一个执行者“顺便自检”，没有真正隔离。
- 验证标准过软，只写“检查是否好用”。
- 验证者能读到执行者的完整推理，导致替执行者找理由。
- 只有文本验证，没有运行测试、看截图、查日志或比对证据。
- 验证者发现问题后直接修复，模糊了“谁发现谁复验、谁实现谁修”的边界。