1.3 为什么它必须连续多次调用模型
一句话结论：因为模型只能看见「上下文里有的东西」，而工具的结果只有通过新的一次调用才能进入上下文。这条硬约束决定了 Agent 的成本、延迟，也决定了「上下文」为什么是它的能力天花板。
读这篇之前
需要先读 1.1（一次性调用为什么只能猜）和 1.2（四模块与闭环）。
一、一个真实的困境
先说一个比喻，它比任何定义都更能说明问题。
假设一位天才工程师空降你的团队。他理论功底深厚、编程能力卓越，但对你们的产品架构、业务逻辑、技术债务、团队规范一无所知——更糟的是，关键决策散落在老员工记忆里，代码库也几乎没文档。
这位天才即便智力超群，也很难真正发挥作用。
这正是当前 Agent 面临的困境。[原文 4668]
大模型在标准测试里成绩亮眼，一到真实业务场景就常常掉链子。原因不复杂：要执行具体任务，模型需要通用训练数据里根本没有的背景信息——产品架构、业务规则、内部约定。
以「帮我修复这个 bug」为例，Agent 结果的差异几乎全部来自上下文质量：[原文 4668]
| 上下文类别 | 具体内容 | 缺了会怎样 |
|---|---|---|
| 实时代码上下文 | 目录结构、模块职责、核心数据结构、代码规范 | 代码语法正确但风格与项目格格不入 |
| 流程规范 | Git 分支策略、提交规范、审查流程、CI/CD 要求 | 直接往主分支提交未经测试的代码 |
| 环境信息 | 开发环境配置、测试库地址、密钥管理 | 本地跑通，测试环境立刻崩 |
这里有一句来自 OpenAI 研究员的判断值得记住：
「人和模型一样，最重要的是 Context。」——他在 OpenAI 的工作「没有那么难，换一个拥有他全部 context 的人也能干」。[原文 4668]
决定 Agent 业务价值的往往不是模型参数量，而是它每个决策点能拿到多丰富、多精准的上下文。
这也顺带解释了一个组织层面的现象：大多数团队的关键知识是隐性的——架构决策只在老员工脑子里、业务规则靠口口相传。对远程工作友好的团队往往也对 Agent 友好，因为它们的讨论公开、决策有记录。Agent 就像一个永远的新员工：给足背景它能干得很好，什么都不告诉它，再聪明也白搭。所以构建 AI 原生团队，首先是一场文档化运动。[原文 4668]
二、模型到底「看见」了什么
要理解为什么要多次调用，得先精确知道模型每次能看见什么。
每次调用模型，你实际上是在发送一个消息列表（messages），每条消息带一个角色（role）：
| 角色 | 谁写的 | 作用 |
|---|---|---|
| system | 开发者 | 定义身份、行为规则、约束。模型视为最高优先级指令，通常只有一条、放在最前 |
| user | 终端用户 | Agent 需要响应的请求 |
| assistant | 模型自己（历史） | 之前的回复，含文本和工具调用请求 |
| tool（或等价机制） | 工具执行结果 | 把工具返回值交回模型 |
模型在生成下一次回复时，能看到的全部内容就是这个消息列表。[原文 4668]
这就是那条硬约束：
模型看不见消息列表之外的东西。 没有例外。
三、由此推出：为什么必须多次调用
现在把上一节和 1.1 的案例放在一起，逻辑链就闭合了：
① 模型判断"需要看日志" ← 只依赖目前消息列表里的信息
② 系统真的去读日志（模型自己不能读）
③ 日志内容要被放进消息列表 ← 关键：这一步需要一次新的调用才能生效
④ 模型看着含日志的新消息列表，继续判断
第 ③ 步是全部原因。 工具的执行发生在模型外面，执行结果必须以新消息的形式追加进列表，而模型要利用这个结果，就必须再推理一次。
所以：
工具结果的条数 + 判断的轮数 ≈ 模型调用次数。
一个查三次数据的任务，至少三次调用。这不是设计缺陷，是当前架构的必然：
| 想做的事 | 需要几轮 | 为什么 |
|---|---|---|
| 直接回答 | 1 轮 | 信息已在列表里 |
| 查一次再答 | 2 轮 | 第一轮决策+调用，第二轮看结果回答 |
| 查→发现不对→再查→答 | 3-4 轮 | 每一轮的新发现都要重新推理 |
两个直接后果
后果一：成本随轮数线性增长。
每一轮都是一次完整推理，输入包含整个消息列表（含之前所有工具结果）。轮数越多，输入越长，单轮也越贵。这是 Agent 成本难以预测的根源。
后果二：延迟随轮数累积。
用户感受到的等待时间是所有轮次之和。这也是为什么「把推理做快」和「减少轮数」是两条独立的优化路径（见 1.2 第六节）。
四、Agent 与环境的闭环
前面一直在说「工具」，但更准确的视角是把工具看成与环境交互的接口。
在控制论与强化学习的经典视角下，Agent 与 Environment 是闭环交互的两方，而不是彼此的组成部分：[原文 4567]
┌──────────── 观察（Observation）────────────┐
↓ │
┌─────────┐ ┌──────────────┐ ┌─────────┐ │
│ Agent │───→│ 决策/行动 │───→│ 环境 │────┘
└─────────┘ └──────────────┘ └─────────┘
三个词的定义要摆清楚：[原文 4567]
- LLM 是大脑：不只是模型参数，而是整个决策内核——理解意图、思考规划、做出判断。它的能力来自两部分：预训练积累的世界知识与语言能力，以及后训练固化的决策策略（第 18 章展开）。
- 上下文是眼睛：不只是输入的那段文本，而是 Agent 在每个决策点收到并保留的信息表示——环境观察、用户记忆、领域知识、自身状态、任务进展。
- 工具是手脚：用来感知或改变外部世界的接口，包括工具定义、调用协议和适配器——从预定义的工具调用，到动态生成代码，到委托子 Agent，到主动与用户沟通。
换成更直白的说法：
Agent = 大脑 + 眼睛 + 手脚 [原文 4567]
注意公式里那句限定：这个公式只描述 Agent 边界之内的实现，不包含它与之交互的环境。 加上「不包含环境」这个限定很重要，因为很多讨论把「环境」也算进 Agent，结果把「Agent 变笨了」和「环境给的信息不对」混为一谈——而这两者的修法完全不同。
五、一个反直觉的推论：上下文是天花板
既然模型只能看见上下文里的东西，那就有一个直接推论：
Agent 的能力上限，不是模型智商，而是它在每个决策点能看到什么。
这句话有三个可操作的延伸：
延伸一：提升 Agent 表现，先看上下文，再看模型。
换更强的模型往往只是小幅改善；补上缺失的上下文（项目规范、领域知识、历史决策）常常带来质变。前者贵且不可控，后者便宜且可积累。
延伸二：上下文有容量上限，所以「给更多」不是解法。
上下文窗口是硬限制，而且越长越贵、越容易稀释注意力（第 2 章详述）。所以真正的工程问题不是「塞多少」，而是「塞哪些」——这正是第 5 章「上下文工程」的主题。
延伸三：上下文会污染。
工具返回的内容里可能夹带误导信息（网页里的一句话、文件里的一段注释）。一旦进入上下文，模型就可能当真。这是第 14 章要处理的安全问题。
六、这套架构还有哪些做不到的事
四模块 + 多次调用能办成很多事，但有三个结构性限制值得现在就摆出来，因为它们不是"实现得不够好"，而是当前架构的天花板。
限制一：不会从经验里学习
每次任务结束，那些踩过的坑、试出来的窍门，大多随着上下文一起被丢掉。下次同类任务，它还是会踩。
原文对此有一个很到位的比喻：今天的模型更像一个记性极好、却学不会新东西的天才——训练时把人类知识背得滚瓜烂熟，上岗后却几乎不再成长。[原文 4577]
要突破这一点，有两条路：一条是把经验沉淀成可检索的记忆（第 6 章），另一条是通过评估 + 后训练把能力写进参数（第 13、18 章）。前者便宜、见效快，后者昂贵、见效慢但更彻底。
限制二：交互是回合制的
绝大多数 Agent 仍是「你说完一句，它想一整段，再一次性吐出结果」。但真实世界不会停下来等它想完——话会被打断、画面在变、邮件在来。[原文 4577]
走向实时性有两条并行推进的路：
- 架构上做快慢分离：实时与智能几乎是两条正交的轴，单一模型难以兼顾。于是让前台快模型维持对话节奏、后台慢模型负责深度思考。
- 把推理本身做快：当 decode 速度足够高，按轮次的等待就短到近乎消失，"回合制"和"实时"的界限也随之模糊。
这个判断对你有实际影响：如果你的场景要求"边说边想"，先别期待单靠一个模型解决，而要考虑双模型架构。
限制三：知识是静态的
模型训练完成后知识就冻结了。这不是 bug，而是"参数里装知识"这种做法的必然代价。
解法就是检索（第 7 章 RAG）——不是为了让它更聪明，而是让它能查到训练时没有的东西。这也就解释了为什么 RAG 在本系列里占了一整部：它是给静态知识装上的唯一一条活水管道。
七、小结：一条完整的因果链
把这一篇的推理串起来：
模型只能看见上下文里有的东西
↓
上下文要靠工具去补（模型自己不能读文件、不能查库）
↓
工具的结果必须作为新消息进入上下文
↓
所以必须再调用一次模型来利用它
↓
所以 Agent 的成本与延迟随轮数线性增长
↓
所以要优化 Agent，要么减少轮数，要么让上下文更精炼
这条链子延伸到后面每一部：
- 减少轮数 → 更好的提示词与工具设计（第 3、4 章）
- 上下文更精炼 → 上下文工程与记忆（第 5、6 章）
- 少查但查得准 → 检索（第 7 章）
- 把循环跑稳跑快 → 运行时与 Harness（第 10 章）
八、成本优化的四条路径
既然轮数决定成本，优化就围绕"少轮次、短上下文"。
| # | 路径 | 效果 | 代价 |
|---|---|---|---|
| 1 | 减少轮数 | 直接省 | 可能降低灵活性 |
| 2 | 缩短每轮输入 | 直接省 | 可能丢信息 |
| 3 | 前缀缓存 | 单价降低（5.3） | 要求前缀稳定 |
| 4 | 用小模型做简单轮 | 单价降低 | 需要路由逻辑 |
第 1 条：怎么真的减少轮数
| 手段 | 说明 |
|---|---|
| 并行工具调用 | 一次回复里请求多个工具，减少决策轮 |
| 更好的工具描述 | 少试错（4.2） |
| 一次给足上下文 | 少查几轮（第 7 章） |
| 结构化输出 | 少返工（3.2） |
"并行工具调用"是最直接的：本来是 4 轮（一个工具一轮），现在 2 轮（一次调 3 个 + 一次总结）。
第 2 条：怎么缩短输入
| 手段 | 说明 |
|---|---|
| 工具结果截断/摘要 | 5.2 |
| 历史压缩 | 5.2 |
| 只传相关片段 | 12.3 的字段/引用传递 |
| 系统提示精简 | 3.4 |
第 4 条：分层模型
简单判断（如意图分类）→ 小模型
复杂推理（如方案设计）→ 大模型
收益可能很大——因为简单轮常常占多数。
风险：小模型在小事上也会错，而错误会传导到后续轮。要评估（第 13 章）。
九、一个具体的成本估算
假设一个任务平均 6 轮，每轮输入 8000 Token、输出 300 Token。
单轮 = 8000 + 300 = 8300 Token
6 轮 = 49,800 Token
如果用了前缀缓存（前 6000 Token 命中）：
有效输入 = 6000 缓存 + 2000 全价
6 轮 ≈ (6000×0.1 + 2000 + 300) × 6 = 17,400 等效 Token
降低约 65%。
这说明：结构化地设计上下文（5.3）带来的成本收益，常常比"换个便宜模型"更大。
十、常见误区
误区一：让模型一次输出多个工具调用，就不用多轮了。
部分正确。模型确实可以在一次回复里请求多个工具调用（并行），但结果回来之后仍然要再推理一次才能利用。并行减少的是「决策轮次」，不是「结果回填后的推理」。
误区二：把工具结果直接拼成文本喂回去，算不算新调用？
算，而且是最常见的做法——本质就是往消息列表追加一条消息。它和「结构化 tool 角色」在协议层不同，但在「需要新一次推理」这一点上完全一样。
误区三：上下文越长，Agent 越聪明。
不是。超过一定长度后，关键信息被淹没、注意力被稀释，表现反而下降。长上下文不是免费的能力，而是要管理的资源。
误区四：Agent 出错一定是模型不行。
先查上下文。多数「模型变笨」的实际原因是它缺了某个关键信息，或者上下文里混进了错误信息。
误区五：环境的问题可以靠 Agent 解决。
不能。如果团队没有文档、决策没有记录，Agent 拿不到就是拿不到——它只能靠工具去读，而没写下来的东西读不到。
十一、下一篇
现在你理解了模型的能力边界：它只能看见上下文，而上下文要靠工具去补。
那么下一个问题就是：当一个系统既不需要模型现场判断、又能把事办完时，它应该长什么样？ 换句话说，什么时候我们根本不该造 Agent。
下一篇给出边界：Agent、Workflow、Chatbot 三者的区分标准，以及一条从简到繁的复杂度阶梯。