Multi-Agent 与 Multi-Task 编排架构

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 答辩 四层递进；每层有 ⚠ 难点 / 🔥 高频 / 💀 陷阱 标注。

---

0. 本篇注意点与核心难点速查

面试前 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	★★★★

---

1. 概念辨析：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 解决"做什么和怎么排"。生产系统两者通常同时出现。

---

2. Multi-Agent 拓扑模式（L2 原理）

2.1 六种核心拓扑

flowchart TB subgraph "① Supervisor" S[Supervisor] --> W1[Worker A] S --> W2[Worker B] S --> W3[Worker C] end subgraph "② Hierarchical" M[Manager] --> L1[Lead 1] M --> L2[Lead 2] L1 --> W4[Worker] L1 --> W5[Worker] L2 --> W6[Worker] end subgraph "③ Peer-to-Peer" P1[Agent A] <--> P2[Agent B] P2 <--> P3[Agent C] P1 <--> P3 end subgraph "④ Pipeline" PL1[Agent 1] --> PL2[Agent 2] --> PL3[Agent 3] end subgraph "⑤ Mixture / Dynamic" DYN[Router] -->|类型A| DA[Specialist A] DYN -->|类型B| DB[Specialist B] DYN -->|复杂| DC[Sub-Supervisor] end subgraph "⑥ Swarm / Handoff" SW1[Agent X] -->|handoff| SW2[Agent Y] SW2 -->|handoff| SW3[Agent Z] SW3 -->|handoff| SW1 end

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 级架构决策树

flowchart TD Q1{子任务可枚举?} Q1 -->|是| Q2{子任务间有依赖?} Q1 -->|否,动态发现| MIX[Mixture/Dynamic] Q2 -->|无依赖,可并行| SUP[Supervisor + Fan-out] Q2 -->|有 DAG 依赖| Q3{角色超过 5 个?} Q3 -->|是| HIER[Hierarchical] Q3 -->|否| PIPE_OR_SUP[Supervisor + Pipeline 节点] Q1 -->|需对抗验证| P2P[Peer-to-Peer 辩论] Q1 -->|对话式逐步移交| SW[Swarm/Handoff]

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。

---

3. Multi-Task 编排模式（L2 原理）

3.1 任务分解策略

策略	描述	适用	风险
LLM Plan	LLM 自主将目标拆为子任务列表	开放域、用户意图模糊	Plan 漂移、幻觉任务
Template DAG	预定义任务模板 + 参数填充	已知 SOP、资金操作	灵活性低
Hybrid	固定骨架 + LLM 填充可变节点	生产推荐	需 policy guard 防溢出

3.2 任务依赖 DAG 🔥

flowchart LR T0[用户请求解析] --> T1[查订单] T0 --> T2[查用户画像] T1 --> T3[算退款金额] T2 --> T3 T3 --> T4[生成退款工单] T3 --> T5[发通知] T4 --> T6[人审 HITL]

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 任务状态机

stateDiagram-v2 [*] --> Pending : 任务创建 Pending --> Blocked : 前置依赖未完成 Pending --> Running : 依赖满足 Blocked --> Running : 依赖满足 Running --> Success : 正常返回 Running --> Failed : 异常/超时 Failed --> Retrying : retry < max Retrying --> Running : 重试 Failed --> Escalated : retry exhausted Running --> HitlPending : 需人审 HitlPending --> Running : 人审通过 HitlPending --> Skipped : 人审拒绝 Success --> [*] Escalated --> [*] Skipped --> [*]

3.6 Replan 策略 ⚠

触发条件	策略	风险
单 task 失败且 retry exhausted	跳过该 task + 调整下游依赖	信息不完整
多 task 并行结果矛盾	Coordinator 仲裁或增加验证 task	增加轮数
用户中途改变目标	清除未执行 task，基于新 goal replan	plan 膨胀
Plan 漂移（goal 偏移检测）	比对 goal embedding 相似度 < 阈值 → 拒绝	误报

💀 陷阱 ：Replan 不受限 → 无限 replan 循环。必须设 max_replan_count ≤ 3。

---

4. 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，否则成本翻倍但质量不升。

---

7. 生产反模式与事故（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 可观测性。

---

9. 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 爆炸），因为最高频。

---

12. 面试前 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 必背）

flowchart LR subgraph ide ["DevEx · 不进用户路径"] P[Parent Agent] S[Subagents] P --> S end subgraph prod ["Production"] C[Coordinator] W[Workers] DB[(Checkpoint)] C --> W --> DB --> C end ide -.->|PR+CI+Harness| prod

• 允许 ：用 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。

---

16. 总结金句

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