1.1 从一个「会聊天的模型」到「会干活的系统」
一句话结论：Agent 不是什么神秘的新物种。它只是一个被装上了「工具」和「循环」的模型——让模型能把话说完之后真正去做事，看到结果再决定下一步。理解这一点，后面所有内容才有落点。
读这篇之前
这是全系列第一篇，不需要前置知识。但你需要接受一个前提：接下来讨论的一切，都是模型 + 外围工程，而不是模型本身变聪明了。
一、先看一个具体的差距
假设你的服务连不上数据库。你打开一个聊天窗口，把现象描述给它：
「我的程序连不上数据库，报超时。」
它会回答：
「可能是数据库地址错误、端口错误、密码错误，或者网络不通。建议逐一检查。」
这个回答没有错，但也没有用。因为它说的每一句都是推测——它没有看过你的配置文件，也没读过你的错误日志。它只能用你给它的那几行字，加上训练时学到的通用规律，猜一个可能性最高的答案。
这就是一次性调用模型的全部能力边界：输入是什么，它就只能基于什么回答。
现在换一种方式。同样的问题，但这次系统被允许自己去找证据：
第 1 轮：模型判断「需要先看日志」
→ 执行：读取日志
→ 结果：「数据库连接超时」
第 2 轮：模型判断「超时可能是地址或网络问题，需要看配置」
→ 执行：读取配置文件
→ 结果：配置里的地址还是旧服务器
第 3 轮：模型判断「证据已够，可以给结论」
→ 输出：数据库地址是旧的，改成新地址后重启
差别在哪？第二种方式里，模型有能力去获得新信息，并根据新信息修正判断。 第一种只能猜，第二种能查。
这个「能查」的能力，就是 Agent 与聊天模型的根本分界。
换个说法：普通大模型像一个知识丰富的回答者——你问它什么，它从已有知识和上下文里组织出答案；Agent 像一个能完成任务的执行者——它不仅生成文字，还能根据任务去调用搜索引擎、数据库、文件系统、代码执行器这些外部工具。[原文 538]
二、Agent 的最小内核
把上面那个过程拆开，一个 Agent 由四样东西组成，缺一不可：
| 组成 | 作用 | 缺了会怎样 |
|---|---|---|
| LLM | 读懂任务、判断下一步该做什么 | 没有判断力，只能按固定流程走 |
| 上下文 | 保存已经发生了什么（含工具返回的结果） | 每一轮都从零开始，无法利用上一轮的发现 |
| 工具 | 真正去读文件、查库、发请求 | 只能"说"，不能"做"，退化成聊天模型 |
| 循环 | 决定要不要再来一轮、什么时候停 | 只有一次机会，无法根据结果调整 |
所以最小内核可以写成一行：
Agent = LLM + 上下文 + 工具 + 循环 [原文 538][原文 4577]
这个公式看起来很朴素，但它是后面所有章节的地基：
- 第 2 章讲 LLM 的能力边界——为什么模型自己干不了这些事
- 第 3、4 章讲上下文和工具——Agent 的输入输出两头
- 第 5、6 章讲记忆——上下文怎么撑过更长的任务
- 第 10 章讲循环和运行时的工程化——用 Harness 把这套东西跑稳
五要素与四要素，是同一件事的两种说法
上面那个四件套是工程视角的说法。如果把「循环」再拆细一点，就成了更常见的五要素：
| 五要素 | 对应四件套里的哪部分 | 作用 |
|---|---|---|
| 大语言模型 | LLM | 理解任务、决定下一步 |
| 工具集合 | 工具 | 搜索、计算、读文件、执行操作 |
| 记忆 / 上下文 | 上下文 | 保存已经发生的事情 |
| 控制循环 | 循环 | 决定是否继续执行 |
| 终止条件 | 循环的一部分 | 判断任务是否已经完成 |
后面的「终止条件」值得单独强调，因为它是工程上最容易出事的地方。一个没有终止条件的循环，轻则烧光 token，重则陷入死循环反复调用工具。常见做法有三种：达到最大轮数、模型显式输出「已完成」、外部校验通过。[原文 538]
同一个公式，三层理解
这个公式可以从三个层次理解，随着你的用途不同而深浅不同：[原文 4577]
- 实现层：四样东西各自的选型——用什么模型、接什么工具、上下文怎么存、循环写在哪。这是写代码时的视角。
- 直觉层：LLM 是「大脑」，工具是「手和眼睛」，上下文是「笔记」，循环是「不办完不罢休的劲头」。这是跟人解释时的视角。
- 学术层：Agent 是在部分可观测环境中、通过动作获取信息、以最大化任务完成度为目标的策略系统。这是读论文时的视角。
三层说的是同一件事。你不需要先搞懂学术层才能动手——但如果你要判断一个 Agent 设计得好不好，学术层那个「部分可观测」的视角会很有用：它提醒你，Agent 永远看不到全部真相，只能通过动作逐步获取信息。
从工作流到自主 Agent，是一条光谱而不是两个格子
「Workflow 还是 Agent」这个问法本身有点误导。真实系统几乎都落在这条光谱的中间地带：[原文 4577]
完全固定流程 ──────────────────────────────── 完全自主
代码决定每一步 代码定骨架+模型填细节 模型每步自主决策
绝大多数生产系统在中间：外层用代码控制阶段，内层让模型决定具体动作。所以不要纠结「我这个算不算 Agent」，而要问「哪些环节需要模型现场判断，哪些环节可以写死」。
三、那个「循环」到底长什么样
业内把这种「想—做—看」的循环叫 ReAct，取自两个词：
- Reasoning：推理，判断当前该做什么
- Acting：行动，调用工具
但实际运行中还有第三个环节，而且它极其重要：
- Observation：观察，把工具执行的结果收回来
完整的一轮是：
Reasoning（想）→ Acting（做）→ Observation（看结果）→ 再回到 Reasoning
用大白话说就是：分析当前情况 → 执行一个动作 → 看看结果 → 决定下一步。循环会一直转，直到任务完成或触达最大轮数上限。[原文 538]
关键在于 Observation 这一环。如果没有它，Agent 只是「连着调用好几次模型」，每次都在盲猜；有了它，每一轮的行动都会改变下一轮的判断依据——这才是从「猜」变成「查」的机制。
四、为什么必须「多次」调用
一个常见疑问：既然模型那么强，为什么不能一次就把事情办完？
原因很直接：一次调用里，模型能看到的只有你给它的那点信息。 它没办法「顺便」去读一个文件——除非你在这一轮里就允许它调用工具，然后把结果再喂回去。而工具返回的结果，需要下一次调用才能被模型「看见」并利用。
换句话说：
模型看到的信息量，取决于上下文里装了什么；而工具的结果，只能通过新的一次调用进入上下文。
这个「必须多次」的限制不是设计缺陷，而是当前架构的必然结果。理解它，你就能看懂为什么 Agent 的成本和延迟天然高于单次调用——每一轮都是一次完整的模型推理。
五、Agent、Workflow、Chatbot 三者的边界
这三个词经常被混用，但它们的差别是谁来决定下一步。
| 下一步由谁决定 | 流程可预测性 | 典型形态 | |
|---|---|---|---|
| Chatbot | 没有人决定——就是一次问答 | 完全可预测 | 客服问答、单轮检索 |
| Workflow | 代码决定（预定义的固定路径） | 高：输入相同则路径相同 | 文案流水线、数据清洗管道 |
| Agent | 模型决定（每轮看着情况判断） | 低：同样输入可能走不同路径 | Claude Code、Cursor、自主助理 |
一个可操作的判据是：
如果所有分支都能在写代码时枚举出来 → 用 Workflow。
如果分支依赖运行时才拿得到的信息 → 才需要 Agent。 【推导】
这条判据非常重要，因为大多数场景其实不需要 Agent。业界的反复验证是：能用一次调用加检索解决的事，不要引入 Agent 框架——它带来的延迟、成本、不确定性远大于收益。[原文 4627]
正确的复杂度阶梯是：
- 先试单次调用（优化提示词、加示例、调参数）
- 不够 → 加检索增强（让模型能查外部知识）
- 还不够 → 上 Workflow（代码控制的多步流程）
- 真的需要灵活决策 → 才用 Agent
每一步都要有「简单方案明确做不到」的理由，才往下走一级。
一个反例：连续对话为什么不是 Agent
判断一个系统是不是 Agent，有个很好用的测试：看它有没有"根据行动结果改变判断"的能力。
考虑你和聊天机器人连续聊了二十轮。看起来它有记忆、能接着上文说，但它从头到尾没有执行过任何动作——没有读过文件、没有查过数据库、没有发过请求。它二十轮做的事，都是「基于你已经告诉它的信息生成文本」。
所以它满足「有上下文」，但不满足「有工具」和「由结果驱动的循环」。它是多轮对话，不是 Agent。[原文 538]
反过来，如果一个系统只调一次模型、但这一次里模型调了三个工具拿到了真实数据——它反而更接近 Agent 的实质：信息是通过行动获得的。
六、五种编排模式：从简到繁
在真正写 Agent 之前，值得先看清 Workflow 这一档有哪几种形态。业界反复验证有效的编排模式，从简到繁大致是这五种：[原文 4627]
| 模式 | 怎么做 | 适合什么 |
|---|---|---|
| 1. 单次调用 | 一个提示词，一次请求 | 绝大多数任务——先验证这里够不够 |
| 2. 链式（Chaining） | 把任务拆成有序步骤，上一步输出作为下一步输入 | 步骤明确、可以串行拆解的任务 |
| 3. 路由（Routing） | 先判断输入类别，再分发给不同的专用提示词 | 输入类型差异大、混在一起会互相干扰 |
| 4. 并行（Parallelization） | 多个调用同时进行，最后汇总 | 子任务互不依赖；或需要多角度交叉验证 |
| 5. 编排者-工作者（Orchestrator-Workers） | 一个调用负责拆解任务，动态分派给多个执行者 | 子任务数量与内容事先不确定 |
注意第 5 种已经踩在 Agent 的边界上了——它由模型动态决定拆几个子任务。而前四种，流程都是代码写死的。
这五种模式的价值在于：当你觉得"需要一个 Agent"时，先在上面这张表里找找，很可能第 2 或第 3 种就够了，而它们比 Agent 便宜、稳定、好调试得多。
七、判断你需不需要 Agent：五道题
在动手之前，先回答五个问题。任何一个答"是"，就说明你不需要 Agent。
| # | 问题 | 如果是"是" |
|---|---|---|
| 1 | 所有分支都能在写代码时枚举出来吗？ | 用 Workflow |
| 2 | 每次任务的步骤都一样吗？ | 用 Workflow |
| 3 | 出错时必须能一模一样复现吗？ | 用 Workflow |
| 4 | 需要给客户报固定价吗？ | 用 Workflow |
| 5 | 只是为了少写几个 if-else？ | 用 Workflow |
五道题都答"否"，才继续往下看。
一个反例：为什么"智能客服"多数不需要 Agent
很多团队想给客服加 Agent，理由是"要能查订单、能退款、能转人工"。
但你仔细看这三件事：
查订单 → 固定调用一个接口
退款 → 固定校验 + 固定接口 + 需人工确认
转人工 → 固定判断规则
三步全是可枚举的。用 Agent 只会带来：不可预测的成本、难复现的行为、更难审核的执行。
正确答案是一个三步 Workflow + 明确的审批闸门。
八、动手：40 行看出 Agent 的全貌
理解了概念，最快的巩固方式是看一个能跑的最小实现。
def run_agent(task, tools, max_turns=10, budget_tokens=100000):
messages = [
{"role": "system", "content": SYSTEM_PROMPT},
{"role": "user", "content": task},
]
used = 0
for turn in range(max_turns): # ① 终止条件1：轮数
resp = llm.chat(messages, tools=tools)
used += resp.usage.total_tokens
if used > budget_tokens: # ② 终止条件2：预算
return {"status": "budget_exceeded", "messages": messages}
if not resp.tool_calls: # ③ 终止条件3：模型说完了
return {"status": "done", "answer": resp.content}
for call in resp.tool_calls:
result = execute_tool(call, tools) # ④ 执行（你的代码）
messages.append({"role": "tool",
"tool_call_id": call.id,
"content": result}) # ⑤ 观察写回上下文
return {"status": "max_turns", "messages": messages}
这 20 行包含了你需要知道的一切：
| 行 | 对应本文哪一节 |
|---|---|
messages 初始化 |
上下文（第二节） |
for turn in range() |
循环（第三节） |
if not resp.tool_calls |
模型判断完成 |
execute_tool |
工具执行在外围（第四节） |
messages.append(...) |
观察写回——最关键的一步 |
最后一步最容易被忽略：忘了写回，模型下一轮就看不到结果，会反复调同一个工具（10.2 讲过的重复调用 bug）。
这个实现缺什么
它只是骨架，生产环境还需要：
| 缺什么 | 在哪一章 |
|---|---|
| 参数校验与失败回填 | 4.3 |
| 工具描述质量 | 4.2 |
| 上下文压缩 | 5.2 |
| 权限与沙箱 | 10.3、14.4 |
| 状态持久化 | 10.4 |
| 轨迹记录 | 10.5 |
| 评测 | 第 13 章 |
但结构是对的——后面所有章节都是在给这 20 行加东西，而不是换掉它。
九、常见误区
误区一：Agent 是「更长的提示词」。
不是。提示词再长，模型依然只能看到上下文里的东西；Agent 的关键是能通过工具获得上下文之外的信息。
误区二：连续对话就是 Agent。
连续聊天只是历史消息越攒越多，模型始终没有「做」的能力，也没有「根据结果调整」的循环。[原文 538]
误区三：Agent 越自主越好。
自主性是有代价的：不可预测、难调试、成本不可控。受约束的 Agent 通常比完全自主的更可靠，这也是第 14 章要讲的「人在环」的出发点。
误区四：用了框架就算 Agent。
框架只是把循环、工具、上下文管理这些零件封装好了。如果你的流程里模型根本没在做判断，那你用的是 Workflow，套了层框架的皮而已。
误区五：Agent 能解决模型幻觉。
不能。Agent 能通过工具获得真实信息，从而降低幻觉的发生概率，但模型依然可能读错、总结错。这是第 13 章「评估」要解决的问题。
十、下一篇
现在你知道 Agent 是「模型 + 工具 + 上下文 + 循环」了。但还有一个更基础的问题没答：模型本身到底能干什么、不能干什么？ 为什么它必须依赖工具才能做事，而不是直接就把事办了？
下一篇我们从模型的工作方式讲起——包括那个决定 Agent 一切上限的东西：上下文窗口。