面试官可能会问：“既然任务已经拆成检索、分析、写作和评审多个 Agent，接下来是固定顺序执行，还是交给 Supervisor 动态调度？”
固定流水线把角色按明确依赖串起来，路径容易理解、测试和回放。Supervisor 则根据当前 State 决定下一步叫谁、是否返工或结束，适合运行时才能确定的开放任务。但 Supervisor 并不会自动让团队更智能，它也可能成为新的单点瓶颈：所有上下文都汇总到中央角色，路由错误反复发生，子 Agent 互相踢任务，最终在没有完成证据时结束。
回答时应直接说明控制权放在哪里，而不要停在“顺序、并行、层级”三个名词上。确定性依赖交给图和代码，语义不确定性才交给模型路由；所有角色通过结构化 State 与工件交接，不靠自由聊天维持事实；每个节点有完成条件、失败出口、重试预算和 Trace。
多数可靠系统不是二选一，而是外层用确定性流水线约束阶段，局部开放环节由 Supervisor 选择角色，随后回到明确的验收节点。
先给出 30 秒回答
多 Agent 编排先看任务依赖是否能在运行前确定。检索、证据校验、写作、发布这类顺序稳定且每阶段可验收的流程，我优先用 Pipeline 或 StateGraph，把路由、并行、合并和失败出口写成显式边。只有下一步必须根据运行中发现动态决定，例如研究过程中出现新子问题、证据冲突或需要专家角色时，才在局部引入 Supervisor。无论哪种模式，角色都通过带版本的共享 State 和结构化工件交接，事实、推断和待办分开；重试有上限，副作用有幂等与审批，Supervisor 的决策也要记录理由并通过完成条件验证。这样既保留开放探索，又避免中央 Agent 包办一切。
核心原则是：能由代码确定的路径不交给模型猜，真正需要语义判断的位置才使用 Supervisor。
固定依赖用图控制，运行时未知分支才需要动态监督。
Pipeline 模式到底是什么
Pipeline 不只是把多个 Agent 写成一个数组顺序调用。它描述任务依赖、节点输入输出、成功条件和失败边。
例如研究报告流程可以是：解析问题，生成子问题，并行检索，合并证据，检查冲突，生成报告，评审核验。每个节点只读取必要 State，输出结构化工件。依赖明确的节点按顺序，互不依赖的子问题并行，所有分支结束后进入合并。
固定流程的优势是可预测。测试可以覆盖每条边，Trace 能看见任务停在哪个节点，重跑可以从 Checkpoint 继续，成本与权限也容易估算。对有明确合规步骤的任务，代码图能保证“审核未通过不能发布”。
它的局限是面对开放任务不够灵活。研究过程中可能发现原问题假设错误，需要新增子问题；某类资料缺失，需要换专家角色；证据冲突，可能回到检索而不是继续写作。如果把所有可能路径提前硬编码，图会变得庞大。
因此 Pipeline 适合“依赖已知、阶段稳定、错误出口清楚”的任务，不等于任务简单。
Supervisor 模式到底是什么
Supervisor 是一个拥有调度责任的控制节点。它读取当前任务状态、已有工件、未完成目标和角色能力，决定下一步调用哪个 Worker、给什么子任务、结果是否可接受，以及继续、返工还是结束。
它适合运行前无法列全路径的场景。例如复杂研究中，初步证据揭示新的关键实体；代码修复中，测试结果决定继续查日志、改实现还是回退；客服场景中，用户意图和风险等级决定转给不同专家。
Supervisor 的输出应是结构化决策，不是一段“我认为下一步可以”。至少包含目标角色、任务说明、输入工件引用、期望输出、原因、剩余预算和返回节点。代码层校验角色是否合法、权限是否允许、预算是否足够。
Supervisor 也不是最终权威。它可以路由，却不能跳过安全规则、审批和结构化完成条件。模型判断“已经完成”后，系统仍要检查必需工件、证据、测试或人工批准。
最常见的错误：把所有控制权都给 Supervisor
如果 Supervisor 同时负责理解用户、拆任务、保存全部上下文、选择工具、评估结果、修复错误和生成最终答案，系统只是把一个大 Agent 换了名字。
中央角色会重新遇到上下文爆炸和工具混乱。所有 Worker 的完整输出都回传，Supervisor 越来越难找到关键状态。它还可能凭自然语言误解 Worker 已完成什么，重复派发相同任务。
更稳的是让代码和状态层承担确定性责任：预算计数、权限、节点状态、幂等键、工件版本、分支完成、超时和最大循环。Supervisor 只在多个合法下一步之间做语义选择。
Worker 结果先经过对应验证器，再交给 Supervisor。检索结果检查来源与结构，代码修改运行测试，写作输出检查引用。未经验证的自然语言自评不能直接变成 completed。
一个判断表：什么时候选哪种模式
路径在运行前已知，节点依赖稳定，合规步骤不能跳过，优先 Pipeline。
下一步由运行时证据决定，子任务数量不可预先确定，需要按领域动态选择角色，可以考虑 Supervisor。
部分阶段固定、局部探索开放，使用混合模式。外层图规定必须经历的阶段，探索节点内部由 Supervisor 调度，达到退出条件后回到固定图。
如果只是按字段路由，例如 language=python 选择 Python 工具，直接用代码条件边，不需要 LLM Supervisor。如果路由依赖语义且规则难以枚举，再使用模型并保留兜底。
如果任务高风险且下一步必须经过人工批准，Supervisor 只能提出建议，Human-in-the-loop 节点拥有放行权。
混合模式把开放探索限制在可控子图内。
共享 State 应该保存什么
多个 Agent 不能靠互相发送整段聊天记录维持协作。共享 State 是任务事实源，应该结构化保存目标、约束、计划、节点状态、工件引用、证据、错误、预算、审批与下一步。
{
"task_id": "...",
"goal": "...",
"constraints": [],
"stage": "evidence_review",
"artifacts": [],
"open_questions": [],
"verified_facts": [],
"hypotheses": [],
"errors": [],
"budget": {},
"version": 1
}
这只是教学字段示意，不是现有项目的真实 Schema。
事实、推断和待验证项必须分开。检索 Worker 说“这可能是关键原因”，不能直接进入 verified_facts。验证节点确认来源后再升级。否则上游猜测会被多个下游角色重复引用，最后看起来像共识。
State 中的大网页、报告和代码放工件存储，只保存引用、版本和哈希。每个角色得到最小 State 视图，避免无关内容和敏感数据扩散。
Agent 之间怎样交接
一次可靠交接要说清楚五件事：当前子目标是什么；提供了哪些已验证输入；哪些是假设或缺口；期望输出 Schema 是什么；完成和失败怎样判断。
例如检索角色的输出不是“我搜到了一些有用资料”，而是一组证据记录，每条包含查询、来源、时间、摘录、与子问题的关系、访问状态和待核验点。分析角色可以据此去重和识别冲突。
报告角色接收的是经过审核的证据包、结构要求和引用规则，不接收全部搜索聊天。若证据不足，它返回结构化缺口，不自行编造内容或直接重新搜索，除非契约允许。
交接工件需要稳定 ID 与版本。Supervisor 重试同一 Worker 时，区分新增结果和重复结果。下游读取工件前校验版本，避免基于旧草稿继续工作。
Pipeline 里的并行与合并
固定流程也可以并行。关键是并行分支之间没有数据依赖，并且合并规则明确。
研究任务可以把多个子问题并行检索，每个分支输出相同证据 Schema。合并节点按来源和内容去重，标记缺失分支与冲突，不把“分支完成”误当作“找到有效证据”。
并行要有并发限制和背压。外部搜索或模型服务有容量边界，不能一次展开无限子任务。父节点保存分支 ID 与状态，超时后决定重试、降级或带缺口继续。
部分分支失败时，是否允许整体继续由任务规则决定。非关键补充资料失败可以标记缺口，关键事实无来源则阻止报告进入发布。合并节点比 Supervisor 更适合执行这些确定性条件。
没有真实运行数据时，只描述并行设计和观测口径，不承诺具体时延收益。
Supervisor 怎样避免无限循环
动态调度最常见的故障是 Worker 返回信息不足，Supervisor 再派同一任务，两个角色不断改写措辞却没有新增证据。
系统需要硬预算：最大调度轮次、每个角色调用次数、工具预算、时间或 Token 上限。达到上限后进入降级、人工确认或带缺口结束，不能只在 Prompt 中写“不要循环”。
还需要进展判定。每轮是否新增工件、解决开放问题、减少冲突、通过新的验证器。若状态没有变化，即使文本不同也算无进展。可以用工件哈希、开放项集合和节点状态做代码检查。
Supervisor 决策记录理由和输入版本。如果连续选择同一角色处理同一目标，调度器可以阻止并要求换策略或退出。
Worker 也不能自行无限转交。所有角色调用通过统一编排层，避免 A 直接叫 B、B 再叫 A 而系统看不到全局预算。
失败应该在谁那里恢复
格式错误和可重复的临时故障，优先在当前节点局部修复。检索服务超时，可以按预算重试或切换允许的来源；Worker 输出缺字段，先做一次结构修复。
业务证据不足不能当作技术异常无限重试。它应返回上游或 Supervisor，由其改子问题、请求用户澄清或结束并说明缺口。
权限拒绝不应该换 Worker 规避。高风险副作用超时后状态不确定，需要按幂等键查询，不可直接重复执行。
Pipeline 可以用显式错误边跳到恢复、人工介入或终止节点。Supervisor 也只能在错误分类允许的候选动作中选择，不能自由绕过策略。
Checkpoint 保存节点、State 版本、已完成副作用和工件引用。恢复时从最近安全点继续，不重新执行已完成动作。Worker 的自然语言“已经做过”不够，必须有执行凭证。
怎样防止 Supervisor 成为性能和质量瓶颈
第一，减少中央上下文。Supervisor 读取结构化摘要、开放项和工件元数据，不读取所有原始日志。
第二，固定能固定的路由。格式校验、权限、预算、重试计数和明显条件分支由代码完成。
第三，局部 Supervisor。不同子图可以有受限控制器，顶层只管理阶段，不让一个角色知道全部工具和细节。
第四，决策缓存与幂等。对同一 State 版本和路由意图，不重复产生不同派发，除非失败信息变化。
第五，独立完成验证。Supervisor 建议结束后由代码或评审节点检查必要产物，避免它为了节省调用提前结束。
第六，Trace 分开记录路由质量和 Worker 质量。目标角色选错是调度问题，角色执行失败是 Worker 问题，不能都算最终答案失败。
一个 Deep Research 混合编排例子
外层固定图先解析用户问题、确认范围与来源要求，再进入研究子图。研究子图由 Supervisor 根据当前开放问题选择检索或分析角色。
检索角色返回结构化证据，验证器检查来源和字段。分析角色识别结论、冲突与缺口。若出现新的关键子问题，Supervisor 可以新增一个有限分支；若连续没有新增证据或预算用尽，退出研究子图。
退出后回到固定流程：证据门禁确认关键主张都有来源；报告角色只使用已验证证据；引用检查和人工审批不能被跳过。发布是独立的有副作用节点，需要明确批准与幂等。
这种结构让 Supervisor 只负责开放研究，不控制发布权限，也不承担最终全部写作。固定图保证必要步骤，局部监督处理未知分支。
Pipeline 和 Supervisor 怎样公平评估
使用同一任务集、同一 Worker 能力、同一工具、同一上下文预算与同一完成条件。否则无法判断差异来自编排还是资源。
任务集覆盖路径固定的标准任务、运行时出现新子问题的开放任务、证据冲突、工具失败、权限拒绝、部分分支失败和需要人工确认。
Pipeline 重点看边覆盖、阶段完成、局部恢复和不跳过门禁。Supervisor 重点看路由正确、无效调度、循环、完成判断和中央上下文。两者都看端到端质量、首次失败、调用开销、人工介入与 Trace。
还要比较混合模式与纯模式。若 Supervisor 在固定任务上频繁做出与代码图相同的选择，它没有必要；若 Pipeline 为开放任务增加大量脆弱分支，可以把局部控制交给 Supervisor。
没有真实运行证据时，只给评测设计和判定规则，不虚构路由准确率、完成率、成本或时延。
路径错误、角色执行错误、状态错误和完成误判需要分层定位。
上线前要做哪些故障演练
让 Worker 返回缺字段、空结果、重复工件和互相冲突的结论，检查验证器是否挡住。
让 Supervisor 选择不存在或无权限的角色，代码层必须拒绝。让它连续派发同一任务，进展检测与预算应终止循环。
让并行分支部分超时，合并节点按关键性决定等待、重试、降级或阻止后续。让旧版本 Worker 晚到，不能覆盖新 State。
在有副作用节点制造超时，恢复不能重复执行。中断后从 Checkpoint 继续，已完成节点和工件仍可验证。
让 Supervisor 提前宣称完成，但缺少关键证据、测试或批准，完成门禁应拒绝。再让关键证据确实缺失，系统要能带限制说明退出，而不是无限探索。
最后做权限演练。不同 Worker 只收到必要 State，敏感工件不通过自由消息传播，Trace 不记录完整秘密。
路由、状态、恢复、完成和权限缺一不可。
面试官会怎样连续追问
追问一：Pipeline 和 Supervisor 最大区别是什么
Pipeline 的主要路径由图和代码预先确定，Supervisor 在运行时根据 State 做语义路由。区别是控制权位置，不是角色数量。
追问二：什么时候不用 Supervisor
条件能由结构化字段和规则确定，步骤必须按顺序，合规门禁不能跳过时，代码边更可靠。不要让模型判断 status=approved 后该去哪里。
追问三：Supervisor 怎样知道任务完成
它可以提出完成建议，但系统还要验证必需工件、开放项、证据、测试、预算和审批。自然语言自评不能单独设置 completed。
追问四：怎样避免 Agent 互相踢皮球
统一编排层控制调用，任务有稳定 ID、所有者、预期输出、最大轮次和进展判定。Worker 不直接自由调用彼此。
追问五：共享 State 和聊天记录有什么区别
State 保存可验证的目标、事实、工件、错误和节点状态，聊天是交互轨迹。多 Agent 协作依赖结构化 State，不依赖复制全部对话。
追问六：最推荐哪种模式
没有统一答案。常见可靠方案是外层固定图加局部 Supervisor，让确定性路径可测试，开放探索又有边界。是否更好仍需任务集验证。
Pipeline 与 Supervisor：怎样交代控制权
多 Agent 已经确定拆分后，我先看任务依赖能否预先确定。顺序稳定、阶段可验收、门禁不能跳过的流程用 Pipeline 或 StateGraph；只有下一步必须根据运行中证据决定时，才在局部用 Supervisor。角色通过带版本的共享 State 和结构化工件交接，事实、推断和待验证项分开，大内容只保存引用。能用代码完成的权限、预算、条件路由、重试计数和完成校验不交给模型。Supervisor 输出结构化派发，Worker 结果先过验证器，循环受轮次、资源和进展约束。失败按格式、临时故障、业务缺口、权限和副作用不确定分类恢复。多数场景我会用外层固定图加局部监督，并用同一任务集比较纯 Pipeline、纯 Supervisor 与混合方案。
多 Agent 编排有没有失控：十一项核验
- 能否说明哪些依赖固定，哪些分支只有运行时才知道。
- 是否把结构化条件路由、权限和门禁交给代码。
- 每个 Worker 是否有输入输出 Schema、完成条件和失败类型。
- 共享 State 是否区分事实、推断、开放项、错误和工件版本。
- 并行分支是否有依赖、并发、背压、去重和部分失败规则。
- Supervisor 是否只看到必要摘要，而非全部原始轨迹。
- 是否有最大轮次、资源预算和无进展检测。
- 副作用是否有审批、幂等和恢复凭证。
- 最终完成是否由工件、证据、测试或批准验证，而非模型自评。
- 是否用相同任务集比较 Pipeline、Supervisor 和混合模式。
- 没有真实数据时，是否避免虚构路由准确率、延迟与成本改善。
多 Agent 编排的专业感不在于画出多少角色，而在于控制权清楚：确定性路径由图保证，开放决策由受限 Supervisor 完成，所有事实通过 State 和工件传递，任何失败都能定位、恢复或安全退出。