Copilot周报：模型分档与Sentry集成

GitHub 在 2026 年 9 月 18 日发布了 Copilot 周报，对应 September 14 当周。这次 changelog 的信息量比标题看起来大：模型选择、代码审查、Sentry 集成、管理员用量与预算、VS Code 1.138 的 Agent 更新都有具体描述。下面按官方原文逐项拆解，并区分哪些是已确认事实、哪些仍需团队自行验证。

自动模型选择新增三档

官方原文写明：auto model selection 新增 efficiency、balance、intelligence 三档，用来决定 Copilot 如何在成本、质量和响应时间之间权衡。三档都从同一批可用模型中选取，更新正在 VS Code、Copilot CLI 和 Copilot app 中逐步推出。

这里有几个边界需要说清楚。官方没有列出具体模型名称，也没有说明每档的默认值、切换入口、组织策略是否覆盖，以及不同档位是否影响数据保留条款。从工程角度看，这三档更像是把“选模型”从手动列表变成策略化偏好：团队可以先确认默认档位，再决定是否允许成员自行切换。

代码审查的四项变化

代码审查更新在原文中有四条明确行为：

  • 后续审查会解决已被处理的评论，未解决的反馈保持打开；
  • 应用代码建议时，Copilot 会建议提交信息；
  • 审查可以使用 shell 工具验证变更；
  • Lite 审查会汇总多个 agent 的发现。

这四条对 PR 流程的影响不同。“解决已处理评论”意味着审查状态会随代码变化收敛，而不是每次重新堆叠评论；“建议提交信息”把审查动作和提交动作连在一起；“shell 工具验证”说明审查过程可能执行命令来验证变更，这一点需要团队确认执行环境和权限边界；“Lite 审查汇总多 agent 发现”则说明轻量审查不是单一 agent 输出。

官方没有说明这些行为的触发规则、适用仓库范围、是否进入审计记录，以及 shell 工具在什么沙箱中运行。这些是落地前必须验证的项。

Sentry canvas：从崩溃报告到 PR

Copilot app 新增 Sentry canvas，官方描述是：查看错误、堆栈和相关上下文，然后与 Copilot 一起调查原因、验证修复并准备 pull request。也就是说，它不只是把 Sentry 链接放进对话，而是覆盖了从错误信息到修复准备的一段流程。

原文没有说明的是：是否支持自托管 Sentry、需要哪些权限、读取哪些项目、是否会传输源码或生产数据、以及是否对所有计划开放。安全与合规团队不能仅凭这段描述批准生产使用。一个稳妥的做法是先在非核心项目验证数据读取范围，记录授权页面、权限范围和实际传输内容，再决定是否扩大范围。

管理员侧：用量指标与预算申请

面向 Business 和 Enterprise 用户，官方给出三项更新：

  • VS Code Agents 窗口的用量指标正式可用，企业级和组织级报告包含日活用户、会话数、用户消息总量，以及用户级活动数据，这些指标与编辑器窗口指标分开；
  • 仓库自定义属性值建议进入公开预览，例如创建 internet-facing 属性时，Copilot 可以建议 yes 和 no 作为允许值，组织和企业所有者可通过 Copilot 策略开关；
  • 达到 AI credit 上限后，可以向组织或企业申请更高预算，所有者和账单管理员可以在设置中批准、调整或拒绝，批准后恢复 AI credits 访问。该功能对使用按量计费的 Copilot Business 和 Copilot Enterprise 计划正式可用，但不适用于使用 managed users 的企业。

这三项里，用量指标和预算申请都直接影响管理动作。用量指标分窗口统计，意味着团队不能把 Agents 窗口的数据和编辑器窗口的数据混在一起看；预算申请则把额度管理变成了一个可审批流程，但官方没有说明审批时限、额度调整粒度或是否影响账单周期。

VS Code 1.138 的 Agent 更新

VS Code 1.138 带来三项与 Agent 相关的更新：

  • 在 Agents 窗口中使用本地 Dev Containers 运行 agent，要求 Docker 和受支持的 Dev Container 配置，支持正在逐步推出；
  • 当所有 pull request 合并后，自动将不活跃会话标记为 Done，并可在单独的宽限期后可选删除，自动清理为 opt-in 且处于预览阶段；
  • 在 Agents 窗口中从 Agent Host 会话创建 pull request，可以查看生成的标题和描述、选择草稿状态，直接创建或让 agent 创建。

Dev Containers 这一项把 agent 运行环境拉回项目自身的工具和依赖，对需要复现构建环境的团队有实际意义。Agent Host 创建 PR 则减少了窗口切换，但官方没有说明 PR 创建是否受分支保护规则限制、是否需要额外权限，以及自动清理的宽限期具体多长。

团队可以立即执行的检查清单

在把这些更新放进工作流之前，建议按以下清单逐项验证：

  • 模型分档：默认档位是什么，成员能否自行切换，组织策略是否覆盖，不同档位是否影响数据保留条款；
  • 代码审查：哪些仓库和分支会触发，shell 工具在什么环境执行，评论是否可审计，误报如何反馈；
  • Sentry canvas：集成入口在哪里，需要哪些权限，读取哪些项目，是否支持自托管 Sentry，是否传输源码或生产数据；
  • 管理员更新：用量指标如何与现有报表对齐，预算申请由谁审批，是否影响账单周期；
  • Agent 功能：Dev Containers 配置是否满足要求，自动清理是否开启，Agent Host 创建 PR 是否受分支保护限制。

这些是验证项，不是官方承诺。把它们写成清单，可以避免团队把 changelog 里的方向误当成已落地能力。

不能从当前资料推出的结论

  • 不能因为提到三档模型选择就认为支持某个具体模型或版本；
  • 不能因为提到 shell 工具就认为审查可以任意执行命令；
  • 不能因为提到 Sentry canvas 就认为支持所有可观测性平台或自托管 Sentry；
  • 不能因为提到预算申请就认为所有计划都能使用；
  • 不能把 September 14 周报等同于这些功能已经全量可用。

这次 changelog 给出的信息足够具体，足以让团队开始验证，但还不足以直接改工作流。比较务实的做法是：先确认模型分档和用量指标，再在非核心项目试点代码审查和 Sentry canvas，最后根据权限边界决定 Agent 功能是否进入日常流程。