一句话答案：Tool Use（工具使用）是模型根据可用能力提出工具请求的通用概念，Function Calling（函数调用）是其中常见的结构化实现。开发者向模型声明工具名称、用途和参数模式；模型可以返回零个、一个或多个调用建议；应用解析参数、检查权限与业务规则，执行后再把结果交回模型。模型通常不直接运行你的函数，也不会因为生成了合法 JSON 就自动获得数据库、付款、删除或外发权限。
最容易误解的地方是把“格式正确”当成“动作正确”。参数符合 JSON Schema，只能说明结构满足约束；它不能证明订单属于当前用户、库存仍然存在、退款金额合理、收件人可以接收数据，或某个网页中的指令值得信任。生产系统应把模型生成的工具名、参数和外部内容都视为不可信输入。本文依据 OpenAI、Anthropic、Google、Model Context Protocol、JSON Schema、Stripe、OWASP 与 NIST 的公开资料整理，资料复核日期为 2026 年 7 月 18 日。
Function Calling 和普通 JSON、MCP、Agent 有什么区别？
| 概念 | 解决的问题 | 不会自动提供什么 |
|---|---|---|
| 结构化输出 | 让模型按预定结构返回数据 | 真实工具执行、业务授权和副作用控制 |
| Function Calling | 让模型从可用工具中选择调用并生成参数 | 参数真实性、用户权限、重试、补偿与回滚 |
| MCP | 标准化主机、客户端、服务器、工具与资源之间的连接 | 让所有服务器天然可信，或替应用完成审批 |
| Agent | 围绕目标规划、多轮调用工具并检查结果 | 无限自主权、天然可靠的长期运行或责任转移 |
OpenAI 的当前 Function Calling 指南、Anthropic 的工具使用文档与 Google 的函数调用文档虽然接口形态不同，但核心流程一致：应用定义工具，模型产生调用请求，应用决定是否执行并回传结果。
如果你正在构建多步骤工作流，可以结合站内的AI Agent 定义、运行循环与上线治理指南、RAG 检索增强生成指南与来源与引用规范理解上层系统和证据边界；Function Calling 本身只是循环中的一个受控接口。需要跨系统接入工具时，再参考AI 智能体与自动化专题设计整体边界。
一次完整调用包含哪五步？
- 应用声明工具。提供稳定名称、用途、参数 schema、返回含义和不应调用的条件。工具集合应根据用户身份与当前任务动态裁剪。
- 模型提出调用请求。模型可能不调用、调用一个或调用多个工具；应用不能假设调用一定正确，也不能只处理数组中的第一项。
- 应用校验和授权。先解析 JSON 并做 schema 校验，再做类型转换、业务规则、身份、租户、额度、敏感范围与人工确认检查。
- 工具实际执行。由应用路由到数据库、内部服务或第三方 API，并设置超时、幂等键、并发上限、审计上下文和错误分类。
- 结果回传模型。把结构化成功结果或可处理错误与对应调用 ID 一起返回；模型据此继续调用、向用户澄清或形成最终答复。
OpenAI 的工具使用总览还区分了函数工具、平台内置工具和远程 MCP 等类型。无论工具来自哪里，真正的安全边界仍然应在应用和业务服务端，而不是写在提示词里。
工具 schema 怎么写，才能减少误调用？
JSON Schema 官方指南提供类型、枚举、必填字段、嵌套对象等约束。字段描述要写业务含义，而不只是类型：金额要说明币种与最小单位，日期要说明时区，标识符要说明所属租户，枚举要写清每个状态的适用条件。能由服务器从会话中确定的 user_id、tenant_id 和权限范围，不应交给模型自由填写。
| 设计项 | 推荐做法 | 典型失败 |
|---|---|---|
| 工具职责 | 一个工具完成一个清晰动作；读、预览、提交分开 | manage_order(action,payload) 权限过宽且难审计 |
| 必填字段 | 只保留执行所需的最小集合 | 把整份用户或订单对象交给模型补写 |
| 枚举与范围 | 限制状态、币种、数量、长度和日期 | 格式合法，但业务值不存在或越界 |
| 身份字段 | 由服务端会话注入，并在执行时重新授权 | 相信模型生成的用户、租户或角色 |
| 工具结果 | 返回稳定状态码、必要数据和可处理错误 | 把密钥、堆栈或整份内部对象塞回上下文 |
OpenAI 文档建议在可用时开启 strict，并要求对象字段通过 required 与 additionalProperties: false 等约束形成明确契约。相关背景可见结构化输出指南。但严格模式解决的是“输出是否符合 schema”，不是“业务是否允许执行”。例如 quantity 是合法整数，仍可能超过库存与用户额度；邮箱格式正确，也不表示允许向该地址发送数据。
权限设计：按副作用分级，而不是按模型能力分级
| 风险级别 | 示例 | 默认控制 | 放量前证据 |
|---|---|---|---|
| L0 只读 | 查天气、查公开库存、检索知识库 | 字段最小化、访问范围过滤、结果脱敏 | 越权测试与来源可追溯 |
| L1 预览 | 生成邮件草稿、计算退款方案、创建变更计划 | 不产生外部副作用；展示目标、范围和差异 | 预览与最终动作一致性 |
| L2 可逆写入 | 创建待审核工单、保存草稿、添加可撤销标签 | 明确确认、幂等、额度、撤销和审计 | 回滚演练与重复请求测试 |
| L3 高影响动作 | 付款、退款、删除、发布、改权限、对外发送 | 强身份验证、逐次审批、双人复核或人工执行 | 故障演练、事故响应与责任人签字 |
工具列表应按用户身份、租户、会话目的与当前步骤动态生成。只读工具与写入工具分开；应用在执行瞬间重新读取权限，不接受模型声称“用户已经同意”。工具结果回传前还应过滤个人信息、内部提示、令牌和与任务无关的字段。企业资料检索可以配合RAG 生产指南建立来源追踪，整体控制可参考AI 安全威胁模型。
幂等、超时、重试与并行调用如何处理？
网络超时不等于工具没有执行。创建订单请求可能已在服务端成功，但客户端没有收到响应；如果直接重试，就可能重复下单。对有副作用的动作应使用幂等键，并在服务端保存请求指纹、处理状态与最终结果。Stripe 幂等请求文档展示了这类通用设计，但具体键范围、保存时间与冲突规则仍应由你的业务服务实现。
| 失败类型 | 判断线索 | 推荐处理 | 不应做什么 |
|---|---|---|---|
| 结构不合法 | JSON 解析或 schema 校验失败 | 拒绝执行；返回可修复字段错误 | 猜测缺失参数后执行 |
| 业务不合法 | 库存、额度、状态或时间窗不满足 | 向用户澄清或返回确定性业务错误 | 反复重试同一参数 |
| 权限拒绝 | 身份、租户、作用域或审批缺失 | 停止并记录拒绝原因 | 更换工具绕过权限 |
| 暂时性故障 | 限流、短暂网络错误、服务不可用 | 指数退避、随机抖动、次数与总时限上限 | 无限重试 |
| 结果不确定 | 写入超时，无法确认是否成功 | 用幂等键查询原请求状态，再决定后续 | 生成新键再次写入 |
| 部分成功 | 多步骤中只有部分动作完成 | 逐步记账；执行补偿或转人工 | 把跨系统调用假装成原子事务 |
OpenAI 当前指南说明，一次模型响应可能包含零个、一个或多个函数调用，程序应按“可能有多个”来处理；在支持的场景中可以设置 parallel_tool_calls: false 限制为零或一个调用。并行只适用于彼此独立的读取或可安全并行任务。如果第二步依赖第一步结果，或多个动作会修改同一资源，应串行执行并使用版本号、锁或条件更新防止竞态。
最危险的不是 JSON 错误，而是不可信内容改变工具行为
网页、邮件、文档与工具结果都可能包含提示注入，例如诱导模型忽略规则、泄露数据或调用高权限工具。外部内容应始终被标记为数据而非系统指令；工具选择范围不能由被读取的内容自行扩大；执行前还要检查动作是否与原始用户目标一致。OWASP LLM Top 10把提示注入、敏感信息泄露与过度代理列为重要风险。
MCP 架构说明有助于理解 host、client、server、tools 与 resources 的边界，当前 2025-11-25 版工具规范也强调工具发现与调用协议；但协议标准化不等于服务器可信。服务来源、工具描述、权限、返回内容和用户确认仍要由接入方审核。
生产上线前，至少完成这六道验收
- 契约闸门：每个工具有版本、责任人、schema、示例、错误码、返回字段与废弃策略。
- 权限闸门：覆盖不同角色、租户和越权参数；确认服务端而不是模型决定身份与作用域。
- 副作用闸门：预览、确认、金额或范围上限、幂等、撤销与补偿均经过演练。
- 故障闸门：覆盖超时、限流、重复请求、依赖不可用、结果过大、部分成功和恢复。
- 注入闸门：用恶意网页、邮件和文档测试，确认不可信内容不能扩大工具权限或泄漏数据。
- 评测审计闸门：保存脱敏调用轨迹，统计误选工具、参数失败、授权拒绝、延迟、成本与人工接管。
离线评测集应该覆盖什么？
至少准备六类样本：明确应调用、信息不足需要追问、不应调用、多个相似工具容易误选、格式合法但业务无效，以及包含恶意指令或敏感数据的输入。为每条样本记录期望工具、允许参数范围、是否需要确认、预期错误与禁止副作用。模型、提示词、schema 或工具版本升级时重放同一批样本，才能识别回归。
| 轨迹字段 | 用途 | 隐私与安全要求 |
|---|---|---|
| 请求与调用 ID | 串联模型响应、工具执行和用户结果 | 使用不可猜测标识，不把令牌写入日志 |
| 模型、提示与 schema 版本 | 还原当时决策条件，支持回归比较 | 提示内容分级访问，敏感片段脱敏 |
| 工具名、参数摘要、授权结果 | 定位误选、越权和参数失败 | 只存必要字段；个人信息散列或掩码 |
| 幂等键与执行状态 | 识别重复动作与结果不确定 | 限制保留周期并建立冲突告警 |
| 延迟、成本、错误与接管 | 评估生产可用性和真实完成成本 | 与业务结果关联，而非只看调用成功率 |
线上不能只看“工具调用成功率”。还应分别统计错误工具选择率、参数校验失败率、授权拒绝率、用户取消确认率、重复动作拦截率、部分成功次数、人工接管率、P50/P95 延迟与每个成功任务的总成本。成功率上升但越权尝试、用户撤销或人工返工增加，不能判定新版本更好。
工具版本变化要留下兼容边界
工具 schema 是接口契约。删除字段、改变枚举含义或修改金额单位，都可能让旧提示与缓存轨迹失效。应为工具保留明确版本，先让新旧版本并行或用影子流量验证，再逐步迁移；废弃时返回可处理错误，而不是让模型猜测新参数。NIST AI 风险管理框架强调治理、识别、测量与管理；其生成式 AI 配套框架进一步提供生成式系统风险视角。把这些要求落实到责任人、离线评测、运行监控、事故响应和版本回滚，才算完成生产准备。
常见误区
- “严格 JSON 就不会错。”结构可能正确，事实、权限与业务含义仍可能错误。
- “模型会自己判断是否需要审批。”审批规则必须由应用和策略系统强制执行。
- “重试能提高成功率。”没有幂等、错误分类和总时限的重试会放大副作用。
- “工具越多越智能。”工具过多会增加误选、上下文成本与权限暴露；应按场景裁剪。
- “接入 MCP 就自动成为 Agent。”MCP 解决连接标准化，规划、记忆、评测与治理仍需系统设计。
- “调用返回成功就代表任务成功。”技术成功不等于用户目标完成，还要检查业务状态和最终结果。
官方资料与进一步阅读
- OpenAI：Function Calling
- OpenAI：Using tools
- OpenAI：Structured Outputs
- Anthropic：Tool use
- Google：Function calling
- JSON Schema 官方指南
- Stripe：Idempotent requests
- MCP：Architecture overview
- MCP：Tools specification 2025-11-25
- OWASP：LLM Top 10
- NIST：AI Risk Management Framework
- NIST：Generative AI Profile
可靠的 Function Calling 不是让模型拥有更多权力，而是用清晰契约把模型建议限制在可验证范围内。先上线只读查询，再增加预览和人工确认，最后才对低风险、可逆动作开放有限自动执行；每次扩权都必须有测试证据、责任人、审计记录与回滚方案。
编辑复核与纠错记录
本文由兰塞 AI 编辑流程于 2026 年 7 月 18 日复核。此次更新把旧稿中“模型主动执行”“接入工具就成为 Agent”等无边界表述改为模型建议、应用校验与真实执行的责任分离；补充零个、一个或多个调用的处理要求、严格模式边界、权限四级阶梯、六类故障处置、审计字段与官方资料索引。预发布 A 级候选代表稿件已通过内容门槛，不等于搜索引擎背书；上线后仍需完成桌面端、移动端、结构化数据和链接可用性检查。本站的来源、更新与纠错原则见关于本站与编辑规范。
