一句话定义：工具调用的错误契约（Tool Error Contract），是指当模型调用外部工具（函数调用 AI 词典：Function Calling">Function Calling、MCP 工具等）失败时，运行时（runtime）回传给模型的错误信息，在格式、字段和措辞上遵循的那套约定。
核心问题只有一个：报错原样回，还是翻译成人话再回？
把模型想象成一个刚入职、只能靠留言条跟你沟通的同事，工具是他楼下跑腿的窗口。窗口出了问题，你回他一句"系统异常"，他只能原地打转或者瞎猜；你把窗口后台的堆栈日志原封不动贴给他，他更懵，还可能顺着堆栈编出一套根本不存在的修复方案。好的回执像一张化验单：哪一项异常、多严重、要不要重试、下次该改什么。
| 回传方式 | 模型看到什么 | 典型反应 | 风险 |
|---|---|---|---|
| 原始报错 | 堆栈、SDK 异常、ECONNRESET | 猜、乱改参数、重复调用 | 幻觉出错误修复路径 |
| 一律翻译成人话 | "出错了，请稍后再试" | 无差别重试，或直接放弃 | 丢掉了可恢复的信息 |
| 结构化错误契约 | 错误类别 + 是否可重试 + 哪个参数有问题 | 换参数、退避重试、改方案 | 需要前期设计 |
一份够用的错误契约通常包含：错误码、类别（参数校验 / 鉴权 / 限流 / 超时 / 资源不存在 / 内部错误）、是否可重试的布尔值、一句人话说明、必要的字段级细节（比如哪个参数不合法），以及可选的修复建议。三条底线：不贴堆栈、不吞细节、不写"服务暂时不可用"这种对谁都等于没说的话。
和相邻概念的区别
错误契约 ≠ 重试策略（Retry Policy）：一个决定"说什么"，一个决定"怎么办"。也 ≠ 可观测性日志（Observability / Logging）：日志是给工程师复盘用的，错误契约是给模型做决策用的。同样 ≠ 面向终端用户的 UI 提示：用户只需要知道"没成功，要不要再来一次"，模型需要知道"为什么没成功，我该改什么"。三拨受众，别共用一份文案。
还有一个容易被忽略的点：外部系统返回的错误文本是不可信输入，可能夹带指令。所以正确的做法是解析、裁剪、重写成契约字段，而不是把原始响应整段塞进上下文。
对从业者的意义
Agent 反复犯同一个错，多半不是模型笨，而是回执没写清楚。把错误分类当成接口设计的一部分，明确哪些错误值得让模型重试、哪些应该立刻终止并上报，能省下大量无效轮次和 token。
对普通职场人的意义
当你发现自动化流程卡在同一个环节，先看它拿到的是"失败了"还是"手机号格式不对，请去掉空格重试"——后者才是能自己走下去的信息。
错误契约的目标从来不是让报错好看，而是让模型在失败之后，还能做出正确的下一步。具体字段规范请以你所用的模型与框架官方文档为准。