GitHub Copilot 双更新：GPT-6 Astra 正式上线，HydraFusion 开启多模型编排

AI 编程工具的能力，正在从生成一段代码，延伸到规划任务、执行修改、检查结果，并持续推进直至完成。与此同时，开发者也面临一个越来越实际的问题：模型选择更多了，怎样才能让合适的模型以合适的方式完成任务？

GitHub 最近公布的两项进展，分别体现了模型能力与任务执行方式的演进。GPT-6 Astra 提升了单个模型承担复杂编码工作的能力；HydraFusion 则把关注点进一步扩展到整个任务的执行方式。

OpenAI 最新通用模型 GPT-6 Astra 已在 GitHub Copilot 正式推出（GA），重点面向需要长周期执行的自主编码与智能体任务。

GitHub 在内部测试中关注到的亮点，是它完成任务的过程：GPT-6 Astra 会边执行边规划和验证，将诊断与验证一并批量执行，并在宣布任务完成前，独立确认自己的结果。

据 GitHub 介绍，相比此前的 OpenAI 模型，这种工作方式让 GPT-6 Astra 在长周期编码任务中表现更好，所需步骤也更少。这里强调的能力已经覆盖从制定方案到验证结果的连续过程。

谁可以使用？GPT-6 Astra 面向 Copilot Pro+、Max、Business 和 Enterprise 用户开放。你可以在以下入口的模型选择器中选择它：

模型正在逐步推出；符合套餐条件的用户如果暂时未在模型选择器中看到，可以稍后再查看。

企业如何管理？Business 和 Enterprise 管理员可以通过 Copilot 设置中的 model policy（模型策略）管理访问。按照默认启用新模型机制，除非管理员关闭全局默认选项，或明确禁用该模型，新模型会自动启用。

如何计费？GPT-6 Astra 采用 usage-based billing（按用量计费），按照模型提供商的公开标价收费。套餐开放范围与模型使用费用，需要结合官方计费说明一并理解。

为开发者提供适合当前任务的模型，一直是 GitHub 的目标。今年早些时候推出的 Auto model selection，会分析任务并匹配合适的模型。Project HydraFusion 则把关注点进一步扩展到解决任务的整个流程。

HydraFusion 目前以研究预览的形式推出，是一个运行时多模型编排系统。它会制定完整的执行计划，从不同提供商的模型中选择合适的模型，完成初稿生成、审阅和修订，或以级联方式升级到更强的模型来解决任务。

GitHub 的整体战略，是基于语义在本地模型、云端模型和复合模型之间实现自动路由，HydraFusion 在其中发挥着关键作用。开发者只需像选择普通模型一样选择 HydraFusion，由它在幕后为每个任务选择兼顾质量、成本和延迟的工作流。

HydraFusion 将工作流选择视为一个优化问题：参考模型在 推理、代码生成、调试和工具使用等方面的能力信号，选择能够达到质量要求的最高效执行方式。目前，每个请求会采用以下三种执行模式之一。

Single：一个模型直接完成

由一个选定的模型直接解决任务。当单个模型足以满足要求时，这种方式可以保持速度与效率。

Cascade：先高效尝试，再按需升级

先由高效模型生成方案，再由质量门控判断是否接受。如果候选方案没有达到验收要求，就升级到更强的模型，继续解决任务。

Critique：独立审阅后，再修订一次

一个模型先生成结果，再由来自不同模型家族的独立、只读审阅模型检查，最后由原模型修订一次。它采用与 Rubber Duck 相同的审阅模式，为那些审阅比再次独立尝试更有帮助的任务引入另一个视角。

图 1：HydraFusion 架构。来源：GitHub。

开发者已经会手动协调多个模型：为任务选择一个模型，请另一个模型审阅结果，或把棘手问题交给能力更强的模型。HydraFusion 将这一熟悉的过程纳入运行时。选择一次后，开发者可以继续专注于任务，由它管理模型和工作流。

关键在于按需选择。有些任务可以直接解决，另一些则能从审阅、修订或升级中获益。HydraFusion 会评估每个请求，选择预计能够满足需求的最简单工作流，只有在额外模型调用可能改善结果时才增加调用，在多个模型之间平衡质量、成本和延迟。

模型池也会随着前沿模型的进步而演进。GitHub 表示，当新模型在 Copilot 中推出时，团队可以对其进行评估并纳入 HydraFusion 模型池，让不同模型在最适合的任务上发挥优势。

要把自适应多模型编排转化为可靠、统一的编码体验，需要谨慎控制执行、审阅、成本和代码仓库状态。HydraFusion 围绕五项运行原则构建：

这些原则共同让多模型编排能够用于代码仓库级工作。在内部，运行时记录每个环节的角色、结果、成本、延迟和诊断信息，便于执行后了解工作流的运行情况；开发者最终收到一个连贯的响应，以及一组受权限控制的更改。

展示进度，同时避免展示未完成的工作

GitHub 在 TerminalBench 2.1、DeepSWE 和 CheckpointBench 三项智能体编码基准上，评估了固定的 HydraFusion 策略，并使用 Claude Opus 5 和 GPT-5.6 Sol 作为对照基线。

各策略采用相同的任务输入、工具、执行限制、定价假设、评分条件和缺失结果处理方式。原文将“经验证任务质量”概括为确认正确完成的任务占比，同时衡量完整的估算工作流成本。成本覆盖每个实际调用的环节，包括初稿生成、审阅、修订、升级、重试和回退。

原文汇总表给出了调优后表现最佳的 HydraFusion 配置相对于 Claude Opus 5 的结果：

4.9 个百分点表示质量指标的绝对差值，而非相对提升 4.9%。从三项结果看，HydraFusion 在 TerminalBench 2.1 上超过了受测 Opus 5 基线，在另外两项基准中以小幅质量差距换取了较大的估算成本降幅。

这些数字来自受控离线评测，仅对应所评估的基准版本、工作流配置、模型池和定价假设；所有模型均采用相同的中等推理强度。GitHub 将通过研究预览，验证这些结果能否延续到开发者的实际工作负载，并进一步优化生产环境质量、延迟、可靠性、缓存效率、成本和安全性。

TerminalBench 2.1：终端中的复杂多步骤任务

TerminalBench 2.1 用于评估编码智能体在终端环境中完成复杂、多步骤任务的能力。下图从任务解决率和估算工作流成本两个维度，对比 HydraFusion、Opus 5 及其他受测模型。

图 2：纵轴为单次尝试任务解决率（pass@1），横轴为每项任务的平均成本（美元）。来源：GitHub。

DeepSWE：大型代码仓库中的端到端修复

DeepSWE 评估高难度的代码仓库级软件工程任务，要求智能体浏览大型代码库、理解跨文件依赖，并完成端到端修复。在这项基准中，HydraFusion 的质量比 Opus 5 低 1.5 个百分点，估算成本降低了 36%，体现了复杂工程任务中质量与成本之间的权衡。

图：DeepSWE 的任务解决率（pass@1）与每项任务平均成本。来源：GitHub。

CheckpointBench：从真实编码会话构建多轮基准

图：CheckpointBench 的 276 个开发者检查点，按编程语言、任务难度和任务类型展示分布。简单、中等、困难任务分别占 42.0%、38.8% 和 19.2%。来源：GitHub。

CheckpointBench 是一项内部多轮基准，整理自真实的 GitHub Copilot 智能体编码会话。每段对话都关联到特定的公共代码仓库和不可变的提交，确保每个会话都可以重放。

该基准在编程语言、任务类型和难度上保持平衡，并经过数据清理以保障质量，形成一组贴近生产环境智能体会话的真实评测任务。在这项基准中，HydraFusion 的质量比 Opus 5 低 0.1 个百分点，估算成本降低了 65%。

图：CheckpointBench 的纵轴为平均会话得分（Mean session score），横轴为每项任务平均成本；指标口径与 TerminalBench 2.1、DeepSWE 图中的 pass@1 不同。来源：GitHub。

早期内部测试也得到了类似的反馈。一位微软首席软件工程师表示：

HydraFusion 的路由策略参考了开发者在真实编码任务中使用 GitHub Copilot 的方式。为了让这些工作流可以复现，GitHub 从真实 Copilot 编码会话轨迹中整理出 CheckpointBench，并在 CheckpointBench、DeepSWE 和 TerminalBench 2.1 上反复改进 HydraFusion，针对多个评测集进行优化，而非只优化某一项基准。

HydraFusion 在各项能力上的评分，为比较候选路由策略提供了一致的依据。团队没有手动调整阈值，而是使用束搜索（beam search）构建最优决策策略。每个候选策略都与固定基线比较质量、成本和失败模式，确保改进建立在稳定的评估基础上。

TerminalBench 2.1 保留了最完整的一系列运行记录，因此最能清楚呈现这种迭代改进。改进过程并非直线上升：在 8 月 11 日至 8 月 25 日 期间，评测框架发生了两次运行故障，产生了无效测试。这些测试被排除在性能趋势之外；故障修复后，HydraFusion 的各项配置继续取得进展。到 8 月 25 日，HydraFusion 在这一系列已记录的运行中取得了最佳表现。

图：HydraFusion 的开发迭代记录。原图标题中的 91.8% 使用 best-of-2 equivalent 口径，与前文 TerminalBench 2.1 基准图的 pass@1 不同。来源：GitHub。

这份开发记录展示了策略如何通过反复实验得到改进。TerminalBench 2.1 是开发过程中使用的多项基准之一。由于它的表现已相对趋于饱和，更广泛的验证尤为必要，因此三项基准的评测也纳入了 DeepSWE 中更具挑战性的代码仓库级任务。研究预览则将这一学习循环延伸到开发者的实际工作负载。

GPT-6 Astra 已 GA；HydraFusion 目前处于研究预览阶段。两者的开放范围和使用入口需要分别看待。

HydraFusion 目前通过 GitHub Copilot CLI 中的 /experimental 功能，面向所有 GitHub Copilot 套餐用户提供。启用步骤为：

HydraFusion 按实际调用的各模型所消耗的 token 计量，并按各模型的标准费率收费。因此，单次任务的费用会随采用的模型和执行路径变化。

本次预览旨在了解哪些任务能够从复合工作流中受益，以及编排在实际使用中如何影响延迟和成本。GitHub 建议现阶段从首轮、单提示词的编码任务开始，选择有一定工作量、范围清晰、能够用一条提示词交给 autopilot 模式下的 Copilot 的任务。团队接下来将重点提升更长、需要持续迭代的会话中的多轮表现。

开发者可以通过 Copilot CLI 中的 /feedback 或 GitHub Community 讨论分享发现，包括表现出色之处、不足，以及希望接下来看到的改进。

虽然离线评测已经包含多轮基准，但研究预览在实际长会话中的表现仍需继续验证。HydraFusion 仍是一项持续推进的研究，其结果、模型、工作流、可用范围、名称和产品行为，都可能随着研究推进而变化。

把两项发布放在一起看，可以看到 GitHub Copilot 正沿着两个相互呼应的方向发展：GPT-6 Astra 提升模型承担长周期、自主编码任务的能力；HydraFusion 则探索如何组织不同模型，让生成、审阅、修订和升级形成一套按任务选择的执行流程。

GitHub 认为，编码智能体的下一次实质性进步，将来自前沿智能与运行时编排的结合。HydraFusion 是团队在这一方向上的首次投入：从选择最佳模型，走向动态构建解决每个任务的最佳方式。

对开发者和技术团队而言，值得持续观察的是同一个结果：当任务变得更长、更复杂时，Copilot 能否更可靠地完成工作，并把质量、成本与等待时间放在一起优化。这也是这两项进展共同指向的变化。