GitHub 实际发布了什么
帖子中有五点对这个问题至关重要，而且这五点都是 GitHub 自己的原话。
第一，决策单元。“对于每个请求，HydraFusion 目前会选择三种执行模式之一。”它们是：Single（单模型），即“一个选定的模型直接解决任务”；Cascade（级联），即“一个高效的模型起草解决方案，质量网关决定是接受它还是升级到更强大的模型”；以及 Critique（评审），即“一个模型起草结果，来自不同模型家族的独立只读评审器对其进行审查，起草模型修改一次”。
第二，评审器被刻意隔离。GitHub 将“隔离评审”列为五个运行原则之一：“在隔离的、无工具的上下文中运行评审步骤，而解决器步骤则使用共享工作区和正常的权限感知智能体循环。这允许模型独立评估工作，而无需修改仓库。”评审器只读。它不能触碰您的文件，也不携带您的工具。
第三 —— 报道完全忽略的一句话 —— 发生了什么的记录是存在的，但在墙的另一侧。“在内部，运行时记录每个分支的角色、结果、成本、延迟和诊断，以便在执行后理解工作流。在外部，开发者会收到一个连贯的响应和一个权限感知的变更集。”
第四，中间工作被刻意保留，GitHub 解释了原因：“目前：HydraFusion 会显示工作流阶段，但会保留中间草稿，直到返回一个连贯的结果，”因为“这些草稿可能会被评审、修改或丢弃，因此实时显示它们可能会让未完成的工作看起来像是最终结果。”GitHub 指出了这一权衡，而不是将其隐藏 —— “在没有足够可见性的情况下等待对开发者来说是一个真正的权衡” —— 并表示正在“积极探索更好的进度更新”。
第五，预览版本身的范围。“对于此预览版，首轮、单提示词的编码任务是最好的起点。接下来我们将专注于具有更长、迭代会话的强大多轮表现。”GitHub 还指出，“随着我们从预览版中学习，结果、模型、工作流、可用性、名称和产品行为可能会发生变化。”它在所有方案中通过 Copilot CLI 中的 /experimental 运行。
这五点共同描述了一个经过优化的系统，旨在为每个请求向您提供一个干净的答案 —— 这是一个合理的设计目标，在其中，产生答案的推理过程是一个运行时产物，而不是持久的产物。
这改变了什么，没有改变什么
它不会改变一个好的指令文件的作用。Copilot 仍然会读取您的指令文件，GitHub 两天前的官方工程文章明确了这一机制：“提示词携带塑造智能体工作方式的指令，并且它们在每轮中都会发送给模型。”指令是被重新发送的，而不是被记住的。在使用单个模型时就是如此，在使用三个模型时同样如此。
它确实改变了谁在进行累积。在单模型会话中，至少存在一种直觉 —— 通常是错误的直觉，但确实是一种直觉 —— 即模型在运行过程中正在“逐渐了解”代码库。而在每个请求的执行计划中，这种直觉无处依附。用 GitHub 的话来说，捕获您竞态条件的评审器是一个“来自不同模型家族的独立只读评审器”。它看到了草稿，做出了判断，而它的判断经过压缩后以修改后的结果呈现在您面前。下一次它不会在场，链条中的任何部分都不会保留它所注意到的内容。如果路由是按请求进行的，并且随着 GitHub “评估并纳入”新模型，模型池可能会发生变化，那么您希望可靠呈现的任何内容都必须声明在路由器无法绕过的某个地方。
这并不是某一家厂商的奇特做法。来自 Sourcegraph 的 Amp 从一个完全不同的起点出发，记录了几乎相同的架构。其 Modes and Models 页面指出，Amp “针对不同类型的工作使用不同的模型。主智能体处理您的任务，专业子智能体承担其中的重点部分，而较小的系统模型处理支持性工作，”并且“随着更好的选择出现，模型可能会发生变化，而每个模式和子智能体的角色保持稳定。”在隔离问题上，Amp 比 GitHub 更直接：其专业子智能体“在隔离状态下工作，因此它们无法相互通信，您无法在任务中途引导它们，并且它们从主智能体给它们的指令和上下文开始，而不是完整的对话。主智能体只接收它们的最终摘要，而不是监控它们的分步工作。”
两个独立的产品，两套独立的文档，得出了相同的结论：组合执行带来了质量和成本效益，而代价是中间理解被总结了，而不是被保留了。这是一个架构上的结果，而不是对任何一个团队的批评。这只是意味着持久层必须位于其他地方。
人们会从中得出什么误解，以及为什么不应该这样想
“它只是一个更便宜的模型选择器。” 价格定位主导了大多数报道，但它忽略了组合会随着每个请求而改变。选择器只选择一个东西。HydraFusion 构建了一个计划，GitHub 将这一举措描述为“从选择最佳模型转变为动态构建解决每个任务的最佳方式”。
“所以评审器的审查记录在我的历史记录中。” 并非如此，这是有意设计的。您收到的是“一个连贯的响应和一个权限感知的变更集”。每个分支的记录都是内部的。
“多轮对话即将推出，所以这个问题会迎刃而解。” GitHub 表示多轮表现是下一步，这是关于更长会话的质量。一个更好的会话仍然只是一个会话。帖子中没有任何内容表明一次运行所学到的东西可以跨任务持久化，将“多轮”视为“持久记忆”的代名词，正是导致团队在十月份不得不重新解释他们在九月份已经解释过的约束条件的原因。
“那么 Copilot 就没有记忆了。” 错误，这值得明确指出。Copilot 拥有有文档记录的记忆表面，而此预览版并不是其中之一。准确的说法更窄：HydraFusion 有文档记录的行为涵盖了执行计划 and 结果交付，其中并没有与跨任务累积项目事实的存储相对应的有文档记录的对应部分。这是关于该功能的范围声明，而不是关于该产品的断言。
解决方案：将持久层保持在执行计划之外
解决办法不是去对抗路由器。而是停止要求链条中的任何模型去充当记忆的角色，并放置一个微小、显式的层，让每个计划的每个分支都能读取它。
步骤 1：分离您当前混淆的两类上下文
将指令文件中的每一行拆分到两个存储桶之一。
第一个是 如何在这里工作：构建命令、评审步骤、样式约束、不要触碰的目录。这属于文件，每轮都会重新发送，就像今天一样。GitHub 和 Amp 都处理得很好，您不应该移动它。
第二个存储桶是 我们确立的事实：放弃流式解析器的决定及其原因、由于供应商沙箱导致支付服务使用不同测试命令的事实、在不稳定的集成测试中已经尝试过的两种方法。这个存储桶不断增长，是在工作过程中发现的，而不是提前写好的，这恰恰是每个请求计划无法容纳的 —— 因为发现它的分支是被隔离并被总结的。
如果您的指令文件目前包含第二个存储桶的内容，那么您一直将重新发送的提示词用作记忆存储。它在失效前一直有效，并且会默默地与第一个存储桶竞争相同的预算。
步骤 2：在纠正的瞬间进行捕获，而不是在会话结束时
宝贵的材料出现在您告诉智能体它错了的时候。那是约束条件变得明确的时刻，也是您最不可能写下任何东西的时刻，因为您想尽快完成任务。
让它成为一个动作，而不是一件繁琐的家务。当您纠正智能体时，将纠正声明为一个持久的事实 —— “支付服务测试通过 make test-payments 运行，而不是 npm test，因为供应商沙箱需要 fixture 服务器” —— 并将该句子发送到您的记忆层，而不仅仅是发送到聊天中。原因正是让它在未来决策中幸存下来的关键；一个没有合理解释的生硬规则在第一次遇到不便时就会被推翻。
步骤 3：为计划的每个分支提供相同的读取路径
将该层放在外面的意义在于，它不在乎哪个模型在执行。解决器分支、级联升级以及明天的新会话都以相同的方式访问相同的存储。在实践中，这意味着通过 MCP 暴露它，以便任何支持该协议的客户端都可以读取它，并通过 API 暴露给无法支持该协议的表面。
这也从另一个方向解决了隔离问题。GitHub 的评审器在设计上是“无工具”运行的，因此它不会在评审中途查询任何内容 —— 但确实使用共享工作区的起草模型可以在编写之前拉取已确立的事实。将约束条件融入草稿中，比在评审中捕获它要好得多。
在 MemoryLake 中设置
MemoryLake 是我们针对这种形式的问题构建的层：一个比任何特定模型、会话或执行计划寿命更长的存储。
步骤 1：创建 API 密钥
生成一个密钥，并在大约 30 秒内发出您的第一个请求。该密钥允许路由工作流、CLI 会话和团队成员的编辑器读取相同的事实，而无需其中任何一个拥有这些事实。
步骤 2：上传您的第一批记忆
放入已经承载您项目既定决策的文档、图像和文件 —— 架构说明、当前重试策略背后的事件记录、大家仍在争论的设计文档。从您厌倦了重复解释的内容开始，而不是试图面面俱到。
步骤 3：连接您的 AI 和智能体
允许 Claude、Codex、OpenClaw 和其他智能体通过 MCP 或 API 进行访问。对于 Copilot CLI 工作流，在任务开始时读取相关记忆，以便草稿中存在这些事实，并在任务期间写回您所做的纠正。
这在实践中改变了什么
您首先会注意到一种特定类型的重复对话消失了。不是“这个函数是做什么的” —— 智能体一直很擅长这个 —— 而是“我们在七月份尝试过那个，结果搞垮了暂存环境（staging）”。这句话不再需要人类来提供。
第二，模型更改不再让您付出代价。GitHub 表示“当 GitHub Copilot 中有新模型可用时，我们可以对其进行评估并将其纳入其模型池中”。如果您的持久知识存在于模型池之外，那么模型池的更改只是质量和成本的更改，而不是您的智能体所知道的内容的更改。这就是升级与迁移之间的区别。
第三，隔离的评审器不再那么令人感到遗憾。您看不到它的推理过程，而且可能也不应该想看 —— GitHub 关于显示废弃草稿“可能会让未完成的工作看起来像是最终结果”的论点是合理的。但是，当它的判断作为您接受的更改呈现出来时，您可以用一句话记录下结论。推理过程留在运行时中；结论则变成了您的。
第四点对团队来说最重要：任何客户端都可以读取的存储，也是新工程师的智能体在第一天就可以读取的存储，因此知识不再是拥有超长会话的那个人的专属财产。
每个请求路由下持久上下文的最佳实践
记录结论，而不是记录。 路由工作流会产生大量您永远看不到的中间材料。不要试图重建它。记录单行结果和原因。
指令文件仅保留不变的内容。 无论您在做什么，任何始终成立的内容都属于文件；任何发现的内容都属于存储。将它们混在一起会使发现的事实与构建命令竞争相同的提示词预算。
为每个事实附加原因。 “在这里使用 make test-payments”会被推翻。“在这里使用 make test-payments，因为供应商沙箱需要 fixture 服务器”则不会。
记录更替，而不是删除。 当决策逆转时，说明这一点并说明时间。保留每个版本的归档解决不了任何问题；而默默丢弃旧版本的存储则无法解释新版本。
结论
HydraFusion 是一个论证充分的赌注，即编码智能体的下一个收益来自于组合模型，而不是选择一个模型。它的五个运行原则 —— 隔离评审、有界执行、故障安全应用、经过验证的路由、完整的记账 —— 读起来就像是一个仔细思考过如何运行别人仓库的团队。
这个赌注还在悄无声息中淘汰了一个假设。您的会话背后不再有一个可以被合理地认为是负责记忆的单一模型。路由器为每个请求选择一个新的计划，评审器被刻意隔离，而到达您面前的是一个答案和一个变更集。Amp 从不同的方向记录了相同的形式，这表明这通常是组合智能体的发展方向。
实际的应对措施很小。确定您的哪些上下文是不变的，哪些是发现的。将不变的部分留在已经发挥作用的文件中。将发现的部分放在任何执行计划都无法绕过的地方，为每个条目附加原因，并让在下一次路由决策中胜出的任何模型读取它。这样，模型池可以根据 GitHub 的需要随时更改，而唯一改变的只是您编写代码的速度。