自我验证循环
Agent 工作的质量受限于其反馈循环的质量。如果 agent 无法在其核心领域观察其行为的后果，它就会去优化那些可能与实际正确性无关的代理指标。
核心失败模式
Agent 在没有进行正确的端到端验证的情况下就将功能标记为已完成。
Agent 修改代码 → 运行单元测试 → 看到通过 → 标记为完成。但用户通过浏览器测试时，功能实际上并不起作用。
单元测试成功 ≠ 端到端功能正常。
解决方案
浏览器自动化（Puppeteer MCP）
让 agent 访问 Puppeteer MCP 服务器，能够真正导航应用、点击按钮、填写表单、验证功能是否端到端运行。
Lint 集成（harness-engineering/aci 中的文件编辑器）
每次编辑后自动运行 Linter，语法错误在引入瞬间被捕获。
Reflection 循环（双 Agent）
Generator 生成 → Critic 审查 → 有问题则传回 Generator → 循环直到 Critic 没有修改建议。 终止条件：Critic 不返回消息 = 通过。
Evaluator（Anthropic 三角色架构）
独立的 Evaluator 与 Generator 之间没有共享内部状态，防止自评失真。见 harness-engineering/anthropic-long-running。
2026-04-15 补充：长跑 agent 的三个前提
来自 Simon Last 和 Eric Zakariasson 的补充，把“自我验证”从抽象原则压缩成了三个更可执行的问题：
- agent 能不能启动你的环境
- agent 能不能访问完成任务所需的外部上下文
- agent 能不能端到端验证自己的改动
Simon Last 的观察
Simon Last 总结自己让 coding agent 连跑 13 天的经验时，把最关键条件写得很明确：如果 agent 不能 end-to-end verify everything itself，它就无法真正长时间自治。
重点不只是“有测试”，而是：
- 测试层必须足够快，agent 才愿意反复 loop
- 验证必须尽量贴近真实结果，而不是只跑最便宜的代理指标
- 人工 review 应该是兜底，而不是主验证路径
Eric Zakariasson 的三问
Eric 用三个问题检查 codebase 是否适合 agent 工作：
- 是否能一条命令启动环境
- 是否能拿到和意图相关的外部上下文
- 是否能验证改动是否真的生效
这等于给 Agent-Computer Interface、Harness 即记忆 和本页内容之间补了一层非常实用的落地检查表。
Agent 自我改进的六条路
- 输出自审（Reflection） — 双 Agent 循环，当次做好，但无跨 session 学习
- 持久记忆 — 跨 session 的记忆持久化（Letta Code、Agent Zero、Hermes Agent）
- 动态工具生成 — 遇到没有现成工具的任务时，当场写代码创建新工具并存入记忆
- 技能提炼 — 完成复杂任务后，自动把操作步骤抽象成 Skill 文档
- 定期回顾（nudging） — 哪怕用户没发起对话，agent 也会自己复盘经验
- 自我修改代码 — 更激进的自我改进形式
关联
- harness-engineering/overview — Harness Engineering 总览
- harness-engineering/aci — ACI 中的 Lint 集成
- harness-engineering/anthropic-long-running — Evaluator 架构
- harness-engineering/continual-learning — 持续学习框架
长时间运行中的自我验证（2026-05-02）
来源：Addy Osmani — Long-running Agents
长时间运行 agent 的三大核心墙之一是缺乏自我验证。模型在评分自己工作时系统性偏正：被问"完成了吗？"时，回答"是"的频率高于实际完成度。
Anthropic 的 test ratchet：
"it is unacceptable to remove or edit tests because this could lead to missing or buggy functionality"
这是防止 agent 删除失败测试来"通过"的硬约束。
Cursor 的发现：GPT 模型比 Opus 更适合 extended autonomous work，因为 Opus 倾向于提前停止和走捷径。同一任务、不同角色、不同模型 —— 模型-角色匹配正在成为设计表面。
实践原则：
- 在 agent 启动前写下 done-condition（最高杠杆动作）
- 将 evaluator 与 generator 分离 —— 即使使用同一模型的不同 prompt
- 投资 session log，而不仅是 prompt
Verifier Sub-Agent vs Self-Critique（2026-06-11）
来源：RLanceMartin — Designing loops with Fable 5
Anthropic 工程师在 Parameter Golf 和 Continual Learning Bench 实验中发现：verifier sub-agent 在独立上下文窗口中评分，系统性优于模型的 self-critique。
具体表现：
- Fable 5 在 Parameter Golf 中的改进幅度约为 Opus 4.7 的 6 倍，关键差异在于 Fable 5 配合 Outcomes grader（verifier sub-agent）使用
- 模型在评分自己工作时系统性偏正（self-preferential bias）：被问"完成了吗？"时回答"是"的频率高于实际完成度
- CMA 的 Outcomes 功能 spawn 独立 grader sub-agent，在独立上下文窗口中进行评分，避免 self-critique 的系统性偏差
与 Dynamic Workflows 的关联：
- Dynamic Workflows 的 Adversarial verification 模式（独立 verifier agent 挑战输出）与此发现一致
- 两者共同指向：验证必须与生成分离，即使使用同一模型的不同 prompt 或不同实例
生产实践：
- 对于 goal/rubric 循环，将评分标准写成可检查的文件（如九项标准清单），由独立 agent 逐项确认
- 在长时间运行的优化任务中，verifier sub-agent 可以在主 agent 继续探索的同时，对已完成的工作进行并行验证
Counterpoints & Gaps
- 自我验证会显著提高 agent 可靠性，但也会增加测试和环境维护成本
- 并不是所有任务都适合做完整 E2E 验证，很多团队仍需要在速度与真实性之间做分层取舍
- 如果外部上下文无法程序化访问，再好的验证循环也会被人类瓶颈卡住
Codex 自动 /review 模式：从生成到验证的闭环（2026-05-12）
steipete 提出一个极端简洁但高杠杆的改进：Codex 在完成任务后应自动进入 /review 模式，循环自检直到不再发现错误。这一提案在 X 获得 4,200+ 点赞，说明资深开发者对生成后质量闭环的需求已成为共识。
关键特征：
- 零人工介入：不需要用户手动触发 review，agent 自己知道什么时候该检查
- 循环终止条件：不是固定轮数，而是“不再发现 booboos”——即验证结果收敛
- 与 clawsweeper 的关联：steipete 此前开源了 clawsweeper，用 50 个 Codex 并行关闭 4000 个 issue。/review 自动循环是同一理念在单任务层面的自然延伸
这一模式将自我验证从“需要人类设计的 harness 组件”推向“agent 原生行为”——agent 默认就会检查自己的工作，正如人类工程师在提交前会 self-review。
视觉验证循环：Zach Lloyd 的 Mermaid → SVG 案例（2026-05-13）
Warp CEO Zach Lloyd 用 agent 在业余时间构建了纯 Rust 的 Mermaid → SVG 渲染器。项目在传统开发模式下需要数月，但他通过构建视觉验证循环让 agent 自主迭代达到生产质量。
核心方法：
- 生成 canonical renderings：用参考实现（mermaid.js）生成大量图表的标准渲染图作为基准
- 视觉验证循环：
- Agent 用自有代码重新生成所有图表
- 启动 N 个 Oz cloud agents，用计算机视觉对比自有渲染与 canonical 渲染
- 按 diagram 类型分片并行处理（约 20 种类型）
- Agents 发现视觉差异后诊断原因并修复，各在独立分支工作
- Cloud agents 完成后合并回主分支
- 重复直到视觉差异消失
- 迭代数据：每轮约 1 小时，共 10-15 轮达到高质量
关键洞察：给 agent 清晰的 success criteria（此处是"像素级匹配 canonical rendering"），agent 就能自主进行 hill climbing。这比人工 review 更快，比单元测试更贴近真实正确性。
这与 Model-Harness-Fit 形成呼应：模型选择取决于 harness 能否提供可验证的反馈信号。
Anthropic 生产验证栈：所有 Agent 都会撒谎（2026-06-07）
Anthropic 工程师 James Brady 在生产环境中观察到：每个生产环境中的智能体都会撒谎，区别在于能否及时发现。Claude Code 团队为此构建了完整的验证栈，在用户看到输出之前检测并纠正 agent 的谎言。
核心模式：
- 将验证视为与生成同等重要的基础设施，而非可选附加组件
- 在 agent 输出到达用户前设置多层校验关卡
- 验证策略需随任务类型调整——代码有编译器和测试，文本有事实核查，设计有视觉对比
这与 "Codex 自动 /review" 提案和 steipete 的 codex-review skill 形成生产验证的三层光谱：
- 平台层（Anthropic 内置验证栈）——用户无感知的自动校验
- 工作流层（/review 自动循环）——agent 完成任务后的自检
- 技能层（codex-review skill）——用户显式安装的验证增强
Anthropic 验证栈技术细节（2026-06-08）
James Brady 在演讲中进一步披露了验证栈的具体组件：
- 自动事实核查：对 agent 生成的声明进行交叉验证
- 会话重放：重放 agent 的执行轨迹以发现偏离预期的行为
- 置信度评分：为 agent 输出分配置信分数，低置信度内容触发人工审查
这些组件与此前记录的 "test ratchet" 和 "evaluator 架构" 形成互补：test ratchet 防止 agent 删除失败测试，evaluator 架构分离生成与评判角色，而 Brady 的验证栈则在输出到达用户前增加了一层自动筛查。三层机制共同构成从"生成可运行代码"到"生成可信输出"的完整验证 pipeline。
Steipete 的 codex-review skill：生产级自检闭环（2026-05-14）
Steipete 将 "Codex 自动 /review" 理念落地为可安装 skill：
实现机制：
- 创建 skill 自动循环执行
codex /review - 终止条件：review 不再发现任何 bug（booboos）
- 系统架构问题仍由人脑作为 master model 解决
关键限制：
- 自动化 review 无法修复系统架构层面的问题
- 代码层面 bug 可由 agent 自修复，架构层面问题需人工决策
开源地址：steipete/agent-scripts 仓库中的 skills/codex-review/SKILL.md
这代表 agentic coding 从"生成"走向"生成+验证"的实用模式。与 2026-05-12 的"自动进入 /review 模式"提案相比，此 skill 是可立即部署的具体实现，而非平台功能请求。