Agent 17种架构模式深度评测与对比指南

Agent 17 种架构模式 深度解析与实践思考

Agent 设计模式的讨论在过去两年持续升温。从最简单的“单轮问答”演进到如今能自主规划、调用工具、甚至多智能体协同的系统，这一领域的迭代速度令人惊叹。写文章的节奏甚至赶不上代码仓库的更新频率。因此，这并非一时冲动——如果再不系统梳理这些思考，很可能就被时代抛在身后了。

本文基于 github.com/FareedKhan-… 上的内容进行了总结与拓展分析，涵盖理论框架、统一分析方法、形式化描述、模式组合策略、工程落地实践以及产业应用视角。同时，参考了“从0开发大模型的17种Agent架构演进”系列文章，在此一并致谢。这些文章给了我很大的启发，帮助我构建了更全面的认知体系。

核心概念

要理解 Agent 的设计模式，可以从两个维度切入：一个是评估维度，用于定义设计目标；另一个是构造维度，用于定义设计变量。简言之，前者回答“你想要什么”，后者回答“你打算怎么做”。评估维度决定了优化的目标函数，构造维度定义了可调参数的搜索空间。两者相辅相成——目标指明方向，变量决定实现的可能性。

设计目标：六个核心评估维度

业界普遍认为：所有 Agent 设计模式本质上都是围绕六个核心维度进行设计与权衡的。这些维度就像衡量 Agent 系统的“六边形能力图”，每种模式都在寻找自己在这个六边形上的最优落点。

• 推理质量：如何让 Agent 的输出更准确、更可靠？这是最根本的问题，也是用户可直接感知的部分。
• 控制流：谁来决定下一步做什么？如何决策？这决定了系统的“意志”源自何处。
• 安全与信任：如何确保 Agent 不会做出错误或危险的行为？这是从实验室走向生产环境必须跨越的门槛。
• 任务分解与协作：复杂任务如何拆解？多个执行单元如何协调？这关乎系统的“肌肉”力量。
• 记忆与状态：Agent 如何记住过去、利用经验？这是让系统从“无状态”走向“有记忆”的关键。
• 可观测性与评估：如何知道 Agent 做得好不好？如何持续改进？这决定了系统的长期生命力。

可以说，本文接下来讨论的每一个设计模式，本质上都是在这六个维度上做出特定的取舍。不存在完美模式，只有最适合当前场景的权衡。

设计变量：六个构造维度

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

该公式将 Agent 架构分解为六个正交的构造维度，它们的笛卡尔积构成了架构的设计空间。这意味着任何一个 Agent 系统都可以用这六个变量来描述其设计决策。

• State：系统快照，承载系统记忆。包括对话历史、中间结果、任务队列等。
• Topology + Routing：拓扑定义连接结构（如线性链、循环、树），路由定义转移决策（如静态、条件分支、LLM动态）。
• Guard：安全闸门，提供转移前的安全检查，如输入校验、执行守卫、人工确认。
• Hook：扩展点，提供生命周期回调，用于插入横切逻辑。
• ACI (Tool)：接口协议，定义Agent与外部世界交互的标准方式。
• Mode：执行模式，包括live（真实执行）、dry_run（副作用拦截）、simulate（反事实模拟）。

将 Topology 和 Routing 分开看，这七个概念共同构成了一个模块化的描述框架，帮助我们精确地拆解和对比不同的 Agent 模式。

两套维度的联系

两套维度的核心区别在于：一个是“你要什么”（评估维度），一个是“你怎么做”（构造维度）。评估维度定义了系统期望达到的效果，而构造维度提供了实现这些效果的具体手段。

产业视角：ETCLSVG 七层分类法

若着眼于产业落地，可以用一个更贴近实践的七层模型来审视 Agent 系统：ETCLSVG。该分类法有助于理解某个模式或组件的“物理位置”，而不仅仅是抽象概念。

将前文提到的七个核心概念映射到这个产业模型上，脉络会更清晰：

可以说，本篇对17种模式的分析，主要覆盖了L (Lifecycle) 和 V (Verification) 这两层。至于 E (Execution) 和 G (Governance)，更多是工程实践中需要额外关注的补充部分。

评估维度

接下来，我们具体看看这六个评估维度的内涵，以及不同策略如何对应各种模式。这些策略和模式远不止本篇讨论的17种，但可以提供一个清晰的认知框架。

维度一：推理质量

核心思考点在于：单一模型的一次调用，推理能力终究有天花板。如何通过结构化的多步过程来突破这个上限，是提升推理质量的关键。

维度二：控制流

这本质上是一个确定性与灵活性的权衡问题。系统越是自主，能力边界就越广阔，但同时也意味着控制难度和不可预测性的增加。

维度三：安全与信任

这里最核心的问题是：Agent 的能力边界在哪里？一个理想的系统，应能在其能力边界内自主运作，而在能力不及或风险过高时，知道如何求助或放弃。

维度四：任务分解与协作

这个维度的核心在于平衡分工的粒度与协调成本。拆得太细，协调开销会指数级增长；拆得太粗，又可能会失去专业化分工带来的优势。

维度五：记忆与状态

LLM 本身是无状态的。如何通过外部存储 + 检索机制的组合，来赋予系统“记忆”和“学习”的能力，是构建更高级 Agent 的关键。

维度六：可观测性与评估

Agent 的行为往往是非确定性的，传统的“对/错”二元测试体系难以胜任。我们需要建立一套概率性的、多维度的评估体系，才能有效理解和改进系统行为。

17种架构总述

统一形式化框架

为了方便后续对17种架构进行严谨的分析，我们先定义一个统一的形式化框架。简单来说，就是把一个 Agent 系统抽象成一个六元组：

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 必须满足 Γ 中的所有约束)

演化路径与升级触发条件

这17种模式并非凭空存在，它们之间存在着清晰的演化路径和触发条件。就像一个生态图谱，每种模式都在特定条件下由另一种模式进化而来。

演化图

升级触发条件表

成熟度分级模型

根据系统的复杂度和成熟度，这些模式大致可以分为五个等级：

升级路径基本上是 L1 → L2 → L3 → L4 → L5。这里有一个很重要的原则：不要跳级。

• 在没有掌握 Tool Use (L2) 之前，不要急着上 Multi-Agent (L4)——连单个Agent加工具的能力边界都没摸清，谈何分工协作？
• 在不具备 PEV (L3) 这样的验证能力时，不要引入 Dry-Run (L4)——连哪些步骤需要验证都没概念，引入人工闸门也只会变成瓶颈。
• 在没有 Memory (L4) 基础设施时，不要尝试 Self-Improvement (L5)——没有持久化的经验积累，自我改进就是空中楼阁。

跨层张力问题

在实际构建系统时，会面临几个普遍存在的张力问题：

1. Cost-Quality-Speed 三难困境。更多验证带来更高质量，但代价是更高的成本和延迟。应对策略是采用分层验证：关键步骤深度验证，常规步骤采样验证，低风险步骤直接跳过。

2. Capability-Control 权衡。Agent 能力越强（更多工具、更自主），就越难控制（潜在的爆炸半径越大）。一个基本的原则是：Guard 应该随 Capability 同步升级。每新增一个工具，至少增加一个对应的 Guard。

3. Harness 耦合问题。Agent 代码与下游 LLM 模型能力存在强耦合。模型版本升级，可能导致之前精心设计的 prompt、验证逻辑甚至超参全部失效。解决思路是将 LLM 依赖隔离在可替换的“reasoning layer”中，保持 Harness 逻辑的模型无关性。

4. 自适应简化。随着模型能力水涨船高，很多为弥补早期模型缺陷而设计的 wrapper（比如手工验证规则）可能会变成不必要的瓶颈。持续评估每个组件的边际贡献是有必要的——当 LLM 在某个任务上的通过率超过99%时，或许就可以考虑将验证方式降级为采样验证了。

统一分析法：拆解任意架构的六个问题

面对任何一个声称的“新架构”，只需要回答以下六个问题，就能快速完成基本分析，避免被各种炫酷的概念所迷惑：

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

速查工具

三问判断法

面对一个新的模式，可以快速问三个问题来判断其独特性：

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

如果三个问题都答不上来，那大概率不是新架构，只是已有模式的变体或重新包装。

三条核心设计原则

1. 从终止性开始设计：先定义“系统在什么条件下停止”，再倒推状态和转移。
2. 从失败模式开始选型：不要问“我需要什么能力”，而要考虑“我最不能接受什么失败”。
3. 从最简组合开始：从ReAct出发，只有在出现明确的触发信号时，再叠加新的模式。

终极三句话

1. 先把状态和控制流画清楚 —— 画出S和δ，一切架构讨论都在这个基础上展开。
2. 大多数系统从ReAct起步，可靠系统引入验证/记忆/边界控制 —— 不要过早地过度设计。
3. 真正高级的Agent不是更敢做事，而是更知道什么时候不该做 —— 懂得拒绝，比产生幻觉要好得多。

17种架构逐一分析

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

扩展分析

框架映射：

2. Tool Use (工具调用模式)

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

核心思想：真正的突破不在于 LLM “会函数调用”，而在于文本控制流可以跨越到结构化世界再返回。真正的难点在于序列化和反序列化，而非 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。

示意图

扩展分析

框架映射：

3. ReAct (推理-行动循环)

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

核心思想：从工具结果反馈到 LLM 的那条“回边”，是整个 Agent 架构中最重要的结构元素。对于80%的任务来说，ReAct 都是一个合理的起点。

核心工作流：① 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 ∈ A vailableActions}

终止性：条件终止——需 max_iterations 兜底（工程上推荐默认值20-50）。

示意图

扩展分析

框架映射：

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 兜底。

示意图

扩展分析

框架映射：

5. PEV (计划-执行-验证)

定义：在 Planning 基础上增加验证步骤。每次执行后验证结果，失败则重试或重新规划，确保错误不会静默传播。

核心思想：执行不再是“完成了一步”，而是“产生了一个待验证的结果”。验证让失败变得显式，而非被默认传播下去。

核心工作流：① 生成执行计划 → ② 执行当前步骤 → ③ 验证执行结果（通过则进入下一步，失败则重试或重新规划） → ④ 全部步骤通过验证后，综合输出最终结果。

形式化描述：

S  = (P, i, R, V)  其中 V = {pass, fail, uncertain}
δ  : (P, i, R, ∅) → execute → (P, i, R∪{r}, ∅) → verify → (P, i, R, v)
     → (v=pass ? (P, i+1, R, ∅) : (P, i, R, ∅))  -- 重试或 replan
F  = {s | i = |P| ∧ ∀ v_j ∈ V_history, v_j = pass}
Γ  = {verifier ∉ executor (独立性要求), ∀ step, step.verified_before_proceed}

终止性：条件终止——需要 max_retries + max_iterations 双重兜底。

示意图

扩展分析

框架映射：

6. Multi-Agent (多智能体协作)

定义：多个具有不同角色（人设/工具）的 LLM Agent 按固定流水线排列，每个处理自己的领域后将结果传给综合器。

核心思想：将单个 prompt 中的隐式角色切换，变成多个显式的独立节点。工程上的收益是巨大的：每个 Agent 可以单独调试、替换、评估，并赋予不同的工具集。

核心工作流：① 任务分解为子领域 → ② 角色分配（给各专家 Agent） → ③ 按流水线协作（前一个的输出是后一个的输入） → ④ 由 Synthesize Agent 汇总所有角色产出，生成最终结果。

形式化描述：

S  = (Agent₁.output, Agent₂.output, ..., Agentₙ.output) × SharedContext
δ  : (∅, ∅, ..., ∅, ctx) → (a₁_out, ∅, ..., ∅, ctx) → (a₁_out, a₂_out, ..., ∅, ctx)
     → ... → (a₁_out, ..., aₙ_out, ctx) → F
F  = {s | ∀ i ∈ [1, n], Agentᵢ.output ≠ ∅}
Γ  = {∀ i, Agentᵢ.output.schema ∈ expected_input_schema(Agentᵢ₊₁)}

终止性：结构性终止——固定流水线走完即终止。

示意图

Agent A ----> Agent B ----> Agent C ----> Synthesizer ----> Output
(Finance)    (Tech)        (Legal)       (aggregate)

扩展分析

框架映射：

7. Blackboard (黑板架构)

定义：共享工作区（黑板）是系统中心。Controller LLM 读取黑板状态，动态选择下一个要调用的 specialist agent。

核心思想：控制逻辑从“预定义工作流”转向“共享状态 + 调度器”。黑板不断积累知识，controller 根据已有内容决定还需要什么。

核心工作流：① Controller 读取黑板当前状态 → ② 动态选择最合适的 Specialist Agent → ③ Specialist 执行任务并将结果写回黑板 → ④ 循环回到①直到 Controller 判断信息充分，输出 FINISH。

形式化描述：

S  = (BB, H)  其中 BB 为黑板字典，H 为调度历史
δ  : (BBₜ, H) → Controller.select(BBₜ) → specialistᵢ(BBₜ) → (BBₜ₊₁, H∪{i})
     ∨ (BBₜ satisfies goal) → F
F  = {s | goal_condition(BB) = true ∨ |H| ≥ max_steps}
Γ  = {∀ write to BB, write.key ∈ RegisteredKeys, BB 始终为合法状态}

终止性：条件终止——需 goal_condition 或 max_steps 兜底。

示意图

扩展分析

框架映射：

8. Meta-Controller (元控制器)

定义：一个一次性路由器，将传入请求分类后派发给对应的 specialist agent。路由器本身不执行任何任务。

核心思想：它更像一个“分诊台”，而非一个“总控台”。由于其简单性和可预测性，这是生产多 Agent 系统最常见的起步架构。

核心工作流：① 接收用户请求 → ② Meta-Controller 对请求进行一次性分类 → ③ 路由到对应领域的 Expert Agent 执行 → ④ Expert 完成任务后直接输出结果。

形式化描述：

S  = (q, c, r)  其中 c ∈ Categories, r ∈ Results
δ  : (q, ∅, ∅) → classify → (q, c, ∅) → route(c) → specialist_c(q) → (q, c, r) → F
F  = {s | r ≠ ∅}
Γ  = {c ∈ KnownCategories, route(c) ∈ Registered Specialists, specialist_c 匹配 c}

终止性：结构性终止——两步固定流程。

示意图

扩展分析

框架映射：

9. Ensemble (集成模式)

定义：多个 agent 独立并行处理相同输入，然后由聚合器将多元视角合并为最终建议。

核心思想：真正的价值不在于取平均，而在于保留冲突。冗余降低了单个模型的偏差，好的聚合器必须暴露分歧，而非简单掩盖它。

核心工作流：① 将同一输入分发（Fan-out）给多个独立 Agent → ② 各 Agent 并行处理，产出独立见解 → ③ Aggregator 收集所有见解并识别分歧 → ④ 综合多元视角输出最终建议（保留冲突信息）。

形式化描述：

S  = (q, O, A)  其中 O = [o₁, o₂, ..., oₙ], n ≥ 2, A 为聚合结果
δ  : (q, ∅, ∅) → fan_out → (q, ∅, ∅) → ∥ᵢ modelᵢ(q) → (q, O, ∅) → aggregate → (q, O, A) → F
F  = {s | A ≠ ∅}
Γ  = {n ≥ 2, ∀ i ≠ j, modelᵢ ≠ modelⱼ ∨ promptᵢ ≠ promptⱼ, 冲突必须保留在 O 中}

终止性：结构性终止——Fan-out → Parallel → Fan-in 一步完成。

示意图

扩展分析

框架映射：

10. Episodic & Semantic Memory (记忆模式)

定义：在基础 Agent（通常是 ReAct）上扩展持久外部记忆——情景记忆（事件历史存为向量）和语义记忆（结构化事实），支持跨会话学习。

核心思想：记忆让系统更强大，但也让错误变得持久。关键的设计决策是：何时检索、何时写入、如何防止记忆污染。

核心工作流：① Agent 推理前先从记忆库检索相关历史（Recall） → ② 结合当前上下文和历史记忆进行推理 → ③ 执行行动并获取结果 → ④ 对话结束后提取新知识写入记忆库（情景事件→向量库，结构化事实→知识库）。

形式化描述：

S  = S_core × M_e × M_s   (核心状态 × 情节记忆 × 语义记忆)
δ  : (s, M_e, M_s) → retrieve(q, M_e, M_s) → inject(s, memories) → act(s') → store(outcome, M_e, M_s)
F  = S_core 的终止条件 (继承自主架构)
Γ  = {store 仅在 outcome.verified = true 时触发, |M_e| ≤ max_episodes, |M_s| ≤ max_entries}

终止性：继承自主架构（通常是条件终止）。

示意图

扩展分析

框架映射：

11. Graph Memory (图记忆模式)

定义：使用知识图谱（实体 + 关系）作为记忆基底，通过 Text-to-Cypher 实现向量检索无法处理的多跳关系查询。

核心思想：关键不只是 LLM 的智能，而是整个知识建模链条：抽取→存储→查询→综合。图结构支持关于关系的结构化推理。

核心工作流：① 从原始文本中抽取实体和关系三元组 → ② 存入图数据库构建知识图谱 → ③ 将自然语言查询转为 Cypher 并在图上执行 → ④ LLM 综合查询结果生成最终答案。

形式化描述：

S  = (q, cypher, graph_result, context, response)
δ  : (q, ∅, ∅, ∅, ∅) → text2cypher → (q, c, ∅, ∅, ∅) → query → (q, c, R, ∅, ∅)
     → augment → (q, c, R, ctx, ∅) → generate → (q, c, R, ctx, resp) → F
F  = {s | resp ≠ ∅}
Γ  = {cypher 语法合法, R ⊆ GraphDB, ctx = q + format(R)}

终止性：结构性终止——固定流水线。

示意图

扩展分析

框架映射：

12. Tree-of-Thoughts (思维树)

定义：将线性推理变为树搜索——展开多条候选思维路径，评估打分，剪枝无效分支，使用程序化搜索控制（BFS/DFS）。

核心思想：永远不要把搜索控制交给 LLM，交给代码。LLM 的职责只是生成候选和打分。代码管理分支、回溯和终止。

核心工作流：① 代码控制展开多条候选思维路径 → ② LLM 对每条路径打分评估 → ③ 代码根据分数剪枝无效分支 → ④ 继续向下展开有效分支，直到找到目标或达到最大深度。

形式化描述：

S  = (T, frontier, budget)  T 为思维树，frontier 为待展开节点队列，budget 为剩余搜索预算
δ  : select(frontier) → expand(LLM) → evaluate(LLM) → prune → update(frontier)
F  = {s | budget = 0 ∨ ∃ n ∈ T.lea ves, score(n) ≥ threshold}
Γ  = {budget 单调递减，每轮至少剪除 |frontier|×p 的候选}

终止性：有界终止——budget 单调递减。

示意图

扩展分析

框架映射：

13. Mental Loop / Simulator (心智模拟)

定义：在执行真实动作前，系统 fork 一个模拟环境，推演动作后果，评估结果，仅在超过基线时才真正执行。

核心思想：架构的上限不是 LLM，而是模拟器的保真度。核心安全不变量：模拟绝对不能修改真实环境。

核心工作流：① Agent 提出待执行动作 → ② Fork 当前环境创建模拟副本 → ③ 在模拟环境中推演动作后果并与基线对比评估 → ④ 评估通过则在真实环境执行，否则放弃该动作。

形式化描述：

S  = (scenario, rollouts: List[Rollout], best_action)
δ  : (s, ∅, ∅) → fork(s, k) → ∥ᵢ rollout(s, kᵢ) → evaluate_all → select_best → execute(real)
F  = {s | real_execution_complete}
Γ  = {simulate(·) 不修改 real_env (核心不变量), k ≥ 2, ∀ rollout, rollout.trajectory ∈ FeasiblePaths}

终止性：有界终止——fork 数 k 固定，rollout 深度有界。

示意图

扩展分析

框架映射：

14. Dry-Run Harness (预演执行)

定义：任何有副作用的动作必须先在 dry-run 模式执行（生成预览），经人工明确批准后才进行真实执行。

核心思想：不是让 Agent 更保守，而是让“是否允许执行”成为一个显式的控制流决策。preview 和 execute 必须共享同一代码路径，以保证保真性。

核心工作流：① Agent 提出有副作用的动作 → ② 以 dry_run=true 模式执行生成预览（零副作用） → ③ 将预览呈现给人工审批 → ④ 批准则以 dry_run=false 真实执行，拒绝则中止。

形式化描述：

S  = (a, preview(a), decision)   decision ∈ {approved, rejected, modified}
δ  : (a, ∅, ∅) → dry_run(a) → (a, preview, ∅) → await_human → (a, preview, d)
     → (d=approved ? execute(a) : abort) → F
F  = {s | decision ≠ ∅}  (无论 approve/reject，决策即终止)
Γ  = {dry_run(·) 与 execute(·) 共用同一代码路径，preview 必须完整展示副作用}

终止性：外部终止——依赖于人工决策。

示意图

扩展分析

框架映射：

15. Reflexive Metacognitive (自反元认知)

定义：在尝试任务前，Agent 基于自我模型（已知领域、工具、置信度阈值）评估自身能力，然后路由到合适策略。

核心思想：Agent 最强的能力不是“回答”，而是“拒绝”。知道自己不知道什么，才能避免输出自信但错误的答案。

核心工作流：① 接收任务后基于 self_model 进行自我评估（置信度 + 风险等级） → ② 根据评估结果选择策略 → ③ 高置信低风险：直接推理回答；需外部信息：调用工具；低置信或高风险：升级给人类 → ④ 输出结果或升级通知。

形式化描述：

S  = S_core × SM × CF × ST   (核心状态 × 自我模型 × 置信度 × 策略)
δ  : (s, sm, ∅, st) → assess(s, sm) → (s, sm, cf, st)
     → (cf ≥ θ_st ? act(s, st) : escalate/refuse) → ...
F  = {s | task_complete ∨ decision = "refuse"}
Γ  = {cf ∈ [0,1], sm 随经验更新, escalate 优先于 hallucinate, "拒绝"是合法动作}

终止性：结构性终止（带拒绝分支）。

示意图

扩展分析

框架映射：

16. Self-Improvement Loop (自改进循环)

定义：一个迭代精炼循环，输出经过多轮生成、批评和改进。高质量输出被存入 gold 标准库供未来参考。

核心思想：两层进化——任务内迭代（生成→批评→改进）和跨任务积累（gold 库持续增长）。gold 库只接受通过 critic 的样本。

核心工作流：① Generator 参考 gold 库中的高质量样例生成输出 → ② Critic 评估输出质量 → ③ 未通过则修订后重新提交（循环直到通过或达上限） → ④ 通过审批的输出存入 gold 库，供后续任务参考。

形式化描述：

S  = (task_state, gold_set, failure_patterns)
δ  : 内层: 正常执行 task → 成功: extract → gold_set ∪ {new_gold}
                 → 失败: analyze → failure_patterns ∪ {new_pattern}
     外层: gold_set 达到阈值 → consolidate → 更新 system_prompt / few_shot
F  = 无全局终止 (持续运行系统)
Γ  = {gold 添加需 verification, failure_pattern 添加需 ≥2 次复现, gold 不互相矛盾}

终止性：有界终止（内层）/ 无全局终止（持续系统）。

示意图

扩展分析

框架映射：

17. Cellular Automata (元胞自动机)

定义：一个由 cell 组成的网格，每个 cell 是独立的 LLM 驱动 agent，仅通过局部更新规则与邻居交互。全局行为从局部交互中涌现。

核心思想：LLM 完全退出主执行循环——它只负责设计局部更新规则。真正的求解通过大规模并行局部演化完成。不存在中央控制器。

核心工作流：① 初始化网格，每个 cell 赋予初始状态 → ② 每个 cell 读取邻居状态 → ③ 根据局部更新规则计算自己的下一状态（全部 cell 同步更新） → ④ 重复②直到网格收敛或达到最大步数。

形式化描述：

S  = Grid[N][M] 其中 Grid[i][j] ∈ CellStates
δ  : ∀ cell(i,j): new_state = Rule(neighbors(i,j), self)  (同步或异步更新)
     LLM 的职责: 设计 Rule, 而非控制 cell
F  = {s | global_stability(s) ∨ step ≥ max_steps}
Γ  = {Rule 在更新中不变 (由 LLM 设计一次), local-only: cell 仅访问 Moore/Von Neumann 邻