多 Agent 系统综述：架构、记忆与规划
原文：A Survey on Large Language Model based Autonomous Agents
发表：arXiv 2404.11584
翻译整理：2026-06-16
综述范围
本综述系统梳理了基于 LLM 的自主 Agent 的最新进展，重点覆盖：
- 单 Agent 架构设计模式
- 多 Agent 协作框架
- 记忆机制实现
- 规划与自我修正方法
- 人类反馈的作用
单 Agent 架构
主流架构回顾
| 架构 | 核心特点 |
|---|---|
| ReAct | 交替进行推理（Reasoning）和行动（Acting），每一步先思考再执行 |
| RAISE | 添加专用记忆模块：短期暂存 + 长期示例存储 |
| Reflexion | 失败后语言反思，将反思存入情景记忆，下轮任务时重用 |
| AutoGPT+P | 结合规划阶段，先生成计划再执行 |
| LATS | 语言 Agent 树搜索，通过树搜索探索多种执行路径 |
共同发现：
“Agent 成功完成目标，取决于正确的规划和自我修正能力。”
这些架构的一个共同趋势是：在执行前增加显式的规划阶段，让 Agent 先「想清楚怎么做」再动手。
多 Agent 系统架构
两种组织结构
垂直结构（层级式）：
[指挥 Agent]
/ | \
[子 Agent A] [子 Agent B] [子 Agent C]
- 有清晰的指挥链
- 指挥 Agent 分配任务，子 Agent 执行并汇报
- 适合任务分解明确、子任务相对独立的场景
水平结构（对等式）：
[Agent A] ←→ [Agent B] ←→ [Agent C]
↑________________________↓
- Agent 之间平等协作，无固定层级
- 通过辩论、投票或共识机制做出决策
- 适合需要多视角验证或创意发散的场景
关键设计特性
动态团队组建：根据任务需求动态选择 Agent 成员，而非固定团队。
专业化角色定义：为每个 Agent 分配明确角色（如代码 Agent、测试 Agent、文档 Agent），避免职责重叠。
代表性框架：
- DyLAN：动态语言 Agent 网络，自适应任务分配
- AgentVerse：多 Agent 协作平台，支持自定义角色
- MetaGPT：将软件开发团队的协作流程编码为多 Agent 工作流
记忆机制
RAISE 的双层记忆方案
RAISE 架构明确分离了两类记忆：
短期存储（暂存器） 长期存储（示例库）
───────────────── ──────────────────
当前任务状态 过去解决过的类似问题
临时变量 成功的行动序列模板
本轮对话历史 领域知识
执行新任务时：
- 从长期存储中检索「相似历史案例」
- 将案例注入上下文作为 few-shot 示例
- Agent 参考历史案例执行当前任务
效果：Agent 不必从零开始解决遇到过的类型问题，可以复用历史经验。
规划方法分类
四种主要规划策略
1. 任务分解（Task Decomposition）
将复杂任务拆分为更小、更可管理的子任务。
复杂任务："帮我分析这份财务报告并给出投资建议"
↓
子任务1：提取关键财务指标
子任务2：与行业基准对比
子任务3：识别风险因素
子任务4：综合生成建议
2. 多计划选择（Multi-plan Selection）
生成多个备选计划，选择最优的执行。
生成计划 A → 评估
生成计划 B → 评估 → 选择得分最高的计划执行
生成计划 C → 评估
3. 反思式优化（Reflection-based Refinement）
执行 → 评估结果 → 反思 → 修改计划 → 重新执行的迭代循环（Reflexion 框架的规划扩展）。
4. 记忆增强规划（Memory-augmented Planning）
将历史规划经验存入记忆，新任务规划时参考历史方案。
关键实证发现
发现 1：有领导者的团队完成任务更快
研究发现，有指定领导 Agent 的多 Agent 团队比无领导的平等团队完成任务更快。
机制分析：领导者的作用是：
- 分配任务，避免多个 Agent 重复做同一件事
- 设定优先级，避免 Agent 陷入无意义的循环讨论
- 综合各 Agent 输出，推动决策向前推进
注意：论文报告了「快 10%」的具体数字，但在对抗性验证中未能独立复现，该方向性结论（有领导者更好）比具体数字更可信。
发现 2：人类反馈显著改善结果
人类在适当节点的介入能防止 Agent 走入低效死胡同，特别是：
- 任务理解偏差时（Agent 做的不是用户真正想要的）
- 进入循环时（Agent 在两个状态间反复横跳）
- 面对高风险决策时（不可逆操作需要人工确认）
发现 3：单 Agent vs 多 Agent 的选择标准
| 使用单 Agent | 使用多 Agent |
|---|---|
| 任务定义明确，工具调用直接 | 需要协作、反馈和并行执行 |
| 失败代价低，可以多次重试 | 需要多视角验证结果 |
| 低延迟要求 | 任务可以并行分解 |
| 调试优先 | 需要专业化分工 |
当前挑战与局限
挑战 1：评估基准不一致
不同研究使用不同评估基准，导致跨研究比较困难。需要社区统一的评估标准。
挑战 2：训练数据污染
LLM 可能在训练时见过评估基准中的题目（数据污染），导致评估结果虚高。
挑战 3：真实世界适用性不足
大多数评估在受控实验环境下进行，真实部署中的噪声、意外输入、系统故障等问题研究不足。
挑战 4：继承的语言模型偏差
Agent 继承了底层 LLM 的所有偏差，包括幻觉、知识截止日期、特定文化视角偏差等。
实践建议
- 优先定义清晰角色：每个 Agent（或子任务）的职责边界要明确，避免职责模糊导致的重复或遗漏
- 规划-执行-评估分离：不要让同一个 Agent 在同一步骤内既规划又执行——显式分离这三个阶段
- 设计检查点：在关键节点（尤其是不可逆操作前）设计人工确认点
- 消息过滤：Agent 间通信需要过滤，避免无关信息污染其他 Agent 的上下文
- 从单 Agent 开始：除非有明确理由需要多 Agent，否则先实现单 Agent 版本并充分验证