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）返回给模型。
处理与响应：模型解析工具返回的数据，将其整合进自然语言回复中，以有意义的方式呈现给用户。
迭代细化：如果用户追问或需要更多信息，模型可以基于上下文发起新的工具调用，逐步细化响应。

技术实现细节

JSON Schema 定义——工具的"规格说明书"

Function Calling 的核心在于工具定义。每个工具通过 JSON Schema 精确描述其名称、用途和参数。设计要点：

description 字段是模型选择工具的依据——描述越清晰，模型选择越准确
enum 约束模型只能输出合法值，降低参数错误率
required 明确哪些参数必须提供，哪些是可选的
参数描述应包含格式说明和业务含义，帮助模型正确填参

参数提取原理——模型如何"理解"需要调什么

当用户说"帮我查一下张总上个月完成了多少订单"，模型需要完成以下推理：

意图识别：用户想要查询订单信息 → 匹配到 query_customer_orders 工具
实体提取："张总" → customer_id（需要从上下文或 CRM 映射中获取）
时间解析："上个月" → start_date（需要计算具体日期范围）
状态推断："完成了" → status = "completed"
参数组装：生成符合 schema 的 JSON 参数

这个过程本质上是大模型将自然语言映射到结构化 API 参数的过程。模型的能力越强（如 GPT-4o、Claude 3.5），参数提取的准确率越高，尤其是在处理模糊表述和隐含参数时。

影响参数提取准确率的关键因素：工具描述的清晰度；参数命名的语义性（customer_id 远优于 cid）；上下文信息的充分性（之前的对话是否提供了足够的线索）；模型的推理能力层级。

多函数编排（Function Chaining）

实际企业场景中，单一工具调用往往无法完成复杂任务。Function Chaining（函数链式编排）是指模型通过多次工具调用的组合，完成一个复杂的工作流。

典型编排模式

串行链（Sequential Chain）：例如用户说"帮我查下王经理的合同到期情况，如果快到期了就发个提醒邮件"。Agent 执行链为：查询客户信息 → 获取合同列表和到期日 → 计算剩余天数 → 条件判断（如果剩余<60天）→ 发送提醒邮件。

并行调用（Parallel Calls）：现代 LLM（如 GPT-4o、Claude 3.5）支持在单次推理中并行调用多个无依赖的工具。例如用户询问"给我对比下北京和上海两个项目的运营数据"，模型可以同时调用两个查询工具，然后综合结果。

迭代细化（Iterative Refinement）：例如用户说"找出最近一个月投诉最多的小区，分析原因"。Agent 执行链为：查询投诉统计排名 → 获取排名第一的详情 → 主题聚类和趋势分析 → 生成分析报告。

编排的工程挑战

上下文管理：每一步工具调用的结果都会占用模型的上下文窗口，长链可能超出限制
错误处理：中间步骤失败时，需要决定是重试、跳过还是终止
成本控制：每次工具调用都涉及模型推理，复杂编排的成本可能很高
确定性 vs 灵活性：过度自由的编排可能导致不可预测的行为，需要通过工作流引擎施加约束

与 MCP 的关系

Function Calling 和 MCP（Model Context Protocol）是互补关系，各自解决不同层面的问题：

解决的问题：Function Calling 解决模型如何决定调用什么工具、传什么参数；MCP 解决工具如何被标准化地发现、描述和执行
所在层级：Function Calling 在模型推理层；MCP 在协议传输层
标准化：Function Calling 各厂商格式有差异；MCP 是跨厂商统一标准
协作关系：模型输出调用意图；系统执行调用请求

协作流程：MCP Server 注册工具，通过 MCP 协议向 Host 暴露工具定义；Host 将工具定义转换为模型的 Function Calling 格式（JSON Schema）；模型通过 Function Calling 选择工具并生成参数；Host 通过 MCP 协议将调用请求转发给对应的 MCP Server；MCP Server 执行工具，返回结果；Host 将结果返回给模型，模型生成最终回复。

简单说：MCP 让工具"可被发现"，Function Calling 让模型"知道怎么用"。

企业实战案例

案例 1：CRM 自动写入

场景：销售经理在对话中说"刚和王总开完会，他对 B 栋 3 层的 500 平感兴趣，预算在 200-250 万，让我下周给方案"。

工具链：提取会议纪要结构化信息 → 创建 CRM 记录（客户、意向、预算、下一步行动） → 创建待办任务（准备方案，下周一截止） → 返回确认信息。

案例 2：ERP 实时查询

场景：商场总经理询问"本月各楼层的客流与销售坪效对比如何"。

工具链：查询 ERP 报表（楼层绩效、客流、坪效指标） → 生成对比分析 → 格式化报告（表格+图表）。

案例 3：工单智能创建

场景：商户在微信群说"我们店门口的灯坏了三天了，一直没人来修"。

工具链：分类意图（维修投诉） → 提取实体（位置、问题、紧急度） → 检查 SLA 标准 → 创建工单（维修、P2优先级、待分派） → 通知工程团队。

安全与权限控制

权限分层模型

企业级 Function Calling 需要严格的权限控制：

只读工具：AI 可自主调用，无需审批（如查询订单状态、搜索知识库）
低风险写操作：AI 可执行，事后审计（如更新客户备注、添加跟进记录）
高风险写操作：需人工确认后执行（如创建订单、修改合同、发送外部邮件）
禁止操作：AI 不可调用（如删除数据、财务核销、系统配置变更）

安全最佳实践

工具描述即安全边界：工具的 description 应明确说明影响范围，帮助模型做出正确的调用决策
参数验证：运行时对模型生成的参数做服务端验证，拒绝不合法的请求
速率限制：对工具调用频率设置上限，防止模型进入调用循环
操作审计：记录所有工具调用的完整上下文（谁触发、什么参数、什么结果）
沙箱执行：工具执行在隔离环境中进行，限制对生产系统的直接访问
敏感数据脱敏：工具返回的结果在送入模型前，对敏感字段（身份证号、银行卡号）做脱敏处理

应用场景

Function Calling 在企业环境中的五大典型应用类型：

信息检索与搜索：从新闻源、学术数据库、金融市场获取实时数据。例如客户询问产品库存时，AI 调用 ERP 系统的查询接口返回实时库存状态。
代码执行：调用数学引擎（如 Wolfram Alpha）或 Python 运行环境执行复杂计算、运行模拟或处理数据。
流程自动化：与 CRM（如 Salesforce）、财务系统（如 QuickBooks）、日历和邮件平台集成，自动化数据录入、报告生成、会议调度等业务流程。
智能设备与 IoT 监控：监控和控制工业 IoT 设备、家居自动化系统。未来可扩展到端到端的自主运维工作流。
多步骤组合工作流：将多个工具按顺序串联，完成复合任务。例如先查询客户信息，再检查订单状态，最后生成个性化回复。

与 LnkChat 的关联

LnkChat 平台的 Agent 能力构建在 Function Calling 基础之上：

工具注册与管理：LnkChat 允许企业将现有 API 和业务系统封装为标准化工具，注册到平台的工具库中，供 Agent 按需调用。
多模型适配：LnkChat 的工具调用层屏蔽了不同 LLM 厂商（OpenAI、Anthropic、DeepSeek 等）在 Function Calling 实现上的差异，提供统一的工具定义和调用接口。
安全执行环境：工具执行在沙箱环境中进行，支持权限控制和操作审计，确保 AI 的操作在企业安全策略范围内。
MCP 集成：LnkChat 支持 MCP 协议，可以通过 MCP Server 发现和使用外部工具，同时也可以将自身能力通过 MCP Server 暴露给其他 AI 应用。

人机边界 (Human-machine boundary)

Function Calling 让 AI 能够：

识别何时需要外部信息或操作
从多个可用工具中选择合适的工具
生成符合 API 规范的结构化调用请求
将工具返回的数据整合为自然语言响应
通过多步骤工具调用链完成复杂任务

仍然需要人工的：

工具的定义、schema 设计和执行逻辑实现
安全策略制定——哪些操作 AI 可以自主执行，哪些需要人工审批
工具执行结果的异常处理和兜底逻辑
业务规则维护——工具背后的业务逻辑和参数校验
合规性评估——确保 AI 的操作符合行业法规和企业政策

证据来源 (Evidence)

IBM Think — "What is tool calling?"（2025）：IBM 对 Tool Calling 概念、工作原理、应用类型和行业意义的全面解读
LangChain Documentation — "Agents"（2025）：LangChain 对 Agent 架构（Model + Harness）和工具调用循环的官方文档定义
OpenAI Function Calling Guide（2023-2024）：OpenAI 对 Function Calling 的官方文档和最佳实践
Anthropic Tool Use Documentation（2024-2025）：Anthropic 对 Tool Use 的技术规范和示例