GitHub 于 2026 年 9 月 14 日更新 Copilot auto model selection，加入 efficiency、balance 和 intelligence 三个取向。三者使用同一组可用模型，但会用不同权重处理成本、质量和响应速度。这不是推出一个新模型，而是把「由系统替每个 prompt 选模型」变成用户可以调校的政策。
Efficiency 优先保持成本较低，适合简单、直接的工作；balance 同时衡量成本、质量和 latency，定位为日常工作；intelligence 则优先质量，面向较复杂的任务。GitHub 的例子是，简单的 docstring 可能使用较小和高效的模型，即使用户把 Auto 设为 intelligence。
Auto 仍然会逐个 prompt 评估，再选择它认为最合适的模型。这意味着取向不是一个永远固定的 model pin，而是给 router 一个优化目标。对 agent workflow 来说，这可以把短任务、日常 coding 和深度分析放进同一个入口，但也让每次调用实际使用哪个模型变得不那么直观。
这项功能目前在 Visual Studio Code、Copilot CLI 和 GitHub Copilot app rollout。用量按 Auto 实际选出的模型收费，不会因为使用某个取向而改变收费方式；付费订户继续享有通过 Auto 计算用量的 10% 折扣。企业如果要估算成本，应查看实际 model mix，而不是只看取向名称。
对开发团队而言，三层取向提供了一个比「永远用最强模型」更清晰的成本治理入口。效率取向可以用于格式化、简短说明和低风险修改；balance 可以覆盖一般 coding 和 review；intelligence 则留给需要更多推理的设计、调试和跨文件任务。这些只是工作流假设，实际仍要以团队的错误率和接受率验证。
Auto model selection 也带来可观察性要求。如果系统按 prompt 选择不同模型，团队需要知道哪些任务被路由到哪个模型、成本如何变化、延迟是否改善，以及是否出现质量回归。如果只有一个总用量数字，管理员很难分辨是取向设置有效，还是某一类任务不断重试。
在企业环境中，取向还要配合政策和权限。组织可以按 repository、team 或工作类型定义默认取向，再用 spend controls、model allowlist 和 audit log 限制可用范围。Auto 选择模型的能力，不应绕过数据分类、代码权限、秘密保护或需要人工批准的 agent action。
这次更新把模型选择由隐藏的基础设施行为，变成更容易讨论的产品设置。它不会自动证明成本下降或质量提升，但提供了一个可以做 A/B 比较的控制面。成熟采用方式，是为每类任务定义成功标准，再同时量度成本、延迟、结果质量和人工介入，而不是单纯选择 intelligence 便期待所有结果更好。
