一个被反复引用的判断
9 月 4 日，GitHub 把 Project HydraFusion 作为研究预览放进了 Copilot CLI。它的形态不是多一个模型可选，而是把选择这件事从用户手里拿走：你选 HydraFusion，它按每个请求现场决定由哪些模型、按什么顺序来完成这次任务。微软方面把它描述为从选模型到编排模型的转移。
这句话值得单独拎出来看，因为它否定的正是过去两年企业采购 AI 编程工具的默认动作——先挑一个榜单上的前沿模型，再把其余都当配置。如果这个前提被推翻，那么工具的价值就从背后是哪个模型，变成了编排层怎么组织这些模型。
三种执行形态
HydraFusion 目前内置三种形态，按任务复杂度与上下文现选一种。
单模型直解，适用于系统判断一个模型就足以完成的任务，优化目标是速度与延迟。
级联，先让成本更低的模型出草稿，再由一道质量门判断是否达标；达标就接受，不达标才升级到更强的模型重做。多数任务理论上不会走到最贵的那一端。
交叉评审，由模型甲出方案，再由来自不同模型族、且只读不可写的模型乙独立审阅，最后由模型甲完成一次结构化修订。评审环节被刻意放在没有工具权限的上下文里，评审者读得到、改不了。
选择策略不是手工阈值，而是用能力信号配合束搜索，在质量、成本与失败率之间搜出一组配置。GitHub 为这套策略列了五条运行原则：完整计费，草稿、评审、修订、升级、重试、回退每一段都汇总进同一个成本数字；有界执行，每段都有明确的超时与取消行为；隔离审阅，评审在无工具上下文中进行；失败不落地，校验失败或被取消时不应用任何部分补丁；执行前校验路由，确认模型绑定与可用性之后再开始跑。
基准数字要分开读
发布材料给出的三组离线评测结果，需要拆开看。
在 TerminalBench 2.1 上，相对被设为参照的 Claude Opus 5，验证任务质量提升约 4.9 个百分点，估算成本降低约 67%。在 DeepSWE 上，成本降低约 36%，但质量下降约 1.5 个百分点。在内部多轮基准 CheckpointBench 上，成本降低约 65%，质量几乎持平，差约 0.1 个百分点。
把质量那一列先读一遍，结论就清楚了：三个基准里，只有一个出现了质量提升，另两个是持平或下降。GitHub 自己的总结也相对克制，用的是匹配或超过被评估的基线、同时降低估算成本，并指出 TerminalBench 2.1 存在相对饱和，需要更广泛的验证。可带走的说法是成本降三到六成、质量大致持平，而不是更便宜还更强。
还有两条范围限制需要一并说明。这些数字来自固定基准版本、固定模型池与固定价格假设下的离线评测，且所有模型都在同一档推理强度下运行；预览版目前也只覆盖首轮、单提示的任务，多轮表现被列为后续工作。
这套编排真正改变了什么
值得展开的不是三个形态本身，而是它们各自要解决什么问题。
级联的成本机制来自概率：只要多数请求能被便宜模型解决，贵模型就只在没过的残余上被调用，支出跟着升级率走，而不是跟着请求数走。这个思路在推理成本优化里已经讨论过一段时间，HydraFusion 的新意在于把它做成了默认行为，而不是需要用户自己搭的流水线。
交叉评审的机制则依赖独立性，而不是多调一次模型。让同一个模型检查自己的输出，缺少外部信号，实践中有研究指出模型在没有外部反馈时的自我纠正能力有限，有时甚至会让表现变差。换一个模型族、放进一个没有工具、也读不到仓库的上下文里做审阅，补的正是这个缺失的信号。
反过来，边界也很明确。评审模型无法越过起草模型：它只能评估，不能改写。这意味着当起草模型整体方向就偏了，独立审阅未必能把它拉回来。评审提供的是纠错信号，不是能力上限。
对采购与工程的两点提醒
其一是成本可预测性的变化。按官方说明，计费仍按实际调用的每个模型的 token 单价结算，没有额外的编排费用。好处是不为用不到的能力付费，代价是单次任务的成本变得难以事先估计——它取决于这次请求触发了哪种形态。对按量结算的团队，这需要在监控口径里把任务级成本分布单独建出来，而不是只看月度总额。
其二是质量分布的管理。编排买到的是成本，不是均匀的质量。任务形态决定你落在分布的哪一侧，而多数团队目前没有工具逐任务判断自己落在哪一侧。可行的做法是把高风险任务单独圈出来，强制走更保守的配置，其余任务再享受降本。
至于多轮任务、跨仓库场景以及更细的路由策略，预览版尚未覆盖。目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。