Function Calling：大语言模型连接业务系统的关键能力
定义 (Definition)
Function Calling（函数调用），也称为 Tool Calling（工具调用），是指大语言模型（LLM）与外部工具、API 或系统进行交互的能力。具备这一能力的模型不再仅依赖预训练知识生成回复，而是可以查询数据库、获取实时信息、执行函数并完成超越其原生能力的复杂操作。
IBM 对此给出了清晰的定义："Tool calling refers to the ability of artificial intelligence (AI) models to interact with external tools, application programming interfaces (APIs) or systems to enhance their functions." 这一能力是 LLM 从被动文本生成器转变为主动数字代理的关键转折点。
需要注意的是，Function Calling 和 Tool Calling 在业界通常作为同义词使用。OpenAI 在 2023 年首次推出此功能时使用 "Function Calling"，随着生态成熟，行业趋势趋向使用更宽泛的 "Tool Calling" 术语。本文中两个术语含义相同。
边界 (Boundary)
Function Calling 不是：
- 不是 AI Agent 本身。 Function Calling 是 Agent 的一个关键能力组件——让模型能够调用外部工具。但一个完整的 Agent 还需要规划能力、记忆机制和循环控制。Agent = Model + Harness（框架），其中 Harness 包含 prompt、tools 和 middleware。
- 不是传统的 API 集成。 传统 API 集成需要开发人员硬编码调用逻辑（何时调用、传什么参数）。Function Calling 由模型在推理过程中自主决定是否需要调用工具、选择哪个工具、构造什么参数。
- 不是 RAG 的替代。 RAG（检索增强生成）关注的是从知识库中检索信息以增强生成的上下文。Function Calling 关注的是让模型执行操作。两者互补：将 Tool Calling 与 RAG 结合，可以让系统在生成响应前同时检索结构化和非结构化数据，减少 API 开销，降低延迟和成本。
- 不是 Prompt Engineering 的延伸。 Prompt Engineering 优化的是模型的文本输出质量。Function Calling 改变的是模型的交互模式——从"只说"变成"能做"。
常见误解 (Misconceptions)
误解一："Function Calling 意味着 AI 可以执行任意代码。"
不准确。Function Calling 的本质是模型输出结构化的调用请求（包含工具名称和参数），真正的执行由外部运行时（runtime）完成。模型本身不直接执行代码——它生成的是"调用意图"，由宿主程序决定是否执行、如何执行。这种设计既保证了灵活性，也提供了安全控制点。
误解二："只有 OpenAI 的模型支持 Function Calling。"
事实并非如此。现代主流 LLM 包括 Anthropic Claude、Meta Llama 3、Mistral 和 IBM Granite 都具备 Tool Calling 能力。不同模型的实现方式有差异，但核心概念一致：模型识别何时需要外部工具，选择合适的工具，输出结构化参数。OpenAI 是最早推广此能力的厂商，但该能力已成为行业标配。
误解三："有了 Function Calling，就不需要写代码了。"
恰恰相反，Function Calling 增加了对工程能力的要求。开发者需要定义工具的 schema（名称、描述、参数类型），实现工具的执行逻辑，处理模型输出和工具结果之间的格式转换，以及管理多步骤调用链。框架如 LangChain 可以简化这些工作，但不会消除工程需求。
工作原理
Function Calling 的完整流程包含以下步骤：
-
识别需求：模型通过自然语言理解，判断当前请求是否需要它自身不具备的能力（如实时数据、外部计算、业务系统操作）。每个工具调用请求会被分配一个唯一的 tool call ID，用于追踪请求与结果的对应关系。
-
选择工具：模型从可用的工具列表中选择最合适的工具。每个工具包含结构化元数据——工具名称、描述、参数定义和输入输出类型。模型基于这些元数据做出选择。
-
构建请求：模型生成符合工具 API 规范的结构化请求，包括所需的参数值。这一步要求模型输出的格式精确匹配目标 API 的 schema。
-
执行与接收：宿主程序接收模型的结构化请求，执行实际的外部调用（如 HTTP 请求、数据库查询），并将结果以机器可读格式（通常为 JSON）返回给模型。
-
处理与响应：模型解析工具返回的数据，将其整合进自然语言回复中，以有意义的方式呈现给用户。
-
迭代细化：如果用户追问或需要更多信息，模型可以基于上下文发起新的工具调用，逐步细化响应。
应用场景
Function Calling 在企业环境中的五大典型应用类型：
- 信息检索与搜索：从新闻源、学术数据库、金融市场获取实时数据。例如客户询问产品库存时，AI 调用 ERP 系统的查询接口返回实时库存状态。
- 代码执行：调用数学引擎（如 Wolfram Alpha）或 Python 运行环境执行复杂计算、运行模拟或处理数据。
- 流程自动化：与 CRM（如 Salesforce）、财务系统（如 QuickBooks）、日历和邮件平台集成，自动化数据录入、报告生成、会议调度等业务流程。
- 智能设备与 IoT 监控：监控和控制工业 IoT 设备、家居自动化系统。未来可扩展到端到端的自主运维工作流。
- 多步骤组合工作流：将多个工具按顺序串联，完成复合任务。例如先查询客户信息，再检查订单状态，最后生成个性化回复。
与 LangChat 的关联 (Capability mapping)
注意：以下为产品映射，非行业定义。
LangChat 平台的 Agent 能力构建在 Function Calling 基础之上：
- 工具注册与管理：LangChat 允许企业将现有 API 和业务系统封装为标准化工具，注册到平台的工具库中，供 Agent 按需调用。
- 多模型适配：LangChat 的工具调用层屏蔽了不同 LLM 厂商（OpenAI、Anthropic、DeepSeek 等）在 Function Calling 实现上的差异，提供统一的工具定义和调用接口。
- 安全执行环境：工具执行在沙箱环境中进行，支持权限控制和操作审计，确保 AI 的操作在企业安全策略范围内。
（以上为产品映射，具体能力以 LangChat 平台实际功能为准。）
证据来源 (Evidence)
- IBM Think — "What is tool calling?"（2025）：IBM 对 Tool Calling 概念、工作原理、应用类型和行业意义的全面解读，基于多个 LLM 厂商的实践
- LangChain Documentation — "Agents"（2025）：LangChain 对 Agent 架构（Model + Harness）和工具调用循环的官方文档定义
人机边界 (Human-machine boundary)
Function Calling 让 AI 能够：
- 识别何时需要外部信息或操作
- 从多个可用工具中选择合适的工具
- 生成符合 API 规范的结构化调用请求
- 将工具返回的数据整合为自然语言响应
仍然需要人工的：
- 工具的定义、schema 设计和执行逻辑实现
- 安全策略制定——哪些操作 AI 可以自主执行，哪些需要人工审批
- 工具执行结果的异常处理和兜底逻辑
- 业务规则维护——工具背后的业务逻辑和参数校验
- 合规性评估——确保 AI 的操作符合行业法规和企业政策
Source notes
- C-01: §定义 (Function Calling/Tool Calling 的核心定义)
- C-02: §定义 (LLM 从静态到动态的演进)
- C-03: §工作原理 (Tool calling 的关键组件)
- C-04: §工作原理 (六步工作流程)
- C-05: §工作原理 (元数据和模板的结构化信息)
- C-06: §边界 (与 RAG 的关系和互补)
- C-07: §常见误解 (多模型支持)
- C-08: §应用场景 (五大应用类型)
- C-09: §应用场景 (LangChain 框架的作用)
- C-10: §定义 (LLM 从被动到主动的转变)
- C-11: §边界 (Agent 架构：Model + Harness)
Items requiring review
- 定义性引述主要依赖 IBM（Grade B），建议后续补充 OpenAI/Anthropic 官方文档作为 Grade A 一手来源
- "与 LangChat 的关联"部分为产品映射（claim_type=product_mapping），需产品团队确认能力描述的准确性
- "工作原理"部分的技术细节程度是否适合目标受众（企业决策者），可能需要调整深度
- "术语演变"段落（Function Calling → Tool Calling）的表述是否需要更精确的来源支撑