多智能体系统
为什么需要多智能体
多智能体系统（MAS）指多个相对独立的 Agent（通常每个绑定不同角色、工具或策略）在某种 协作协议 下共同完成复杂任务。与「一个通用大模型 + 长提示词」相比，多 Agent 强调 分工、通信、状态与治理。
单 Agent 的常见瓶颈：
| 问题 | 现象 | 通俗说法 | 技术含义 |
|---|---|---|---|
| 注意力漂移 | 提示词越长，模型越「抓不住重点」 | 长上下文下，关键约束与中间推理步骤被稀释；模型对中间段落的有效利用弱于首尾（与架构与训练有关，常被称为 lost in the middle 类问题） | |
| 推理链断裂 | 一步想太多，后面忘了前面 | 复杂任务需要多步规划与回溯；单轨迹里若缺少外部结构化记忆，易出现自相矛盾或跳步 | |
| 能力局限 | 「一个全能选手」往往样样稀松 | 单一 system prompt 难以同时覆盖：严谨规划、创意发散、代码执行、合规审查；工具权限也难以「全开」而不失控 |
多 Agent 的优势
- 专业化分工（Specialization）：每个子 Agent 有窄而深的职责（如「只写测试」「只做威胁建模」），提示词与工具集可更小、更稳。
- 并行处理（Parallelism）：无强依赖的子任务可并行调用模型或工具，缩短墙钟时间（需注意成本与速率限制）。
- 容错与隔离（Fault tolerance）：某一子 Agent 失败可重试、替换实现或降级策略，避免整系统一次失败全盘重来。
单 Agent 和多 Agent 的本质区别是什么？什么时候该上多 Agent？
本质区别不在「调几次模型」，而在 是否显式建模角色、通信与治理。
单 Agent 适合：任务边界清晰、工具少、强实时、成本极度敏感的场景。
多 Agent 适合：任务可分解、需要不同专业视角、需要并行、需要权限隔离（例如代码执行与对外发布分离）、需要可观测的分阶段产出 的场景。
多 Agent 会不会更贵？
通常 Token 与调用次数上升，但若通过 小模型子任务 + 大模型仲裁、并行缩短时间、减少无效重试，总成本未必更高，需要按业务度量。
什么是「注意力漂移」？多 Agent 如何缓解？
注意力漂移指模型在长上下文或多目标提示下，对关键约束的关注度下降，导致输出偏离要求。
多 Agent 缓解方式包括：拆分子目标使每个子上下文更短；专职角色减少单提示中的目标数量；中间结果结构化（JSON/状态机）减少自然语言堆砌。
多 Agent 的「容错」具体怎么体现？
体现为 失败隔离 + 可替换性：例如审查 Agent 发现实现 Agent 的代码不合规，可打回重写而不污染主对话；执行 Agent 沙箱崩溃可只重启该步骤。工程上常配合 重试、指数退避、断路器、降级模板。
三大协作模式
协作模式描述 谁说了算、信息怎么流、何时并行/串行。
常见三类：
- 中心化（Boss-Worker）
- 流水线（Pipeline）
- 民主讨论（Joint Discussion）
- 中心化模式（Boss-Worker）
- 结构：一个 Planner / Manager 负责任务分解、分配与汇总；多个 Worker 执行子任务。
- 优点：决策路径清晰，易做权限与审计（Boss 可统一批准工具调用）。
- 风险：Boss 成为瓶颈与单点；Boss 若规划错误会放大到全局。
- 流水线模式（Pipeline）
- 结构：Agent (A \rightarrow B \rightarrow C)，上游输出作为下游输入（可加质检环）。
- 优点：适合 文档/数据处理、固定 SOP；易测试每段 I/O。
- 风险：错误逐级传递；难以处理需要「回到第一步重想」的大改动（需显式 反馈边）。
- 民主协作模式（Joint Discussion）
- 结构：多个对等 Agent 多轮发言，可能由 协调者 仅负责流程而非内容独裁。
- 优点：适合 头脑风暴、策略博弈、多角度审稿。
- 风险：易 空转与重复；若无终止条件会 Token 爆炸；需要 投票/仲裁（见第 5 节）。
Boss-Worker 和 Pipeline 有什么本质差异？
Pipeline 强调 固定的阶段顺序与数据形态；
Boss-Worker 强调 动态任务图——Boss 可按需增删子任务、并行派发。
Pipeline 更像工厂流水线；Boss-Worker 更像项目经理排期。
通信机制
通信机制决定 Agent 之间 如何交换信息与引用共享事实。
常见四类：
- 直接消息
- 共享黑板
- 发布-订阅（Pub-Sub）
- 消息队列
| 机制 | 核心思想 | 典型优点 | 典型缺点 |
|---|---|---|---|
| 直接消息 | A 显式发给 B（点对点） | 简单、易追踪 | N² 连接复杂；需知道对端地址 |
| 共享黑板（Blackboard） | 公共读写区，各 Agent 读全局、写局部 | 解耦「谁知道谁」 | 并发写需锁/版本；易成「垃圾堆」 |
| Pub-Sub | 主题广播，订阅者自选感兴趣事件 | 扩展性好 | 主题设计不好会混乱；需保留顺序时更复杂 |
| 消息队列 | 先入先出（或可优先级），异步解耦 | 削峰、重试、持久化 | 延迟增加；需死信与幂等设计 |
选型提示：
强审计、强顺序、高吞吐 → 队列；
探索式协作、快速原型 → 黑板；
简单多角色 → 直接消息。
消息队列补充（小白向）：
可以把队列理解成 带收件箱的任务管道。生产者 Agent 把「任务描述、载荷、关联 trace_id」入队；消费者 Agent 异步取出执行。生产环境常需要：持久化（重启不丢）、重试与死信队列（失败可人工排查）、幂等键（防止重复消费导致重复下单等）。与 Pub-Sub 的差别：队列通常 点对点消费一条消息（或竞争消费）；Pub-Sub 常是 多订阅者各拿一份副本，更偏广播。
黑板模式和消息队列有什么相似与不同？
相似：都 解耦发送方与接收方。
不同：黑板通常是 共享状态容器（读最新快照），强调 协作求解；
队列是 事件/任务的管道，强调 可靠投递、顺序、削峰。
黑板更像「会议室白板」；队列更像「工单系统」。
任务分配策略
任务分配决定「这个子任务交给谁」。常见：按能力、按负载、动态调整、竞拍。
- 基于能力的分配（Skill-based）：为 Agent 声明 能力标签（如 python、security_review），调度器做 匹配度打分。
- 基于负载的分配（Load-based）：看队列深度、进行中任务数、最近失败率，把任务给 最空闲且健康 的执行器。
- 动态任务分配：运行时根据中间结果 改派（如发现需要法律审查则插入新 Agent）。
- 竞拍机制（Contract Net / Auction）：任务广播 招标，Agent 按 报价（成本、ETA、置信度）竞标，Boss 选标。适合 异构资源 与 多候选执行者。
动态任务分配和固定 Pipeline 各适合什么场景？
固定 Pipeline 适合 SOP 稳定、输入输出契约清晰（如审核流水线）。
动态分配适合 探索性任务（研究、故障排查），中间可能发现新子问题。
工程上常 混合：主干 Pipeline + 动态插入节点。
冲突解决
多 Agent 可能对 同一问题给出矛盾结论（例如「能上线」vs「有高危漏洞」）。冲突解决机制用于收敛到可执行决策。
| 冲突解决方法 | 做法 | 适用 |
|---|---|---|
| 投票 | 多数票或加权票 | 意见独立、噪声可平均的场景 |
| 优先级仲裁 | 规则：安全 > 产品 > 体验 | 合规、强约束领域 |
| 主席 Agent | 指定角色做最终拍板 | 需要单一责任点 |
| 基于证据的共识 | 必须引用日志、测试结果、CVE 编号等 | 技术决策、审计要求高 |
状态管理与同步
状态包括任务进度、共享事实、用户约束、工具中间结果等。同步指多 Agent 并发读写时保持一致性与可恢复性。
- 全局状态共享：单一 Source of Truth（如数据库行 + 版本号），各 Agent 只通过 API 更新，避免各自复制矛盾副本。
- 状态机管理：任务阶段用 显式状态（PLANNING → CODING → REVIEW → DONE），非法迁移拒绝执行，利于 断点续跑。
- 事件驱动：状态变更以 事件 发布（可与 Pub-Sub/队列结合），Agent 订阅自己关心的事件，而非轮询黑板。
多 Agent 系统为什么推荐状态机而不是纯自然语言传递一切？
自然语言灵活但 难校验、难回放、难测试。
状态机提供 可验证迁移、清晰终止、可观测指标（卡在何阶段多久）。自然语言可作为 附件说明，不应是唯一真相来源。
主流多 Agent 框架
| 框架 | 背景/特点 | 典型适用 |
|---|---|---|
| AutoGen（微软） | 对话型多 Agent、可与人协作；强调 可定制 Agent 与聊天模式 | 研究原型、对话式工作流 |
| CrewAI | 角色（Role）+ 任务（Task）+ 团队（Crew） 抽象较贴近「项目组」叙事 | 快速搭建「岗位分工」类 Demo |
| MetaGPT | SOP/公司角色 隐喻强（PM/架构/工程师），偏 软件工程过程仿真 | 代码生成流水线、教学 |
| ChatDev | 虚拟软件公司 多阶段聊天驱动开发 | 学术/实验、流程可视化 |
| LangGraph 多 Agent | 基于 图 与 状态 的编排，和 LangChain 生态结合；强调 可控循环与检查点 | 生产级需要可恢复、可调试的流程 |
对比维度（面试可用）：编排模型（图/对话/层级）、状态与持久化、人机协作、生态与供应商锁定、可观测性、学习曲线。
AutoGen 和 LangGraph 多 Agent 有什么气质差异？
AutoGen 偏 对话与多角色交互 的快速组合；
LangGraph 偏 显式图状态机 与 检查点/分支。
若强调 生产可恢复与审计，LangGraph 往往更易 形式化；
若强调 探索式对话与人机混合，AutoGen 叙事更自然。