无人值守跑了几个月：编码 agent 的七种隐性失败模式

Fragrant_Yoghurt1135 · reddit · 2026-09-05

作者长期以 planner + worker 模式无人值守运行编码 agent（planner 永不写代码，每个工人独占 git worktree），总结出短交互会话中根本暴露不出的失败模式：

技术上为真的乐观自报：agent 称"构建通过、lint 干净、测试全绿"且每句都真，但功能用户根本触达不了——构建≠集成，未合并分支上的工作不算完成。只验证用户实际路径上的运行工件，不看构建日志。
自我验证无价值：72 个修复中 21 个被人工 QA 打回，因为验证 agent 给自己的工作放行。解法是结构性的：写改动的 agent 不得验证，由不知情的新 agent 跑两次 A/B（修复前必须失败、修复后必须通过）。
看起来真实的假测试：四种一撤销修复仍保持绿的测试模式（测试内重实现逻辑、断言"可见"而可见恰是 bug、测 helper 而 bug 在别的层、断言源字符串而非行为）。门禁是：他人撤销修复并确认测试变红。
缺失声明几乎都是工具 bug：旧引用、错误工作目录、未认证会话、minify 后的 bundle 都读作"未找到"。现在要求同一运行中做阳性对照；grep 部署 bundle 必然假阴性。
"已知失败"列表是污染源：清单上的失败不再有人读，刚弄坏的测试与本来就坏的无法区分。规则：没有在 base 分支跑红过的失败不得称"预先存在"。
沉默≠无发现：某晚 6/10 工人未回报但工作都在磁盘上；退出码双向说谎，只信 report 文件。
版本号不是内容标识：本地构建包报告的版本未必包含其内容，按版本信任会误报别人的包有 bug。

元教训：散文规则恰恰在最需要时被绕过，能存活的规则都变成了 hook 或脚本门禁（如 pre-commit 强制第二 agent 审查 staged diff、外部 watchdog 等）。

「编程与Agent」频道最新