错误信息是怎么反馈给模型的？过程拆开看

工具报错后的错误反馈，决定了大模型智能体能否一次修正，而不是反复撞墙——报错并非终点，是新一轮决策的起点。这篇拆解报错从发生到被消化的全过程。

报错不是终点，是新的输入

人修东西靠手感和经验，模型修流程靠的是把错误文本读进去再推理。所以错误信息的质量，直接决定修正的效率：一句「失败」，模型只能瞎猜重试；一句「参数 date 格式应为 YYYY-MM-DD，收到的是 2026/10/18」，模型改一次就能过。喂给模型的错误，值得当成提示词一样认真打磨，这句话就是本篇的核心。

错误信息在回传前被怎么处理

原始报错往往又长又绕，堆栈、内部路径、无关告警混在一起。回传前系统通常做三件事：提炼——只留错误类型、原因与修正建议；脱敏——路径里的密钥、内部地址先抹掉，做法与密钥是怎么注入调用的的脱敏规矩一致；限长——超长报错截断保关键段，手法与工具返回的内容太大是怎么办的相通。加工后的错误进对话，既省空间又提高命中率。

模型看到错误后怎么改

常见路径有三条：改参数重试，适用于格式、范围类问题；换工具或换方法，适用于此路不通的场景；向用户求证，适用于信息本身缺失、猜无可猜的情况。模型选哪条，取决于错误里给了多少线索——线索越具体，越倾向自己动手改，而非上来就求助。DeepSeek 与 Kimi 在函数调用报错时的自修正行为，就是观察这套机制的现成样本，工具挑选的依据则与工具描述是怎么影响选择的直接相关。

重试与放弃的分界线

同一错误连错三次，就该跳出重试循环了：继续撞墙只会浪费调用与时间。成熟的框架会区分错误类型——瞬时类错误适合退避重试，节奏问题见工具调用失败是怎么重试的；参数类错误必须改了再试；权限类错误重试无意义直接上报，拦截逻辑见权限校验在哪一步。到放弃那一步，也要把已尝试的路径与失败原因打包说清楚，让接手的人或上层流程不必从头排查。

错误反馈自查清单：错误文本是否提炼过而不是原样倾倒；敏感信息是否脱敏；同类错误是否限定了重试次数；放弃时是否带上了尝试清单。四条做到，报错才值钱。

把错误当养料还是当噪音，是流程成熟度的分水岭。反馈链路打磨得好，同一个坑模型只掉一次；打磨得差，它会以同样的姿势掉十次，还附带消耗你的耐心与调用额度。

错误分类表与升级话术

把常见错误预先分成几类，回传时按类套模板，比临场组织语言又快又稳：格式类直接给正确样例；超时类给等待建议并附退避说明；不存在类给相近候选让模型选；拒绝类给原因与替代路径。升级话术也要预备好：模型修正到上限仍失败时，交给人的那句话要包含任务目标、已试路径、卡住的错误类型，接手的人一眼能看出该从哪儿继续。模板放在配置里而不是代码里，调整不用重新发布。带走的判断：好报错是设计出来的，不是碰运气撞出来的，模板库就是这份设计的载体。分类表每季度过一遍，新出现的错误类型补进去，长期不再出现的降权下架，让模板始终贴着真实情况走。

四类错误配的模板与处理取向各不相同：

关于错误反馈的三个常问问题

• 错误信息原文要完整保留吗？：对外展示可以保留，回传给模型要提炼，两类受众用两种版本。
• 模型会不会把报错学进去越改越错？：会，所以同一错误要限定修正轮数，到上限就换思路或升级处理。
• 上游服务的报错能直接转发吗？：不能直接转发，要先翻译成模型能读懂的语言并脱敏，再进对话。