从每个token获取更多：Copilot如何改进上下文处理与模型路由

随着 Copilot 承担更多代理性工作——从规划、编辑到调试、审查以及在更长的会话中调用工具——效率的意义已超越单纯减少 token 使用量。它意味着更聪明地使用 token。提升效率始于减少 Copilot 在每次交互中需要重复的内容，包括上下文、工具定义和缓存状态。接着是为任务选择合适的模型。快速解释、针对性编辑和复杂的多文件变更不应被同等对待。我们正在两方面努力：改进 Copilot 的框架，使更多会话资源用于任务本身；以及扩展 Auto 功能，让 Copilot 能自动选择适合工作的模型，无需开发者每次都手动选择。本文重点介绍 VS Code 中 GitHub Copilot 的框架改进，以及将 Auto 扩展到更多 Copilot 界面的持续工作。

增强的 prompt 缓存与延迟工具

在 VS Code 中较长的 GitHub Copilot 会话里，框架会为模型准备大量重复信息：指令、仓库上下文、对话历史、可用工具以及任务的当前状态。其中部分上下文是必需的，部分则可以缓存、延迟加载或仅在相关时才加载。VS Code 中 GitHub Copilot 的两项改进在此发挥了主要作用。Prompt 缓存帮助 Copilot 复用模型状态来处理重复的 prompt 前缀，而无需在每次请求时重新计算相同的前缀。工具搜索则允许模型按需加载工具定义，而不是在每次交互时将所有完整工具 schema 都送入上下文。

随着代理使用更多工具，这一点变得更为重要。一个会话可能需要访问 MCP 工具、终端命令、文件操作、工作区搜索以及特定于产品的操作。预先加载所有完整工具定义为每次交互增加了固定成本，即使只有少量工具与任务相关。借助工具搜索，Copilot 可以保持广泛的可用工具集，同时向模型发送更少不必要的工具 schema。关于实现细节的深入技术探讨，包括 prompt 缓存、缓存控制断点、特定于提供商的工具搜索以及这些更改如何在长时间运行的代理会话中工作，请阅读 VS Code 技术深度解析。

GitHub Copilot 自动模型选择的作用

Auto 回答了一个实际问题：当前哪个模型最适合这个任务？在您发出第一个 prompt 后，Copilot 会根据任务意图和当前模型健康状态选择最适合该任务的模型。不同类型的工作——如快速解释、针对性编辑或多文件变更——并非都能从相同程度的推理中受益，因此 Auto 会做出这一选择，无需您调整模型设置。在我们的评估中，没有单一模型能在所有任务上持续表现最佳。在许多情况下，更高效的模型能达到相同结果，而更强的模型在任务需要更深层推理时才最为关键。Auto 会学习何时更强的推理能改善结果。当任务需要时，它会升级到更强模型；当不需要时，则保持更高效。目标不是用质量换取成本，而是使用最适合工作的模型。

Auto 如何选择合适的模型

Auto 结合两种信号：当前哪些模型健康且可用，以及 Copilot 被要求执行何种工作。

• 实时模型健康状态：一个动态引擎跟踪模型的可用性、利用率、速度、错误率和成本。一个模型可能能够处理某项任务，但这并不意味着它在当时是最佳选择。Auto 会考虑当前系统状况，以便 Copilot 能路由到既具备能力又能及时响应的模型。
• 基于任务感知的路由（HyDRA）：一个考虑推理深度、代码复杂度、调试难度和工具编排需求等因素的路由模型。HyDRA 会识别出能够满足任务质量标准的模型，然后从中选择最合适的。

图 1：三个 HyDRA 运行点展示了可调性：(Peak) 在节省 12.9% 成本的情况下超越 Sonnet；(Agg.) 在节省 72.5% 成本的情况下平衡质量。 图 2：HyDRA (Cons.) 在节省 3.3 倍成本的情况下，在解决率 (70.8%) 上与 OpenRouter Auto 持平。HyDRA (Agg.) 优于 Azure Foundry 的两种运行模式。

综合来看，这些信号让 Auto 避免了“一刀切”的方法。关键不是将每个任务都发送给最大的模型，也不是都发送给最便宜的模型，而是选择适合工作的模型。

让 Auto 在实践中发挥作用

在评估中正确路由只是问题的一部分。为了让 Auto 在实际工作流中有用，我们还必须考虑开发者实际使用 Copilot 的方式：会话变长、上下文累积、任务切换，以及开发者使用多种语言。

• 缓存感知路由。每次交互都切换模型听起来很灵活，但可能损害效率。当对话停留在同一模型上时，prompt 前缀可以被缓存并在多次交互中复用。在对话中途切换模型会破坏该缓存，其成本可能超过路由变更节省的成本。Auto 通过在自然缓存边界处路由来避免这种情况：在首次交互时（此时没有缓存可丢失），以及在压缩之后（此时 Copilot 总结较旧的交互轮次并重置 prompt 前缀）。在这两个点之间，所选模型保持不变，以便缓存可以持续构建。
• 跨语言路由。Copilot 服务于全球开发者，因此路由必须适用于英语以外的语言。我们使用涵盖 16 个语系（包括中日韩、欧洲及其他语系）的对话训练了路由模型。在评估中，跨语言组的路由准确率与英语基线相差在 4 个百分点以内，且无统计上显著的质量差距。 图 3：智能路由与英语基线相差在 4 个百分点以内。基于从 19 种语言的 VS Code 聊天遥测数据中采样的保留评估集，对英语、欧洲、中日韩及其他文字家族的模型进行评估。
• 学习何时升级重要。我们没有简单地将任务标记为“简单”或“困难”，而是训练路由器学习模型实际产生差异的地方。对于每个训练查询，来自能力较弱模型和能力较强模型的响应会在多个质量维度上进行评分。路由器会学习何时更强的模型能增加价值，以及何时更高效的模型能产生同样好的结果。对于较长代理会话中依赖上下文的消息，路由器是在完整的多轮对话（包括原始用户意图、最近的助手响应和对话元数据）上进行训练的。

Auto with task intent 正在扩展

Auto with task intent 已在 Visual Studio Code、github.com 和移动端上线。它为 Copilot 提供了更多关于您正在执行的工作类型（无论是编码、调试、规划还是使用工具）的信号，以便为任务做出更好的模型选择。我们正在继续将该体验扩展到更多 Copilot 界面。接下来，我们将把 Auto with task intent 带到更多平台，并增加更多方式让团队将 Auto 设为默认选项。Auto with task intent 即将登陆 Copilot CLI、GitHub App 以及其他 IDE。Copilot Free 和 Student 计划将简化，以利用 Auto 作为唯一的模型选择选项。管理员控制将允许组织将 Auto 设为默认值，或强制 Auto 作为唯一选项。

从您的 AI 积分中获得更多价值

Copilot 默认变得更高效，但一些习惯可以帮助您的积分用得更多。

• 从 Auto 开始。Auto 是许多任务的强力默认选项，因为它会根据您尝试做的事情选择模型，而无需您每次都手动挑选。
• 保持上下文聚焦。当您切换任务时开始新会话，在需要时压缩长时间运行的会话，并在您已经知道相关代码位置时提及您希望 Copilot 使用的文件。更少的不必要上下文意味着更多会话资源用于实际工作。
• 避免在会话中途更改模型或设置。切换模型、推理级别、上下文大小或工具配置可能会破坏缓存复用，并迫使 Copilot 重建上下文。按您希望的方式设置会话，然后将相关工作保持在一起。
• 在并行化之前先规划。对于较大的任务，先让 Copilot 制定计划。当工作确实可以拆分时，并行代理可能有用，但它们也会并行消耗积分，因此请有意识地使用它们。
• 仅使用您需要的工具。工具和 MCP 服务器功能强大，但广泛的工具集可能会增加额外上下文。启用与任务相关的工具，关闭不需要的工具。查看 GitHub Copilot 中的 agent finder 以帮助简化您的工具使用。
• 检查您的使用情况。您的 AI 使用情况页面显示了积分在功能和模型之间的去向。在 Copilot CLI 中，会话级别的使用情况也可以帮助您在工作时发现昂贵的模式。

完整指南请参阅《如何从您的 AI 积分中获得更多价值》。

开始使用

Auto 模型选择现已可用于受支持的 Copilot 体验。要了解更多信息，请参阅 Auto 模型选择文档。您也可以在 Copilot 讨论中分享反馈。我们正在持续让 Copilot 在整个系统中更高效，以便更多积分用于有用工作，而无需您自己调整每个模型选择。

本文《从每个 token 中获取更多价值：Copilot 如何改进上下文处理和模型路由》最初发表于 GitHub 博客。