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 个维度上做出特定的取舍

Pattern 主要侧重维度 牺牲的维度
Reflection 推理质量 延迟 (多次LLM调用)
Tool Use 推理质量 (知识增强) 成本、复杂性
ReAct 控制流灵活性 可预测性
Planning 任务分解 灵活性 (计划可能过时)
Multi-Agent 任务分解 + 推理质量 协调成本
PEV 安全 + 可观测性 延迟
Dry-Run Harness 安全 速度
Blackboard 任务分解 (灵活协作) 确定性
Episodic + Semantic Memory 记忆 系统复杂性
Tree of Thoughts 推理质量 计算成本
Mental Loop 安全 (预测后果) 延迟
Meta-Controller 控制流 (智能路由) 路由准确性依赖
Ensemble 推理质量 (多视角) 计算成本
RLHF Loop 记忆 (经验学习) 时间成本
Reflexive Metacognitive 安全 (自我认知) 自主性 (会拒绝行动)
Cellular Automata 任务分解 (涌现) 可解释性
1.2 设计变量（公式6维度）
Agent = State × Topology(Routing) × Guards × Σ(Plugins via Hooks) × Tools(ACI) @ Mode
这个公式将 Agent 架构分解为六个正交维度，六个维度的笛卡尔积构成了架构的设计空间:

State 承载系统记忆。
topology + Routing 定义控制流拓扑与转移决策。
Guard 提供安全闸门。
Hook 提供生命周期扩展。
ACI 定义工具接口。
Mode 决定执行模式。
这六个正交维度涉及七个概念，具体如下：

概念 本质 一句话解释
State 系统快照 系统在任意时刻的完整状态, 包括对话历史、中间结果、memory、任务队列等
Topology 连接结构 节点间的静态连接关系: 线性链 / 循环 / 分叉-汇聚 / 树 / 网格
Routing 转移决策 在拓扑上决定下一步去向: 静态路由 / 条件分支 / LLM 动态 / 策略驱动
Guard 验证闸门 转移前的安全检查: 输入校验 / 边守卫 / 执行守卫 / 输出守卫 / 人工确认
Hook 扩展点 生命周期回调: before / after / on_error / on_timeout, 插件化插入横切逻辑
Mode 执行模式 live(真实执行) / dry_run(副作用拦截) / simulate(反事实模拟)
Tool (ACI) 接口协议 Agent-Computer Interface: 系统与外部世界(API/DB/FS/人类)的标准化交互协议
1.3 联系
两套维度的核心区别: 一个是"你要什么"(评估维度), 一个是"你怎么做"(构造维度)。

映射关系如下：

评估维度 (WHAT) 构造维度 (HOW) 关系
推理质量 Topology(Routing) + Mode 拓扑决定推理路径, simulate 模式支撑深度推理
控制流 Topology(Routing) 直接对应
安全与信任 Guards + Mode Guard 是闸门, dry_run 是沙盒
任务分解与协作 Topology (多节点/DAG/Fan-out) 协作结构被编码在拓扑里
记忆与状态 State 直接对应
可观测性与评估 Hooks + Guards Hook 埋点做观测, Guard 做评估
1.4 产业视角: ETCLSVG 七层分类法
来源: Agent Harness Engineering: A Survey (Li et al., 2026)

层级 英文 中文 关注点
E Execution 执行环境 沙箱、容器、进程隔离、blast radius 控制
T Tooling 工具集成 ACI 标准化、工具注册、schema 管理
C Context 上下文管理 窗口压缩、memory 检索、上下文组装
L Lifecycle 生命周期 任务编排、状态转移、终止条件、重试策略
O Observability 可观测性 追踪、日志、指标、归因分析
V Verification 验证体系 Guard、evaluator、输出校验、一致性检查
G Governance 治理控制 权限、审计、合规、成本控制、人机协作
与七核心概念的映射:

核心概念 对应 ETCLSVG 层
State C (Context)
Topology + Routing L (Lifecycle)
Guard V (Verification)
Hook L + V (Lifecycle + Verification)
Mode E (Execution)
Tool (ACI) T (Tooling)
本篇的 17 种模式分析主要覆盖 L (Lifecycle) 和 V (Verification) 两层，E (Execution) 和 G (Governance) 更多的是从实践角度进行补充。

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

2.1 维度一: 推理质量 (Reasoning Quality)
核心问题: 如何让 Agent 输出更准确、更可靠?

策略 对应模式 机制
自我纠正 Reflection, Evaluator-Optimizer 迭代审视 → 改进
多路径探索 Tree of Thoughts 生成多个方案 → 评估 → 选最优
多视角综合 Ensemble, Voting 不同 agent/prompt 独立分析 → 聚合
知识增强 Tool Use, RAG, Graph Memory 外部知识弥补 LLM 知识盲区
设计思考: 单次 LLM 调用的推理有上限, 如何通过 结构化的多步过程 突破这个上限?

2.2 维度二: 控制流 (Control Flow)
核心问题: 谁决定下一步做什么? 如何决定?

策略 对应模式 机制
预定义路径 Prompt Chaining 代码编排, 确定性
条件路由 Routing, Meta-Controller LLM 分类后走固定分支
动态循环 ReAct, PEV LLM 每步决定继续/停止
完全自主 Autonomous Agent LLM 控制全部决策, 步骤数不确定
设计思考: 确定性 vs 灵活性 的权衡—越自主越强大, 但越难控制和预测。

2.3 维度三: 安全与信任 (Safety & Trust)
核心问题: 如何确保 Agent 不做错误/危险的事?

策略 对应模式 机制
预执行模拟 Dry-Run Harness, Mental Loop 先模拟后执行, 可回滚
人工门控 Human-in-the-Loop 关键操作前需人类批准
自动验证 PEV (Plan-Execute-Verify) 每步执行后自动校验结果
自我认知 Reflexive Metacognitive Agent 知道自己不知道什么, 主动升级
并行护栏 Guardrails (Parallelization) 护栏与主逻辑并行运行, 不阻塞
设计思考: Agent 的 能力边界 在哪里? 如何让它在边界内自主、在边界外求助?

2.4 维度四: 任务分解与协作 (Decomposition & Collaboration)
核心问题: 复杂任务如何拆解? 多个执行单元如何协调?

策略 对应模式 机制
静态分解 Planning, Prompt Chaining 预先规划步骤
动态分解 Orchestrator-Workers 运行时根据输入决定子任务
角色专业化 Multi-Agent, Meta-Controller 每个 agent 有专长
共享工作空间 Blackboard 通过共享状态间接协作
并行独立 Parallelization, Ensemble 无依赖的并行执行
设计思考: 分工的粒度和协调成本 的平衡—拆得太细协调开销大, 拆得太粗失去专业性优势。

2.5 维度五: 记忆与状态 (Memory & State)
核心问题: Agent 如何记住过去、利用经验?

策略 对应模式 机制
短期工作记忆 State (TypedDict/Pydantic) 图的状态对象, 单次执行内
情景记忆 Episodic Memory (FAISS) 过去对话的向量检索
语义记忆 Semantic Memory (Neo4j) 结构化知识图谱
涌现记忆 Cellular Automata 局部状态 → 全局模式
设计思考: LLM 无状态, 如何用 外部存储 + 检索机制 赋予它"记忆"和"学习"能力?

2.6 维度六: 可观测性与评估 (Observability & Evaluation)
核心问题: 如何知道 Agent 做得好不好? 如何持续改进?

策略 对应模式/工具 机制
执行追踪 LangSmith, OpenTelemetry 每个节点/工具调用的 trace
离线评测 Datasets + LLM-as-Judge 基准测试、回归检测
在线评测 Online Scoring 生产流量实时打分
中间步骤评估 Trajectory evaluation 不只看最终结果, 看路径质量
反馈闭环 Production → Dataset → Eval → Improve bad case 反哺测试集
设计思考: 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 个模式的演化路径与条件如下：

total

3.2.2 升级触发条件表
这些模型彼此升级之间的关系如下。

当前架构 触发信号 升级方向
单次 LLM 调用 输出质量不稳定, 需要自查 Reflection
Reflection critique 缺乏外部信息, 需要查资料 Tool Use
Tool Use 工具调用间需要推理链条 ReAct
ReAct 输出重复循环, 缺乏全局视角 Planning
ReAct 需要记住用户偏好和历史 + Memory
ReAct 需要多个专家角色协作 Multi-Agent
Planning plan 执行后结果不对但未被发现 PEV
PEV 验证器本身不可靠, 需要冗余 Ensemble
Multi-Agent 角色固定但任务类型多变, 需动态调度 Blackboard
PEV 执行前需要预判, 不能先做了再说 Mental Loop
Mental Loop 模拟与现实可能有差异, 需要真实环境 Dry-Run
Dry-Run 人工审批成为瓶颈, 需要自主判断 Metacognitive
Metacognitive 判断能力停滞, 需要从经验学习 Self-Improvement
3.2.3 成熟度“模型”
我们可以将这些模式分为几个等级。

等级 特征 典型架构组合 适用场景
L1 基础 单次 LLM 调用, 无状态, 无工具 裸 prompt 简单 Q&A, 文本分类, 摘要
L2 交互 多轮对话, 有 tool use, 有基本循环 ReAct + Tool Use 客服, 信息检索, 简单自动化
L3 可控 有规划, 有验证, 有终止保证 Planning + PEV 代码生成, 数据处理 pipeline
L4 可靠 多 agent 协作, 有 memory, 有安全闸门 Multi-Agent + Memory + Dry-Run 生产级自动化, 金融/医疗
L5 自适应 自我评估, 自我改进, 自主边界判断 Metacognitive + Self-Improvement 研究型 agent, 长期自主运行
升级路径: 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 个问题即可完成基本分析:

它要解决什么问题? —— 该模式的原始动机和核心场景
它的 State 是什么? —— 状态空间 S 的结构定义
它的拓扑是什么? —— 节点连接方式
它的 Router 怎么工作? —— δ 转移函数的决策逻辑
它的失败模式是什么? —— 常见退化场景及根因
什么时候该升级到下一种? —— 能力边界与升级触发信号
3.5 速查工具
3.5.1 三问判断法
面对一个新提出的"架构", 问三个问题:

新增了什么 State? —— 有没有引入新的状态字段或状态结构?
新增了什么 Router? —— 有没有引入新的路由决策机制?
新增了什么 Evaluator? —— 有没有引入新的验证或评估方式?
→ 三个都答不出来 = 不是新架构, 只是已有模式的变体或重命名。

3.5.2 三条核心设计原则
从终止性开始设计: 先定义"系统在什么条件下停止", 再倒推状态和转移
从失败模式开始选型: 不是"我需要什么能力", 而是"我最不能接受什么失败"
从最简组合开始: 从 ReAct 出发, 只在明确触发信号下叠加新模式
3.5.3 终极三句话
先把状态和控制流画清楚 —— 画出 S 和 δ, 一切架构讨论从此开始
大多数系统从 ReAct 起步, 可靠系统引入验证/记忆/边界控制 —— 不要过早设计
真正高级的 agent 不是更敢做事, 而是更知道什么时候不该做 —— 拒绝 > 幻觉