好的Agent架构不是堆砌模式，而是让“规划—执行—反思”在正确的粒度上各司其职。
一、引言：Agent开发的核心困惑
AI Agent正从“能聊”走向“能用”。它以一个LLM为“大脑”，能够理解复杂目标、进行规划、并调用外部工具来执行任务。然而，很多开发者在构建Agent时面临一个共同的困惑：ReAct、Plan-and-Execute、Reflection、Multi-Agent，这些架构模式到底是什么关系？我该怎么选、怎么组合？
本文试图回答这个问题。我将从一个完整软件工程流程的视角——需求分析、设计、实现、测试、验证——来梳理Agent架构的设计思路，并给出一个清晰的框架：P-R²-E（规划-双轨反思-执行）模型。
二、核心架构模式速览
在深入之前，先简要回顾几个核心模式。
2.1 ReAct：推理与行动的循环
ReAct（Reasoning + Acting）是最基础的Agent模式。它将推理和行动交替进行：LLM先“思考”（Thought）当前状态，再“行动”（Action）调用工具，然后“观察”（Observation）结果，如此循环。
1 | Thought → Action → Observation → (repeat) → Final Answer |
ReAct的优势在于灵活——每一步都根据上一步的观察动态调整。但它的局限也很明显：每次只规划一步，缺乏全局视野。适合简单任务，如信息查询、单步工具调用。
2.2 Plan-and-Execute：规划与执行分离
Plan-and-Execute将“规划”和“执行”解耦为两个阶段。Planner先生成多步骤计划，Executor再按计划逐步执行。
其核心优势在于全局视野——规划阶段就能看到全貌，避免“走一步看一步”的短视。但缺点是规划一旦定下就相对固化，对执行中的意外情况应变不足。
2.3 Reflection：自我反思与修正
Reflection让Agent对自己的输出进行自我批评和改进。基础Reflection Agent就是“生成器+反思器”的循环：生成器起草，反思器批评，生成器根据反馈修订。
Reflexion在此基础上更进一步，在日志中记录历史行为、假设和反思内容，让Agent从多次失败中汲取经验。
2.4 Multi-Agent：多角色协作
Multi-Agent系统由多个智能Agent组成，每个Agent承担特定角色，通过协作解决复杂任务。它不是一个独立的架构模式，而是组织多个Agent协作的拓扑方式。
三、P-R²-E：一个统一的架构框架
有了以上基础，我们可以提出一个贯穿全流程的统一框架——P-R²-E（Plan -双轨Reflection - Execute） 。
3.1 核心思想：粒度决定模式
ReAct和Plan-and-Execute不是“二选一”，而是在不同粒度上同时存在。
- 宏观ReAct（规划层） ：推理周期长，动作粒度粗。动作为“生成需求文档”“确定技术选型”“划分模块边界”。
- 微观ReAct（执行层） ：推理周期短，动作粒度细。动作为“编写这个函数”“调用这个API”“查询这条数据”。
规划阶段本身就是一个ReAct过程——LLM反复思考、生成规划方案、评估方案、修正方案。执行阶段同样是一个ReAct过程——每执行一步都观察结果、调整下一步。
Plan-and-Execute的本质，就是用宏观ReAct产出蓝图，再用微观ReAct落实蓝图。
3.2 双轨反思：两个质量闸门
Reflection作为“第四架构”，在P-R²-E中体现为两个独立的质量闸门：
规划期反思（战略反思） ：在动手之前，对规划方案进行对抗性评审。这就像建筑图纸的会审——在破土动工之前发现问题，成本最低。可以采用“魔鬼代言人”方式，让反思器从安全性、可扩展性、边界条件、依赖项等维度扫描规划。
执行期反思（战术反思） ：最简化的形式就是测试。单元测试验证逻辑正确性，集成测试验证模块间协作，端到端测试验证完整流程。测试失败就是最直接、最客观的“反思信号”——它告诉Agent：“你错了，需要调整。”
3.3 Multi-Agent的定位：贯穿流程的协作拓扑
Multi-Agent不是第四架构，而是贯穿P-R²-E全程的“执行拓扑” 。它在不同阶段以不同形态出现：
- 规划期的头脑风暴拓扑：架构师Agent、资深开发Agent、测试专家Agent并行评审规划。
- 执行期的流水线拓扑：起草Agent写代码 → 测试Agent写测试 → 审查Agent运行验证。
- 纠偏期的仲裁拓扑：执行失败且微观ReAct无法修复时，主管Agent介入，触发重规划。
四、全流程应用指南
4.1 需求分析阶段：宏观ReAct + 规划期反思
目标：将模糊的用户需求转化为结构化的任务蓝图。
做法：
- 需求理解（宏观ReAct的“思考”） ：LLM分析用户输入，识别隐含假设和约束条件。
- 方案生成（宏观ReAct的“行动”） ：生成初步的任务规划和执行方案。
- 规划期反思：调用反思器扫描方案漏洞——边界条件、资源依赖、风险点。
- 迭代修正：根据反思结果修正方案，直到通过评审。
产出：一份带验收标准的结构化执行蓝图。
4.2 设计阶段：任务分解 + Multi-Agent拓扑设计
目标：将蓝图拆解为可并行执行的子任务，并设计Agent间的协作方式。
做法：
- 任务分解：将大任务拆解为独立的子任务。
- 角色分配：为每个子任务分配专门的执行Agent——搜索Agent、代码Agent、报告Agent等。
- 协作拓扑设计：确定Agent间的通信方式和协作流程——串行、并行、还是条件分支。
4.3 实现阶段：微观ReAct + 执行期反思
目标：按蓝图落实每个子任务，并通过持续反思保证质量。
做法：
- 微观ReAct循环：每个执行Agent针对自己的子任务，循环执行“思考→行动→观察”。
- 执行期反思（测试驱动） ：每完成一个功能模块，立即运行对应的测试用例。
- 红绿重构：测试通过则提交；测试失败则触发微观ReAct修正代码。
4.4 测试与验证阶段：系统性验证 + 跨层传导
目标：验证整体功能正确性，并建立“失败向上传导”机制。
做法：
- 分层测试：单元测试（逻辑正确性）→ 集成测试（模块协作）→ 端到端测试（完整流程）。
- 跨层传导机制：如果微观ReAct重试N次仍然失败，则向上抛出异常，触发宏观层面的重规划，而非在同一层无限死循环。
- 经验沉淀：将失败案例和修正方案存入记忆库，供未来类似任务参考。
五、通俗实例：一个旅行规划Agent
让我们用一个具体的例子来理解上述框架。
场景
用户输入：“帮我规划一个从上海出发、去北京玩3天的行程，预算5000元，想去故宫和长城。”
阶段一：需求分析（宏观ReAct + 规划期反思）
宏观ReAct思考：“用户要去北京玩3天，预算5000，必去故宫和长城。我需要考虑交通、住宿、门票、餐饮、市内交通等维度。但用户没说具体日期、住宿偏好、饮食禁忌……”
宏观ReAct行动：生成初版规划方案——
- 查询上海-北京往返交通（高铁/飞机）
- 查询故宫、长城门票及开放时间
- 推荐2-3家预算内酒店
- 规划3天行程（D1故宫+天安门，D2长城，D3自由活动）
- 计算总预算
规划期反思（魔鬼代言人）：“方案没考虑天气——长城下雨怎么办？没考虑周一故宫闭馆？没考虑用户是否愿意早起赶高铁？没考虑景点间交通时间？”
修正后方案：增加天气查询、日期校验、交通时间评估、备选方案（雨天室内景点）。
阶段二：设计（任务分解 + Multi-Agent拓扑）
将任务分解给多个专业Agent——
- 搜索Agent：查询高铁/机票价格、酒店信息
- 景点Agent：查询故宫、长城门票、开放时间、游览建议
- 行程Agent：综合信息生成每日行程
- 预算Agent：逐项计算并控制总预算
- 反思Agent：全程监控方案合理性
阶段三：实现（微观ReAct + 执行期反思）
搜索Agent的微观ReAct：
- Thought：“需要查询上海到北京的高铁时刻和价格。”
- Action：调用12306 API查询
- Observation：“返回10个车次，价格从553到933不等……”
- Thought：“用户预算5000，建议选择性价比高的G字头，票价约553。”
- Action：筛选并记录推荐车次
执行期反思（测试） ：
- 单元测试：“查询结果是否包含日期、车次、价格、时长？”
- 集成测试：“行程Agent能否正确读取搜索Agent的输出？”
- 若测试失败 → 微观ReAct修正 → 重试
阶段四：测试与验证（系统性验证 + 跨层传导）
端到端测试：输入用户需求，检查输出的3天行程是否——
- 包含故宫和长城
- 总预算≤5000元
- 交通时间合理（如高铁不早于6:00、不晚于22:00）
- 景点开放时间匹配
跨层传导：假设长城门票查询失败（API超时），微观ReAct重试3次仍失败→向上传导到宏观层→规划期反思触发→方案增加备选：推荐慕田峪长城（人少、体验好）或调整行程顺序。
最终，Agent输出一份完整的3天北京旅行方案，包含每日行程、交通建议、酒店推荐、预算明细和备选方案。
六、总结：核心原则
- 粒度分层：规划是宏观ReAct，执行是微观ReAct，各司其职。
- 反思即质量：规划期用对抗性评审，执行期用测试——反思是贯穿全程的质量闸门。
- Multi-Agent是工具而非目的：它是承载上述流程的“角色演员表”，核心在于协作拓扑的设计。
- 失败向上传导：执行层解决不了的问题，交给规划层重新思考，避免死循环。
- 经验可积累：将失败案例和修正方案存入记忆，让Agent越用越聪明。
好的Agent架构，不是堆砌模式，而是让每一种模式在正确的粒度、正确的阶段发挥应有的作用。