GitHub HydraFusion Copilot CLI 指南：运行时路由机制

一项编码任务看起来可能很简单，直到它牵涉到跨文件依赖。Project HydraFusion 会选择它认为能够达到质量标准的工作流，但研究预览版目前不会展示完整路由，也不保证每个代码仓库都能获得同样的成本节省。

一张表看懂路由决策

Project HydraFusion 是 GitHub Copilot CLI 中的运行时编排层，并不是一种新的基础模型。你选择 HydraFusion (Research Preview) 后，具体使用哪些模型、采用怎样的执行方式，会由运行时决定。

想试用预览版，先运行 /update，再运行 /experimental on，然后运行 /model，选择 HydraFusion (Research Preview)。GitHub 在官方 HydraFusion 公告中记录了这套流程。所有 Copilot 计划均可使用该预览版，但如果账号由组织管理，能否访问还取决于管理员启用的Copilot CLI 策略。

这些是执行模式，并不是三个可以让用户手动强制请求进入的公开开关。发布材料介绍的是选择 HydraFusion，然后让运行时在性能、成本和延迟之间进行平衡。

运行时究竟在预测什么

GitHub 表示，HydraFusion 会参考推理、代码生成、调试和工具调用等能力信号，选择它认为能够达到请求质量标准的最高效执行模式。不过，GitHub 并未公布具体阈值，也没有给出类似“改动三个文件就使用 Cascade”这样的确定性规则。

因此，任务形态只能作为判断方向，不能视为路由保证：范围较小、测试路径明确的修改，概念上更适合 Single；难度可能较高的请求，适合 Cascade 的选择性升级；如果任务受益于独立复核，则更适合 Critique。公告没有提供每个请求固定对应的模型清单，也没有提供可读的路由追踪记录。

能强制使用 Single、Cascade 或 Critique 吗？

GitHub 记录的用法是选择 HydraFusion，然后让运行时自行决定工作流；官方并未提供强制使用这三种模式之一的公开命令。如果你需要可预测的路由，就应该改用固定的 Copilot 模型。

什么时候值得为额外调用买单

Single：路径明确时直接执行

Single 会让任务进入 Copilot 常规的、遵循权限控制的智能体循环，由一个求解器完成处理。它适合小型且定义清晰的修改、简短说明，或者实现方式和测试路径都很明确的修复。

它的优势在于成本和延迟更容易预测。该工作流不会主动加入质量门槛或第二种意见，因此如果求解器误解了任务，开发者仍然是主要审查者。

Cascade：只有第一轮不够好时才升级

Cascade 会先调用高效模型。质量门槛会评估候选结果；如果结果没有达到要求，就可以把任务升级给更强的模型。

它的经济逻辑是有条件的：

1. 先由第一个模型处理它能够充分完成的工作。
2. 质量门槛筛掉质量不足或存在不确定性的候选结果。
3. 只有确实需要更强能力的任务，才会进入更强模型的路径。

与把每个任务都交给前沿模型相比，这种方式可能降低平均工作流成本。但升级、重试或回退仍可能拉高成本和延迟的尾部表现，而且 GitHub 尚未公布适用于所有代码仓库规划任务的通用升级比例。

Critique：为第二种视角付费

Critique 是一个“起草—评审—修订”循环。第一个求解器生成结果，来自不同模型家族的评审器在隔离、无工具且只读的环境中进行审查，原始求解器随后修订一次。

评审器不能运行项目测试，不能通过命令检查生成文件，也不能自行修复问题。Critique 买到的是评审视角的多样性，而不是独立完成端到端实现的能力。

基准测试账本：成本更低，不等于质量承诺只有一种

GitHub 在三项智能体编码基准测试中，将固定 HydraFusion 策略与 Claude Opus 5 进行了比较。以下数据来自GitHub 官方公告。

质量结果并不完全一致，这恰恰是重点：HydraFusion 的目标不是每次请求都使用更多模型，而是在预期质量提升足以抵消成本和延迟时，才增加推理环节。

GitHub 表示，评估统一了输入、工具、执行限制、价格和评分方式，并统计了起草、评审、修订、升级、重试和回退等环节。这些仍然是与特定评估策略、模型池、基准版本和定价假设绑定的受控离线估算。

这些数据并不能证明普通 Copilot 任务一定会便宜 67%，也不能证明 HydraFusion 在某个具体代码库中一定胜过 Claude Opus 5。GitHub 建议，在使用预览版测试真实工作负载时，先从规模较大、范围明确、能够在一条提示中完成的首轮编码任务开始。

成本方程有三个维度

评估 HydraFusion 时，要把预期 Token 成本、尾部成本和等待时间分开看。

预估工作流成本更低，并不自动意味着响应更快：Cascade 在需要升级的任务上可能变慢，Critique 会增加串行评审，而 Single 虽然返回更快，却会把更多验证工作留给开发者。

GitHub 的Copilot CLI 使用文档显示，/usage 可以查看会话时长、消耗的 AI Credits、修改行数以及按模型拆分的 Token 使用情况。这些数据有助于比较真实任务，但无法解释每一次路由决策，也不会展示被丢弃的中间草稿。

提示词与补丁之间的黑箱

GitHub 表示，系统会完整记录各个工作流环节，提供带超时和取消行为的有界执行、隔离评审、经过验证的路由，以及在工作流无效或被取消后安全应用补丁的机制。这些控制措施能够降低运行风险，但不能证明路由一定正确，也不能证明最终代码一定正确。

GitHub 还表示，预览版会保留中间草稿，直到能够返回一个连贯的最终结果。这让用户很难判断某项任务究竟一直使用 Single、通过 Cascade 升级，还是经过了 Critique 和修订。

一位真实用户直接指出了这一可观测性缺口：

“我希望产品下一步增加的功能，是一份可读的追踪记录，说明哪个模型做了什么，以及路由器为什么切换。”——X 用户 @_Mazzana

没有路由回执，开发者就无法完整地把任务的成本、延迟和最终补丁，与生成它们的工作流对应起来。

如何测试预览版，避免过度解读

在把 HydraFusion 设为团队默认方案之前，先把它当成一次实验：

1. 创建干净的分支或 worktree，并记录起始提交。
2. 分别测试一个常规修复、一个跨文件修改和一个含义模糊的任务，并为每个任务准备可复现的验收检查。
3. 在第一条提示中写清预期行为、约束条件和测试命令。
4. 检查最终 diff，确认没有修改无关文件，并自行运行相关测试。
5. 记录会话时长、可见的 AI Credit 或 Token 使用量、测试结果，以及任何可见的重试或升级信号。
6. 在与固定模型进行比较前，先覆盖多个任务。

不要仅凭响应长度猜测隐藏模式。响应较长，可能只是因为代码仓库更复杂，并不代表使用了 Critique。在长流程、多轮交互、对延迟敏感或后果严重的任务中，保留固定模型作为备选方案：GitHub 针对当前预览版推荐首轮任务，并在其发布指南中将更强的多轮表现列为未来重点。

HydraFusion 常见问题

我能手动选择 Single、Cascade 或 Critique 吗？

目前没有文档记录的 HydraFusion 模式命令可以做到这一点。当前的控制方式是选择 HydraFusion，然后让运行时自行决定；如果确定性的路由更重要，请使用固定模型。

HydraFusion 如何计费？

GitHub 表示，使用量取决于 HydraFusion 所调用模型消耗的 Token，并按照每个模型的标准费率分别计费，具体说明见官方公告。基准测试中的成本下降并不等于面向所有客户的统一折扣，而且多环节工作流的消耗可能高于直接请求。

当一项任务足够重要，值得通过选择性升级或评审来提升质量，同时又足够结构化、能够完成验证时，HydraFusion 最有吸引力。对于快速任务，Single 的简单性可能更重要；对于长期或高风险工作，在有足够的代码仓库数据证明额外编排值得之前，可预测的固定模型行为仍可能是更好的运营选择。