大家好，我是吴师兄。
上周大模型训练营开始直播讲解 Agent 的项目，发现很多同学普遍有一个误区：
以为 Function Call 只要“给模型几个工具，它自然就能用好”。
结果实际一跑：
不是调用错工具，就是参数不全，要么格式不对，要么 API 返回被模型理解错……
最后大家都会露出那种熟悉的表情：
“吴师兄，这玩意儿怎么这么不稳？”
这篇文章，就带大家系统拆解：
一个 Agent 的工具调用能力，到底怎么做，才能真正稳定、正确、可控？
这也是在带训练营同学做项目时，最常讲的一个公式：
场景 → 找 badcase → 定位问题 → 优化策略 → 重新验证
所有 Function Call 的改进，都逃不过这个闭环。
为什么 Function Call 需要体系化优化？
真实项目里，一个 Agent 系统的可靠性，70% 卡在工具调用的对错上。 你想让模型更聪明，首先得让它“别犯低级错误”。
根据我们在大模型训练营的实践，Function Call 的准确性主要由 5 大因素决定：
-
Schema 定义质量 （函数名、参数名是否无歧义）
-
Prompt 上下文 （system 和 user 的语义是否干净）
-
采样策略 （温度过高，Agent 开始乱试）
-
训练数据与模型能力 （本篇不讲，下篇单讲）
-
运行时防御机制 （Retry / Reflection / JSON 校验）
这一篇专讲： 1、2、3、5
（第 4 点在之前的一篇《 面试官问：Function Call 训练数据怎么构建？ 》中细讲了）
为了让内容更“可落地”，我们使用一个统一示例场景：
假设正在打造一个旅行助手 Agent，拥有六个工具：航班查询、航班预订、酒店查询、酒店预订、天气查询、用户偏好。
接下来所有优化策略，都基于这个六工具案例展开。
体系化优化方法
在大模型训练营里，我通常把 Function Call 的优化分成五个方向。
1）动态函数路由（Dynamic Tool Routing）
Agent 最大的问题是：工具太多就更容易犯错。
例如一句话：
“明天北京天气怎么样？”
如果把六个工具全给模型，它完全没意义地看到“航班、酒店、预订”。
这会带来：
-
token 压力增大
-
决策空间更大
-
错误概率变高
所以需要一个轻量级意图分类器， 在模型出手前就决定工具子集。
示例：
用户说：“查一下明天北京的天气” 动态路由只给模型：
[get_weather]
效果极其显著： 少 80% 的工具噪音，错误率直线下降。
在训练营项目里，我们对工具数超过 5 个的 Agent，几乎都强制加路由器。
2）CoT + Plan-Execute：强制让模型“先想后做”
当用户任务复杂：
“帮我订明天从上海到北京的机票，再订个机场附近的酒店。”
如果直接让模型 Function Call，大概率：
-
工具顺序乱
-
参数缺失
-
或者跳步执行
解决方案：
强制模型先输出 Thought 和 Plan，再执行 Action。
模型提前规划：
-
Step1 查航班
-
Step2 订航班
-
Step3 查酒店
-
Step4 订酒店
并通过 ReAct 将 API 错误带回，让模型自我纠错。
这套 “Plan → Execute → Observation → 修正” 的闭环， 现在是训练营里所有 Agent 项目的标配。
3）结果校验层（Validation Layer）
这是大多数人遗漏的关键。
无论模型调用工具，还是工具返回数据，都必须：
-
参数校验
-
Schema 校验
-
错误重试
-
错误类型判断（401、429、格式错误、参数缺失）
例如：
模型生成：
search_flights(destination="北京", date="明天")
但缺少 origin 校验层立即拒绝，并反馈：
“缺少参数 origin，请补全。”
模型就能自动修正。
再例如 API 返回 temperature="15 Celsius"（字符串） Schema 要求 number 校验层可做：
-
自动清洗
-
或重试
-
或反馈给模型进行 Reflection
这一层，是“工程稳健性”真正的分水岭。
4）长程记忆 + Prompt 变量注入
多轮对话里，如果没有记忆：
“我想去北京玩几天。”
“帮我查机票。”
模型可能根本不知道出发地、目的地、日期是什么。
训练营的 Agent 框架统一做法：
-
把关键信息写入 memory
-
在 system prompt 中自动注入变量
-
模型每轮都能获得最新状态
例如：
吴师兄当前行程信息:
- 出发地: 上海
- 目的地: 北京
- 出发日期: 2023-10-30
然后模型自然能执行：
search_flights(origin="上海", destination="北京", date="2023-10-30")
记忆 + 注入，是让 Agent 变得“有大脑”的核心手段。
5）日志驱动调优（Log-Driven Optimization）
所有真实项目走到最后，都要落到这一点：
用日志找 badcase，通过聚类分析高发错因，反推 Prompt / Schema / 路由优化。
记录：
-
user_query
-
tool_chosen
-
params
-
error_type
-
LLM Thought（若有）
例如经过聚类你会发现：
-
30% 的错是日期解析
-
20% 的错是酒店 location 语义不明
-
10% 的错是工具名太相似
-
5% 的错是模型乱输出
这才是“体系化落地”的真正路径。
通过 3 个真实 CASE，看优化效果
下面用三个典型 Case，完整串一遍 Agent 优化思路，为了方便读者朋友们更好的理解，我把训练营相关的文档稍微简化一些。
训练营的同学直接结合视频看原文档即可。
CASE 1：动态工具路由，减少 80% 的错误来源
用户输入：
“查一下明天北京的天气。”
传统做法：
-
六个工具全部暴露给模型
-
模型浪费 token
-
功能冲突
改进后：
意图分类器：意图=查天气 工具子集：
[get_weather]
模型直接输出正确调用：
get_weather(city="北京", date="明天")
单点优化，提升的是 整体稳定性。
CASE 2：CoT + Plan-Execute，解决复杂任务的可靠性
用户：
“帮我订机票，再订酒店。”
模型先规划（Thought + Plan），再逐步执行。
遇到 API 支付失败：
error: Payment Failed
模型进行 ReAct：
“支付失败，我将尝试备用支付方式。”
这类“自我纠错”，是可控 Agent 的核心。
CASE 3：结果校验层，拦截 90% 的“模型幻觉式参数错误”
模型忘记 origin：
search_flights(destination="北京", date="明天")
校验层卡住：
origin 缺失，请补全
模型重新生成正确调用。
API 返回字段类型不符时：
-
自动清洗
-
或重试
-
或让模型 Reflection 修正
你会惊讶地发现：
一个简单的 SchemaCheck 可以把错误率降低一半。
总结：稳不稳，取决于“系统性思维”
这篇文章的所有内容，来自我们在「吴师兄大模型训练营」里实战项目的总结和简化易懂版。
很多同学以前做 Agent，总觉得模型不听话、爱乱跑。
但当你真正把 Function Call 的链路拆开：
-
Schema
-
Prompt
-
路由
-
CoT
-
校验
-
日志闭环
-
记忆注入
一个稳健的 Agent 工程体系自然显现出来。
如果面试时能讲到：
“我们在 Agent 中加入了动态路由、Plan-Execute、Schema 校验与日志驱动优化，用来提升工具调用的准确率。”
那面试官一定知道：
这不是看博客学的，这是做过真项目的人。