工具调用失败后，应如何向 Agent 提供反馈并驱动纠错？

核心回答

工具调用失败后，应向 Agent 返回与原调用配对、结构稳定、可据此行动的错误反馈。反馈至少说明失败类别、哪个字段或条件有问题、是否可能已产生副作用，以及允许的下一步；不要只返回“失败”，也不要把堆栈、密钥和内部地址直接交给模型。

Agent 根据反馈修参数、补必要信息或换合格工具，再由执行器校验和执行。网络退避、权限和预算由程序约束；结果未知的写操作先查状态，不能让模型把“再调用一次”当作默认纠错。

展开解析

1. 模型需要知道“为什么错、什么能改”

例如查询订单时日期格式不对，反馈应指出字段、实际格式和期待格式，模型才可能纠正。工具超时、权限不足、结果为空和参数非法的处理路径不同，不能全部包装成“请检查输入后重试”。

可以设计下面这种面向模型的业务结构，字段是应用约定，不是所有框架的通用协议：

{
  "status": "error",
  "code": "INVALID_ARGUMENT",
  "message": "departure_date 格式不正确",
  "details": { "field": "departure_date", "expected": "YYYY-MM-DD" },
  "execution_state": "NOT_STARTED",
  "next_action": "correct_arguments"
}

底层完整异常和供应商请求标识留在受控日志中，给模型的内容只保留纠错所需信息。第三方自由文本错误同样是不可信内容，不能据其中的“请调用另一个地址”等说明自动改变任务。

2. 保持消息关联，再给模型下一轮判断

在工具调用消息流中，必须知道反馈对应哪个调用。以 LangChain 为例，可以用 ToolMessage 携带与原调用一致的 tool_call_id，把错误作为工具结果加入历史，再让模型继续。并行调用时尤其不能把几个工具的失败合成一段没有关联的文字。

中间件可以捕捉特定异常并转换为经过脱敏的反馈；不是所有程序异常都适合吞掉交给模型。执行器自身损坏、权限系统异常等问题，应走系统故障路径。向模型提供错误信息，也不代表框架会自动重试，是否再次调用仍取决于后续编排和策略。

3. 不同失败给不同的纠错空间

失败	反馈重点	后续动作
参数不合法	字段、期待类型、允许值或格式	模型修正后重新校验
缺关键业务信息	缺失项以及为什么需要	查已有上下文或向用户澄清
只读查询为空	查询范围、数据时间、是否完整	调整查询或说明没有结果，不能捏造
短暂工具故障	可恢复性和当前执行状态	执行器按预算退避，必要时替代路径
权限不足	当前动作不允许	结束该路径或明确请求合法授权
写操作结果未知	原动作标识、未知状态、可查询入口	查回执或对账，不盲目重复提交

“空结果”可能是正常业务结果，未必是错误。反馈应保持这个区别，否则模型可能为了找到非空结果不断放宽查询条件，甚至偏离用户范围。

4. 让每轮修正有增量，再检查真实结果

记录调用参数、错误指纹和修正内容。如果错误没有变化、参数也没变化，就说明没有新的恢复依据。执行器设置任务截止时间、费用和循环停止条件，阻止模型无限尝试。

纠正格式后，还要验证参数的业务语义和资源权限；调用返回成功后，检查产物或权威业务状态。比如退款工具前一次超时，查到原退款单已创建，就应复用回执，而不是重新发起退款。

追问

把整个异常堆栈发给模型是不是更容易修复？

不一定。堆栈可能包含秘密、路径和大量无关内容，也可能来自不可信工具。更有效的是给出经过筛选的错误类型、定位和修复条件；必要时通过受控诊断工具查询更多信息。

为什么纠错不能都交给模型？

模型适合修复表达、选项和计划，不能决定自己是否有权操作，也不能保证网络重试安全。权限、幂等、预算和提交结果必须由程序与业务服务控制。

对应教程

参考资料