工具调用失败时，把原始 stack trace 整段塞回给模型，是我见过最贵的偷懒。翻译一层通常就够——「date 参数格式应为 YYYY-MM-DD，你给的是 2026/1/1」——模型下一轮自己就改对了。但翻译层一旦把原文吃掉，模型就再也学不到真实失败模式长什么样。我的立场：翻译，别销毁原文。
先分类，别急着调 prompt
我现在的做法是把工具错误分三类，只有前两类回喂给模型。
可重试的：超时、429、连接被重置。这类不需要模型动脑，重试逻辑写在代码里，模型最好只看到「已重试两次仍失败」。把 connection reset by peer 的栈丢给模型，它只会开始编理由。
可改参重试的：schema 不匹配、字段缺失、枚举值不在允许集合里、日期格式不对。这一类回喂价值最大，但必须翻译过——告诉它哪个字段、期望什么、实际收到什么。
不可恢复的：认证失效、权限不足、资源不存在、接口已下线。回喂只会让它进入「换个姿势再试一次」的循环。我吃过这个亏：一个已经删除的资源 ID，模型在五轮里换着法子重试，最后自己编出一句「资源可能只是暂时不可见」。
反面意见我认一半
有人说翻译过度会丢信息，模型永远学不会真正的失败模式。这话对。翻译本质上是一次有损压缩，而压缩规则是人写的——人写的规则一定有盲区。你没想到的错误，翻译层要么映射成「未知错误」，要么直接吞掉。
我更怕另一种情况：翻译层把错误「美化」成一句人话，但那句人话是错的。比如把 401 翻译成「请检查你的参数」，模型就乖乖去改参数，改十轮也改不对。
所以我的做法是双轨：喂给模型的是翻译后的短消息，但每轮都往 trace 里写完整原始错误，包括 response body。模型看不见，我和我的 eval 看得见。翻译规则出问题的时候，原始日志是唯一能复盘的东西。
信噪比比信息量重要
dan luu 那篇 How well do agents use test/verification techniques? 值得读。我的理解是：agent 拿到「跑测试」这个工具之后用得好不好，跟错误信息怎么给关系很大。测试失败输出是典型的高噪声——几百行 pytest 输出里可能只有一行是真正原因。翻译层在这儿不是可选项，是必需品。但翻译错了方向，agent 会去修一个没坏的东西。
HN 上那个 i-have-adhd 是同一个问题的另一面，它做的是让 coding agent 别把答案埋在长篇输出里。错误回喂其实是镜像问题：模型需要的不是更多信息，是更少但更准的信息。Cognition 讲 Devin 自己测自己那篇，逻辑也一样——给它可验证的信号，而不是给它一坨日志。
让模型看原始错误，代价可能是学会撒谎
Bengio 那篇 Why are AI agents lying, cheating and coordinating? 我没读完，但它提的方向让我警惕一件事：如果模型长期看到「失败 → 重试 → 成功」的轨迹，它学到的不一定是「怎么修」，也可能是「怎么把失败藏起来」。原始错误给多了，模型会开始猜你想要什么样的错误信息。这不是瞎想，是 reward 结构决定的。所以「该不该给原始错误」之外还有个问题——给了之后，你怎么知道它没在编。
顺带说一句，OpenAI 这周把 Agents API 的文档摆出来了。我没细看，但 tool 失败在返回结构里怎么表达，是值得抄的地方。
落到代码上
我现在的默认配置：工具返回结构固定三个字段——code（枚举，机器读）、message（翻译后的一句人话，模型读）、raw（原文，默认不进 context）。code 决定要不要重试、要不要回喂。回喂时只拼 message，偶尔附一行 raw 的关键片段——比如上游 API 返回的错误码本身，那玩意儿翻译不了。
要点是 raw 默认不进 context，但永远落盘。这样翻译层的 bug 是可修的，不是不可见的。
按我现在看，翻译层的成本被严重低估。大家都在调 tool schema、调 prompt，很少有人认真维护「错误消息」这套东西。但 agent 的迭代速度，很大一部分就卡在这儿。也许半年后回头，这块会被某个框架标准化——也可能不会，毕竟它脏、琐碎、每家长得都不一样。