如果整本书只允许保留一个分析框架，我会保留这一章。
因为无论一个 Agent 看起来多复杂，背后都可以先压缩成一个最小闭环。 这个闭环不一定足以描述所有细节，但足以判断一个系统是不是在真正运行，而不是只是在生成表象。
本书采用的最小闭环是五个词：
- 目标
- 观察
- 决策
- 动作
- 反馈
只要这五个环节能成立，Agent 才开始具备系统意义。 只要其中任何一环缺失，系统就很容易退化成问答器、脚本、流程节点，或者看起来忙碌但其实不收敛的自动化玩具。
为什么用这五个词？
因为它们是多个传统在大模型时代的交汇点。
经典 AI 用的是 percept -> action 和基于目标或效用的 rational agent 视角。
控制论与自适应系统强调的是 feedback loop。
OODA 强调的是 observe、orient、decide、act 的快速循环。
IBM 的 MAPE-K 强调监测、分析、规划、执行以及知识基座。
ReAct 强调 reasoning 和 acting 的交替。
Reflexion 强调把反馈显式纳入后续策略修正。
Generative Agents 强调 observation、memory、reflection、planning 的连续耦合。
这些框架名字不同，但内核很像：
系统必须基于目标读取环境，形成判断，采取动作，
并让动作结果重新进入下一轮判断。本书把这件事压缩成“目标、观察、决策、动作、反馈”，是因为这种表达既足够抽象，又足够工程化。
先看第一个环节：目标。
没有目标，系统就只有输出，没有方向。 它也许能说很多话、做很多事，但无法判断哪些行为是推进任务，哪些行为只是看起来合理。
所以，目标在 Agent 里从来不是一句口号，而至少包含三层内容：
- 成功标准是什么
- 约束条件是什么
- 停止条件是什么
例如“帮我做一个旅行计划”不是完整目标。 它至少还需要补上预算、时间、出行成员、偏好、是否允许自动预订、何时算完成。
在工程里，目标定义不清通常会直接导致两类问题：
- 系统过早结束，因为它误以为自己完成了
- 系统过度执行，因为它不知道该停在哪
再看第二个环节：观察。
观察不是“世界本身”，而是系统能够拿到并交给模型消费的那一部分世界。 这是 Agent 设计里最容易被低估、但又最决定上限的环节。
很多人一谈 Agent，注意力会立刻放到模型推理上。 但实际上，模型能做出什么判断，很大程度上取决于它看到了什么，以及没看到什么。
观察至少有四个来源：
- 用户当前输入
- 历史状态与记忆
- 工具或环境返回结果
- 系统预先注入的规则、约束、上下文
经典 agent literature 说的是 percept。 今天工程里更准确的说法是 model-visible context。
OpenAI 对 context management 的强调非常重要，因为它明确区分了：
- 程序世界里已经存在的信息
- 模型这一步真正看得到的信息
这两者不等同。 程序拿到的数据，可能没有进模型上下文。 进了上下文的数据，可能又被裁剪、压缩、摘要或重排。
所以很多系统失败时，问题并不是“模型不会推理”，而是：
- 它没看到关键事实
- 它看到的是错序事实
- 它看到的是被污染或冲突的事实
- 它没法把过去结果和当前观察接起来
这里顺便要强调一点：
观察不等于记忆。 记忆是状态存储能力。 观察是当前这一步实际被送入决策过程的那部分信息。 有记忆但没正确取出来，和根本没有记忆，在效果上经常没有区别。
第三个环节，是决策。
决策是 Agent 最像“智能”的位置，但也最容易被神秘化。 实际上，决策无非是在当前目标、当前状态和当前观察之下，选择下一步最值得做的动作。
这个“选择”可能表现为很多不同形态：
- 选一个工具
- 选一个子任务
- 选一个执行顺序
- 选一个协作对象
- 选是否继续还是停止
- 选是否需要追问用户
OODA 里的 orient 和 decide，在这里可以理解成“先把当前观察转成可判断的问题，再形成下一步动作选择”。
很多 Agent 看起来会“思考”，其实只是会生成文本，并没有真正做这一步面向任务的策略选择。
ReAct 的贡献就在于，它把 reasoning 和 acting 放在同一个循环里，让决策不再是一次性规划，而是随观察变化的动态过程。
Plan-and-Solve、ReWOO 这类方法则是在探索：怎样让决策既保持质量，又不至于在每一步都完全自由，导致成本和不稳定性失控。
第四个环节，是动作。
动作是 Agent 和纯分析系统真正分家的地方。 没有动作，再好的决策也只是脑内模拟。
动作可以有很多形态：
- 生成给用户看的内容
- 发起工具调用
- 修改某个外部系统状态
- 写文件、发消息、下指令
- 调起另一个 workflow 或另一个 Agent
- 发起审批或中断等待
动作最重要的，不是数量，而是可执行性和可验证性。
如果动作接口含糊不清，Agent 就可能：
- 明明决定了，却执行不出去
- 执行了，却副作用不可控
- 执行完了，却无法确认是否成功
这也是为什么 Anthropic 会专门讲“如何为 agents 写工具”，因为动作接口设计得差，整个闭环都会变形。
第五个环节，是反馈。
反馈不是附属物，而是 Agent 能不能形成闭环的决定因素。 很多系统看起来已经具备目标、观察、决策和动作，但仍然不稳定，核心原因就是没有把反馈变成下一轮决策的有效输入。
反馈至少可以来自三类地方：
- 动作执行结果
- 环境状态变化
- 外部评估或内部反思
Reflexion 之所以重要，就是因为它把“从结果中修正后续策略”显式化了。
而在工程上，feedback 并不一定非要长成一段自然语言反思。
它也可以是：
- 工具返回的状态码
- 测试是否通过
- 网页是否出现目标元素
- 数据库写入是否成功
- 人工审批是否通过
- 运行 trace 中暴露出的错误轨迹
只要这些结果没有真正回流到下一轮决策，它们就不构成闭环中的反馈。
所以，这五个环节可以写成一条非常简单但很有力量的链：
目标规定方向
观察提供现实
决策选择下一步
动作改变世界
反馈修正后续注意，这里还有一个经常被忽略但实际贯穿五环的隐变量：
状态状态不是五环之外的可选配件，而是这五环能够连续运转的载体。
目标要落在状态上，才能知道完成了多少。 观察要写入状态，才能被后续利用。 决策要读取状态，才能理解自己在流程中的位置。 动作要更新状态，才能让系统不是每轮都从零开始。 反馈要沉淀为状态，才能真正改变未来行为。
所以，从工程角度说，更完整的最小闭环其实是：
目标 -> 基于状态读取观察 -> 做出决策 -> 发起动作 ->
接收反馈 -> 更新状态 -> 再进入下一轮OpenAI 的 sessions、context management、tracing，LangGraph 的 persistence、checkpoint、interrupt，本质上都在为这个闭环补工程支架。 Google ADK 的 event loop、state delta、session service，以及 Microsoft/AutoGen 的 runtime、persisted conversation，也在强调同一件事。
它们在提醒同一件事：
- 闭环不是逻辑上存在就够了
- 它还必须能被保留、恢复、检查和重放
否则系统虽然“理论上有循环”，但工程上不可验证，也不可治理。
理解了这个最小闭环，再去看 Agent 失败，诊断会快很多。
大致可以按五环排查。
目标问题：
- 目标太宽，导致系统不知道先做什么
- 目标冲突，导致系统在多个优化方向之间摇摆
- 停止条件不清，导致过早结束或无穷执行
观察问题：
- 关键事实没有进入模型可见上下文
- 历史状态没有正确提取
- 环境返回结果被压缩得过度失真
- 噪声信息盖过了关键信号
决策问题：
- 动作空间过大，系统不会选
- 缺少中间策略，系统只能盲跳
- 约束没有显式进入判断，导致选择失真
动作问题：
- 工具接口不清晰
- 副作用不可控
- 权限过大或过小
- 执行结果不可验证
反馈问题：
- 执行结果没有回流
- 回流结果没有进入下一轮上下文
- 系统不会把失败解释成策略修正信号
一旦用这个框架看问题，你会发现很多所谓“模型不行”的锅，其实并不在模型本身。
模型也许只是在一个坏闭环里被迫做决定。
最后，本章给出一个非常实用的分析问题清单。
看任何一个 Agent，先问五个问题：
第一，它到底在优化什么，何时算完成。
第二，它此刻到底能看到什么，看不到什么。
第三，它凭什么决定下一步，而不是另一种下一步。
第四，它实际能执行哪些动作，这些动作会产生什么副作用。
第五，动作结果怎样进入下一轮，系统如何因此改变行为。
如果这五个问题回答不清，一个 Agent 系统大概率只是“看起来在运行”。 如果这五个问题回答得很清楚，哪怕系统还不复杂，它也已经具备了真正可扩展的骨架。
下一章我们就在这个骨架之上，去看现实里最常见的几种 Agent 形态到底有什么差别。