⚠️ AI 生成标识 · 本文由 AI Agent 协助撰写，人类作者审核发布。
一、写在前面
这篇文章不是教程，是一次知识收网。
过去几天我花了几个小时跟我的 AI Agent 对话，从 Agent 八股文一路聊到生产落地。这篇文章把对话中涉及的所有核心概念串联起来，形成一个完整的知识体系。
二、三层架构
Agent 系统的所有概念可以归纳为三个层次：
1
2
3
4
5
6
7
8
9
10
11
12
┌────────────────────┐
│ Workflow 模式 │ ← 多步骤编排
│ Chain / Router │
│ Parallel / Orch │
├────────────────────┤
│ Agent 范式 │ ← 想 + 做的组织方式
│ ReAct / Reflexion │
│ Plan-and-Solve │
├────────────────────┤
│ 推理模式 │ ← 一步怎么想
│ Direct / CoT │
└────────────────────┘
这三层是堆叠关系：上层依赖下层。
三、第一层：推理模式
什么是推理模式
推理模式 = LLM 在一步思考单元内部组织思维的方式。它不关心外部行动、工具调用、步骤编排——它只关心脑子里面怎么转。
模型涌现的推理模式
这些是 LLM 自身具备的能力——不需要外部代码辅助，模型在训练中就已经学会了。
| 模式 | 本质 | 一句话 |
|---|---|---|
| Direct | 输入 → 输出 | 一步到位 |
| CoT（思维链） | 输入 → 推理1 → 推理2 → … → 输出 | 一步步想 |
框架实现的推理增强策略
这些不是模型原生的推理方式——它们是外部代码多次调用 LLM，再用搜索/投票/剪枝等算法组合结果。
| 策略 | 本质 | 一句话 | 实现方式 |
|---|---|---|---|
| Self-Consistency | 多次 CoT → 投票选最一致的 | 多次思考取共识 | 外部并发调用 N 次 LLM，投票选答案 |
| ToT（思维树） | 同时探索多条路径 → 剪枝 → 选最优 | 像下棋一样推演 | 外部维护搜索树，逐层扩展开启新 LLM 调用 |
| GoT（思维图） | 推理节点形成图结构，可以合并/分支 | 最灵活，最贵 | 外部维护图结构，控制 LLM 调用链路 |
用一句话区分：
CoT 我什么都不用做，模型自己会。ToT 我得写代码去调 N 次 LLM、比较结果、砍分支。
这也解释了为什么 LLM（如 ChatGPT）天然能做 CoT，但不会自己跑 ToT——因为 ToT 不是它内部的能力，是需要外部代码编排的流程。
核心洞察
CoT、ReAct、Reflexion 不是三个不同的推理模式。这是市面上八股文最常见的错误。
拆开来看：
- ReAct 里的 “Thought” 用的就是 CoT
- Reflexion 里的 “审查” 用的也是 CoT
它们共享同一个元模式：
1
当前状态 → LLM 评估 → 决定下一步 → 执行 → 新状态 → 再评估 → ...
区别只在于关注的方向不同：
| 模式 | 关注方向 | 类比 |
|---|---|---|
| CoT | 向内看 — 盯着自己的推理链 | 心里盘算 |
| ReAct | 向外看 — 盯着外部世界的反馈 | 边做边看 |
| Reflexion | 向后看 — 盯着自己的历史输出 | 交卷后检查 |
它们是同一个引擎在三个方向上的投影，不是三个不同的引擎。
四、第二层：Agent 范式
范式不是平级的——它们是不同维度的
很多人学 Agent 时会看到一张并列的表格：
| ReAct | 边想边做 |
| Reflexion | 做完回头审查 |
| Plan-and-Solve | 先计划后执行 |
| Multi-Agent | 多 Agent 协作 |
但事实是：它们不在同一个维度上，不能并列。 还有另一个重要的区分：有些范式靠模型自身能力实现，有些靠写死的代码结构实现。
执行策略：ReAct vs Plan-and-Solve
这两个才是真正同一层级的东西——它们回答“怎么执行”：
1
2
3
4
5
6
ReAct：边想边做，没有预设计划
Thought → Action → Observation → Thought → ...
Plan-and-Solve：先制定完整计划，再逐步执行
Plan 阶段：制定计划，不写代码
Solve 阶段：按计划执行，不改计划
它们不是互斥的，可以嵌套。
Copilot Workspace 就是例子：
- 外层是 Plan-and-Solve：先规划 Issue 的修改方案，再执行
- 内层的 Solve 阶段里嵌了 ReAct：写代码 → 检查语法 → 发现错误 → 修正
质量机制：Reflexion（可叠加）
Reflexion 不是跟 ReAct、Plan-and-Solve 平级的——它是可以贴在任意执行策略外面的质量保障层：
1
2
3
4
无 Reflexion 有 Reflexion
──────────── ────────────
ReAct ChatGPT 普通对话 ChatGPT 写完代码自己检查一遍
Plan-and-Solve 按计划机械执行 执行完审查 → 发现不对 → 修订计划 → 重做
Reflexion 回答的是”怎么保证质量“，而不是”怎么执行”。
协作模式：Multi-Agent（另一个维度）
Multi-Agent 回答的是”一个人干还是多个人干“，跟”怎么干”是正交的：
1
2
3
4
5
单 Agent Multi-Agent
──────── ────────────
ReAct ChatGPT 多个 ChatGPT 各干各的
Plan-and- 一个 Agent 计划并执行 一个 Orchestrator 分配任务
Solve 多个 Specialist 各自执行
真正的分界线：模型能力 vs 代码结构
这是理解 Agent 范式最容易被忽略的一个维度。
有些范式是模型自身涌现的能力——LLM 在训练过程中学会了怎么做，不需要你写额外的代码去实现它：
1
2
3
4
5
6
7
8
9
10
11
CoT（思维链）
→ 模型在脑子里一步步推理，这是训练出来的能力
→ 你不需要写一个 "CoT 模块" 去强制它
规划（Planning）
→ 模型在 thinking 里自己规划先做什么后做什么
→ 你不需要写一个 "Plan 模块"
反思（Reflection）
→ 模型收到负面反馈后会修正自己的输出
→ 你不需要写一个 "Reflexion 循环"
这些能力存在于模型的参数里，跟模型大小和训练数据有关。你作为开发者不需要写代码去实现它们——你只需要给模型合适的 prompt，它自己就能做。
另一些范式是代码硬编码的结构——LLM 没有选择权，必须按你写的代码走：
1
2
3
4
5
6
// Chain——代码写死的顺序，LLM 不能跳过
void process(frame) {
step1(frame); // 必须第一步
step2(frame); // 必须第二步
step3(frame); // 必须第三步
}
1
2
3
# Router——代码写死的分支，LLM 不能自己选
matrix:
os: [ubuntu, macos, windows]
1
2
# Multi-Agent——代码写死的分工，LLM 不能自己合并
crew = Crew(agents=[spec_agent, code_agent, review_agent])
ReAct 是两者的交界
ReAct 比较特殊——它横跨了两个世界：
1
2
3
4
5
6
7
8
ReAct 循环：
Thought（推理） ← 模型能力（CoT 涌现）
↓
Action（调工具） ← 代码结构（写死的 Tool 调用）
↓
Observation ← 代码结构（写死的返回值处理）
↓
Thought（推理） ← 模型能力（CoT 涌现）
Thought 靠模型自己”想”，Action/Observation 靠代码写死。 这就是为什么 ReAct 看起来既像”范式”又像”模型行为”——它本来就是两者的混合体。
总结表格
1
2
3
4
5
6
7
8
9
靠模型涌现 靠代码硬编码
────────── ────────────
CoT ✅ ❌
规划（Plan） ✅ ❌
反思（Reflection） ✅ ❌
ReAct ⚠️ Thought 部分 ⚠️ Tool 调用部分
Chain ❌ ✅
Router ❌ ✅
Multi-Agent ❌ ✅
这也解释了为什么 LLM（比如 ChatGPT）看起来能”自己反思”和”自己规划”——不是因为它的代码里有一个 Reflexion 模块或 Plan 模块，而是模型本身就会这些。但如果你要它必须按固定流程走、或者同时调度多个 Agent——那就必须写代码。
范式总结
1
2
3
4
5
6
7
8
9
执行策略（同一级，可二选一或嵌套）
├── ReAct（边想边做）—— Thought 靠模型，Tool 靠代码
└── Plan-and-Solve（先想后做）—— 计划靠模型，执行靠代码
质量机制（可叠加在任一种之上）
└── Reflexion（执行后审查）—— 靠模型涌现
协作模式（另一个维度）
└── Multi-Agent（多个 Agent 协作）—— 靠代码硬编码
不能把它们列成一个四选一的表格——那不是它们真实的关系。
五、第三层：Workflow 模式
Workflow = 把 Agent 范式 + 工具调用 + 决策逻辑编排成可执行的流程。
常见 Workflow 模式
| 模式 | 流程是否固定 | 一句话 |
|---|---|---|
| Chain（链式） | ✅ 完全固定 | 一步一步走 |
| Router（路由） | ⚠️ 分支固定，选谁不一定 | 先判断再分流 |
| Parallel（并行） | ✅ 多个同时 | 多路齐发，汇总结果 |
| Orchestrator（编排器） | ❌ 完全动态 | 主控 LLM 动态分配 |
补充：Sub Agent vs Multi-Agent
很多人搞混这两个概念，因为它们都涉及”多个智能体”。
Sub Agent 是 Workflow 层面的实现手段——父 Agent 临时委派一个子任务，干完就销毁，属于代码硬编码的编排逻辑。
Multi-Agent 是 Agent 范式层面的协作架构——多个常驻 Agent 各司其职，互相通信，属于范式维度中的”协作模式”。
| Sub Agent | Multi-Agent | |
|---|---|---|
| 关系 | 父子委派 | 平级协作 |
| 生命周期 | 临时，用完即毁 | 常驻，长期存活 |
| 通信方式 | 单向：父→子→父 | 双向：A↔B↔C |
| 所属层级 | Workflow 层（代码硬编码） | Agent 范式层（协作维度） |
| 典型例子 | 主 Agent spawn 子 Agent 去查资料 | CodeAgent + TestAgent + ManagerAgent |
六、整个体系的关系图
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
┌─────────────────────────────────────────────┐
│ Workflow │
│ Chain / Router / Parallel / Orchestrator│
├─────────────────────────────────────────────┤
│ Agent 范式 │
│ 执行策略: ReAct / Plan-and-Solve │
│ 质量机制: Reflexion (可叠加) │
│ 协作模式: Multi-Agent (另一维度) │
│ ┌───────────────────┐ │
│ │ 推理模式 │ │
│ │ CoT / Direct │ │
│ │ │ │
│ │ 推理增强策略 │ │
│ │ ToT / Self-Con │ │
│ │ (框架实现) │ │
│ └───────────────────┘ │
├─────────────────────────────────────────────┤
│ 能力底座 │
│ Tools / MCP / Function Calling │
└─────────────────────────────────────────────┘
从下往上：
- Tools / MCP 决定 Agent 能做什么
- 推理模式 决定每一步怎么想（靠模型涌现）
- Agent 范式 决定怎么执行、怎么保证质量、谁来做（模型 + 代码混合）
- Workflow 决定整个流程的编排（靠代码硬编码）
七、总结
整个知识体系可以浓缩为四句话：
- 推理模式管一步怎么想——靠模型涌现（Direct / CoT）
- 推理增强策略管怎么提升推理质量——靠框架实现（Self-Consistency / ToT / GoT）
- Agent 范式管怎么执行 + 怎么保证质量 + 谁来做——模型 + 代码混合（ReAct / Chain / Multi-Agent）
- Workflow 管多步的编排——靠代码硬编码（Chain / Orchestrator）
区分模型涌现和框架实现的关键：
| 能力 | 来源 | 例子 |
|---|---|---|
| 模型自己会的 | 训练时涌现 | Direct、CoT、规划、反思 |
| 需外部代码做的 | 框架编排 | ToT、Self-Consistency、Chain、Multi-Agent |
八股文给你概念，生产环境给你约束。把概念放进三层体系里理解，你就知道什么时候该用什么了。
