多智能体系统与协作架构

多智能体系统 (MAS) 概述

多智能体系统 (Multi-Agent System, MAS) 是指由 2 个或更多独立 Agent 通过协议和共享环境进行协作的系统。每个 Agent 拥有自己的感知能力、决策能力和行动能力，通过消息传递或共享状态协调完成任务。

四大特征

独立性 (Autonomy)

每个 Agent 独立运行，拥有自己的状态和决策逻辑，不依赖中央控制。单一 Agent 的故障不会导致整个系统崩溃。

交互性 (Interaction)

Agent 之间通过消息传递、共享内存或黑板系统进行通信。交互协议定义了谁能说话、说什么、何时说。

协同性 (Coordination)

多个 Agent 通过任务分解、资源分配和冲突消解共同完成超出单一 Agent 能力的复杂目标。

涌现性 (Emergence)

系统整体行为无法从单个 Agent 行为推断——群体智能、分工自组织、意外创新都是涌现的表现。

单 Agent vs 多 Agent

维度	单 Agent	多 Agent
架构复杂度	低，单一控制流	高，需协调、通信、共识机制
可扩展性	受限于单 LLM 上下文窗口	可按需增减 Agent，天然水平扩展
容错性	单点故障	部分失败可隔离，整体继续运行
适用场景	明确、线性的任务	跨领域、大规模、需分工的复杂任务
成本	较低，单模型调用	较高，多模型 × 多轮调用
典型框架	ReAct, Plan-and-Execute	CrewAI, AutoGen, OpenAI Swarm

四种协作拓扑

拓扑决定了 Agent 之间信息流动的方式。选择拓扑的核心依据是问题的 依赖结构——任务之间是否有先后、是否可并行、是否需要共识。

主管-专家模式 (Hierarchical)

一个 Supervisor Agent 负责任务分解和分配，多个 Expert Agent 执行具体子任务。Supervisor 收集结果、评估质量、决定是否需要返工。

适用：任务可清晰分解且子任务之间有明确边界的场景。类似组织架构中的"经理-工程师"关系。
代表：CrewAI 的 Crew 模式，AutoGen 的 AssistantAgent + UserProxyAgent。

并行模式 (Swarm / Parallel)

多个同质或异质 Agent 同时工作，各自独立解决问题，最后通过聚合函数 (merge/vote/select) 合并结果。

适用：子任务之间无依赖关系、可独立求解的场景。也适合需要"多视角投票"以提高准确性。
代表：Anthropic 的并行工具调用，OpenAI Swarm 中的多 worker 并发。

顺序模式 (Pipeline / Sequential)

Agent 形成线性流水线，前一个 Agent 的输出是后一个的输入。每个 Agent 专注一个处理阶段。

适用：有严格先后依赖的任务链——如"分析 → 生成 → 审查 → 修正"。Prompt Chaining 的多 Agent 版本。
代表：政务七智能体流水线、内容审核多级 pipeline。

网络模式 (Conversational / Mesh)

所有 Agent 都可以互相通信，形成全连接或稀疏连接的对话网络。通过多轮对话逐步达成共识。

适用：需要跨领域知识融合、创意碰撞、或复杂辩论的场景。
代表：AutoGen Group Chat，ChatDev 的角色扮演对话。

核心洞察

拓扑选择应镜像问题的依赖结构，而非追求复杂性。层级拓扑适合可分解问题，并行拓扑适合可独立求解的问题，顺序拓扑适合严格依赖链，网络拓扑适合需要共识的问题。选错拓扑比选错模型更致命。

两种规划策略

多 Agent 系统的规划分为两大范式，核心区别在于 分解和执行是否交替进行。

预先分解 (Static Planning)

机制：先完整分解任务为子任务树，再逐一分配执行。计划在执行前就固定。

优点：全局视图清晰，资源可预先分配，适合已知结构的任务。
缺点：对执行中的意外缺乏适应性，可能需要返工整个计划。
典型：CrewAI 的 SequentialProcess、Plan-and-Execute 模式。

交错分解 (Dynamic Planning)

机制：分解一步、执行一步、观察结果后再决定下一步。计划和执行交替进行。

优点：高度适应执行中的变化，可基于实际结果调整后续计划。
缺点：缺乏全局视野，可能遗漏跨步骤的优化机会。
典型：ReAct 循环、AutoGen 的自适应对话流。

实践建议：混合使用

生产系统通常混合两种策略：用静态规划生成高层大纲（里程碑和依赖关系），在执行每个子任务时使用动态规划展开细节。这样既有全局视野，又保持对变化的适应性。类似敏捷开发中的"Epic → Sprint → Daily"三层规划。

Generator-Evaluator 架构

受 GAN (生成对抗网络) 启发，Generator-Evaluator 架构将 Agent 系统分为三个核心角色：Planner（规划）、Generator（生成）和 Evaluator（评估），形成持续改进的闭环。

三角色分工

角色	职责	典型实现	调用成本
Planner	分析需求，分解任务，制定执行计划	高质量模型 (Claude Opus / GPT-4o)	$0.46
Generator	执行具体生成/编码任务	高能力模型 + 工具调用	$71.00
Evaluator	评估输出质量，提供反馈，触发返工	专项评估模型 + 规则检查	$3.24
典型 Sprint 总成本			~$124.70

V1 Sprint → V2 持续构建

V1 Sprint 架构：Planner 一次性生成完整计划，Generator 按计划顺序执行，Evaluator 在最后做一次性评估。适合短任务，但长任务中 Generator 可能偏离方向而 Evaluator 无法及时纠正。

V2 持续构建：Generator 每完成一个子任务就提交给 Evaluator，Evaluator 实时反馈，Planner 根据评估结果动态调整后续计划。形成 Generator↔Evaluator 的快速反馈回路。

四大设计原则

1. Evaluator 不应固定

Evaluator 的标准应随任务类型和 Generator 的能力进化而调整。硬编码的评估规则会快速过时。

2. 组件编码假设

每个组件（Planner/Generator/Evaluator）都内嵌了对任务和领域的假设。明确这些假设是调优的前提。

3. 校准需要迭代

Generator 和 Evaluator 之间的"共识"需要多轮校准。Evaluatortoo 严格会阻塞进度，太宽松会放过缺陷。

4. 更强模型 = 更大驾驭空间

底层模型越强，Planner 可以制定更复杂的策略，Evaluator 可以做更精细的判断，整个系统的上限更高。

自我完善飞轮

自我完善飞轮是 MAS 实现持续进化的核心机制，将 Agent 的每一次执行都转化为未来改进的素材。

Action (执行)

Agent 执行具体任务——生成代码、回答问题、调用工具。每次执行产生原始结果和元数据（耗时、token 数、工具调用链）。

Experience (经验)

将执行结果与预期目标对比，提取成功模式和失败原因。包括：哪些步骤有效、哪些失败、失败的环境条件是什么。

Reflection (反思)

更高层次的抽象——跨多次执行归纳规律。"这类问题用方法 A 比方法 B 成功率高 40%"。Reflexion 论文的核心贡献。

Memory (记忆)

将反思结果存入三层记忆架构：工作记忆（当前任务上下文）、短期记忆（近期会话经验）、长期记忆（跨会话的规律和知识）。

Improve Future Actions (改进)

下次执行类似任务时，从记忆中检索历史经验，调整策略选择、Prompt 模板、工具使用方式，形成闭环改进。

与三层记忆架构的连接

自我完善飞轮的 Memory 环节直接对应三层记忆架构：工作记忆维持当前任务上下文（如 ReAct 的思考链），短期记忆存储近期会话的反思结果（如 Reflexion 的 verbal memory），长期记忆积累跨会话的规律（如向量数据库中的历史经验）。飞轮每转一圈，长期记忆就更丰富，Agent 的能力边界就更大。

案例：政务领域七智能体流水线

一个典型的多 Agent 顺序流水线应用——将政务执法案件的复杂处理流程拆解为七个专职 Agent，形成端到端的自动化处理管线。

阶段	Agent 名称	职责	输入 → 输出
1	任务分解 Agent	解析案件描述，识别违法行为类型，分解为结构化子任务	案件文本 → 结构化任务清单
2	合规审查 Agent	检查案件处理是否符合程序法和实体法要求	任务清单 → 合规检查报告
3	条款匹配 Agent	从法规数据库中检索并匹配适用法律条款	违法行为描述 → 适用条款列表
4	处罚分析 Agent	基于匹配条款和案件情节，分析量罚建议	条款 + 情节 → 处罚建议
5	归档 Agent	将处理结果整理为标准格式，生成案件档案	全流程数据 → 标准案件档案
6	整改追踪 Agent	生成整改通知，设定追踪时间节点和验收标准	处罚建议 → 整改追踪计划
7	摘要 Agent	生成面向不同受众（领导/当事人/公众）的案件摘要	全流程数据 → 多版本摘要

为什么是多 Agent 而非单 Agent？

政务执法场景对准确性和可追溯性要求极高。单 Agent 处理七类任务会导致 Prompt 臃肿、上下文稀释和角色混乱。拆分为七个专职 Agent 后：每个 Agent 的 System Prompt 可以高度优化；中间结果可在 Agent 之间持久化，断点可恢复；每个 Agent 可独立升级和测试；出了问题可以精确定位到具体环节。