Copilot Auto Model Selection：Efficiency、Balance和Intelligence怎么选

摘要： GitHub Copilot 的 Auto Model Selection 在 2026 年 9 月新增 Efficiency、Balance 和 Intelligence 三档。三档并不是三套固定模型，也不是“低配 / 中配 / 高配”的简单套餐，而是对同一 Auto 模型池采用不同的路由偏好：Efficiency 更看重成本，Balance 同时权衡成本、质量与延迟，Intelligence 更看重回答质量。本文结合 GitHub 官方 Changelog、Copilot 文档、计费文档和 VS Code 更新说明，解释三档的实际差异、适用任务、AI Credits 成本逻辑、VS Code 与 Copilot CLI 的使用方法，以及企业团队如何制定默认策略。对于大多数开发者，建议把 Balance 作为日常默认，把 Efficiency 用于批量、重复、低风险任务，把 Intelligence 留给复杂调试、跨文件重构、架构推理和高价值 Agent 任务。

核心结论

如果只想记住一句话：Efficiency、Balance 和 Intelligence 改变的是 Copilot Auto 的“路由目标”，不是可用模型集合。 GitHub 官方明确说明，三档使用相同的可用模型集合，Auto 仍会逐个判断提示词的任务复杂度，并结合实时模型健康状态、可用性以及所选档位的优化目标，决定实际调用哪个模型。

• Efficiency：优先控制成本，适合文档注释、简单解释、格式转换、重复性代码改动、基础测试补全等快速任务。
• Balance：同时考虑成本、质量和响应延迟，是绝大多数日常编码、PR 修改、一般调试和中等复杂度 Agent 任务的默认选择。
• Intelligence：优先回答质量，适合跨模块重构、疑难 Bug、复杂架构分析、长链路 Agent 任务和高风险代码变更。
• 三档并不会锁定某个模型：即使选择 Intelligence，简单任务仍可能被路由给较小、较便宜的模型；反过来，Efficiency 也不是“永远只用最小模型”，而是寻找满足任务能力要求的更经济模型。
• 计费仍按 Auto 最终选中的模型和实际 Token 消耗计算。GitHub 当前文档说明，付费方案在符合条件的 Auto 使用场景下继续享受 10% 的模型成本折扣。

对 AI Stack Nav 读者而言，最重要的不是纠结“哪一档最强”，而是把任务按风险和复杂度分层：低风险批量任务用 Efficiency，日常工作用 Balance，高复杂度和高价值任务再切 Intelligence。

背景：Copilot 为什么要把 Auto 再拆成三档

GitHub Copilot 过去的模型选择逻辑主要有两种：一种是用户手动选择某个具体模型，另一种是选择 Auto，让 Copilot 根据任务和模型可用性自动路由。2026 年 9 月 14 日，GitHub 在 Changelog 中正式宣布 Auto Model Selection 增加 Efficiency、Balance 和 Intelligence 三个优化档位。

这次变化的关键，不是“又新增了三个模型”，而是 Auto 从“由 GitHub 自动做决定”进一步变成“用户先指定优化目标，GitHub 再自动做模型路由”。

GitHub 当前对 Auto with task optimization 的描述包含两套核心判断机制：

1. 一套系统关注实时模型健康状态和可用性。
2. 另一套系统判断当前任务复杂度。
3. 两者结合后，再依据 Auto tier 的偏好，对候选模型进行路由。

因此，Auto 的价值不只是省去人工挑模型，还承担了三个实际职责：

• 避开当前拥塞、降级或高错误率的模型；
• 根据任务复杂度决定是否值得使用更昂贵的推理模型；
• 在自然缓存边界切换模型，避免频繁换模型破坏缓存经济性。

这也是为什么 GitHub 不建议把“最强模型”固定用于所有任务。简单任务如果长期固定使用高价模型，往往只会增加 AI Credits 消耗；而复杂任务如果一味追求最低成本，又可能导致来回追问、反复修正和更多 Agent 循环，最终总成本反而更高。

三档到底有什么区别

三档最容易被误解的地方，是很多人会把它理解成“Efficiency = 小模型、Balance = 中模型、Intelligence = 大模型”。官方文档明确否定了这种理解：三档使用同一个可用模型集合，只是改变优先路由规则。

档位	官方优先目标	更适合的任务	典型风险	AI Stack Nav 建议
Efficiency	成本	简单解释、注释、格式化、批量小改、模板代码、基础测试	复杂任务可能需要更多轮修正	低风险、高频、可验证任务优先
Balance	成本 + 质量 + 延迟	日常开发、一般调试、PR 修改、中等复杂度 Agent	对极难问题可能不如 Intelligence 激进	作为个人与团队默认档
Intelligence	质量	架构设计、疑难调试、跨文件重构、复杂 Agent、多约束任务	单次调用成本可能更高	高价值、高复杂度任务按需启用

Efficiency：重点不是“最便宜”，而是“满足任务能力前提下更经济”

Efficiency 的官方定位是优先考虑成本。实际理解时需要加一句限定：它不是无条件挑最便宜模型，而是在 Copilot 判断足以完成当前任务的候选中，更偏向成本效率。

适合 Efficiency 的任务通常具有几个共同点：

• 输入目标明确；
• 输出格式容易验证；
• 任务范围小；
• 出错后回滚成本低；
• 不需要复杂跨文件推理；
• 可以依靠测试、Lint、类型检查或人工快速验收。

例如：

为这个 TypeScript 函数补充 JSDoc，不修改函数逻辑。

把这 8 个 Python dataclass 的字段说明统一成同一风格。

根据现有测试风格，为这个纯函数补 5 个边界测试。

这些任务不需要为了“质量上限”持续调用高成本推理模型。对每天大量使用 Copilot 的团队，Efficiency 特别适合批量整理、文档生成、机械性重构和低风险维护。

Balance：最适合做默认档

Balance 同时考虑成本、质量和延迟。对多数开发者来说，它最接近“什么都不想手动管，但希望结果比较稳”的模式。

典型场景包括：

• 根据 Issue 修改 2～5 个文件；
• 修复一个已有明确报错堆栈的 Bug；
• 给现有 API 增加参数校验；
• 调整 React 组件状态逻辑；
• 修改数据库查询并同步单元测试；
• 在 Agent 模式中完成一组中等复杂度开发任务。

Balance 的优势是不用为了每个 Prompt 手动判断是否值得升级模型。对于长期使用 Copilot 的个人开发者和中小团队，把 Balance 作为默认，然后在个别任务上手动切 Intelligence，通常比长期固定 Intelligence 更容易控制 AI Credits。

Intelligence：优先质量，但不代表每次都调用最贵模型

Intelligence 的目标是优先高质量结果。它更适合那些“答错一次就可能造成大量返工”的任务。

例如：

• 跨十几个文件重构核心模块；
• 分析并发、竞态、锁、缓存一致性问题；
• 迁移大型框架版本；
• 根据复杂业务约束设计数据模型；
• 排查偶发 CI 失败；
• Agent 需要先阅读大量代码，再规划、修改、运行测试并根据结果继续迭代；
• 对生产配置、安全策略、权限边界进行高质量分析。

但要注意，GitHub 明确说明：即使选择 Intelligence，简单 Prompt 仍可能被路由到较小模型。 这说明 Intelligence 不是“强制最大模型”，而是“当高质量模型确实更有价值时，更愿意为质量付出成本”。

这也是 Auto tier 比固定模型更灵活的地方。

Auto 的模型池到底有哪些模型

这里不建议写死一份“永远有效”的模型清单，因为 GitHub 明确说明 Auto 可用模型会随时间变化，而且最终候选集还受以下条件约束：

• 你的 Copilot 套餐；
• 组织或企业管理员的模型策略；
• 数据驻留政策；
• FedRAMP 等合规限制；
• Evaluation models 是否允许；
• 模型当时的可用性和健康状态。

因此，“选择 Intelligence 后一定会用 GPT-6 Astra”或者“Efficiency 一定只会用某个 Flash / mini 模型”都不是可靠说法。

更准确的理解是：

用户选择 Auto tier
        ↓
读取当前账号 / 企业允许使用的模型
        ↓
排除策略禁止、套餐不可用、合规不允许的模型
        ↓
评估任务复杂度
        ↓
检查实时模型健康与可用性
        ↓
根据 Efficiency / Balance / Intelligence 的偏好排序
        ↓
选择实际模型

对企业用户尤其要注意：Auto 不会绕过管理员策略。 如果管理员禁用了某个模型，或者企业要求只使用特定合规模型，Auto tier 仍必须在允许的集合中路由。

成本怎么计算：三档不是固定价格

很多开发者最关心的问题是：Efficiency 会不会有一套固定低价？Intelligence 会不会每次固定多扣 Credits？

答案都是否定的。

GitHub 当前的 AI Credits 计费逻辑本质上取决于：

1. 实际使用的模型；
2. 输入 Token；
3. 输出 Token；
4. 缓存相关 Token；
5. 某些模型的扩展上下文或推理设置。

GitHub 文档当前规定 1 AI Credit = 0.01 美元。不同模型每百万 Token 的价格不同，因此同样一个 Prompt，如果 Auto 最终选中的模型不同，消耗也会不同。

Auto tier 本身没有“每次固定扣 X Credits”的价格表。正确公式应该理解为：

实际成本
≈ Auto 选中模型的 Token 成本
× 实际 Token 用量
× 适用的计费调整

对于付费 Copilot 用户，GitHub 当前还提供 Auto model selection 的 10% 模型成本折扣。这意味着你不应该把 Intelligence 理解成“固定贵 30%”或 Efficiency 理解成“固定省 50%”，官方并没有给出这样的比例。

为什么最便宜的档不一定总成本最低

如果一个复杂任务用 Efficiency 后出现以下情况：

• 第一次理解错需求；
• 第二次修复遗漏；
• 第三次又因为上下文不足重复读取；
• Agent 多跑几轮测试；
• 最后还需要人工再切模型重做；

那么总 Token 和总 Agent 调用次数可能明显增加。

因此成本优化要看 完成一个任务的总成本，而不是只看“单次调用用了哪个档”。

这也是推荐策略：

• 简单任务：Efficiency；
• 中等任务：Balance；
• 难任务：Intelligence；
• 如果某任务在 Efficiency 连续两轮没有收敛，直接升级档位，不要机械重试。

VS Code 中怎么使用 Efficiency、Balance 和 Intelligence

GitHub 文档目前确认 Auto tiers 可用于 VS Code、Copilot CLI 和 GitHub Copilot app。VS Code Insiders 1.139 的更新说明还明确出现了 Auto 的 “Optimize for” 控件，可在 Efficiency、Balance 和 Intelligence 之间切换。

实际使用时可以按下面流程操作：

1. 更新 VS Code 与 GitHub Copilot 扩展。 新功能存在逐步推出过程，如果你的界面没有出现三档，先确认客户端版本。
2. 打开 Copilot Chat。
3. 在 Chat 底部打开模型选择器。
4. 选择 Auto。
5. 在支持 Auto tiers 的版本中找到 Optimize for / Auto tier 选项。
6. 日常先选择 Balance。
7. 处理批量简单任务时切换 Efficiency。
8. 处理疑难调试、复杂重构或高价值 Agent 任务时切换 Intelligence。
9. 提交 Prompt 后查看实际使用模型。 GitHub 文档说明 Copilot Chat 可以通过响应信息查看本次 Auto 最终选中的模型。
10. 结合 AI Credits 使用记录复盘。 不要只比较一次响应速度，而要比较“任务是否一次完成”和“总消耗”。

如果你看不到 Optimize for，优先考虑三个原因：客户端尚未更新、功能仍在逐步 rollout、当前使用的 Copilot surface 还不提供 tiers。

Copilot CLI 怎么用 Auto

Copilot CLI 官方文档支持通过 /model 或 --model 选择模型，--model=auto 可以让 Copilot 自动选择。

基础方式：

copilot --model=auto

交互式会话中也可以使用：

/model

然后选择 Auto。

需要强调的是，GitHub 的公开 CLI 参考文档已经确认 Auto 可以通过 --model=auto 启用，但三档 UI / 配置细节可能随着 CLI 版本继续调整。不要在自动化脚本里猜测一个官方未固定的 --tier=efficiency 参数。 如果当前版本通过交互式模型选择器暴露 Auto tier，应以 CLI 实际显示的选项为准。

对自动化场景，可以先把“是否使用 Auto”固定下来，再通过任务队列进行复杂度分层。例如：

copilot -p "为 src/utils/*.ts 中的导出函数补充简短 JSDoc，不修改逻辑" \
  --model=auto

如果你的 CLI 版本支持三档持久化设置，可以在交互模式中配置后，再通过团队文档记录默认策略；如果没有出现三档，则说明当前客户端或 rollout 状态尚未提供这一配置。

三类真实开发任务应该怎么选

场景一：文档、注释、格式调整、批量机械修改

优先：Efficiency

例如：

把以下 12 个 API handler 的错误响应统一成现有项目格式。
不要修改业务逻辑。
修改后运行 lint。

这类任务的正确性容易通过静态检查、测试或 Diff 验证，没必要一开始就使用质量优先档。

场景二：日常 Bug 修复和功能开发

优先：Balance

例如：

Issue #321：用户修改邮箱后，资料页仍显示旧缓存。
先定位缓存写入和失效逻辑，再给出修改计划。
实现后运行相关单测，不要改无关文件。

这类任务需要一定推理，但通常没有必要为了每一步都追求最高模型质量。Balance 可以更好地控制交付质量与成本。

场景三：跨模块重构、复杂 Agent、生产高风险任务

优先：Intelligence

例如：

分析订单服务中偶发重复扣库存的问题。
重点检查事务边界、消息重试、幂等键和并发更新。
先只做根因分析和修改计划，不直接改生产配置。
列出证据后再进入实现阶段。

如果任务涉及支付、权限、安全、数据库迁移、生产部署等高风险操作，即使选择 Intelligence，也不应该把“模型更强”当成自动放权的理由。模型选择解决的是质量 / 成本路由问题，不解决权限治理问题。

一套适合个人开发者的默认策略

个人开发者可以直接采用下面这套简单规则：

1. 把 Balance 设为默认。
2. 一眼能看懂、输出可快速验证的任务切 Efficiency。
3. 需要阅读多个模块、排查复杂根因、做设计权衡时切 Intelligence。
4. Efficiency 连续两轮没有收敛，就升级到 Balance 或 Intelligence。
5. Intelligence 任务结束后，下一项普通任务及时切回 Balance。
6. 不要把“响应更长”误认为“质量更高”，最终以测试、Diff 和任务完成度判断。
7. 每周查看一次 Copilot 使用量，把最消耗 Credits 的任务类型单独归类。

这个策略的好处是简单，不需要你记住每个具体模型的价格变化，也不用追逐每周新增或退役的模型。

如果你正在搭建更完整的 AI 编程工作流，也可以参考 AI Stack Nav 的站内内容搜索：
GitHub Copilot 相关教程 和 AI Coding Agent 工作流。

企业团队应该怎么定默认档

企业团队和个人最大的区别，是企业需要同时管理预算、权限、数据合规和开发效率。

推荐建立三层策略：

第一层：默认档

将 Balance 作为大多数研发人员的默认策略。

原因不是 Balance “最好”，而是它对成本、质量和响应速度的权衡更适合作为组织级基线。

第二层：任务类型建议

团队内部可以建立一张简单矩阵：

任务类型	默认建议	是否需要独立验收
文档、注释、格式化	Efficiency	通常不需要
单文件小修	Efficiency / Balance	建议跑测试
普通功能开发	Balance	需要
多文件重构	Balance / Intelligence	需要
并发、性能、复杂 Bug	Intelligence	强烈建议
权限、安全、生产配置	Intelligence	必须
自动发布、部署、数据库变更	Intelligence	必须 + 人工审批

第三层：组织模型政策

企业管理员应继续使用 Copilot 模型策略限制不适合组织的数据处理模型。Auto 会尊重组织和企业政策，因此先确定“哪些模型允许使用”，再谈 Efficiency / Balance / Intelligence 的自动路由。

如果企业有数据驻留、FedRAMP 或特定供应商限制，还要先验证 Auto 的候选模型是否符合要求。

对于 Agent 权限治理，可以继续参考 AI Stack Nav 的 Copilot 权限治理相关文章。

Auto 和手动固定模型怎么选

Auto tier 并不会让手动模型选择失去价值。

更适合 Auto 的情况

• 日常任务类型变化很大；
• 不想长期追踪模型上新和退役；
• 希望减少模型拥塞和限流影响；
• 希望让系统根据复杂度选择模型；
• 团队希望降低“所有人一律选最贵模型”的浪费。

更适合固定模型的情况

• 正在做严格 A/B 测试；
• 需要可重复的模型行为；
• 特定代码库已经验证某个模型效果显著更好；
• 合规或供应商要求必须固定模型；
• 某个工具链依赖具体模型能力；
• 需要精确估算单一模型 Token 成本。

因此最实用的做法不是二选一，而是：

日常默认 Auto，关键基准测试和特殊任务固定模型。

为什么 Auto 对未来模型更有价值

2026 年 GitHub Copilot 的模型更新频率已经很高。模型会增加、升级、退役，团队如果把大量脚本、培训文档和使用习惯都绑定在某个具体模型名称上，维护成本会越来越高。

Auto tier 相当于多了一层稳定抽象：

开发者表达目标：
“这次我要低成本”
“这次我要均衡”
“这次我要高质量”
        ↓
Auto Router
        ↓
GitHub 根据当前可用模型池进行实际选择

这样一来，模型供应商和具体型号变化时，开发者不一定需要立即修改所有使用习惯。

但这层抽象也有代价：可重复性下降。 同样的 Prompt 在不同日期、不同账号策略、不同模型健康状态下，可能由不同模型处理。因此对关键评测、回归测试和生产级基准，仍建议记录实际模型信息。

风险、限制与注意事项

1. 三档功能不是所有 Copilot surface 都一样

GitHub 当前文档明确说明：Auto task optimization 的覆盖范围比 Auto tiers 更广，而 Efficiency / Balance / Intelligence 三档当前只在 VS Code、Copilot CLI 和 GitHub Copilot app 提供。不要看到 GitHub.com 有 Auto，就默认一定有三档。

2. rollout 可能导致不同账号界面不同

GitHub 9 月 14 日公告使用了“rolling out”表述。即使同一个组织，不同客户端版本或账号看到功能的时间也可能不同。

3. 模型池会变

GitHub 会持续增加或退役模型。文章中不应把某一时刻的模型池当作永久承诺。

4. 企业策略会影响 Auto

管理员禁用的模型、套餐不包含的模型、数据驻留或 FedRAMP 限制不允许的模型，都不会被 Auto 绕过。

5. Intelligence 不等于安全

更强的模型仍可能误改代码、误判业务逻辑或执行危险命令。对于删除数据、生产部署、修改权限、支付流程和数据库迁移，仍应使用最小权限、人工审批、审计日志和独立测试。

6. 不要只看单次 Credits

真正需要优化的是“每个任务从开始到验收的总成本”。低价模型多次失败，可能比一次高质量执行更贵。

7. Agent 任务要单独限制预算

Copilot CLI 等 Agent 场景可能包含多轮模型调用、工具调用和测试循环。复杂任务建议设置 AI Credits 限额或其他会话预算控制，并限制 Shell、文件写入和网络权限。

事实依据与来源

本文以下内容属于 GitHub 官方已确认事实：

• 2026 年 9 月 14 日，GitHub 发布 Efficiency、Balance、Intelligence 三个 Auto tier。
• 三档使用相同的可用模型集合，区别是模型路由偏好不同。
• Efficiency 优先成本，Balance 同时考虑成本、质量和延迟，Intelligence 优先质量。
• Auto 仍会逐个评估任务复杂度，并考虑实时模型健康和可用性。
• 付费方案使用符合条件的 Auto model selection 时，当前享受 10% 模型成本折扣。
• Auto tiers 当前可用于 VS Code、Copilot CLI 和 GitHub Copilot app。
• Auto 会遵守套餐、管理员模型策略、数据驻留和合规限制。
• Copilot CLI 官方支持 --model=auto 和 /model 进入 Auto 模式。

本文关于“Balance 作为日常默认”“复杂任务连续失败后升级档位”“企业按任务风险建立 tier 矩阵”等内容属于 编辑判断与实施建议，不是 GitHub 官方强制规则。

本文没有引用第三方 Benchmark，也没有编造 Efficiency 相对 Intelligence 的固定节省比例，因为 GitHub 当前并未公布三档统一的百分比成本差异。

实际 AI Credits 消耗仍应以你的 GitHub 使用记录、实际选中模型、Token 用量和当时的模型价格为准。

FAQ

Copilot Efficiency、Balance 和 Intelligence 是三个不同模型吗？

不是。GitHub 官方明确说明三档使用同一组可用模型。区别在于路由目标：Efficiency 更偏成本，Balance 同时考虑成本、质量和延迟，Intelligence 更偏质量。最终实际使用哪个模型仍由 Auto 根据当前 Prompt、模型可用性和账号策略决定。

选择 Intelligence 后，会不会每次都使用最强、最贵模型？

不会。官方特别举例说明，即使使用 Intelligence，一个很简单的任务仍可能被路由到较小、更高效的模型。Intelligence 的含义是质量权重更高，而不是强制固定到某个旗舰模型。

Efficiency 一定最省 AI Credits 吗？

单次调用通常更偏向成本效率，但完整任务不一定。复杂问题如果因为模型能力不足而反复失败、重试或重新读取上下文，总消耗可能更高。对复杂调试和跨模块重构，更合理的做法是直接用 Balance 或 Intelligence。

Balance 适合长期设为默认吗？

对多数个人开发者和团队，适合。Balance 同时考虑成本、质量和延迟，覆盖日常开发、一般调试和普通 Agent 任务的范围最广。本文建议将 Balance 作为默认属于实施建议，不是 GitHub 的强制要求。

三档现在在哪些地方能用？

根据 GitHub 当前文档，Auto tiers 可用于 VS Code、Copilot CLI 和 GitHub Copilot app。其他 Copilot surface 可能支持 Auto model selection，但不一定提供 Efficiency、Balance 和 Intelligence 三档。

Copilot Auto 如何收费？

Auto 没有独立固定单价。实际费用仍由最终选中的模型和 Token 用量决定，并换算成 GitHub AI Credits。GitHub 当前规定 1 AI Credit 等于 0.01 美元。付费方案在符合条件的 Auto 使用场景下享受 10% 模型成本折扣。

企业管理员禁用的模型，Auto 会偷偷使用吗？

不会。GitHub 文档说明 Auto model selection 受套餐和管理员策略约束。被组织或企业策略禁用、因数据驻留或 FedRAMP 等政策排除的模型，不会进入 Auto 可选集合。

Copilot CLI 可以直接使用 Auto 吗？

可以。官方 CLI 文档支持 --model=auto，交互模式也可以使用 /model 选择 Auto。至于 Efficiency、Balance 和 Intelligence 的具体交互入口，应以当前安装的 CLI 版本实际显示为准，不建议在脚本中使用未经官方文档确认的 tier 参数。

Auto 会不会在同一个 Agent 任务中频繁换模型？

GitHub 文档说明 Auto 会考虑缓存边界，避免为了少量质量收益而频繁在会话中切换模型，因为这样可能增加缓存相关成本。具体路由由系统控制，开发者不应假设每条消息都一定切换模型。

参考来源

1. GitHub Changelog：Configure cost and quality in Copilot auto model selection
2. GitHub Docs：About Copilot auto model selection
3. GitHub Docs：Usage-based billing for individuals
4. GitHub Docs：Models and pricing for GitHub Copilot
5. GitHub Docs：GitHub Copilot CLI command reference
6. Visual Studio Code 1.139：Auto Model Selection Optimize for 控件更新

安装部署教程

环境配置与 Docker 工作流

适合阅读安装部署、本地配置、服务器搭建和自动化流程类文章后继续转化。

环境配置资料包 包含 Windows / Mac / Linux 常见环境配置、依赖安装和报错排查清单。 查看资料包 Docker 工作流包 整理 Docker 部署模板、compose 示例和常用服务编排流程。 查看资料包