六、多智能体系统 Multi-Agent

多智能体的本质是用组织架构换取单个模型在上下文、角色和并行度上的突破。这一章既考协作模式、通信与 Handoff 等设计功底，也隐含考察一个工程判断力：什么时候不该上多 Agent。

64. 什么场景真的需要多 Agent？单 Agent + 好工具能不能解决？说说你的判断标准。

高频 · 中等

参考答案

结论：大多数业务一个 Agent + 好工具就够。多 Agent 的真实价值集中在三个瓶颈：上下文隔离、专业分化、并行加速——判断标准就是看是否真的踩到这三个瓶颈。

单 Agent 够用（绝大多数场景）：任务线性、工具十几个以内、单会话上下文装得下。典型如知识库问答、数据分析、客服、各类 Copilot。

真的需要多 Agent 的信号：

1. 上下文污染：任务链长（几十上百步），中间产物堆积撑爆上下文，或相互干扰（代码检索的碎片污染写作上下文）。拆成多 Agent 各持干净上下文，只交换结论；
2. 角色 / 提示词冲突：一个 Prompt 同时要求"批判性审查"和"共情陪伴"会互相打架，拆成生成者 / 审查者各用各的系统提示词，效果明显更好；
3. 可并行：任务可分解为独立子任务（多源调研、批量文档处理），并行把墙钟时间从"各步之和"降到"最慢分支"；
4. 权限隔离：子任务需要不同权限或沙箱（只读研究 vs 可写执行），用 Agent 边界做权限边界。

反向校验（成本视角）：多 Agent 带来 N 倍模型调用、Handoff 信息损耗、编排与调试复杂度。经验做法：先做单 Agent，遇到具体瓶颈再拆。面试里能讲出"我们砍掉了多 Agent、换成一个 Agent 加子任务循环"反而是加分项。

面试官可能追问

• 单 Agent 上下文要爆，除了拆 Agent 还有什么办法？（摘要压缩、外置记忆、子任务独立会话处理完只回传结论——后者本质是轻量多 Agent）
• 多 Agent 会让效果一定更好吗？（不会：信息在交接中损耗，弱环节错误被下游放大，组织不当就是负优化）

65. 多 Agent 有哪些常见协作模式？（Supervisor、Pipeline、辩论、分层）各自适合什么任务？

必刷 · 中等

参考答案

四种主流模式，按控制权集中度排：

• Supervisor（主管模式）：一个 Supervisor 负责拆解、分派、验收，Worker 各司其职，结果回传后由 Supervisor 决定"完成 / 重做 / 追加任务"。适合子任务异质、需动态调度的场景。优点是控制点集中、好加 HITL；缺点是 Supervisor 既是吞吐瓶颈又是单点，它的规划质量决定上限。LangGraph 的 supervisor 模板、CrewAI 的 hierarchical 模式属于这类；
• Pipeline（流水线）：固定拓扑，上游产出即下游输入（写作 → 审校 → 排版）。适合流程稳定、可标准化的大批量任务。确定性强、易测试、延迟可预估；灵活性差，且某环质量差会向下游传播（Garbage In, Garbage Out）；
• 辩论（Debate）：多个 Agent 就同一问题独立作答、互相批驳，多轮后收敛或由裁判汇总。适合答案质量优先于成本的判断型任务：事实核查、代码评审、方案评审。经验值：2~3 个 Agent、1~2 轮辩论后收益快速递减，成本却是 Agent 数 × 轮数线性增长，要用在刀刃上；
• 分层（Hierarchical）：Supervisor 的递归版——中层 Manager 各带一支子团队，顶层只管目标与验收。适合任务规模单层调度不动，或天然按业务域分层（调研组 / 开发组 / 测试组）。MetaGPT 的"软件公司"（产品经理 → 架构师 → 工程师 → QA）本质是分层 + 流水线。

选型经验：默认从 Supervisor 起步（最通用），流程固化后沉淀成 Pipeline 省钱省心；辩论只留给高价值判断题；规模失控再分层。生产系统常见"Pipeline 为主 + 关键节点嵌辩论"的混合形态。

面试官可能追问

• Supervisor 怎么判断子任务完成了？（结构化验收标准：Worker 回传带状态和产出的结构化结果，Supervisor 按清单校验，不靠模型感觉）
• 辩论为什么能收敛？（多轮后立场互相吸收趋同，且通常有轮数上限 + 裁判强制收敛，防止为辩而辩）

66. Agent 之间怎么通信？自然语言、结构化消息、共享状态各有什么优缺点？

高频 · 中等

参考答案

三类载体各有定位：

• 自然语言消息：表达力最强，接收方（也是 LLM）天然能懂。缺点是无 Schema 保证——字段缺失、歧义、格式漂移全靠模型"悟"，不可校验、不可测试。适合探索期和低关键性的协调性对话；
• 结构化消息：JSON / Pydantic 定义契约（sender、task、result、status），可校验、可序列化、可测试。缺点是表达力受限，复杂推理过程塞不进固定字段——常用解法是"结构化壳 + 自然语言芯"，result 里分 summary 和 detail 两层。适合正式的任务交接（Handoff）和结果回传；
• 共享状态（blackboard）：所有 Agent 读写同一份状态对象（LangGraph 的 State、或共享内存 / 数据库）。优点：全局一致、无需逐跳转发、状态持久化后天然支持断点恢复；缺点：并发写冲突、状态结构变更是全局影响、谁都写导致责任不清。适合流水线 / 图式编排和需要人机协同暂停恢复的场景。

选型经验：编排层用结构化 + 共享状态保可靠，语义层用自然语言保表达力。典型组合：共享 State 存"事实"（任务清单、各步产物指针），消息带自然语言"论述"加结构化"结论与状态码"。通信内容要最小化：传结论和引用，不传全量中间过程，控制上下文膨胀。

面试官可能追问

• 共享状态的并发写怎么处理？（按字段划分写权限、用 reducer 合并更新（LangGraph 的做法），或加版本号乐观锁）
• Agent 间通信和人与 Agent 通信的本质区别？（前者可以强契约，后者必须容错；别把对用户输入的宽松处理习惯带进 Agent 间通信）

67. 多 Agent 系统的成本和延迟怎么控制？什么情况下"多 Agent"反而是负优化？

中频 · 较难

参考答案

成本来源：Token 是层层放大的——每个 Agent 各有系统提示词和工具集，中间产物在 Agent 间复制传递，轮数 × Agent 数是乘法关系。一个 5 Agent、每 Agent 3 轮的流程，模型调用轻松 15~30 次，总成本达到单 Agent 单轮的 10 倍以上。

控制手段：

1. 模型分级：编排与判断用强模型，Worker 的机械步骤（抽取、格式转换）用小模型，重复步骤走缓存。经验上分级能省约 50% 成本；
2. 上下文最小化：Agent 间只传结论和引用，不传全量原文；每个 Agent 的工具集按角色裁剪；
3. 并行化：独立子任务并发，总延迟 ≈ 最慢分支而非各步之和；
4. 流程固化降级：跑稳的流程从"每步问模型"降级为确定性 Pipeline / 代码，模型只留在真正需要判断的节点；
5. 缓存与短路：相同子任务结果走语义缓存；低风险节点跳过审查 Agent；
6. 预算硬限制：单任务 Token / 调用数 / 时长上限，超限熔断——这是多 Agent 上线的必要护栏。

负优化的典型信号：

• 效果没升甚至下降（信息在多次 Handoff 中损耗，弱 Agent 的错误被下游放大）；
• 成本 5~10 倍于单 Agent，成功率只提升个位数百分点；
• 排查一个 bad case 要翻 5 个 Agent 的轨迹；
• 大部分子任务是确定性的，根本不需要 LLM 决策。

一句话：多 Agent 买的是上下文隔离与并行，卖的是信息保真度。任务单上下文装得下、又无可并行结构时，多 Agent 几乎必然负优化。

面试官可能追问

• 怎么预估多 Agent 成本？（离线跑标注任务集，统计每 Agent 平均输入 / 输出 Token × 单价 × 轮数，加约 30% 重试余量）
• 有没有省钱的结构性做法？（子任务独立会话 + 共享系统提示词和工具结果的 prompt caching，能显著压低重复前缀成本）

68. Agent 之间意见冲突或任务死锁怎么处理？需要引入仲裁或投票机制吗？

中频 · 较难

参考答案

先分类再治理。冲突分三类，死锁另算：

• 事实类冲突（两个检索 Agent 给出不同数据）：不投票，回到源头——要求冲突方给出数据来源与时间戳，按数据可信度排序（权威源 > 推断），以工具 / 数据为准；
• 判断类冲突（方案 A vs 方案 B）：需要收敛机制。常用：① 裁判 Agent（更强模型 + 明确评审标准）裁决并给理由；② 简单投票（Agent 立场真正独立时有效）；③ 升级人工（HITL），高代价决策必须保留这条路。经验：有明确评审标准的裁判优于裸投票——LLM Agent 之间常同源（同底座模型、相似提示词），错误是相关的，独立性不足时票数不代表正确；
• 资源 / 流程冲突（两个 Agent 抢写同一数据）：这是架构问题不是智能问题——写操作加锁 / 排队，职责划分保证同一资源单一 Owner。

死锁与活锁的治理（A 等 B 的结果、B 等 A 的确认，或互相推诿"这不是我的任务"）：

1. 全局超时 + 熔断：每个任务、每次等待都有 deadline，超时升级给 Supervisor 或人；
2. 责任显式化：任务分派带唯一 Owner 和完成标准，拒绝执行必须显式拒绝并给理由，禁止静默不响应；
3. 拓扑检查：依赖图有环（A 依赖 B、B 又依赖 A）在编排期就拒绝，不等运行时卡死；
4. 重试上限与降级：冲突轮数超限（如辩论 3 轮）强制收敛，规则从"达成一致"降级为"记录分歧、按默认策略执行"。

要不要仲裁：要，但作为兜底而非常规路径——常规冲突应靠设计期消除（职责不重叠、单一数据源），运行期仲裁只接住漏网的。

面试官可能追问

• 多数投票在 LLM Agent 上为什么打折？（Agent 独立性弱：同底座、相似提示词，系统性偏差投票消不掉）
• 裁判 Agent 也错了怎么办？（换更强模型、细化评审标准、要求逐条给理由，关键决策升级人工）

69. Handoff（交接）机制怎么设计？交接时上下文怎么传递、怎么裁剪才不丢关键信息？

中频 · 中等

参考答案

Handoff 是一个 Agent 把任务控制权转给另一个 Agent 的机制。OpenAI 的 Swarm 实验框架是教科书实现：Agent 声明在什么条件下转给谁，函数返回下一个 Agent 即完成交接（这一思想后被 OpenAI Agents SDK 的 handoffs 原语产品化）；客服转专员、转人工、Claude Code 的 subagent 委派，本质都是 Handoff。

设计要点：

1. 触发条件显式化：什么情况必须交接（超出能力边界、权限不足、用户明确要求）写进系统提示词或由分类器判断，不靠模型"感觉"；
2. 交接包结构化：用 Pydantic 定义 schema，至少包含——任务目标、已完成步骤摘要、关键决策及理由、当前阻塞点、用户约束与偏好、下一步建议。可校验、可测试；
3. 上下文传递与裁剪：全量历史照搬是最常见错误（又贵又淹重点）。策略是"结论全传、过程摘要、原文按需"：结构化结论（订单号、已确认的约束）完整传递；中间过程压成几条摘要；长文档只传引用 / 指针，接收方需要时自己取。两类信息绝不能裁：用户亲口说的约束与偏好、影响后续决策的事实结论；
4. 接收方确认：新 Agent 先复述任务理解（"我确认一下：您要……"），错位第一步就暴露，这是性价比最高的设计；
5. 可回退：交接记录入轨迹，接错了能退回原 Agent 或升级人工。

验收：Handoff 质量单独评测——只给交接包，看接收 Agent（或人）能否不追问就继续任务。这个指标比整体成功率更能定位交接层的问题。

面试官可能追问

• 交接后原 Agent 的会话还保留吗？（保留为可回退的审计轨迹，但不再注入新 Agent 上下文，避免重复计费和信息污染）
• 多级 Handoff（A→B→C）怎么防信息漂移？（以结构化交接包为准、避免层层自然语言转述，关键约束字段端到端透传）

70. 介绍一个你了解的多 Agent 框架或案例（AutoGen、MetaGPT、CrewAI 等），说说它的设计亮点和局限。

低频 · 较难

参考答案

主推一个讲深，其余带过：

AutoGen（微软）——对话驱动编排。亮点：核心抽象极简，Agent 之间互相发消息（GroupChat 可配 manager 负责路由），UserProxy 内置代码执行与人工介入，人机混在同一对话流里，研究原型效率极高；0.4 版重写为异步事件驱动架构后工程性更好。局限：自由对话式的轮数与上下文难控、成本高、确定性不足，生产上通常要自己再包一层编排和护栏。

MetaGPT——SOP 驱动的软件公司模拟。亮点：把人类组织的标准作业程序编码进多 Agent 流程（产品经理 → 架构师 → 工程师 → QA），强调产出结构化中间制品（PRD、设计文档）而非自由聊天，以文档为信息载体降低交接损耗，一条命令能跑出小型项目。局限：对软件公司场景过拟合，流程重、定制成本高；中间制品不规范时下游连锁劣化。

CrewAI——角色化团队协作。亮点：Role（角色 / 目标 / 背景故事）、Task、Crew 为一等公民，支持 hierarchical 模式自动规划分派，概念直观上手快。局限：抽象较简单，条件分支、循环、人机协同断点这类复杂控制流不如图式编排表达力强。

OpenAI Swarm：极简概念验证（Agent + Handoff 两个原语），官方定位是实验 / 教学框架而非生产框架，适合学 Handoff 思想。

选型一句话：研究原型 AutoGen；SOP 明确的成套流程 MetaGPT / CrewAI；要精细控制流与人机协同，用 LangGraph（严格说是图编排框架而非多 Agent 专用）。

面试官可能追问

• 为什么很多团队最后不用框架、自己写编排？（多 Agent 编排核心就是一个循环加消息路由，框架抽象与业务控制流不匹配时，自研的可控性和可调试性更好）
• LangGraph 与这些框架的本质区别？（它提供图 / 状态机层的编排原语，Agent 只是图上节点，控制流由开发者显式定义而非框架隐式决定）

71. 多 Agent 系统怎么评估？单个 Agent 好测，整体涌现出来的行为怎么测？

低频 · 较难

参考答案

分层评估 + 专项盯涌现行为，这是多 Agent 评估与单 Agent 的本质区别：

分层框架：

1. 单 Agent 层：每个 Agent 有独立评测集（该接的任务接住没、工具用对没），保证零件合格——零件不合格，整体测试没有意义；
2. 交互层（链路级）：固定其他环节，测关键交接点——Handoff 包完整率、路由准确率、消息 Schema 违规率，指标化后可回归；
3. 端到端层：任务成功率（按验收清单达成目标，而非"没报错"）、总成本、总延迟、人工干预率；
4. 系统行为层（涌现行为）：整体才有的属性——死锁 / 活锁发生率、辩论轮数分布、成本长尾（p99 是否失控）、权限越界次数、任务漂移率（最终产出偏题）。

涌现行为的测法：

• 大规模轨迹模拟：跑成百上千个任务，对轨迹做统计画像（步数分布、工具调用分布、消息长度分布），死锁和漂移会以分布异常的形态暴露；
• LLM as Judge 审轨迹：让更强模型按检查表审完整轨迹（有无推诿、信息丢失、违反角色），定位问题环节，人工抽检校准 Judge 的偏差；
• 混沌 / 对抗测试：故意注入坏输入（某 Agent 返回错误结果、超时、拒绝任务），看系统是自愈、卡死还是级联失败——鲁棒性是多 Agent 最容易翻车的地方；
• 不变式断言：定义系统不变式（"写操作前必须有对应读操作""总轮数 ≤ N""敏感数据不出沙箱"），运行时持续断言，违反即告警。这是把"涌现行为"变成可测属性的关键手段。

回归策略：多 Agent 里改一个提示词可能改变全局行为，任何改动都要跑全量端到端回归，并做轨迹 diff（对比改动前后走了什么路径）。

面试官可能追问

• 端到端成功率低，怎么定位是哪个 Agent 的问题？（先看交互层指标哪个交接点异常，再下钻该 Agent 的单测，轨迹回放辅助）
• LLM as Judge 审轨迹可靠吗？（有位置 / 长度偏差，需检查表约束 + 人工抽检对齐，Judge 模型应强于被测系统）

72. 群体智能（Swarm）和层级式（Hierarchical）多 Agent 架构的区别？各自适合什么规模？

低频 · 较难

参考答案

根本区别是去中心化 vs 中心化：Swarm 靠简单规则的局部交互涌现全局智能，Hierarchical 靠显式的管理与分解结构达成目标。

Swarm（群体智能）：

• 结构：大量同质（或少量异质）Agent，无中央控制，靠简单局部规则交互（刺激-响应、信息与"信息素"式的正反馈，经典生物隐喻是鸟群蚁群）；
• 优点：天然可扩展（加 Agent 即扩容）、鲁棒（无单点，挂掉一批不影响整体）、自组织适应动态环境；
• 缺点：行为不可解释、任务保证弱——只能收敛到"足够好"，无法保证精确达成指定目标，调试归因困难；
• 适合规模与场景：几十到上千 Agent 的大规模群体任务——分布式搜索与覆盖、大规模信息收集、社会 / 市场模拟仿真。注意与 OpenAI 的 Swarm 框架重名：那是中心化的 Handoff 路由编排，不是群体智能，面试中主动澄清这点是加分项。

Hierarchical（层级式）：

• 结构：树状——顶层定目标并分解，中层 Manager 规划调度，叶子 Agent 执行，结果逐层汇聚验收（Supervisor 模式即只有一层的层级式）；
• 优点：任务可保证（验收标准逐层下发）、可解释可审计（责任链清晰）、易加人机协同（管理层插确认点）、与人类组织对齐便于管理；
• 缺点：上层是瓶颈和单点（顶层决策错全局错）、层级间信息损耗、规模受管理跨度限制——经验值单层管 5~10 个下属 Agent，再多就要加层，层深了延迟与失真加剧；
• 适合规模与场景：几个到几十个 Agent、目标明确且要交付保证的任务——软件公司模拟（MetaGPT）、复杂项目执行、企业级工作流。

选型判断：要"涌现的发现"（搜索、探索、模拟）用 Swarm；要"可靠的交付"（工程、项目、业务流程）用层级式。生产系统绝大多数是层级式或其扁平化变体；纯 Swarm 多见于研究与模拟，工程落地常取折中——分层组织 + 层内同质 Agent 并行。

面试官可能追问

• 为什么生产系统很少用纯 Swarm？（业务要确定性交付与可归因，Swarm 的不可解释性和弱保证与工程诉求冲突）
• 层级式上层决策错误会被放大，怎么缓解？（管理层加验收校验与 HITL 确认点、关键分叉多方案并行评估、底层保留异常上报通道）