AI面试题：为什么 Agent 的工具调用不稳定，怎么解决？

AI训练营6期，12月中旬开班，欢迎咨询

之前我们说过，复杂的AI项目，其难度有三：

第一，如何将认知整理成知识，或者已经有知识的情况下，如何组织数据；

第二，数据应该如何与AI交互，保证每次AI都能拿到相关数据。发现由于数据不足导致的AI问题，应该如何用生产数据反馈系统，优化知识库，这就是我们常说的数据飞轮系统，他是数据工程的一个分支；

第三，也是最后一个关卡，意图识别；

这不，我们P9的学员，在智能体创业项目中就被意图识别折腾得很惨：

并且错误的花样还五花八门的：

1. description明明写得很清楚，但工具就是不被调用；
2. 工具倒是调用准了，但是工具所需参数又拿不到；
3. 终于最后调好了，模型一个更新，整个系统又被玩坏了；

总结下来就一句：工具调用（Function Calling）总出问题，这个该如何解决呢？大概图示如下：

但具体要回答这个问题，就得从头说起咯，首先我们来看智能体架构的基石工具调用：

Agent的本质：函数调用

首先，我们要知道的是，现阶段大模型可以说是很简单的，因他就只有一个API调用，并且只有一个输入/输出：

但他其实很复杂，因为输入内容的背后具有大量的含义，需要我们把各行各业的知识放进去，否则输出很容易不符预期：

现在常见的智能体如Manus也是这个模式，比如最经典的让模型回答天气情况，因为模型本身是没有天气数据的，所以在用户询问天气时候，需要外调工具，这里核心代码是：

tools = [{
"type": "function",
"name": "get_weather",
"description": "Retrieves current weather for the given location.",
"parameters": {
"type": "object",
"properties": {
"location": {
"type": "string",
"description": "City and country e.g. Bogotá, Colombia"
      },
      ......
    },
  }
}]
response = client.responses.create(
  model="gpt-5",
  tools=tools,
  input="今天成都的天气怎么样",
)

可以看出来，模型具有哪些工具调用能力，全部是我们预定义好的，模型会根据用户输入，选择使用哪个工具：

# 用户输入
user_query = "今天北京天气怎么样？"

# 模型会分析：
# - 用户问的是"天气" → 匹配到 get_weather 的 description
# - 提到了"北京" → 对应 location 参数
# - 决定调用 get_weather 函数

而模型是如何判断要调用某个工具呢，答案是根据用户输入与description（名称、参数也会用到）做对比，也就是：

判断“今天北京天气怎么样？”
与
"description": "Retrieves current weather for the given location."
的关联性

于是这里问题也就来了，也就是我们之前学员会遭遇的问题：

这里是存在黑盒的，对于本次对话要不要调用工具、用哪个工具、参数怎么填，这个是没法直接插手的

当前场景简单、工具单一，模型的表现是很稳健的，但生产环境聊天上下文复杂度较高，并且工具数量也很多，这会加大模型工具调用难度，最直接的表现就是 漏调用 → 错调用 → 参数提取错误 → 调用出错

而这里会不会出工具调用问题，从架构设计来说，几乎是必定会发生的，而想要缓解工具调用的问题，只有两个点可操作：

第一，为问题添加更多上下文，以方便模型更好做意图判断，也就是在提示词上做文章；

第二，将Tools的设置，包括描述、参数等信息写得更清晰点；

除此两点之外，还有些“懒加载”策略，每次调用模型前，先做一轮意图识别，只加载需要的Tools，由此降低模型识别压力，但总的来说依旧是在大规则内做小优化。

只不过，出问题不重要，重要是发生得多频繁，如何降低他的问题。

意图收敛

如果在生产环境已经表现出了多工具调用出问题，那么就不能将用户上下文一股脑的给模型了，连这种都不能：

帮我查一下最近北京天气怎么样，还有机票贵不贵？
然后再给一堆工具：get_weather、search_flight、search_news...

更稳的做法是对用户问题进行改写，把输入整理成一个结构化意图，做一层意图清洗：

# 让模型只做意图识别 + 槽位填充
{
"task_type": "check_weather",
"city": "北京", 
"need_flight_info": true
}

再根据task_type去决定到底要出几个子任务、每个子任务暴露哪些工具。

换句话说：不要让模型一边理解人话，一边挑工具，一边还要组织答案。

把这些步骤拆开，这也是我们之前介绍的提示词规则单一职责原则，这样操作下来，错误率会降低的同时，出问题也好直接定位到对应提示词。

在落地上，常见的几种意图收敛手段：

1. 固定输入模板：让用户“填表”做选择题，而不是自由回答，这种方式使用较少，但效果很好；
2. 意图识别小模型：第一个模型只负责识别任务类型，第二个模型才负责调用工具，如果在成本、响应速度有要求时候，这个是常见选项；
3. 场景分流：用户入口就分查天气/查订单/问知识，不同入口走不同的工具集；
4. 问题改写，最后也是最常见的方式，会用模型对用户提问基于我们已有工具进行问题改写，这种效果较好，就是消耗Token很凶；

{
"intents": [
    {
"type": "get_weather",
"city": "北京",
"date": "最近三天"
    },
    {
"type": "search_flight",
"from": "上海",
"to": "北京",
"date": "本周五",
"sort_by": "price"
    }
  ]
}

总结下来就一句话：先认为对问题尽量结构化，再说工具调用。

工具收敛

前面说过，工具调用的黑盒部分我们管不了，但工具列表是完全能控制的。

很多时候工具调用最大的问题，不是模型不够聪明，而是你给它的工具太多、太像。这里实操下来，策略也就3个可以分享的：

第一，依旧是单一职责原则，一个工具绝不完成两个任务

# ❌ 多合一大工具
"description": "获取天气和航班信息"

# ✅ 单一职责  
"description": "获取指定城市的实时天气信息"

第二，按场景加载工具包，工具包预定义能少则少

# 不要有一个大 tools = [...] 到处复用
weather_tools = [get_weather]
order_tools = [query_order, cancel_order]  
# 每次请求前根据意图选一个小包挂上去

第三，描述和名称，AI要读得懂：

# ❌ 模糊的描述
"description": "Retrieves current weather for the given location."

# ✅ 清晰的描述
"description": "获取指定城市的实时天气信息。当用户询问当前温度、湿度、风速时使用。不适用于查询历史天气或气候特征。"

很多“description明明写得很清楚但就是不被调用”的场景，真拆开看，会发现description根本没有把什么时候用/不用说清楚，还有些时候name与参数的定义非常随意，你如果随意，模型就更随意了！

自由收敛

就算意图收敛、工具列表收敛、描述写得再漂亮，最终照样会出问题，原因是前面收敛有些动作也是依赖模型，本来就可能出问题，而更多的情况是参数抽取错误。

换句话说：关键词抽取错误（或者说抽取不稳定），是模型常见错误。

碰到这种情况，要么需要建立飞轮系统，不断根据错误增加知识库数据，不停在提示词加标签；要么会用到微调技术（概率很低）；

而有些时候，我们也会在代码上做处理，加一些验收逻辑，比如各种校验：

def get_weather(location, units='celsius'):
# 先校验，再执行
if not location or len(location) > 50:
    raise ValueError("城市名称无效")
if units not in ["celsius", "fahrenheit"]:
    raise ValueError("温度单位不支持")


# 工具返回后，检查数据结构是否完整
if not response.get('temperature'):
# 走备用方案或给用户友好提示
return"暂时无法获取温度信息"

# 设一个上限，比如每次最多重试2次
for attempt in range(2):
try:
return call_tool()
except ValidationError:
if attempt == 1:  # 最后一次还错
return"抱歉，暂时无法处理您的请求"

...

# 真正的业务逻辑...

工具调用评测集

事实上，所有的Agent，都会需要一个评测和数据回收。不然好不好都是抓瞎，甚至每次模型发布、新版本发布，稳不稳定都只能看脸。

而很多人确实也是这样开发Agent的：

1. 本地调试几次，觉得“挺准”；
2. 上线一跑，过几天用户开始骂；
3. 有时候好、有时候坏、还特别难复现；

这种“不稳定感”完全就是缺少评测集所致。而要建立这个测试集也很简单，就是对错误情况进行收集，而收集的第一步就是日志做得足够细，甚至每天有人审查：

一、日志：

# 每次调用都要记下来：
log_data = {
"user_input": "今天北京天气",
"model_tool_call": "get_weather",
"model_arguments": {"location": "北京"},
"tool_result": {"temperature": 25},
"final_response": "北京今天25度，晴天",
"success": True  # 业务标记
}

二、人工审查： 从日志里抽样本，标注：

1. 该不该调用工具？
2. 应该用哪个工具？
3. 参数有没有填对？

然后统计：漏调用率、错调用率、参数错误率...

三、根据错误样本做优化，策略也就是我们前面说的几点；

这其实就是数据飞轮在Function Calling上的一个子循环：生产数据 → 错误样本 → Prompt/规则迭代 → 新版本上线 → 再收集数据

Skills

然后最近Claude提出了Skills策略，其实他在一定程度也能缓解工具调用错误问题，在Skills策略之前的流程是：

用户输入 → 模型直接在一堆 tools 里挑
漏调 / 选错 / 懒得调，常发生在这一层

上了 Skills 之后变成：

用户问题 → 先选 Skill（粗意图路由） → 再在 Skill 里用少量工具 + 既定 SOP
模型不再对着几十个工具瞎撞，而是在各种小环境里做判断

其实可以认为Skills将之前我们一部分工程优化做到模型层去了。Skill 可以缓解：选错工具、什么时候调用工具、调用后数据如何处理等问题。

但是碰到用户语焉不详、工具schema一塌糊涂等问题时候依旧没办法。

只不过Skills这东西还不确定其他厂商要不要支持，所以我们后面再具体讨论吧。

结语

2025年10月2日，在美国旧金山硅谷举办内部封闭讨论会，有600多人的创业者，AI工程师参与；

而真实信息反馈：95% 的 AI Agent系统，在生产环境中根本用不起来。

并不是因为打模型不够聪明，而是AI工程以及工具层还需要继续努力，最后回归下，我们之前说过：

1. 复杂AI项目的第三难关是意图识别；
2. 意图识别失败，最直观的表现就是：工具调用乱七八糟；

但如果我们从工程的视角拆开看，它无非是几件事：意图收敛、工具收敛、自由度收敛（很多校准）以及一条评测数据集。

上述动作做完也不意味着问题没了，只不过会更心里有数了，如果这样都解决不了，那就换模型或者等模型更新就好，或者我们还有更复杂的策略，如提供上下文的上下文，只不过这确实很复杂了，我们这里就不展开了...

点击上方卡片关注叶小钗公众号，查看下方二维码，添加我个人微信：