Agent 17 种架构模式 分析 思考

0x01 核心概念

对于 Agent Design Patterns，其实有两个维度可以衡量：评估维度和公式维度。评估 6 维度指定设计目标, 公式 6 维度指定设计变量。评估维度定义了优化的目标函数, 公式维度定义了可调参数的搜索空间。两者相辅相成。

1.1 设计目标（评估6维度）

有一种说法是：所有 Agent Design Patterns 本质上围绕6 个核心维度进行设计和权衡:

• 维度一: 🧠 推理质量 (Reasoning Quality)。其核心问题: 如何让 Agent 输出更准确、更可靠?
• 维度二: ⚡ 控制流 (Control Flow)。其核心问题: 谁决定下一步做什么? 如何决定?
• 维度三: 🔒 安全与信任 (Safety & Trust)。其核心问题: 如何确保 Agent 不做错误/危险的事?
• 维度四: 🌿 任务分解与协作 (Decomposition & Collaboration)。其核心问题: 复杂任务如何拆解? 多个执行单元如何协调?
• 维度五: 🗄️ 记忆与状态 (Memory & State)。核心问题: Agent 如何记住过去、利用经验?
• 维度六: 📊 可观测性与评估 (Observability & Evaluation)。核心问题: 如何知道 Agent 做得好不好? 如何持续改进?

本文的每个 Design Pattern 本质上是在这 6 个维度上做出特定的取舍

1.2 设计变量（公式6维度）

Agent = State × Topology(Routing) × Guards × Σ(Plugins via Hooks) × Tools(ACI) @ Mode

这个公式将 Agent 架构分解为六个正交维度，六个维度的笛卡尔积构成了架构的设计空间:

• State 承载系统记忆。
• topology + Routing 定义控制流拓扑与转移决策。
• Guard 提供安全闸门。
• Hook 提供生命周期扩展。
• ACI 定义工具接口。
• Mode 决定执行模式。

这六个正交维度涉及七个概念，具体如下：

1.3 联系

两套维度的核心区别:一个是"你要什么"(评估维度), 一个是"你怎么做"(构造维度)。

映射关系如下：

1.4 产业视角: ETCLSVG 七层分类法

来源:Agent Harness Engineering: A Survey(Li et al., 2026)

与七核心概念的映射:

本篇的 17 种模式分析主要覆盖L (Lifecycle)和V (Verification)两层，E (Execution) 和 G (Governance) 更多的是从实践角度进行补充。

0x02 评估维度

我们再来分析下评估维度（其中涉及到的模式并不限于本篇的17种模式）。

2.1 维度一: 推理质量 (Reasoning Quality)

核心问题: 如何让 Agent 输出更准确、更可靠?

设计思考: 单次 LLM 调用的推理有上限, 如何通过结构化的多步过程突破这个上限?

2.2 维度二: 控制流 (Control Flow)

核心问题: 谁决定下一步做什么? 如何决定?

设计思考:确定性 vs 灵活性的权衡—越自主越强大, 但越难控制和预测。

2.3 维度三: 安全与信任 (Safety & Trust)

核心问题: 如何确保 Agent 不做错误/危险的事?

设计思考: Agent 的能力边界在哪里? 如何让它在边界内自主、在边界外求助?

2.4 维度四: 任务分解与协作 (Decomposition & Collaboration)

核心问题: 复杂任务如何拆解? 多个执行单元如何协调?

设计思考:分工的粒度和协调成本的平衡—拆得太细协调开销大, 拆得太粗失去专业性优势。

2.5 维度五: 记忆与状态 (Memory & State)

核心问题: Agent 如何记住过去、利用经验?

设计思考: LLM 无状态, 如何用外部存储 + 检索机制赋予它"记忆"和"学习"能力?

2.6 维度六: 可观测性与评估 (Observability & Evaluation)

核心问题: 如何知道 Agent 做得好不好? 如何持续改进?

设计思考: Agent 行为非确定性, 传统的"对/错"测试不够, 需要概率性的、多维度的评估体系。

0x03 17 种架构总述

3.1 统一形式化框架

我们可以把Agent 系统定义为一个六元组，后续会据此对17种架构进行分析。

A = (S, T, δ, s₀, F, Γ) S = 状态空间 (所有可能的系统状态) T = 拓扑结构 (有向图 G(V, E), 节点 v ∈ V 为处理单元, 边 e ∈ E 为转移路径) δ = 转移函数 δ: S × E → S (在当前状态 s 下沿边 e 转移到新状态 s') s₀ = 初始状态 (s₀ ∈ S) F = 终止条件集合 (F ⊆ S, 系统进入任意 f ∈ F 则停止) Γ = 不变量集合 (∀ 状态 s 在合法执行路径上, s 必须满足 Γ 中的所有约束)

3.2 演化路径与升级触发

3.2.1 演化图

17 个模式的演化路径与条件如下：

3.2.2 升级触发条件表

这些模型彼此升级之间的关系如下。

3.2.3 成熟度“模型”

我们可以将这些模式分为几个等级。

升级路径: L1 → L2 → L3 → L4 → L5

不要跳级原则:

• 在没有 Tool Use (L2) 前不要上 Multi-Agent (L4)——因为你还不知道单 agent + 工具的能力边界在哪里
• 在没有 PEV (L3) 前不要上 Dry-Run (L4)——因为你还不知道哪些步骤需要人工闸门
• 在没有 Memory (L4) 前不要上 Self-Improvement (L5)——因为 gold 积累需要持久化基础设施

3.3 跨层张力

来源: ETCLSVG 研究揭示的 agent 系统内在矛盾。

1. Cost-Quality-Speed 三难困境

问题: 更多验证 → 更高质量 → 更高成本 + 更高延迟。

应对: 分层验证策略——关键步骤深度验证, 常规步骤采样验证, 低风险步骤跳过验证。

2. Capability-Control 权衡

问题: 更强的 agent (更多工具+更自主) → 更难控制 (blast radius 更大)。

应对: Guard 应该随 capability 同步升级。每新增一个 tool, 至少新增一个对应的 guard。

3. Harness 耦合问题

问题: agent 代码与 LLM 能力强耦合。模型升级后, prompt 策略/验证逻辑/超参可能失效。

应对: 将 LLM 依赖隔离在可替换的 "reasoning layer" 中, harness 逻辑保持模型无关。

4. 自适应简化

"每一个 wrapper 都编码了一个假设。"

问题: 随着模型能力提升, 许多 wrapper (如手工验证规则) 可能成为不必要的瓶颈。

应对: 持续评估每个 wrapper/guard 的边际贡献。当 LLM 在某个任务上 pass rate > 99% 时, 考虑降级为采样验证。

3.4 统一分析法: 6 个固定问题

对任意 Agent 架构, 回答以下 6 个问题即可完成基本分析:

1. 它要解决什么问题?—— 该模式的原始动机和核心场景
2. 它的 State 是什么?—— 状态空间 S 的结构定义
3. 它的拓扑是什么?—— 节点连接方式
4. 它的 Router 怎么工作?—— δ 转移函数的决策逻辑
5. 它的失败模式是什么?—— 常见退化场景及根因
6. 什么时候该升级到下一种?—— 能力边界与升级触发信号

3.5 速查工具

3.5.1 三问判断法

面对一个新提出的"架构", 问三个问题:

1. 新增了什么 State? —— 有没有引入新的状态字段或状态结构?
2. 新增了什么 Router? —— 有没有引入新的路由决策机制?
3. 新增了什么 Evaluator? —— 有没有引入新的验证或评估方式?

→ 三个都答不出来 = 不是新架构, 只是已有模式的变体或重命名。

3.5.2 三条核心设计原则

1. 从终止性开始设计: 先定义"系统在什么条件下停止", 再倒推状态和转移
2. 从失败模式开始选型: 不是"我需要什么能力", 而是"我最不能接受什么失败"
3. 从最简组合开始: 从 ReAct 出发, 只在明确触发信号下叠加新模式

3.5.3 终极三句话

1. 先把状态和控制流画清楚 —— 画出 S 和 δ, 一切架构讨论从此开始
2. 大多数系统从 ReAct 起步, 可靠系统引入验证/记忆/边界控制 —— 不要过早设计
3. 真正高级的 agent 不是更敢做事, 而是更知道什么时候不该做 —— 拒绝 > 幻觉

0x04 17 种架构逐一分析

4.1 Reflection (反思模式)

基础

定义: 一个线性三步流水线，LLM 先生成、再批评、再改进自己的输出，无需外部工具即可提升质量。

核心思想: LLM 做 critic 比做 generator 更稳定。把生成拆成 "创作" 和 "评估" 两个 pass, 比单次尝试效果更好。

核心工作流: ① LLM 生成初始草稿 → ② Critic LLM 审视草稿并输出批评意见 → ③ Refiner LLM 根据批评改进草稿 → ④ 输出最终优化结果。

形式化描述:

S = {s₀} ∪ {(d, c, r) | d ∈ Drafts, c ∈ Critiques, r ∈ Refinements} δ : s₀ → draft → critique → refined → F F = {refined} (单一终止状态) Γ = {critique ≠ ∅, refined ≠ draft}

终止性: 结构性终止 —— 三步走完即终止, 无循环。

示意图

Generator ----> Critic ----> Refiner ----> Final Output (LLM) (LLM) (LLM) draft critique refined

扩展

框架映射:

我们来看看 本模式 如何映射到其它模式上。

核心洞察: LLM 作为critic比作为generator更稳定。把生成和评判分离, 是最小但最有效的质量闭环。

4.2 Tool Use (工具调用模式)

基础

定义: LLM 可以调用外部工具（API、数据库、计算器）来获取训练数据之外的真实世界信息，然后综合结果。

核心思想: 突破不在于 "会函数调用", 而在于文本控制流可以跨越到结构化世界再返回。真正的难点是序列化 / 反序列化，不是 prompting。

核心工作流: ① 用户发起请求 → ② LLM 决定是否需要调用工具及调用哪个 → ③ 执行工具调用并获取结构化结果 → ④ LLM 综合工具返回结果生成最终回答。

形式化描述:

S = H × TC × TR (H=对话历史, TC=tool calls, TR=tool results) δ : (h, ∅, ∅) → (h, tc, ∅) → (h, tc, tr) → F (每次工具调用) F = {s | LLM 输出不含 tool_call} Γ = {∀ tc ∈ TC, tc.tool_name ∈ RegisteredTools}

终止性: 条件终止 —— 需 max_iterations 兜底, 防止 tool-call loop。

示意图

扩展

框架映射:

我们来看看 本模式 如何映射到其它模式上。

核心洞察: Tool Use 首次将文本控制流跨越到结构化世界。tool_call 是 agent 的行动边界第一次突破语言.

4.3 ReAct (推理-行动循环)

基础

定义: 一个迭代循环，LLM 交替进行思考（推理下一步做什么）、行动（调用工具）、观察（处理结果）, 直到任务完成。

核心思想: 从工具结果反馈到 LLM 的那条回边，是整个 agent 架构中最重要的结构元素。这是 80% 任务的合理起点。

核心工作流: ① LLM 推理当前状态并决定下一步行动 → ② 执行工具调用（Action） → ③ 接收工具返回的观测结果（Observation） → ④ 循环回到①直到 LLM 判断任务完成，输出最终答案。

形式化描述:

S = (T × A × O)^k × T (T=Thought, A=Action, O=Observation) δ : (..., t_i) → (..., t_i, a_i) → (..., t_i, a_i, o_i) → (..., t_{i+1}) F = {s | t_k = "Final Answer" ∨ k ≥ max_iterations} Γ = {∀ a_i, a_i ∈ AvailableActions}

终止性: 条件终止 —— 需 max_iterations 兜底 (工程上推荐默认值 20-50)。

示意图

扩展

框架映射:

我们来看看 本模式 如何映射到其它模式上。

核心洞察: ReAct 让 Agent 真正成形。Thought→Action→Observation 是最小但完整的感知-决策-行动闭环, 也是80% 任务的合理起点。

4.4 Planning (规划模式)

基础

定义: LLM 先生成一个显式的分步计划，然后逐步执行每一步，使控制流本身成为一等可检视对象。

核心思想: Planning 新增的不是 "更聪明的思考", 而是让控制流变得可视、可修改、可审计。plan 队列单调递减 — 这是终止性的保证。

核心工作流: ① LLM 生成显式分步计划（plan 队列） → ② 按序取出下一步并执行 → ③ 将中间结果存入状态 → ④ 重复②直到 plan 为空，综合所有结果输出。

形式化描述:

S = (P, i, R) 其中 P = [step₁, step₂, ..., stepₙ] 为计划队列 i 为当前步骤索引, R 为已执行步骤结果 δ : (P, i, R) → execute(stepᵢ) → (P, i+1, R∪{resultᵢ}) ∨ replan → (P', 0, R) (当 resultᵢ 偏离预期) F = {s | i = |P| ∨ |P| = 0} (计划执行完毕) Γ = {|P| 单调递减 (无 replan 时), ∀ step ∈ P, step.is_executable}

终止性: 有界终止 —— 无 replan 时 plan 队列单调递减; 有 replan 时仍需 max_iterations。

示意图

扩展

框架映射: