Function Calling 到底是什么：模型不能自己查天气，工具调用链路的六个环节如何接力

很多刚接触大模型应用开发的人会有一个误解：以为模型接到「帮我查下明天杭州天气」就能自己去查。实际上模型只做一件事——根据上下文预测下一个 token，它没有网络、没有数据库、也没有执行环境。工具调用（Tool Calling，也就是常说的 Function Calling）解决的正是这个断层：让模型用结构化的方式表达「我想调用哪个函数、传什么参数」，真正的执行交给外部程序。理解这条链路里的每个环节，才谈得上把模型接入业务系统。

Function Calling 的本质经常被说错。它不是模型在执行函数，而是模型在生成一段符合约定的 JSON。开发者事先把可用工具以 schema 的形式声明给模型，模型判断这轮要不要调用、调用哪一个、参数填什么；应用层收到这段结构化输出后，自己去执行真实函数，再把执行结果作为新消息回灌，模型据此生成面向用户的自然语言答复。整个过程里，模型始终只负责决策和表达，副作用由业务代码承担。

一条完整的工具调用链路通常有六个环节。第一是工具声明，把每个工具的名称、用途、参数结构写成模型能读懂的描述；第二是意图判断，模型决定这轮对话要不要调工具；第三是参数生成，按 schema 填出结构化参数；第四是应用层执行，做校验、鉴权、限流后调用真实接口；第五是结果回灌，把返回值塞回消息列表；第六是二次生成，模型基于返回值组织最终答复。任何一个环节出问题，用户看到的都是答非所问。

工具描述的质量，往往比模型本身更决定成败。description 写得含糊，模型就会在多个相似工具之间乱选；参数类型不严谨，就会收到字符串形式的数字、缺字段的半成品；没有列出枚举值，就会编出不存在的状态。实践中的经验是：把 description 当成写给新同事的接口文档来写，说清什么时候该用、什么时候不该用，并为易错参数补上一两个示例，工具选择的准确率会有明显提升。

并行调用是近几年才普及的能力。早期接口一次只能返回一个函数调用，复杂任务要来回多轮；现在不少模型可以在一次回复里同时给出多个 tool_calls，比如查天气和查航班同时发起，应用层并发执行后再统一回灌。这带来两个新的工程问题：有依赖关系的调用必须串行，回灌顺序必须和调用 id 严格对应，否则模型会把结果对错工具，输出一段看起来很合理但完全错误的答案。

工程落地最容易踩的坑集中在参数层。模型会幻觉出一个 schema 里根本没有的字段，会把日期写成自然语言，会在必填项上留空。比较稳妥的做法是在执行前做一次严格校验：类型不对直接拒绝并返回结构化错误，让模型自我修正一轮；涉及写操作的工具，参数里一定要带幂等键。此外还要设最大调用轮数，防止模型在两个工具之间来回调用形成死循环，把一次普通问询变成持续消耗。

安全边界是工具调用里最容易被低估的部分。模型能调用什么，就等于它间接拥有了什么权限，原则是最小权限：能只读就不要给写权限，能查单条就不要给批量导出，涉及资金、删除、对外发送的动作一律加人工确认。另一个常被忽略的风险来自工具返回值本身，如果外部网页或用户上传的内容里夹带了「忽略之前的指令」这类文字，模型可能被诱导去做越权操作，因此回灌内容也要做过滤和标注。

从协议层面看，工具调用正在收敛。OpenAI 风格的 tools 字段已成事实标准，国产主流模型和各类聚合中转服务也大多兼容这套结构。这对开发者是好事：同一套工具定义可以跨模型复用，切换上游时改动量很小。但细微差异仍然存在，比如并行调用是否默认开启、参数错误的返回格式、流式输出时 tool_calls 的分片方式，这些差异处理不好，会在切换模型时集中爆发。

这正是中转层在工具调用场景里的价值所在。以快米兔的模型 API 中转为例，它对外提供统一的接口形态，把上游国产合规模型在工具调用上的字段差异收敛在一层，应用侧按同一套 schema 写工具、按同一套结构解析 tool_calls 即可；流式场景下参数分片的拼接也由中转层统一处理。对于还在选型阶段、需要同时对比多家模型工具调用表现的团队来说，这种统一入口能省下不少适配代码。

成本也是选型时要算的一笔账。工具调用的 token 消耗比普通对话高得多：工具 schema 每轮都要随请求发送，回灌的结果同样计入输入，多轮调用会把输入长度推高好几倍。快米兔的模型 API 中转采用按量计费，注册送 5 元测试金，先小规模跑通链路、测出真实消耗，再决定正式用哪家模型，试错成本相对可控。具体资费与可用模型以官方说明为准。

建议的验证路径分三个阶段。第一阶段只接只读工具，用几十条真实问法跑一遍，看模型选对工具的比例、参数填对的比例；第二阶段加入多轮依赖，观察它拿到错误返回后能否自我修正；第三阶段再开放写操作，并且全部加上幂等与人工确认。每个阶段都保留完整调用日志，包括输入的 schema、模型返回的 tool_calls、执行结果和最终答复，出问题时才能判断是模型选错了还是代码执行错了。

评测工具调用能力，靠感觉不行。可行的做法是自建一小套用例集，覆盖必须调用、不该调用、需要多工具协作、参数易错四类场景，每条用例记录期望的工具名和关键参数，跑完后统计三个指标：工具选择正确率、参数完整率、多轮任务完成率。同一套用例在不同模型上跑，横向差距通常比榜单分数更贴近自己的业务。工具调用是模型从会说话走向能干活的分水岭，链路里的每个环节都值得认真对待。