生产里的 Agent 大多数时间不是在推理，是在处理上一步的失败。工具超时、参数报错、模型走偏——这三件事占了运行日志的大半。我不确定有多少团队认真想过：这三种错误的修法完全不一样。参数非法，把报错回喂给模型往往就好了；工具超时，重试是合理的、便宜的；模型走偏，请直接中止。最差的做法是无脑重试——那是把成本、延迟、以及你未来的失眠，一起乘个三。
先承认：Agent 的日常是擦屁股，不是推理
这周 HackNews 上有个热帖是 Hugging Face 发布的前沿实验室 Agent 入侵事件时间线，讲一个 agent 在关键几步判断失控后，一路把自己的权限用完才被拦住。我读完最大的感受不是“AI 多危险”，而是：整个事件是几十个小错误累积出来的。每一个单看，都是“再试一次就好”的类型。
另一个佐证是 Handbook.md：长政策文档不能可靠地约束 agent，实验结论说得很直白——你写一百页运行手册，agent 该跑偏还是跑偏。规则在推理模型那里是一种“参考”，不是“约束”。
这就是现实。我们花大力气让 agent 变得更聪明，但生产环境的稳定性，靠的是错误处理，不是聪明。
三类错误，三种对策
我现在的习惯，是把 agent 的错误分成三类，按类型给对策。
工具超时。网络抖动、上游服务慢、PDF 解析器卡住。这类错误没有语义，就是“这次没跑完”。重试合理，配上退避就行。注意：就退一次，最多三次。每一次重试，延迟和成本都按倍数叠上去。
参数非法。调 API 传了个 schema 不认识的字段。这类错误有信息——报错文本里写着错在哪。把报错原样回喂给模型，让它在下一轮自己修。这不是重试，是给模型新信息。大部分模型修得挺好，这属于临场手滑，不是能力问题。
模型走偏。这里最坑。模型开始幻觉前置结果、把目标自己改了、在循环里越转越自信。遇到这种，直接中止，不要重试，不要回喂报错，不要想“也许加个 system prompt 就好了”。——重试模型走偏，等于把已经错的一次操作再精化一遍再跑一次。成本延迟都乘个三，错误概率还是接近一。
无脑重试是最贵的 bug
PostHog 这周写了篇 你到底能委派给 agent 多少事，里面讲 agent 能在多大范围内自主跑，取决于你多敢让它失败。有个细节我记得很清楚：他们让 agent 干活，最要紧的不是让 agent 自己成功，是让每个失败都早暴露、不出错地暴露、可回滚地暴露。
这让我想起 Uncle Bob 那条推：[我的策略是不