作者：Codex 整理时间：2026-04-23 02:45:00 CST 来源：基于 AI Agent 全景指南：从基础认知到工程化落地 的第四章扩展，并结合 Anthropic Claude Code 与 OpenAI Codex 的官方公开能力做架构抽象。 主题：把“架构形态”“工作机制”“核心模块”三组概念拆开讲清，再系统展开 Single Agent、Workflow Agent、Planner-Executor、ReAct、Memory Agent、Multi-Agent，以及更接近 Claude Code / Codex 这类系统的运行时编排型 Coding Agent。 说明：文中涉及 Claude Code / Codex 的部分，区分为“官方公开能力”与“合理架构抽象”，后者用于理解系统设计，不代表厂商披露的内部实现。
关联总文：AI Agent 全景指南：从基础认知到工程化落地
运行时展开：Claude Code 与 Codex 式 Coding Agent 运行时详解：一次真实任务如何被推进
为什么这篇要单独写：很多人把三件事混成了一件事
很多关于 Agent 的文章，一谈到“架构”，就会把 ReAct、Memory、Planner、Tool Calling、Multi-Agent 全部堆在同一层。 这样写虽然热闹，但读者很容易越看越乱，因为这些概念本来就不在同一个分析层级上。
更稳的分法是：
- 架构形态：回答“系统是怎么搭起来的”
- 工作机制：回答“系统是怎么跑起来的”
- 核心模块：回答“系统由哪些积木组成”
如果只记一句话，可以直接记成：
架构形态 = 组织方式，工作机制 = 运行流程，核心模块 = 实现积木。
这也解释了为什么你在总文里会感觉第四章和第二、三章有耦合：
- 第二章的重点其实是“闭环怎么运行”
- 第三章的重点其实是“有哪些可复用模块”
- 第四章真正该回答的是“这些模块和机制，被组织成了什么系统形态”
所以这篇文章的任务不是把原来的第四章写得更长，而是把它从“总览性介绍”升级成一篇真正的系统设计文章。
一、先建立观察框架：以后看任何 Agent，都先问这三层
为了避免概念继续打架，我们先给所有架构套同一个观察模板。
1. 先看它属于什么架构形态
也就是看它到底是：
- 一个 Agent 自己全包
- 一个固定工作流包着 Agent
- 一个 Planner 管规划、一个 Executor 管执行
- 一个或多个 Agent 在协作
- 还是已经演进成“带环境、权限、记忆、验证与治理层的代理运行时”
这一层关注的是角色分工、控制流拓扑、状态边界和系统边界。
2. 再看它用什么工作机制跑任务
工作机制是任务执行时真正发生的动态过程。 例如：
- 目标理解
- 规划拆解
- Thought / Action / Observation 循环
- 记忆读写
- 并行探索
- 验证与交付
同一种架构，可以采用不同工作机制； 不同架构，也可能共享相似机制。
例如 ReAct 更像一种运行机制，而不是一种足以独立解释整个系统边界的完整架构。
3. 最后看它由哪些核心模块拼起来
模块层看的是“这个系统到底用什么东西实现出来”。 常见模块包括：
- 模型
- Planner
- Executor
- Tool Router
- Memory
- Context Manager
- Permission / Sandbox
- Verifier
- Subagent Orchestrator
- Environment Runtime
模块是积木，机制是积木的动作组合，架构是积木和动作被组织起来后的整体形态。
二、最小可用形态：单 Agent 为什么总是起点
单 Agent 是最容易理解、也最容易落地的起始形态。 它通常表现为：一个模型面对一个任务，读取上下文，调用有限工具，然后返回结果。
1. 架构上长什么样
单 Agent 的基本拓扑通常是：
- 用户输入
- 主模型
- 若干工具
- 结果返回
整个系统里没有明显的角色拆分，也没有独立的子任务执行单元。 即使内部做了“先想再做”，外部看起来仍然是一条较短的闭环。
2. 它的典型工作机制
单 Agent 最常见的机制是：
- 理解任务
- 判断是否要用工具
- 调用一两个工具
- 整理结果
- 直接交付
如果任务简单，这种机制非常高效。 但只要任务开始变长，单 Agent 就容易暴露三个问题：
- 上下文越来越长
- 决策和执行耦合得太紧
- 错误恢复能力有限
3. 它依赖哪些核心模块
最小可用版本通常只需要：
- 模型
- 基础上下文管理
- 工具接口
- 很薄的一层状态记录
这也是为什么很多 Agent Demo 看起来很容易做出来。 但问题也恰恰在这里：它很容易“能演示”，却不容易“能持续运行”。
三、把流程外显：Workflow Agent 与 Planner-Executor 为什么是第一轮升级
当任务复杂度上升，系统的第一反应往往不是马上上 Multi-Agent，而是先把“隐式做事方式”变成“显式流程”。
1. Workflow Agent：把 Agent 放进可治理的流程状态机
Workflow Agent 的思路是： 把原本让模型临场决定的一部分路径，提前固化成一个稳定流程。
例如：
- 先检索资料
- 再提炼要点
- 再生成执行结果
- 最后做格式化输出
但如果只讲到这里，它还只是概念，不是架构。 真正的 Workflow Agent 架构，至少要包含下面这些角色：
- Workflow Orchestrator：流程编排器，决定当前任务走到哪个节点
- State Machine：状态机，记录任务处于待处理、执行中、待审批、失败、完成等状态
- LLM Decision Node：智能判断节点，负责分类、总结、生成、选择策略等开放判断
- Tool Action Node：工具执行节点，负责调用 API、查询数据库、创建工单、写文件等动作
- Human Approval Node：人工确认节点，拦截高风险动作
- Retry / Compensation Node：重试与补偿节点，处理失败、撤销、回滚和降级路径
- Audit Log：审计日志，记录每一步为什么执行、谁批准、工具返回了什么
它的典型控制流不是“模型想一步做一步”，而是：
用户目标
-> 流程入口
-> 状态机创建任务状态
-> 固定节点 1：收集输入
-> LLM 节点：判断任务类型
-> 条件分支：进入不同流程
-> 工具节点：执行外部动作
-> 风险节点：是否需要人工确认
-> 验证节点：检查结果是否满足条件
-> 完成 / 重试 / 补偿 / 转人工这里最重要的设计点是：核心控制权在流程状态机，而不在模型的自由发挥。 模型不是没有决策权，而是被放在有限节点里做局部判断。
这种形态适合：
- 客服工单流转
- 报销审批
- 销售线索分级
- 内容审核
- 数据报表生成
- 企业内部标准流程自动化
它的优势很明确：
- 稳定
- 可控
- 好审计
- 容易接企业流程
- 方便设置权限和人工确认
但缺点也很清楚： 如果任务变化太大，固定流程会开始显得僵硬。 所以 Workflow Agent 的设计重点，不是让它“无限智能”，而是明确哪些地方必须固定，哪些地方允许 Agent 判断。
一个比较成熟的设计原则是：
- 高风险路径固定化
- 低风险判断智能化
- 关键节点可审计
- 外部动作可回滚
- 异常路径能转人工
2. Planner-Executor：把目标拆成可执行、可验证、可回滚的任务链
Planner-Executor 比 Workflow Agent 更进一步。 它不是把路径完全写死，而是把“规划能力”和“执行能力”分开。
- Planner 负责理解任务、生成步骤、排序优先级
- Executor 负责按步骤动工具、取结果、推进状态
如果把它写成架构，最小可用版本通常包括：
- Goal Interpreter：把用户自然语言目标转成任务定义
- Planner：生成计划、依赖关系、优先级、成功标准
- Plan Store：保存计划，让计划可展示、可修改、可恢复
- Task Queue：把计划拆成可执行任务
- Executor：逐步执行任务，调用文件、终端、浏览器、API 等工具
- Observation Collector：收集工具返回、错误信息、环境状态
- Verifier：检查执行结果是否满足计划要求
- Replanner：在失败或新信息出现时修改计划
- Human Gate：在高风险步骤前请求人工确认
- Final Reporter：整理最终结果、过程说明和残留风险
它的典型控制流是：
用户目标
-> Goal Interpreter 明确成功标准
-> Planner 生成结构化计划
-> Plan Store 保存计划
-> Task Queue 拆分可执行步骤
-> Executor 执行第 N 步
-> Observation Collector 收集反馈
-> Verifier 判断是否通过
-> 通过：进入下一步
-> 不通过：Replanner 修改计划或回滚
-> 所有步骤完成后 Final Reporter 交付这种架构的关键价值，不只是“多了一个 Planner”，而是：
让系统第一次拥有了相对独立的规划层。
这会带来几个直接好处：
- 复杂任务更容易拆分
- 失败后更容易回到某一步重试
- 计划本身可以被展示、审查和修订
它特别适合目标明确但路径不确定的任务，例如：
- “修复这个测试失败”
- “把这个功能接入现有权限系统”
- “分析日志并定位根因”
- “整理某个主题的研究报告”
- “把一个脚本迁移到新框架”
但 Planner-Executor 也有自己的失败模式：
- Planner 计划过粗，Executor 不知道怎么落地
- Planner 计划过细，遇到变化就频繁失效
- Executor 执行偏航，但反馈没有及时回到 Planner
- Verifier 太弱，导致“看似完成，其实没通过”
- Replanner 过于频繁，任务陷入反复改计划
所以它的架构重点是：计划必须可执行，执行必须可观察，观察必须能回流，验证必须有硬标准。
3. Workflow Agent 与 Planner-Executor 的本质区别
它们都在做“流程外显”，但不是一回事。
- Workflow Agent 更像“预定义流水线”
- Planner-Executor 更像“规划层 + 执行层”的职责拆分
更系统地看：
- Workflow Agent 的控制权在预定义流程 / 状态机
- Planner-Executor 的控制权在动态生成的计划
- Workflow Agent 适合“路径稳定但局部需要智能判断”
- Planner-Executor 适合“目标稳定但路径需要临场生成”
- Workflow Agent 的失败处理更像流程补偿
- Planner-Executor 的失败处理更像重新规划
- Workflow Agent 更容易审计
- Planner-Executor 更容易适应新问题
前者的核心是稳定，后者的核心是弹性。 所以在真实系统里，常见组合其实是：
- 骨架用 Workflow
- 某些开放节点内部用 Planner-Executor
例如一个企业研发助手可以这样设计：
外层 Workflow：
接收需求 -> 判断风险 -> 创建任务 -> 执行 -> 验证 -> 人工确认 -> 合并
内部 Planner-Executor：
在“执行”节点里动态拆解：
读代码 -> 定位问题 -> 修改文件 -> 运行测试 -> 根据失败重新规划这也是现代 coding agent 常见的方向： 外层要可治理，内层要有弹性。
四、把推理嵌入动作：为什么 ReAct 更像机制，不该直接等同于架构
很多人学 Agent 的时候第一次接触到的就是 ReAct，于是很容易把它误认为“一种完整架构”。 但更准确地说，ReAct 首先是一种运行机制。
它最核心的循环是：
- Thought
- Action
- Observation
也就是：
- 先想一步
- 再做一步
- 再看世界给了什么反馈
- 然后继续下一轮
1. 为什么 ReAct 很重要
因为它把 Agent 从“先生成完整方案再执行”变成了“边做边看边修”。 这非常适合开放环境，尤其是：
- 搜索型任务
- 浏览器任务
- 代码排障任务
- 文档分析任务
2. 为什么它又不够解释整个系统
ReAct 只解释了“循环怎么跑”，却没完全回答：
- 角色怎么分工
- 状态放在哪里
- 验证由谁负责
- 权限和审批怎么进系统
- 长任务怎么切分
- 并行任务怎么治理
换句话说，ReAct 很像一台发动机的工作原理， 但架构文章还必须说明车身、底盘、油路、刹车和仪表盘。
3. 它在现代 Agent 里通常以什么方式存在
今天很多看起来很不同的 Agent，底层仍然共享 ReAct 式闭环，只是外面套上了更多系统层：
- 规划层
- 验证层
- 记忆层
- 审批层
- 多代理协作层
所以更合理的说法不是“某系统是 ReAct 架构”，而是：
该系统内部包含 ReAct 式运行机制。
五、把状态带出单轮：Memory Agent 真正改变的是什么
Memory Agent 常被写成一种“新的 Agent 类型”，但更严谨地说，它本质上是在架构里引入了持久状态层。
1. 它为什么重要
只靠当前对话窗口的 Agent，做短任务没问题； 一旦任务横跨多轮、多天、多项目，就会立刻暴露失忆问题。
所以 Memory 的价值在于让系统开始记住：
- 当前任务的中间状态
- 项目级规则
- 用户偏好
- 历史决策
- 已验证过的事实
2. 它通常分几层
比较实用的分法是：
- 短期上下文：当前轮和当前会话
- 会话记忆：最近若干轮任务状态
- 项目记忆：仓库规则、团队约定、项目说明
- 长期偏好：用户风格、习惯、常用路径
3. 它带来的收益与新风险
收益很直观：
- 连续性更强
- 个性化更好
- 重复解释更少
- 长任务恢复能力更强
但风险也同样明显：
- 错误信息会被“记牢”
- 旧结论可能污染新任务
- 记忆过多会拖慢和扰乱决策
所以 Memory 不是“存得越多越高级”，而是“存得越准、越分层、越可治理越好”。
六、把复杂任务拆开：Multi-Agent 什么时候真的有价值
Multi-Agent 是最容易被神化的形态。 很多人一听“多个 Agent 协作”，就自动联想到更高级。 但现实里它是否值得上，关键看并发收益能不能覆盖协调成本。
1. 它解决的根本问题是什么
不是“让画面更像科幻片”，而是解决这些真实工程问题：
- 一个上下文装不下所有内容
- 一个 Agent 同时兼顾探索、执行、审查太累
- 某些子任务天然可以并行
- 不同子任务需要不同角色视角
2. 常见的协作拓扑
常见形式包括：
- Manager - Worker
- Planner - Coder - Reviewer
- Researcher - Executor - Synthesizer
这些形态的共同点，是把原本塞在一个 Agent 脑子里的事情，拆给多个角色单元。
3. 它必须新增哪些系统模块
只要进入 Multi-Agent，系统就几乎一定要补上：
- 代理编排器
- 消息或任务协议
- 共享状态
- 结果合并器
- 冲突消解策略
否则看起来是多代理，实际只是在放大混乱。
4. 什么时候不该上 Multi-Agent
如果任务：
- 很短
- 很直接
- 没什么可并行
- 上下文也不大
那一个设计良好的单 Agent 往往更划算。 Multi-Agent 最怕的不是“不够聪明”，而是“协调开销比任务本身还贵”。
七、更接近 Claude Code 与 Codex 的先进形态：运行时编排型 Coding Agent 系统
到这里，前面的几种形态已经足以解释很多 Agent。 但像 Claude Code、Codex 这类现代 coding agent，通常已经不再适合被简单叫成“更强的单 Agent”。
更合适的抽象是：
运行时编排型 Coding Agent 系统。
这个名字的重点有两个：
- 它是一个系统，而不是单个会说话的模型
- 它有运行时，也就是能持续感知环境、调用能力、治理风险并维持任务状态的执行底座
1. 先说边界：什么是官方公开能力，什么是合理架构抽象
对于 Claude Code 与 Codex 这类产品，最稳妥的写法应该始终区分两层：
- 官方公开能力
- 合理架构抽象
官方公开能力通常能看到的是：
- 读写代码与文件
- 运行终端命令
- 接入外部工具或 MCP
- 使用项目级指令、规则或记忆
- 权限审批与环境限制
- 代码验证、检查或审查相关能力
- 子任务、并行任务或后台任务能力
- 本地或云端运行环境
而“内部到底是不是固定三代理协作、是不是某种专有调度器、是不是某个具体记忆图谱”，如果厂商没有公开说，就不该写成事实。
2. 为什么这类系统已经超出传统单 Agent
因为它们往往同时具备下面几层能力：
- 一个主代理负责理解任务和总体推进
- 一个运行时负责连接文件、终端、网络、工具和环境
- 一层上下文治理负责限制提示词膨胀和规则污染
- 一层权限治理负责审批、沙箱、边界控制
- 一层验证闭环负责测试、审查、diff 检查和结果确认
- 在某些场景下，还会有并行探索或子代理拆分
这说明它们真正先进的地方，不只是模型更强，而是：
把模型、工具、环境、权限、记忆、验证和编排做成了一个可以持续运行的代理系统。
3. 用架构语言怎么描述它们
如果做一个不冒进的抽象，可以把这类系统拆成五层：
- 用户任务入口层
- Agent Runtime 层
- 工具与能力层
- 状态与环境层
- 治理与安全层
这五层之间的关键闭环通常是：
- 任务进入
- 理解与规划
- 行动与观察
- 验证与修正
- 交付与状态沉淀
这已经不是传统“问一次答一次”的产品逻辑，而是明显的“代理运行时”逻辑。
4. 它和前面几种形态是什么关系
这类先进系统并不是把旧形态推翻，而是把它们组合起来。
- 它内部可能仍有 ReAct 式循环
- 某些任务可能使用 Planner-Executor 分层
- 某些复杂任务可能演进成 Multi-Agent 或子代理
- 项目规则和用户偏好让它具备 Memory 层
- 高风险动作又会被 Workflow / Approval 骨架约束
也就是说，它不是“第七种完全无关的新物种”，而是多种架构与机制的系统级叠加。
5. 为什么 coding agent 特别容易推动架构升级
因为代码任务天然满足几件事：
- 任务链路长
- 工具多
- 环境强依赖
- 结果可验证
- 失败代价真实存在
这迫使系统不能只做“语言输出”，而必须补齐：
- 规划
- 执行
- 观察
- 记忆
- 权限
- 验证
- 审计
所以 Claude Code / Codex 这类系统之所以值得单独讨论，不是因为它们只是“又一个 Agent 产品”，而是因为它们让 Agent 从概念演示走向了具备运行时与治理层的系统工程。
最后把三者重新扣回去：以后怎么判断一篇 Agent 文章有没有讲清楚
看完这一篇，再回头看很多常见文章，你会发现最常见的问题其实很明确：
- 把 ReAct 当成完整架构
- 把 Memory 当成独立物种
- 把 Multi-Agent 当成天然高级
- 把 Claude Code / Codex 误解成“更强的单 Agent”
更合理的理解应该是：
- 单 Agent、Workflow、Planner-Executor、Multi-Agent 属于组织形态
- ReAct、规划-执行-验证闭环、并行探索属于运行机制
- Planner、Memory、Tool Router、Sandbox、Verifier、Subagent Orchestrator 属于系统模块
所以一篇真正讲清楚 Agent 的文章，至少应该同时回答三件事：
- 系统是怎么搭的
- 任务是怎么跑的
- 能力是由什么模块实现的
如果只讲其中一件事，就很容易产生“明明看了很多名词，脑子里却没有系统图”的感觉。
回到总文：AI Agent 全景指南：从基础认知到工程化落地 如果你想把大图重新串回去，可以把这篇当成第四章的展开版，再配合总文里的第二章“工作机制”和第三章“核心模块”一起看，三块就能真正扣上。