完整题目
在Agent系统中，当外部工具调用失败时，应如何设计有效的反馈策略以保障任务的连续性与智能性？请说明是否应向模型返回具体错误信息、如何决策重试机制或工具切换、以及这些反馈如何影响后续规划与整体闭环决策过程。
本文目录
核心设计原则：分层反馈 + 状态驱动决策
一、错误信息暴露策略（分层控制）
| 层级 | 暴露内容 | 适用场景 |
|---|---|---|
| 受控诊断 | 经脱敏的错误码、参数路径和可修复摘要 | 如缺字段/枚举错误；不向模型发送凭据、内部堆栈和敏感参数 |
| 语义化摘要 | "认证失败"/"数据不存在" | 通用场景，避免信息过载 |
| 完全屏蔽 | 仅返回"工具不可用" | 安全敏感或外部不可信工具 |
关键判断：先满足最小信息与敏感数据策略，再按可修复性和实测错误处理能力选择反馈；不存在7B/70B的通用能力门槛。认证由可信服务处理，不把访问token交给模型修复。
二、重试 vs 切换的决策机制
# 策略伪代码：动作与状态字段需由执行框架实现，不直接调用真实工具。
def decide_next_action(error, context):
if context.deadline_expired or context.attempts >= context.max_attempts:
return Escalate(reason="budget_exhausted")
if error.type == AUTH_FAILED:
return Reauthorize(to="trusted_application")
if error.type == NOT_FOUND:
return ClarifyOrEmptyResult()
if error.type in [TIMEOUT, RATE_LIMIT]:
if context.has_side_effect and not context.idempotency_supported:
return ReconcileExternalState()
return Retry(backoff="exponential_with_jitter",
retry_after=error.retry_after)
return Escalate(reason="unclassified_error")决策因子：错误语义、deadline/总尝试预算、Retry-After、幂等与外部状态、工具SLA，以及替代工具是否有相同授权和数据边界。认证失败不能靠换更宽权限工具绕过；NOT_FOUND也可能是正常空结果，先核实输入/可见性。
三、反馈融入闭环决策
短期（单轮会话）：
- 将错误及处理结果写入
observation，ReAct循环中作为新上下文 - 示例：
"搜索工具超时，已切换至备用API，获取结果：..."
长期（跨会话）：
- 工具失败日志入库，用于：
- 动态调整工具优先级（失败率高的降权）
- 微调或Prompt优化（常见错误模式→few-shot示例）
四、状态机驱动的规划调整
Planning → ToolCall ──失败──┬─→ Retry ──成功→ Resume
├─→ Switch ──成功→ Resume
└─→ Fail ──→ Replan/Abort关键：由on_tool_fail按策略决定恢复、澄清、重新授权或终止。授权拒绝、预算耗尽或高风险结果未知时可以暂停/结束；闭环不等于失败后必须继续。
学习建议
建议先理解Agent的执行流程，再学习常见工具调用模式与错误类型，结合实际案例练习设计带容错和反馈的Agent决策逻辑。
参考资料
换一种问法，检查是否真正理解
场景切入
假设我们在做一个订单查询Agent，用户问‘我的订单到哪了’，它调用物流API但超时了。这种情况下，你觉得应该直接把超时错误堆栈返回给模型，还是包装成‘查询暂时不可用’？怎么设计才能让Agent自己决定重试还是换个快递查询工具？
层层追问
Agent调用外部工具时，失败是家常便饭。你是怎么处理的？……比如重试策略，你一般怎么决定要不要重试？……那如果重试几次还是失败，你会让它换工具吗？……这些失败信息反馈给模型后，它怎么影响后续的计划？你整体上怎么设计这个闭环？
直球架构
设计一个Agent系统的工具调用失败反馈机制，要求分层错误暴露、动态决策重试还是切换工具，并且失败信息要能影响后续规划。你怎么设计这个状态机？具体说说错误信息怎么过滤、重试策略有哪些因子、以及如何把失败记录反馈到长期优化中。
练习口述回答 · 约4分钟
- 这道题本质是问Agent在工具调用失败时怎么保持智能和连贯
- 反馈先脱敏与最小信息，再按可修复性与实测能力分层
- 重试还是换工具，核心看错误类型和上下文
- 反馈要进闭环，短期影响当前规划，长期用来优化工具选择
- 落地关注权限边界、尝试预算与结构化日志
这道题其实就是在问，[[Agent]] 调用外部工具失败时，怎么保证它还能继续往下走，不傻掉。本质是 反馈怎么设计才能让 Agent 保持智能和连贯，而不是简单的失败重试。
先说错误信息暴露。很多人第一反应是“把所有错误细节都扔给模型”，但实际落地会发现，先遵守最小信息与敏感数据策略，再看错误能不能修和实测能力，不能按7B或70B划一条通用能力线。我一般分为受控诊断、语义摘要和必要屏蔽。受控诊断只给脱敏错误码、字段路径与可修复提示，不送凭据、内部堆栈或敏感参数；语义化摘要就是“认证失败”“数据不存在”这种，通用场景最常用；完全屏蔽用在安全敏感或者外部不可信的接口，只告诉它“工具不可用”。
例如订单查询返回401，可以给模型“需要重新授权”的受控状态，由可信应用恢复认证或向用户请求授权；不让模型拿token自行修复，也不因模型大小改变权限边界。
再说重试和切换的决策。核心逻辑很简单：按错误语义和业务状态决策。超时/限流仅在总预算与幂等条件满足时退避加抖动，尊重Retry-After；写操作结果未知先对账。认证失败走可信重新授权，数据不存在先区分正常空结果和输入问题；切换工具还要保持相同授权与数据边界。决策因子包括错误类型、已重试次数，还有任务的时效性，如果用户等不了，就少重试快切换。
这里有个坑：重试和切换不能拍脑袋定死，得动态判断。例如高峰期限流多时应控制尝试总量和退避，防止恢复流量放大；不能因为限流更多就加大重试压力。所以我会把决策做成一个可配置的策略，结合工具的历史成功率动态调整。
然后是反馈怎么融入闭环。短期看，错误和处理结果要写进 observation，让 [[ReAct]] 循环能感知。比如“搜索工具超时，已切换至备用 API，获取结果：...”，这样 Agent 接下来规划时就知道发生了什么。长期看，工具失败日志要入库，用来调整工具优先级，失败率高的自动降权，甚至定期生成 few-shot 示例，让模型学会常见错误怎么处理。
最后说规划调整。我倾向用状态机驱动：Planning -> ToolCall -> 失败 -> 进入 on_tool_fail 钩子，重新评估是重试、切换、还是重新规划。失败按策略恢复、澄清或终止；权限拒绝、预算耗尽或高风险状态未知时可暂停，闭环并不要求一直执行。比如 Agent 原本计划查库存再计算运费，但库存接口挂了，切换到备用接口后，它应该能意识到“备用接口返回的数据格式不同”，自动调整后续的计算逻辑。