大语言模型已经能够回答问题、总结文档、编写代码甚至帮助人们分析复杂业务。但如果让它查询一笔真实订单的退款状态或者修改数据库中的某条记录仅仅依靠模型本身就不够了。例如用户问“我的订单 20261030001 退款成功了吗”模型可以理解这个问题也能生成一句“我来帮你查询”。但它真的知道这笔订单是否退款成功吗不知道。因为真实的订单状态保存在企业的业务系统中而不是模型能够凭空获取的信息。要让模型真正使用外部系统就需要一种机制让模型能够识别可用工具、选择合适的工具并提出规范的调用请求。这就是 Function Calling 要解决的问题。一、Function Calling让模型能够提出工具调用请求Function Calling也常称为 Tool Calling是一种让大语言模型通过结构化请求使用外部工具的机制。它改变了传统 AI 应用只能输入问题、输出文字的交互方式。过去用户提问 → 模型生成文字 → 用户自行操作。引入 Function Calling 后用户提问 → 模型选择工具 → 应用程序执行工具 → 返回结果 → 模型生成回答。这里需要先明确一个容易产生的误解Function Calling 并不是让模型直接执行代码而是让模型按照约定的格式提出工具调用请求。真正执行代码、访问数据库和调用业务接口的仍然是外部应用程序或工具服务。例如用户询问退款状态系统可以提供一个工具get_refund_status它的作用是根据订单编号查询退款状态。模型识别到用户需要查询订单就可以提出调用这个工具的请求。但这时数据库还没有被查询。应用程序还需要接收请求并执行对应的操作。二、模型怎么知道自己有哪些工具这是 Function Calling 中非常关键的一环。模型并不会自动发现开发人员编写的 Java 方法也不知道企业系统中有哪些 API。工具需要提前定义再由应用程序提供给模型。一个工具通常需要描述三个方面工具名称它叫什么工具描述它能做什么什么时候应该使用参数结构调用它需要提供什么信息例如{name:get_refund_status,description:根据订单编号查询退款状态,parameters:{type:object,properties:{order_id:{type:string,description:需要查询的订单编号}},required:[order_id]}}这段定义相当于一份工具说明书。模型能够知道有一个叫get_refund_status的工具。它用于查询退款状态。使用时需要提供order_id。但这份定义本身并不包含查询数据库的具体代码。工具定义与工具实现是两个不同的东西。工具定义通常放在哪里常见的方式有两种。第一种应用程序自己注册工具。例如Java 应用程序中维护一个工具注册表工具注册表 | -- get_refund_status | | | -- 查询退款状态 | -- get_order_detail | | | -- 查询订单详情 | -- cancel_order | -- 取消订单应用程序在请求模型时将当前允许使用的工具定义一并提供。第二种通过 MCP Server 提供工具。MCP Server 可以注册并暴露自己提供的工具。AI 应用通过 MCP Client 连接 Server使用tools/list获取工具名称、描述和参数结构再由应用的集成层将这些工具提供给模型。这样开发人员不必为每个 AI 应用重新编写一套完全不同的外部工具连接方式。需要注意MCP 工具清单如何转换成模型能够使用的工具定义具体取决于 AI 应用和模型平台的集成方式。三、模型选择工具后究竟发生了什么继续使用退款查询的例子。用户提出“查询订单 20261030001 的退款状态。”应用程序已经向模型提供了可用工具及其参数定义。模型根据用户意图可能生成这样的调用请求{name:get_refund_status,arguments:{order_id:20261030001}}这意味着模型认为应该使用get_refund_status并且已经生成了需要的参数。但是模型并没有真正访问退款数据库。接下来由应用程序接管。完整调用过程第一步模型选择工具。根据用户的问题模型判断需要查询退款状态于是选择get_refund_status。第二步生成参数。模型从用户的问题中提取订单编号生成符合工具定义的参数。第三步应用程序接收请求。应用程序检查工具名称是否存在、参数是否符合要求以及当前用户是否有权限执行该操作。第四步找到真正的执行入口。如果工具是应用程序本地注册的就调用对应的程序实现。如果工具来自 MCP Server应用程序则根据工具注册映射找到对应的 MCP Client 和 Server。第五步执行真实业务操作。工具执行器调用业务 API 或查询数据库获得真实退款状态。第六步返回结果。应用程序将工具执行结果交还给模型模型再根据真实结果生成自然语言回答。整个过程可以简化为用户提出问题 | v 应用程序提供工具定义 | v 大语言模型选择工具 | v 生成 Function Calling 请求 | v 应用程序校验并路由 | v 调用工具执行器 | v 业务 API / 数据库 | v 返回真实结果 | v 模型组织最终回答这里有一个非常重要的职责边界模型负责选择工具应用程序负责找到工具的执行入口工具服务负责完成实际操作。模型选择的是工具名称并不直接管理 MCP Server 的网络连接。四、Function Calling、API、Tool 和 MCP 有什么区别这几个概念经常一起出现但它们解决的问题并不相同。1. API业务系统对外提供的接口APIApplication Programming Interface应用程序编程接口是不同软件系统之间进行交互的一种方式。例如订单系统可以提供一个退款查询接口GET /api/orders/20261030001/refund-status这个接口可以让其他程序查询订单退款状态。API 是业务系统提供的能力入口但它本身并不负责判断大模型应该什么时候调用。2. Tool提供给模型使用的工具Tool 可以理解为对某项外部能力的封装。例如get_refund_status它可能在内部调用一个 HTTP API也可能调用多个接口甚至执行一段本地程序。因此一个 Tool 不一定只对应一个 API。3. Function Calling模型提出工具调用请求的机制它解决的是模型如何表达“我想调用哪个工具需要传入哪些参数”模型返回的通常是结构化的调用信息而不是直接执行结果。4. MCP标准化的工具连接协议MCPModel Context Protocol模型上下文协议主要解决 AI 应用如何以统一方式发现和调用外部能力。例如MCP Server 暴露工具。MCP Client 连接 Server。Client 可以获取工具清单。调用时通过协议向对应 Server 发出请求。Server 执行工具并返回结果。两者可以配合使用但并不是必须绑定。概念主要解决的问题API业务系统如何对外提供能力Tool如何把某项能力包装成可调用的工具Function Calling模型如何提出工具调用请求MCPAI 应用如何标准化地发现和调用外部工具例如Function Calling 可以调用 Java 应用程序中的本地方法也可以让应用程序通过 HTTP 调用业务 API不一定需要 MCP。而使用 MCP 时MCP Server 提供的工具也可以被 AI 应用转换成模型可使用的工具定义。它们是可以组合的技术而不是相互替代的产品。五、Agent 和 Workflow 在工具调用中负责什么Function Calling 解决了模型如何提出工具调用请求但实际任务往往不止一次工具调用。例如“查询退款状态如果退款失败帮我重新发起退款。”这个任务至少涉及两个动作查询退款状态。根据查询结果决定是否需要重新发起退款。此时还需要理解 Agent 和 Workflow 的职责。Agent 负责理解目标和判断下一步。它可以根据用户需求分析是否需要查询退款状态以及查询结果是否需要进一步处理。Workflow 负责定义和约束执行流程。例如查询退款状态 | v 判断是否退款失败 | v 检查是否满足退款条件 | v 人工审批 | v 调用退款接口 | v 验证最终结果Function Calling 在这个过程中负责让模型提出工具调用请求。MCP 可以提供外部工具的连接能力。Agent 和 Workflow 则负责更高层次的任务判断与流程控制。需要注意Agent 并不意味着可以任意调用所有工具。应用程序仍然需要控制工具范围、权限和执行条件。六、为什么不能让模型直接执行所有操作模型能够提出工具调用请求并不代表它提出的请求一定正确。例如用户要求查询退款状态但模型生成了错误的订单编号。或者用户要求查询订单模型却选择了取消订单的工具。如果系统不进行检查模型的一次错误判断就可能产生真实业务影响。因此Function Calling 只是打通了模型与外部能力之间的调用机制并没有自动解决安全问题。实际系统至少需要考虑以下几个方面。1. 参数校验模型生成的参数不一定符合要求。例如订单编号不能为空金额必须大于零状态值必须属于允许范围。这些条件应由程序进行校验而不是完全依赖模型理解。2. 身份和权限校验不能因为模型生成了一个tenant_id就认为用户有权访问该租户的数据。用户身份应该从服务端可信的登录态中获取权限也应该由后端授权系统判断。模型可以提出请求但不能自行授予权限。3. 查询操作与修改操作分开查询退款状态和重新发起退款虽然都与退款有关但风险完全不同。查询通常不会修改业务数据而重新发起退款可能直接影响资金。因此涉及退款、支付、删除、发布等有副作用的操作应根据风险设置额外的授权、审批和执行限制。4. 防止重复执行假设退款接口已经执行成功但网络响应超时。此时模型或应用程序如果直接重试就可能造成重复操作。系统需要通过幂等机制、业务流水号和状态核实等方式确认操作是否已经完成。5. 保留调用记录实际系统还需要记录谁发起了请求模型选择了哪个工具使用了什么参数工具是否执行成功返回了什么结果是否经过人工审批这些记录可以帮助系统定位问题也方便后续审计。七、Function Calling 适合解决什么问题并不是所有 AI 任务都需要调用工具。如果用户只是询问一个概念模型通常可以直接回答。但当任务需要获取实时数据、访问外部系统或者执行真实操作时工具调用就变得重要。业务场景是否适合工具调用原因解释什么是 Redis通常不需要模型可以直接生成知识性回答总结一份文章通常不需要用户已经提供了内容查询订单退款状态需要必须读取真实业务数据查询当前库存需要必须访问业务系统提交退款申请需要涉及真实业务操作查询用户是否有退款资格视情况而定可以通过确定性业务规则判断一个好的 AI 系统不是让模型接管所有程序而是让模型在适合的地方使用外部能力。八、总结Function Calling 是连接模型与外部能力的关键机制理解 Function Calling需要把几个概念分开API 提供真实业务能力。Tool 把能力包装成模型可以使用的工具。Function Calling 让模型能够选择工具并生成结构化调用请求。MCP 为 AI 应用提供标准化的工具发现与调用协议。Agent 负责理解任务和判断下一步。Workflow 负责约束执行顺序和处理规则。它们组合起来才能让大语言模型从单纯生成文字逐步具备使用外部业务能力的能力。但必须记住模型提出调用请求不等于业务操作已经执行工具执行成功也不等于业务目标一定完成。真正可靠的 AI 应用既需要模型理解用户意图也需要程序控制工具执行、权限校验、异常处理和结果验证。这才是从“会聊天的 AI”走向“能够参与真实业务的 AI 系统”的关键一步。参考资料OpenAI 官方文档Function calling——介绍工具定义、参数 Schema、模型生成工具调用请求以及应用程序执行并返回结果的完整过程。Model Context Protocol 官方文档Build your first client——介绍 MCP Client 如何连接 Server、获取工具列表和调用工具。OpenAI 官方文档Using tools——介绍 Function Calling、远程 MCP 等工具接入方式。 
长河君 · 2026/11/6 1:49:39 · 阅读 1.2k Function Calling 是什么？大模型如何从“会回答”走向“会调用工具”？
大语言模型已经能够回答问题、总结文档、编写代码甚至帮助人们分析复杂业务。但如果让它查询一笔真实订单的退款状态或者修改数据库中的某条记录仅仅依靠模型本身就不够了。例如用户问“我的订单 20261030001 退款成功了吗”模型可以理解这个问题也能生成一句“我来帮你查询”。但它真的知道这笔订单是否退款成功吗不知道。因为真实的订单状态保存在企业的业务系统中而不是模型能够凭空获取的信息。要让模型真正使用外部系统就需要一种机制让模型能够识别可用工具、选择合适的工具并提出规范的调用请求。这就是 Function Calling 要解决的问题。一、Function Calling让模型能够提出工具调用请求Function Calling也常称为 Tool Calling是一种让大语言模型通过结构化请求使用外部工具的机制。它改变了传统 AI 应用只能输入问题、输出文字的交互方式。过去用户提问 → 模型生成文字 → 用户自行操作。引入 Function Calling 后用户提问 → 模型选择工具 → 应用程序执行工具 → 返回结果 → 模型生成回答。这里需要先明确一个容易产生的误解Function Calling 并不是让模型直接执行代码而是让模型按照约定的格式提出工具调用请求。真正执行代码、访问数据库和调用业务接口的仍然是外部应用程序或工具服务。例如用户询问退款状态系统可以提供一个工具get_refund_status它的作用是根据订单编号查询退款状态。模型识别到用户需要查询订单就可以提出调用这个工具的请求。但这时数据库还没有被查询。应用程序还需要接收请求并执行对应的操作。二、模型怎么知道自己有哪些工具这是 Function Calling 中非常关键的一环。模型并不会自动发现开发人员编写的 Java 方法也不知道企业系统中有哪些 API。工具需要提前定义再由应用程序提供给模型。一个工具通常需要描述三个方面工具名称它叫什么工具描述它能做什么什么时候应该使用参数结构调用它需要提供什么信息例如{name:get_refund_status,description:根据订单编号查询退款状态,parameters:{type:object,properties:{order_id:{type:string,description:需要查询的订单编号}},required:[order_id]}}这段定义相当于一份工具说明书。模型能够知道有一个叫get_refund_status的工具。它用于查询退款状态。使用时需要提供order_id。但这份定义本身并不包含查询数据库的具体代码。工具定义与工具实现是两个不同的东西。工具定义通常放在哪里常见的方式有两种。第一种应用程序自己注册工具。例如Java 应用程序中维护一个工具注册表工具注册表 | -- get_refund_status | | | -- 查询退款状态 | -- get_order_detail | | | -- 查询订单详情 | -- cancel_order | -- 取消订单应用程序在请求模型时将当前允许使用的工具定义一并提供。第二种通过 MCP Server 提供工具。MCP Server 可以注册并暴露自己提供的工具。AI 应用通过 MCP Client 连接 Server使用tools/list获取工具名称、描述和参数结构再由应用的集成层将这些工具提供给模型。这样开发人员不必为每个 AI 应用重新编写一套完全不同的外部工具连接方式。需要注意MCP 工具清单如何转换成模型能够使用的工具定义具体取决于 AI 应用和模型平台的集成方式。三、模型选择工具后究竟发生了什么继续使用退款查询的例子。用户提出“查询订单 20261030001 的退款状态。”应用程序已经向模型提供了可用工具及其参数定义。模型根据用户意图可能生成这样的调用请求{name:get_refund_status,arguments:{order_id:20261030001}}这意味着模型认为应该使用get_refund_status并且已经生成了需要的参数。但是模型并没有真正访问退款数据库。接下来由应用程序接管。完整调用过程第一步模型选择工具。根据用户的问题模型判断需要查询退款状态于是选择get_refund_status。第二步生成参数。模型从用户的问题中提取订单编号生成符合工具定义的参数。第三步应用程序接收请求。应用程序检查工具名称是否存在、参数是否符合要求以及当前用户是否有权限执行该操作。第四步找到真正的执行入口。如果工具是应用程序本地注册的就调用对应的程序实现。如果工具来自 MCP Server应用程序则根据工具注册映射找到对应的 MCP Client 和 Server。第五步执行真实业务操作。工具执行器调用业务 API 或查询数据库获得真实退款状态。第六步返回结果。应用程序将工具执行结果交还给模型模型再根据真实结果生成自然语言回答。整个过程可以简化为用户提出问题 | v 应用程序提供工具定义 | v 大语言模型选择工具 | v 生成 Function Calling 请求 | v 应用程序校验并路由 | v 调用工具执行器 | v 业务 API / 数据库 | v 返回真实结果 | v 模型组织最终回答这里有一个非常重要的职责边界模型负责选择工具应用程序负责找到工具的执行入口工具服务负责完成实际操作。模型选择的是工具名称并不直接管理 MCP Server 的网络连接。四、Function Calling、API、Tool 和 MCP 有什么区别这几个概念经常一起出现但它们解决的问题并不相同。1. API业务系统对外提供的接口APIApplication Programming Interface应用程序编程接口是不同软件系统之间进行交互的一种方式。例如订单系统可以提供一个退款查询接口GET /api/orders/20261030001/refund-status这个接口可以让其他程序查询订单退款状态。API 是业务系统提供的能力入口但它本身并不负责判断大模型应该什么时候调用。2. Tool提供给模型使用的工具Tool 可以理解为对某项外部能力的封装。例如get_refund_status它可能在内部调用一个 HTTP API也可能调用多个接口甚至执行一段本地程序。因此一个 Tool 不一定只对应一个 API。3. Function Calling模型提出工具调用请求的机制它解决的是模型如何表达“我想调用哪个工具需要传入哪些参数”模型返回的通常是结构化的调用信息而不是直接执行结果。4. MCP标准化的工具连接协议MCPModel Context Protocol模型上下文协议主要解决 AI 应用如何以统一方式发现和调用外部能力。例如MCP Server 暴露工具。MCP Client 连接 Server。Client 可以获取工具清单。调用时通过协议向对应 Server 发出请求。Server 执行工具并返回结果。两者可以配合使用但并不是必须绑定。概念主要解决的问题API业务系统如何对外提供能力Tool如何把某项能力包装成可调用的工具Function Calling模型如何提出工具调用请求MCPAI 应用如何标准化地发现和调用外部工具例如Function Calling 可以调用 Java 应用程序中的本地方法也可以让应用程序通过 HTTP 调用业务 API不一定需要 MCP。而使用 MCP 时MCP Server 提供的工具也可以被 AI 应用转换成模型可使用的工具定义。它们是可以组合的技术而不是相互替代的产品。五、Agent 和 Workflow 在工具调用中负责什么Function Calling 解决了模型如何提出工具调用请求但实际任务往往不止一次工具调用。例如“查询退款状态如果退款失败帮我重新发起退款。”这个任务至少涉及两个动作查询退款状态。根据查询结果决定是否需要重新发起退款。此时还需要理解 Agent 和 Workflow 的职责。Agent 负责理解目标和判断下一步。它可以根据用户需求分析是否需要查询退款状态以及查询结果是否需要进一步处理。Workflow 负责定义和约束执行流程。例如查询退款状态 | v 判断是否退款失败 | v 检查是否满足退款条件 | v 人工审批 | v 调用退款接口 | v 验证最终结果Function Calling 在这个过程中负责让模型提出工具调用请求。MCP 可以提供外部工具的连接能力。Agent 和 Workflow 则负责更高层次的任务判断与流程控制。需要注意Agent 并不意味着可以任意调用所有工具。应用程序仍然需要控制工具范围、权限和执行条件。六、为什么不能让模型直接执行所有操作模型能够提出工具调用请求并不代表它提出的请求一定正确。例如用户要求查询退款状态但模型生成了错误的订单编号。或者用户要求查询订单模型却选择了取消订单的工具。如果系统不进行检查模型的一次错误判断就可能产生真实业务影响。因此Function Calling 只是打通了模型与外部能力之间的调用机制并没有自动解决安全问题。实际系统至少需要考虑以下几个方面。1. 参数校验模型生成的参数不一定符合要求。例如订单编号不能为空金额必须大于零状态值必须属于允许范围。这些条件应由程序进行校验而不是完全依赖模型理解。2. 身份和权限校验不能因为模型生成了一个tenant_id就认为用户有权访问该租户的数据。用户身份应该从服务端可信的登录态中获取权限也应该由后端授权系统判断。模型可以提出请求但不能自行授予权限。3. 查询操作与修改操作分开查询退款状态和重新发起退款虽然都与退款有关但风险完全不同。查询通常不会修改业务数据而重新发起退款可能直接影响资金。因此涉及退款、支付、删除、发布等有副作用的操作应根据风险设置额外的授权、审批和执行限制。4. 防止重复执行假设退款接口已经执行成功但网络响应超时。此时模型或应用程序如果直接重试就可能造成重复操作。系统需要通过幂等机制、业务流水号和状态核实等方式确认操作是否已经完成。5. 保留调用记录实际系统还需要记录谁发起了请求模型选择了哪个工具使用了什么参数工具是否执行成功返回了什么结果是否经过人工审批这些记录可以帮助系统定位问题也方便后续审计。七、Function Calling 适合解决什么问题并不是所有 AI 任务都需要调用工具。如果用户只是询问一个概念模型通常可以直接回答。但当任务需要获取实时数据、访问外部系统或者执行真实操作时工具调用就变得重要。业务场景是否适合工具调用原因解释什么是 Redis通常不需要模型可以直接生成知识性回答总结一份文章通常不需要用户已经提供了内容查询订单退款状态需要必须读取真实业务数据查询当前库存需要必须访问业务系统提交退款申请需要涉及真实业务操作查询用户是否有退款资格视情况而定可以通过确定性业务规则判断一个好的 AI 系统不是让模型接管所有程序而是让模型在适合的地方使用外部能力。八、总结Function Calling 是连接模型与外部能力的关键机制理解 Function Calling需要把几个概念分开API 提供真实业务能力。Tool 把能力包装成模型可以使用的工具。Function Calling 让模型能够选择工具并生成结构化调用请求。MCP 为 AI 应用提供标准化的工具发现与调用协议。Agent 负责理解任务和判断下一步。Workflow 负责约束执行顺序和处理规则。它们组合起来才能让大语言模型从单纯生成文字逐步具备使用外部业务能力的能力。但必须记住模型提出调用请求不等于业务操作已经执行工具执行成功也不等于业务目标一定完成。真正可靠的 AI 应用既需要模型理解用户意图也需要程序控制工具执行、权限校验、异常处理和结果验证。这才是从“会聊天的 AI”走向“能够参与真实业务的 AI 系统”的关键一步。参考资料OpenAI 官方文档Function calling——介绍工具定义、参数 Schema、模型生成工具调用请求以及应用程序执行并返回结果的完整过程。Model Context Protocol 官方文档Build your first client——介绍 MCP Client 如何连接 Server、获取工具列表和调用工具。OpenAI 官方文档Using tools——介绍 Function Calling、远程 MCP 等工具接入方式。