Agent 的 7 种死法：从无限循环到自信胡说，一份失败模式图鉴

为什么需要一份「死法图鉴」

Agent 出问题时，新手的第一反应是「换个模型试试」或「再跑一次」。有时候管用，更多时候是烧钱。真相是：Agent 的失败模式高度可重复——同样的问题，在不同的项目、不同的模型上，一遍遍上演。能叫出死法的名字，你就赢了一半。

死法 1：无限循环——在同一个错误里转圈

症状：Agent 反复尝试同一种修复，每次都失败，每次都说「让我再试一次」。你的 token 像流水一样没了，错误纹丝不动。

根因：它没有「放弃」这个概念。Agent 的循环是：尝试→观察→调整，但调整空间被它自己的假设锁死了。

对策：设硬上限（比如 3 次失败就停），强制它换思路：「用完全不同的方法重做，不要修现在的方案」。人要在循环外当裁判。

死法 2：自信胡说——错得理直气壮

症状：交出来的方案看起来完整、注释齐全、逻辑自洽，但核心假设是错的。它不会说「我不确定」，只会说「完成了」。

根因：模型被训练成「给出答案」，而不是「承认无知」。不确定性不会自动表达出来。

对策：要求它先讲方案再写代码；对关键决策追问「你确定吗？有什么反例？」；核心逻辑必须有测试覆盖——测试是唯一不听它狡辩的裁判。

死法 3：上下文丢失——做到一半忘了开头

症状：长任务做到后半段，Agent 开始重复问已经确定的事，或者推翻自己早先的决定。

根因：上下文窗口是有限的，早期的关键信息被挤出去了。它不是「忘了」，是「看不见了」。

对策：任务切小，每个子任务独立可验证；关键决策写进文件（AGENTS.md 或决策日志），而不是只留在对话里；定期让它总结当前状态并写入文档。

死法 4：权限越界——手比脑子快

症状：没让你删，它删了；没让你改配置，它改了。今年 4 月的 PocketOS 事件就是极端案例：Agent 删了生产数据库和备份。

根因：默认权限太宽，且 Agent 不理解「这个操作不可逆」的重量。

对策：最小权限起步；删除、发布、对外发送三类操作必须人工确认；生产环境和开发环境物理隔离。

死法 5：过度工程——给你造了座大教堂

症状：你要一个简单的脚本，它给你搭了个微服务架构，带配置中心和插件系统。

根因：训练数据里「好代码」的范本大多是大型项目，Agent 分不清「演示」和「生产」的界限。

对策：在 prompt 里明确约束：「最小可用实现，不要预留扩展性」；要求它先给方案，你砍一刀再让它写。

死法 6：幻觉依赖——引用了不存在的东西

症状：import 了一个不存在的包，调用了文档里没有的 API，还写得有鼻子有眼。

根因：模型按概率生成， API 名字「听起来合理」就会被编出来。

对策：跑起来是唯一的真理——任何代码必须实际执行验证；让 Agent 自己跑测试，而不是只给你看代码。

死法 7：沉默腐烂——慢慢变差，没人发现

症状：没有报错，没有失败，但代码质量一周比一周差：重复代码变多、命名越来越随意、测试覆盖率悄悄下降。

根因：没有人 review，Agent 的「及格线」会自适应下调。

对策：定期（比如每周）让另一个 Agent 或你自己做一次代码评审；设硬性门禁：lint 必须过、覆盖率不能掉。

我们怎么看：把图鉴贴在墙上

这 7 种死法没有一种是模型升级能彻底解决的——它们是「自主系统」的固有属性，不是 bug。区别老手和新手的，不是用的模型多贵，而是多久能认出当前是哪种死法。

建议把这份图鉴存下来，下次 Agent 出问题时，先对号入座再动手。定位准了，对策往往一句话；定位错了，烧再多 token 也是交学费。