Function Calling，也叫函数调用，是 Agent 调用外部能力的一种结构化机制。开发者把可用工具的名称、用途和参数格式提供给模型，模型根据用户目标判断是否调用、调用哪一个、传什么参数，并输出一段结构化的调用请求。实际的函数、API 或数据库操作由应用程序执行，结果再回传给模型，供它继续推理或生成最终回答。
放到企业级 AI Agent的语境里，Function Calling 是行动接口。它让 Agent 能够查询业务数据、创建工单、发送消息、执行代码，而不只停留在生成文字。它本身不等于 Agent；一个可用的 Agent 还需要任务拆解、状态管理、权限控制、循环终止和结果验证。理解这条边界，企业才能判断一个 Agent 能做什么，风险又落在哪里。
一个客服场景可以说明这个过程。用户问：“我上周的订单怎么还没到？”模型可能输出 get_order({"order_id": "A1024"})。应用程序拿到请求后，先校验参数和权限，再查询订单系统，把物流状态回传给模型。模型看到结果，才回答“包裹已到达上海分拨中心，预计明天送达”。如果用户接着说“那帮我退款”，模型可能继续调用退款工具；是否真的执行，取决于应用程序的权限和确认规则。
Function Calling 的定义与执行边界
Function Calling 让模型用结构化数据表达“要做什么”。开发者先定义工具，通常包括三个部分：
- 名称：工具做什么，例如 `get_order`、`query_metrics`、`create_ticket`。
- 描述：什么时候该用，什么时候不该用，和相邻工具怎么区分。
- 参数：用 JSON Schema 描述字段类型、必填项、取值范围和约束。
下面是一个简化的工具定义：
<code class="language-json">{
"name": "get_order",
"description": "按订单号查询订单状态和物流信息",
"parameters": {
"type": "object",
"properties": {
"order_id": {
"type": "string",
"description": "订单号，例如 A1024"
}
},
"required": ["order_id"]
}
}
</code>模型收到用户问题和这份工具清单后，可能直接回答，也可能输出一个调用请求，例如工具名 get_order、参数 {"order_id": "A1024"}。这段输出遵循约定的结构，应用程序可以稳定解析，不需要从自由文本里猜。
它更像模型和应用程序之间的一份调用契约：模型说明要调什么、传什么，应用程序决定执不执行。边界在于，模型负责生成调用意图，应用程序负责执行。 模型不会直接运行 Python 函数，也不会直接连上企业的订单库。对于企业自定义的工具，参数校验、身份认证、权限判断、超时重试、副作用和审计，通常都发生在模型之外。这个分工让企业可以把执行权留在自己手里，也决定了 Function Calling 的安全设计要覆盖运行时，提示词只能承担其中一部分。
“函数”这个词也不必理解得太窄。被调用的对象可以是一段代码、一个 REST API、一次 SQL 查询、一个内部工单动作，或者一个封装好的业务能力。很多厂商把它称为 Tool Calling，也就是工具调用，范围更宽，除了开发者自定义的函数，还包括模型提供方内置的联网搜索、代码执行，以及通过 MCP 连接的外部工具。MCP 全称 Model Context Protocol，中文常译为模型上下文协议，是一套连接模型与外部工具、数据源的开放协议。
一次 Function Calling 怎么跑完
把一次完整的 Function Calling 拆开，通常会经过五个步骤。
- 声明工具。 应用程序把当前可用的工具、描述和参数 Schema 随请求一起发给模型。工具可以是本轮的少量几个，也可以按业务域分组后动态加载。
- 模型判断。 模型结合用户目标、对话上下文和工具描述，判断是否需要调用工具、调用哪一个，以及参数怎么填。不需要工具时，它直接生成回答。
- 返回调用请求。 需要工具时，模型返回结构化的调用请求，包含工具名和参数。部分模型支持在一次响应里发起多个调用，也就是并行调用。
- 运行时执行。 应用程序或 Agent 运行时解析请求，做参数校验、权限判断和业务规则检查，再执行对应的函数、API 或数据库操作。执行结果会被整理成模型能理解的消息。
- 结果回传，继续循环。 模型读取工具结果，判断信息是否足够。足够就生成最终回答；不够就发起下一次调用。这个循环持续到任务完成、达到步数上限、需要人工确认，或者触发其他终止条件。
图 1：一次 Function Calling 从模型生成调用请求，到运行时执行工具并回传结果的闭环。
三方的分工可以这样看：
| 角色 | 主要职责 | 执行边界 |
|---|---|---|
| 模型 | 理解目标、选择工具、生成参数、根据结果调整下一步 | 只生成调用意图，不执行函数，不直接产生业务副作用 |
| 运行时 | 校验参数、鉴权、执行工具、处理超时和错误、记录日志 | 决定这次调用能不能执行、怎么执行 |
| 工具 | 完成一个明确的查询或动作，例如查订单、跑 SQL、发消息 | 只对自己的输入和输出负责 |
对于企业自定义的工具，执行权和副作用留在应用侧。这是 Function Calling 能被企业采用的前提。 模型可以提议“给这位用户退款”，但是否退款、退多少、要不要人工审批，由运行时和业务规则决定。
为什么 Agent 需要 Function Calling
大语言模型擅长理解语言、归纳信息和生成内容，但企业任务往往需要三样模型本身给不了的东西：实时或私有的数据、确定性的计算、以及会改变外部状态的动作。
Function Calling 把这三类能力接到模型旁边。查订单需要订单系统的数据，算留存率需要 SQL 或分析引擎，发通知、建工单、退款则会改变业务状态。模型负责理解用户要什么，工具负责把事做准，运行时负责守住权限和副作用。
Anthropic 在《Building effective agents》中把 Agent 描述为“由模型动态决定自己的处理过程和工具使用”的系统，并指出 Agent 通常就是“模型基于环境反馈，在循环中使用工具”。Function Calling 的位置由此清晰：它是循环里的行动接口，循环还包括任务拆解、状态管理和终止条件。Agent 也可以通过代码执行、浏览器操作等方式行动，Function Calling 是其中常见的一种接口。
一个可用的 Agent，通常可以分成四层：
- 模型：理解目标，决定下一步。
- 工具：提供查询、计算和动作能力。
- 循环：把工具结果送回模型，直到任务完成或触发停止条件。
- 治理：权限、审批、日志、超时、重试、成本控制和效果验证。
工具数量本身不构成 Agent。单次天气查询只用了一次工具调用，没有持续的计划和调整；一个能自己查订单、判断物流异常、再决定是否退款的客服系统，才更接近 Agent。区别在于谁决定下一步，以及系统能不能根据结果继续行动。
这也解释了工作流和 Agent 的分工。工作流的步骤由代码预先编排，适合稳定、可预测的任务；Agent 由模型动态决定下一步，适合步骤不确定、需要边做边判断的任务。Function Calling 在两者中都能用，差别在于调用发生在固定节点，还是在模型控制的循环里。
| 形态 | 谁决定下一步 | 适合的任务 | Function Calling 的角色 |
|---|---|---|---|
| 固定工作流 | 代码或流程引擎 | 步骤稳定、结果可预测 | 在预设节点调用工具 |
| Agent | 模型 | 步骤不确定、需要根据结果调整 | 循环中的行动接口 |
企业不必为了追求 Agent 形态，把所有流程都改成 Agent。步骤清楚、异常可控的任务，用工作流加少量工具调用往往更稳定，也更容易验证。Anthropic 也建议从最简单的方案开始，只在必要时增加复杂度。Agent 的自主性也带来更高成本和错误累积风险；Anthropic 建议在沙箱环境充分测试，并设置防护栏。这对 Function Calling 的工具权限设计同样适用。
Function Calling、Tool Calling、MCP 有什么区别
Function Calling 经常和 Tool Calling、MCP、Agent、API 一起出现。它们有关系，但不在同一个层面。
| 概念 | 是什么 | 和 Function Calling 的关系 |
|---|---|---|
| Function Calling | 模型生成结构化调用请求的机制 | 讨论对象 |
| Tool Calling | 更广的统称，包含自定义函数、模型内置工具和 MCP 工具 | 实现机制相近，范围更宽 |
| MCP | 连接模型与外部工具、数据源的开放协议 | 负责工具的发现、连接和调用传输 |
| Agent | 模型、工具、循环、状态和治理组成的系统 | Function Calling 是其中的行动接口 |
| API | 应用程序对外提供的接口 | 运行时执行工具时可能调用 API |
Function Calling 和 Tool Calling 在多数文档里可以互换使用。差异主要在范围：Function Calling 更常指开发者自定义的函数，Tool Calling 还包含模型厂商内置的联网搜索、代码执行，以及通过 MCP 接入的外部工具。两者都是模型输出调用意图，由运行时执行。
Function Calling 和 MCP 解决的是不同问题。MCP 规定工具怎么被发现、怎么连接、怎么调用，官方规范里有 tools/list 和 tools/call 这样的消息；Function Calling 解决模型怎么表达“我要调用哪个工具、传什么参数”。两者可以组合：用 MCP 把企业系统暴露成标准工具，再用模型的原生调用能力发起请求。也可以不用 MCP，直接在应用里注册几个函数。
Function Calling 和 Agent 是能力与系统的关系。Function Calling 让模型能调用工具，Agent 还要决定什么时候调用、调用几次、失败怎么办、什么时候停下来。把一次工具调用说成 Agent，会高估系统的自主性；把 Agent 说成一次函数调用，又会低估权限、状态和治理的复杂度。
Function Calling 和 API 也常被混在一起。API 是执行端点，Function Calling 是模型侧的调用意图。模型不因为知道了 API 地址就会正确使用它，工具描述、参数 Schema 和运行时的校验，才是让 API 被可靠调用的关键。
客服场景里，Function Calling 怎么串起来
假设一个电商客服 Agent 要处理“订单没到，想退款”的问题。它可能经历下面几步：
| 步骤 | 谁在行动 | 发生什么 |
|---|---|---|
| 1 | 用户 | 说明订单号和问题 |
| 2 | 模型 | 选择 `get_order`，生成订单号参数 |
| 3 | 运行时 | 校验参数和权限，查询订单系统，返回物流状态 |
| 4 | 模型 | 根据物流结果回答；用户提出退款 |
| 5 | 模型 | 选择 `check_refund_policy`，确认是否符合退款条件 |
| 6 | 运行时 | 执行规则检查；对 `create_refund` 这类写操作发起人工确认 |
| 7 | 模型 | 根据退款结果告知用户进度和到账时间 |
这个例子里，查询类工具可以自动执行，退款类工具则要经过更严格的权限和确认。读操作和写操作的风险不同，工具设计也应该分级。 查询失败通常只影响一次回答，退款、扣款、发消息、改配置失败，可能带来真实的业务损失。
流程走到这里，Function Calling 的作用已经超出一次 API 调用。它把一次服务拆成可观察的步骤：模型选了什么工具、传了什么参数、运行时有没有拒绝、工具返回了什么、用户有没有确认。这些记录既能用于排错，也能用于审计和效果评估。
企业落地 Function Calling，哪些环节决定效果
把 Function Calling 接进企业系统并不难，难的是让它稳定、可控、可验证。下面几件事比支持多少种模型更影响最终效果。
工具描述决定模型选得对不对
工具描述是模型选择工具的主要依据。名称要能表达动作，描述要说明什么时候用、什么时候不用、和相邻工具怎么区分，参数要写清类型、必填项、取值范围和例子。Anthropic 在工具设计建议中提到，工具定义值得投入和提示词同等的工程精力，并且要用大量真实输入测试模型会不会选错。
一个反例是叫 query_data 的工具，描述只写“查询数据”。模型很难判断它查的是订单、用户还是指标，也很容易和另一个 search_data 搞混。更清楚的写法是 query_game_daily_active_users，描述里写明按游戏 ID 和日期范围查询日活跃用户数，最多返回 90 天。名称和描述越具体，模型的选择空间越窄，误调用就越少。
工具粒度也要控制。一个工具只做一件边界清楚的事，避免做成“什么都能干”的大接口。工具太多、描述太像时，模型会在相似选项之间摇摆，调用准确率下降，排查也更困难。
读写工具要分级授权
企业可以把工具分成只读和写入两类。只读工具包括查订单、查库存、查指标、检索知识库；写入工具包括退款、扣款、发消息、建工单、改配置、删除数据。只读工具可以在较小权限下自动执行，写入工具则需要更严格的授权、确认和审计。
MCP 规范在工具章节中建议，始终保留一个能够拒绝工具调用的人在回路中，对敏感操作向用户展示输入并请求确认。这个建议同样适用于自建 Agent。模型可以提出“我要退款”，系统要判断当前用户有没有这个权限、金额是否超限、是否需要主管审批。
权限控制要落在服务端，不能只靠提示词。 给模型一个高权限数据库账号，再用提示词要求它“不要删数据”，这种做法的防护能力有限。更稳妥的方式是使用范围受限的凭据、行级权限、租户隔离和操作白名单，把危险动作挡在执行之前。
参数校验、错误处理和幂等
模型生成的参数应当被视为不可信输入。运行时需要检查类型、必填项、长度、范围和业务规则，再决定是否执行。微软的 .NET AI 文档也提醒，模型可能编造工具定义里没有描述的参数，应用层不能假设输出一定正确。
错误信息要能让模型理解并采取下一步。比如订单号不存在时，返回“未找到订单 A1024，请确认是否为 8 位订单号”，模型就可以追问用户；只返回一个“500 错误”，模型很难判断该重试、换工具还是结束。对于写操作，还要考虑幂等键、超时和重试上限，避免一次退款请求被执行两次。
MCP 规范把错误分成协议错误和工具执行错误两类，前者包括未知工具、无效参数、服务器错误，后者包括 API 失败、无效输入和业务逻辑错误。这个划分值得借鉴：不同错误对应不同的恢复策略，不要把所有人都导向“再试一次”。
工具数量要控制，避免占满上下文
工具定义会随请求一起发送，占用模型的上下文和 token。 工具越多，说明越长，成本和选择难度都会上升。微软的文档明确提到，工具描述会计入请求的 token 限制；如果接近上限，可以减少注册的工具数量、缩短名称和描述，或者只保留当前对话相关的工具。
工具数量上来之后，可以按业务域分组，例如订单、营销、财务、知识库各自成组，只暴露当前任务需要的组。OpenAI 在其 Agents SDK 文档中给出的经验法则是，每个命名空间尽量少于 10 个函数；工具特别多时，可以用工具搜索按需加载，只把当前任务需要的工具放进上下文。
调用链要可观测，才能定位问题
Function Calling 出错时，原因可能有很多层：模型选错工具、参数填错、运行时权限拒绝、工具超时、返回数据格式变化、模型误解了结果。只记录最终回答，很难判断问题出在哪一步。
可观测性至少要覆盖工具名、参数、执行结果摘要、耗时、token 使用、错误类型和 trace ID。更进一步，要把一次用户会话中的模型调用、工具调用和最终结果串起来，区分模型错误、工具错误、权限错误和数据错误。这样调整工具描述、权限规则或重试策略时，才有依据。
以 ThinkingAI 为例，Agentic Engine 支持多 Agent 协作和私有化部署，已服务全球超 1500 家企业、接入产品超 8000 款。其 Agentic SDK 通过 Trace 采集调用关系、执行状态、耗时和 Token 使用等结构化数据。Trace 记录了一次任务从模型调用到工具执行的完整链路。Agent 观测平台 AI Monitor 再从失败、长耗时、异常 Trace 和 Token 波动中聚合问题，并下钻到单次调用核对证据。对于要把 Function Calling 从演示推到生产的企业，这类能力决定了问题能不能被看见、被定位、被复核。
工具结果也要校验
工具返回的内容同样需要校验。 外部网页、用户上传的文件、第三方 API 的响应，都可能包含未经确认的指令或不可信内容。模型读到这些内容后，可能被引导去调用不该调用的工具，或者把敏感数据带到不该去的地方。
MCP 规范的安全建议包括：对敏感操作向用户确认，在调用前展示工具输入，在把工具结果传给模型前做验证，为工具调用设置超时，并记录使用情况以便审计。企业还可以限制工具的网络访问范围、文件访问范围和可写资源，把高风险动作放在隔离环境里执行。
FAQ
Function Calling 和 Tool Calling 是一回事吗？
实现机制相近，很多文档会混用。Tool Calling 的范围更宽，除了开发者自定义的函数，还包括模型厂商内置的联网搜索、代码执行，以及通过 MCP 接入的外部工具。Function Calling 更常指自定义函数的调用。
模型会自己执行函数吗？
不会。模型只输出结构化的调用请求，包含工具名和参数。实际的执行发生在应用程序或 Agent 运行时，参数校验、权限判断、超时重试和副作用都在那里完成。这个边界是理解 Function Calling 安全设计的关键。
Function Calling 和 Agent 是什么关系？
Function Calling 是 Agent 的行动接口，Agent 是更完整的系统。一个 Agent 还要负责任务拆解、循环控制、状态管理、权限、审批和效果验证。单次工具调用可以增强一次问答，但不一定构成 Agent。
Function Calling 和 MCP 是什么关系？
MCP 是工具连接和发现的协议，Function Calling 是模型发起调用的机制。MCP 让企业系统以标准方式暴露工具，Function Calling 让模型表达要调用哪个工具、传什么参数。两者可以组合使用，也可以各自独立存在。
所有大模型都支持 Function Calling 吗？
主流模型厂商普遍提供这项能力，但支持范围不同。参数格式、并行调用、严格 Schema、内置工具和工具搜索等细节，可能因模型和 API 而异。选型时要看具体模型的官方文档，不要假设所有模型的行为一致。
企业第一个 Function Calling 场景怎么选？
优先选高频、低风险、结果可验证的只读场景，例如订单查询、指标查询、知识检索。先把工具描述、参数校验、权限和日志跑通，再扩展到退款、发消息、改配置等写操作。写操作上线前，确认人工审批、幂等和回滚方案。
参考资料
- Anthropic Engineering，《Building effective agents》，https://www.anthropic.com/engineering/building-effective-agents，访问日期 2026-11-07。
- Model Context Protocol，《工具》，协议版本 2025-11-25，https://modelcontextprotocol.info/zh-cn/specification/2025-11-25/server/tools/，访问日期 2026-11-07。
- Microsoft Learn，《Understanding OpenAI function calling》，https://learn.microsoft.com/en-us/dotnet/ai/conceptual/understanding-openai-functions，访问日期 2026-11-07。
- OpenAI Agents SDK，《Tools》，https://openai.github.io/openai-agents-python/tools/，访问日期 2026-11-07。
- 腾讯云开发者社区技术百科，《结构化工具调用》，https://cloud.tencent.cn/developer/techpedia/2719，访问日期 2026-11-07。
