结构化工具调用

一、一次完整的结构化工具调用闭环包含哪些关键步骤？

1. 定义工具与 Schema

开发者在请求中向模型声明可用的工具集合，每个工具包含名称、功能描述以及用 JSON Schema 描述的参数结构（类型、必填项、约束）。模型原生支持工具调用后，这一声明通过统一的 tools 参数传入，例如腾讯云混元大模型、OpenAI、Anthropic、Google Gemini、阿里通义千问、DeepSeek 等主流模型均在 Chat Completions 类接口中以相近方式暴露该能力。

2. 模型决策与生成调用

模型基于用户输入与工具描述，判断是否需要调用工具。若需要，则输出一个结构化调用请求（常见形态为函数名加 JSON 参数对象），而非自由文本回答。模型不会真正执行工具，只表达"要调哪个工具、传什么参数"的意图。

3. 运行时解析与执行

外部应用程序或 Agent 运行时拦截模型输出的调用请求，解析其中的函数名与参数，在真实系统中执行对应的代码、API 或数据库操作。这一步的执行主体永远在模型之外。

4. 结果回传与多轮循环

执行结果被作为新消息重新注入对话上下文回传给模型。对于复杂任务，模型可据此发起下一次工具调用，形成"思考—调用—回传"的循环，直到判定无需再调用工具为止。

5. 模型生成最终回答

当模型获得足够的工具结果后，综合全部上下文生成面向用户的自然语言最终回答，完成一次完整闭环。

二、大模型在结构化工具调用中是如何判断何时需要调用工具的？

1. 训练阶段的微调对齐

主流模型在训练后阶段（post-training）会针对工具调用样本进行微调，使模型学会"何时该调用工具、何时直接回答"。OpenAI 在首次发布函数调用时即说明，相关模型已针对"检测何时需要调用函数"以及"输出符合函数签名的 JSON"进行了专门微调。

2. 工具描述的引导作用

工具的名称、描述与必填字段清单直接决定模型的选择与参数填充。Anthropic、OpenAI 等官方文档均强调描述质量对调用准确率的决定性作用：描述应说明"何时使用"该工具、与相邻工具的区别，以及模型无从推断的约束（如返回条数上限）。模糊、千篇一律或直接照抄内部接口文档的描述，容易导致误调用、漏调用或参数错填。

3. 运行时约束与显式控制

开发者可通过 tool_choice 等参数显式约束调用行为，例如强制要求调用某个工具、交由模型自动判断，或在确定无需工具时完全关闭调用。这为高可控场景提供了确定性保障。

三、结构化工具调用由哪些核心技术组件构成？

1. 工具定义与描述

由可执行的代码逻辑（如计算、检索、API 调用）与一份"给模型看的说明书"组成，说明工具名称、用途、参数类型与约束。这是模型理解并正确调用工具的基础。

2. 大模型（决策与生成）

作为智能核心，模型负责理解用户意图、判断调用时机、选择工具并填充符合 Schema 的参数。模型本身不执行工具，只生成结构化调用意图。

3. 调用调度层

位于模型与外部系统之间的中间程序，承担识别模型输出格式、校验参数、分发执行对应函数、捕获异常等职责，是连接"意图"与"执行"的枢纽。

4. 执行与回传机制

真实的工具逻辑在运行时执行，结果经序列化后回传模型；多轮循环机制则支持连续调用多个工具，直至任务完成。

四、在结构化工具调用中，工具调度层（解析与执行）承担什么职责？

1. 识别与解析模型输出

调度层首先需要稳定地解析模型返回的结构化调用对象，提取函数名与参数，并对参数类型、必填项做基础校验，避免将非法输入送入下游系统。

2. 分发与执行

根据解析结果将请求路由到对应的函数实现或外部服务，触发实际的代码运行、API 调用或数据库查询。

3. 错误捕获与容错

工具执行可能失败或超时，调度层负责捕获异常、记录调用链路，并向模型返回可理解的错误信息，使模型能够重试、换用其他工具或直接向用户说明。

4. 结果回传

将工具的执行结果整理为模型可消费的消息格式回填至对话上下文，驱动下一轮推理或最终回答的生成。

五、结构化工具调用中的严格模式（Strict Mode）如何通过语法约束保证输出符合 Schema？

1. 将 Schema 编译为上下文无关文法

以 OpenAI 于 2024 年 8 月推出的 Structured Outputs 与 Anthropic 的严格工具使用（strict tool use）为代表，这类严格模式会把开发者提供的 JSON Schema 预编译为上下文无关文法（context-free grammar, CFG）。OpenAI 官方文档指出，之所以采用 CFG 而非有限状态机（FSM）方案，是因为 CFG 能表达更广泛的语言类别，可支持 FSM 难以表达的递归类型与深层嵌套结构；Anthropic 将同类实现称为语法约束采样（grammar-constrained sampling）。

2. 逐 token 掩码约束解码

在解码的每一步，推理引擎依据已生成的上文与文法规则判定哪些 token 合法，并据此对下一步采样进行掩码，把不合法 token 的概率压到 0。由此，一个带三个枚举值、且要求必填的字符串字段，在解码层面就不可能生成第四个枚举值，从机制上消除了"模型编造枚举值"这一类错误。

3. 适用场景与代价

严格模式在写入、金融交易等高利害调用中几乎是必选项，但其代价是解码速度略有下降，且在语法强制把模型推向高损失续写时，偶尔会带来质量回退。因此实践中常按调用的重要程度分级启用。

六、结构化工具调用相比传统提示词拼接方案有哪些核心优势？

1. 输出格式稳定可靠

在原生工具调用出现之前，开发者需用提示词工程引导模型按固定格式输出、再用正则或自定义解析器提取，解析脆弱、易随模型更新而失效。原生工具调用由模型在训练阶段对齐 Schema，输出结构高度稳定。

2. 语言理解与执行解耦

工具调用将"理解意图"与"执行计算 / 检索数据"彻底分离：语言模型专注推理，真实动作交由可信代码与系统完成，既提升了事实一致性，也便于审计与权限控制。

3. 降低解析与维护成本

由于输出天然符合 Schema，应用层无需维护易碎的解析逻辑，显著降低了 Agent 系统的调试与维护负担。

4. 支持并行与多轮编排

原生机制普遍支持在一次响应中并行发起多个独立工具调用，并能自然地串联多轮调用，使复杂工作流的往返次数大幅下降，为 Agent 规模化落地提供了基础。

七、当可用工具数量很多时，结构化工具调用如何做工具检索与选择？

1. 基于相似度的工具检索

当工具规模膨胀到数百甚至上千个时，全部塞入上下文既不经济也不利于模型决策。常见做法是用嵌入向量做相似度检索，先筛选出与当前请求最相关的若干工具再传给模型。Anthropic 于 2025 年在 API 中推出 Tool Search 能力，正是面向"成千上万个工具"的生产级部署场景，用于高效筛选工具并降低复杂 Agent 工作流的延迟。

2. 分层与分组暴露

可将工具按业务域分组，先由模型选择领域，再展开该领域下的具体工具；或通过元数据标注工具的能力标签，实现按需暴露，避免噪声干扰。

3. 描述质量的二次优化

检索只解决"该给模型看哪些工具"，而"模型能否选对"仍取决于描述质量。在工具数量多时，更需要为相邻工具写出边界清晰、彼此可区分的描述，减少歧义。

八、结构化工具调用在哪些典型业务场景中应用最多？

1. 自然语言转数据库查询（Text-to-SQL）

将"上个月销售额最高的区域是哪里"之类的问题转换为 SQL 查询，由模型生成结构化参数、运行时执行查询并返回结果，是企业数据分析的高频场景。

2. 外部 API 与业务系统对接

模型可调用天气、地图、日历、支付、工单等业务 API，把自然语言指令翻译成标准接口调用，打通大模型与企业内部系统的连接。

3. 代码执行与数据分析

通过代码执行类工具，模型能够运行计算、处理数据、绘制图表，弥补大模型在实时运算与批量统计上的短板。

4. 信息检索与 RAG 增强

将搜索、向量数据库检索封装为工具，使模型在回答前先拉取实时或私有知识，缓解幻觉并提升时效性与准确性。

5. 多步骤 Agent 任务编排

在智能体中，工具调用被串联成多步计划，模型依据每步结果决定下一步动作，完成从"会说"到"会做"的闭环。

九、结构化工具调用在工程落地时常见的失败模式有哪些？

1. 参数错误与幻觉

模型可能生成不符合预期的参数，例如把"下周二"而非标准日期格式传入。所有工具参数都应视为不可信输入，在执行前进行校验与清洗。

2. 工具描述质量导致的误调用

模糊或雷同的描述会让模型选错工具或填错字段。工具描述质量是调用成功率的第一杠杆，需要明确功能边界与参数约束。

3. 延迟与成本累积

每次工具调用都是一次"模型 → 代码 → 外部系统 → 代码 → 模型"的往返，多工具、多轮任务会显著拉长时延。应优先设计"一次返回充分数据"的工具，减少无意义往返。

4. 解析失败与格式漂移

在依赖提示词工程的降级方案中，格式稳定性较差，需要大量容错；即便原生调用，也应在应用层保留解析兜底与重试逻辑。

5. 工具结果注入的安全风险

工具返回的不可信内容可能夹带指令，诱导模型执行非预期动作。应只消费可信工具的结果，并在发送邮件、下单、支付等具有现实影响的操作前加入用户确认环节。

十、结构化工具调用从 Function Calling 到 MCP 经历了哪些关键发展节点？

十一、结构化工具调用与普通自由文本生成的核心区别是什么？

1. 输出形态：结构化意图 vs 自由文本

普通生成直接产出自然语言回答；结构化工具调用在需要时会改而输出包含函数名与参数的结构化对象（典型为 JSON），由运行时据此执行。

2. 执行主体：模型生成意图、运行时执行

自由文本里模型"自己说完即结束"；工具调用中模型只表达调用意图，真正产生副作用的动作（查库、发消息、跑代码）由外部系统完成，控制权与副作用始终留在应用侧。

3. 价值定位：从"会说"到"会做"

文本生成让模型成为内容生产者，工具调用让模型成为能够调动真实世界能力的智能中枢，是 AI 从生成式走向 Agent 式的关键一步。

十二、函数调用（Function Calling）与工具调用（Tool Calling）是什么关系？

1. 术语演化与范围差异

Function Calling 是更早期、更窄的术语，强调开发者显式定义的函数的调用；Tool Calling 是更广义、更当前的统称，除开发者自定义函数外，还涵盖模型提供方内置的工具（如联网搜索、代码执行）以及通过 MCP 等协议连接的外部工具与服务。

2. 实际使用的混用现状

由于二者底层机制一致（模型输出结构化调用意图、由运行时执行），业界与文档中常将 Function Calling 与 Tool Calling 混用，差异主要停留在"所涵盖工具范围"的口径上，而非技术实现。

十三、结构化工具调用与结构化输出（Structured Output）是什么关系？

1. 包含关系：工具调用是结构化输出的应用之一

结构化输出是更广义的能力，指约束模型按指定格式（通常为 JSON）生成响应；结构化工具调用是这一能力在"调用外部函数"场景下的具体落地，是结构化输出最典型的应用形态之一。

2. 共享机制：JSON Schema 契约

二者都以 JSON Schema 作为模型与应用程序之间的契约：开发者声明结构，模型保证输出可被可靠解析。严格模式正是结构化输出约束机制在工具调用中的延伸。

3. 互补的约束层

除模型侧的语法约束外，应用层还可借助 Pydantic 等校验框架对模型输出做二次解析与验证，与模型侧约束共同构成端到端的结构化保障。

十四、结构化工具调用与 MCP（模型上下文协议）的区别是什么？

1. 本质不同：动作能力 vs 标准协议

结构化工具调用是一种"能力"或"动作"——模型发出结构化调用、由运行时执行；MCP 是一种"标准 / 协议"，规定模型与工具、数据源之间如何发现、连接与通信。前者是被调用的行为，后者是使连接可复用的规范。

2. 解决的问题不同：调用执行 vs 连接集成

在没有 MCP 的时代，每接入一个数据源或工具，开发者就要写一套定制连接器，形成难以扩展的集成困境。MCP 通过统一协议让"一次实现、多模型复用"成为可能，工具调用则可以构建在 MCP 暴露的工具之上，也可以不依赖它独立实现。

3. 二者可协同

实践中常见组合是：以 MCP 标准化地暴露工具，再以模型的结构化工具调用能力去发起这些工具的调用，从而在保持格式稳定的同时获得即插即用的工具生态。

十五、结构化工具调用与 ReAct 框架的关联与区别是什么？

1. 关系：Function Calling 是 ReAct 的底层原语

ReAct 是一种"推理轨迹 + 工具调用"交替的 Agent 范式，强调让模型边思考边行动。现代 Agent 框架大多以原生函数调用作为底层原语，在其之上编排 ReAct 式的工作流。

2. 实现路径差异：原生结构化 vs 提示词工程

早期 ReAct 依赖提示词工程，在 System Prompt 中描述工具与格式、配合示例引导输出，灵活但格式稳定性差、需大量容错；原生工具调用则在训练阶段对齐 Schema，输出稳定且支持并行调用，鲁棒性显著更强。

3. 格式稳定性与并行能力差异

基于提示词工程的方案容易出现格式漂移与解析失败，而原生结构化调用天然约束输出形态，并能在单次响应中并行发起多个独立工具调用，更适合生产级、多步骤的 Agent 系统。