多智能体：概念体系与学习要点
定位：本篇是 01-多智能体协作.md 的配套补遗——把"有哪些概念"系统列全，并给出"应该按什么顺序学、学到什么程度"。原 01 文件未改动。
配套阅读：13-进阶与工程化/06-多智能体进阶.md（通信/共识/框架对照）、13-进阶与工程化/01-Agent设计模式与工作流.md（Workflow vs Agent 边界）。
一、概念全景图（先建立地图）
多智能体系统 = 结构（拓扑） × 通信（怎么说话） × 角色（谁干什么） × 调度（怎么分活） × 共识（怎么达成一致） × 状态（共享什么） × 治理（怎么兜底）。
┌─────────── 编排者 Orchestrator ───────────┐
│ 拓扑选择 / 任务分发 / 汇总仲裁 / 终止控制 │
└───────────────────────────────────────────┘
角色层： Planner · Researcher · Coder · Critic · Tester · Validator
通信层： 消息传递 / 共享黑板 / 共享状态
调度层： 分解 → 分发 → 并行/串行 → 依赖(DAG) → 回收
共识层： 投票 / 协商 / 仲裁 / 冲突解决
状态层： 全局状态 / 局部状态 / 记忆共享
风险层： 死锁·活锁·幻觉传播·群体思维·成本爆炸
二、核心概念清单（按维度速查）
2.1 拓扑 / 结构（Topology）
| 概念 |
极简说明 |
何时用 |
| 中心化 / Hub-and-Spoke |
一个中枢分发并汇总，其余为辐条 |
任务可独立分解、需统一出口 |
| 分层 / Hierarchical |
经理逐级委派给工人，结果逐层回传 |
大任务需多级拆解 |
| 流水线 / Pipeline |
串行接力（研究→写作→评审） |
线性、阶段清晰的任务 |
| 网状 / 去中心化 |
Agent 间可任意互联、无中枢 |
需要灵活协商、鲁棒性高 |
| 辩论 / 投票 / Debate |
多个 Agent 互相质疑后投票/综合 |
需深思、易错的高风险判断 |
| 群体 / 蜂群 / Swarm |
大量同质 Agent 简单规则涌现整体行为 |
搜索、优化、探索类任务 |
与原 01 的 4 种编排模式对应：Hub≈Hub-and-Spoke，Pipeline≈Pipeline，Hierarchical≈Hierarchical，Debate/Voting≈Debate。本表补了"网状/蜂群"两种。
2.2 通信（Communication）
| 概念 |
极简说明 |
| 消息传递（Message Passing） |
Agent 间通过显式消息通信，最常用 |
| 共享黑板（Blackboard） |
公共区域，各 Agent 读写共享信息 |
| 共享状态（Shared State） |
跨 Agent 的全局可变状态 |
| 同步通信 |
发方等收方响应，顺序可控但慢 |
| 异步通信 |
发完即走，效率高但需处理时序 |
| 黑盒协作 |
只看对方输出，不知内部过程 |
| 白盒协作 |
共享中间推理，便于溯源但易污染 |
| 自然语言通信 |
用人类语言对话，灵活但难解析 |
| 结构化通信 |
用 JSON/Schema 通信，可校验、易自动化 |
| A2A 协议 |
Google 提出的 Agent 间标准化通信协议 |
| 通信压缩/摘要 |
长对话摘要后再传，省 token、防膨胀 |
2.3 角色与分工（Roles）
| 概念 |
极简说明 |
| Planner（规划者） |
拆解目标、制定步骤 |
| Researcher（研究员） |
检索/调用工具收集信息 |
| Coder / Executor（执行者） |
写代码/调工具落地 |
| Writer（写作者） |
生成文档/报告 |
| Critic / Reviewer（评审者） |
挑错、提改进 |
| Tester / Validator（测试/校验） |
验证结果与约束是否达标 |
| Orchestrator / Supervisor（编排者） |
调度、汇总、仲裁 |
| Worker（工人） |
执行具体子任务 |
| Summarizer（摘要者） |
压缩中间产物 |
| Router（路由器） |
按输入分类分发 |
| 角色粒度（Granularity） |
角色拆多细——过细协调成本高，过粗无分工收益 |
| 动态角色（Dynamic Role） |
运行中按需要切换/认领角色 |
2.4 调度与任务流（Scheduling）
| 概念 |
极简说明 |
| 任务分解（Decomposition） |
把目标拆成子任务（常与规划重叠） |
| 任务分发（Dispatch） |
编排者把子任务派给合适 Agent |
| 任务队列（Task Queue） |
Agent 领取待办，天然支持并行 |
| 并行执行（Parallelism） |
独立子任务同时跑，省时 |
| 依赖图（DAG） |
用有向无环图表达任务先后依赖 |
| 负载均衡 |
避免某 Agent 过载、其他闲置 |
| 终止条件（Termination） |
何时停——达成目标/达轮次上限/无进展 |
2.5 共识与冲突（Consensus）
| 概念 |
极简说明 |
| 投票（Voting） |
多 Agent 对方案表决 |
| 多数决（Majority） |
过半即采纳 |
| 加权投票 |
按角色可信度给不同权重 |
| 协商（Negotiation） |
Agent 间交换立场逐步靠拢 |
| 仲裁（Arbitration） |
由编排者/评审者做最终裁定 |
| 冲突解决 |
角色意见不一致时的处置机制 |
| 群体思维（Groupthink） |
风险：过度一致、缺乏质疑导致错漏 |
2.6 状态与记忆（State）
| 概念 |
极简说明 |
| 全局状态 |
所有 Agent 可见的共享上下文 |
| 局部状态 |
单个 Agent 私有上下文 |
| 黑板模式 |
以共享内存为中心的协作范式 |
| 状态污染 |
某 Agent 写入错误/越权信息影响全局 |
| 状态膨胀 |
共享上下文无限增长拖慢且费钱 |
2.7 失败模式（Failure Modes）⚠️ 重点
| 概念 |
极简说明 |
对策 |
| 死锁（Deadlock） |
多 Agent 互相等待对方先动 |
设超时、打破循环依赖 |
| 活锁（Livelock） |
不停动作却无进展 |
检测"无进展"并干预 |
| 无限辩论（Infinite Debate） |
反复质疑不收敛 |
硬性轮次上限 + 终止条件 |
| 幻觉传播（Error Amplification） |
一个 Agent 的错误被后续 Agent 当真、放大 |
校验点 + 评审 Agent 拦截 |
| 负向级联（Negative Cascading） |
早期偏差沿链路层层放大 |
关键节点回滚/重做 |
| 协调开销爆炸 |
通信/调度成本超过分工收益 |
先做单 Agent 基线对比 |
| 角色冲突 |
抢活（重复做）或推诿（无人做） |
边界清晰 + 编排者兜底 |
2.8 评估（Evaluation）
| 概念 |
极简说明 |
| 系统级评估 |
看整体任务是否达成，而非单个 Agent |
| 个体评估 |
单独测每个角色的贡献质量 |
| 协作效率 |
token/延迟/成本 vs 单 Agent 的增益 |
| 一致性（Consistency） |
多 Agent 输出是否自洽、不矛盾 |
| 任务成功率 |
端到端完成正确任务的比例 |
| 回归测试 |
改角色/提示后验证不退化 |
2.9 前沿形态（Frontier）
| 概念 |
极简说明 |
| 自我组织（Self-organization） |
Agent 自发形成结构，无需预定义编排 |
| 涌现行为（Emergent Behavior） |
整体表现出个体没有的能力（可好可坏） |
| Agent 网络 / 市场 |
跨系统、跨组织的 Agent 互操作生态 |
| 人类-AI 混合团队 |
人作为其中一个"角色"参与协作 |
三、需要学习的要点（分层路线图）
🟢 基础层（先搞懂，对应原 01）
- 为什么要多 Agent：单 Agent 的瓶颈——上下文太长、角色冲突、难并行、缺独立评审。
- 四种基础编排模式：Hub-and-Spoke / Pipeline / Hierarchical / Debate，能说出各自结构、适合什么。
- 角色设计三原则：职责单一、边界清晰（防抢活/推诿）、系统提示写明"你是谁、不做什么"。
- 两种协作机制：消息传递 vs 共享黑板，各自利弊。
- 成本意识：多 Agent 成本/延迟常是单 Agent 的数倍，先单后多。
- 终止条件：必须有"停"的标准，否则会无限循环/辩论。
🟡 进阶层（能设计中等复杂系统）
- 拓扑选型：除 4 种基础外，理解网状/蜂群，以及"何时该去中心化"。
- 通信范式：同步 vs 异步、黑盒 vs 白盒、自然语言 vs 结构化；知道 A2A 协议的存在与定位。
- 共识机制：投票/协商/仲裁怎么选；警惕群体思维——要保留"唱反调"的 Agent。
- 任务调度：用 DAG 表达依赖；并行独立子任务；负载均衡。
- 失败模式识别：能预判死锁/活锁/幻觉传播，并在设计里加超时、校验点、评审拦截。
- 状态治理：防污染（写权限控制）、防膨胀（定期压缩/摘要）。
- 可观测：记录 Agent 间消息与决策，便于复盘（接
13-进阶/04-可观测性）。
🔴 实战层（能交付可靠系统）
- 决策清单：先做单 Agent 基线 → 只在"确实需要并行/独立评审/超长上下文"时才上多 Agent。
- 角色提示工程：每个 Agent 的 system prompt 要含目标、约束、输出格式、与其他角色的接口。
- 成本与可靠性工程：预算上限、重试/熔断、人在环关键节点（接
13-进阶/05）。
- 评估方法：定义系统级指标，做回归测试，对比单 Agent 基线看是否真有增益。
- 框架选型：
- AutoGen —— 对话式多 Agent，研究/原型快；
- CrewAI —— 角色化"团队"，业务流清晰；
- MetaGPT —— 把软件工程 SOP 注入多 Agent；
- LangGraph —— 有状态、可控的图式编排，生产友好。
- 安全护栏：多 Agent 下权限最小化、沙箱隔离、防止一个被注入的 Agent 污染全局（接
13-进阶/09）。
四、设计自检清单（动手前过一遍）
五、与知识体系其他模块的关联
| 本篇概念 |
关联模块 |
| 编排模式 / Workflow vs Agent |
13-进阶/01-Agent设计模式与工作流 |
| 通信 / A2A / 共识 |
13-进阶/06-多智能体进阶（更深入） |
| 角色提示 / system prompt |
13-进阶/03-高级提示工程 |
| 调度 / 状态 |
04-记忆系统（共享记忆） |
| 失败模式 / 成本 |
13-进阶/05-可靠性与成本工程 |
| 可观测 / 评估 |
13-进阶/04-可观测性与LLMOps、08-评测框架 |
| 安全护栏 |
09-安全与护栏、13-进阶/09-安全实战OWASP |
六、参考资料
- "MetaGPT: Meta Programming for Multi-Agent Collaborative Framework"（2023）
- "Improving Factuality and Reasoning through Multiagent Debate"（2023）
- "Communicative Agents for Software Development"（ChatDev）
- AutoGen / CrewAI / MetaGPT / LangGraph 官方文档
- Google, "Agent2Agent (A2A) Protocol" 草案
- Anthropic, "Building Effective Agents"（多 Agent 审慎使用建议）
评论
评论加载中…