934 lines
45 KiB
Markdown
934 lines
45 KiB
Markdown
# Multi-Agent与Multi-Task编排架构
|
||
|
||
> 来源：[知乎专栏](https://zhuanlan.zhihu.com/p/2045496378252588635?utm_psn=2045633590483068568)
|
||
> 抓取时间：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 答辩 四层递进；每层有 ⚠ 难点 / 🔥 高频 / 💀 陷阱 标注。
|
||
|
||
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 六种核心拓扑
|
||
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。
|
||
|
||
3. 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。
|
||
|
||
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 必背）
|
||
允许：用 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
|
||
|
||
---
|
||
|
||
*笔记由 Hermes Agent 自动抓取保存* |