在 AI Agent 系统中，基础模型并不只是“负责聊天”的组件，而是工具路由器、参数解析器和执行计划生成器。模型选型如果只参考通用问答、代码生成或榜单分数，很容易出现演示效果不错、上线后却频繁选错工具、漏填字段或混淆参数的问题。因此，评估 Agent 模型时，应把函数调用准确率与工具参数理解能力拆开测试，再结合成本、延迟和工程可控性做决定。
一、函数调用准确率究竟包含什么
函数调用并非简单地输出一段 JSON。一个完整过程至少包括：识别用户是否需要调用工具、从多个候选工具中选择正确工具、生成符合约束的参数、处理工具返回结果，并判断是否需要继续调用。OpenAI、Anthropic 和 Google 的接口格式有所不同，但基本流程都是由应用提供工具定义，模型提出调用请求，应用执行后再把结果交还模型。相关机制可参考 来源链接 函数调用文档、来源链接 工具使用文档及 Gemini 函数调用文档。
因此，“能输出合法 JSON”不等于“函数调用准确”。模型可能正确生成了数据结构，却选错函数；也可能调用了正确函数，却把城市填入国家字段。评测时至少要分别记录调用判断准确率、工具选择准确率、参数结构合规率、参数语义准确率以及任务最终完成率。
二、工具参数理解比格式合规更难
结构化输出或严格模式可以减少缺少字段、类型错误和非法枚举值，但无法自动保证参数符合用户真实意图。例如，用户说“把下周二下午的评审改到两小时后”，模型需要理解当前日期、原会议时间、时区以及“改到”的操作对象。即使最终 JSON 完全符合 Schema，也可能得到错误日期或把时长误当成开始时间。
参数理解能力应重点考察四类问题：第一是实体映射，例如把昵称关联到联系人标识；第二是约束理解，例如金额必须为正数、结束时间不得早于开始时间；第三是上下文补全，例如从前文继承项目名称；第四是歧义处理，即信息不足时主动询问，而不是猜测关键参数。
三、不同模型应如何进行横向比较
不要直接照搬公开榜单作为采购结论。不同测试集的工具数量、Schema 复杂度、提示词和容错规则可能完全不同。更可靠的方法是从自身业务日志中整理脱敏样本，建立统一测试集，并让候选模型使用相同工具描述、相同上下文和一致的生成设置。
- 单工具测试：验证模型能否从自然语言中提取必填参数、可选参数和枚举值。
- 多工具路由：加入名称相似、功能相近的工具，观察误选率和不必要调用率。
- 多轮补参：故意缺少时间、金额、账号等信息，检查模型是否提出有效追问。
- 并行与串行调用：测试模型能否区分可同时执行的查询与存在依赖关系的步骤。
- 异常恢复：模拟超时、空结果、权限不足和参数校验失败，检查模型是否能够调整方案。
计分时不宜只采用“整条样本全对或全错”。建议同时统计工具名称、必填字段、可选字段、字段取值和执行结果，并将高风险字段设置更高权重。例如，天气查询中的单位错误影响有限，而付款工具中的收款方或金额错误必须直接判为失败。
四、Schema 与工具描述会显著影响结果
许多所谓的“模型能力问题”，实际来自工具设计不清。函数名称应体现动作与对象，如查询、创建、更新和删除不应混在同一工具中；参数描述要说明单位、格式、取值范围与默认行为；枚举值尽量显式定义；高风险动作则应增加确认字段或审批步骤。
工具数量也不是越多越好。一次暴露大量相似工具，会增加路由难度和上下文开销。更稳妥的方式是先按业务域进行一级路由，再向模型提供当前任务所需的工具集合。对于复杂对象，可把深层嵌套结构拆成较小步骤，避免模型一次生成过长且相互依赖的参数。
严格 Schema 解决的是“输出能否被程序解析”，清晰语义解决的是“模型是否理解了应该做什么”。生产系统需要同时满足两者。
五、选型时不能忽略工程指标
准确率最高的模型不一定最适合所有请求。高频、低风险、参数简单的任务可以使用速度快、成本低的小模型；涉及多工具规划、复杂约束或关键业务操作时，再切换到推理能力更强的模型。实践中可以建立分层路由：先用轻量模型分类和提取，低置信度样本升级到更强模型，高风险操作始终进入规则校验或人工确认。
除效果指标外，还应记录端到端延迟、首个工具调用时间、平均调用轮数、重试率、输入输出消耗以及供应商限流表现。测试时还要固定模型版本并保存原始响应，因为同一系列模型升级后，工具选择偏好和参数生成行为可能发生变化。
六、生产环境的安全边界
无论模型表现多好，都不应直接信任其生成的工具参数。应用层必须再次执行类型检查、权限校验、业务规则验证和幂等控制。删除数据、发送消息、修改权限、支付或对外发布等操作，应设置明确确认机制，并限制模型能够访问的数据范围。
工具返回内容也可能包含提示注入或恶意指令。系统应把外部数据视为不可信输入，避免模型因为网页、邮件或文档中的文字而绕过既定权限。完整记录工具选择、参数、执行结果和模型后续决策，则有助于问题追踪、回归测试与安全审计。
总结
AI Agent 的基础模型选型，核心不是比较谁更会说，而是验证谁能在真实约束下正确判断是否调用、选择合适工具、准确填写参数并从失败中恢复。合理流程应是：先建立贴近业务的测试集，再分项评估调用与参数能力，随后加入成本、延迟和风险权重，最后通过小流量灰度观察生产表现。只有把模型能力、Schema 设计、执行校验和安全治理结合起来，函数调用才能从演示功能变成稳定可靠的 Agent 基础设施。
