Copilot 代码审查设置可由 API 管理

Copilot Code Review 的管理边界已从网页设置扩展到 REST 与 GraphQL API：企业可设全局策略，组织可设默认审查力度和 runner，仓库可设审查力度、严重度过滤、指令与 MCP 开关。对开发团队而言，这使配置能够进入基础设施即代码和权限审计流程；但令牌类型、上级策略及 API 尚未覆盖的设置，决定了自动化究竟能改什么。

这次 API 增加了什么

GitHub 在 2026 年 11 月 6 日的变更说明中，将更新分成了两类。第一类是配置管理：企业管理员能启用或禁用所有组织的代码审查，也能把决定权交给组织管理员；组织管理员能调整功能启用状态、默认审查力度和 runner 配置；仓库管理员能设置审查力度，以及审查时是否使用仓库自定义指令和 MCP 工具。REST 与 GraphQL 两套 API 均可用于管理其中一部分设置。

第二类是审查结果的可识别性。REST 响应现在可通过明确的归属字段识别 Copilot 的审查和评论；在元数据可用时，还能读取该次审查使用的 effort，并查看 Copilot 报告某条评论参考过哪些 skills、MCP servers 和 custom instructions。这些信息适合进入内部审计或审查报表，但不应被解释为完整的模型推理轨迹：官方描述的是输出归属及其报告的来源，不是逐 token 的推理记录。

需要把配置能力与审查结果字段分开处理。前者改变组织实际采用的策略；后者帮助程序识别结果和配置来源。若只升级配置自动化却不读取返回字段，团队仍可能无法在汇总报表中辨别哪些评论来自 Copilot；若只消费归属字段，则不会自动启用审查功能。

先按管理层级拆分配置

实现时不要把企业、组织、仓库设置压成一个布尔值。企业策略决定代码审查对组织整体是启用、禁用，还是允许组织管理员自行决定。组织策略只有在企业授权组织管理的情况下才能由组织修改；组织的默认 effort 则用于没有仓库级覆盖的仓库。仓库配置只调整本仓库审查方式，不等同于打开代码审查功能。

GraphQL schema 把这些差异显式表达出来。例如，updateEnterpriseCopilotCodeReviewPolicy 更新企业策略；updateOrganizationCopilotCodeReviewPolicy 更新组织启用状态；updateOrganizationCopilotCodeReviewSettings 更新组织默认 effort；updateOrganizationCopilotCodeReviewRunnerConfiguration 设置组织 runner；updateRepositoryCopilotCodeReviewSettings 更新仓库级设置。组织和仓库设置 mutation 都说明：未提交的字段保持不变。因此自动化只应发送自己负责的字段，避免用一份全量配置意外覆盖控制台里由其他团队维护的值。

仓库设置的输入字段包括 reviewEffort、severityFilter、customInstructionsEnabled 和 mcpEnabled。其中 reviewEffort 可选 AUTO、LITE、BALANCED、MAX 或 INHERIT；INHERIT 表示清除仓库覆盖并回到上级或默认值。severityFilter 控制哪些严重度的评论被省略。组织默认 effort 也有 INHERIT，但它清除的是组织自己的默认值。两处同名概念的作用范围不同，回滚脚本应记录目标层级和原值，而不是只保存一个“继承”状态。

GraphQL 自动化的实施顺序

可以把配置流程拆成读取、授权判断、变更、回读四步。首先读取当前企业策略、组织可编辑状态、有效 effort 和仓库的已配置值；其次判断本次改动所在层级是否由当前管理员控制；然后只提交需要变化的字段；最后重新读取并比对配置值。GraphQL 返回值提供 configured 与 effective 等区分：配置值为空可能代表继承，而有效值仍有实际结果。只检查 mutation 是否返回成功，不足以证明预期策略已生效。

组织层的 schema 会返回 managedBy、editable、configuredState 和 effectiveState 等字段。若企业策略管理组织，组织 mutation 可能返回 POLICY_MANAGED_BY_ENTERPRISE 冲突；组织设置也可能返回 SETTING_NOT_EDITABLE。把冲突作为明确状态交给部署流水线，比吞掉错误后继续创建仓库配置更安全，因为下级配置无法绕过上级治理。

runner 也应单独管理。组织 runner 配置包括 runner 类型、标签或 runner group，以及仓库是否可自定义。GraphQL 文档说明，LABELED 类型至少需要一个 label 或 runner group；输入无效时配置不会改变。流水线因此应校验这些字段的组合，并在更新后读取有效 runner 配置。文档还区分配置来自代码审查设置还是继承自 coding agent runner，这能帮助排查“保存成功但实际 runner 与预期不同”的情况。

REST 令牌边界与未覆盖设置

REST 权限有容易踩到的差异：企业和组织设置端点（包括组织 runner 端点）不支持 GitHub Apps 或 fine-grained personal access tokens。仓库设置端点支持这两类身份；读取需要 Administration: read，更新需要 Administration: write。Classic personal access token 则需要仓库管理员权限。不要因为仓库级脚本使用 fine-grained token 能成功，就推断同一令牌也可以配置组织或企业；应将不同层级的凭据和权限检查拆开。

API 也不是网页设置的完整镜像。GitHub 文档明确指出，最大审查力度、计费方式和审批相关设置不在该 API 覆盖范围内。若配置代码把这些未覆盖项也写进“期望状态”，就会出现无法自动收敛的假告警。建议把配置分成 API 可管理项和需人工管理项，并在差异报告里标出边界，不要对未开放字段反复重试。

同样要区分“启用审查”和“调节审查”。GitHub 的 GraphQL 仓库设置说明明确写出，仓库级设置用于调整审查行为，并不会启用 Copilot Code Review。启用策略要在有权限的企业或组织层处理。这样分层后，仓库仓单可以安全地选择 effort、MCP 和指令，而不会被误当成拥有启用产品能力的权限。

落地检查

开始接入时，先选 GraphQL 还是 REST。需要同时读取有效值、继承状态和冲突原因时，GraphQL schema 提供了相应类型与 mutation；既有管理程序已围绕 REST 构建时，可沿用 REST，但要分别确认调用目标和令牌类型。不要把端点名称或权限从某一层复制到另一层，尤其不要把仓库的 fine-grained token 权限套用到组织设置。

接着建立最小变更集：明确哪些字段由代码管理、哪些由企业管理员管理、哪些仍需网页设置；为每个字段保存期望值、当前配置值和有效值。更新前确认 managedBy 或 editable，更新后回读。若返回冲突，停止覆盖并报告实际控制层级；若字段为空，区分“未设置并继承”和“功能关闭”。对 runner 更新还要检查 LABELED 所需标签或 runner group。

最后验证结果归属字段的消费方式。审查报表应将 Copilot 的 review/comment attribution 与 effort 元数据作为结构化字段保存；skills、MCP servers、自定义指令来源则按 API 实际返回值呈现。字段缺失时保留“未提供”的语义，不要推断为“没有使用”。这一点能避免把可选元数据误报成审查过程的确定事实。

对于同时治理编码代理和代码审查的团队，可以把本次 API 配置与已有的 GitHub Copilot 权限治理实践分开规划：前者管理审查策略、runner 和审查来源，后者关注代理可用模型及执行权限。若还需要比较不同 AI 开发平台的接入边界，可从平台目录查看各平台信息，但不要把模型调用配置与 GitHub 仓库审查策略混成同一权限域。