Copilot Code Review 从固定 Reviewer 演进为可编程 Runtime：仓库控制面、Setup 供应链、Runner 资源和 MCP 工具同时被纳入审查决策

Copilot Code Review 已成为可编程 Agent Runtime（2026-07-17 GitHub Changelog 解析）

TL;DR

• 场景：GitHub 在 2026-07-17 一次性把 Copilot Code Review 的 Instructions、Setup Workflow、Firewall、Runner 与 Cloud Agent 网络策略全部向前推进，单看是配置增强，组合起来是一套可编程 Agent Runtime。
• 结论：Review 结果开始由仓库控制文件、运行时依赖、工具、网络策略和 Runner 共同决定；Head Branch 读取 Instructions 让"被审对象和审查控制面同源"，需要独立治理控制文件 Diff。
• 产出：一张 Runtime 七层分解、一份最小治理模型（含 Owner / Lock / Isolate / Audit 四类门禁）、一组控制文件清单、12 条错误速查卡与上线前 10 项工程检查清单。

版本矩阵

文章正文

Copilot Code Review 已成为可编程 Agent Runtime

摘要

GitHub 在 2026 年 7 月 17 日把 Copilot Code Review 的多个能力同时向前推进：从 Pull Request 的 Head Branch 读取更多 Instructions 文件，允许通过专用 Workflow 准备依赖和 Runner，默认启用可独立配置的防火墙，并拆分组织级 Code Review 与 Cloud Agent Runner 设置。单独看，每一项都像配置增强；放在一起看，它们构成了一个可编程执行环境。

真正的变化不是 Reviewer 能读更多文本，而是 Review 结果开始由仓库控制文件、运行时依赖、工具、网络策略和 Runner 共同决定。Copilot Code Review 应被当作一项独立 CI Workload 管理，而不是聊天功能。

本文解决什么问题

本文回答四个问题：

1. 为什么这次更新意味着 Agent Runtime，而不只是功能增加；
2. Runtime 的控制面、数据面和执行面分别是什么；
3. Head Branch Instructions 为什么形成新的信任边界；
4. 团队应如何建立最小治理框架，而不把 Preview 能力写成成熟安全方案。

官方更新了什么

根据 GitHub Changelog，本次变更包括：

• Code Review 从 Head Branch 读取 copilot-instructions.md、*.instructions.md、Agent Skills 和 AGENTS.md；
• 新增读取 REVIEW.md、GEMINI.md、CLAUDE.md；
• 支持 .github/workflows/copilot-code-review.yml，用于安装依赖、配置 Runner、准备工具和执行预处理；
• 若专用文件不存在，可以回退到 copilot-setup-steps.yml；
• Code Review 默认运行在防火墙之后；
• Code Review 与 Cloud Agent 的网络策略可独立配置；
• 自托管 Runner 当前不支持平台防火墙；
• 组织级 Runner 设置在 Changelog 中被描述为已拆分。

这里存在两处必须公开说明的文档冲突。当前 GitHub 使用文档仍写 Code Review 从 Base Branch 读取 Instructions；当前 Runner 文档仍写组织级配置同时作用于 Code Review 和 Cloud Agent。由于 7 月 17 日 Changelog 直接描述"现在改为"Head Branch 和"现在拆分"，本文把 Changelog 视为较新的行为说明，但不把文档滞后当作已确认事实。生产团队应以账号实际行为和 GitHub Support 回复为最终依据。

从 LLM 调用到 Runtime

传统的 AI Code Review 可以简化成：

Diff + Prompt -> Model -> Comments

这种模型里，风险主要集中在上下文质量、模型误报和输出审查。现在的执行链更接近：

IDE / Pull Request UX↓Instruction Resolution↓Runtime Setup↓Runner / Workspace↓Skills / MCP / Tools↓Network Policy↓Reviewer Model↓Comments / Logs / Metrics / Audit

每一层都有独立的版本、权限和失败模式。

1. Instructions 是行为控制面

Instructions 不只是额外上下文。它们定义 Reviewer 应关注什么、忽略什么、使用哪些检查清单以及如何解释仓库约定。当系统同时读取 AGENTS.md、REVIEW.md、CLAUDE.md、GEMINI.md 和路径级 Instructions 时，团队必须面对三个问题：

• 多份文件冲突时谁优先；
• 哪个目录的文件对哪些代码生效；
• 谁可以修改这些文件。

GitHub 当前公开资料没有给出本文可以稳定引用的完整优先级表。因此文章不能编造一个"官方加载顺序"。工程上应先把这些文件视为同一类控制资产，再通过仓库规范减少重叠。

2. Setup 是可执行控制面

copilot-code-review.yml 允许在 Review 前安装依赖、准备工具和选择 Runner。只要配置能够执行命令，它就不再是普通文档，而是供应链入口。依赖来源、Action 版本、包管理器锁文件、安装脚本和环境变量都会影响 Reviewer 能看到什么、运行什么。

"让 Reviewer 跑测试"会提高准确性，但也把包安装脚本、构建工具和网络访问纳入威胁模型。一个被篡改的依赖安装步骤可能在模型开始审查前就已经执行。

3. Runner 是资源与网络边界

GitHub 文档说明 Code Review 的 Agentic 能力运行在 GitHub Actions 环境。默认 GitHub-hosted Runner 是临时环境；自托管方案目前只正式支持 ARC 管理的 Ubuntu x64 Runner。选择自托管不是简单的性能优化，而是把网络、凭据、镜像、工作区销毁和横向移动风险交给组织自己管理。

4. Firewall 是部分网络策略

GitHub 明确说明防火墙默认限制互联网访问，也明确说明其局限：

• 只覆盖 Agent 通过 Bash 工具启动的进程；
• 不覆盖 MCP Server；
• 不覆盖配置的 Setup Steps；
• 不覆盖 Actions appliance 外部的进程；
• 高级攻击可能绕过。

因此正确表述是"提供常见场景下的出站限制"，不是"形成完整沙箱"。

5. Skills 与 MCP 扩大工具面

当前 GitHub 使用文档把 Code Review 对 Agent Skills 和 MCP Server 的支持标为 Public Preview。工具提高 Reviewer 的上下文能力，也增加新的数据源、认证和网络路径。尤其是 MCP 流量不受该 Agent Firewall 覆盖，网络审计不能只检查 Firewall Allowlist。

新的核心风险：被审对象和审查控制面同源

Head Branch 读取 Instructions 的产品价值很明确：团队可以在 Feature Branch 验证新规则，无需先合并主分支。但它也改变了信任关系。

过去的直觉是：

Base Branch Policy 审查 Head Branch Code

新的可能语义是：

Head Branch Policy 审查 Head Branch Code

这不自动等于漏洞。是否可利用取决于 Fork PR、仓库权限、Workflow 读取分支、Secrets 暴露、Ruleset 和 GitHub 内部实现。但从治理角度，团队必须假设 PR 可能同时改变：

• 业务代码；
• Review 指令；
• Review Skill；
• Setup Workflow；
• Runner 选择；
• 工具配置。

这意味着普通 Code Diff 之外，还需要 Control-plane Diff。

一套最小治理模型

控制资产清单

至少把以下路径列为 Reviewer 控制资产：

.github/copilot-instructions.md.github/instructions/**/*.instructions.md.github/skills/**.github/workflows/copilot-code-review.yml.github/workflows/copilot-setup-steps.ymlAGENTS.mdREVIEW.mdCLAUDE.mdGEMINI.mdMCP configuration

实际路径需要按仓库结构调整。重点不是文件名完整性，而是任何能改变模型规则、工具、依赖、Runner 和网络的资产都应纳入同一控制集合。

变更门禁

建议建立四级处理：

GitHub CODEOWNERS 和 Rulesets 可用于实现审批，但不能仅依赖 AI Reviewer 自己判断"自己的规则是否被安全修改"。控制文件审批必须由独立机制执行。

基线与审计

为每次 Review 记录：

pull_request_shabase_shainstruction_files + content_hashskill_manifest + content_hashsetup_workflow_hashrunner_typerunner_image/versionfirewall_policy_versionmcp_server_config_hashmodel/provider/versionreview_started_atreview_completed_atoutput_comment_ids

GitHub 当前是否暴露所有字段并不确定。这是建议的审计模型，不是官方 API Schema。无法直接获得的字段可先由自建检查 Workflow 记录。

可复现性不是"同一个 Prompt"

Agent Review 的可复现性至少包含五个维度：

1. 代码版本；
2. 指令与 Skill 版本；
3. 依赖和工具版本；
4. Runner/网络环境；
5. 模型和服务端策略版本。

只保存 Prompt 无法解释为什么同一 Diff 在两天后得到不同意见。团队应把 Review 视为带外部依赖的构建任务：能够重放输入、识别环境漂移、记录失败和比较输出。

企业级策略模板

# 这是组织策略示意，不是 GitHub 官方配置格式review_control_policy:protected_paths:- ".github/copilot-instructions.md"- ".github/instructions/**"- ".github/skills/**"- ".github/workflows/copilot-code-review.yml"- "AGENTS.md"- "REVIEW.md"- "CLAUDE.md"- "GEMINI.md"approvals:instructions: ["review-governance-maintainers"]executable_setup: ["platform-security"]network_and_mcp: ["security-admins"]checks:- control-plane-diff- dependency-pin-validation- outbound-policy-validation- instruction-conflict-scanblock_on_unknown_instruction_precedence: true

这段 YAML 是 Policy-as-Code 设计示例，用于表达责任边界，不应直接提交为 GitHub 原生配置。

常见误区

"默认防火墙已经解决供应链风险"

错误。Setup Steps 和 MCP 不在该防火墙的覆盖范围内；防火墙本身也被官方描述为非全面方案。

"Instructions 只是 Prompt，不需要 CODEOWNERS"

错误。Instructions 可以改变 Review 关注点和工具使用，属于行为控制面。

"自托管 Runner 更安全，因为在内网"

错误。内网连接意味着潜在影响更大。安全取决于隔离、最小权限、临时凭据、网络出口和销毁机制。

"PR 被 Copilot Review 就等于通过质量 Gate"

错误。GitHub 文档说明 Copilot 留下的是 Comment Review，不是 Approve 或 Request Changes，不计入必需审批，也不会自动阻止合并。

工程检查清单

• 枚举所有可能被 Code Review 读取的 Instructions 和 Skills。
• 对控制资产设置独立 CODEOWNERS/Ruleset。
• 将 Setup Workflow 视为可执行供应链代码。
• 固定第三方 Actions 到不可变提交或可信版本策略。
• 验证 Fork PR、外部贡献者和 Secrets 的真实行为。
• 分别审计 Agent Bash、Setup Steps、MCP 的网络路径。
• 自托管 Runner 使用 ARC、临时实例、最小网络和无持久工作区。
• 保存指令、Workflow、Runner、Policy 和模型版本。
• 把文档冲突列为上线前验收项。
• 定期运行 Prompt Injection 和控制文件篡改回归测试。

对团队的影响

Copilot Code Review 的采购问题已经从"是否启用 AI Review"变成"谁拥有 Reviewer Runtime"。平台团队需要提供受控环境，安全团队需要定义出站与工具边界，仓库 Maintainer 需要维护 Review Policy，工程效能团队需要记录采纳率和缺陷结果。没有清晰责任划分时，功能越可配置，行为越难解释。

结论

2026 年 7 月 17 日的更新标志着 Copilot Code Review 从固定 Reviewer 向可编程 Runtime 演进。价值是更贴合仓库、更能运行真实验证；成本是控制面扩大、供应链入口增加、网络覆盖出现分层。正确落地方式不是关闭所有能力，而是把 Reviewer 当作独立 CI Workload：保护控制文件、锁定环境、限制网络、保存证据、验证结果。

参考资料

1. GitHub Changelog: Copilot code review customization and configurability improvements
2. GitHub Docs: Using GitHub Copilot code review
3. GitHub Docs: Configure the development environment
4. GitHub Docs: Customizing or disabling the firewall for GitHub Copilot
5. GitHub Docs: Configuring runners for GitHub Copilot code review

错误速查卡