给 AI Agent 加上“同事”能解决死循环报错吗

给公司内部推 AI Agent 落地的时候，最让人血压升高的情况就是看到它在日志里陷入死循环：调用一个接口报错 422，它立刻重试，还是 422，接着又重试，试了三遍之后它突然跟你道歉说对不起没办成。这种场景在各种 Agent 框架里太常见了。

很多人习惯性地觉得是模型不够聪明，但其实是它面对的信息太匮乏。一个 422 validation_error 字符串，模型根本没法判断这是因为接口临时抽风（重试能成），还是因为上周版本更新把字段名给改了（重试一万次也没用）。它选择重试，纯粹是因为它读过的代码库里绝大多数处理逻辑都是这么写的。

我试过在 System Prompt 里加指令，比如告诉它“不要盲目重试，先判断是否为瞬时故障”，结果几乎没用。因为指令里没有提供判断依据，你只是让它在没有信息的情况下“更深思熟虑地猜一次”。最坑的是，这种重试偶尔能成功，在心理学上这叫“可变比例强化”，就像赌博一样，会让模型（以及熬夜调参的程序员）产生一种“再试一次没准就成了”的错觉，导致这个错误行为极难被根除。

单纯记录 Error Log 也没用，因为报错信息不等于操作指令。要让 Agent 真正从失败中学习，一个有用的失败追踪（Failure Trace）必须包含这三项：

• 唯一标识（Identity）： 必须给这次失败一个稳定的 ID。不能直接用原始报错字符串，因为里面包含请求 ID 和时间戳，每次都不同。得把变量剔除后做 Hash，让两个不同的 Agent 意识到它们撞到了同一个坑。
• 结果而非意图（Outcome）： 记录接下来的操作是否成功。写“我尝试刷新了 Schema”没用，得写“我刷新了 Schema 且调用随后成功了”，这才是关键信息。
• 分母（Denominator）： 必须记录成功率。100 次调用失败 100 次是系统宕机，100 万次调用失败 100 次只是日常波动。

如果直接对比字符串，它们是两条无关记录。正确的做法是用正则把时间戳、UUID、长数字等变量替换掉，再把剩下的核心报错内容和操作名称一起 Hash。

text = URL_RE.sub("", text)
text = UUID_RE.sub("", text)
text = TIMESTAMP_RE.sub("", text)
text = LONG_NUMBER_RE.sub("", text)

只有这样，当第二个 Agent 遇到同样的 422 错误时，它能通过这个 Hash ID 查到之前的“同事”尝试刷新 Schema 后成功了，它才会学聪明，不再死磕重试，而是直接去更新 Schema。