2026年2月5日
Uncategorized

Agent调用工具出错了，如何处理？

在构建 Agent 时，“错误”不是终点，而是极具价值的“上下文输入”。优秀的 Agent 设计会将错误转化为自我修正的线索（Self-Correction Cues）。

以下是处理工具调用错误、制定分级策略以及解决多工具冲突的工程化方案：

一、 Agent 调用工具出错了，如何处理？（闭环机制）

传统的软件开发遇到 Exception 通常会 Crash 或 Log，但在 Agent 架构中，我们需要构建一个 “观察-反思-修正” (Observe-Reflect-Correct) 的闭环。

核心原则： 将 Error Traceback 当作 Observation 喂回给 LLM。

标准处理流程图

  1. 捕获异常 (Catch): 在工具执行层（Executor）捕获所有异常，不要让程序崩溃。
  2. 格式化错误 (Format): 将冗长的 Python 报错堆栈（Traceback）精简为 LLM 能读懂的提示。
    • Bad: File "/lib/python...", line 40, in ... ValueError: ...
    • Good: ToolExecutionError: The argument 'date' must be in 'YYYY-MM-DD' format, but received 'tomorrow'.
  3. 反馈上下文 (Feedback): 将上述“Good”的错误信息作为 System Message 或 User Message 再次发送给 Agent。
  4. 重试推理 (Re-reasoning): Agent 看到错误信息后，会利用自身的逻辑能力生成新的、修正后的工具调用参数。

二、 如何按照错误类型调策略？（分级治理）

不同的错误需要不同的“药方”。建议在代码层建立一个 Error Handler Mapping，针对不同类型的错误注入不同的 Prompt 或执行不同的逻辑。

错误类型典型场景应对策略 (Strategy)系统 Prompt 注入示例
幻觉参数 (Hallucinated Args)调用 send_email 时编造了一个不存在的参数 priority=highSchema 强化再次注入工具的 JSON Schema 定义，并提示：“参数 priority 无效。请仅使用 Schema 中定义的字段。”
格式错误 (Parsing Error)LLM 输出的 JSON 少了括号，或包含 Markdown 符号格式修复器调用一个轻量级 LLM (Output Parser) 进行修复，或者提示：“输出无法解析为 JSON，请严格仅输出 JSON 字符串，不要包含 Markdown。”
逻辑校验错误 (Validation Error)日期填了“下周三”，但 API 需要 “2026-02-11”规则提示将 Pydantic 的校验报错直接返回：“日期格式错误。当前时间是 X，请计算出具体日期。”
运行时错误 (Runtime Error)API 超时 (Timeout) 或 500 错误指数退避 (Backoff)不要立即问 LLM。在代码层自动重试 3 次（间隔 1s, 2s, 4s）。如果全失败，再通知 LLM 换个工具。
空结果 (Empty Result)查询数据库返回 []，文件不存在策略切换提示 Agent：“未找到数据。请尝试放宽搜索条件，或改用 keyword_search 工具。”

三、 多个工具符合需求，如何选最优？（工具消歧）

当用户说“帮我查一下 A 公司”，而你有 Google Search、internal_wiki_search 和 stock_api 三个工具时，Agent 容易犹豫或乱选。

以下是三种优化工具选择的策略：

1. 描述工程 (Description Engineering) – 最基础

LLM 选择工具主要依赖 docstring (函数注释)。如果描述重叠，LLM 就会困惑。

  • Bad: search_wiki: “Search information.” / google: “Search internet.”
  • Good:
    • search_wiki: “Use this ONLY for internal company policies, employee directory, and project documentation.”
    • google: “Use this for public news, competitor analysis, and external market data.”
  • 技巧： 在描述中加入 Negative Constraints (负向约束)，明确告诉 Agent 什么时候不要用这个工具。

2. 路由层 (The Router Pattern) – 更精准

在 Agent 执行具体任务前，增加一个专门的 Router Chain (分类器)。

  • 原理： 先用一个快速的 Prompt 将用户意图分类。
  • Prompt: “用户的问题属于以下哪类？[内部知识, 外部新闻, 股票数据]。只返回类别名称。”
  • 逻辑：
    • 如果是“内部知识” -> 仅挂载 internal_wiki_search 工具给 Agent。
    • 如果是“外部新闻” -> 仅挂载 Google Search 工具。
  • 优势： 缩小了 Agent 的选择范围，极大降低了幻觉概率。

3. 成本与性能优先级 (Cost/Latency Priority)

如果在代码层面发现多个工具都能解决问题（例如都有 search 功能），可以通过 Metadata 进行硬编码排序。

  • 策略： 优先使用 更快、更便宜、更可信 的工具。
  • 逻辑示例：
# 伪代码：自定义工具选择逻辑
def select_best_tool(tools, query):
    # 1. 优先尝试本地缓存/数据库 (Cost: 0, Latency: low)
    if local_db.has_data(query):
        return local_db_tool
    # 2. 其次尝试内部 API (Cost: low)
    elif is_internal_query(query):
        return internal_api_tool
    # 3. 最后兜底使用昂贵的外部 Search (Cost: high)
    else:
        return google_search_tool

总结建议

  1. 容错： 永远不要 swallow exceptions。把 Python 的报错翻译成“人话”喂回给 Agent。
  2. 策略： 区分“系统崩了”（重试）和“Agent 傻了”（提示修正）。
  3. 选择： 与其让 Agent 在 10 个工具里瞎猜，不如先用 Router 把工具缩减到 2 个，再让它选。