跳到正文

Tool Calling 决策机制与执行流程

Function Calling 的输入输出格式、决策机制与执行流程详解

原题：请说明大模型实现工具调用（Tool Use / Function Calling）的常见架构与实现方式，包括输入输出格式设计、调用决策机制及执行流程。

Agent · 百度真题

回答与解析

核心架构：两种实现路径

1. 原生支持（Native）

  • OpenAI/Claude等模型内置，训练阶段注入工具使用能力
  • 通过tools参数传入工具描述，模型学习生成特定格式的调用请求

2. 提示工程（Prompt-based）

  • 通用模型通过精心设计的System Prompt模拟
  • 关键：在Prompt中明确定义工具描述、输出格式、执行流程

输入输出格式设计

工具描述（Tool Schema）

{
  "name": "weather_query",
  "description": "查询指定城市的天气",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {"type": "string", "description": "城市名称"},
      "date": {"type": "string", "description": "日期，格式YYYY-MM-DD"}
    },
    "required": ["city"]
  }
}

模型输出格式

  • 需调用时：{"tool": "weather_query", "arguments": {"city": "北京"}}
  • 无需调用：直接返回最终答案

调用决策机制

机制 说明
隐式决策 模型自主判断，通过训练内化"何时调用"
显式决策 输出中包含action字段，如"action": "call_tool"

关键约束：结构化输出（JSON Mode/Constrained Decoding），确保参数可解析

执行流程（ReAct简化版）

用户输入 → 模型决策 → [需工具?] → 生成调用参数 → 执行工具
                              ↓
                         返回观察结果 → 拼接上下文 → 模型再决策 → 最终输出

循环终止条件：模型输出不含工具调用标记，或达到最大迭代次数

工程要点

  • 工具描述质量：直接影响调用准确率，需清晰说明功能边界和参数含义
  • 错误处理：工具执行失败时，将错误信息反馈给模型，支持自我修正
  • 并行调用：支持一次生成多个独立工具调用，提升效率

学习建议

建议系统学习该知识点

口语版讲法(约4分钟)

  • 本质是模型与外界的交互能力
  • 两种实现路径及其适用边界
  • 输入输出格式与决策机制
  • 执行流程与落地风险
  • 工程师的取舍与延伸点

这道题问的是工具调用，其实本质就是问大模型怎么跟外界交互。模型本身是静态的，它不知道实时天气、不会查数据库、不能操作API，所以需要一种机制让模型能说“我需要用某个工具”，然后我们把结果喂回去让它继续推理。

实现路径主要有两种。一种是原生支持，像OpenAI、Claude这些模型在训练时就注入了工具调用能力，你只需要按格式传tools参数，它就会输出结构化的调用请求。另一种是提示工程，对通用模型在System Prompt里把工具描述、输出格式、流程都写清楚，让模型通过In-Context Learning模拟出来。两者的边界很清晰：原生支持准确率高、输出稳定，适合对可靠性要求高的场景，比如金融交易、自动化客服；提示工程灵活、不依赖特定模型，适合快速原型或模型不固定的情况。但真正落地时，我通常两种一起用，用原生支持的输出格式，但同时在System Prompt里写清楚边界条件和错误处理，相当于双保险。

具体说一下输入输出格式。工具描述一般用JSON Schema，包括名称、描述、参数类型和必填项，比如天气查询工具就需要城市名称和可选日期。模型输出分两种情况：要调用工具时，输出一个包含工具名和参数的结构化对象；不需要就直接返回答案。这个格式设计的关键是结构化输出，必须用Function Calling或JSON Mode约束解码，否则参数格式乱掉后续没法解析。

调用决策机制有两种。隐式决策是模型自己判断，通过训练内化了“什么时候该调工具”；显式决策是在输出里加一个action字段，比如"action": "call tool"。我倾向于显式决策，因为可解释性强，调试时能清楚看到模型每一步的意图。

执行流程可以看成简化版的ReAct：用户输入后模型先决策，如果需要工具就生成调用参数，执行工具后把观察结果拼回上下文，模型再决策，直到不需要调用工具或达到最大迭代次数。举个例子，一个企业客服系统处理退款请求：用户说“我订单号12345，要退款”，模型先调用订单查询工具获取订单状态，发现已发货，再调用退款规则工具判断是否可退，最后生成最终答案。这个循环里有个常见失败场景：工具执行失败或返回空结果，模型可能陷入死循环或胡乱猜测。所以上线前我会特别关注错误处理，把工具返回的错误信息原样喂给模型，让它尝试修正参数重试，同时设置最大迭代次数防止无限循环。

还有一个有意思的点是并行调用，模型可以一次生成多个独立的工具调用，比如同时查天气和航班。这能提升效率，但前提是这些调用之间没有依赖关系，否则需要顺序执行。

所以我会把工具调用看成模型能力的延伸，而不是模型本身的功能。前提是工具描述要足够清晰，参数边界要严格，否则模型会乱调。如果工具描述模糊，比如只说“查询用户信息”但不说明需要什么权限，模型可能生成不合法的参数。更倾向的做法是：先做小范围压测，统计调用准确率和失败重试次数，再逐步开放。

关键一句:并行调用可以提升效率，但前提是调用之间没有依赖关系，否则需要顺序执行。

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你正在做一个智能客服，用户说'帮我查下订单'，然后模型要调用订单查询API。你怎么让模型知道它能用哪些工具、什么时候该调用、以及怎么输出调用参数？

  2. 问法 2 · 层层追问

    大模型是怎么跟外部工具配合的？……那它怎么决定要不要调用？……如果调用了，返回的结果怎么再喂给模型？整体的执行流程你画一下？

  3. 问法 3 · 直球架构

    请你讲讲大模型工具调用的常见架构，包括输入输出格式怎么设计、调用决策是隐式还是显式的，以及整个执行流程是怎样的。

同模块相关题目