想象你是一家餐厅的主厨，厨艺登峰造极，能背出一千道菜谱。但你的厨房里没有冰箱、没有烤箱，也没有任何食材供应商的联系方式。客人点一道清蒸鲈鱼，你只能口若悬河地描述这道菜的做法——却永远端不出一道热气腾腾的菜。你缺的不是手艺，而是与真实世界连接的那根线。 大模型正在经历同样的尴尬。它拥有海量的语言知识，可一旦问题涉及“今天的天气”“我上个月的订单”“最新股价”，它就哑口无言，甚至一本正经地编造答案，这就是著名的“幻觉”。工具使用（Tool Use）和 Function Calling，就是给大模型接通“食材供应链”的那根线。 在这篇文章里，你会看到大模型这位“主厨”如何通过一张张采购单（Function Calling）向外部 API 下单，如何用“想一步、做一步、看一步”的 ReAct 循环边做边调整，如何通过数据训练掌握这些本领，又如何在一桌宴席（多工具编排）中统筹调度、在食材缺货（错误恢复）时临危不乱。读完你会发现：让大模型“动手”，比让它“开口”更接近真正的智能。

岗位关联

掌握工具使用与 Function Calling，是让大模型从“会聊天的专家”进化为“能干活的下属”的关键一步，也是 AI 应用开发者、大模型工程师与 AI 产品经理交付可用产品必须跨越的门槛。

目录
  1. 可视化演示
  2. 能力边界：没有食材的主厨
  3. 接口设计：写给采购员的采购单
  4. 参数生成：把需求翻译成采购明细
  5. ReAct 循环：想-做-看的烹饪工作流
  6. 数据训练：厨师学校的标准菜谱
  7. 工具编排：一桌宴席的炒菜单
  8. 错误恢复：食材缺货的临场应变
  9. Agent 应用：从后厨走向大堂
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示ReAct推理-行动-观察-回答的循环框架，以及LLM Agent通过Function Calling编排搜索/计算/API/数据库/执行五种工具的多工具调用流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

ReAct推理-行动循环 THK 推理：分析问题需要什么信息 ACT 行动：调用工具执行具体操作 OBS 观察：获取工具返回结果 Thought → Action → Observation → Answer 循环执行直至得出最终答案。

能力边界：没有食材的主厨

米其林主厨也有无能为力的时刻——当冰箱空空如也。他会一百道菜的做法，却连一道茄子也端不上桌。大模型正是这位主厨：它的全部“手艺”都凝固在训练时读过的文本里，一旦被问到训练截止之后的事情——今天的股票、现在北京的天气、你后台的订单状态——它就只能凭空想象。这种“一本正经地胡说八道”，业界称为幻觉（Hallucination），根源就在于模型从未真正“摸到”过真实世界。

工具使用（Tool Use）就是给主厨接上食材供应链：天气服务是送菜的，计算器是烤箱，数据库是冰箱。大模型的角色从“什么都知道的专家”变成“什么都敢做的指挥”。当它能调用外部工具时，就不再只是一个文本生成器，而是一个 Agent——业界常译作“智能体”，你可以把它理解为一个戴上围裙、真能下厨的数字员工。

一个完整的 Agent 至少由三块拼图组成：语言理解与规划靠大模型（LLM），真实执行靠工具（Tools），而“什么时候、按什么顺序、调用谁”则由编排（Orchestration）统一负责，三者的关系可以写成：

一位主厨的真正实力，不在刀工本身，而在把刀、火、食材和供应商组合成一道道菜的系统能力。大模型的工具使用能力，正是这种“组合系统力”——它让模型从“纸上谈兵”走向“真刀真枪”。

Agent=LLM⊕Tools⊕Orchestration\text{Agent} = \text{LLM} \oplus \text{Tools} \oplus \text{Orchestration}
这个公式说明：智能体不是“模型 + 一堆函数”的简单堆叠，而是推理、执行与调度三者深度协作的系统。
  1. Agent 项智能体，指能够感知环境、做出决策并执行行动的自主系统，是工具使用的最终载体。
    Agent\text{Agent}
  2. LLM 项大语言模型，担任“大脑”角色，负责理解用户请求和规划任务步骤。
    LLM\text{LLM}
  3. ⊕ 组合运算表示各组件不是简单拼接，而是深度协作——模型的输出会成为工具的输入，工具的返回又会喂回模型。
    ⊕\oplus
  4. Tools 项外部工具集合，如 API、数据库、代码解释器，负责产生可验证的真实结果。
    Tools\text{Tools}
  5. Orchestration 项编排机制，决定工具调用顺序、并行关系与错误处理策略，是 Agent 的“调度室”。
    Orchestration\text{Orchestration}

接口设计：写给采购员的采购单

主厨要给供应商打电话，不能只喊一句“我要鱼”。称职的采购单必须写清楚三件事：找哪家（供应商的名字）、为什么要买（用途备注）、要什么货、多少量、什么规格（具体参数）。Function Calling 的接口设计，就是大模型世界里的“采购单模板”——只不过沟通对象从供应商变成了各种 API。

在工程上，这份采购单被称为工具定义（Tool Definition）。开发者把每个可调用的函数描述成结构化的元数据，连同用户的问题一起交给大模型。模型会先“阅读说明书”，再决定要不要下单、下给谁。就像采购员拿到一本供应商通讯录，每个条目都标注着“这家卖什么、什么时候该找它”。

一份合格的工具定义由三个核心字段构成：

采购单写得潦草，采购员就会买错菜。同理，接口描述写得含糊，模型就会在“查天气”时误调用“开灯”。好的工具接口，是一张让大模型一看就懂、一调就对的采购单。

ToolDef={name, description, parameters}\text{ToolDef} = \{\text{name},\ \text{description},\ \text{parameters}\}
工具定义三要素：名称保证调用不会对错号，描述引导模型在恰当场景做出选择，参数约束则保证生成的调用“语法正确”。
  1. 工具定义整体一份可被模型理解和调用的工具，必须同时包含名称、描述、参数三部分，缺一不可。
    ToolDef={name, description, parameters}\text{ToolDef} = \{\text{name},\ \text{description},\ \text{parameters}\}
  2. name 字段工具在系统中的唯一标识，必须与注册的函数一一对应，相当于供应商的“短号”。
    name\text{name}
  3. description 字段用自然语言说明工具的能力、触发时机和用法，直接决定模型能否在恰当时机选中它。
    description\text{description}
  4. parameters 字段以 JSON Schema 格式声明每个参数的类型、是否必填、枚举取值等，相当于采购单上“数量必须填数字”的校规。
    parameters\text{parameters}

参数生成：把需求翻译成采购明细

客人说“想吃点清淡的”，主厨要把它翻译成一张具体清单：鲈鱼一条、一斤、活杀。如果翻译错了，比如写成一斤花椒，后厨就全乱套了。参数生成（Parameter Generation）就是这个“翻译”环节：模型把用户口语化的请求，填进工具参数里，输出一纸标准化的 JSON 采购单。

参数生成本质上是一个条件生成问题：模型同时“读”两样东西——用户的输入和工具的 JSON Schema——然后猜出最合理的一组参数。它之所以有难度，是因为要在几十个候选字段里选对名字，还要把口语中模糊的“北京”、“-3 度”等表达映射成 tool 规定的数据类型。

用概率语言描述，模型在备选参数集合中，搜索能最大化“合理性得分”的那一组：

主厨的翻译功夫不是天生的——他得熟记每种食材的规格表，才能把“随便来点”这种含糊需求，变成供应商听得懂、拿得准的采购明细。参数生成的质量，决定了你的 Agent 是“懂事的帮厨”还是“糊涂的临时工”。

args∗=arg⁡max⁡args Pθ(args∣query, schema)\text{args}^{*} = \underset{\text{args}}{\arg\max}\ P_{\theta}(\text{args} \mid \text{query},\ \text{schema})
模型不是在“查表”，而是在“创作”参数：它在所有可能的参数组合里，挑一个在用户请求和工具约束下最像正确答案的组合。
  1. 最优参数记号args\* 表示模型最终选出的“最合理”参数组合，也就是写入函数调用的那段 JSON。
    args∗\text{args}^{*}
  2. argmax 运算在所有候选参数组合中挑出使概率最大的那一组，是一个“优中选优”的搜索过程。
    arg⁡max⁡args\underset{\text{args}}{\arg\max}
  3. 条件概率分布Pθ 表示在用户请求与工具 Schema 的双重约束下，某组参数出现的概率，θ 是模型自身的权重。
    Pθ(args∣query, schema)P_{\theta}(\text{args} \mid \text{query},\ \text{schema})

ReAct 循环：想-做-看的烹饪工作流

真正的主厨从不写“一次性采购单”，而是边做边看：先想今晚主打什么（Thought），去冰箱拿食材或下单（Action），看看成色、尝尝味道（Observation），不行再调整。这个“想-做-看”的循环，就是 ReAct——“推理”（Reasoning）与“行动”（Acting）的交替进行。

在技术层面，ReAct 把一次性的问答拉长成一个循环：每一步，模型都基于当前状态——包括之前的思考、动作和观察结果——决定下一步动作；工具执行后产生观察；观察又被追加进上下文，成为下一步推理的新依据。循环会一直持续，直到模型认为信息足够，给出最终答案。

形式化地看，每一步都包含两个关键更新：

主厨从不把整桌菜一口气做完再检查，那样八成会翻车。ReAct 的意义在于“每走一步都看一眼锅”，让大模型的每次行动都有真实反馈兜底——这是 Agent 可靠性的地基。

Actiont=πθ(Thoughtt∣st),Observationt=Env(Actiont)\text{Action}_t = \pi_{\theta}(\text{Thought}_t \mid s_t), \quad \text{Observation}_t = \text{Env}(\text{Action}_t)
s_t 是不断累积的“状态记忆”，πθ 是模型决策策略，Env 是外部工具环境。行动改变世界，观察反馈行动，这就是循环的动力。
  1. 行动决策Action_t 是第 t 步模型决定采取的动作，通常体现为一次函数调用，由当前状态和思考共同决定。
    Actiont=πθ(Thoughtt∣st)\text{Action}_t = \pi_{\theta}(\text{Thought}_t \mid s_t)
  2. 状态累积s_t 把历史的一切想法、动作、观察串成上下文，让推理拥有“记忆”，避免模型“失忆”。
    st=(st−1, Observationt−1)s_t = (s_{t-1},\ \text{Observation}_{t-1})
  3. 环境反馈Observation_t 是工具执行后的真实返回结果，被追加进上下文，成为下一步推理的依据。
    Observationt=Env(Actiont)\text{Observation}_t = \text{Env}(\text{Action}_t)

数据训练：厨师学校的标准菜谱

新厨师怎么学会“想-做-看”？去看师父怎么操作，一招一式记下来，反复模仿。工具使用能力的训练也是这样：先收集大量“名师示范”——用户提问、模型思考、工具调用、观察结果组成的完整轨迹，然后让大模型照着这些轨迹模仿学习，这种方法叫行为克隆（Behavior Cloning）。

这些轨迹数据从哪里来？一是人工标注：让熟练的模型（如 GPT-4）或人类专家写出正确的调用链；二是从真实 Agent 的运行日志中筛选高质量样本。经过统一的格式化后，就变成监督学习的训练集，这个过程对应业界常说的 SFT——有监督微调（Supervised Fine-Tuning），相当于用标准答案手把手教模型。

训练目标非常直观：让模型在同样的状态下，倾向于输出示范中出现的动作：

厨师学校的教材从来不是一张成品菜照片，而是记录全过程的操作录像。工具使用训练的精髓，也在于让模型从“知道答案”进化到“知道怎么一步步拿到答案”。

LSFT=−∑tlog⁡Pθ(Actiont∣st)\mathcal{L}_{\text{SFT}} = -\sum_{t} \log P_{\theta}(\text{Action}_t \mid s_t)
这个损失函数在“奖励”模型模仿标准轨迹：示范里怎么调用的，模型也要学着怎么调用。学完格式之后，还可以用偏好优化让模型学会“选好工具”。
  1. 交叉熵损失L 衡量模型输出与示范动作之间的差距，差距越小，损失越低。
    LSFT=−∑tlog⁡Pθ(Actiont∣st)\mathcal{L}_{\text{SFT}} = -\sum_{t} \log P_{\theta}(\text{Action}_t \mid s_t)
  2. 对全部时间步求和轨迹中每一步都要学对，早期“想错了”不会被放过，后期“调对了”才会得到强化。
    ∑t\sum_{t}
  3. 对数条件概率模型在当前状态下选中示范动作的概率取对数，概率越高，损失贡献越小。
    log⁡Pθ(Actiont∣st)\log P_{\theta}(\text{Action}_t \mid s_t)

工具编排：一桌宴席的炒菜单

一桌十道菜的宴席，主厨不能做完一道再想下一道：蒸锅可以同时蒸两笼，烤箱里烤着羊排，炒锅旁边还炖着汤。多工具编排（Orchestration），就是主厨手里的“炒菜单”——统筹哪道菜先做、哪道菜能并行、哪道菜必须等上一道出锅。

当 Agent 面对复杂任务时，往往需要依次或并行调用多个工具。比如“明天北京适合穿什么”至少两步：先查天气，再根据天气数据生成穿搭建议。如果两个工具互不依赖（查天气 + 查空气质量），就可以并行调用节省时间。编排的核心，就是识别这些依赖关系。

建模上，一个复杂任务可以被分解为多个子任务：

若两个子任务之间没有数据依赖，则可以并行执行：

好主厨的炒菜单上，每道菜的入厨时间、灶台占用、出锅顺序都清清楚楚；好 Agent 的编排器，也会把“先查、再算、后汇总”安排得井井有条，绝不浪费一次 API 调用。

T=τ1→τ2→⋯→τnT = \tau_1 \rightarrow \tau_2 \rightarrow \cdots \rightarrow \tau_n
τi∥τj\tau_i \parallel \tau_j
"→“表示前一个工具的输出来自后一个工具的输入，”∥"表示两个工具可以同时发起。编排器负责识别这些关系、安排调度，并把结果汇总成答案。
  1. 总任务分解T 是复杂总任务，被拆解成 n 个有先后关系的子任务序列。
    T=τ1→τ2→⋯→τnT = \tau_1 \rightarrow \tau_2 \rightarrow \cdots \rightarrow \tau_n
  2. 依赖箭头→ 表示“必须先拿到前一步的输出”，例如穿搭建议必须等天气结果返回才能生成。
    →\rightarrow
  3. 并行子任务∥ 表示两个子任务互不依赖，可同时执行，最后再合并结果，节省等待时间。
    τi∥τj\tau_i \parallel \tau_j

错误恢复：食材缺货的临场应变

再周全的采购单，也可能收到供应商一句“今天没货”。主厨的应变方式有三种：换一家供应商（换个参数重试）、换等价食材（换一个工具）、或者问客人能不能换菜（向用户确认）。最忌讳的是对着同一个空货架傻等一百遍——那叫无限重试，除了浪费时间毫无意义。

工具调用失败是常态，不是意外：网络超时、参数类型错、API 变更、权限不足……错误恢复策略决定了 Agent 的稳定性。设计时首先要给错误分类：可重试的（超时、限流）与不可重试的（参数错误、权限不足，重试一万次也白搭）。关键原则是：每次重试都必须有“增量变化”。

若第 i 种策略的单次成功概率为 p_i，按策略依次尝试，总成功率会随尝试次数显著提升：

客人不会因为你偶尔缺货而生气，但会因为你对着空冰箱假装做出了一盘菜而发火。错误恢复的底线是诚实：重试要有章法，失败要敢承认，大模型的“临场应变”才配得上“可靠”二字。

P(success)=1−∏i=1k(1−pi)P(\text{success}) = 1 - \prod_{i=1}^{k}(1 - p_i)
k 是尝试次数。注意每次尝试都是“不同的打法”——修正参数、换工具、降级方案——而不是原样重发。达到上限仍失败时，应当如实告诉用户，而不是编造一个结果。
  1. 单次失败率(1 - p_i) 表示第 i 次尝试失败的概率，它是总成功率公式的原料。
    (1−pi)(1 - p_i)
  2. 全失败概率把 k 次尝试的失败率连乘，得到“所有策略都失败”的概率。
    ∏i=1k(1−pi)\prod_{i=1}^{k}(1 - p_i)
  3. 总成功率用 1 减去“全失败”概率，得到至少一次成功的总概率。
    P(success)=1−∏i=1k(1−pi)P(\text{success}) = 1 - \prod_{i=1}^{k}(1 - p_i)

Agent 应用：从后厨走向大堂

当家好餐厅已经训练好厨师、设计好采购单、打磨好应急流程，剩下的就是把这一切变成客人桌上的菜。Agent 应用实践，就是主厨把所有本领整合成一套稳定的“出餐系统”——把前面讲到的能力边界、接口设计、参数生成、ReAct 循环、数据训练、工具编排和错误恢复，组装成一个真正能用的产品。

一个真正落地的 Agent 产品——智能客服、数据分析助手、个人助理——都在做同一件事：对外表现为“一个懂事的助手”，对内则是 Function Calling 的参数生成、ReAct 的循环推理、训练好的工具选择、多工具编排与错误恢复的有机配合。任何一个环节掉链子，用户感知到的都是“这个助手不好用”。

工程上，衡量 Agent 是否可靠，最常用的指标是任务完成率：

客人不会关心厨房里用了多少口锅、多少种调料，只关心菜好不好吃、上得快不快。Agent 应用也是同理：用户只感知最终效果，而效果的根基，正是我们前面讲到的每一个环节——这，就是工具使用能力从原理走向价值的全过程。

R=N成功N总R = \frac{N_{\text{成功}}}{N_{\text{总}}}
N_总 是测试任务总数，N_成功 是端到端顺利完成的次数。这个指标是前面所有环节的“体检报告”。
  1. 完成率定义R 是端到端任务完成率，越高代表 Agent 越可靠，越接近生产可用。
    R=N成功N总R = \frac{N_{\text{成功}}}{N_{\text{总}}}
  2. 成功任务数N_成功 是所有工具调用、推理步骤都顺利走完、答案正确的任务数量。
    N成功N_{\text{成功}}
  3. 任务总数N_总 是测试集中任务的总数量，用于把完成数归一化为比例。
    N总N_{\text{总}}

AI 应用场景

智能客服查单

阶段：应用部署与工具调用

解决的问题：传统客服大量依赖人工查询物流与订单，纯 LLM 客服又只会话术模板，遇到“我的快递到哪了”就只能含糊其辞。接入订单查询 API 后，模型先通过 Function Calling 生成 {order_id: "12345"}，调用物流系统，再把真实轨迹组织成人话回复，把“猜”变成“查”。

具体案例：某电商平台智能助手收到“上周买的耳机到哪了”，先调用身份解析工具确认用户 ID，再调用物流查询工具获得“已到达本市分拣中心”，最后生成回复并主动附上配送时间预估。整条链路就是 Think → Action → Observation 的 ReAct 循环在真实产品中的一次缩影。

数据分析 Agent

阶段：多工具编排

解决的问题：数据分析师大量时间耗在写 SQL、调接口、画图表上；Agent 把“查表 → 计算 → 可视化 → 解读”编排成自动化流水线，让非技术人员也能用自然语言完成分析。

具体案例：运营提问“这个月哪个城市转化率最高”，Agent 先调用元数据工具确认表结构（Observation），再调用 SQL 工具执行聚合查询（Action → Observation），最后调用绘图工具生成柱状图，并附一段结论解读。工具之间是严格的顺序依赖关系，正是多工具编排的典型应用。

个人生活助手

阶段：端到端 Agent 与错误恢复

解决的问题：个人助理要完成“明早 7 点打车去机场”这类任务，需要闹钟、天气、打车三个工具按依赖协作；若打车 API 超时，还要有错误恢复策略兜底。

具体案例：语音助手先查天气（判断是否提醒带伞）、设置闹钟，再调用打车工具；若首选打车品牌返回超时（可重试错误），自动修正请求或切换备用品牌（等价工具降级），成功后再汇总时间、车牌号与提醒事项。这正是错误恢复三策略——修正参数、换工具、如实反馈——的组合演练。

Python 演示

python95 行
import re  class MockLLM:    """模拟大模型按 ReAct 格式生成思考与动作"""     def __init__(self):        self.call_count = 0     def reason(self, prompt, tools):        self.call_count += 1        if self.call_count == 1:            return 'Thought: 用户想知道北京天气，先查天气。\nAction: get_weather(city="北京")'        if self.call_count == 2:            return 'Thought: 天气已知，再计算 23*7。\nAction: calculator(expr="23*7")'        return 'Thought: 信息已齐全。\nAnswer: 北京晴 25 度，23*7=161。'  class ToolAgent:    """可注册工具并执行 ReAct 循环的最小 Agent"""     def __init__(self):        self.tools = {}        self.history = []        self.llm = MockLLM()     def register_tool(self, name, func, description, parameters):        self.tools[name] = {            "func": func,            "description": description,            "parameters": parameters,        }     def schema(self):        return [            {"name": n, "description": t["description"], "parameters": t["parameters"]}            for n, t in self.tools.items()        ]     def parse_action(self, text):        match = re.search(r'Action:\s*(\w+)\((.+)\)', text)        if not match:            return None, {}        name = match.group(1)        args = dict(re.findall(r'(\w+)\s*=\s*"?([^",)]+)"?', match.group(2)))        return name, args     def execute(self, name, args):        if name not in self.tools:            return 'Error: 工具不存在'        try:            return self.tools[name]["func"](**args)        except Exception as exc:            return 'Error: {}'.format(exc)     def run(self, prompt, max_steps=5):        steps = []        final_answer = ''        for _ in range(max_steps):            raw = self.llm.reason(prompt, self.schema())            self.history.append(raw)            if 'Answer:' in raw:                final_answer = raw.split('Answer:')[-1].strip()                break            name, args = self.parse_action(raw)            observation = self.execute(name, args)            steps.append({'tool': name, 'args': args, 'observation': observation})            prompt += '\nObservation: {}'.format(observation)        return {'steps': steps, 'final_answer': final_answer}  def get_weather(city):    table = {'北京': '晴 25 度', '上海': '小雨 22 度'}    return table.get(city, '未知城市')  def calculator(expr):    return str(eval(expr))  # 仅用于教学演示  if __name__ == '__main__':    agent = ToolAgent()    agent.register_tool(        'get_weather', get_weather,        '查询指定城市的实时天气', {'city': '城市名称'}    )    agent.register_tool(        'calculator', calculator,        '计算数学表达式结果', {'expr': '数学表达式'}    )    result = agent.run('北京天气怎么样？顺便算一下 23*7')    for i, s in enumerate(result['steps'], 1):        print('Step {}: 调用 {}，参数 {}'.format(i, s['tool'], s['args']))        print('  观察: {}'.format(s['observation']))    print('最终回答: {}'.format(result['final_answer']))
目的：用几十行代码实现一个最小的 ReAct Agent——注册工具、让“模型”按 Thought+Action 格式输出、解析并执行调用、把观察结果追加回上下文，最终生成答案。跑一遍就能直观感受 Function Calling 与 ReAct 循环的完整链路。
  1. class MockLLM:封装一个“假大模型”，用 call_count 分步返回 ReAct 输出，让你在没有真实模型时也能体验完整循环。
  2. return 'Thought: ...。\nAction: get_weather(city="北京")'模型按 Thought + Action 的固定格式输出动作，这是 ReAct 的结构约定。
  3. self.tools[name] = {...}注册工具：把函数对象与描述、参数 Schema 绑定，相当于给采购员一份供应商通讯录。
  4. re.search(r'Action:\s*(\w+)\((.+)\)', text)从模型输出中解析出工具名与参数，把“采购单”翻译成可执行的调用。
  5. observation = self.execute(name, args)执行工具并拿到真实结果，对应 ReAct 里的 Observation。
  6. prompt += '\nObservation: {}'.format(observation)把观察结果追加进上下文，状态累积是循环推理的关键。
  7. if 'Answer:' in raw:模型认为信息足够时输出最终答案，循环终止。

常见误区

误区“模型一旦开启 Function Calling 就能自己上网，什么都能查到。”

正解Function Calling 中，模型只输出“调用哪个函数 + 参数”的指令文本，真正的 API 请求由程序执行，结果再喂回模型。模型从头到尾没有联网，它只是写了张采购单，跑腿的是系统。主厨只管写单，送货是供应商的事。

为何常见：产品宣传常省略中间链路，加上“调用”二字会让人本能联想到联网请求，于是误解就产生了。

误区“注册几十个工具，模型自然能解决所有问题。”

正解工具过多会让模型在选型时“挑花眼”，描述含混还会互相干扰——就好比采购单上列了几十家供应商的电话，采购员反而不知道该打给谁。正确的做法是把每个工具描述写精准、参数约束写严格，必要时对工具做分组和路由。

为何常见：人们习惯默认“选项越多越好”，忽略了模型的选择器同样受上下文窗口和注意力机制的限制。

误区“多写几句'请思考，再行动，再观察'就是 ReAct 了。”

正解ReAct 是结构化的循环机制：模型的输出会被解析为正式动作并真实执行，观察结果真实地追加进上下文，状态逐轮累积。提示词只是表层，真正的关键是“行动被真实执行、结果被真实反馈”的闭环——就像主厨真的尝了菜，而不是脑补味道。

为何常见：ReAct 的实现常表现为“提示词加 if-else 循环”，初学者很容易把表象当成本质。

误区“错误恢复就是一直重试，重试多了总会成功。”

正解对参数错误、权限不足这类不可重试错误，重试一万次结果都一样，反而浪费算力和钱。正确的做法是先给错误分类、修正参数、换等价工具或降级，最后把失败如实告诉用户。前面公式 P = 1 - Π(1-pᵢ) 有个隐含前提——每次尝试都必须不同。

为何常见：工程上的“重试”是常见手段，人们很容易把它过度泛化到所有错误类型，忽略了“无意义重试”与“有章法重试”的本质区别。

面试题

Q1. Function Calling 中，大模型直接输出的是什么？

单选题 · easy

  • A.工具执行后的最终结果
  • B.工具调用后的返回数据
  • C.工具名称与参数的 JSON← 正确答案
  • D.数据库中的查询记录

答案：C。Function Calling 时模型只负责生成“调用指令”——函数名和参数组成的 JSON，真正的执行由系统完成。就像主厨写采购单，跑腿的是采购员，菜不会自己飞到厨房。A、B、D 都是执行之后的产物，不是模型的直接输出。

Q2. 工具定义中，description 字段的主要作用是？

单选题 · easy

  • A.供用户阅读的界面文案
  • B.帮助模型判断何时调用哪个工具← 正确答案
  • C.限制模型生成答案的长度
  • D.加密工具调用所需的密钥

答案：B。description 是给模型“读说明书”用的：描述得越清楚，模型越能在恰当的时机选中正确的工具。A 是面向用户的文案，C 与长度限制无关，D 与密钥无关，三者都不是 description 的职责。

Q3. ReAct 循环中，三个环节的正确顺序是？

单选题 · easy

  • A.先行动再思考再看结果
  • B.先看结果再思考再行动
  • C.先思考再行动再看结果← 正确答案
  • D.先行动再看结果再思考

答案：C。ReAct 先想（Thought）再动（Action），然后看结果（Observation）并进入下一轮。主厨也是先想菜谱、再动手、看成色。A、B 颠倒了因果，D 把行动放在了思考之前，都不符合循环逻辑。

Q4. 工具使用能力训练中的“行为克隆”是指？

单选题 · mid

  • A.用状态到动作的轨迹样本监督模型← 正确答案
  • B.让模型模仿人类作家的文风
  • C.复制其他模型的全部权重
  • D.用随机探索代替有监督数据

答案：A。行为克隆把“名师示范轨迹”——在什么状态下做了哪些动作——作为监督信号，让模型最大化 P(Action|state)，即“照师父的样子做”。B 是写作任务，C 是权重复制，D 是强化学习的探索思路，都不是行为克隆。

Q5. 以下哪些属于合理的错误恢复策略？

多选题 · mid

  • A.检测失败后修正参数再重试← 正确答案
  • B.换用功能等价的备用工具← 正确答案
  • C.原样无限次重复同一请求
  • D.告知用户并提议降级方案← 正确答案

答案：ABD。错误恢复要求“每次尝试有增量变化”：修正参数（A）、换等价工具（B）、降级并告知用户（D）都是正确做法。C 是无意义重试，就像对着同一个空货架反复下单，只会浪费资源。

Q6. 若工具 B 必须拿到工具 A 的输出才能执行，应当如何处理？

单选题 · mid

  • A.同时并行调用 A 和 B
  • B.按依赖顺序先 A 后 B← 正确答案
  • C.随机选一个先执行
  • D.只调用 B 忽略依赖

答案：B。存在数据依赖时，必须先执行 A 拿到结果，再把结果作为 B 的输入，这是编排中的顺序调用。并行（A）只在没有依赖时可用；C 和 D 必然导致 B 因缺输入而失败。

Q7. 关于 Function Calling 的接口设计，正确的做法有哪些？

多选题 · hard

  • A.JSON Schema 约束参数类型← 正确答案
  • B.描述写清触发场景与用法← 正确答案
  • C.工具参数越多能力越强
  • D.返回结果结构化便于推理← 正确答案

答案：ABD。A 保证参数可校验，B 帮助模型选对工具，D 让观察结果更容易被推理利用，都是好实践。C 是常见误区：参数冗余会增加生成出错的概率，就像采购单上写满无关字段只会添乱。

Q8. 在 ReAct 框架中，Observation 指的是什么？

单选题 · mid

  • A.模型内部的随机猜测值
  • B.训练样本的人工标注标签
  • C.用户预设的最终答案文本
  • D.工具执行后返回的环境反馈← 正确答案

答案：D。Observation 是工具执行后的真实结果，被追加到上下文中供下一步推理使用。主厨尝的那口菜就是 Observation——是真实的，不是脑补的。A、B 与循环机制无关，C 不属于循环的定义。

Q9. 提升模型工具选择能力的训练方法有哪些？

多选题 · hard

  • A.用高质轨迹做行为克隆← 正确答案
  • B.偏好优化学选正确工具← 正确答案
  • C.工具描述加入冗余文字
  • D.真实环境收集运行反馈← 正确答案

答案：ABD。A 是 SFT 监督学习，B 是 RLHF/DPO 偏好优化，D 是从真实 Agent 日志和运行反馈中学习，三者都能提升工具选择能力。C 是干扰项：冗余描述会稀释语义，反而干扰选择。

Q10. 参数生成时 P(args|query,schema) 很低却仍被采样，最可能造成的后果是？

单选题 · extreme

  • A.格式正确但语义荒谬的幻觉调用← 正确答案
  • B.模型参数的梯度消失问题
  • C.上下文窗口被自动扩大
  • D.工具返回结果的自动合并

答案：A。低概率采样意味着模型“没把握但硬答”，最容易生成类型都对、含义离谱的参数——比如把城市名填成“红烧肉”。梯度消失是训练问题，上下文扩大与结果合并都是机制层面的行为，与采样语义无关。