自测题库

概念层

1. 拓扑结构、协调机制、通信方式。说“正交”是因为三者可独立取值：同一种拓扑（如 supervisor）既能用共享 state 也能用消息传递、既能中心调度也能带局部 handoff——改一条轴不强制改另一条，所以任意系统都是三轴各取一值的组合。
2. supervisor：一个中心节点连向多个 worker，星形；hierarchical：多层星形嵌套，上层 supervisor 管下层 supervisor；swarm-handoff：agent 之间直接相连、无中心，谁接棒谁干，网状。
3. 中心调度：决策权在 supervisor，它决定每一步派给谁（例：supervisor 看任务把子任务分给 search/写作 worker）。去中心 handoff：决策权在当前 agent，它自己决定交接给谁（例：客服 agent 判断这是技术问题，直接 handoff 给技术 agent）。
4. 共享 state：所有 agent 读写同一份状态，省去显式传参、适合状态紧耦合；消息传递：显式发收消息、边界清晰、适合松耦合与审计。上下文隔离解决的是context clash——让每个 subagent 只看到与自己任务相关的上下文，避免无关信息互相干扰、也省 token。
5. 当任务的步骤能由一个 agent 配合多个工具线性走完、没有需要并行的独立子任务时，单 agent + 多工具就够——多 Agent 的协调开销与 token 翻倍只在“子任务独立可并行且价值高”时才划算。
6. 大致：LangGraph=有状态图 + 任意拓扑 + 共享 state（精控、可持久化）；AutoGen-AG2=会话式 GroupChat（消息传递、偏去中心）；CrewAI=角色化 crew（supervisor 式编排、上手快）；OpenAI Agents SDK=显式 handoff（去中心交接）。框架只是把某种三轴组合封装好了。

原理层

1. 每个 subagent 都带独立的上下文（系统提示 + 工具定义 + 各自的历史），再叠加 supervisor 与 worker 之间来回的协调轮次，token 随 agent 数与轮次相乘——Anthropic 实测约 15×。本质是“用更多 token 买并行广度”。
2. 意味着多 Agent 的收益主要是烧更多 token 换来的广度，不是结构本身更聪明。所以只有当任务价值撑得起这笔 token、且确实需要并行探索时才划算；否则单 Agent 同样的 token 预算可能效果更好。
3. supervisor 的瓶颈：所有决策与汇总都过中心节点，它成为吞吐与单点故障的瓶颈，且容易上下文过载。swarm-handoff 用“去中心、agent 自行交接”换灵活，代价是难调试、可能踢皮球或死循环（没有中心视角看全局）。
4. 隔离过度会让 subagent 缺少完成任务必需的上下文（例如不知道总目标、重复别人已做的工作）。把握点：传“足够完成本子任务”的最小上下文，而非整段历史——既不过载（context clash）也不缺信息。
5. ① 子任务强依赖、必须串行（后一步要等前一步结论）；② 需要共享大量中间状态、隔离反而增加同步成本；③ 步骤可预先枚举（那是 workflow 的活，不需要 agent 的自主性）。
6. 难在：路径不唯一、中间步骤难判对错、失败可能源于任一 agent 或它们的交互；所以除最终正确性，还要看过程指标（每个 agent 的工具调用准确率、协调轮次、token），并按 agent 维度拆解 trace 才能定位。

应用判别层

1. 子任务（查不同信源）天然独立、可并行，汇总前的素材又容易超出单上下文——属于“广度优先”，supervisor + 并行 worker 划算，前提是这份报告的价值吃得下约 15× token。判据=独立可并行 + 价值够高；代价=token 翻倍、协调与合并开销、调试更难。若各信源强依赖、要频繁共享中间结论，则退回单 Agent。
2. 质量没变而成本暴涨，多半不是质量 bug 而是结构 bug：先怀疑“协调轮次过多 / 上下文每轮膨胀 / 某个 worker 在循环”。定位：按 agent 维度看 token 燃烧率与单次任务的协调轮次、对比哪个 agent / 哪类请求贡献了增量，再下钻具体 trace——不是凭感觉猜。
3. 根因是通信轴的选择：用了“共享 state”却没处理并发写——两个 worker 同时写同一键，更新互相覆盖（竞态）。修：要么改通信为消息传递 / 各写各的键再汇聚，要么给共享 state 的该键配reducer（定义并发更新如何合并，而非覆盖），把“并行写冲突”交给合并规则处理。