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 ModeGuard 是闸门, dry_run 是沙盒任务分解与协作Topology (多节点/DAG/Fan-out)协作结构被编码在拓扑里记忆与状态State直接对应可观测性与评估Hooks GuardsHook 埋点做观测, Guard 做评估1.4 产业视角: ETCLSVG 七层分类法来源:Agent Harness Engineering: A Survey(Li et al., 2026)层级英文中文关注点EExecution执行环境沙箱、容器、进程隔离、blast radius 控制TTooling工具集成ACI 标准化、工具注册、schema 管理CContext上下文管理窗口压缩、memory 检索、上下文组装LLifecycle生命周期任务编排、状态转移、终止条件、重试策略OObservability可观测性追踪、日志、指标、归因分析VVerification验证体系Guard、evaluator、输出校验、一致性检查GGovernance治理控制权限、审计、合规、成本控制、人机协作与七核心概念的映射:核心概念对应 ETCLSVG 层StateC (Context)Topology RoutingL (Lifecycle)GuardV (Verification)HookL V (Lifecycle Verification)ModeE (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-ControllerLLM 分类后走固定分支动态循环ReAct, PEVLLM 每步决定继续/停止完全自主Autonomous AgentLLM 控制全部决策, 步骤数不确定设计思考:确定性 vs 灵活性的权衡—越自主越强大, 但越难控制和预测。2.3 维度三: 安全与信任 (Safety Trust)核心问题: 如何确保 Agent 不做错误/危险的事?策略对应模式机制预执行模拟Dry-Run Harness, Mental Loop先模拟后执行, 可回滚人工门控Human-in-the-Loop关键操作前需人类批准自动验证PEV (Plan-Execute-Verify)每步执行后自动校验结果自我认知Reflexive MetacognitiveAgent 知道自己不知道什么, 主动升级并行护栏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 → Improvebad 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 个模式的演化路径与条件如下3.2.2 升级触发条件表这些模型彼此升级之间的关系如下。当前架构触发信号升级方向单次 LLM 调用输出质量不稳定, 需要自查ReflectionReflectioncritique 缺乏外部信息, 需要查资料Tool UseTool Use工具调用间需要推理链条ReActReAct输出重复循环, 缺乏全局视角PlanningReAct需要记住用户偏好和历史 MemoryReAct需要多个专家角色协作Multi-AgentPlanningplan 执行后结果不对但未被发现PEVPEV验证器本身不可靠, 需要冗余EnsembleMulti-Agent角色固定但任务类型多变, 需动态调度BlackboardPEV执行前需要预判, 不能先做了再说Mental LoopMental Loop模拟与现实可能有差异, 需要真实环境Dry-RunDry-Run人工审批成为瓶颈, 需要自主判断MetacognitiveMetacognitive判断能力停滞, 需要从经验学习Self-Improvement3.2.3 成熟度“模型”我们可以将这些模式分为几个等级。等级特征典型架构组合适用场景L1 基础单次 LLM 调用, 无状态, 无工具裸 prompt简单 QA, 文本分类, 摘要L2 交互多轮对话, 有 tool use, 有基本循环ReAct Tool Use客服, 信息检索, 简单自动化L3 可控有规划, 有验证, 有终止保证Planning PEV代码生成, 数据处理 pipelineL4 可靠多 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 不是更敢做事, 而是更知道什么时候不该做 —— 拒绝 幻觉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扩展维度分析1. 要解决什么LLM 输出质量不稳定, 需要自检自修闭环2. StateS {draft, critique, refined}, 三个离散阶段3. 拓扑线性三步链: Generate → Critique → Refine4. Router静态: 始终沿 draft → critique → refined 单向流动5. 失败模式critique 泛泛而谈; refine 不收敛; 无外部信息注入导致自说自话6. 何时升级需要外部工具获取新信息时 → Tool Use; 需要多步交互时 → ReAct框架映射:我们来看看 本模式 如何映射到其它模式上。维度取值Topology线性链Routing静态Guard无 (最小实现)Modelive核心维度State Topology核心洞察: LLM 作为critic比作为generator更稳定。把生成和评判分离, 是最小但最有效的质量闭环。4.2 Tool Use (工具调用模式)基础定义: LLM 可以调用外部工具API、数据库、计算器来获取训练数据之外的真实世界信息然后综合结果。核心思想: 突破不在于 会函数调用, 而在于文本控制流可以跨越到结构化世界再返回。真正的难点是序列化 / 反序列化不是 prompting。核心工作流: ① 用户发起请求 → ② LLM 决定是否需要调用工具及调用哪个 → ③ 执行工具调用并获取结构化结果 → ④ LLM 综合工具返回结果生成最终回答。形式化描述:S H × TC × TR (H对话历史, TCtool calls, TRtool results) δ : (h, ∅, ∅) → (h, tc, ∅) → (h, tc, tr) → F (每次工具调用) F {s | LLM 输出不含 tool_call} Γ {∀ tc ∈ TC, tc.tool_name ∈ RegisteredTools}终止性: 条件终止 —— 需 max_iterations 兜底, 防止 tool-call loop。示意图扩展维度分析1. 要解决什么LLM 知识有截止日期, 无法访问外部系统2. StateS 3. 拓扑LLM ⇄ Tool 双向交互, 可多轮4. RouterLLM 动态决定是否调用工具、调用哪个工具5. 失败模式tool hallucination (调用不存在的工具); 参数错误; tool 返回超长截断6. 何时升级需要在工具调用间加入推理时 → ReAct框架映射:我们来看看 本模式 如何映射到其它模式上。维度取值Topology星形 (LLM 为中心, tool 为叶子)RoutingLLM 动态Guardtool schema 校验Modelive核心维度ACI核心洞察: Tool Use 首次将文本控制流跨越到结构化世界。tool_call 是 agent 的行动边界第一次突破语言.4.3 ReAct (推理-行动循环)基础定义: 一个迭代循环LLM 交替进行思考推理下一步做什么、行动调用工具、观察处理结果, 直到任务完成。核心思想: 从工具结果反馈到 LLM 的那条回边是整个 agent 架构中最重要的结构元素。这是 80% 任务的合理起点。核心工作流: ① LLM 推理当前状态并决定下一步行动 → ② 执行工具调用Action → ③ 接收工具返回的观测结果Observation → ④ 循环回到①直到 LLM 判断任务完成输出最终答案。形式化描述:S (T × A × O)^k × T (TThought, AAction, OObservation) δ : (..., t_i) → (..., t_i, a_i) → (..., t_i, a_i, o_i) → (..., t_{i1}) F {s | t_k Final Answer ∨ k ≥ max_iterations} Γ {∀ a_i, a_i ∈ AvailableActions}终止性: 条件终止 —— 需 max_iterations 兜底 (工程上推荐默认值 20-50)。示意图扩展维度分析1. 要解决什么复杂任务需要推理与行动的交替迭代2. StateS {(thought, action, observation)^k}, k 为已执行轮次3. 拓扑循环: Thought → Action → Observation → Thought → ...4. RouterLLM 在每轮生成 thoughtaction, observation 由环境返回5. 失败模式循环不收敛; action 重复; thought 与 action 脱节6. 何时升级需要提前规划时 → Planning; 需要多角色时 → Multi-Agent框架映射:我们来看看 本模式 如何映射到其它模式上。维度取值Topology循环 (自环)RoutingLLM 动态Guardaction schema 校验Modelive核心维度Topology (首个循环拓扑)核心洞察: 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, i1, 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。示意图扩展维度分析1. 要解决什么复杂多步任务的全局编排, 避免 ReAct 短视2. StateS 3. 拓扑外层循环: Plan → Execute_Step → Update → Plan(replan?)4. RouterLLM 生成 plan 队列, 每步后检查是否需 replan5. 失败模式plan 过于抽象无法执行; plan 偏差累积; 频繁 replan 震荡6. 何时升级需要验证每步结果时 → PEV; 需要多角色协作时 → Multi-Agent框架映射: