自我验证循环
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 — 持续学习框架
Counterpoints & Gaps
- 自我验证会显著提高 agent 可靠性，但也会增加测试和环境维护成本
- 并不是所有任务都适合做完整 E2E 验证，很多团队仍需要在速度与真实性之间做分层取舍
- 如果外部上下文无法程序化访问，再好的验证循环也会被人类瓶颈卡住