Wiki Notes

Appearance

多模型协同编排专题 ​

版本：v1.2

最后更新：2026-07-09

适用对象：需要把多个模型按角色、步骤和条件组织进同一条任务链路中的产品、研发、平台与架构同学

很多系统在引入多个模型后，第一反应是：

  • 做个路由就够了

但真正复杂的场景往往需要的不只是选一个模型，而是：

  • 不同步骤由不同模型协作完成
  • 不同模型承担不同角色
  • 输出在链路中传递和校验
  • 失败时能跳步、降级或转人工
  • 有些角色并行跑，有些角色接管整个会话

这也是为什么需要多模型协同编排。

根据 2026-07-09 复核可访问的 OpenAI Agents、Orchestration and handoffs、Agent orchestration、Reasoning best practices，以及 Anthropic Choosing the right model、Tool use overview 的当前官方资料，可以先建立一个关键共识：

  • 协同编排的重点不是模型数量更多，而是让每个模型或 agent 在合适的位置承担清晰、可验证、可替换的职责。

1. 什么是多模型协同编排 ​

更实用的理解通常是：

  • 把多个模型放进同一任务链路中
  • 让它们按角色、顺序或条件协同工作

重点不是“模型数量更多”，而是：

  • 不同模型是否在合适的位置发挥合适作用

1.1 协同编排不等于盲目堆模型 ​

如果只是把原本一个模型做的事拆成三个模型重复做，通常只会带来：

  • 成本更高
  • 延迟更长
  • 调试更难

1.2 真正值得做协同编排的前提 ​

通常至少满足一个条件：

  • 单模型在某些步骤明显不经济
  • 不同步骤的能力偏好差异明显
  • 需要额外校验或审校环节
  • 需要显式的人机协同与审批
  • 需要把不同 specialist 的 instructions、tools 或 policies 隔离开

2. 先决定角色，不要先决定模型数量 ​

OpenAI 当前 Agents 官方资料明确指出，多 agent workflows 特别适用于：

  • 不同 specialist 需要不同 instructions、tools 或 policies

这句话对多模型协同的启发非常直接：

  • 先定义角色，再给角色选模型

2.1 更常见的角色拆法 ​

  • router：分类、风险判断、路径选择
  • planner / manager：拆任务、决定下一步
  • specialist：在某一类任务上深做
  • checker / judge：做结构、引用、一致性或安全复核
  • executor：把结构化结果变成工具调用或状态变更

2.2 为什么“角色优先”更稳 ​

因为这样你更容易明确：

  • 每个角色看什么输入
  • 每个角色产出什么 artifact
  • 每个角色失败时怎么回退
  • 每个角色能不能被更换模型而不影响全局

2.3 一个很常见的误区 ​

很多团队会说：

  • “上个强模型，再加一个便宜模型兜底”

这在工程上往往不是协同，只是：

  • 没有清楚职责的混合调用

3. 单模型不一定适合所有步骤，而且不同模型的差异不只在“聪明” ​

Anthropic 当前 Choosing the right model 把模型选择归成三件事：

  • capability
  • speed
  • cost

OpenAI 当前 Reasoning best practices 也明确提醒：

  • reasoning 模型更适合复杂规划和多步问题
  • 不应该默认所有步骤都上 reasoning

这两组官方结论放在一起，基本就能推出协同编排的基础原则：

  • 不是所有步骤都该由“最强模型”来做

3.1 哪些步骤更适合强推理模型 ​

  • 复杂规划
  • 路径选择
  • 高风险决策建议
  • 多约束冲突判断

3.2 哪些步骤更适合快模型或便宜模型 ​

  • 意图分类
  • 结构化清洗
  • query rewrite
  • 简单总结
  • 低风险格式转换

3.3 哪些步骤更适合工具或规则，不该继续靠模型 ​

  • schema 校验
  • 枚举检查
  • 权限判断
  • 超时与重试策略
  • 幂等控制

4. handoff 和 agents-as-tools 是两种完全不同的协同方式 ​

OpenAI 当前 Orchestration and handoffs 明确给出了一个很重要的设计问题：

  • specialist 是接管会话，还是只在后台给 manager 提供能力

这基本对应两条路。

4.1 handoff：由 specialist 接管接下来的会话或分支 ​

更适合：

  • specialist 应该拥有后续对话
  • specialist 有自己独立的 tools、guardrails 和 policies
  • specialist 要对用户最终结果负责

例如：

  • 从通用客服 handoff 到法务 specialist
  • 从总控 agent handoff 到某个高风险审批分支

4.2 agents-as-tools：specialist 留在幕后 ​

更适合：

  • manager 仍然保留最终回答权
  • specialist 只负责一段能力
  • specialist 产出的是中间 artifact，而不是接管整个用户界面

例如：

  • manager 调用 query-rewrite specialist
  • manager 调用 citation-check specialist
  • manager 调用 pricing specialist 做结构化判断

4.3 两者的工程差异 ​

handoff 更像：

  • 会话所有权切换

agents-as-tools 更像：

  • 后台能力组合

如果这一步没想清楚，系统很容易出现：

  • 谁该对最终答案负责不清楚
  • tools 和 guardrails 权限边界混乱
  • trace 里看不出谁真正决定了下一步

5. 编排方式至少要分三种：顺序、并行、评审 ​

很多文档只讲“多 agent 协作”，但工程里至少要把拓扑想清楚。

5.1 顺序链 ​

典型形态：

text
router -> planner -> producer -> checker -> finalizer

适合：

  • 有明确阶段顺序
  • 每一步依赖前一步 artifact

优点：

  • 易解释
  • 易回放

缺点：

  • 链路长
  • 延迟容易拉高

5.2 并行链 ​

典型形态：

text
manager
 -> specialist A
 -> specialist B
 -> specialist C
 -> merge / judge

适合：

  • 多证据源汇总
  • 多模型多视角判断
  • 不同模态并发预处理

优点：

  • 更快
  • 更适合复杂输入分治

缺点：

  • merge 成本高
  • artifact 对齐更难

5.3 评审链 ​

典型形态：

text
producer -> checker -> revise / escalate

适合：

  • 结构化抽取
  • 引用核验
  • 高风险建议
  • 生成后安全复核

优点：

  • 风险更可控

缺点：

  • 如果 checker 变成第二个主模型，链路会越来越重

6. manager 模式和 graph / state machine 模式不是一回事 ​

这是很多团队最容易混的地方。

6.1 manager 模式 ​

更像：

  • 一个主控 agent 决定接下来让谁做什么

优点：

  • 灵活
  • 更接近自然任务调度

风险：

  • 决策不透明时更难预测成本
  • 容易出现路径漂移

6.2 graph / state machine 模式 ​

更像：

  • 流程由代码或状态机显式定义

优点：

  • 稳定
  • 容易审计
  • 适合审批、回退、重试和恢复

风险：

  • 灵活性更低
  • 初始设计更重

6.3 当前官方资料给的一个现实建议 ​

OpenAI 当前 Agent orchestration 文档明确说：

  • 你可以让 LLM 决定流程
  • 也可以由代码决定流程
  • 两种方式可以混用

这意味着最稳的企业方案通常不是二选一，而是：

  • 普通灵活任务让 manager 决定
  • 高风险、可恢复、要审批的路径由代码或状态机收口

7. 模型之间传递的不是“全量历史”，而应是最小必要 artifact ​

多模型协同特别容易出现一个问题：

  • 每一步都把所有历史和原始资料全量传给下一个模型

这会直接带来：

  • token 成本飙升
  • 延迟增加
  • 噪音累积
  • 权限和租户边界更难控制

7.1 更好的做法是按角色裁剪上下文 ​

例如：

  • router 只看任务描述与少量元信息
  • producer 看检索证据和业务约束
  • checker 看主答案、引用和 schema

7.2 artifact contract 比“自然语言交接”更重要 ​

更稳的角色间交接对象通常至少要明确：

  • artifact_type
  • schema_version
  • source_refs
  • risk_bucket
  • confidence_hint
  • next_action_hint

7.3 为什么 artifact contract 特别关键 ​

因为没有它，后面会很难判断：

  • 上一步到底产出了什么
  • checker 到底在验证什么
  • fallback 后还能不能继续跑

8. 并行不代表都该同时跑，先判断是否值得 fan-out ​

并行是多模型协同里最容易被滥用的一种能力。

8.1 真正值得并行的场景 ​

  • 多模态预处理彼此独立
  • 多个外部知识源可以并发
  • 多个 specialist 的结果需要汇总比对
  • latency 比成本更敏感

8.2 不值得并行的场景 ​

  • 后一步强依赖前一步输出
  • 最终 merge 比单模型本身还重
  • 每个 specialist 都在看几乎同样的上下文

8.3 一个很常见的错误 ​

为了“显得高级”，把：

  • 改写
  • 检索
  • 生成
  • 审校

同时 fan-out，最后再人工 merge。

这通常只会得到：

  • 更慢
  • 更贵
  • 更难解释

9. 背景任务、批处理和异步 lane 应该直接进入协同设计 ​

很多团队做协同时只看模型分工，不看运行 lane。

但真实系统里，是否同步执行，往往比“多一个模型还是少一个模型”更影响成本和体验。

9.1 哪些步骤更适合后台 ​

  • 大规模检索回放
  • 多 specialist 并行汇总
  • 复杂审校
  • 低优先级批量生成

9.2 哪些步骤更适合同步 ​

  • 用户在等待的分类
  • 首轮路径选择
  • 快速澄清
  • 小型只读工具决策

9.3 协同编排不该只返回“最终答案” ​

更成熟的系统往往还会返回：

  • queued
  • awaiting_approval
  • requires_handoff
  • background_review

这些状态。

10. 编排为什么要和回退策略、质量门禁一起设计 ​

只要链路里有多个模型，就要考虑：

  • 某个模型不可用怎么办
  • 某一步输出异常怎么办
  • 是否需要跳过某个角色直接降级
  • 是否需要直接转人工

所以协同编排最好和：

  • 多模型回退
  • 质量门禁
  • 风险分层路由

一起设计。

10.1 某一步失效，不代表整链必须失败 ​

例如：

  • checker 不可用时，是否可以降级到规则校验
  • planner 不可用时，是否可以走默认路径
  • 并行 specialist 缺一个时，是否仍可出低置信结果

10.2 有些步骤失败后应该直接转人工 ​

尤其是：

  • 高风险动作
  • 审批建议
  • 合规敏感问答
  • 会改变外部状态的执行

这类场景里，“继续自动化尝试”不一定比“立即转人工”更好。

10.3 一个更像生产系统的 gate 对象 ​

  • quality_gate
  • safety_gate
  • approval_gate
  • fallback_gate

每个 gate 都应该能回答：

  • 谁触发
  • 用什么证据判断
  • 失败后去哪条支路

11. 如何评估协同编排是否真的有效 ​

更稳妥的做法通常是：

  • 对比单模型路径和多模型路径
  • 回放关键任务样例
  • 分析质量收益是否覆盖新增成本

11.1 评估时至少要拆四层指标 ​

第一层：

  • 任务结果质量

第二层：

  • 结构化稳定性 / 工具调用成功率 / 引用质量

第三层：

  • 成本、延迟、调用次数

第四层：

  • 人工接管率 / 审批率 / 回退率

11.2 不要只看平均值 ​

还要特别看：

  • 高风险场景
  • 长上下文场景
  • 工具密集场景
  • 多轮场景

11.3 更适合的结论不是“更强”，而是“在哪更值” ​

例如：

  • 在复杂审批场景更值
  • 在普通 FAQ 场景不值
  • 在长文抽取里 checker 值得保留
  • 在简单摘要里 planner 层不值

这种结论才有助于后续路由与编排收敛。

12. OpenAI Agents 的 orchestration 思路对我们有什么启发 ​

OpenAI 当前 Agents 官方资料与 SDK orchestration 指南强调：

  • 从工作流设计角度看 agent flow
  • 先决定谁拥有最终用户可见答案
  • specialists 可以 handoff，也可以 stay behind a manager

这些对多模型协同同样适用。

12.1 不要先问“要几个模型”，先问“要几个角色” ​

角色清楚后，模型数量通常自然会收敛。

12.2 handoff 规则必须显式 ​

要明确：

  • 什么条件下进入下一个角色
  • 传递什么上下文
  • 失败后回哪一步

12.3 sessions、tracing、guardrails、approval flows 都是协同的一部分 ​

OpenAI 当前 Agents 指南明确提到：

  • built-in sessions
  • tracing
  • guardrails
  • resumable approval flows

这说明编排不是只有：

  • “模型 A 调模型 B”

还包括：

  • 工具
  • 人工审批
  • 状态流转
  • trace
  • 可恢复暂停点

13. Anthropic 当前资料给协同设计的另一个现实提醒 ​

Anthropic 当前 Choosing the right model 和 Tool use overview 给了两个很实际的提醒：

  • 选型永远要同时看 capability、speed、cost
  • tool use 的执行位置和职责边界必须清楚

这对多模型协同的启发很直接：

  • specialist 不是越强越好，而是越适合该步骤越好
  • tool-calling specialist 不能只看生成文本效果，还要看参数稳定性和执行语义

如果忽略这两点，系统很容易变成：

  • 账面很复杂
  • 运行并不更稳

14. 更适合企业的最小协同编排方案 ​

如果团队还没有成熟体系，建议至少从下面这套最小方案开始：

  1. 先定义角色，而不是先堆模型。
  2. 为每个角色定义输入、输出和禁止事项。
  3. 限制角色间传递的上下文范围。
  4. 为每个角色建立局部 eval。
  5. 把回退与人工接管写入编排状态机。
  6. 统一 trace 每一步的决策与耗时。
  7. 把 gate、approval 和 resume 点显式建模。

这套最小方案已经足够支持多数企业内的多模型系统。

15. 常见反模式 ​

15.1 模型变多了，职责却没变清楚 ​

这是最常见的问题之一。

15.2 每一步都传全量历史 ​

结果通常是：

  • 更贵
  • 更慢
  • 更脏

15.3 checker 变成第二个主模型 ​

这样会让链路越来越难解释。

15.4 没有角色级 eval ​

最后只能看到全链路好不好，却看不出哪一步出了问题。

15.5 编排和回退分开设计 ​

这样一旦某个角色失效，整条链往往没有自然降级路径。

15.6 并行 fan-out 不受控 ​

结果是：

  • 成本爆炸
  • merge 更难
  • trace 更难读

16. 这章最值得立刻补上的实践动作 ​

  1. 把你现在的“多模型流程图”改成“角色图 + artifact 图”，不要再只写模型名。
  2. 为每个角色补输入、输出、禁止事项和 fallback 规则。
  3. 明确哪些 specialist 应该 handoff，哪些更适合作为 agents-as-tools 留在后台。
  4. 为并行步骤建立 merge contract 和失败降级路径，不要等并行上线后再补。
  5. 给每个角色单独建 eval，不要只看全链路平均分。
  6. 把 approval、guardrails、trace 和 resume 点显式接进状态机。

17. 推荐搭配阅读 ​

18. 重点官方资源 ​

以下入口在 2026-07-09 复核可访问：