Copilot 代码审查开始可编程治理：企业到仓库三层设置走 API
GitHub 2026-11-06 让 Copilot 代码审查的设置可从企业策略到单个仓库全程走 REST / GraphQL API，并新增归因字段；同时把 Balanced 档改成三个审查模型加权汇总。
2026-11-08 · GitHub Changelog（官方原文，2026-11-06，一手）
发布 2026-11-08核实 2026-11-08要点
- GitHub 于 2026-11-06 开放 Copilot 代码审查设置的 API 管理：企业策略 → 组织 → 单个仓库三层，REST 与 GraphQL 都能读写。
- 🆕 新增归因能力：可识别哪些审查与评论出自 Copilot（显式归因字段）、本次审查用了哪档 effort（元数据可用时）、以及某条评论引用了哪些 skills / MCP server / 自定义指令。
- 企业级与组织级端点（含新增的组织 Runner 端点）不支持 GitHub Apps 与细粒度 PAT；仓库级端点两者都支持，权限为
Administration: read/Administration: write。 - Balanced 审查档改为「三个审查模型 + 一个汇总模型」——审查质量官方未给数据，但模型调用次数翻了几倍，这是成本与延迟的口径变化。
- 失败或超时的审查自动重试一次，且首选模型不可用时可切换到另一个合格模型——你选择的模型不保证是跑这一次的模型。
- 后续审查会折叠与近期改动无关的发现：同一个 PR 的第二轮及以后，历史遗留问题被折叠后隐藏，评审者看到的默认视图变短。
- 关闭再开启代码审查会保留计费与预览设置；机器人提交的 PR 在
Block reviews requested with an external Copilot license开启时仍可请求审查（组织付费前提下）。 - 审查概览 UI 变紧凑：跳过的文件与内容排除文件合并为「Files not reviewed」一个区块，空区块不再占位，长列表显示溢出计数； 后可「Add a reason」选择主要问题类型。
这次到底放开了什么
过去 Copilot 代码审查的设置只能在 Web 界面一层层点：企业管理员开关、组织默认档位、仓库是否用自定义指令和 MCP 工具。对一家有几百个仓库的组织，这意味着每次策略调整都是一轮人工点击，而且很难证明「策略确实生效了」。
现在同一批设置走 API，且官方给了明确的权限分层：
| 层级 | 能管什么 | 凭据限制 |
|---|---|---|
| 企业 | 为全部组织启用 / 禁用代码审查，或把决定权下放给组织管理员 | 不支持 GitHub Apps、不支持细粒度 PAT |
| 组织 | 启用状态、默认审查力度、Runner 配置（含新增组织 Runner 端点） | 同上 |
| 仓库 | 审查力度、是否使用自定义指令与 MCP 工具 | 支持 GitHub Apps 与细粒度 PAT，需 Administration: read/write |
「企业管理的设置不能被覆盖」这条官方写得很直白——一旦某项设置被企业层接管，组织与仓库层的写入不会生效。做自动化配置的团队要注意：你的脚本可能返回成功但设置没变，得读回来校验。
三处「看起来是改进、实际改口径」的变化
① 归因字段：从「猜是不是 Copilot 评的」到「能查是不是」
官方新增「显式归因字段」，让 API 能区分 Copilot 的审查与评论，并在元数据可用时给出这次审查用的 effort 档位，以及 Copilot 自己报告引用了哪些 skills、MCP server、自定义指令。
这条对做研发效能度量的团队是真增量：以前统计「AI 审查占了所有评论的多少」只能靠用户名匹配，机器人改了显示名就失真。现在有官方字段。但注意措辞是「Copilot 报告的来源」——这是模型的自我声明，不是系统层面的调用记录，把它当审计证据要打折。
② Balanced 档变成四模型：质量未证实，成本先变
原文："Balanced effort reviews now use three reviewer models, with another model combining their findings."
**这条写在「其他改进」里，很容易被当成纯好事跳过。**实际影响是：同一档位的一次审查，模型调用从「一个」变成「三个 + 一个汇总」。审查更慢、更贵是几乎必然的；是否更准，官方当日没有给任何数据。
按 AI credits 计费的组织，这一条会直接改变单 PR 的审查成本基线。升级后不要只看「审查还跑得动」，要重新量一遍月度 credits。
③ 自动重试 + 模型回退：结果可复现性下降
失败或超时的审查会自动重试一次，首选模型不可用时可换一个「合格模型」。作为可靠性改进这没问题，但如果你的团队做过「同一 PR 同一档位」的横向比较，现在比较的两侧可能根本不是同一个模型跑出来的。
对团队的实际影响
- 有平台工程的团队可以开始做「策略即代码」：企业层开关、组织默认档、仓库是否允许 MCP 工具，都能进 IaC 流水线。但企业/组织层必须用 Classic PAT 或等效凭据，这条会卡住已经全面迁移到细粒度 PAT 的组织——要么留一个特权凭据，要么继续手点。
- 做 AI 审查效果度量的：归因字段解决了「哪些评论是 AI 的」，但没解决「这条评论对不对」。评测仍然得靠自己标注样本，参考 AI 代码审查工具横评 里的接地做法。
- 按 credits 计费的组织：Balanced 档的调用次数变化会直接反映在账单上，季度预算要重算。
- 依赖「Copilot 抓到的问题会一直显示」的评审流程：后续审查折叠无关发现之后，老问题在默认视图里消失，需要主动展开。这条会改变 PR 的长尾问题可见性。
AI 之家 观点
一、这次更新的真正主题不是「API 化」，是「AI 审查开始被当成基础设施来治理」。 一个功能要能被企业管理、能被审计、能被归因，才会进入采购清单。GitHub 把三层设置全开出去，等于承认了代码审查已经从「插件功能」变成「组织级策略对象」——这跟两年前 Copilot 只在 IDE 里补全的位置完全不同。
二、但凭据限制暴露了治理模型还没迁完。 企业级和组织级端点不支持 GitHub Apps 与细粒度 PAT，意味着想做「最小权限的自动化」，恰恰在最需要它的那一层做不到。要么留一把能改全企业策略的 Classic PAT（这本身就是风险），要么人工点。这不是文档瑕疵，是权限模型的历史包袱：细粒度 PAT 的能力集还没覆盖企业级策略面。
三、Balanced 档的「三个审查模型 + 一个汇总」值得单独警惕。 多模型投票是提高召回率的常规手段，但它同时带来三个后果：成本上升、延迟上升、结论可解释性下降。真正该问的是「三个模型一致时是不是就不报了」——官方没答。在没有这批数据前，把 Balanced 当「更贵」而不是「更准」是更安全的默认。
四、给团队的三条动作：① 先读一遍现有组织的代码审查策略，确认哪些设置已被企业层接管，再决定自动化从哪一层写；② 按 credits 计费的组织升级后重测单 PR 成本；③ 在 PR 模板或评审规范里补一句「折叠的发现要主动展开」，否则长尾问题会静默消失。
待核实
- Balanced 档三模型的具体型号与投票规则（是否全票、加权、还是取合并结果）——官方只有一句描述。
- 「三个审查模型」是否计入 AI credits 三倍，以及各计划档位对此的限制。
- 企业级 / 组织级端点何时支持 GitHub Apps 与细粒度 PAT——官方未给时间表。
- 归因字段的稳定性：skills / MCP / 自定义指令的「来源」是模型自报还是系统记录，官方措辞是「Copilot reported」。
- 折叠规则的边界：多久算「近期改动」、被折叠的发现能否重新唤起，官方未说明。
相关阅读
- GitHub Copilot 工具卡
- AI 代码审查工具横评（CodeRabbit / Qodo / Greptile / Ellipsis）
- CodeRabbit 工具卡
- Copilot 进 JetBrains Air：云端任务的三个治理缺口
来源
常见问题
企业级和组织级设置端点支持 GitHub Apps 或细粒度 PAT 吗？
不支持。官方原文明确：企业和组织设置端点（含新增的组织 Runner 端点）不支持 GitHub Apps 与 fine-grained personal access tokens。仓库级端点两者都支持，需要 Administration 的 read / write 权限；Classic PAT 则需要仓库管理员权限。
Balanced 审查档为什么变贵了？
官方原文写「Balanced effort reviews now use three reviewer models, with another model combining their findings」，即一次 Balanced 审查会调用三个审查模型再加一个汇总模型。审查质量的变化官方未给数据，但模型调用次数从一档变成四档是明确的口径变化。
审查失败会自动重试吗？
会，官方写「Failed or timed-out reviews are retried once automatically」，且首选模型不可用时 Copilot 可切换到另一个合格模型。也就是说审查结果背后的模型可能不是你选的那个。