面试官问：为什么 Agent 的 Function Call 一直不稳？

大家好，我是吴师兄。

做 Agent 应用的团队都会提到一个共同的痛点：“模型经常调用错工具、少传参数、瞎补字段、乱猜意图，Function Call 根本不稳定，怎么上线？”

这个问题在面试里也越来越高频。

因为 Function Calling 不是“会用就完事了”，而是一整套体系。

没有体系，就会变成你喊一句“查天气”，模型给你整一段“帮你订机票”的操作出来。

而在训练营里做了多个真实 Agent 项目之后，我越来越确信—— Function Call 的不稳不是模型的问题，而是系统设计的问题。

今天这篇文章就系统拆一下： 为什么 Function Call 一直不稳？到底卡在哪？

Function Call 不稳，不是偶然，是“必然”

很多同学天真地以为：

“Function Call 是 ChatGPT 自带的特性，它会自动选对函数、填好参数。”

实际工程里完全不是这样。

Function Call 会不稳，本质上是因为：

模型要在“不确定”的上下文里，完成“确定”的选择。

而不确定来自很多维度：工具多、Schema 名字混乱、上下文歧义、模型被截断、输入太长、采样温度太高、提示词不严格……

所以，只要系统里有一点点模糊，就会导致模型做错决策。

Function Call 的不稳，从来都不是 bug，而是设计不到位的自然结果。

影响 Function Call 稳定性的四大核心因素

在训练营的项目里，我们会让大家复盘每一个 badcase，慢慢就能总结出所有错误都来自这四类根因。

下面逐条拆解。

① Schema 不规范：函数名、参数名有歧义，是最大元凶

这是最容易被忽略、但影响最大的问题。

举个我们在旅行助手项目中的真实例子：

工具有：

• search_flights

• search_hotels

• get_weather

如果 Schema 写得不规范，比如：

• searchFlight

• flightSearch

• find_flight_info

模型马上会懵： 这些到底是不是同一个功能？是不是重复工具？哪个才是真正的航班查询？

再比如参数名写成：

• from_city

• origin

• start_place

模型也不知道哪一个才是正确字段。

Schema 不规范，是 Function Call 不稳定的头号杀手。

② Prompt 上下文不严谨：系统消息有歧义、被截断、信息缺失

当上下文写得模糊，模型就会“自己脑补”。

比如：

用户问： “明天北京天气怎么样？”

但系统同时把 6 个工具都塞进去：

• 查机票

• 订机票

• 查酒店

• 订酒店

• 查天气

• 查用户偏好

此时模型看到“明天、北京”，可能误以为是机票问题，甚至会调用 search_flights 。

上下文太臃肿 → 工具越多 → 决策越随机。

一个最简单的优化，就是做：

动态函数路由（tool subset） → 先识别意图，再把“可用工具列表”缩小。

这在训练营里是必讲模块，而不是可选。

③ 采样策略不合理：温度太高、top-p 太随机

很多人在开发 Agent 时，沿用了聊天模式的采样配置：

• temperature = 0.7
• top_p = 0.95

这在 Function Call 场景下是非常危险的。

因为 Function Call 不是生成创意回答，而是：

要让模型做一个“精确决策”。

温度越高，随机性越大，模型越容易幻觉出奇怪的参数、调用错误的函数。

正确的做法是：

• temperature = 0 ~ 0.2

• top_p = 0.8 左右

• 建议固定为 deterministic 模式

模型越“严谨”，Function Call 越稳定。

④ 缺少运行时防御机制：没有 Retry、没有 Reflection

模型是概率模型，不可能做到 100% 正确。

工程能力的意义就在于：

模型错一次，系统不能错一次。

很多团队直接把模型的 Function Call 输出拿去执行，导致：

• 参数缺失

• 参数类型错误

• 调用不存在的函数

• 把日期填成“明天后天之间”

• 把城市填成 None

这些错误，如果系统没有：

• JSONSchema 校验

• 参数校验

• Retry 机制

• Reflection 反馈给模型

那么 Function Call 的稳定性永远不会好。

这也是为什么在训练营里，我们把“结果校验层”作为 Agent 的标准组件，而不是可选增强。

用真实场景看看：为什么模型会选错工具？

旅行助手 Agent 是一个很好的例子。

场景：

用户问： “查一下明天北京天气”

如果不给动态路由，模型看到所有工具，会产生：

• “北京，明天” → 可能理解成机票日期

• “查一下” → 可能理解成查询航班

• “北京天气” → 但 weather 工具放在工具列表最后，模型可能忽略

所以就会出现：

{ "name": "search_flights", "arguments": { "origin": "北京", "destination": "明天" } }

这类 badcase 在真实项目里非常常见。

但当我们做了意图分类 + 工具子集后：

只给：

[get_weather]

模型就永远不会选错。

面试里到底该怎么回答？

面试官问：

“为什么 Function Calling 不稳定？”

最稳的回答逻辑是：

1）本质是模型要在不确定的上下文里做确定决策

• Schema 歧义

• Prompt 歧义

• 工具太多

• 输入被截断

• 采样随机

2）要从四个维度解决：

• Schema 唯一化、解耦化、无歧义

• Prompt 严格结构化、无歧义

• 采样策略调低随机性

• 运行时防御：参数校验 + JSONSchema 校验 + Retry/Reflection

3）举一个真实场景的 badcase，解释如何优化

例如旅行助手里的“查天气被误判成查机票”。

必须能讲出：

• 一个真实 FunctionCall badcase
• 对应的根因
• 用过的优化策略
• 改进后的效果

这才算真正能在面试里拿下 Agent 岗位。

总结

Function Calling 不稳定，并不是模型不行，而是系统设计没有做到位。 所有问题都可以归结为四件事：

• Schema 不规范 → 模型不知道选哪个

• Prompt 不严谨 → 模型不知道要干嘛

• 采样随机性太高 → 模型会“瞎填”

• 缺少运行时防御 → 一次错误＝彻底失败

当这四个方面都补齐之后，Function Call 才能真正做到可上线、可工程化。