R

S02 流派架构对照表

创建 2026-05-18 更新 2026-06-12 5 条双链 Agent 专题 AI 整理

S02 流派架构对照表

一句话定义：把 ReAct / Plan-and-Execute / Reflexion / LATS / Multi-Agent / Computer Use 六种主流 Agent 范式映射到 S01 Agent 六层架构剖面 的六层堆栈上，看每个范式”重心层”在哪里——重心决定适用场景，重心冲突决定它们为什么不能简单叠加。

0. 为什么要做这张表

c10/m206/m207 把范式当成”技术列表”列出来——你能记住名字，但你不知道什么时候选哪个、为什么不能全选。

把范式压到六层堆栈上之后，三件事立刻清楚：

  1. 每个范式在某些层”重投入”，在另一些层”近乎为零”——这是它的 DNA，不是 bug；
  2. 范式之间的组合是有序的——Computer Use 可以包在 Plan-and-Execute 外面，反过来不行；
  3. 所谓”流派之争”很多时候不是技术分歧，而是工程哲学分歧（控制 vs 涌现）——后面会展开。

1. 对照矩阵（六层 × 六范式）

强（●●●） / 中（●●○） / 弱（●○○） / 无（○○○）。每格 1-2 句简评。

范式 \ 层感知规划记忆工具执行反思
A03 ReAct (G1)●○○
纯文本输入		●○○
隐式规划（thought 即 plan）		●○○
上下文窗口即记忆		●●●
工具调用是核心		●○○
简单 while-loop		○○○
无显式反思
A05 Plan-and-Execute●○○
同 ReAct		●●●
显式 plan 树、可审计		●●○
plan 状态需持久化		●●●
执行子任务必需工具		●●○
状态机 / 重规划逻辑		●○○
重规划即弱反思
A04 Reflexion (G3)●○○
同 ReAct		●●○
在 ReAct 基础上多一层 reflection-guided plan		●●●
反思笔记是长期记忆		●●●
工具调用 + 失败可学习		●●○
需要 episodic memory 持久化		●●●
显式反思 + 反思笔记
LATS / Tree Search●○○
同 ReAct		●●●
显式搜索树 + 节点扩展		●●●
完整树状态 + 节点 value		●●●
工具是动作空间		●●●
树管理 / 回溯 / 剪枝		●●●
节点打分即反思（value 估计）
Multi-Agent (A07 Multi-Agent Teams)●●○
多 Agent 各自感知		●●●
角色分工式规划		●●●
共享 + 私有记忆		●●●
每 Agent 各有工具集		●●●
消息总线 + 协调者		●●○
反思常委托给 critic agent
Computer Use●●●
视觉 + DOM 双通道		●●○
中等粒度 plan		●●○
屏幕状态需缓存		●●●
屏幕动作是工具		●●●
高错误率需重试 / 校验		●○○
通常弱反思

读法：先看”●●●“列在哪——那是这个范式的”重心层”。再看”●○○“列在哪——那是它要靠组合或外置补足的层。

矩阵表的反共识结论（R3 新增）

从这张表里读出来的最重要的一句话不是”每个范式有自己的重心层”——而是 Multi-Agent 是六层中除感知外全部重投入的范式。

观察矩阵第 5 行：Multi-Agent 在规划、记忆、工具、执行四层都是 ●●●，反思也是 ●●○，只有感知是 ●●○ 而非 ●●●。这意味着 Multi-Agent 的工程成本不是”在某一层多花一份钱”的单点累加，而是”在每一层都多花一份钱”的面状放大——因为每个 agent 都要有自己的规划、记忆、工具集、执行循环。

这正是为什么 Anthropic 在 Building Effective Agents 反复强调”先单 agent”——他们看到的不是”multi-agent 复杂”，而是”multi-agent 在六层架构上有六重成本”。PM 视角下，默认不应该选 Multi-Agent——除非任务确实满足 A07 Multi-Agent Teams § 三的三题判据。

这是矩阵表能给的最大反共识 takeaway——不是”挑重心层最合适的范式”，而是”避开六层全重的范式作为默认”。

2. 每范式的”重心层”如何决定适用场景

2.1 ReAct：工具层独重

ReAct 的全部聪明都在工具层——thought-action-observation 滚动续写本质是”问 LLM：基于你看到的，下一步调哪个工具”。

适用：步骤少（≤ 5）、任务边界清晰、工具集小（≤ 10）的场景。典型——客服 Agent、搜索增强问答、单步代码 lint。

不适用：步骤多（> 10）——上下文爆炸 + 复合错误（c10 § 10.3 数学：单步 95% → 10 步 60%）；需要回溯——ReAct 是单向流，回不去。

与 c10 § 10.4 的关系：c10 说”单 Agent + 多工具是最简单的架构”，那就是 ReAct。

2.2 Plan-and-Execute：规划层独重

把”想”和”做”切开——先生成完整 plan，再逐步执行。这是把 A03 ReAct 隐式的 plan 显式化。

适用：步骤多但可预先规划、任务可拆解、需要让人审核 plan（关键 HITL 断点在”规划完毕、执行前”）。典型——研究 Agent、Manus、DeerFlow。

不适用：环境高度动态（plan 还没执行完就 stale）、需要探索式试错（plan 一开始就要 commit 死）。

2.3 Reflexion：反思层独重

在 ReAct 失败后注入”反思笔记”——这一次失败的原因 / 下次如何避免——以 episodic memory 形式存到长期记忆，下次任务时检索回来。

适用：相同任务会重复出现、有训练-推理闭环、单次任务失败成本不大但累积学习价值高。典型——AlphaCode 类竞赛、自动化代码评测改进、长期客户支持知识沉淀。

不适用：一次性任务、任务高度异质（反思笔记无法迁移）、对单次正确率要求极高（反思来不及救火）。

2.4 LATS：规划层 + 反思层 + 执行层三重

把规划做成可回溯的搜索树，每个节点用 value（来自反思打分）指导扩展。本质是 MCTS（蒙特卡洛树搜索）+ LLM。

适用：搜索空间有限可枚举、单步成本不高（可以多 rollout）、对最优解的追求胜过对成本的追求。典型——SWE-bench 上的研究型方案、定理证明、复杂规划问题。

不适用：单步贵（截图任务做不起 tree search）、实时交互场景（响应延迟会炸）、生产环境（成本通常不可接受）。

2.5 Multi-Agent：执行层独重，规划/记忆中重

A07 Multi-Agent Teams 不是技术范式，更像组织范式——通过”角色分工”把单 agent 的认知过载分摊到多个 agent。CrewAI 用”角色 + 任务”语言、AutoGen 用”对话 + GroupChat”语言、DeerFlow 用”研究 / 编码 / 报告”分工。

适用：任务天然可分（研究 + 编码 + 报告）、角色边界稳定、能接受协调开销。典型——研究 Agent（DeerFlow）、复杂内容创作（多角色对话）。

不适用：任务高度耦合（拆了之后不停”互相回灌”）、上下文不能分隔（每个 agent 都要全量上下文 → 成本爆炸）、协调成本超过分工收益。

详见 m208 § 编排框架对比 中关于 CrewAI / LangGraph 的选型。

2.6 Computer Use：感知层重 + 执行层重 + 工具层”用屏幕动作”

把”屏幕”当作通用接口——任何人类能用鼠标键盘做的事，理论上 Agent 都能做。

适用：目标系统无 API（遗留 ERP、老旧 CRM、个人桌面应用）、不可改造的第三方系统、需要”像人一样操作”的演示与回放。典型——Anthropic Computer Use beta、OpenAI Operator、Manus 通用任务。

不适用：有 API 时（成本差 10-100 倍，详见 m209 - 推理成本控制手册）、需要确定性时（屏幕理解错误率比 API 高一个数量级）、对延迟敏感（每步几秒到十几秒）。

m206 已明确：“Computer Use 适合无 API 的遗留系统自动化，不应该作为有 API 情况下的首选。” 本节点提供了这条结论的层级解释——Computer Use 用感知层 + 工具层的高额预算换 API 不可得的能力，能做交易就别做。

3. 范式的组合性：什么能套什么

范式不是互斥的”流派标签”，更像可叠加的”图层”。但叠加是有序的——内层应该比外层粒度更小、决策更短。

3.1 合法组合

外层内层实例
Plan-and-ExecuteReAct主流。先 plan，每个子任务内部用 ReAct 跑工具
Plan-and-ExecuteComputer UseManus 的核心模式。plan 划阶段，每阶段用浏览器执行
Multi-AgentReActCrewAI 的每个 worker 内部就是 ReAct
Multi-AgentReflexion高级用法——每个 worker 是 reflexion agent，长期共享反思笔记
LATSReActLATS 的每个节点”扩展”调用一次 ReAct rollout
ReflexionPlan-and-Execute反思笔记里包含”上次哪一步 plan 错了”，下次 plan 时检索

3.2 不合法（或难协调）的组合

  • ReAct 套 Multi-Agent：单 agent 的 ReAct 循环里临时召唤多 agent，协调开销 > ReAct 本身预算
  • Computer Use 套 LATS：屏幕动作不可逆，无法回溯——树搜索的基本假设违反
  • Reflexion 套 LATS：两层都重反思，反思反思，循环难收敛

3.3 组合的元规则

  • 外层粒度大 / 内层粒度小——plan 是粗粒度结构，ReAct 是细粒度执行。反过来会让外层无法收敛。
  • 不可逆动作不能放在可回溯结构里——Computer Use 的”点提交按钮”不能给 LATS 试错。
  • 反思层只能有一处——否则陷入”我在反思我的反思”无限递归。

4. 流派之争的本质：控制 vs 涌现

把范式按”显式控制”到”隐式涌现”排序：

显式控制 ←———————————————————→ 隐式涌现
LangGraph    Plan-and-Execute    ReAct    AutoGen GroupChat    LATS Tree Search
显式状态图    显式 plan tree      隐式 plan   多 agent 对话涌现   搜索 + value 涌现

LangGraph 在最左——一切边和状态都要画出来；AutoGen 的 GroupChat 偏右——“让几个 agent 讨论，看看会发生什么”；LATS 在最右——把决策权完全交给搜索 + value 估计。

这是工程哲学的两条传统：

  • 理性主义控制论：从泰勒制、控制论（Wiener）、操作系统设计、Hashimoto 在 Hashicorp 的工具传统——一切都要可观测、可配置、可重现。落到 Agent 就是 LangGraph / Plan-and-Execute。
  • 涌现主义系统论：从复杂适应系统（Holland）、群体智能、多主体仿真传统——少给规则、看会涌现什么。落到 Agent 就是 LATS / AutoGen GroupChat。

这两条传统不只是技术偏好——它们对应对智能本身的两种立场：

  • 控制派认为：智能是工程结果，不可控就是不可用。
  • 涌现派认为：智能本质上不可完全控制，过度控制等于砍掉它的能力上限。

Polanyi 给控制派的具体认识论挑战（R3 扩展，从装饰升级为论证）：这与 Polanyi 默会知识与提示工程的认识论张力 同源——Polanyi 说”我们知道得比我们能说出的更多”。Polanyi 的洞察给控制派一个具体的认识论挑战：当控制派试图把所有”agent 该如何决策”都写进 plan 和 state graph 时，Polanyi 提醒我们”真正高效的判断往往无法被显式化”——老程序员看一眼代码就知道有问题，但说不清为什么；老医生看一眼病人就知道严重程度，但写不进诊断手册。

所以纯控制派 orchestrator（LangGraph）在”高度结构化任务”上是最优（API 流水线、ETL、合规审查这些每一步都可显式化的任务），但在”需要直觉的探索任务”上注定碰壁（写一篇有洞察力的报告、调试一个跨多模块的复杂 bug、设计一个新产品方案）。这就是为什么 Claude Code 即便有 plan mode，仍保留”让模型自由发挥”的余地——它知道把所有判断都显式化是 Polanyi 意义上的认识论傲慢。

对 PM 的具体启示：选 LangGraph 之前先问”我的任务步骤是不是每一步都能写下来”——如果答”不能”，说明你需要给涌现派留位置；如果硬上 LangGraph，会得到一个能跑但永远做不深的系统。

Polanyi 默会知识在 LLM 时代可能被部分内化(R4 新增 — 反 confirmation bias)

R4 修正:本节点 § 4 把 Polanyi 默会知识当成”已被验证的认识论真理”反复使用——这是 echo chamber 倾向。Polanyi 本身是 1958 年的哲学论著,在 LLM 时代的适用性其实需要重新论证:默会知识到底有多少能被 LLM 内化?多少永远漏?这是个开放问题,不是已解决的真理。

LLM 可能正在挑战 Polanyi 的强版本:

  • LLM 的 in-context learning 可能就是”显性化默会知识”的工程实现:你给 LLM 5-10 个 examples,它能在没见过的新场景上 generalize—— 这其实是把”过去专家的默会判断”通过 examples 显性化,让 LLM 学到。
  • LLM 的 RLHF/DPO 也可能内化部分默会知识:Anthropic Constitutional AI、OpenAI RLHF 都是把”人类的默会偏好”通过 reward model 编码进权重——这与 Polanyi 说的”默会知识不能被显性化”形成张力。
  • Hubert Dreyfus(详见 S03 Harness Engineering 全景 § 5.4 R4 新增)其实部分驳斥了 Polanyi:Dreyfus 说 LLM 永远停在 Level 1-2,但他也承认 LLM 在 Level 1-2 已经显著超越早期符号 AI——这意味着默会知识的”Level 1-2 部分”是可以被显性化的(通过 prompting、in-context learning、fine-tuning),只是 Level 3+ 部分不行。

Polanyi 在 LLM 时代需要的修正版本:

  • 强版本(Polanyi 原意):默会知识完全不能显性化。
  • 弱版本(R4 提议):默会知识可以被部分显性化(Level 1-2 部分),但 Level 3+ 的”直觉判断”和”专家嗅觉”仍无法显性化。LLM 时代的 in-context learning / RLHF 显著扩大了”可显性化部分”,但没有改变”不可显性化部分”的边界。

对本节点 § 4 的具体修正:

  • 不再说”Polanyi 给控制派致命挑战”—— 改为”Polanyi 给控制派提供一个边界,但这个边界正在被 LLM 时代的工程实践不断推前”。
  • 承认 LangGraph + LLM 的组合可能比纯 LangGraph 解决更多”需要直觉的探索任务”——前提是把直觉的”Level 1-2 部分”通过 prompting/RAG/examples 显性化,让 LLM 学到;只有 Level 3+ 部分仍需要人类介入。

对 PM 的具体启示:

  • 在选型 LangGraph vs AutoGen 时,不要把”Polanyi 默会知识” 当成反 LangGraph 的万能论据 —— 这是对 Polanyi 的过度引用。
  • 正确做法是问”我的任务的’直觉部分’是 Level 1-2(可通过 examples 显性化)还是 Level 3+(必须人类介入)” —— 答案不同,选型完全反向。Level 1-2 任务选 LangGraph + 好 prompt 就够;Level 3+ 任务必须设计 HITL,任何 orchestrator 都做不到完全自动化。

韦伯科层制 vs 阿伦特复多性也是同一组对照——CrewAI 的”角色 + 任务”是科层制思维（明确职责、自上而下），AutoGen GroupChat 是阿伦特意义上的”复多性涌现”（多个独立行动者在对话中产生新意义）。

参考 范式 章节的库恩讨论——这种工程哲学的两极对立，本质上是同一研究纲领内部的方法论分歧，不是真正的”范式革命”。真正的范式革命是 G5/G6 的”原生 agent 模型”——直接训练 LLM 自带 plan/reflect/tool-use 能力，那时控制 vs 涌现的分歧会被部分悬置。详见 G01 Agent 代际谱系总图 关于 G6 的预测。

5. 选型决策表（PM 直接抄）

你的场景特征推荐范式内层
步骤 ≤ 5、单一目标ReAct—
步骤 > 10、可预先 plan、需要人工审核 planPlan-and-ExecuteReAct
相似任务重复出现、有学习闭环ReflexionPlan-and-Execute
任务可分（研究 / 编码 / 报告）、角色稳定Multi-AgentReAct 或 Reflexion
目标系统无 API、必须 GUI 操作Plan-and-ExecuteComputer Use
学术研究 / 评测刷分 / 不计成本LATSReAct
不知道选什么Plan-and-ExecuteReAct

最后一行不是开玩笑——P&E + ReAct 是”中庸的好默认”，落地概率最高、debug 最容易、可演进性最强。

与已有节点的关系

  • 对 c10 - Agent 技术栈与工具调用：c10 § 10.4 列了三种架构模式（单 Agent + 多工具 / 多 Agent 协作 / MCP），但没做范式矩阵化对比。本节点补缺。
  • 对 m207 - Agent 产品化：场景推演与失败模式：m207 给了失败模式分类。本节点告诉你”哪些范式更易在哪一类失败上踩坑”——比如 ReAct 易在”无限循环”、Multi-Agent 易在”雪崩效应”。
  • 对 m208 - AI 基础设施与中间件选型：m208 比较了 LangChain / LangGraph / CrewAI / Dify。本节点的范式视角解释了为什么 LangGraph 和 CrewAI 都存在却不互相替代——它们的重心层不同（LangGraph 重执行层的状态图，CrewAI 重规划层的角色分工）。
  • 对 S01 Agent 六层架构剖面：S01 给静态分层，S02 把动态范式映射到静态分层上——配套使用。
  • 对 Skill 系统的本质：Skill 是 procedural knowledge 的封装，可以看作”反思层的一种制度化”——把过去成功的反思笔记沉淀为可复用模板。

PM 决策启示

面试：被问”ReAct 和 Reflexion 区别是什么”——直接画范式矩阵的两行：ReAct 在反思层是”无”，Reflexion 在反思层是”强”且使用 episodic memory 持久化。然后追问任何一格都能展开。

选型：用第 5 节的决策表当起点，然后用第 3 节的组合规则校验”我打算的组合合法吗”。落地之后用 S01 Agent 六层架构剖面 的接口表逐层 review 实现。

面试反向问”为什么不用 LATS”：说出”单步成本不允许 tree search、生产环境不接受 rollout 多次”——这比说”LATS 太复杂”具体得多，证明你理解它的重心层而非只是听过名字。

架构师转型 PM：你以前讨论”控制 vs 涌现”是讨论操作系统设计或微服务架构。在 Agent 领域这个张力完全可平移——LangGraph 是 Kubernetes 风格的”声明式编排”，AutoGen 是 actor model 风格的”消息涌现”，你的旧 mental model 几乎可以直接用。

与 S01 Agent 六层架构剖面 的对话（R3 新增）

S01 给六层骨架，S02 把六种范式映射到六层。两节点必须配对阅读：

  • 看一个 Agent 产品的”骨架”用 S01 § 1 架构图。
  • 看一个 Agent 产品”重心层在哪、走的是什么范式”用 S02 § 1 矩阵。
  • 看”层间耦合点会不会被该范式踩雷”——回 S01 § 9 三个致命耦合点。例如：Multi-Agent 范式在 S01 § 9 耦合点 1（工具层和执行层）问题被放大 N 倍（N 个 agent × 每个的重试），所以选 Multi-Agent 前必须先把”全局重试预算”做好。

关联节点

核心关联（必读）：

延伸关联（可选）：

修订日志

  • 2026-06-11 P3.4 校链：修订日志内简写死链 S01 补全为真实节点名 [S01](/kb/专题-安全对齐与失败/s01-agent-六层架构剖面/)
  • R3 → R4（2026-05-18）：本轮聚焦反方对话训练 + Polanyi 在 LLM 时代的边界承担。修订要点:
    1. § 4 新增 “Polanyi 默会知识在 LLM 时代可能被部分内化” —— 反 confirmation bias 修订:承认 Polanyi 原版”默会知识完全不能显性化”是强版本,LLM 时代的 in-context learning / RLHF 显著扩大了”可显性化部分”
    2. § 4 新增 Polanyi 修正版本:默会知识可以被部分显性化(Level 1-2 部分),但 Level 3+ 仍无法显性化 —— 与 Dreyfus 技能分级理论联动(详见 S03 Harness Engineering 全景 § 5.4 R4 新增)
    3. § 4 给 PM 的具体启示:不要把”Polanyi 默会知识”当成反 LangGraph 的万能论据;问”Level 1-2 还是 Level 3+”
    4. 引入的对手立场:LLM 时代对 Polanyi 强版本的工程挑战、Dreyfus 技能分级理论(部分驳斥 Polanyi 强版本)
  • R2 → R3（2026-05-18）：聚焦判断密度提升。本轮修订要点：
    1. § 1 矩阵表下新增”反共识结论”段（300 字）——“Multi-Agent 是六层全重的范式，PM 默认不应选”——回应 Round 2 [失血-6]
    2. § 4 Polanyi 段从 50 字装饰扩展到 200 字论证”控制派的认识论挑战”——回应 Round 2 [装饰-6]
    3. § 4 Polanyi 段加 PM 具体启示”选 LangGraph 前先问’我的任务步骤是不是每一步都能写下来’”
    4. 新增 § “与 S01 的对话”，与 S01 § 9 致命耦合点联动——回应 Round 2 [对话缺失] 的 S01 ↔ S02 桥
    5. 关联节点分两档
  • R1 → R2（2026-05-18）：Round 1 同行评议未针对本节点提出具体修订项，无修订动作。
  • 2026-06-12 内审修复：frontmatter 补 final_path 字段（= 本文件在库内实际相对路径）。