第 2 章：Agent 的最小组成单元
本章目标：把“Agent”从一个模糊名词拆成几个可操作的系统部件，建立后续章节共同使用的分析框架。
本章对应总纲：docs/ebook-outline.md中“第 2 章正文写作提纲（2026-03-31 归档）”。
2.1 为什么必须先拆结构，再谈能力
很多人一谈 Agent，就喜欢直接谈“这个模型强不强”“会不会自动做事”“能不能自己完成任务”。这种讨论很容易失焦。
原因很简单：系统能力从来不是某一个部件单独决定的，而是由部件之间如何组织决定的。
同样一个模型：
- 放在纯问答系统里，它只是回答器
- 放在带工具的交互系统里，它变成执行协调者
- 放在有状态、有反馈、有权限边界的循环里，它才开始接近 Agent
所以工程上更有价值的问题不是：
这个模型是不是足够聪明？
而是：
这个系统到底由哪些最小部件组成？这些部件如何配合，才能把一个目标持续推进下去？
如果这个问题答不清，后面所有“增强 Agent”的讨论都容易变成堆概念、堆名词、堆幻觉。
2.2 一个最小 Agent 至少包含哪几部分
本书采用一个非常务实的拆法。一个可工作的 Agent，最少可以拆成五类部件：
- 模型（Model）
- 工具（Tools）
- 记忆/状态（Memory / State）
- 规划与决策（Planning / Decision）
- 执行循环（Execution Loop）
这五个部件不是为了教学好看，而是因为它们刚好对应了一个 Agent 系统最核心的五个问题：
- 用什么来理解和推理？
- 用什么和外部世界交互？
- 用什么保存上下文和历史？
- 用什么决定下一步？
- 用什么把这一切串成闭环？
少了其中任何一个，系统能力都会明显塌陷。
2.3 模型：负责理解、判断与生成，但不等于 Agent
2.3.1 模型的职责是什么
模型是 Agent 的认知核心。它通常负责：
- 理解用户目标
- 解释当前上下文
- 根据已有信息做判断
- 生成下一步动作建议
- 在必要时生成要执行的工具调用参数
所以模型确实很重要。但重要不等于它可以独立定义整个系统。
2.3.2 为什么“只有强模型”仍然不够
只靠模型，你最多得到一个更聪明的回答器。
它也许能：
- 分析问题
- 写出计划
- 提供建议
- 生成代码草案
但它未必能：
- 真的去读取文件
- 真的去运行测试
- 真的根据测试失败继续修复
- 真的记住中间状态
- 真的在风险动作前停下来请求确认
这就是一个基本事实：
模型负责“想”，但 Agent 还必须负责“做”与“继续做”。
2.3.3 一个常见误区：把模型升级误当成系统升级
工程里最常见的误判之一，就是把“模型更强了”直接等同于“Agent 更成熟了”。
这通常只说明一件事：认知核心可能变强了。
但系统层面的问题仍然还在：
- 工具有没有被正确定义
- 状态有没有被保存
- 决策有没有边界
- 执行有没有反馈闭环
所以判断一个 Agent 系统，不要只盯模型型号，而要看模型被放进了什么结构里。
2.4 工具：让系统不只会说，还能真的动手
2.4.1 工具为什么是 Agent 的第一道分水岭
没有工具，系统几乎只能停留在文本世界里。
有了工具，它才开始具备改变外部状态的能力。常见动作包括：
- 读文件
- 搜代码
- 改文件
- 运行命令
- 调接口
- 打开网页
- 请求用户确认
- 调用其他 Agent
工具的意义不是“功能更多”，而是：
系统第一次从“解释任务”变成“推进任务”。
2.4.2 工具不是越多越好
很多人一设计 Agent 就想把一堆工具全挂上去，结果很快把系统做成垃圾堆。
问题在于：
- 工具越多，选择空间越大
- 选择空间越大，误用概率越高
- 误用概率越高，系统就越不稳定
好品味不是“什么都能调”，而是只暴露完成任务真正需要的能力。
2.4.3 Claude Code 的现实例子
当前仓库把工具层暴露得非常直白：Read、Edit、Write、Grep、Glob、Bash、Agent、AskUserQuestion 这些能力都不是混成一个“大工具箱”，而是被刻意拆成不同接口。
这种拆法背后不是形式主义，而是几条很硬的设计规则：
- 读、写、搜索、执行要分开建模，这样系统才知道自己现在是在感知环境，还是在改变环境
- 高风险动作不能和低风险动作混成同一层，所以
Bash这种能力天然更接近风险边界 - 能用专用工具解决的问题，就不要退化成通用 shell，否则动作语义会变脏，反馈也更难约束
- 工具不是越多越强，而是越清楚越稳
再看 examples/settings/settings-strict.json:1，这个项目甚至把工具权限直接写成了策略对象：
ask: ["Bash"]deny: ["WebSearch", "WebFetch"]allowManagedPermissionRulesOnly: trueallowManagedHooksOnly: true
这说明一个成熟 Agent 的工具层从来不是“模型想调什么就调什么”。真正的设计思路是：工具先按能力和风险分层，再由配置层决定本次运行到底开放到哪。
所以工具层真正回答的，不只是“系统能做什么”，还包括：
- 哪些动作只是读取
- 哪些动作会改状态
- 哪些动作风险高
- 哪些动作必须先问人
- 哪些动作在当前环境根本不该放开
这才是现实里的动作接口层。没有这层分化，所谓“工具调用”最后通常只会退化成一堆不受控的万能命令。
2.5 记忆与状态：没有状态，系统就只能重复失忆
2.5.1 为什么状态不是“可选增强”
很多人把记忆理解成“聊天记录保存”或者“长期记住用户偏好”。这太浅了。
对 Agent 来说，状态首先意味着：
- 当前目标是什么
- 已经做到了哪一步
- 哪些动作做过了
- 哪些结果失败了
- 当前环境是什么状态
- 后面该延续什么上下文
如果这些东西没有被保存，系统每一轮都像刚醒来一样重新猜。
那就根本谈不上持续推进任务。
2.5.2 状态不只有一种
工程上至少可以分几层：
- 瞬时上下文：当前轮对话、当前工具输出
- 会话状态：这一轮任务的中间结果、任务列表、暂存结论
- 持久记忆：用户偏好、项目背景、长期规则
- 外部状态：文件系统、Git 状态、Issue 状态、服务响应
真正的 Agent 往往同时依赖这几层，而不是只靠聊天历史。
2.5.3 为什么状态层最容易被低估
很多入门讨论会把注意力都放在模型和工具上，因为它们最显眼。
但真正让系统从“一次回答”变成“持续推进”的，往往恰恰是状态层。因为只要状态管理做不好，系统就会不断出现这些问题：
- 重复做已经做过的事
- 忘记前一轮为什么失败
- 无法判断任务当前处于哪个阶段
- 不能稳定地把反馈接到下一轮
所以状态不是锦上添花，而是执行连续性的地基。
2.6 规划与决策：不是为了好看，而是为了少走弯路
2.6.1 规划的本质
规划不是让模型写一段漂亮计划书。规划真正的价值是：
- 降低盲动
- 把任务拆成可执行步骤
- 在多种路径里选一条更合理的路
- 在执行前识别风险和依赖
如果没有规划层，系统很容易陷入两种坏状态：
- 一上来就乱做
- 说得头头是道，但根本不落地
2.6.2 决策发生在每一轮，而不只在开头
很多人把规划理解成“任务开始前生成一个计划”。这只说对了一半。
真正的 Agent 还需要持续决策：
- 现在该读文件还是直接改？
- 是继续当前路径，还是回退重查？
- 是该问用户，还是可以自主处理？
- 是该启动子 Agent，还是自己完成？
- 当前错误说明代码逻辑错了，还是上下文还不够？
所以更准确地说，规划层包含两部分：
- 前置规划：先设计路径
- 过程决策：边执行边修正
2.6.3 这层为什么不能硬编码成固定流程
固定流程当然有价值，但它解决的是“已知路径问题”。
而 Agent 更擅长处理的是：
- 信息不完整
- 反馈会改变路径
- 环境不断变化
- 需要临场判断
当任务具备这些特点时，规划与决策就不再是装饰，而是核心能力。
2.7 执行循环：把前面四部分真正焊接起来
2.7.1 为什么循环才是系统的骨架
现在把前面四部分摆在一起：
- 模型负责理解与判断
- 工具负责行动
- 状态负责连续性
- 规划负责选择路径
但这些部件如果不被串起来，只是零件，不是系统。
真正把它们焊成 Agent 的，是执行循环。
最小循环可以写成：
读取状态 -> 理解目标 -> 选择动作 -> 执行动作 -> 接收反馈 -> 更新状态 -> 再判断
只要这个回路存在，系统就可以持续推进任务。
2.7.2 为什么很多“伪 Agent”会失真
因为它们通常只做了前半段：
- 理解问题
- 生成建议
- 给出计划
但没有后半段：
- 真正执行
- 接收反馈
- 根据反馈继续迭代
于是看上去像在做事，实际上只是更复杂的文字表演。
2.7.3 停机条件同样属于执行循环的一部分
很多人只关心系统怎么开始跑，却很少认真设计它怎么停。
但一个成熟 Agent 的循环一定包含停机条件，例如：
- 目标已经完成
- 当前路径已经证伪
- 风险动作需要授权
- 缺少关键上下文，必须请求外部输入
- 达到明确的失败边界
如果没有停机条件，循环就会退化成盲目试错；如果停得太早，系统又只会做半截事。
所以执行循环不是“不断重复”，而是“有边界地持续推进”。
2.8 这五个部件之间是什么关系
现在可以把它们之间的关系压缩成一句话：
模型负责判断，工具负责行动，状态负责连续，规划负责选路，循环负责把一切变成持续运行。
如果你愿意再工程化一点，可以这样理解：
| 部件 | 回答的问题 | 缺失后会怎样 |
|---|---|---|
| 模型 | 现在该怎么理解与推理？ | 系统不会判断 |
| 工具 | 现在能做什么动作？ | 系统只能建议 |
| 状态 | 已经发生了什么？ | 系统持续失忆 |
| 规划 | 下一步为什么这样走？ | 系统容易乱撞 |
| 循环 | 如何持续推进直到停机？ | 系统只能做一轮 |
这张表的意义在于：以后你看到任何一个所谓 Agent 系统，都可以先别听营销词，直接拿这五项去查。
如果它说自己是 Agent，但：
- 没有工具，只会输出建议
- 没有状态，每轮重来
- 没有反馈闭环，只跑一步
- 没有决策层，只是固定脚本
那它大概率就不是一个成熟的 Agent。
2.9 从“部件视角”看系统设计，为什么更稳
当你开始用“最小组成单元”去看系统，会获得两个好处。
第一，你不会再被营销词带偏
别人说“我们有 Agent”。你不用吵概念，只要追问：
- 模型是什么？
- 工具是什么？
- 状态存哪？
- 怎么决策？
- 闭环怎么跑？
对方答不上来，基本就露馅了。
第二，你能更稳地做设计取舍
因为很多问题会变得非常具体：
- 当前问题是模型不够强，还是工具描述太差？
- 是状态管理有洞，还是规划层没起作用？
- 是工具太少，还是执行循环没有接住反馈？
这比一句“Agent 不够智能”有用得多。
“Agent 不够智能”这话通常是懒。
2.10 本章小结
这一章真正做的，不是介绍一堆术语，而是建立一把拆系统的刀。
你现在应该记住五件事：
- Agent 不是一个单点能力，而是多个部件协作形成的系统。
- 模型很重要，但模型绝不等于 Agent。
- 工具让系统具备行动能力，状态让系统具备连续性。
- 规划负责选路，执行循环负责把各部件焊成闭环。
- 以后判断一个系统是不是 Agent，先看这五个部件是否成立。
下一章我们不再只讲静态结构，而是沿着一次真实请求往下走：从用户提出任务开始，看一个 Agent 到底如何一步步形成完整闭环。