17种Agent架构演进：控制流设计的完整演化史¶

Ch04.507 17种Agent架构演进：控制流设计的完整演化史¶

📊 Level ⭐⭐⭐ | 34.8KB | entities/17-agent-architectures-evolution.md

→ 原文存档

评分¶

统一分析框架¶

每种架构用六个固定问题拆解 ： 1. 解决什么问题（上一代哪里不够） 2. State 是什么（新增了哪些字段） 3. 拓扑是什么（线性链/循环/分叉汇聚/共享黑板/树搜索/网格涌现） 4. Router 怎么工作 5. 失败模式是什么 6. 什么时候升级

判断新架构的三个过滤问题：它新增了什么 state？它新增了什么 router？它新增了什么 evaluator？答不出来就不是新架构，只是旧架构换了个名字。

17种架构详细拆解¶

1. Reflection — 最小质量闭环¶

解决什么问题：单次生成质量不可控，错误不出门，需要外部反馈才能修正。

State 新增字段：

• draft — 初始生成内容
• critique — 评审意见
• refined_code — 修正后内容

拓扑：线性三段式（Generator → Critic → Refiner），无环路，无 Router。

Router 工作方式：无动态路由。三阶段顺序执行，Critic 输出 critique 后直接交 Refiner 处理。

失败模式：

• Critic 识别出问题但 Refiner 未能真正修复（修复只是表面迎合）
• 无法验证 Refiner 的修复是否真正解决了 Critique 指出的问题
• Generator 和 Critic 可能形成对抗但相互妥协的局部最优解

何时升级：当需要修正的不仅仅是代码片段，而是需要重新理解问题本身时，升级到 Self-Improve 跨任务优化回路。

2. Tool Use — 世界接口¶

解决什么问题：LLM 的知识截止日期限制和参数化知识边界。文本交互无法获取实时信息或触发真实世界副作用。

State 新增字段：

• user_input — 用户原始请求
• model_output — LLM 回复
• tool_call — 调用的工具及参数
• tool_return — 工具执行结果
• next_round — 下一轮输入（包含工具返回）

拓扑：工具调用形成 LLM ↔ Tool 的闭环回边。内部 while 循环，只要 model 回复包含 tool_calls 就继续执行。

Router 工作方式：基于 tool_calls 结构化输出。模型输出 JSON 格式的工具调用，框架解析后执行，结果注入下一轮输入。

失败模式：

• 工具名幻觉（模型生成不存在的工具名）
• 参数类型错误（JSON 结构与工具 schema 不匹配）
• 序列化/反序列化失败（复杂返回值无法正确传递）
• 工具描述不清导致模型选了错误工具

何时升级：当单工具调用不足以完成任务、需要多步推理链时，升级到 ReAct 观察循环。

3. ReAct — 观察行动循环¶

解决什么问题：Tool Use 的单步调用无法处理需要「根据观察结果决定下一步」的场景。现实任务往往是动态推理而非一次性工具调用。

State 新增字段：

• thought — 当前推理步骤的思考
• action — 决定执行的动作
• observation — 动作执行后的观察结果

拓扑：闭环（Thought → Action → Observation → Thought...）。Tool Use 的 tool→model 回边是架构中最关键的结构性改进。

Router 工作方式：Observation 结果作为下一轮 Thought 的输入。上一步观察决定下一步行动，而非预设固定执行路径。

失败模式：

• 局部贪心：每步选择当前最优，但整体非最优（类似 RL 中的 greedy 策略）
• 观察噪声放大：错误观察导致后续推理全错
• 循环终止判断：可能无限循环或过早终止

何时升级：当需要显式规划步骤、控制流需要可审计时，升级到 Planning。

4. Planning — 显式规划¶

解决什么问题：ReAct 的隐式控制流无法审计、无法干预。规划过程不可见，失败时无法定位是哪一步出了问题。

State 新增字段：

• plan: List[str] — 步骤清单，每个元素是一个子任务描述

拓扑：线性执行（Loop execute_all），终止条件是 plan_is_empty。控制流从「LLM 临时决定」变成「数据结构是否还有剩余项」。

Router 工作方式：路由决策从 LLM 临时判断变成结构化数据遍历。执行完一个 plan item 才能执行下一个。

失败模式：

• Plan 出错后面全错（可预测性增强，适应性下降）
• 规划粒度不当：过粗导致关键步骤遗漏，过细导致执行僵化
• 无法处理规划外情况：现实任务往往需要动态调整

何时升级：当执行结果需要验证才能进入下一步时，升级到 PEV (Plan-Execute-Verify)。

5. PEV — 验证驱动重规划¶

解决什么问题：Planning 的验证在规划外执行，错误静默传播到下游。需要在主回路中嵌入验证作为质量关卡。

State 新增字段：

• verification_result — 验证结果（pass/fail/retry）
• replan_triggered — 是否触发了重规划

拓扑：Plan → Execute → Verify → (continue | replan | finish)。Router 的 selector 根据 verdict 决策下一步。

Router 工作方式：验证结果决定路由分支。Fail → Replan → 重新执行；Pass → 继续下一项；Finish → 任务完成。

失败模式：

• 验证逻辑本身的正确性无法自证（验证器可能有 bug 或偏差）
• 无限重规划循环：每次验证都失败导致规划器反复重试
• 验证开销：频繁验证增加延迟和成本

何时升级：当任务需要多角色协作、单角色无法完成全流程时，升级到 Multi-Agent。

6. Multi-Agent — 认知分工¶

解决什么问题：单 Agent 的能力边界有限，复杂任务需要不同专业角色协作。

State 管理：不同 Agent 写入不同 state 区域，形成流水线式的状态隔离。可用 Team(mode="coordinate") 让 leader 调度。

拓扑：线性流水线（研究员 → 写作 → 审阅）。角色在编译时确定，执行时顺序流转。

Router 工作方式：固定顺序流转，无动态路由。Agent A 完成 → 传递给 Agent B → 传递给 Agent C。

失败模式：

• 流程固定，执行中途无法动态调回
• 信息压缩损失：传递时摘要导致关键细节丢失
• 角色边界模糊导致职责冲突
• 单点瓶颈：上游失败导致下游全部等待

Factory 的 Mission 系统 是 Multi-Agent 架构的典型实践：Validator-Creator 分离、Validation Contract 预承诺机制、串行优先于并行的调度策略。

AI Native 研发组织设计 则从组织维度探讨了 Multi-Agent 时代的架构演化。

何时升级：当需要动态决定「谁来处理」而非固定顺序时，升级到 Blackboard 或 Meta-Controller。

7. Blackboard — 共享工作空间¶

解决什么问题：Multi-Agent 的固定流水线无法适应任务复杂度动态变化。需要一个共享空间让多个 Agent 能根据当前状态协作决定下一步。

State 管理：所有 Agent 共享一个 blackboard 状态空间。任何 Agent 可以写入中间结果，任何 Agent 可以读取已写入的内容。

拓扑：持续调度回路。Controller 持续检查 blackboard 决定下一步激活哪个 Agent。

Router 工作方式：Controller 动态决定激活哪个 Agent。不是固定顺序，而是根据当前状态和任务需求实时调度。

失败模式：

• Controller 决策不稳定：同一状态不同决策
• 信息冲突：多个 Agent 写入矛盾信息
• 过度循环：Agent 间互相激活形成死循环
• 状态一致性问题：并发写入导致状态损坏

何时升级：当入口需要一次性分诊判断而非持续调度时，升级到 Meta-Controller。

8. Meta-Controller — 入口分诊¶

解决什么问题：Blackboard 的持续调度过于复杂，许多场景只需要入口处做一次判断决定路由到哪个专家 Agent。

State 管理：Team(mode="route")，leader Agent 只做路由选择，不执行具体任务。路由决策后任务转发给子 Agent 处理。

拓扑：一次性分诊（入口判断 → 转发 → 子 Agent 执行）。和 Blackboard 的本质区别：分诊台 vs 总控台。

Router 工作方式：一次性判断任务类型，选择最合适的专家 Agent。之后由专家 Agent 全权处理，无需回传决策。

失败模式：

• 分诊错误导致路由到错误专家，后续全错
• 分诊标准模糊导致决策不稳定
• 缺乏回退机制：分诊后无法动态调整

何时升级：当单一专家不够、需要多专家冗余并行时，升级到 Ensemble。

9. Ensemble — 冗余并行¶

解决什么问题：单 Agent 判断存在偏差，需要多视角冗余来降低错误率。

State 管理：Parallel fan-out（并行分发） + Aggregator fan-in（聚合收敛）。多个 Agent 分析同一问题，结果聚合。

拓扑：星形结构（中心分发 → 多个 Agent 并行 → 中心聚合）。

Router 工作方式：同题多 Agent 并行执行，结果通过投票或融合输出。关键：保留冲突信息而不仅是取平均。

失败模式：

• 多数暴政：少数正确意见被多数错误淹没
• 相关性崩溃：多个 Agent 因训练数据相似导致同错
• 聚合逻辑复杂导致输出不可预测

何时升级：当任务需要跨轮记忆历史经验时，升级到 Episodic+Semantic Memory。

10. Episodic + Semantic Memory — 长期记忆¶

解决什么问题：State 只存在于单次执行内，跨轮任务无法利用历史经验。

State 扩展：从「图内状态」扩展到「图外可检索历史」。通过 agno Memory + AgentKnowledge + enable_agentic_memory 实现。

拓扑：单次执行环 + 外部记忆存储层。历史经验可被向量检索召回。

Router 工作方式：基于相似度检索召回相关历史经验，注入当前执行上下文。

失败模式：

• 错误记忆长期污染：向量相似度召持续带出已被修正的错误上下文。一旦错误记忆被存入，后续检索会反复放大错误
• 记忆碎片化：缺乏结构导致无法进行复杂查询
• 置信度缺失：无法区分高质量和低质量记忆

何时升级：当需要关系推理而非相似性召回时，升级到 Graph Memory。

11. Graph Memory — 关系推理¶

解决什么问题：Episodic Memory 只能做相似性召回，无法回答「A 和 B 是什么关系」「谁影响了 C」这类关系推理问题。

State 结构：Text → Knowledge Graph → Cypher 查询语言 → 答案。解决多跳关系查询。

拓扑：向量化存储 + 图结构索引。记忆以实体和关系而非文本块为单位存储。

Router 工作方式：将自然语言问题转换为 Cypher 查询，在知识图谱中执行关系推理。

失败模式：

• 图构建质量依赖 NLP 抽取准确性
• 错误关系比错误文本更难发现和纠正
• 图结构变更（增删实体/关系）可能导致查询结果漂移

何时升级：当需要探索多种解题思路时，升级到 Tree-of-Thoughts。

12. Tree-of-Thoughts — 推理搜索¶

解决什么问题：单路径推理可能陷入局部最优。需要在解空间中进行搜索，探索多种可能路径后选择最优。

State 新增字段：

• thought_node — 思维树中的一个节点
• score — 节点评分
• children — 子节点列表

拓扑：树搜索结构。多个思路展开、打分、剪枝。推理变成搜索。

Router 工作方式：关键判断：搜索控制权归属。正确实现是：LLM 负责生成候选动作（proposer），程序化代码负责搜索树的扩展和剪枝。把搜索控制权交给 LLM 是反模式。

失败模式：

• 组合爆炸：分支过多导致搜索树失控
• 只适合回溯场景：问题需要有良好可定义的分支结构
• 评分函数质量决定搜索效率

何时升级：当需要行动前预演验证时，升级到 Mental Loop。

13. Mental Loop — 反事实执行¶

解决什么问题：真实执行有副作用，失败有代价。需要先在内部世界模拟，验证方案可行后再真实执行。

State 新增字段：

• simulation_context — 模拟执行的上下文副本
• simulation_result — 模拟结果

拓扑：双轨制。simulate_action（fork copy 预演）和 execute_action（真实执行）分离。

Router 工作方式：先在模拟环境 fork 一个 copy，执行动作后观察结果。如果模拟成功且结果可接受，才执行真实动作。

失败模式：

• 模拟与真实环境差异导致模拟有效但真实失败
• Fork copy 的开销可能很大
• 复杂状态难以完全复制模拟

何时升级：当需要系统化安全闸门时，升级到 Dry-Run Harness。

14. Dry-Run Harness — 副作用闸门¶

解决什么问题：Mental Loop 的模拟是 Agent 内部行为，缺乏外部审批机制。需要将副作用变成可审批对象。

State 新增字段：

• dry_run_result — 干跑结果
• approval_status — 审批状态（pending/approved/rejected）

拓扑：Workflow 显式插入人工审批 Step。工具调用必须先 dry_run，审批通过后才能执行真实操作。

Router 工作方式：干跑通过 → 进入审批队列 → 审批通过 → 执行真实操作。任何一步失败则终止。

失败模式：

• 审批者疲劳：频繁审批导致审批者降低标准
• 干跑结果与真实结果差异
• 审批延迟影响实时任务

何时升级：当需要 Agent 具备自我边界认知时，升级到 Metacognitive Agent。

15. Metacognitive Agent — 自我边界¶

解决什么问题：Agent 无法判断自己能力边界。遇到超出能力范围的任务时盲目尝试而非主动拒绝。

State 新增字段：

• AGENT_SELF_MODEL — 自我模型，包含：
• 知识域（会什么）
• 工具列表（能用什么）
• 置信度阈值（什么情况下应该拒绝）
• 高风险话题（需要升级处理）

拓扑：决策分支（reason_directly / use_tool / escalate）。自我边界建模使 Router 能做出「能力判断」而非「任务匹配」。

Router 工作方式：决策前先查询自我模型。如果任务超出边界，触发 escalation 而非盲目尝试。

失败模式：

• 自我模型过时或不准确
• 边界设置过于保守导致能力浪费
• 过度依赖自我模型而缺乏灵活性

何时升级：当需要系统持续自我优化时，升级到 Self-Improvement Loop。

16. Self-Improvement Loop — 迭代优化¶

解决什么问题：Reflection 只在单次任务内修正，修正结果无法跨任务积累。Agent 需要持续从历史中学习。

State 新增字段：

• gold_standard_samples — 高质量样本库
• iteration_score — 迭代评分

拓扑：Loop(end_condition=...) + GoldStandardMemory 跨任务积累高质量样例。形成进化回路。

Router 工作方式：Editor 评分 + 修改 → 高分样本存入 GoldStandardMemory → 后续任务优先使用高质量样本。

和 Reflection 的区别：迭代优化 + 跨任务记忆。Reflection 是单次质量闭环，Self-Improve 是持续进化系统。

失败模式：

• 样本选择偏差：高质量样本可能只是特定模式的过拟合
• 遗忘灾难：新样本覆盖旧样本导致能力退化
• 评分标准漂移：Editor 评分标准随时间变化

何时升级：当需要完全去中心化、让全局行为从局部交互涌现时，升级到 Cellular Automata。

17. Cellular Automata — 涌现计算¶

解决什么问题：中心化控制难以扩展。需要 LLM 退出主循环，让全局行为从局部规则自下而上涌现。

State 管理：LLM 只负责设计局部规则。多个 CellAgent 同步并行更新，共享状态按规则演化。

拓扑：网格/网络结构。每个 Cell 遵循局部规则，状态更新只依赖邻居。全局行为从局部交互涌现。

Router 工作方式：无中心路由。Cell 按规则自主更新状态，信息在邻居间传播。

失败模式：

• 涌现行为不可预测且难以干预
• 规则设计依赖 LLM 但结果不可控
• 局部最优不等于全局最优

何时升级：架构演进到此已达到去中心化极限。后续演进方向是多个 CA 系统的组合。

17种架构总览¶

关键技术洞察¶

控制流三要素¶

每看到一个新的"agent 架构名词"，先问三个问题 ：

• 它新增了什么 state？
• 它新增了什么 router？
• 它新增了什么 evaluator？ 答不出来就不是新架构，只是旧架构换了个名字。

LLM 作为 critic 比作为 generator 更稳定¶

Reflection 将"生成"拆成两个不同职能的 pass 后，critic 往往比 generator 表现更稳定——这是整个架构演化路线的底层判断。其深层原因可能是：评估任务（比较两个输出的优劣）比生成任务（从头产生正确内容）的解空间更窄，LLM 在窄空间内校准更容易。此判断对实际系统设计有直接指导：优先为 Critic 分配更强或更专精的模型资源。

ToT 的关键判断：搜索控制交给代码，不交给 LLM¶

Tree-of-Thoughts 的正确实现是：LLM 负责生成候选动作（proposer），程序化代码负责搜索树的扩展和剪枝。把搜索控制交给 LLM 是反模式。这意味着 ToT 的工程实现难度不在 prompt 设计，而在于状态空间定义和搜索算法的选择。若搜索树规模受控（如代码搜索、数学证明），ToT 价值显著；若问题无良好可定义分支结构（如开放域写作），ToT 容易组合爆炸。

真正高级的 agent 不是更敢做事，而是更知道什么时候不该做¶

Dry-Run（副作用闸门）+ Metacognitive（自我边界）的组合，让 agent 从"能做"升级到"知道不该做"。这两条路线在 17 种架构中的位置靠后，暗示当前 Agent 系统的成熟度仍处于早期——大多数生产系统尚未到达需要严格边界控制的阶段。

从 Multi-Agent 到 Blackboard 到 Meta-Controller 构成认知分工的渐变谱系¶

三者都解决"谁来处理"的问题，但控制粒度不同：

• Multi-Agent：固定流水线（角色在编译时确定）
• Blackboard：动态调度（controller 在运行时决定激活谁）
• Meta-Controller：入口分诊（一次性判断后转发）

选择哪个取决于：任务复杂度是否随时间增长、角色边界是否清晰、调度开销是否可接受。实践中许多团队过早引入 Blackboard 的动态调度复杂度，实际上用 Multi-Agent 的固定流水线即可解决问题。

Evaluator 五类¶

架构演进中产生了五种 Evaluator 类型： 1. LLM-as-a-Judge：用 LLM 评估输出质量 2. 内置 Critic：专门训练的评估模块 3. 程序化验证：可执行代码验证结果正确性 4. Human-in-the-Loop：人工审批 5. 演示式验证：通过执行结果验证（如 Dry-Run）

选型速查¶

最终结论¶

大多数系统从 ReAct 起步，但可靠系统一定会引入验证、记忆和边界控制。Agent architecture 不是模型能力表，而是控制流设计史 。

三句话总结： 1. 先把状态和控制流画清楚 2. 大多数从 ReAct 起步，可靠系统一定引入验证/记忆/边界控制 3. 真正高级的 agent 不是更敢做事，而是更知道什么时候不该做

深度分析¶

1. 控制流三问是架构去重的方法论，而非装饰性框架。原文提出判断"是否为新架构"的三问：新增了什么 state、新增了什么 router、新增了什么 evaluator。这不是教学噱头，而是区分真实架构创新与营销换词的操作标准。例如 Tool Use 相对于基础 generation 新增了 tool_calls state 和 tool-result router；ReAct 在 Tool Use 基础上新增了 observation loop 的回边。掌握此框架，可在听到新架构名词时立即还原其本质。

2. LLM-as-Critic 比 LLM-as-Generator 更稳定是整个演进路线的底层判断。Reflection 架构最早揭示此规律，后续 Self-Improve、PEV 均延续此逻辑：分离生成与评估，让擅长评判的模块不受生成噪声干扰。其深层原因可能是评估任务（比较两个输出的优劣）比生成任务（从头产生正确内容）的解空间更窄，LLM 在窄空间内校准更容易。此判断对实际系统设计有直接指导：优先为 Critic 分配更强或更专精的模型资源。

3. 架构演进方向从"更敢做"转向"更知道不该做"。Dry-Run（副作用闸门）与 Metacognitive（自我边界）的组合标志着能力崇拜到风险意识的范式转移。前者用模拟执行将不可逆副作用拦截在决策前，后者用自我建模将"能力边界"显式化为可查询的状态。这两条路线在 17 种架构中的位置靠后，暗示当前 Agent 系统的成熟度仍处于早期——大多数生产系统尚未到达需要严格边界控制的阶段。

4. ToT 类架构的实现关键在于搜索控制权归属，而非 LLM 生成的候选质量。原文明确指出"把搜索控制交给 LLM 是反模式"：正确的分工是 LLM 负责 proposer（生成候选动作），程序化代码负责扩展和剪枝。这意味着 ToT 的工程实现难度不在 prompt 设计，而在于状态空间定义和搜索算法的选择。若搜索树规模受控（如代码搜索、数学证明），ToT 价值显著；若问题无良好可定义分支结构（如开放域写作），ToT 容易组合爆炸。

5. 从 Multi-Agent 到 Blackboard 到 Meta-Controller 构成一条认知分工的渐变谱系。三者都解决"谁来处理"的问题，但控制粒度不同：Multi-Agent 是固定流水线（角色在编译时确定），Blackboard 是动态调度（controller 在运行时决定激活谁），Meta-Controller 是入口分诊（一次性判断后转发）。选择哪个取决于任务复杂度是否随时间增长、角色边界是否清晰、调度开销是否可接受。实践中许多团队过早引入 Blackboard 的动态调度复杂度，实际上用 Multi-Agent 的固定流水线即可解决问题。

实践启示¶

1. 新项目从 ReAct 起步，在 output quality 检查点之前不要引入 Planning/PEV。过早引入显式规划会增加系统复杂度但收益有限——当单步输出质量尚不稳定时，多步规划只是在放大每一步的错误。正确的迭代顺序是：先用 ReAct 跑通基础流程，再用 Reflection 闭环质量，最后根据失败模式决定是否需要 PEV 验证介入。

2. 实现任何需要多轮迭代的架构时，第一件事是定义 state 的 schema 并画拓扑图。17 种架构的核心差异都是 state 结构和流转规则。定义清楚 draft/critique/verification_result/memory 等状态字段的类型和含义，比写 prompt 更重要。拓扑图（线性/循环/分叉/汇聚）直接决定控制流代码的分支走向。

3. 引入 Multi-Agent 时，优先用固定流水线而非动态调度。Meta-Controller 和 Blackboard 的动态调度能力很诱人，但带来 controller 决策稳定性、信息冲突和循环风险等新失败模式。先用 Multi-Agent 的顺序 pipeline 验证角色边界是否正确，等固定流程稳定后再考虑升级到动态调度。

4. 在 Memory 系统上线前，必须设计遗忘或覆盖机制。Episodic Memory 的明确失败模式是"错误记忆长期污染"——向量相似度召回会持续带出已被修正的错误上下文。Graph Memory 虽然支持多跳推理，但错误的实体关系比错误文本更难发现。生产系统应内置置信度衰减或人工标注纠正通道。

5. 安全相关的 Agent 必须实现 Dry-Run 闸门，并在 Metacognitive 层显式维护能力边界表。将 dry_run=True 作为所有外部操作工具的默认参数，先在模拟环境验证结果后再执行真实副作用。同时在 system prompt 之外用结构化 state 维护 AGENT_SELF_MODEL（工具列表、置信度阈值、高风险话题），让路由决策可被审计而非依赖 LLM 的隐式判断。

相关实体¶

• 基于多智能体架构的深度思考交易系统
• Claude Code 架构解析
• AI Agent 记忆系统架构
• Self-Evolving Agents 系统性综述
• Hermes Agent 记忆系统深度拆解
• Agent 时代架构师技能指南
• Agent Memory System Design
• Agent Memory System 设计指南
• Claude Code 源码核心机制详解
• AI Agent 工程师能力地图
• MOC