Appearance
Q44 · Function Calling 和 Tool Calling 有什么区别？
用户在客服窗口问：“订单 A123 发货了吗？”模型只看到聊天内容，并不会凭空获得订单数据库的最新状态。应用可以向模型提供一个“按订单号查状态”的能力：模型提出调用请求，真正连接订单服务的是应用，查询结果再交还模型组织成答复。你在文档中可能看到这个过程叫 Function Calling（函数调用），也可能叫 Tool Calling（工具调用）。
这两个词没有跨平台统一、互斥的定义。在工程讨论里，Function Calling 常指把开发者定义的函数暴露给模型；Tool Calling 常作更宽的名称，涵盖自定义函数，也可能涵盖平台托管的搜索、代码执行等工具。但 OpenAI 直接把 function calling 称为 tool calling，Anthropic 也把 tool use 称为 function calling。所以不能把“函数调用一定是工具调用的严格子集”当作所有 API 的术语定律。理解一次调用由谁提出、谁执行、结果怎样返回，比争名字更有用。
术语与例子中的名字
| 词或名字 | 直白解释 | 本文对应物 |
|---|---|---|
| 大语言模型 / 模型 | 根据输入生成文字或结构化调用请求的系统；它本身没有订单数据库权限 | 阅读用户问题，提出查询 A123 |
| 应用 | 接收用户请求、调用模型与业务系统的程序 | 客服后端 |
| 函数 / Function | 程序里有明确输入和返回结果的一段能力；这里不是数学公式 | get_order_status 包装订单服务的只读查询 |
| 工具 / Tool | 提供给模型使用的外部能力的统称，具体范围依平台而定 | 自定义订单函数或平台搜索工具 |
| 函数声明 / 工具定义 | 告诉模型能力的名称、用途、输入格式；只是说明书，不是执行结果 | “可用 get_order_status，必填 order_id” |
| Schema / JSON Schema | 描述输入数据有哪些字段、各字段是什么类型的规则；JSON 是常见的键值文本格式 | 要求 order_id 是字符串 |
| 参数 / Arguments | 某次调用填写的实际输入值 | {"order_id":"A123"} |
| 工具调用请求 | 模型输出的“请调用此能力及这些参数”；它不证明代码已运行 | 请求调用 get_order_status |
| 工具结果 | 执行方完成调用后返回的真实数据或错误 | status=已发货、tracking_no=T88 |
u7 / A123 / T88 | 虚构的已登录用户、订单号、运单号 | u7 有权查询 A123，查询得到 T88 |
| 客户端工具 / 平台内置工具 | 前者由你的应用执行；后者可能由模型平台在其服务端执行 | 订单查询由客服后端执行；网页搜索可由平台托管 |
下文所有订单和运单数据都是教学假设：已登录用户 u7 拥有订单 A123；订单服务真实返回“已发货”、运单号 T88，但没有预计送达时间。这些事实只有工具查询后才知道。若未查询或查询失败，模型不能把示例结果当成事实回答。
一次订单查询具体怎样走
业务上先有“查订单状态”这个动作，才给它起程序名 get_order_status。它接收订单号 order_id，向订单服务取回状态 status 和运单号 tracking_no。在一次模型请求中，应用把用户问题和这个工具的说明一起发给模型。下面是跨框架的接口示意，不是任何一家 API 可直接运行的完整请求体：
json
{
"name": "get_order_status",
"description": "查询已登录用户有权查看的订单状态",
"parameters": {
"type": "object",
"properties": {
"order_id": { "type": "string", "description": "要查询的订单号" }
},
"required": ["order_id"]
}
}name 是模型要选择的工具名，description 说明何时使用；parameters 是输入规则，object 表示一组有名字的字段，properties 列出字段，required 表示必须提供。order_id 这个字符串字段装 A123。真实 API 还可能要求额外的外层 type、严格模式、字段约束和版本参数，因此复制这段示意 JSON 并不能直接接通模型。OpenAI 的函数工具说明使用 JSON Schema 定义函数参数；具体协议应以所选 API 为准。
请求发出后，正常路径按以下顺序发生：
- 模型提出请求。 它根据用户的问题与工具说明，输出类似
get_order_status({"order_id":"A123"})的结构化调用。括号内是本次参数，不是订单状态。模型也可能直接答复或选错工具，所以程序仍要检查。 - 应用验证并执行。 客服后端只允许白名单中的工具，检查参数格式，再从已认证会话取得用户
u7，验证u7有权查看 A123，然后调用订单服务。登录身份不交给模型自由填写，以免模型传入别人的用户号。工具说明和 Schema 能帮助模型填对格式，却不能替代权限检查。 - 应用返回工具结果。 订单服务在本例返回
{"status":"已发货","tracking_no":"T88","eta":null}。eta在这里表示预计送达时间，null表示未提供，不代表“今天送达”。应用把结果关联到刚才那一次调用并交回模型；不同 API 的关联字段名称不同。 - 模型生成答复。 它可以说“订单 A123 已发货，运单号 T88；目前没有可确认的预计送达时间”。这个结论来自真实查询结果，不能补造具体到货日。
图中上方只画自定义函数的请求与执行；下方的放大镜提醒读者还有平台内置工具，执行位置须看平台文档。图里的“提出调用”绝不是“模型已经查过数据库”。例如 OpenAI 的 Responses API 会给自定义函数调用一个 call_id，应用执行后以对应的 function_call_output 回送；这是OpenAI 的字段名，不是所有平台通用的协议。OpenAI 官方流程明确包含模型给出调用、应用执行、回传结果和模型继续生成这几个环节。
如果 A123 不属于 u7，应用应在真实查询前拒绝，给出可安全展示的权限错误；模型只可说明无权查看，不能换账号重查。如果订单服务超时，应用应返回“查询结果未知”或明确的错误，模型不能凭先前示例说“已发货”。这也是把“模型提议”与“应用执行并核实结果”分开的原因。Q39 的工具失败处理进一步讨论重试和会产生副作用的写操作。
为什么四套文档看起来用词不同
| 文档体系 | 官方怎样用词 | 看订单例子时的理解 |
|---|---|---|
| OpenAI | “Function calling”也叫“tool calling”；函数工具用 Schema 描述，另有可接收自由文本的 custom tools。Tools 总览还列出网页搜索、文件搜索等能力 | get_order_status 是应用执行的自定义能力；搜索等是另外的工具类型，不能假定执行过程一样 |
| Anthropic | “Tool use”也叫“function calling”；区分应用执行的 client tools 和 Anthropic 执行的 server tools | 订单函数属于客户端工具，模型输出调用请求后由客服后端执行 |
| Gemini | “Tools”是总称；自定义工具通过 Function Calling 定义；Google Search、Code Execution 等属于内置工具 | 订单函数由应用执行，内置工具可在 Google 服务端完成；一个 API 调用是否能组合两类工具取决于模型与功能支持 |
| Spring AI | 框架章节叫“Tool Calling”，开发者可以把 Java 方法标上 @Tool 暴露为工具 | 即使底层是普通 Java 方法，框架仍叫工具调用；框架负责把模型请求分派给应用侧方法 |
这个对照表比较的是各文档的命名与执行责任，并不声称四家的请求字段、支持模型、部署方式相同。尤其是“平台内置”不能简单理解为“绝对不需要应用参与”：应用仍需配置可用工具、凭据、策略，并检查响应是否满足业务要求。对私有订单 A123，公开网页搜索也不会天然获得企业订单数据库权限。
函数定义、JSON 输出与真正执行是三回事
首先，函数定义只是给模型看的能力说明。它可以是订单查询、退款、发邮件，也可以调用另一个系统的 HTTP 接口，不要求必须对应一个同名的本地函数。get_order_status 在例子里是应用对外暴露的名字；底层可能经过权限服务和订单 API。工具调用请求是模型选择了名字并填参数；只有执行方验证并实际调用成功，才有可信的业务结果。
其次，模型输出 JSON 不自动等于 Function Calling。让模型最终输出 {"answer":"已发货"} 只是约束最终答复的格式；如果没有中途向订单服务发起调用，内容仍可能是猜测。Gemini 官方把 Structured Outputs 与 Function Calling分开：前者约束最终输出结构，后者用于连接外部系统的中间动作。Schema 也只能限制输入形状，不能保证订单号真实、用户有权查看，或工具结果一定正确。
最后，工具是否由应用执行要看工具类型。对上面的自定义订单函数，模型平台通常返回调用请求，应用负责执行并回传。对某些平台托管的网页搜索或代码执行，平台可能在服务端完成调用并给出最终或中间结果。以 Gemini 的内置工具流程为例，内置工具可在一次 API 请求中由 Google 执行；这不能推导出私有订单函数也自动由 Google 执行。Anthropic 对客户端和服务端工具也做了明确区分。
同时调多个工具意味着什么
“Tool Calling”这个名字本身不保证每轮只调一次，也不保证能并行。假设用户同时有权查看 A123 和另一个独立订单 B234，两个状态查询若彼此没有数据依赖，支持并行调用的模型与运行时可以在一轮提出两个请求；应用要按各自调用标识把结果配回正确请求，不能把 B234 的状态写到 A123 上。反过来，若下一步需要先拿到 A123 的运单号 T88，才能调用物流查询，那么物流查询依赖前一步结果，应顺序执行。
平台限制还会更具体。例如 OpenAI 的并行函数调用文档说明模型可以在一轮选择多个函数，也提供 parallel_tool_calls=false 控制为零个或一个；其文档还说明内置工具不能放进并行函数调用批次。这是 OpenAI 的协议约束，不能直接套给 Anthropic、Gemini 或 Spring AI。即使平台支持并行，对退款、发消息等写操作也需要单独考虑授权、顺序、重复执行和审计；并行能力不是并行执行的业务许可。
什么时候关注这个区别
读文档或设计系统时，先问三个具体问题：这项能力由谁定义？调用请求由谁执行？执行结果怎样回到模型？ 如果是应用定义并执行的订单函数，讨论“函数调用的参数 Schema、验证与回传”很贴切；如果系统还要接入平台搜索、代码执行或其他托管能力，用“工具调用”指整组能力更方便。落到某个 SDK 时，始终采用它自己的正式术语和字段名。
选型时还要检查是否支持当前模型、同轮多个调用、内置与自定义工具组合、错误回送、调用上限以及日志可见性。这些都是具体产品和版本的能力，不会由“Function”或“Tool”这个单词自动决定。Spring AI 的应用侧示例可接着看 Q18：Spring AI 中如何实现工具调用；基础调用流程可看 Q2：Tool Calling。
面试时可以怎样说
“Function Calling 和 Tool Calling 在很多官方文档里是同一套能力的不同叫法，不能硬划全球统一的边界。工程上我通常用 Function Calling 指开发者声明一个带名称、说明和参数 Schema 的自定义函数，让模型提出函数名和参数；用 Tool Calling 指更宽的工具能力，还可能包含平台内置搜索等。真正关键的是模型只提出调用请求：自定义订单查询由应用校验身份、参数和权限后执行，把结果回传，模型才据此答复。平台内置工具可能由服务端执行，需看各家文档。JSON 格式输出不等于已经调用函数；并行调用也取决于模型、API 和工具类型，不能由名称推断。”
若被追问“Function Calling 是否一定是 Tool Calling 的子集”，可以补一句：“作为工程分类可以这样画，但 OpenAI 和 Anthropic 文档直接把两词并用；跨厂商交流时先说明你讲的是自定义函数还是所有工具。”若被追问“模型调用了函数，是否就能告诉用户订单已发货”，回答应是：“不能。先看应用是否真正执行、用户是否有权限、订单服务返回什么；如果没有可信结果，就不能宣布已发货。”