OpenAI Function Calling / Tools

1. 调研缘由

2023 年 6 月，OpenAI 推出了 Function Calling，让 GPT 模型能按开发者给出的函数定义，从用户请求里选函数、生成结构化参数。它最初搭载在 Chat Completions API 上，主要用来把自然语言请求转成应用能执行的函数调用。[S2]

之后，Function Calling 被纳入了更完整的 Tools 体系。现在的 Responses API 可以同时接入开发者自定义函数、Web Search、File Search、Code Interpreter、远程 MCP、Tool Search 和 Programmatic Tool Calling；Agents SDK 再往上管理多轮执行、handoff、session、guardrail 和 tracing 这些 Agent 运行逻辑。[S4][S5][S6][S7]

另一边，Anthropic 和 Google 也已经提供了流程类似的 Tool Use 或 Function Calling：开发者声明工具，模型选工具、出参数，应用或平台执行工具，再把结果返回模型。[S10][S13] 所以，“模型能输出函数名和 JSON 参数”已不再是 OpenAI 独有的产品能力。

这篇简调重点回答三个问题：

1. Function Calling 在 OpenAI 工具体系里处于什么位置；
2. 跟 Anthropic Tool Use、Gemini Function Calling 比，OpenAI 的差异主要落在哪些具体机制上；
3. strict 和 Structured Outputs 解决了哪些可靠性问题，哪些安全与工程责任仍然在开发者手里。

2. 简介与产品工作流

OpenAI Function Calling（官方也称 Tool Calling）是一种机制，模型通过结构化输出来请求应用调用外部代码。开发者在 API 请求的 tools 字段里声明函数名称、用途和 JSON Schema 参数；模型决定要不要调工具，并返回函数名称和参数；应用执行真实的代码后，再把结果连同对应的调用标识还给模型。[S1]

一个基本工作流包括五步：

1. 应用把用户请求和可用工具定义一起发给模型；
2. 模型返回零个、一个或多个工具调用请求；
3. 应用检查参数并执行对应代码；
4. 应用把工具执行结果返回模型；
5. 模型生成最终回复，或者继续发起下一轮工具调用。[S1]

这里的“调用”不等于模型直接跑开发者的代码。对于自定义函数，模型只负责输出工具名称和参数；数据库访问、发邮件、退款、改账户或其他真实操作，仍然由开发者控制的应用来执行。[S1]

OpenAI 当前文档里的工具主要包括：

• Function tools：通过 JSON Schema 定义参数，由开发者的应用执行；
• Custom tools：接受自由文本或自定义语法输入，适合代码、查询语言之类不方便固定成 JSON 对象的任务；
• OpenAI 托管工具：包括 Web Search、File Search、Code Interpreter 和 Image Generation 等；
• 远程 MCP 与 Connectors：把外部服务或 MCP Server 暴露给模型；
• Tool Search：先提供工具目录，模型需要时再加载完整工具定义；
• Programmatic Tool Calling：让模型生成 JavaScript，组合条件判断、循环及多个工具调用。[S1][S4][S5][S6]

开发者能用 tool_choice 控制模型用不用工具：可以让模型自己决定，也可以强制至少调一个工具、强制指定某个函数、限制本轮可用工具，甚至完全禁止工具调用。自定义函数还允许模型在一次响应里请求多个相互独立的调用。[S1]

这套机制主要面向需要把模型接入内部 API、数据库、业务系统和自动化流程的开发者及企业技术团队。[S1][S7] 它本身不提供固定的文本、检索、自动化或其他业务能力，实际能力取决于开发者连接了哪些工具，所以 frontmatter 的 capabilities 留空。

3. 团队与资本背景

Function Calling 既不是一家独立的公司，也不是开源组织或单独融资的项目，它只是 OpenAI API 平台的一项基础能力。2023 年 6 月，OpenAI 随新版 GPT-4 和 GPT-3.5 Turbo 正式对外公布了 Function Calling。[S2]

2024 年，OpenAI 又推出 Structured Outputs，把严格的 schema 约束加了进来。相关发布文章里列出了产品、研究和工程的贡献者，但他们是 OpenAI 平台功能开发团队的人，并没有一个对外独立运营的 Function Calling 团队。[S3]

2025 年 3 月，OpenAI 发布了 Responses API 和开源的 Agents SDK，把函数调用、托管工具和 Agent 运行能力放到了同一个开发体系里。[S7][S8] 所以这份报告不单独展开 OpenAI 公司的融资情况；funding_stage 记为“不适用（OpenAI API 平台能力）”。

4. 技术基础与生态位

4.1 Function Calling 负责什么

Function Calling 更像模型与应用代码之间的结构化控制接口。

它主要定下三件事：

1. 开发者怎么向模型描述自己有哪些函数可用；
2. 模型怎么返回函数名和结构化参数；
3. 应用怎么把执行结果交还给模型。[S1]

它不负责完整的权限系统、业务执行环境、状态数据库、重试机制，也不管人工审批。这些部分，开发者可以基于 Responses API 自己实现，也可以借助 Agents SDK 管理一部分 Agent 运行逻辑。[S1][S7]

4.2 OpenAI 工具体系中的责任划分

OpenAI 目前的相关组件各司其职，并不是同一回事：

• Function Calling：管模型和开发者函数之间的结构化调用格式；
• Responses API Tools：在同一 API 里把自定义函数、OpenAI 托管工具和外部连接组织起来；
• MCP 与 Connectors：管发现和接入外部服务提供的工具；
• Agents SDK：管 Agent 循环、工具执行、handoff、session、guardrail 和 tracing 这些运行时的逻辑。[S1][S4][S6][S7]

OpenAI 官方文档里明确区分了两种用法：开发者可以自己管理工具分发和多轮状态，也可以用 Agents SDK 去跑 Agent 循环。[S1][S7] 所以，Function Calling 是完整 Agent 系统里的一块基础组件，而不是 Agent 的完整运行环境。

4.3 strict 与 Structured Outputs

函数参数用 JSON Schema 描述。如果开了 strict: true，OpenAI 会通过 Structured Outputs 来约束生成，让返回参数在支持的范围内符合 schema。[S1][S3]

严格模式下，对象必须设 additionalProperties: false，而且所有字段都要列进 required；如果某个字段是可选的，可以允许它取 null。[S1]

Responses API 会尝试把兼容的函数 schema 自动转成严格模式；如果转不了，就可能退回 strict: false 的 best-effort 模式。Chat Completions API 默认还是非严格模式，得由开发者自己显式设成 strict: true。[S1]

严格模式主要保证的是参数结构符合 schema。它不会自动保证：

• 模型选对了工具；
• 参数值在业务语义上是对的；
• 用户确实授权了这项操作；
• 工具的输出真实可信；
• 执行结果符合安全与合规要求。

OpenAI 在 Structured Outputs 发布说明里也明确讲过，结构化输出没法阻止模型在 JSON 字段的内容里出错。[S3]

4.4 工具目录扩张

函数的名称、说明和 schema 会进到模型上下文里，按输入 token 计费。OpenAI 建议一开始同时提供的函数尽量不超过 20 个左右；工具一多，可以用 Tool Search 来延迟加载不常用的工具。[S1]

截至 2026 年 7 月，OpenAI 文档注明 Tool Search 只支持 GPT-5.4 及之后的模型。[S1][S4]

Programmatic Tool Calling 则更进一步，允许模型在隔离的 V8 环境里生成并执行 JavaScript，通过循环、条件判断和并行逻辑把多个工具组合起来。中间结果可以留在程序执行环境内，不必全部重新喂给模型上下文。[S5]

这些机制解决的是大型工具目录和多步调用时的上下文占用、工具选择和编排问题，而不是要取代 Function Calling 本身。

4.5 是否属于开放标准

OpenAI 公开了函数定义、请求字段、返回结构和 schema 约束，但核心模型和托管运行时仍由 OpenAI 自己提供。[S1][S4] 因此，本报告在生态分类上把它归入 protocol-standard，方便和其他工具调用规范做比较，但正文里把它看作厂商定义的 API 接口规范，而不是独立标准组织治理的厂商中立协议。

open_status 记为 partial：接口格式和文档是公开的，但核心模型和服务端实现不开放。

远程 MCP 和 Function Calling 也不是同一层机制。MCP 管外部工具的发现、描述和连接；工具进到 Responses API 之后，模型还是要走工具调用流程去选、去用它们。[S1][S6]

需要说明的是，本报告生态分类上归入 protocol-standard，是为了方便和 MCP、Anthropic Tool Use 等工具调用规范横向比较；但从治理方式看，它同时有厂商私有 API 规范的属性，跨越了“厂商接口”和“事实标准”两层，分类字段没法完整表达这种双重性质。

5. 市场与外部信号

5.1 功能演进

• 2023 年 6 月：OpenAI 发布 Function Calling，通过 Chat Completions API 让模型生成函数名和 JSON 参数。[S2]
• 2024 年 8 月：Structured Outputs 上线，Function Calling 可以通过 strict: true 得到 schema 约束。[S3]
• 2025 年 3 月：OpenAI 发布 Responses API 与 Agents SDK，把自定义函数、托管工具和 Agent 运行能力放进了新的开发体系。[S7][S8]
• 此后到 2026 年 7 月：官方 Tools 文档里又陆续加入了远程 MCP、Tool Search 和 Programmatic Tool Calling 等机制。[S4][S5][S6]

这条时间线说明，Function Calling 并没有被 Responses API 或 Agents SDK 取代，而是继续作为更高层工具体系底下的调用机制。[S1][S4][S7]

5.2 成本模式

Function Calling 本身没有单独的订阅价格。函数名、描述和参数 schema 会占上下文，按所用模型的输入 token 计费；工具结果回传给模型时，也走正常的请求计费。[S1]

OpenAI 的托管工具可能有各自的使用费和存储费，具体看工具种类和当前的价格表。这份报告不把托管工具的费用等同于 Function Calling 自己的定价。

所以，大型工具目录会同时带来准确率和成本的问题：工具越多，模型要处理的描述就越多，输入 token 和选择的难度也可能增加。OpenAI 提供了 Tool Search，并建议减少一开始给出的工具数量。[S1][S4]

5.3 外部生态信号

Anthropic 和 Google 也都采用了类似的基本流程：开发者声明工具，模型出结构化调用，应用执行客户端函数，再把结果交给模型。[S10][S13]

Anthropic 还提供了严格工具输入、Tool Search 和 Programmatic Tool Calling；Google Gemini 有并行调用、连续调用和多种工具选择模式。[S11][S12][S13]

UC Berkeley 的 Berkeley Function Calling Leaderboard（BFCL）把函数调用拆成单轮、并行、多轮和 Agent 任务等来测。它的 ICML 2025 论文将 Function Calling 描述为 Agent 应用的重要基础能力，并建了一套可执行的跨模型评测体系。[S14]

这些资料表明，Function Calling 已经变成一种多家模型平台共同支持的接口模式，只是各家用的 API 格式、托管工具和运行时还不一样。

这次我们没有找到 OpenAI 单独披露 Function Calling 的调用量、企业采用数或开发者留存数据，不能用 OpenAI API 的整体规模来代替这项功能自己的使用情况。

6. 公开评价与主要分歧

目前针对 OpenAI Function Calling API 开发体验和长期生产表现的独立资料有限。外部研究主要测试模型的工具选择、参数正确性、输入稳健性和 Agent 安全，而不是单独统计 OpenAI 接口的商业采用情况。

正面评价（官方 / 同行评审研究）

官方资料： OpenAI 把 strict: true 定位成一种提升参数结构可靠性的机制。它能约束字段名、类型、必填关系和对象结构，减少基础的 JSON 格式错误。[S1][S3]

同行评审研究： BFCL 论文认为，先进模型在单轮函数调用任务上已经表现出较强能力，并通过可执行测试覆盖串行、并行和多轮调用。这项研究为函数调用提供了比单纯检查 JSON 格式更完整的外部评价方法。[S14]

它支持 Function Calling 作为技术路径的实用性，但不能单靠它就证明 OpenAI 的接口在所有生产场景里都比其他平台更可靠。

主要批评与局限（官方自述 / 独立研究）

官方自述： OpenAI 明确说明，Structured Outputs 不能防止参数内容本身出错。开发者仍然需要验证输入、控制权限，并避免让模型去填写可以由代码确定的参数。[S1][S3]

独立研究： IBM Research 的函数调用稳健性研究测试了 GPT-4o-mini、o1-mini 和其他模型。研究发现，改写用户表达以及往工具集里加入语义相近的函数，都会引发不同程度的工具选择或参数错误。[S15]

该论文同时指出，部分“改写后下降”来自现有评测采用严格字符串匹配，而不一定代表调用在语义上完全错误；相比之下，加入相似工具后选错函数或参数属于更直接的能力下降。[S15]

IFEval-FC 进一步测试了参数描述中的格式要求。其预印本报告称，包括 GPT-5 和 Claude Opus 4.1 在内的受测模型仍会忽略大小写、引号、标点和固定格式等要求，并且没有哪个受测模型在全部任务上的准确率超过 80%。[S16]

这些结果说明，参数能通过 JSON Schema，不等于字段内部的自然语言、标识符或业务格式就一定正确。

安全争议（官方）

2023 年发布 Function Calling 时，OpenAI 就已经提醒过，工具返回的不可信内容可能诱导模型做出意料之外的操作；在发邮件、购物、发布内容等真实操作之前，应该让用户确认。[S2]

现在的 Agent 安全文档仍然把 Prompt Injection、隐私数据泄露和误操作列为工具型系统的主要风险。OpenAI 建议收窄工具的权限和数据范围、对敏感工具保留审批，并用结构化输出限制不同步骤之间的数据流。[S6][S9]

OpenAI 也说明，guardrail、结构化输出和审批机制只能降低风险，不能完全杜绝模型犯错或被恶意内容误导的可能。[S9]

存在分歧之处

主要的分歧不在于 Function Calling 有没有用，而在于该用哪一层指标去评价它：

• 官方强调的是 schema 合规和接口的可控性；
• 独立的函数调用研究关注的是工具选没选对、参数语义准不准，以及工具集变化后稳不稳定；
• Agent 安全资料则在问：一次格式正确的调用，是否仍可能越权、泄露信息或执行错误操作。

所以，“参数结构正确”“任务完成正确”和“执行过程安全”是三种不同的评价维度，谁也代替不了谁。

7. 同类对比（与头部 / 高知名度同类项目）

主要对标项目：

• Anthropic Tool Use
• Gemini Function Calling

关键维度对比（事实，标来源）

维度	OpenAI Function Calling / Tools	Anthropic Tool Use	Gemini Function Calling
自定义工具基本流程	模型返回工具名与参数，应用执行后通过调用标识返回结果。[S1]	Claude 返回 tool_use 内容块，应用执行客户端工具后返回 tool_result。[S10]	Gemini 返回函数名称与参数，应用执行后把函数响应交还模型。[S13]
参数描述	使用 JSON Schema；严格模式只支持其中一部分特性。[S1]	input_schema 使用 JSON Schema 描述工具输入。[S10][S11]	Function Declaration 使用 OpenAPI Schema 的一个子集。[S13]
严格参数模式	strict: true；Responses API 会尝试转换兼容 schema，失败时可能退回非严格模式。[S1]	strict: true 用受约束生成保证工具名称和输入符合 schema。[S11]	提供 VALIDATED 工具模式以加强 schema 遵循；截至本次调研，官方文档仍将其标为 Preview。[S13]
工具选择控制	支持自动决定、强制至少调用一个工具、指定函数、限制可用工具及禁止调用。[S1]	支持 auto、any、指定工具和 none 等模式。[S10]	支持 AUTO、ANY、NONE 和 VALIDATED，并可限制允许调用的函数。[S13]
并行及连续调用	自定义函数可一次返回多个调用；当前内置工具不支持并行调用。[S1]	支持并行 Tool Use，SDK Tool Runner 可自动执行客户端工具并返回结果。[S10]	支持并行函数调用和连续调用，即根据前一个工具结果继续请求后续工具。[S13]
大型工具目录	提供 namespace 和 Tool Search；官方建议初始函数尽量少于约 20 个。[S1][S4]	提供 Tool Search，可按需加载工具定义。[S10][S12]	本次核实的 Function Calling 文档重点说明多工具组合，未找到与前两者完全对应的延迟工具加载机制。[S13]
编程式工具编排	Programmatic Tool Calling 可在隔离 V8 环境中生成 JavaScript，组合多个工具。[S5]	Programmatic Tool Calling 可通过代码执行环境生成 Python，组合多个工具。[S12]	Function Calling 文档主要描述并行和连续调用，本次未找到同名的 Programmatic Tool Calling 机制。[S13]
更高层工具体系	Responses API 提供托管工具、远程 MCP 等；Agents SDK 管理 Agent Runtime。[S4][S6][S7]	提供客户端工具、服务器工具、Tool Runner、Tool Search 和代码执行等能力。[S10][S12]	Gemini API 可将内置工具和自定义函数放入同一交互流程。[S13]

三种机制的基本流程已经很接近了：模型管选工具、出参数，应用管执行自定义函数。公开文档里的差异主要集中在严格模式的行为、工具目录的加载方式、托管工具、程序化编排和 SDK 运行时这些方面，而不是支不支持基础的函数调用。[S1][S10][S13]

公开评价中的对比（标源，非个人裁决）

BFCL、IBM 稳健性研究和 IFEval-FC 都会同时测试多家厂商的模型，但结果会随模型版本、端点配置、工具定义和评分方法变化。[S14][S15][S16]

BFCL 论文认为，先进模型在单轮函数调用上已经较强，但记忆管理、动态决策和长任务仍是多家模型共同面对的问题。[S14]

IBM 的研究发现，GPT-4o-mini、o1-mini、Claude 3.5 Haiku 和 Claude 3.5 Sonnet 都会在用户表达变化或工具目录扩张后出现不同程度的错误。[S15] IFEval-FC 也观察到 GPT-5 与 Claude Opus 4.1 未能稳定遵循参数描述中的全部内部格式要求。[S16]

这些研究提供了跨平台观察，但不足以对 OpenAI、Anthropic 和 Gemini 的最新版本做稳定的整体优劣排序。

8. 信息缺口与后续观察

1. 缺少独立的版本化规范。 这次没找到由独立标准组织维护的 OpenAI Function Calling 规范、兼容性认证或多实现一致性测试。

2. 端点行为不完全统一。 Responses API 和 Chat Completions API 的严格模式处理不同，部分工具功能也只在特定模型上才支持。[S1][S4]

3. 独立评测容易过时。 模型和 API 更新很快，测过 GPT-4o、o1 或早期 GPT-5 的研究，不能直接代表后来的模型。

4. 需要把可靠性指标拆开看。 后续实测应该分别记录工具选择准确率、参数结构合规率、参数语义正确率、执行成功率和最终任务完成率。

5. 大型工具目录仍然缺真实数据。 Tool Search 能不能在几百甚至几千个相似的企业工具里稳定选对，要靠生产环境或专门评测来验证。

6. 安全仍然依赖应用实现。 权限控制、幂等、金额上限、人工审批、审计、沙箱和敏感数据过滤，都不是 Function Calling 能自动保证的。

7. 没找到单项采用数据。 这次没找到 Function Calling 独立的调用量、企业客户数或开发者留存数据。

8. 这次没有实测。 后续可以用同一套工具 schema，去测 OpenAI、Anthropic 和 Gemini 在工具选择、严格格式、多轮恢复、错误工具输出和提示注入场景下的表现。

9. 归纳洞察 ★

OpenAI Function Calling 的主要生态位，就是模型和应用代码之间的结构化交接接口。模型说“想调什么、参数是什么”，应用来决定“允不允许、怎么执行、结果可不可信”。它既不是完整的 Agent 运行环境，也不替外部工具协议背全部的责任。

OpenAI 目前的工具体系可以按职责这样看：

• Function Calling 处理结构化调用；
• Responses API 把模型、自定义函数和托管工具统一起来；
• MCP 与 Connectors 处理外部工具的接入；
• Agents SDK 处理循环、状态、handoff、审批辅助和运行追踪。

这也正好说明了，为什么 Responses API 和 Agents SDK 上线之后，Function Calling 依然保留着：上层的运行时还是需要一个底层的工具选择和参数交接机制。

OpenAI、Anthropic 和 Gemini 的基础调用流程已经很接近。三家的差别更多体现在严格模式的具体行为、工具加载方式、托管工具、程序化编排和 SDK 运行时上，而不是基础的“函数调用”这个概念。

strict 把一部分格式检查提前到了模型生成阶段，但并没有消除工具选择、参数语义、用户授权和执行安全的问题。生产系统还是要把模型给出的调用当成需要验证的请求，由确定性的代码来管真实操作。

Tool Search 和 Programmatic Tool Calling 反映出另一个变化：当工具数量和任务步骤变多以后，工程上的难点就不再只是让模型生成一次 JSON，而是怎么管理工具目录、减少上下文占用，并控制好多步执行的过程。Function Calling 是这套体系的基础接口，最终的可靠性仍然来自模型、schema、运行时和业务控制这几块的合力。

10. 来源与更新时间

• 信息截至（as_of）：2026-07-19
• 最后复查（last_checked）：2026-07-19
• 最后更新（last_updated）：未更新