6.1 Agent如何工作：推理循环与工具调用

6.1 Agent 如何工作：推理循环与工具调用

Agent 的运行机制是一个循环：模型读到问题与工具清单 → 决定"调哪个工具、传什么参数" → 平台执行工具并把结果喂回去 → 模型决定"够不够回答，不够就再调" → 直到给出最终答案或撞上迭代上限。Function Calling 与 ReAct 是实现这个循环的两种策略，前者靠模型原生能力，后者靠提示词里的思考格式。

第 6 章开篇。本节先建机制认知（不动手），6.2 才开始写工具。理解循环是后面一切调优的前提——不知道 Agent 每步看见什么信息，就永远在玄学调参。

一个需求看清一个循环

需求场景：用户问"我上周买的空气炸锅怎么还没到"。这个问题的答案不在知识库里（第 4 章管政策），也不在预定义流程里（第 5 章的流水线管转单）——它需要先知道是哪个订单，再查物流状态，两步的先后和参数传递要现场判断。这正是 Agent 的主场。

复盘一次真实的循环（工具是 6.2 将要定义的查订单与查物流）：

第 1 轮
模型可见：系统提示词 + 问题 + 工具清单（两个工具的名称与描述）
模型决策：信息不足，调用 query_order，参数 user_msg="上周买的空气炸锅"
平台动作：执行工具，返回 {order_id: "SO-1024", status: "已发货"}

第 2 轮
模型可见：上一轮全部内容 + 工具返回结果
模型决策：拿到订单号但物流细节不够，调用 query_logistics，
          参数 order_id="SO-1024"
平台动作：执行工具，返回 {carrier: "顺丰", latest: "8月25日到达杭州转运中心"}

第 3 轮
模型可见：前两轮全部内容 + 两次工具结果
模型决策：信息齐了，不再调用工具，直接输出最终回答
最终回答：您的空气炸锅已发货，顺丰承运，8月25日到达杭州转运中心，
          预计明天送达……
​

三轮，两次工具调用，一次收口。注意两个细节：其一，每轮模型看到的都是完整历史——所以循环越长，单轮输入 token 越多，成本近似线性上涨；其二，第 3 轮"不调工具直接回答"是一个显式决策，好的 Agent 知道什么时候停，差的 Agent 会继续乱调。

图 6-2：推理循环的三个决策点与信息流

Function Calling 与 ReAct：两种循环策略

同一个循环，两种驱动方式，Dify 在 Agent 设置里可选：

Function Calling（函数调用）。模型厂商在模型层面内置的能力：把工具清单作为特殊字段随请求发出，模型直接输出结构化的调用意图（工具名加参数 JSON）。判断与表达都在模型内部完成，干净、快、不易出格式错误。前提是模型支持——用它之前确认你所选的模型在能力清单里。

ReAct（推理加行动）。不依赖模型内置能力，靠提示词约定一套"思考-行动-观察"文本协议：模型先写一段思考（Thought），再写行动（Action 指明工具与参数），平台解析文本执行，把结果作为观察（Observation）拼回对话，循环往复。兼容性极好（任何能对话的模型都能跑），代价是多耗 token（思考文本也要算钱）、解析偶发失败。

选择口径一句话：模型支持就优先 Function Calling；模型不支持、或你需要看清每步思考做排障，用 ReAct。小艺用的模型支持函数调用，本章后面均以 Function Calling 为准，但循环逻辑两种策略完全同构。

从运行记录读出"它为什么这么选"

Agent 的运行记录（日志里每次会话的工具调用轨迹）是最被低估的调优资料。读法：逐轮问三个问题——这轮它看见什么（历史与返回）、它选了什么（工具与参数）、这个选择合理吗。选错了不要归因于"模型笨"，九成能在三处找到根因：工具描述有歧义（两个工具都像是对的）、工具返回信息缺失（拿不到订单号只好再调一次）、系统提示词没约束（没告诉它"查到一次就别再查"）。这三个根因分别对应 6.2 与 6.3 的处方。

问题：Agent 的"思考"能看见吗？

能，而且建议第一次就去看。调试面板里展开一次 Agent 会话，可以看到每轮的中间过程（Function Calling 模式下是调用意图与参数，ReAct 模式下还有显式的思考文本）。看中间过程的收益是巨大的：你能直观看到模型"以为"自己在干什么——它把"订单"理解成了什么、它预期工具返回什么。ReAct 的思考文本在这点上更友好，即便生产用 Function Calling，排障期切到 ReAct 看一轮思考，常常比猜半天更快找到根因。

问题：一轮里能同时调多个工具吗？

取决于平台版本与模型能力——较新的模型支持一次输出多个调用意图（并行工具调用）。对 Agent 的意义是省轮次（查订单与查物流若参数都已齐，可以一轮并发）。但要泼一盆冷水：并行调用对工具之间的依赖关系没有保护，若工具 B 的参数依赖工具 A 的返回，并行就会拿到空值。保守策略是把并行留给真正独立的只读查询，有依赖的链路保持串行——稳定性永远优先于那几秒的提速。

⚠️ 常见坑：把 Agent 当更聪明的聊天助手——什么问题都丢给它。循环机制决定了 Agent 单问的成本与延迟都高于普通对话（多轮模型调用加工具执行），纯政策问答走第 4 章的检索链路又快又便宜。Agent 只为"需要现场决策动作路径"的问题付费。

💡 关键直觉：Agent 不是更高级的模型用法，而是把决策权外包给模型的架构。外包出去的每一分控制权，都要用防护栏（6.3）赎回来一部分——这笔账在架构评审时就要算清。

本节要点回顾

• 循环三要素：决策（调不调、调哪个、停不停）→ 执行（平台调工具）→ 回填（结果进历史），直到收口或撞上限；
• 每轮历史全量可见：token 成本随轮数线性上涨，长循环即高账单；
• 两种策略：Function Calling 靠模型原生能力、快而稳；ReAct 靠文本协议、兼容性好但费 token；
• 选错工具的三个根因：描述歧义、返回缺信息、提示词没约束——都不是"模型笨"；
• 运行记录是调优金矿：逐轮看"看见什么、选了什么、合理吗"。

机制清楚了。下一节把公司的查订单、查物流接口包成 Agent 用得顺手的工具——写好工具定义，循环的第一步就赢了一半。