AI代理设计模式的二维框架：认知功能与执行拓扑

# AI Agent设计模式的二维框架：认知功能 × 执行拓扑
来源: https://arxiv.org/html/2605.13850
Jia Huang¹ Joey Tianyi Zhou¹,² ¹新加坡科技研究局 (A*STAR) ²A*STAR前沿人工智能研究中心 (CFAR) [email protected] [email protected]

（2026年3月）

###### 摘要

现有的基于LLM的智能体架构框架仅从单一角度描述系统：行业指南（Anthropic、Google、LangChain）侧重于*执行拓扑*——数据如何流动；而认知科学综述侧重于*认知功能*——智能体做什么。仅凭任一轴都无法区分架构上不同的系统：相同的编排器-工作者拓扑可以实现“计划与执行”、“层次委派”或“对抗性验证”——这三种模式具有根本不同的故障模式和设计权衡。

我们提出一个二维分类法，结合了（1）**认知功能轴**，包含七个类别（上下文工程、记忆、推理、行动、反思、协作、治理）和（2）**执行拓扑轴**，包含六种结构原型（链式、路由、并行、编排、循环、层次）。由此产生的7×6矩阵识别出27种命名模式，其中13种为原创命名。我们通过系统性的跨轴分析证明了正交性，详细定义了八种代表性模式，并在四个真实世界领域（金融借贷、法律尽职调查、网络运维、医疗分诊）验证了描述覆盖范围。跨领域分析得出了五种关于模式选择的经验法则，这些法则支配着环境约束（时间压力、行动权限、失败成本不对称性、数据量）与架构选择之间的关系。该框架为AI智能体架构设计提供了一套原则性、框架中立且模型无关的词汇表。

关键词: AI智能体、设计模式、分类法、认知功能、执行拓扑、软件架构、多智能体系统

## 1 引言

基于LLM的智能体系统的快速部署产生了一个支离破碎的架构指导格局。每个主要的人工智能组织都发布了其理解智能体架构的框架：

- •Anthropic 的“构建有效智能体”[1](https://arxiv.org/html/2605.13850#bib.bib1) 识别了六种执行拓扑（提示链式、路由、并行化、编排器-工作者、评估器-优化器、自主智能体）。
- •Google 的智能体开发套件[2](https://arxiv.org/html/2605.13850#bib.bib2) 描述了围绕顺序、并行和循环结构组织的八种工作流模式。
- •LangChain 的多智能体指南[3](https://arxiv.org/html/2605.13850#bib.bib3) 提出了四种协调模式（监督者、层次、网络、移交）。
- •吴恩达的智能体设计模式[4](https://arxiv.org/html/2605.13850#bib.bib4) 识别了四种认知能力（反思、工具使用、规划、多智能体协作）。

关键观察：**所有现有框架仅从*一个轴*描述智能体架构**。行业来源侧重于执行拓扑——*如何*流动数据。认知综述[5](https://arxiv.org/html/2605.13850#bib.bib5),[6](https://arxiv.org/html/2605.13850#bib.bib6),[7](https://arxiv.org/html/2605.13850#bib.bib7) 侧重于功能能力——*智能体做什么*。单独任何一个轴都难以区分架构上不同的系统。

考虑编排器-工作者拓扑。相同的结构化接线图至少服务于三种根本不同的模式：

1. 1.**计划与执行**（行动）：规划器将任务分解为子任务并将其分派给执行智能体。
2. 2.**层次委派**（协作）：管理者从特定领域的子智能体获取专门知识。
3. 3.**可观测性管理**（治理）：中央监控器编排跨智能体模块的日志记录、追踪和告警。

这些是架构上不同的系统，具有不同的故障模式、不同的扩展属性和不同的测试策略——然而它们共享一个拓扑。没有认知功能轴，它们无法区分。类似地，单一的认知功能可以通过多种拓扑实现：推理（C3）可以实现为思维链（链式）、基于复杂度的路由（路由）、并行探索（并行）或迭代假设检验（循环）。拓扑的选择决定了延迟、成本和故障特性。

本文做出四项贡献：

1. 1.**一个二维分类框架**，将认知功能与执行拓扑结合成一个坐标系（第2节）。
2. 2.**详细定义**八种代表性模式——每个认知功能一个加上一个治理模式——足以独立理解（第3节）。
3. 3.**系统性的正交性论证**，证明两个轴不能相互归约（第4节）。
4. 4.**跨四个真实世界领域的覆盖评估**，验证了框架的描述能力并得出五种模式选择的经验法则（第6节）。

## 2 二维框架

### 2.1 设计原则

我们的框架遵循三个原则：

**正交性。** 两个轴必须能够独立变化。认知功能的改变不应要求执行拓扑的改变，反之亦然。

**完备性。** 这些轴应涵盖生产级智能体系统所需的所有能力，以及足以组合任何智能体工作流的所有结构原型。

**持久性。** 类别描述的是*结构性需求*和*结构性形式*，这些形式跨越框架和模型的变化而持续存在。“上下文工程”无论上下文窗口是4K还是2M token都仍然相关；“循环”无论循环体是GPT-4调用还是Claude调用都仍然相关。

### 2.2 轴1：认知功能（做什么）

我们识别了七个认知功能类别。这些类别基于语言智能体的认知科学文献[7](https://arxiv.org/html/2605.13850#bib.bib7)，并扩展了两个类别（治理、上下文工程），这些类别源于生产部署分析：

**表1：七个认知功能类别。** 这七个类别形成了一个认知处理流水线：智能体感知输入（C1），检索相关知识（C2），推理该做什么（C3），执行行动（C4），评估其输出（C5），必要时与其他智能体协调（C6），并始终在治理约束下运作（C7）。这个流水线并非严格顺序——智能体反复循环通过感知-推理-行动循环——但类别在功能上是不同的。

### 2.3 轴2：执行拓扑（如何做）

我们识别了六种执行拓扑原型。这些原型包含了现有行业框架[1](https://arxiv.org/html/2605.13850#bib.bib1),[2](https://arxiv.org/html/2605.13850#bib.bib2) 中描述的拓扑：

**表2：六种执行拓扑原型。**

### 2.4 7×6模式矩阵

笛卡尔积产生一个7×6=42个单元格的矩阵。我们识别出占据这些单元格的27种命名模式；其余15个单元格要么结构冗余，要么在实践中尚未观察到。表3显示了完整的矩阵。标有★的单元格携带了本工作中首创的原创名称。

**表3：7×6模式矩阵。27种命名模式；★ = 本工作中首创的原创名称。**

## 3 代表性模式定义

我们详细定义了八种代表性模式——每个认知功能行至少一种——以便独立理解。每种定义遵循以下格式：*坐标、问题、架构解决方案和工程权衡*。其余19种模式遵循相同的模板。

### 3.1 上下文分诊（C1×T2：上下文工程×路由）

**问题。** 一个智能体在任务开始时可以访问许多信息来源：用户消息、对话历史、项目文件、文档、工具输出、检索到的知识和环境元数据。上下文窗口无法容纳所有内容。朴素方法——先进先出，满时截断——失败，因为相关性与新旧程度并不相关。

**解决方案。** 上下文分诊将急诊分诊逻辑应用于信息选择。每个信息来源按优先级（P0-P3）分类，路由函数将每个来源分派到适当的处理：P0（始终加载），P1（相关时加载），P2（按需加载），P3（从不加载）。路由函数根据当前任务描述、token预算约束和缓存友好性评估来源相关性。Claude Code的五级CLAUDE.md层次结构（企业→用户→项目→规则→本地）是该模式的一个生产实现。

**权衡。** 更高的分诊准确性减少了上下文噪声，但增加了路由延迟。过度激进的过滤可能使智能体丧失关键信息；过滤不足会稀释注意力质量[12](https://arxiv.org/html/2605.13850#bib.bib12)。

### 3.2 RAG流水线（C2×T1：记忆×链式）

**问题。** 智能体需要超出其上下文窗口或训练数据范围的知识。这些知识可能是领域特定的、频繁更新的或专有的。

**解决方案。** 检索增强生成[13](https://arxiv.org/html/2605.13850#bib.bib13)实现了“开卷考试”：查询→检索→重排序→生成。链式拓扑确保每一步的输出馈入下一步。检索步骤将智能体的信息需求转换为针对外部知识存储的向量查询；重排序步骤按相关性过滤和排序结果；生成步骤基于检索到的证据综合答案。MemGPT[14](https://arxiv.org/html/2605.13850#bib.bib14)通过虚拟上下文管理扩展了这一点——使用操作系统启发的内存管理在上下文窗口和外部存储之间分页数据。

**权衡。** 每个检索的块消耗token预算。以每块500个token检索10个块，成本为5,000个token，这些token不能用于推理。架构师必须在召回率（更多块，更多证据）和精确率（更少块，每个块更多注意力）之间取得平衡。

### 3.3 基于复杂度的路由（C3×T2：推理×路由）

**问题。** 智能体工作负载包含难度差异很大的查询。将具有64K思考token的深度思维链推理应用于“你们的营业时间是什么？”会浪费计算资源；而将快速启发式方法应用于多步骤诊断任务则会产生错误。

**解决方案。** 一个轻量级分类器评估每个传入查询，并将其路由到适当的推理深度：系统1（直接响应，约500个token）用于简单查询，系统2（思维链，约8K token）用于中等查询，以及扩展审议（约64K token）用于复杂查询。这模仿了卡尼曼的双过程理论[15](https://arxiv.org/html/2605.13850#bib.bib15)：架构在思考之前决定*思考到多深*。RouteLLM[16](https://arxiv.org/html/2605.13850#bib.bib16)通过在不同强度的模型之间路由，展示了85%的成本降低，同时质量损失极小。

**权衡。** 分类器准确性决定了系统性能。将复杂查询误路由到系统1会产生错误；将简单查询误路由到系统2会浪费token。每天10万次查询，每次查询0.0015美元和0.19美元之间的差异是每天18,850美元。

### 3.4 计划与执行（C4×T4：行动×编排）

**问题。** 一个复杂任务需要多次工具调用，其执行顺序取决于中间结果。单步方法无法分解任务；纯顺序链过于死板，无法处理动态依赖关系。

**解决方案。** 将策略与战术分离：一个*规划器*智能体将任务分解为子任务的有向无环图（DAG），一个*执行器*智能体（或执行器池）执行每个子任务。规划器可以使用更便宜的模型；执行器使用特定领域提示处理工具调用。这是来自分布式系统的Saga模式[17](https://arxiv.org/html/2605.13850#bib.bib17)为智能体工作流所做的适配：每个子任务是一个可补偿动作，规划器管理整个事务。

**权衡。** 计划质量决定执行效率。过度分解会产生不必要的协调开销；分解不足会创建对执行器来说过于复杂的子任务。这种分离还会引入延迟——对于简单任务，先计划再执行比立即执行慢。

### 3.5 生成器-评论家（C5×T5：反思×循环）

**问题。** 智能体的初稿输出功能尚可但不够完美。智能体需要在交付前通过结构化批评来改进此输出。

**解决方案。** 将生成与评估分离并迭代：生成→批评→修订→批评→...→接受。关键的设计选择是*反馈来源*。Huang等人[18](https://arxiv.org/html/2605.13850#bib.bib18)（ICLR 2024）证明，没有外部反馈，LLM无法可靠地自我纠正。三种变体解决了这个问题：（1）使用不同提示进行生成和评估的自我批评，（2）跨模型批评，由单独的模型进行评估，以及（3）工具锚定批评，由测试套件、代码检查器或计算器提供确定性反馈。CRITIC[19](https://arxiv.org/html/2605.13850#bib.bib19)表明，工具交互式批评始终优于纯自我批评。Self-Refine[20](https://arxiv.org/html/2605.13850#bib.bib20)通过2-4次迭代在七个任务上展示了约20%的绝对改进。

**权衡。** 每次迭代消耗token。收敛需要一个停止标准——质量阈值或迭代预算——以防止过度编辑或振荡。

### 3.6 扇出/汇聚（C6×T3：协作×并行）

**问题。** 一个任务可以分解为可以同时处理的独立子任务。单个智能体顺序处理它们将花费n倍的时间。

**解决方案。** 一个协调器将子任务扇出到n个工作智能体并行运行，然后汇聚并聚合它们的结果。每个工作智能体在包含其仅子任务的隔离上下文窗口中运行。协调器处理结果综合、冲突解决和质量评估。Du等人[21](https://arxiv.org/html/2605.13850#bib.bib21)表明，多个LLM实例之间的多智能体辩论提高了事实性和推理能力，在算术和策略推理基准上，基于共识的聚合优于单智能体基线。然而，在没有结构化辩论协议的情况下进行朴素聚合，当智能体产生冲突输出时可能会放大错误。

**权衡。** n个工作智能体消耗n倍token。聚合步骤是质量瓶颈——简单拼接工作智能体输出会产生不连贯的结果。工作智能体的独立性必须是真正的；相互依赖的子任务会强制顺序执行，而与拓扑无关。

### 3.7 审批门（C7×T2：治理×路由）

**问题。** 一个在现实世界行动的智能体面临两难：过多的审批提示会导致“审批疲劳”（用户习惯性地点击批准），而过少则可能导致不可逆转的损害。

**解决方案。** 将每个智能体行动通过三阶段评估进行路由：（1）**拒绝**规则（绝对优先级——阻止