从 35 种 Agent 架构看懂智能体系统：模块设计、运行机制与工程组成

本文转自：Coggle数据科学

当我们第一次接触 Agent 技术时，很容易被大量新名词淹没：Reflection、ReAct、Self-RAG、Tree of Thoughts、LATS、MemGPT、Multi-Agent、GraphRAG、SWE-Agent……这些名称看起来像是三十多种完全不同的技术路线，仿佛每学习一种架构，就需要重新理解一套系统。

但真正阅读这些 Agent 架构的代码后会发现，事情并没有那么复杂。某些架构增加了反思模块，某些架构增加了搜索树，某些架构接入外部知识库，某些架构加入长期记忆，还有一些架构通过多个 Agent 的协作、辩论或监督来提高结果质量。

从工程角度来看，一个 Agent 系统通常可以拆解为几个相对稳定的组成部分：

模块	主要职责
状态 State	保存任务执行过程中的上下文和中间结果
模型 Model	理解任务、生成内容、分类和判断
工作流 Workflow	决定节点之间按照什么顺序执行
工具 Tools	搜索、浏览网页、运行代码、操作文件或调用业务接口
检索 Retrieval	从外部知识库中找到相关信息
记忆 Memory	保存跨步骤或跨任务的经验
评估 Evaluator	判断答案质量、任务是否完成以及是否需要继续
路由 Router	选择下一步动作、工具或子架构
追踪 Tracing	记录 Agent 执行了哪些节点和决策
安全控制 Safety	限制高风险操作，增加审批、模拟和权限判断

理解了这些模块以后，再看 35 种 Agent 架构，就会发现它们更像是使用同一组积木搭建出来的不同建筑，而不是 35 种互不相关的技术。

---

Agent 并不是一个会自主思考的软件生命体

很多人对 Agent 的第一印象，是“让大模型自己决定接下来做什么”。

这种描述并不算完全错误，但如果把它直接应用到工程系统中，就很容易产生误解。一个可靠的 Agent 系统，通常不会让大模型无限制地控制整个执行过程，而是提前定义好允许执行的节点、合法的状态变化以及能够选择的动作范围。

例如，一个最基础的反思型 Agent，可以被设计为：

生成初稿

↓

评价初稿

↓

判断是否达标

├── 达标 → 输出结果

└── 未达标 → 修改答案 → 再次评价

这里真正决定流程结构的不是大模型，而是程序代码。

大模型可以生成初稿，也可以分析初稿存在的问题，但“评价之后只能进入输出或修改节点”“最多允许修改三次”“分数达到八分以后必须结束”，这些规则通常由 Python 或工作流引擎负责执行。

因此，在成熟的 Agent 系统中，通常存在这样一种分工：

大模型负责模糊认知

程序负责确定性执行

大模型擅长理解自然语言、分析复杂语义、生成方案和提取结构化信息，但它不擅长稳定地执行严格规则。程序则恰好相反，它难以理解复杂语义，却非常适合进行计数、比较、循环、条件判断和权限校验。

Agent 工程的关键，并不是把所有决定都交给大模型，而是找到模型能力与程序逻辑之间的合理边界。

---

统一架构接口是整个系统的基础

在代码层面，这类 Agent 项目通常会先定义一个统一的架构接口。不同 Agent 虽然内部流程不同，但对外都可以使用类似的方式运行：

architecture = Reflection(...)

result = architecture.run(task)

其中，架构一般会提供两个核心方法：

build()

run(task)

build()用来构建工作流图，定义系统中有哪些节点、节点之间如何连接以及什么条件下切换路线。

run()则负责接收用户任务，创建初始状态，执行工作流，并最终返回结果。

为了让不同架构之间可以互相组合，返回值也需要保持一致。一个典型的 Agent 执行结果通常包括：

ArchitectureResult(

output=最终答案,

state=最终状态,

trace=执行轨迹,

metadata=运行指标

)

其中，output是用户最终看到的内容，state保存任务执行完成后的内部状态，trace记录 Agent 依次执行了哪些节点，而metadata则可以保存调用次数、迭代轮数、评分结果、检索文档数量和工具使用次数等信息。

这种统一接口非常重要，因为它使得上层系统不需要关心某个架构内部究竟使用了反思、搜索树还是多 Agent 协作。对于 Meta-Controller 这样的路由架构来说，Reflection、Planning、ReAct 和 GraphRAG 都只是可以被调用的能力模块。

---

State 是 Agent 工作流中的隐形主角

普通的大模型调用通常只有输入和输出：

用户问题 → 大模型 → 回答

Agent 则不同，它往往需要经过多个步骤，因此必须保存过程中的各种中间信息。

例如，一个检索增强 Agent 的状态可能包含：

{

"task":"用户问题",

"query":"改写后的检索词",

"documents": [],

"graded_documents": [],

"draft":"",

"critique":"",

"iteration":0,

"final_answer":""

}

每一个节点只负责读取状态中的部分字段，然后写入新的结果。

检索节点读取query，写入documents；文档评价节点读取documents，写入graded_documents；答案生成节点读取筛选后的文档，写入draft；反思节点读取draft，写入critique。

这种设计使 Agent 的执行过程从一个难以观察的黑盒，变成了一组可以检查、测试和替换的状态变化。

对于初学者而言，可以把 State 理解成 Agent 在完成任务时使用的一张工作台。模型、工具和工作流节点不会凭空记住之前发生了什么，它们只是不断读取和修改这张工作台上的内容。

---

Reasoning 与 Reflection：让答案经过多轮修正

Reasoning & Reflection 家族的核心目标，是通过自我检查和迭代提高答案质量。

这一类包括 Reflection、Reflexion、Chain-of-Verification、Self-Discover 和 Constitutional AI。

最简单的 Reflection 使用“生成、批评、修改”的循环。模型先生成一个答案，再由评估节点检查答案是否准确、完整和清晰，如果结果没有达到目标，就根据批评意见重新生成。

Reflexion 在此基础上增加了情景记忆。系统不仅修改当前答案，还会把失败原因和改进经验保存下来，使后续任务可以参考之前的反思。

Chain-of-Verification 更关注事实验证。它不会直接要求模型重新评价整篇答案，而是先从答案中拆解出需要验证的关键事实，再分别回答验证问题，最后根据验证结果修正原答案。

Self-Discover 则尝试先选择合适的推理模块，再根据任务调整这些模块，形成具体推理结构，最后执行求解。它关注的不只是答案本身，还关注“这个问题应该使用什么推理方式”。

Constitutional AI 引入了一组明确的原则。系统会根据每一条原则检查答案是否合格，例如是否有害、是否误导、是否违反规则，然后针对未通过的原则进行修改。

这些架构虽然名称不同，但底层结构非常接近：

生成候选结果

↓

根据某种标准进行评价

↓

找到问题

↓

修改结果

↓

判断是否继续

它们之间最大的区别，不在于是否进行了反思，而在于使用什么标准反思、是否保存反思经验，以及如何确定停止条件。

---

Sampling 与 Search：不要只相信第一次生成

大模型的输出具有随机性。同一个问题生成多次，可能得到不同的推理路径和答案。Sampling & Search 家族正是利用了这种特性。

Self-Consistency 会对同一个问题采样多条推理路径，然后通过多数投票选择最终答案。它背后的直觉很简单：单次推理可能出错，但如果多条相互独立的推理都指向同一个结果，这个结果通常更加可靠。

Ensemble 与 Self-Consistency 类似，但它可以使用多个模型或多个不同角色，并且为不同候选答案设置不同权重。

Tree of Thoughts 不再只生成完整答案，而是把推理过程拆成多个“思维节点”。系统会在每一层生成多个候选思路，评价这些思路，保留更有希望的分支，然后继续向下扩展。

LATS 则进一步使用类似蒙特卡洛树搜索的方式维护一棵搜索树。每个节点记录访问次数、价值和父子关系，系统通过选择、扩展、评价和价值回传，不断找到更有希望的路径。

Mental Loop 的结构相对简单，它通过多次模拟候选结果，再使用确定性规则进行评分和筛选。

这一家族的共同特点可以概括为：

不要让模型只思考一次

让它生成多个可能

再通过程序选择更好的路径

它们通常能够提升复杂推理任务的表现，但代价也十分明显。候选数量越多、树的深度越大，模型调用次数和运行成本就越高。因此，搜索类 Agent 必须同时设计预算机制，例如最大分支数、最大深度、最大迭代轮数和全局 Token 限制。

---

Retrieval：让 Agent 使用外部知识

大模型自身的知识有限，而且可能过时。Retrieval 家族通过接入外部知识库，使答案能够基于真实文档生成。

基础 RAG 的流程通常是：

用户问题

↓

向量检索

↓

找到相关文档

↓

文档与问题一起交给模型

↓

生成答案

Agentic RAG 在此基础上增加了自主判断。Agent 可以决定是否需要检索、应该搜索什么内容，以及现有信息是否足够。

Corrective RAG 会先评价检索结果。如果本地文档质量足够，就直接使用本地文档；如果相关性较差，则退回到 Web 搜索；如果部分文档可用，则可以采用混合策略。

Self-RAG 会为每篇文档生成反思结果，判断文档是否相关、是否支持当前回答以及是否值得使用，然后由程序筛选文档。

Adaptive RAG 会根据问题复杂度提前选择路线。简单问题可以直接回答，中等问题执行一次检索，复杂问题则采用多步骤检索。

GraphRAG 不只把文档保存为向量，还会从文档中提取实体与关系，形成知识图谱，并通过社区摘要回答宏观问题，通过局部图查询回答具体实体问题。

这五种 RAG 架构的区别，本质上来自几个关键问题：

问题	不同架构的处理方式
是否需要检索	固定检索或由 Agent 判断
检索多少次	一次检索或多阶段检索
如何判断文档质量	相似度、模型评价或结构化标签
文档不足怎么办	继续检索、改写问题或搜索 Web
知识如何组织	文本块、向量或知识图谱

在实际系统中，RAG 的核心往往不只是“接一个向量数据库”，而是完整的检索决策链条，包括查询改写、召回、重排、文档评价、答案生成、引用验证以及检索失败时的回退策略。

---

Memory：让 Agent 跨任务积累经验

普通对话历史不等于真正的 Agent Memory。

对话历史只是把之前的消息重新放进上下文，而 Agent Memory 更关注应该保存什么、以什么结构保存、什么时候检索以及如何避免旧信息干扰当前任务。

Episodic + Semantic Memory 通常同时保存两类内容。Episodic Memory 保存发生过的任务、对话和行为过程，Semantic Memory 则保存从经历中抽取出的稳定事实。

Graph Memory 把信息保存为：

主体 → 关系 → 客体

例如：

用户 → 偏好 → 长篇技术文章

项目 → 使用 → LangGraph

MemGPT 借鉴操作系统的分层存储思想，把信息划分为核心上下文、近期记忆和外部归档，避免所有历史信息同时占用模型上下文。

Voyager 保存的不是普通文本记忆，而是可以重复执行的技能。系统完成一个任务后，将成功方案整理成 Python 技能，后续遇到相似任务时直接复用。

Agent Workflow Memory 保存的是更高层的工作流经验，例如“处理竞品分析任务时，先搜索产品信息，再收集用户评价，最后按功能、价格和口碑生成对比报告”。

从工程上看，Memory 系统至少要回答四个问题：

保存什么

什么时候保存

如何检索

检索出来以后如何使用

如果没有明确的写入规则，记忆库会不断积累无效内容；如果没有合理的检索规则，旧记忆又可能干扰当前决策。

因此，Memory 并不是简单地增加一个向量数据库，而是一套信息生命周期管理机制。

---

Tools 与 Actions：让 Agent 从回答问题走向执行任务

当 Agent 只能生成文字时，它本质上仍然是一个复杂的问答系统。工具调用使 Agent 可以真正影响外部环境。

Tool Use 是最基础的工具型架构。模型根据用户任务决定是否调用搜索、计算器、数据库或业务接口，然后根据工具返回的结果继续回答。

ReAct 把流程显式拆分为：

Thought → Action → Observation

模型先分析当前情况，再选择工具执行动作，然后根据工具观察结果继续思考。

Planning 会先把复杂任务拆解为多个步骤，再依次执行这些步骤，并在执行过程中根据结果重新规划。

PEV，也就是 Plan-Execute-Verify，会在每个步骤执行完成后进行验证。如果当前步骤没有达到目标，就重新执行或修改后续计划。

SWE-Agent 面向软件工程任务，它需要读取项目文件、定位代码、修改文件、执行测试，并根据测试结果继续修复。

BrowserAgent 则使用真实浏览器完成网页操作，包括打开页面、点击按钮、填写表单和读取动态内容。

这些架构之间能力差异很大，但从代码结构来看，工具通常需要具备统一接口：

tool.name

tool.description

tool.input_schema

tool.invoke(...)

其中，description非常关键，因为模型会根据工具描述判断什么时候应该调用这个工具。

与此同时，工具系统还必须提供硬性限制。模型在 Prompt 中承诺“只调用三次工具”并不可靠，真正稳定的做法是由程序统计工具调用次数，并在达到限制后禁止继续调用。

对于文件修改、代码执行、浏览器操作和外部系统写入等高风险工具，还需要额外增加沙箱、审批、权限控制和操作日志。

---

Multi-Agent：多个 Agent 不只是多次调用模型

Multi-Agent 家族通过多个角色协作完成任务。

最基础的 Multi-Agent 架构通常包含一个 Supervisor 和若干 Specialist。Supervisor 负责分析任务并选择合适的专家，专家分别完成研究、编程、分析或写作。

Blackboard 架构让多个 Agent 共享一个公共工作区。每个 Agent 都可以读取黑板中的内容，并根据自己的专业能力补充信息。

Debate 让多个 Agent 针对同一问题进行多轮辩论，希望通过观点冲突暴露错误并提高答案质量。

STORM 会从多个视角开展资料研究，再把不同视角的研究结果汇总成一篇结构完整的文章。

Meta-Controller 则位于更高一层，它不是在多个普通 Agent 之间路由，而是在多个 Agent 架构之间路由。它可以判断当前任务更适合 Reflection、Planning、ReAct 还是其他架构。

Multi-Agent 系统真正的难点，并不是创建多个模型角色，而是如何协调它们。

如果每个 Agent 都生成一遍完整答案，只会成倍增加成本，却不一定提高质量。有效的多 Agent 设计需要明确角色边界、输入输出格式、共享状态、冲突解决方法以及终止条件。

---

Safety 与 Routing：把风险决策交给确定性程序

Agent 具备的工具越多，安全问题就越重要。

Dry-Run 架构不会直接执行高风险操作，而是先生成行动方案，再模拟可能产生的影响，最后进入审批节点。只有通过审批以后，系统才会真正执行。

Reflexive Metacognitive 架构会分析自身能力边界，判断当前任务是否可以直接处理、是否需要使用工具、是否应该转交其他架构，或者是否需要拒绝。

Computer Use 类架构允许 Agent 操作计算机界面，因此必须设置更严格的安全门，包括允许访问的网站、禁止点击的区域、敏感操作确认以及执行记录。

在这些架构中，最重要的工程思想是确定性路由。

与其让模型直接输出一个模糊分数：

这个操作的危险程度是 7.6 分

更稳定的方法是让模型输出结构化类别：

{

"involves_payment":True,

"modifies_external_data":True,

"is_reversible":False,

"contains_sensitive_information":False

}

然后由 Python 根据明确规则决定：

ifinvolves_payment:

require_human_approval =True

这种方式可以称为 deterministic-picker，也就是确定性选择器。

它把大模型擅长的语义判断，与程序擅长的规则执行结合起来，是整个 Agent 工程中非常重要的通用模式。

---

Specialty：具有特殊运行形态的架构

有些 Agent 架构很难被归入常见分类。

RLHF Self-Improvement 会生成候选结果，按照多个维度进行评价，将高质量结果保存到经验库，并在后续任务中继续参考这些结果。它虽然借用了 RLHF 的思想，但在应用层实现中通常并不真正训练模型参数，而是通过评价、筛选和记忆实现行为改进。

Cellular Automata 则把 Agent 规则应用到网格环境中。每个单元根据相邻状态和模型生成的规则发生变化，它更像是 Agent 与复杂系统模拟的结合。

这类架构的共同点不强，它们更多是在探索大模型如何参与新的计算结构和交互环境。

---

Cross-Cutting：真正重要的是跨架构能力

阅读这些架构后会发现，一些模式会反复出现，它们往往比具体的架构名称更加重要。

Deterministic-picker 出现在文档筛选、路线选择、安全判断、候选答案评价和搜索树节点选择中。

Memory variants 出现在 Reflexion、Voyager、MemGPT、Workflow Memory 和多 Agent 协作中。

结构化输出几乎贯穿整个系统，因为只有当模型输出可解析的字段时，程序才能进行稳定路由。

预算控制同样是所有架构都必须考虑的问题，包括最大迭代次数、最大工具调用次数、最大检索次数、最大树深度和最大运行时间。

Tracing 也是不可缺少的能力。没有轨迹记录，就很难判断答案错误到底来自模型生成、检索失败、工具异常、路线错误还是记忆污染。

因此，真正成熟的 Agent 平台并不会只关注“实现了多少种架构”，而会优先建设这些跨架构基础设施。

---

一个完整 Agent 系统的模块关系

综合这些架构，一个较为完整的 Agent 系统可以被理解为下面这条链路：

用户任务

↓

任务分析与安全检查

↓

架构或路线选择

↓

创建任务状态

↓

规划 / 检索 / 工具调用 / 多 Agent 协作

↓

结果评价

↓

不合格则反思、重试或重新规划

↓

保存有价值的记忆

↓

生成最终结果

↓

记录轨迹、成本和执行指标

其中，LLM 并不是整个系统，而是系统中的一个推理组件。

工作流负责组织步骤，State 负责传递上下文，Tools 负责连接外部环境，Retrieval 负责补充知识，Memory 负责积累经验，Evaluator 负责判断质量，Router 负责选择下一步，Safety 负责限制风险，Tracing 则让整个系统变得可观察。

---

初学者应该如何选择 Agent 架构

对于初学者来说，没有必要一次性学习全部 35 种架构。最合适的学习路线，是先从模块和控制流出发。

• 首先学习 Reflection，因为它包含最基本的状态、循环、评价和终止条件。
• 接着学习 Tool Use，理解模型如何选择工具，以及程序如何执行工具并把结果返回给模型。
• 然后学习 ReAct，观察思考、行动和观察如何形成循环。
• 在此基础上学习 Planning，理解复杂任务如何拆解为多个步骤。
• 掌握基本工作流以后，再学习 Corrective RAG 和 Self-RAG，理解检索、文档评价和回退策略。
• 随后可以学习 Reflexion 和 MemGPT，理解短期状态与长期记忆的区别。
• 最后再进入 Tree of Thoughts、LATS、Multi-Agent 和 Meta-Controller，因为这些架构需要同时处理搜索空间、预算控制、角色协调和复杂路由。

可以按照下面的顺序逐步深入：

Reflection

↓

Tool Use

↓

ReAct

↓

Planning

↓

Corrective RAG

↓

Memory

↓

Multi-Agent

↓

Tree Search

↓

Meta-Controller

---

Agent 工程的本质

Agent 技术看起来充满了新概念，但从软件工程角度，它仍然遵循一些非常朴素的原则。

复杂任务需要拆解，执行过程需要状态，外部能力需要工具，知识不足需要检索，经验需要记忆，结果需要验证，高风险动作需要审批，失败需要重试，整个过程需要日志和指标。

大模型为这些传统模块增加了自然语言理解、模糊推理和内容生成能力，但它并没有替代程序控制。

一个稳定的 Agent 系统，不是让大模型无限自由地决定一切，而是在确定性的系统边界内，允许大模型处理那些难以使用固定规则描述的问题。

因此，Agent 的核心并不是“模型会不会自己思考”，而是：

如何把模型的概率性智能，嵌入一个可控制、可观察、可评估、可恢复的软件系统之中。

Reflection 增加了自我修正，Tree of Thoughts 增加了搜索空间，RAG 增加了外部知识，Memory 增加了跨任务经验，Tools 增加了现实执行能力，Multi-Agent 增加了角色协作，Safety 增加了系统边界，而 Meta-Controller 则尝试在这些能力之间进行动态选择。

最终，一个真正有价值的 Agent，并不一定拥有最复杂的架构，而是能够在任务质量、运行成本、响应速度、系统可靠性和操作风险之间，做出恰当的工程平衡。