AI Agent 究竟如何运转：一次工具调用的完整循环拆解

当你问一个产品「它是 AI agent 吗」，答案往往藏在你的问题和它的回复之间那几十行看不见的代码里。Anthropic 的文档把这件事说得很清楚：模型自己从不执行任何操作。它只写下请求，真正去跑的是你写的代码。

从聊天机器人到 Agent：只差一张工具清单

普通聊天机器人的逻辑很单调——文字进，文字出，世界里什么都没发生。Agent 的出现只多加了一样东西：在发送消息的同时，你给模型附上一份「允许调用的工具清单」。

关键在于默认设置下的一个细节：Claude 会在每一轮自行决定是调用工具还是直接回答。这个「逐轮决策」是后面所有复杂性的根源。

这个思路有明确源头。2022 年 10 月的一篇 React 论文提出，模型应当把推理和行动交错输出，由行动从外部拉取信息。不过真正决定产品行为的不是论文，而是机制本身。

什么是「工具」（tool）？ 在 LLM 语境下，工具并不是模型自身拥有的能力，而是宿主应用提前注册、声明好参数 schema 的外部函数。常见工具包括搜索引擎、代码执行沙箱、数据库查询、文件读写、HTTP 请求等。模型并不运行这些函数，它只输出一段符合工具 schema 的结构化 JSON，比如 {"name": "get_weather", "input": {"city": "X"}}。宿主应用解析这段 JSON、真正执行函数、再把返回值包成 tool result 块回灌给模型。因此工具的边界完全由开发者划定：模型只能请求清单里列出的工具，任何未声明的操作它都无法触发。这也解释了为什么工具清单既是能力清单，也是权限清单。

什么是 React 论文？ 2022 年 10 月的 ReAct（Reasoning + Acting）论文提出了一种提示范式：让模型交替输出「推理轨迹」和「行动」，行动从外部环境拉取事实反馈，再把反馈拼回上下文供下一轮推理使用。它把过去分离的「思维链推理」和「工具调用决策」合并进同一个生成过程。ReAct 之所以被反复引用，是因为它第一次系统性地说明了「推理—行动—观察」这个交错的循环结构，而这正是今天所有 agent 循环的骨架。不过要注意，ReAct 是提示层面的方法，与厂商 SDK 里 max_turns 之类的机制是两回事：决定产品行为的是后者。

一行一行看 Agent 循环

把整个循环拆成四条泳道：模型、宿主应用（包裹模型的程序）、你的代码、工具。任务很简单——比较城市 X 和城市 Y 哪个更暖，然后存一条笔记。

• 第 1 行：宿主应用把你的问题和工具清单一起发给模型。
• 第 2 行：模型返回的不是答案，而是一个 tool use 块，stop reason 标记为 tool use。这是请求，不是行动。
• 第 3 行：宿主应用读取请求并调用工具。此时工具泳道亮起，模型泳道保持黑暗。
• 第 4 行：宿主应用把工具输出作为 tool result 块，连同已有对话一起发回模型。

第二轮循环开始。模型看到第一个城市的温度后，请求第二个城市的数据，同样的模式重复一遍。

第三轮请求保存笔记。当模型终于掌握全部信息，stop reason 变为 end turn，回复是纯文本——这就是停止信号。

翻译成代码就是一句话：只要 stop reason 还是 tool use，就继续循环。Anthropic 文档还列了其他出口：end turn、max tokens、stop sequence、refusal。这些不必背诵，重点在于——这就是普通的程序控制流，没有任何神秘之处。

谁来决定下一步？这是区分 Agent 和 Workflow 的唯一测试

既然模型只提请求，循环由代码执行，那停下来的是谁？Anthropic 把 agent 描述为「每一步都从环境获取 ground truth（比如工具结果）」，并设有停止条件，比如最大迭代次数。另一家 SDK 里对应的设置叫 max turns。

现在做一次替换实验：同样的任务、同样的工具，但把决策权从模型手里拿走。代码框写死——第一步查城市 X，第二步查城市 Y，第三步保存。模型只负责在固定步骤里填文本。

Anthropic 给这两种形态起了名字：workflow 是 LLM 和工具通过预定义代码路径编排的系统；agent 是 LLM 动态指挥自身流程和工具使用的系统。改变的既不是工具也不是模型，只是「谁决定下一步」。

Anthropic 还列出五种 workflow 模式：prompt chaining、routing、parallelization、orchestrator workers、evaluator optimizer。最后一种让一个模型生成、另一个模型评估，本身就在循环里。所以循环本身并不构成 agent，真正的判据是谁在做决定。

五种 workflow 模式的简要说明：

• prompt chaining（提示链）：把任务切成有序的若干步，每一步的模型输出作为下一步的输入，路径固定。
• routing（路由）：先由一个分类步骤判断输入属于哪一类，再分派给对应的下游处理链，路径由分类结果决定但分支是预设的。
• parallelization（并行化）：把任务拆成互不依赖的子任务同时跑，或让同一任务跑多遍再投票汇总。
• orchestrator workers（编排者—工作者）：一个「编排」模型把任务分解成子任务，分派给若干「工作者」模型执行，最后汇总结果。
• evaluator optimizer（评估者—优化者）：一个模型生成答案，另一个模型评估并给出反馈，生成方据此修改，反复迭代。

这五种模式都是预定义的代码路径，即便像后两种内部含有循环，循环的进出条件、迭代次数和角色分配仍由代码写死，模型没有中途改变流程的权力。因此它们属于 workflow 而非 agent。这个区分对工程决策很重要：workflow 更可预测、成本更可控，agent 更灵活但更难调试。

为什么同样的循环更贵、更容易出错

看 trace 是如何膨胀的：每一轮都携带此前的完整对话。而 Anthropic 的计费文档说明，计入 token 的远不止你说的话——工具定义、tool use 块、tool result 块都算，还会额外附加一段内置的工具使用提示。

Anthropic 在自己的研究系统上测过一个数字：agent 消耗的 token 约是聊天模式的 4 倍，多 agent 系统约为 15 倍。这是一个厂商、一个系统的数据，并非普适常数。

膨胀的不只是账单，还有模型的上下文窗口。Anthropic 称之为 context engineering，定义为「在推理过程中策展和维护最优 token 集合」，其观点是 token 堆积会拉低召回率，模型的注意力预算是有限的。

这是不是一家之言？Chroma 测试了 18 个模型，报告称性能随输入增长而愈发不可靠——但那是商业报告，未经同行评审，且任务被刻意简化。peer-reviewed 的 2023 年论文 Lost in the Middle 发现，模型在相关信息位于开头或结尾时表现最好，位于中间时更差。

需要说清楚：这两份来源都没能确立「效应在当今最强模型上究竟有多大」。两篇论文针对的是较老的模型。

什么是 context engineering（上下文工程）？ Anthropic 把它定义为「在推理过程中策展和维护最优 token 集合」，即把上下文窗口当成一种有限且昂贵的资源来主动管理，而不是把能塞的东西都塞进去。它的核心假设是：模型的注意力预算是有限的，token 堆积越多，对关键信息的召回率就越低。相关工作包括上下文压缩（把长历史摘要成短文本）、外部化记忆（把笔记存到窗口之外，按需检索）、结构化的工具结果截断，以及给子任务分配独立的干净窗口。它与 prompt engineering 的区别在于关注对象：前者关注“放什么进窗口、怎么维护”，后者更关注“怎么说这一句话”。

团队实际怎么应对上下文压力

Anthropic 给出四种战术：接近上限时总结历史然后重启；把笔记存在窗口外，需要时拉回；用 sub-agent 给它一个干净的窗口，只取回简短摘要；以及 just-in-time retrieval，在需要的那一刻才拉取信息。

关于加更多 agent，Anthropic 自己有一个提醒：它们适合能切成并行片段的工作，但当每个 agent 都需要同一份上下文时并不合适。

下次看 Agent 演示时该问的三个问题

1. 每一步里，是谁选择了下一步做什么？你的代码还是模型？
2. 什么让循环停下来？
3. 每一轮额外循环的代价是多少？

Anthropic 的建议是找到最简单的方案，只在必要时增加复杂度，并警告 agent 的自主性意味着更高成本和复合错误的可能。

有两个问题这次没有展开：agent 读到不该信任的内容时会发生什么？当 agent 数量变多时又会怎样？