系列位置：基础篇第 27 篇（总第 56 篇）
承接：  Assistants API 已关闭：给 Responses 迁移补一张“切换后证据卡”：https://blog.csdn.net/THE_BULE_BOTTOW/article/details/164118950?spm=1001.2014.3001.5501 
调研日期：2026-08-28
本文目标：GitHub Copilot Code Review 已能为特定机器人作者 PR 和 Copilot cloud agent PR 提供完整的 agentic review，并取消过去的 300 文件或 2 万行审查上限。本文把这项能力翻译成一份团队可执行的审查合同：大 PR 可以进入审查队列，不等于可以越过分层切片、预算、人审、合并规则和事后回放。

30 秒结论

2026 年 8 月 27 日，GitHub 宣布 Copilot Code Review 扩大了覆盖范围：在满足组织策略的情况下，它可以审查自动请求审查的机器人作者 PR；对 Copilot cloud agent 创建、原先只能得到有限体验的 PR，改为提供 full agentic review；过去 300 个文件或 2 万行代码的大小限制也不再适用。

但这不是“超大 Agent PR 已被自动验收”的公告。GitHub 的使用文档明确：Copilot 始终留下的是 Comment 类型的 review，不是 Approve 或 Request changes；它不计入 required approvals，也不会自行阻止合并。文档同时明确提醒 Copilot 可能漏报或出错，反馈需要人工验证。

因此，团队应把这次变化理解为：自动产出的变更终于能获得更完整的机器证据，而非自动取得发布资格。 大 PR 的合并资格仍必须由可执行测试、受保护分支规则、负责人的人工判断和可回放的证据共同决定。

---

一、先把公告事实和团队推断分开

最容易造成事故的不是 Copilot 给出了一条错评，而是团队在流程中悄悄把“有评论”升级成“已批准”。先把两类陈述分开，后续的门禁才不会建立在产品没有承诺的前提上。

维度	GitHub 已公开的事实	团队必须自行建立的推断与控制
覆盖范围	自动请求审查的机器人作者 PR 可以被审查；Copilot cloud agent PR 可获 full agentic review	哪些 bot、仓库、分支和变更类别允许自动请求审查
变更规模	原 300 文件或 2 万行的审查限制不再适用	超大变更是否应拆 PR、是否先做架构审查、每个切片需要多少人审
审查结论	Copilot 留下 Comment review；不算 required approval，不会单独阻止合并	哪些检查必须通过、谁能批准、何时升级到安全或领域负责人
运行能力	agentic review 可做全项目上下文收集，并可把建议交给 Copilot cloud agent；它依赖 GitHub Actions 运行器	上下文、MCP 工具、运行器和 Actions 分钟的可用范围及故障时的降级动作
新关闭原因	可选择 Addressed、Won’t fix、Incorrect 来关闭 Copilot 评论，供产品改进反馈	这些标签如何进入团队缺陷、例外和回归样本的复盘流程

尤其要注意“取消上限”只说明此前的大小门槛不再适用。公告没有给出“任意大小 PR 都有相同检出率”“等待时间恒定”“成本封顶”或“模型能理解全部跨服务影响”的保证。现实中，变更越大，依赖关系、构建矩阵、提示上下文和审查者的认知负担通常都越难管理。把大 PR 送去审，正好应触发更多控制，而不是更少。

---

二、机器人 PR 能被审，先确认策略和账单是谁的

“机器人作者”不是一种可忽略的特殊身份。一个机器人可能只是 CI 帐号，也可能代表能修改代码、生成依赖升级、重写基础设施或批量修复漏洞的 Agent。GitHub 为无 Copilot 许可证成员及相应的自动审查提供了组织策略与计费路径，但这并不等于所有机器人都天然获准消耗组织预算。

已知的产品边界

GitHub 文档说明，组织希望让没有 Copilot 许可证的成员在 GitHub.com 使用 Code Review，需先启用“AI credits paid usage”，再启用“Allow members without a Copilot license to use Copilot code review in GitHub.com”。后一策略默认关闭、采用最严格原则，并且只在显式启用的组织仓库中有效。自动代码审查开启后，符合该策略的仓库会自动审查 PR，不取决于作者是否拥有 Copilot 许可证。

对于由 GitHub Actions 或 bot 创建的 PR，文档列出的归属顺序是：若能识别到触发工作流的用户，使用量归该用户；否则归指定的 billing owner。对无许可证用户，产生的 AI credits 是组织或企业的付费附加用量，而不是个人月度额度。代码审查还有两类成本：模型交互的 AI credits，以及用于 agentic context gathering 和工具使用的 GitHub Actions minutes。

这些事实带来一个很实际的工程问题：若“自动生成 PR → 自动审查”没有明确触发者、账单负责人和上限，那么一次依赖机器人失控、一次批量修复或一次每次 push 都触发复审的规则，就可能同时扩大排队、账单和噪声。

团队应补上的策略表

建议不要把“允许机器人审查”设为单一布尔值，而是维护下列最小清单。它不是 GitHub 原生配置格式，只是团队的策略记录，字段名称可以按内部系统调整。

条目	要写清的内容	为什么不能省略
作者身份	bot/Agent 名称、安装来源、允许的仓库和分支	防止把未知自动化账户纳入组织付费审查
触发归属	workflow 触发者、不可识别时的 billing owner	让预算异常能追到真正的责任人
审查范围	草稿 PR 是否审、是否每次 push 复审、是否只审风险标签 PR	避免一个长期更新的 PR 反复消耗预算
工具与上下文	是否允许 MCP、只读数据源、允许的 Actions runner	Code Review 可使用的上下文不应超过机器人本身的业务需要
合并门槛	必需测试、必需人审角色、禁止自动合并的条件	让机器评论永远不替代仓库保护规则
停止条件	预算、失败率、超时、误报率或安全异常的阈值	发生异常时可以立刻缩小范围而非临场争论

这里应避免另一种误读：策略开启并没有让“bot 的产出”变成可信来源。它只允许该 PR 获得 Copilot review，并定义相关用量的承担方式。供应链签名、分支保护、CI 权限、依赖来源以及发布审批仍是各自独立的控制面。

---

三、把“大 PR”拆成可验证的分层切片

取消 300 文件/2 万行限制以后，最合理的默认反应不是把历史积压的巨型分支一次性打开自动合并，而是改进切片方式。PR 的总规模很大时，审查系统看到的是一个更广的候选集合；发布系统则仍应面对一组可独立验证、可回退的风险单元。

1）先按副作用边界切，而不是按目录凑批

一个 Agent 很容易按“改完所有匹配文件”生成一大组修改，但审查契约应优先依据副作用和回滚边界切片：

切片	典型内容	应有的最小证据	默认合并姿态
纯机械改动	格式化、明确的 API 重命名、生成文件更新	可重复生成记录、diff 统计、构建通过	可由代码所有者抽样人审
行为局部改动	一个模块的逻辑、单一服务接口	单元/契约测试、异常路径、回滚说明	至少一位领域审查者
跨服务改动	协议、数据模型、权限或队列语义	集成测试、兼容策略、迁移与回滚演练	架构/平台人审，不应仅依赖评论
高风险写入	支付、生产权限、删除、部署、密钥和合规数据	明确审批、最小权限、干跑或受控 canary	默认暂停，等待指定责任人批准

这不是要求每个提交都拆成一个 PR。真正的原则是让每一个待批准单元有可说清的目的、测试范围、影响面和恢复路径。无法说明这些内容的巨型 PR，即使 Copilot 已能审，也仍应要求作者先给出变更地图，必要时退回拆分。

2）让 Copilot 做“发现候选问题”，让规则和人做“决定”

Copilot Code Review 能用全项目上下文收集信息；当 GitHub-hosted runners 被禁用或相关 Actions 工作流失败时，文档说明 review 仍会生成，但不会包含这些额外 agentic capabilities。因而审阅页面上出现评论并不能证明本轮得到了同样深度的上下文分析。

团队可以把每轮审查视为一份辅助证据：记录使用的 effort level、是否有 agentic capability 降级、相关 CI 状态、评论数量及处理状态。真正的合并判定仍由受保护分支的 required checks、代码所有者审查与人工评估组成。对于流程受控的组织，更稳妥的逻辑是：

Copilot comment / no comment
        ↓
测试、静态分析、依赖与部署检查
        ↓
代码所有者与风险负责人确认
        ↓
满足仓库规则后，才允许合并

no comment 只表示这一次辅助审查没有留下评论，绝不能被仪表盘转换为“无缺陷”。同样，出现评论也不自动证明修改建议正确；它可能是值得调查的信号、误报，或本来就由其他约束处理的风险。

---

四、把预算与审查强度当成门，而不是质量承诺

GitHub 在 8 月 7 日将 Lite 与 Balanced 审查强度 GA。Lite 面向快速、聚焦的常见问题反馈；Balanced 会以更高推理能力更长时间分析复杂逻辑、安全敏感代码和跨服务变更。GitHub 文档还明确，Balanced 通常使用更多 AI credits，并且可能消耗更多 GitHub Actions minutes；消耗一般也随 PR 大小和仓库自定义指令增加。

因此，“Balanced”应被当作一笔有预算、需记录的审查投入，而不是“更高强度就可以省略人审”的质量保证。以下是一个可复制的团队审查合同示例。它刻意不用任何 GitHub 配置字段，也不会宣称可以直接粘贴进 GitHub；团队可将其保存为 PR 模板、变更单或内部策略记录。

# 团队审查合同示例，不是 GitHub 原生 schema，也不会自动配置 Copilot。
review_contract:
  change_id: PR-1842
  author_kind: copilot-cloud-agent
  repository_tier: internal-service
  change_slices:
    - name: api-compatibility
      risk: cross-service
      required_evidence:
        - contract-tests
        - rollback-plan
      human_roles:
        - api-owner
        - service-owner
    - name: deployment-manifest
      risk: production-write
      required_evidence:
        - dry-run
        - change-approval
      human_roles:
        - release-manager

  copilot_review:
    requested: true
    effort: balanced
    re_review_on_new_push: false
    agentic_capability_required: true
    allowed_context_categories:
      - repository-code
      - approved-issue-metadata
    mcp_write_tools_allowed: false

  budget_guard:
    billing_owner: platform-engineering
    max_review_runs: 2
    stop_when:
      - review-run-exceeds-change-budget
      - agentic-capability-degraded
      - required-check-fails

  merge_gate:
    copilot_comment_is_approval: false
    required_checks:
      - unit-tests
      - integration-tests
      - dependency-scan
    required_human_approvals: 2
    prohibited_conditions:
      - unresolved-security-finding
      - unowned-high-risk-slice

max_review_runs 与 re_review_on_new_push 的存在尤其重要。GitHub 默认不会在后续 push 后自动重新审查；组织可以配置每次新 push 复审。若团队对一个大型 Agent PR 启用后者，必须将复审次数、变更窗口和预算一并纳入合同，否则“修一条评论再 push 一次”的正常迭代，会变成不可预估的重复消费。

---

五、关闭原因是反馈分类，不是事实裁决

8 月 27 日的更新让审阅者可以把 Copilot 评论标记为 Addressed、Won’t fix 或 Incorrect 后关闭。这一变化有价值：它让团队不必把所有关闭动作混成一个无含义的“已处理”，也可为 GitHub 产品团队提供更结构化的反馈。

不过，三个标签并不是自动验证系统：

• Addressed 表示有人认为已采取处理动作；它不证明改动没有引入新问题，也不证明测试覆盖充分。
• Won’t fix 表示团队选择不按该建议修复；应留下简短的风险接受理由、替代控制或负责人，而不是把它当成忽略告警的快捷键。
• Incorrect 表示评论被判断为不正确；它是对本条建议的反馈，不等于 Agent、模型或整个 PR 已被判定可靠。

对于安全、数据迁移、权限或生产写入类评论，建议不要只依赖关闭理由。应额外记录“谁判定”“依据什么测试/规范”“是否有后续复查”。对高频 Incorrect 的类型，应把脱敏案例收进内部评测夹具或审查指引；对高频 Won’t fix，则要问清楚规则本身是否和架构现实冲突。这样，标签才从产品反馈变成团队可学习的信号，而不是漂亮的关闭率。

---

六、MCP、指令和 Agent 产物必须有回放门

当前文档说明，Code Review 可在相关时使用仓库级 agent skills 和 MCP servers；GitHub MCP 与 Playwright MCP 默认启用，仓库设置中允许 Copilot 在 PR review 使用 MCP 工具的选项默认开启。文档还说明，审查会从变更头分支读取 repository custom instructions、agent instructions 和 skills，而不是从 base branch 读取。

这意味着一个很大的 Agent PR 不仅可能包含应用代码，也可能包含会影响审查上下文的说明、skills 或 MCP 配置。即便它们没有运行时业务代码那么醒目，仍应被纳入变更地图和审查范围。不能因为“只是给 Copilot 的提示”就绕过代码所有者、安全审查或配置回放。

建议在每个高风险 PR 的合并前保留最小回放卡；同样，这只是团队记录，不是 GitHub 原生 schema：

# 团队回放卡示例，不包含 prompt、令牌、源码或完整 MCP 响应。
review_replay_card:
  pull_request: 1842
  reviewed_head_sha: 8f3c...redacted
  review_effort: balanced
  agentic_capability: available
  mcp_context:
    enabled_categories:
      - issue-tracker-read-only
    write-capable-tools: disabled
  evidence:
    - required-checks-url-recorded
    - code-owner-approval-recorded
    - security-comment-disposition-recorded
  merge_decision:
    owner: release-manager
    decision: approved-after-human-review
  follow_up:
    - re-run-review-if-head-sha-changes

回放卡不应保存原始 prompt、客户数据、密钥或完整第三方工具响应。它的作用是让事故复盘时能回答：审的是哪一个 commit？本轮是否具备 agentic capabilities？用了什么类别的外部上下文？哪些人和哪些检查共同决定合并？如果 head SHA 已变，旧评论又是否还可被当作当前证据？

---

七、六个常见误区

1）“取消文件和行数上限”就是“适合提交单体巨型 PR”

不再拒绝超大 PR，不代表超大 PR 的依赖、回滚和人工理解成本消失。优先按副作用、服务边界和发布风险拆分；无法拆分时，至少先审变更地图与迁移计划。

2）“full agentic review”就是“完全等价于人类全仓审查”

它代表产品能力范围的提升，包含完整项目上下文等 agentic capabilities。GitHub 同时说明，运行器不可用或相关 Actions 失败时会降级；并且 Copilot 不保证发现所有问题。把它称为自动化辅助证据更准确。

3）Copilot 没有评论，就可以跳过 required approvals

官方文档已经明确：Copilot 留下的是 Comment，不计入 required approvals，也不会阻止 merge。分支规则、必需检查和人审仍须独立配置、独立执行。

4）给自动 PR 配上审查，就不再需要预算治理

机器人/Actions PR 的使用量可能归触发者或指定 billing owner；没有许可证成员的用量还可能成为组织付费附加使用。每次 push 是否复审、审查强度与 runner 选择都会影响成本和排队。

5）Incorrect 就证明模型不可靠，Addressed 就证明代码正确

它们只是对单条评论处置的分类。真正的结论要回到测试结果、领域规范、风险接受记录和人工复核。

6）只审核生成的业务代码，不审核它带来的审查上下文

头分支上的 instructions、skills 和 MCP 配置可能影响 Copilot Review 读取和调用什么。应把这些文件视为审查系统的供应链输入，单独设所有者和回放证据。

---

八、未来 72 小时行动清单

第 0 天：收紧入口

• 盘点自动创建 PR 的 bot、Copilot cloud agent、GitHub Actions 工作流和其触发者；为无法识别触发者的路径指定 billing owner。
• 核对 AI credits paid usage、无许可证 Code Review 策略、自动 review 规则和仓库覆盖范围；不要把全组织策略作为第一个试点。
• 在一个低风险仓库检查：Copilot 评论是否仍只是 Comment、分支 required checks 与 required approvals 是否独立生效。

第 1 天：建立切片和预算证据

• 选择一份代表性 Agent PR，按机械、局部行为、跨服务和高风险写入四类切片标注；先补变更地图、测试和回滚点，再请求高强度审查。
• 为 Lite/ Balanced、每次 push 是否复审、最大 review runs、可用 runner 及 Actions minutes 设定短期预算；记录本轮实际使用，而不是只看预估。
• 检查 MCP 工具、skills 与 instructions 是否在头分支变更中；对写能力 MCP 默认关闭或要求额外审批。

第 2 天：把合并决定做成可回放证据

• 对一项跨服务或安全敏感变更，试跑本文的审查合同和回放卡，验证 head SHA、检查、审查角色、评论处理和合并决定能否关联。
• 故意模拟 agentic capability 降级、测试失败或预算触顶；确认流程会暂停或转人工，而不是因为 Copilot 留下了评论就继续合并。
• 汇总 Addressed、Won’t fix、Incorrect 的样本，挑出一个高频类别，转化为更清楚的测试、仓库指令或人工审查清单。

这三天的目标不是追求“Copilot 审得更多”，而是证明在它审得更大、更自动化的 PR 时，团队仍能回答：谁提交、谁付费、哪些工具与上下文参与、什么证据允许合并，以及失败后怎样停止和复盘。

---

结语

Copilot Code Review 对 Agent 和机器人 PR 的扩展，解决的是自动化变更缺少审查入口的问题；取消大 PR 限制，则让它能被带入更复杂的工程场景。但入口扩大并不改变合并的责任归属。

最稳妥的升级路径是：将 Copilot 评论定位为候选问题和上下文证据，将 Lite/ Balanced 视为可计量的审查投入，将关闭原因作为反馈分类；再用策略、切片、预算、必需检查、人审和回放卡守住真正的发布门。这样，团队才能既利用 Agent 生成代码的速度，也不把速度误当成可信度。

---

来源与延伸阅读

• Copilot code review: Resolution reasons and expanded capabilities：GitHub 官方 Changelog，2026-08-27。用于核验机器人作者 PR、Copilot cloud agent PR 的 full agentic review、取消 300 文件/2 万行限制，以及 Addressed、Won’t fix、Incorrect 三种关闭原因。
• About GitHub Copilot code review：GitHub 官方产品概念文档，本文于 2026-08-28 复核。用于核验无许可证成员策略、机器人/Actions PR 的计费归属、agentic capabilities 与 Actions runner、Lite/ Balanced、成本构成、MCP/skills，以及“可能漏报或出错，需人工验证”的边界。
• Using GitHub Copilot code review on GitHub：GitHub 官方操作文档，本文于 2026-08-28 复核。用于核验 Copilot 仅留下 Comment、不计 required approvals、不能独立阻止合并，以及后续 push 的复审、头分支 instructions/skills 与 MCP 使用边界。
• Copilot code review effort levels are generally available：GitHub 官方 Changelog，2026-08-07。用于核验 Lite/ Balanced 的 GA 状态、复杂/安全敏感/跨服务变更需要更深分析，以及组织默认值的能力。