45 KiB
Multi-Agent与Multi-Task编排架构
来源：知乎专栏 抓取时间：2026-06-03 22:39
Multi-Agent 与 Multi-Task 编排架构
定位：Staff/Architect 面试中「多智能体协作」与「多任务并行调度」的 专题深潜。区分 Multi-Agent（多个"谁"）与 Multi-Task（多个"什么"），覆盖拓扑模式、通信协议、任务 DAG、状态共享、成本建模与生产反模式。 不重复：框架选型见 04；12 能力域见 13；七视图与成熟度 Stage 见 27；Buy 领域落地见 18。 DevEx 对照：Cursor Subagent / Fork / Resume 与本篇 Coordinator/Supervisor 的映射 → 06。 工业级索引：编排/Token/多任务场景 → 96 §2.6–§2.7 · 深读索引（MA_* / MT_* / CTX_*）。 风格：沿 L1 概念 → L2 原理 → L3 生产 → L4 Staff 答辩 四层递进；每层有 ⚠ 难点 / 🔥 高频 / 💀 陷阱 标注。
- 本篇注意点与核心难点速查
面试前 3 分钟过一遍此表，定位薄弱项。
难点 / 注意点 为什么难 对应章节 🔥频率
1 Multi-Agent vs Multi-Task 概念混淆 面试官常故意混用，需 30s 内澄清 §1 ★★★★★ 2 拓扑选型说不出 trade-off 只知道 Supervisor，不知 Hierarchical/Peer/Swarm 差异 §2 ★★★★ 3 Coordinator token 爆炸 N 个 Worker × R 轮 → context 超窗口 → 幻觉 §5, §6 ★★★★★ 4 Fan-out 写操作一致性 并行写 → 重复退款/发货；需 DAG + 幂等 + Saga §3, §7 ★★★★★ 5 何时上 Multi-Agent 的准入判断 很多人跳 Stage 1 直上多 Agent → 成本翻倍、completion 下降 §2.4, §9 ★★★★ 6 A2A vs MCP 分不清 两者都是协议，但层次和解决问题不同 §4 ★★★ 7 跨 Agent 可观测 trace 断裂 每个 Agent 独立 trace → 无法端到端归因 §8 ★★★★ 8 Multi-Agent Memory/Context 共享边界 过度共享 → token 爆炸；过度隔离 → 信息断层 §5 ★★★★ 9 动态 Agent 编排（Swarm/OpenAI Agents SDK） 新范式 vs 传统 Supervisor，何时用 §2.5 ★★★ 10 Multi-Agent 测试与 Eval 单 Agent eval 不够，需协调质量+端到端+收敛性 §9 ★★★★
- 概念辨析：Multi-Agent vs Multi-Task 1.1 定义对比 🔥 维度 Multi-Agent（多智能体） Multi-Task（多任务） 定义 多个具备独立 Prompt/工具/角色 的 Agent 协作完成目标 多个子任务被分解、调度、并行或依赖执行 关注点 角色设计、通信协议、状态共享、冲突解决 任务分解、依赖图(DAG)、调度策略、结果聚合 独立存在 ✅ 多 Agent 处理同一任务（辩论式验证） ✅ 单 Agent Fan-out 多个 tool calls 交集 多 Agent 各领一个 Task → Multi-Agent Multi-Task Staff 考点 拓扑选型、Coordinator 设计、A2A 协议 DAG 调度、Fan-out/Fan-in、幂等聚合 1.2 四象限模型 ⚠ 单任务 多任务 ┌───────────────┬───────────────┐ 单 Agent │ 标准 Agent │ Fan-out │ │ ReAct 循环 │ 并行 tool │ ├───────────────┼───────────────┤ 多 Agent │ 辩论验证 │ 协作编排 │ │ 红蓝对抗 │ (生产主流) │ └───────────────┴───────────────┘
左上：单 Agent 单任务 → 最简单，Stage 1 起点 右上：单 Agent 多任务 → LangGraph Send API / OpenAI parallel tool calls 左下：多 Agent 单任务 → 用于验证、质量提升（如 Generator + Verifier） 右下：多 Agent 多任务 → 生产级系统，本篇重点 1.3 💀 常见混淆 错误说法 纠正 “Multi-Agent 就是 Multi-Task” 不对，Multi-Agent 是角色维度，Multi-Task 是任务维度 “单 Agent 不能做 Multi-Task” 不对，单 Agent 可以 Fan-out 并行调用多个 tool “Multi-Agent 一定更好” 不对，Coordinator 开销可能让成本翻倍但质量不升 “Pipeline 不是 Multi-Agent” Pipeline 也是 Multi-Agent 的一种拓扑
一句话：Multi-Agent 解决"谁来做"，Multi-Task 解决"做什么和怎么排"。生产系统两者通常同时出现。
- Multi-Agent 拓扑模式（L2 原理） 2.1 六种核心拓扑 2.2 拓扑选型矩阵 🔥 拓扑 适用场景 优势 劣势 典型框架 Supervisor 明确角色分工、可枚举子任务 简单、可控、易审计 单点瓶颈、Supervisor token 开销 LangGraph supervisor node Hierarchical 大规模 Agent 团队、跨域协作 分层管理、局部自治 层间延迟、Manager prompt 复杂 AutoGen GroupChat + nested Peer-to-Peer 辩论/验证、创意头脑风暴 无单点、多视角 难收敛、token 爆炸 CrewAI process off Pipeline 线性流水线（提取→转换→校验） 最低协调开销 无并行、上游阻塞 LangGraph 线性 StateGraph Mixture/Dynamic 请求类型差异大、需动态路由 灵活、按需分配 路由逻辑本身需维护 LangGraph conditional_edges Swarm/Handoff 对话式客服、逐步移交 上下文自然传递、按需升级 回退困难、handoff 条件需精确 OpenAI Swarm / Agents SDK 2.3 Staff 级架构决策树 2.4 准入门槛与 Stage 对齐 ⚠ Stage 拓扑 准入门槛 来源 Stage 1 单 Agent 有 checkpoint + trace 27 §8.1 Stage 2 Supervisor / Pipeline 单 Agent eval ≥ 80% 本篇 §9 Stage 3 Hierarchical / Mixture + Workflow 写操作全 HITL 或 Saga 13 §19 Stage 4 Agent Mesh / Swarm 联邦 AI Gateway + 统一 eval 24
💀 反模式：跳 Stage 1 直上 Multi-Agent → 成本翻倍、completion 下。先 Single Agent 优化到极致再加复杂度。
2.5 Swarm / Handoff 模式详解（新范式） 🔥
OpenAI Agents SDK 和 Swarm 框架引入的 handoff 范式与传统 Supervisor 有本质区别：
维度 Supervisor Swarm/Handoff 控制流 中心化：Supervisor 分发 去中心化：Agent 间直接移交 上下文传递 通过 Coordinator state 通过 handoff 携带 conversation history 适用 结构化任务拆分 对话式、意图逐步明确 回退 Coordinator 重新分配 需显式 handoff 回源 Agent 典型场景 退款处理分角色 客服从通用→专业→人工层层升级
OpenAI Agents SDK handoff 示例概念
triage_agent = Agent( name="Triage", instructions="判断用户意图，移交给专业 Agent", handoffs=[order_agent, refund_agent, faq_agent] ) refund_agent = Agent( name="Refund", instructions="处理退款相关问题", tools=[check_order, calculate_refund], handoffs=[human_agent] # 复杂case升级人工 )
⚠ 难点：Handoff 条件不够精确 → Agent 乒乓跳转（A→B→A→B…）；解法：handoff 带 reason + max_handoff_count。
- Multi-Task 编排模式（L2 原理） 3.1 任务分解策略 策略 描述 适用 风险 LLM Plan LLM 自主将目标拆为子任务列表 开放域、用户意图模糊 Plan 漂移、幻觉任务 Template DAG 预定义任务模板 + 参数填充 已知 SOP、资金操作 灵活性低 Hybrid 固定骨架 + LLM 填充可变节点 生产推荐 需 policy guard 防溢出 3.2 任务依赖 DAG 🔥 3.3 Plan 输出结构化 schema ⚠ { "goal" : "处理用户退款请求" , "tasks" : [ { "id" : "t1" , "action" : "query_order" , "agent" : "order_agent" , "deps" : [ ] , "write" : false } , { "id" : "t2" , "action" : "query_profile" , "agent" : "profile_agent" , "deps" : [ ] , "write" : false } , { "id" : "t3" , "action" : "calc_refund" , "agent" : "refund_calc_agent" , "deps" : [ "t1" , "t2" ] , "write" : false } , { "id" : "t4" , "action" : "create_refund" , "agent" : "refund_exec_agent" , "deps" : [ "t3" ] , "write" : true , "hitl" : true } , { "id" : "t5" , "action" : "send_notification" , "agent" : "notify_agent" , "deps" : [ "t3" ] , "write" : true } ] , "constraints" : { "write_tasks_sequential" : true , "max_parallel" : 3 , "timeout_per_task_s" : 30 } }
💀 陷阱：Plan 中 write: true 的任务如果没有标 hitl 且没有幂等键 → 重复执行风险。
3.4 并行调度：Fan-out / Fan-in ┌─→ Task A ──┐ User Request → Plan ├─→ Task B ──┼─→ Merge → Respond └─→ Task C ──┘
组件 职责 实现要点 Plan 拆分子任务、声明依赖 输出结构化 JSON（见 §3.3 schema） Scheduler 按依赖图调度、并行无依赖任务 拓扑排序 + asyncio.gather / thread pool Worker 执行单任务、返回结构化结果 幂等、超时、重试、输出 schema 固定 Merger 聚合结果、冲突解决 reduce 函数；冲突时 escalate 给 Supervisor 3.5 任务状态机 3.6 Replan 策略 ⚠ 触发条件 策略 风险 单 task 失败且 retry exhausted 跳过该 task + 调整下游依赖 信息不完整 多 task 并行结果矛盾 Coordinator 仲裁或增加验证 task 增加轮数 用户中途改变目标 清除未执行 task，基于新 goal replan plan 膨胀 Plan 漂移（goal 偏移检测） 比对 goal embedding 相似度 < 阈值 → 拒绝 误报
💀 陷阱：Replan 不受限 → 无限 replan 循环。必须设 max_replan_count ≤ 3。
- Agent 间通信协议（L2 原理） 4.1 四种通信范式 范式 描述 延迟 耦合度 适用 Direct Call Agent A 同步调用 Agent B 低 高 同进程、Pipeline Message Bus 通过队列/事件异步通信 中 低 跨服务 Multi-Agent Shared State 通过共享 checkpoint/黑板写读 中 中 LangGraph StateGraph Handoff Agent A 将控制权+context 移交 Agent B 低 中 对话式 Swarm 4.2 A2A（Agent-to-Agent）协议 🔥
Google 提出的 A2A 协议为跨组织 Agent 互操作提供标准：
概念 说明 Agent Card JSON 描述 Agent 能力、输入输出 schema、认证方式 Task A2A 的原子单位，包含 input/output/status Streaming SSE 流式返回中间结果 Push Notification 长任务异步回调 Artifact 任务产生的文件/数据，可传递给下游 Agent Agent A ──AgentCard 发现──→ Agent B ──Task 请求────→ ←─SSE 流式结果── ←─Artifact 交付── ←─完成回调──────
4.3 MCP 与 A2A 的关系 🔥 维度 MCP A2A 解决问题 Agent ↔ Tool/Data 的标准接口 Agent ↔ Agent 的互操作协议 类比 USB 接口（连接外设） HTTP/gRPC（服务间通信） 互补 Agent B 可以通过 MCP 暴露自己为 Tool A2A 在上层编排，MCP 在下层连接 认证 MCP Server 需独立鉴权 A2A Agent Card 声明认证方式 状态 无状态（每次调用独立） 有状态（Task 生命周期管理） 4.4 通信 Schema 版本管理 ⚠ 问题 解法 Worker 输出 schema 变更 并存 2 版 30 天 + Coordinator 适配 Agent Card 能力变更 semver + 发现服务自动刷新 Handoff context 格式不兼容 中间层 adapter + 版本协商 5. 状态共享与隔离（L3 生产） 5.1 状态分层模型 🔥 ┌─────────────────────────────────────────┐ │ Global State（共享·Coordinator 单写） │ │ → goal, plan, completed_steps, │ │ current_round, error_summary │ ├─────────────────────────────────────────┤ │ Agent-local State（隔离·各 Agent 写） │ │ → scratchpad, tool_cache, memory │ ├─────────────────────────────────────────┤ │ Task-local State（隔离·单任务写） │ │ → input, output, retry_count, status, │ │ idempotency_key, duration_ms │ └─────────────────────────────────────────┘
5.2 设计原则 原则 说明 违反后果 Single Writer 同一 state key 只有一个 Agent 可写 写冲突、状态污染 Coordinator 持 Plan 只有 Coordinator 可修改 goal / plan Worker 各改 plan → 发散 Structured Observation Worker 返回 JSON，不返回自由文本 Coordinator 解析失败 Checkpoint 租户隔离 tenant_id 行级过滤 跨租户记忆泄漏（见 27 §12） Append-only for Workers Worker 只 append observation，不覆盖 历史丢失、审计断裂 5.3 Context Engineering for Multi-Agent ⚠ 难点
多 Agent 的 Context Engineering 比单 Agent 复杂一个数量级。
层级 策略 实现 Coordinator 滑动窗口 + 摘要 只读最近 N 轮 observation + completed_steps 全量 Worker 最小信息原则 只投递该 Worker 需要的 task context，不给全局 plan 跨 Agent 摘要传递 Agent A 的输出经 summarizer 压缩后再给 Agent B 长期 外部记忆 共享 checkpoint 存 PG，按需检索而非全量加载
Context 压缩示例
def compress_observation(raw_obs: dict) -> dict: """将 Worker 的原始 observation 压缩为摘要""" return { "task_id": raw_obs["task_id"], "status": raw_obs["status"], "key_findings": raw_obs["key_findings"][:3], # 最多3条 "error": raw_obs.get("error"), # 不传递: raw_data, tool_logs, debug_info }
5.4 LangGraph 实现模式 from langgraph.graph import StateGraph from typing import TypedDict, Annotated from operator import add
class MultiAgentState(TypedDict): goal: str # Coordinator 写 plan: list[dict] # Coordinator 写 current_round: int # Coordinator 写 completed_tasks: Annotated[list[str], add] # Workers append-only observations: Annotated[list[dict], add] # Workers append-only（压缩后） final_answer: str # Coordinator 写 error_summary: list[dict] # Coordinator 写
graph = StateGraph(MultiAgentState)
Coordinator node: 读 observations → 更新 plan → 分配下一批 task
Worker nodes: 读 plan 中自己的 task → 执行 → append observation（压缩）
Merge node: 聚合并行结果 → pre-condition 校验 → 交回 Coordinator
5.5 Memory 共享模式 ⚠ 模式 描述 适用 风险 No Sharing 各 Agent 独立 memory Pipeline 信息断层 Blackboard 共享黑板，按 key 读写 Supervisor 写冲突 Event Sourcing 所有 observation 追加到事件流 审计要求高 存储膨胀 Selective Sharing 按 tag 选择性投递 生产推荐 需维护 tag 映射 6. 成本与延迟建模（L3 生产） 6.1 Token 开销分析 🔥 组件 Token 消耗 优化手段 Coordinator 每轮读所有 observations → O(N×T) 摘要压缩、滑动窗口 Worker 仅读自身 task context → O(T) 限制 context window Plan 节点 一次性生成 → O(1) 缓存相似请求的 plan Merge 节点 聚合 N 个结果 → O(N×T) 结构化 reduce 而非 LLM 合并 总开销 单 Agent: T ; Multi-Agent: N×T + Coordinator×R轮 + Merge 控制轮数 R≤5 6.2 并行 vs 串行 Trade-off 维度 串行 Pipeline 并行 Fan-out 延迟 所有 Agent 延迟之和 max(各 Agent 延迟) Token 较少（无 Coordinator） 较多（+Coordinator+Merge） 复杂度 低 高（需 scheduler、超时、部分失败处理） 适用 严格顺序依赖 子任务独立可并行 部分失败 上游失败 → 后续全停 单 Worker 失败 → 降级或 replan 6.3 成本公式 Cost_single = tokens_per_turn × turns × price_per_token Cost_multi = Σ(worker_tokens) + coordinator_tokens × rounds + merge_tokens ROI 准入 = (Quality_multi - Quality_single) / (Cost_multi - Cost_single) > threshold
6.4 容量估算（Staff 白板必会）⚠ 假设： 峰值 Agent QPS = 100 平均每请求拆分 3 个 Worker 任务 每 Worker 平均 1.5k token（输入+输出） Coordinator 每轮 3k token，平均 2.5 轮 Token 单价 $3/1M (GPT-4o)
Worker token/s = 100 × 3 × 1500 / avg_task_duration(3s) = 150k token/s Coord token/s = 100 × 3000 × 2.5 / avg_round_duration(5s) = 150k token/s 总 token/s ≈ 300k $/hour = 300k × 3600 × $3 / 1M = $3,240/hour
对比单 Agent（2k token × 5 轮）： 单 Agent token/s = 100 × 2000 × 5 / 15s ≈ 67k $/hour = 67k × 3600 × $3 / 1M ≈ $720/hour
Multi-Agent 成本约 = 4.5x → 需要 completion 提升 ≥ 15% 才值得
准入规则（来自 27 §11.7）：单 Agent eval ≥ 80% 后再上 Multi-Agent，否则成本翻倍但质量不升。
- 生产反模式与事故（L3 生产） 7.1 反模式清单 🔥
反模式 后果 正确做法
1 无 Coordinator 的 Peer-to-Peer 循环对话、token 爆炸、不收敛 设 max_rounds + Coordinator 裁决 2 Worker 私自修改 Plan 目标漂移、任务重复 Coordinator 单写 plan 3 跳 Stage 1 直上 Multi-Agent Completion 低 + 成本高 单 Agent eval ≥ 80% 准入 4 全 Agent 共享完整 context token 爆炸、O(N²) 按需投递、摘要压缩 5 并行 Worker 无超时 一个慢 Worker 阻塞全局 超时 → 降级/跳过 + Coordinator replan 6 无幂等的写操作 Fan-out 重复退款、重复发货 写操作单线程 + 幂等键 7 Multi-Task 无依赖声明 并行本应串行的任务 → 数据不一致 显式 DAG + 拓扑排序 8 Agent 间自由文本通信 解析失败率高 结构化 JSON schema 9 Handoff 无 max_count Agent 乒乓跳转 A→B→A→B… handoff 带 reason + max_handoff ≤ 3 10 Replan 无上限 无限 replan 循环 max_replan_count ≤ 3 11 Coordinator 无进度检测 连续空转消耗 token 连续 2 轮无新 completed_task → 强制终止 12 Multi-Agent 无独立 eval 不知道 Multi-Agent 是否真的优于单 Agent 对照实验 + eval gate 7.2 STAR-M-P 事故案例 1：Multi-Agent 退款协调失败 🔥 字段 内容 S 电商客服 Multi-Agent 上线：Planner 拆分为"查单→算退款→执行"三个 Worker，无依赖声明，三者并行启动。 T “执行退款” Worker 在"查单"完成前就调用了 create_refund，传入 null 订单 → 退款金额为 0 → 用户投诉。 A ① 补充 DAG 依赖声明；② 写操作 Worker 强制等待前置 task Success；③ 写操作增加 pre-condition 校验（订单非 null）；④ 添加 dry-run 阶段。 R 事故率归零；延迟增加 200ms（可接受）；后续推广到所有写操作 Worker。 M 方法论：Multi-Task 必须显式声明依赖；写操作 禁止无条件并行。 P 推动平台级 Task Scheduler 支持 DAG 拓扑排序 + pre-condition guard。 7.3 STAR-M-P 事故案例 2：Coordinator Token 爆炸 🔥 字段 内容 S 5 个 Worker 每轮返回 2k token observation，Coordinator 每轮读全量 → 第 4 轮 context 超 128k 被截断 → Plan 丢失关键信息 → 幻觉。 T 在不降低 completion 的前提下控制 Coordinator 上下文。 A ① Worker observation 压缩为结构化摘要（≤200 token）；② Coordinator 只读最近 2 轮 + 全局 completed_steps；③ 历史 observation 存 checkpoint，按需检索。 R Coordinator token 从 40k/轮 降至 8k/轮；completion 不降反升（噪声减少）。 M Multi-Agent 的 Context Engineering 是成本和质量的关键杠杆。 P 沉淀 ObservationCompressor 组件，强制 Worker 输出 ≤ schema 上限。 7.4 STAR-M-P 事故案例 3：Handoff 乒乓风暴 字段 内容 S 对话式客服 Swarm 架构，Triage → Order → Refund → Triage → Order… 用户问"退款后重新下单"触发 Agent 间无限 handoff。 T 24h 内止血，防止 token 消耗失控。 A ① 加 max_handoff_count = 5；② handoff 带 reason 字段，重复 reason 触发熔断；③ 超限后自动转人工。 R 乒乓事件从日均 200 次降至 0；用户体验评分持平（转人工后处理）。 M Swarm/Handoff 的收敛性不如 Supervisor，必须有硬上限。 P 平台级 handoff 中间件：全局 count + reason dedup + 熔断。 7.5 STAR-M-P 事故案例 4：Multi-Agent 跨租户状态污染 字段 内容 S 多租户 Agent 平台，两个租户的 Worker 共享了同一个 checkpoint namespace → 租户 A 的 observation 出现在租户 B 的 Coordinator context 中。 T 隔离修复 + 影响面评估 + 合规报告。 A ① Checkpoint 表增加 tenant_id + 行级安全策略（RLS）；② 全量扫描历史 checkpoint 删除越权数据；③ Worker observation 增加 tenant_id 校验中间件。 R 影响 12 个会话，无资金损失。7 天内修复。 M Multi-Agent 的 checkpoint 隔离比单 Agent 更易出问题（多写入源）。 P 平台级 checkpoint 写入层强制 tenant_id；新租户上线前自动化隔离测试。 8. Multi-Agent 可观测性（L3 生产） ⚠ 难点 8.1 跨 Agent Trace 关联 ┌─ trace_id: abc-123 ────────────────────────────────────────┐ │ span: coordinator │ │ ├─ span: fan-out-scheduler │ │ │ ├─ span: worker-order (agent_id: order, task_id: t1) │ │ │ ├─ span: worker-profile (agent_id: profile, task_id: t2)│ │ │ └─ span: worker-risk (agent_id: risk, task_id: t3) │ │ ├─ span: merge │ │ └─ span: worker-refund (agent_id: refund, task_id: t4) │ └─────────────────────────────────────────────────────────────┘
必须的 trace 属性 说明 trace_id 用户请求级，贯穿所有 Agent agent_id 哪个 Agent task_id 哪个 Task round 第几轮 tokens_in / tokens_out 每个 span 的 token 统计 tool_calls 该 span 调用了哪些工具 decision Coordinator 的路由/分配决策 8.2 成本归因 总请求成本 → 按 agent_id 归因 → 按 task_id 归因 → Coordinator 占比 (通常 30-50%) → Worker A 占比 → Worker B 占比 → Merge 占比
8.3 告警规则 指标 阈值 动作 rounds_per_request > 5 收敛不良 降级到单 Agent coordinator_tokens > 50k context 即将溢出 触发压缩 handoff_count > 3 乒乓风险 熔断转人工 task_timeout_rate > 10% Worker 性能问题 扩容或降级 cost_per_completion > budget 超预算 切换小模型
→ 详见 25 AI 可观测性。
- Multi-Agent Eval 体系（L3 生产） 9.1 四层 Eval 🔥 层级 评估什么 指标 工具 单 Agent 每个 Worker 的任务完成质量 accuracy, latency, tool_call_success LangSmith / Braintrust 协调质量 Coordinator 的任务拆分和分配 plan_precision, plan_recall, routing_accuracy 自建 eval dataset 端到端 用户目标是否达成 completion_rate, user_satisfaction A/B test 成本效率 同质量下的 token 消耗 cost_per_completion LiteLLM 统计 收敛性 多少轮达成目标 avg_rounds, timeout_rate, handoff_count trace 分析 9.2 准入 Gate ⚠ ┌─ Stage 1 → Stage 2 准入 ─────────────────────────────┐ │ 单 Agent eval ≥ 80% │ │ 有 checkpoint + trace + 至少 30 条 eval case │ ├─ Stage 2 留存条件 ─────────────────────────────────────┤ │ Multi-Agent eval ≥ 单 Agent + 5% │ │ Multi-Agent cost ≤ 单 Agent × 2 │ │ avg_rounds ≤ 5 │ │ timeout_rate ≤ 5% │ ├─ 不达标 → 自动回退 ────────────────────────────────────┤ │ eval 连续 3 天低于阈值 → 灰度缩量 → 回退单 Agent │ └─────────────────────────────────────────────────────────┘
9.3 Multi-Agent 专属 Eval Case ⚠ 用例类别 测什么 通过标准 Plan 拆分正确性 给定 goal → plan 包含必需 task F1 ≥ 0.9 依赖排序正确性 写操作在前置读操作之后 100% 部分失败降级 1 个 Worker 超时 → 系统仍可返回有意义结果 ≥ 80% Coordinator 收敛 不出现空转（连续 2 轮无新完成） timeout_rate ≤ 5% 跨 Agent 一致性 Worker A 和 B 的 observation 不矛盾 矛盾率 ≤ 2% Handoff 合理性 handoff reason 与用户意图匹配 accuracy ≥ 90% 重复写操作 Fan-out 后无重复 side effect duplicate_write = 0 Replan 正确性 replan 后 goal 不偏移 goal_drift = 0 10. 框架实战对比（L3 生产） 10.1 LangGraph Multi-Agent from langgraph.graph import StateGraph, START, END from langgraph.constants import Send
Supervisor 拓扑
graph = StateGraph(MultiAgentState) graph.add_node("coordinator", coordinator_node) graph.add_node("researcher", researcher_node) graph.add_node("writer", writer_node) graph.add_node("reviewer", reviewer_node)
graph.add_edge(START, "coordinator") graph.add_conditional_edges("coordinator", route_to_worker, {"research": "researcher", "write": "writer", "review": "reviewer", "done": END}) graph.add_edge("researcher", "coordinator") graph.add_edge("writer", "coordinator") graph.add_edge("reviewer", "coordinator")
Fan-out 多任务并行：用 Send API
def fan_out(state): return [Send("worker", {"task": t}) for t in state["plan"] if t["status"] == "pending" and all_deps_met(t, state)]
graph.add_conditional_edges("coordinator", fan_out)
10.2 AutoGen Multi-Agent from autogen import AssistantAgent, GroupChat, GroupChatManager
planner = AssistantAgent("planner", system_message="你负责拆解任务...") researcher = AssistantAgent("researcher", system_message="你负责查询...") coder = AssistantAgent("coder", system_message="你负责实现...")
group_chat = GroupChat( agents=[planner, researcher, coder], messages=[], max_round=10, speaker_selection_method="auto" # 或 "round_robin" ) manager = GroupChatManager(groupchat=group_chat)
10.3 CrewAI Multi-Task from crewai import Agent, Task, Crew, Process
researcher = Agent(role="Researcher", goal="...", tools=[search_tool]) writer = Agent(role="Writer", goal="...", tools=[])
task1 = Task(description="调研竞品", agent=researcher, expected_output="报告") task2 = Task(description="撰写文章", agent=writer, expected_output="文章", context=[task1]) # 显式依赖
crew = Crew(agents=[researcher, writer], tasks=[task1, task2], process=Process.sequential) # 或 Process.hierarchical
10.4 生产选型决策 🔥 场景 推荐 理由 资金写操作 LangGraph checkpoint + interrupt + 幂等 + 显式边 研发探索/Code Review AutoGen 多角色对话自然、快速迭代 内容生产（无写操作） CrewAI Task 依赖声明直观、上手快 对话式客服升级 OpenAI Agents SDK / Swarm handoff 自然、上下文传递好 企业级 Java 栈 Spring AI + 自建 Coordinator 与 Spring 生态集成、事务管理 跨组织 Agent 互操作 A2A 协议 + 任一框架 标准化发现与通信 11. Staff 面试高频题与满分答（L4 答辩）
格式：结论先行 → 原理展开 → 边界/陷阱 → 落地经验 → 反问引导。答题时间标注在题目后。
11.1 Multi-Agent vs Multi-Task 区别？🔥🔥🔥🔥🔥
Q：Multi-Agent 和 Multi-Task 有什么区别？
答（30s）：Multi-Agent 是"多个谁"——多个具备独立角色/提示/工具的 Agent 协作；Multi-Task 是"多个什么"——多个子任务被分解调度执行。单 Agent 可以 Multi-Task（Fan-out tool calls），多 Agent 也可以只处理单一任务（辩论验证）。生产中两者通常同时出现：Coordinator 拆任务（Multi-Task），分给不同 Worker（Multi-Agent）去并行执行。
追问预判：→ 那什么时候用单 Agent Multi-Task 就够了？→ 当 角色 skill 无差异 时，加 Agent 只加成本不加质量。
11.2 什么时候上 Multi-Agent？🔥🔥🔥🔥🔥
Q：什么时候值得用 Multi-Agent？
答（60s）：三个条件同时满足：① 子任务可并行且上下文可隔离——否则共享 context 反而浪费 token；② 角色 skill 差异大——不同 system prompt + 工具集能显著提升各子任务质量；③ 单 Agent completion < 目标——先证明单 Agent 不够再加复杂度。准入门槛：单 Agent eval ≥ 80%，Multi-Agent 必须比单 Agent 至少高 5 个点且成本 ≤ 2 倍。
追问预判：→ 如果 eval 高了但成本超 2x 怎么办？→ 看 completion vs cost 曲线的边际收益，有的场景（资金）可以接受 3x 成本换 5% completion。
11.3 拓扑怎么选？🔥🔥🔥🔥
Q：Multi-Agent 有哪些拓扑模式？怎么选？
答（60s）：六种核心拓扑——Supervisor（中心分发）、Hierarchical（分层管理）、Peer-to-Peer（去中心辩论）、Pipeline（线性流水线）、Mixture/Dynamic（按类型路由）、Swarm/Handoff（对话式移交）。决策点：子任务可枚举 → Supervisor；DAG 依赖+角色<5 → Pipeline 子图；角色>5 跨域 → Hierarchical；对话逐步升级 → Swarm；需验证 → Peer。核心原则：Supervisor 够用就不上 Hierarchical，Pipeline 够用就不上 Fan-out，复杂度是成本。
追问预判：→ Swarm 和 Supervisor 本质区别？→ Supervisor 控制流中心化，Swarm 控制流去中心化，Supervisor 更可控但单点瓶颈，Swarm 更自然但收敛难保证。
11.4 Coordinator 设计的关键原则？🔥🔥🔥🔥🔥
Q：Multi-Agent 系统中 Coordinator 怎么设计？
答（60s）：五个原则：① Single Writer——只有 Coordinator 可写 goal/plan/completed_steps，Worker 只 append observation；② 结构化通信——Worker 返回固定 JSON schema，不返回自由文本；③ 摘要压缩——每轮只读最近 N 轮 observation + 全局 completed 列表，防 token 爆炸；④ 收敛保证——设 max_rounds + 进度检测，连续 2 轮无进展 → 强制汇总或 escalate；⑤ 最小信息投递——Worker 只拿自己 task 的 context，不拿全局 plan。
追问预判：→ Coordinator 本身 context 溢出怎么办？→ 三招：observation 压缩到 ≤200 token、滑动窗口只保留最近 2 轮、历史存 checkpoint 按需检索。
11.5 并行任务的一致性怎么保证？🔥🔥🔥🔥🔥
Q：Fan-out 多任务并行时怎么保证一致性？
答（60s）：三层保障：① 显式 DAG 依赖——写操作的前置任务必须 Success 才启动，拓扑排序强制执行；② 写操作禁止无条件并行——多个写操作走 Saga 不走 Fan-out，补偿逻辑明确；③ Merge pre-condition——聚合前校验所有必需 task 已完成，缺失则 replan 而非用 null 值拼接。额外：写操作必须有 幂等键（业务键如 order_id + refund_type），防止重试导致重复写。
11.6 A2A 与 MCP 的关系？🔥🔥🔥
Q：A2A 协议和 MCP 有什么关系？
答（30s）：MCP 解决 Agent 到 Tool/Data 的标准连接，类比 USB 接口；A2A 解决 Agent 到 Agent 的互操作协议，类比 HTTP。两者互补：A2A 在上层编排 Agent 协作，MCP 在下层让每个 Agent 接入工具。一个 Agent 也可以通过 MCP 把自己暴露为另一个 Agent 的 Tool。关键区别：MCP 无状态，A2A 有 Task 生命周期管理。
11.7 画一个 Multi-Agent 退款系统的架构？🔥🔥🔥🔥
Q：白板画一个 Multi-Agent 退款架构。
答（90s）：
User → API Gateway → Coordinator Agent │ ┌──────────┼──────────┐ ← Fan-out (读操作, 可并行) ▼ ▼ ▼ Order Agent Policy Agent Risk Agent (查订单) (查退款政策) (风控评估) │ │ │ └──────────┼──────────┘ ↓ Coordinator Merge ← pre-condition: 3个全 Success │ ▼ (全部通过) Refund Agent ← 串行 + HITL 人审 + 幂等键 (执行退款) │ ▼ Notify Agent ← 异步, 允许失败重试 (发通知)
关键点：① 前三个 Agent 可并行（Fan-out），因为互不依赖；② Refund Agent 必须等前三个全部 Success（DAG 依赖）；③ 写操作（退款）走 HITL + 幂等；④ 每个 Agent 的 observation 是结构化 JSON；⑤ Coordinator 负责 merge 和决策；⑥ 全链路统一 trace_id。
11.8 Multi-Agent 的 Context Engineering 怎么做？🔥🔥🔥🔥
Q：多个 Agent 协作时，上下文怎么管理？
答（60s）：三层策略——Global State（目标/计划/完成列表，Coordinator 单写）、Agent-local（各 Agent 的 scratchpad 和工具缓存，互不可见）、Task-local（单任务的 input/output/重试计数）。核心技巧：① Worker observation 强制压缩到 ≤200 token 的结构化摘要；② Coordinator 用滑动窗口只读最近 N 轮；③ 跨 Agent 传递用 summarizer 压缩；④ 长期 context 存 checkpoint PG，按需检索。过度共享 → token 爆炸，过度隔离 → 信息断层，所以用 tag-based selective sharing。
11.9 Multi-Agent 怎么做可观测？🔥🔥🔥
Q：多 Agent 系统的可观测性怎么建？
答（60s）：三个维度——Trace：统一 trace_id 贯穿所有 Agent，每个 Agent/Task 一个 span，span 上打 agent_id/task_id/round/tokens/decision 标签；Cost：按 agent_id 归因 token 消耗，Coordinator 通常占 30-50%，据此优化；Quality：告警 5 个阈值——rounds>5（收敛差）、coordinator_tokens>50k（context 溢出）、handoff>3（乒乓）、task_timeout>10%（性能）、cost>budget（超预算）。
11.10 Swarm/Handoff 和 Supervisor 怎么选？🔥🔥🔥
Q：OpenAI 的 Swarm/Handoff 模式什么时候用？和 Supervisor 区别是什么？
答（45s）：Supervisor 是 中心化控制——一个 Coordinator 决定分给谁、什么时候收；Swarm 是 去中心化移交——每个 Agent 自己决定何时 handoff 给谁。Supervisor 适合 结构化任务拆分（退款流程），Swarm 适合 对话式逐步升级（客服从通用→专业→人工）。关键风险：Swarm 的收敛性不如 Supervisor，必须加 max_handoff + reason dedup 防乒乓。生产建议：资金路径用 Supervisor，对话路径用 Swarm。
11.11 Multi-Agent 部分失败怎么处理？🔥🔥🔥🔥
Q：Fan-out 后有 Worker 失败了怎么办？
答（45s）：分三级——① 可忽略（如通知 Agent 失败）：标记 skipped，继续后续步骤，异步重试；② 可降级（如风控 Agent 超时）：用默认策略（如拒绝高风险），降级完成；③ 必需（如查单 Agent 失败）：阻塞后续，retry × 3，exhausted 后整体 replan 或转人工。Coordinator 的 merge pre-condition 定义了哪些 task 是 required vs optional。配合 超时 ：每 task 30s hard timeout，10s soft timeout 触发降级路径。
11.12 给我讲一个 Multi-Agent 的生产事故？🔥🔥🔥🔥🔥
Q：你在生产中遇到过什么 Multi-Agent 的问题？
答（90s，用 §7.2-7.5 任一案例，STAR-M-P 格式）：
选择最贴近你经历的案例背诵。推荐 §7.2（退款协调失败）或 §7.3（Coordinator token 爆炸），因为最高频。
- 面试前 30 分钟 Checklist（Staff / Architect）
只勾不看内容，发现 ❌ 立即翻对应章节。
能 30s 内说清 Multi-Agent vs Multi-Task 区别（§1、Q11.1） 能说出 6 种拓扑 + 各自 trade-off（§2.2） 能画 Supervisor + Fan-out 退款架构白板（Q11.7） 能说出 Coordinator 5 个设计原则（Q11.4） 能说出 Fan-out 一致性三层保障（Q11.5） 能区分 A2A vs MCP（Q11.6） 能说出 Multi-Agent 准入门槛数字（eval≥80%, +5%, cost≤2x） 能讲 1 个 STAR-M-P 事故（§7.2–7.5 选一） 能说出 Context Engineering 三层策略（Q11.8） 能说出 5 个告警阈值（§8.3） 知道 Swarm vs Supervisor 区别和选型（Q11.10） 能说出部分失败的三级处理（Q11.11） 准备好 1 个成本估算例子（§6.4 替换数字） 能对照 06 讲 Subagent/Fork/Coordinator（§15） 能说明 LangGraph Send 与 Cursor 并行 Task 的异同（§15.2） 13. 全知识点 Checklist（逐项自测） 13.1 概念层（L1）— 8 项 KC-01 能定义 Multi-Agent：多个独立角色/提示/工具的 Agent 协作 KC-02 能定义 Multi-Task：多个子任务分解、调度、并行/依赖执行 KC-03 能画四象限（单Agent单Task / 单Agent多Task / 多Agent单Task / 多Agent多Task） KC-04 知道单 Agent 也能 Multi-Task（Fan-out tool calls） KC-05 知道多 Agent 可以处理单任务（辩论验证） KC-06 能区分 Coordinator / Worker / Scheduler / Merger 四角色 KC-07 能说出 Stage 1→4 成熟度与拓扑对应 KC-08 知道 Multi-Agent 不一定优于单 Agent 13.2 拓扑与编排层（L2）— 16 项 KC-09 Supervisor 拓扑：优势（可控）、劣势（单点、token 开销） KC-10 Hierarchical 拓扑：优势（分层自治）、劣势（层间延迟） KC-11 Peer-to-Peer 拓扑：优势（多视角）、劣势（难收敛） KC-12 Pipeline 拓扑：优势（最低开销）、劣势（无并行） KC-13 Mixture/Dynamic 拓扑：优势（灵活）、劣势（路由维护） KC-14 Swarm/Handoff 拓扑：优势（自然传递）、劣势（回退困难） KC-15 能画拓扑选型决策树 KC-16 任务分解三策略：LLM Plan / Template DAG / Hybrid KC-17 Plan 输出结构化 schema（id, deps, agent, write, hitl） KC-18 DAG 拓扑排序调度 KC-19 Fan-out / Fan-in 模式 KC-20 任务状态机（Pending→Running→Success/Failed→Retrying/Escalated，含 HITL） KC-21 Replan 策略与 max_replan_count ≤ 3 KC-22 四种通信范式（Direct / Message Bus / Shared State / Handoff） KC-23 A2A 协议核心概念（Agent Card / Task / Streaming / Artifact） KC-24 MCP vs A2A 区别与互补关系 13.3 状态与 Context（L2-L3）— 12 项 KC-25 状态分层：Global / Agent-local / Task-local KC-26 Single Writer 原则 KC-27 Coordinator 持 Plan 原则 KC-28 Structured Observation 原则 KC-29 Append-only for Workers 原则 KC-30 Checkpoint 租户隔离（tenant_id RLS） KC-31 Context Engineering：Coordinator 滑动窗口 + 摘要压缩 KC-32 Worker 最小信息原则 KC-33 跨 Agent 摘要传递 KC-34 ObservationCompressor 组件（≤200 token） KC-35 Memory 共享模式（No Sharing / Blackboard / Event Sourcing / Selective） KC-36 LangGraph MultiAgentState 实现模式 13.4 生产工程层（L3）— 18 项 KC-37 Token 开销公式：N×T + Coordinator×R + Merge KC-38 并行 vs 串行 trade-off KC-39 容量估算：能口算 $/hour KC-40 准入门槛数字：eval≥80%, +5%, cost≤2x KC-41 回退机制：eval 不达标 → 灰度缩量 → 回退单 Agent KC-42 12 个反模式（§7.1）能说出 ≥ 5 个 KC-43 能讲 ≥ 2 个 STAR-M-P 事故案例 KC-44 跨 Agent trace 关联：统一 trace_id + agent_id/task_id span KC-45 成本归因：按 agent_id 维度 KC-46 5 个告警阈值 KC-47 四层 Eval（单Agent / 协调 / 端到端 / 成本 / 收敛） KC-48 Eval Gate 准入流程 KC-49 8 类 Multi-Agent 专属 eval case KC-50 部分失败三级处理（可忽略 / 可降级 / 必需） KC-51 超时机制：soft timeout（降级）+ hard timeout（终止） KC-52 写操作一致性：DAG 依赖 + Saga + 幂等键 + pre-condition KC-53 Handoff 防乒乓：max_handoff + reason dedup + 熔断 KC-54 通信 Schema 版本管理 13.5 框架选型层（L3）— 6 项 KC-55 LangGraph Multi-Agent：StateGraph + Send API + conditional_edges KC-56 AutoGen：GroupChat + GroupChatManager + speaker_selection KC-57 CrewAI：Agent + Task(context) + Crew(process) KC-58 OpenAI Agents SDK / Swarm：Agent + handoffs KC-59 Spring AI + 自建 Coordinator KC-60 场景→框架映射表（资金→LangGraph, 对话→Swarm, 内容→CrewAI） 13.6 Staff 答辩层（L4）— 12 项 KC-61 能白板画 Multi-Agent 退款架构 KC-62 能 30s 说清 Multi-Agent vs Multi-Task KC-63 能说出 Coordinator 5 原则 KC-64 能说出 Fan-out 一致性三层保障 KC-65 能说出 Swarm vs Supervisor 选型逻辑 KC-66 能讲 STAR-M-P 事故 KC-67 能口算 Multi-Agent 成本估算 KC-68 能说出 A2A vs MCP 区别 KC-69 能说出 Context Engineering 三层策略 KC-70 能画跨 Agent trace span 结构 KC-71 能说出部分失败三级处理 KC-72 能回答"什么时候不该用 Multi-Agent" KC-73 能区分 Cursor Subagent vs 生产 Worker（06） KC-74 能说明 IDE 会话 Fork 不等于业务 checkpoint KC-75 能口述 LangGraph Send Fan-out 与写操作互斥 15. DevEx Subagent 与生产 Coordinator 闭环（2026 增补）
专章：06-Coding-Agent运行时对照 · Catalog：96 DEVEX_* + MA_*
15.1 同一问题，两套答案 面试问法 先答运行面 再答生产不变式 「Subagent 是什么？」 Cursor：独立 context 的 Worker Coordinator 单写 plan；Worker append observation 「Coordinator 在哪？」 父 Agent 隐式协调 MultiAgentState + checkpoint 显式节点 「并行会不会更快？」 探索只读可并行 写操作 Fan-out 禁止；Saga 串行 「断了怎么续？」 Resume agent ID / Fork 实验分支 thread_id + 幂等键；禁全量 replan 15.2 LangGraph Send API：生产 Fan-out 标准写法
依据：LangGraph 动态扇出。
from langgraph.types import Send
def coordinator_fanout(state): """Coordinator 选出可并行 task → Send 到对应 worker 节点""" pending = [t for t in state["plan"] if t["status"] == "pending" and deps_met(t, state)] # 写操作：同一 round 最多 1 个 writes = [t for t in pending if t.get("write")] if len(writes) > 1: pending = [writes[0]] return [Send(worker_node(t["agent"]), {"task": t, "goal": state["goal"]}) for t in pending]
def worker_node(agent_name: str, payload: dict) -> dict: obs = run_worker(agent_name, payload["task"], minimal_context(payload)) return {"observations": [compress_observation(obs)]}
DevEx 对照 LangGraph 父 Agent 发多个 Task Send[] explore/bash/browser 专用 worker 节点 + 工具白名单 background subagent 异步节点 + 轮询 merge readonly subagent worker 图内只读 tool 边 15.3 与 Cursor Subagent 的边界（Staff 必背） 允许：用 subagent 做 explore / verifier / test-runner（06 §3）。 禁止：IDE 并行 subagent 直接写 生产库；Fork 会话当业务 checkpoint（DEVEX_FORK_NO_AUDIT）。 迁移：Orchestrator 三角色（Planner→Implementer→Verifier）→ Pipeline + 验证节点（06 §22）。 15.4 Multi-Agent Eval 门禁（与 06 §25 成本账本校准） Gate 阈值（示意） 失败动作 单 Agent baseline success ≥ 80% 不准上 Multi-Agent Multi vs Single completion +5pt 且 cost ≤2x 缩 Worker 或改拓扑 Coordinator token < 50k/run 压缩 observation Convergence rounds ≤ 5 降级单 Agent Trajectory golden 匹配 ≥ 95% 阻断发布（19） 15.5 追加面试题（与 06 §99 交叉） 11.13 Subagent 与 Multi-Agent Worker 一样吗？🔥🔥🔥🔥
答（40s）：角色同、治理不同。Subagent 缺业务 checkpoint/租户/幂等；生产 Worker 必须在 Coordinator 下 结构化 JSON 回传。IDE 父 Agent≈Coordinator，但须 显式化 到图与 DB。
11.14 Fork 会话能否代替 checkpoint？🔥🔥🔥
答（30s）：不能。Fork/Resume 解决 研发实验与续聊；checkpoint 解决 写操作可审计续跑。见 96 DEVEX_* vs RUN_*。
11.15 三个 readonly subagent 并行改同一模块？🔥🔥🔥🔥
答（40s）：探索可并行，实现必须单写者。否则 Git 冲突与局部最优（06 §11 STAR）。生产同理：Fan-out 只给 读 Worker。
11.16 Java 侧如何落地 Supervisor？🔥🔥🔥
答（45s）：Spring AI ChatClient 做 intent → Scripted/LLM Supervisor 路由 → 多 Worker Bean → summarize；轨迹见 multi-agent-supervisor demo。演进：LangGraph4j 或 Plan-Execute 自研，不变式同 §5。
11.17 Peer 辩论为何生产慎用？🔥🔥🔥
答（35s）：无 Coordinator 时 token 与轮次易失控（MA_PEER_NO_CONVERGE）。仅用于 离线评审/红队；资金路径用 Supervisor + HITL。
- 总结金句
Multi-Agent 解决"谁来做"，Multi-Task 解决"做什么和怎么排"。Coordinator 是唯一写 plan 的人，Worker 只反馈结构化 observation。写操作永远串行 + 幂等 + HITL，只有读操作才值得 Fan-out。上 Multi-Agent 前先证明单 Agent 不够——eval ≥ 80% 是准入门槛，成本 ≤ 2x 是留存条件。
拓扑选型不是技术品味，是架构决策——Supervisor 够用就不上 Hierarchical，Pipeline 够用就不上 Fan-out。复杂度是成本，简单是竞争力。
Context Engineering 是 Multi-Agent 的隐藏 boss——过度共享 token 爆炸，过度隔离信息断层。三层分离 + 摘要压缩 + 按需检索是生产正解。
每个 Multi-Agent 系统都需要三个安全网：max_rounds 防空转、max_handoff 防乒乓、max_replan 防无限重做。没有硬上限的 Agent 系统迟早会在凌晨三点叫你起床。
DevEx Subagent 与生产 Coordinator 是同一套编排的两层皮肤——IDE 省 context，生产保幂等与审计；详见 06 与 §15。
官方文档与源码（一级依据）
AI Engineering · 正文机制应来自下方 官方文档（L1） 与 官方源码仓库（L2）； 禁止用教程站/博客充当机制依据。本章 QPS/延迟/STAR 为面试示意。 写作规范：docs/official-sources-registry.md §0
L1 · 官方文档
Spring AI Reference LangGraph Interrupts LangChain4j Docs
L2 · 官方源码
spring-projects/spring-ai langchain-ai/langgraph langchain4j/langchain4j
L3 · 论文 / 开放规范
L3 MCP Specification
笔记由 Hermes Agent 自动抓取保存