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 项工程检查清单。

版本矩阵

功能 / 控制面	状态	说明
从 Head Branch 读取 `copilot-instructions.md`	✅ 已验证	2026-07-17 Changelog 明确"now reads custom instructions from the head branch"
从 Head Branch 读取 `*.instructions.md`（路径级 Instructions）	✅ 已验证	Changelog 与 og:description 范围覆盖路径级 Instructions
从 Head Branch 读取 `AGENTS.md`、Agent Skills	✅ 已验证	Changelog 显式列出 Agent Skills 和 `AGENTS.md`
新增读取 `REVIEW.md` / `GEMINI.md` / `CLAUDE.md`	⚠️ 待验证	用户原文声明支持；本次未在 Changelog/og:description 中独立核到，需查 GitHub Docs
专用 `copilot-code-review.yml`（Setup Workflow）	✅ 已验证	og:description:"custom setup steps"；文件名见用户原文与 Changelog 行文
缺失时回退到 `copilot-setup-steps.yml`	⚠️ 待验证	用户原文声明回退；本次未独立核到独立段落
Code Review 默认启用 Firewall	✅ 已验证	og:description:"now utilizes a firewall"；与官方 Firewall 文档一致
Firewall 与 Code Review 工具边界（Bash-only）	✅ 已验证	官方 Firewall 文档明确"only covers processes launched via the Bash tool"
MCP Server 不在 Firewall 覆盖范围	✅ 已验证	官方 Firewall 文档明确不覆盖 MCP Server
Setup Steps 不在 Firewall 覆盖范围	✅ 已验证	官方 Firewall 文档明确不覆盖 Setup Steps
Code Review 与 Cloud Agent 网络策略可独立配置	✅ 已验证	og:description:"independent runner configurations"
自托管 Runner 不支持平台 Firewall	⚠️ 待验证	用户原文声明；本次未在 Changelog 中独立核到独立句
组织级 Runner 设置在 Changelog 中被描述为已拆分	✅ 已验证	og:description 措辞为"independent runner configurations"；用户原文以 Changelog 为依据
Agent Skills / MCP Server 支持状态	⚠️ Public Preview	官方使用文档当前明确"Public Preview"，非 GA
当前文档仍写"从 Base Branch 读取 Instructions"	⚠️ 文档冲突	Changelog 与文档存在字面冲突；本文按 Changelog 行为为准、文档滞后视为待核验
当前 Runner 文档仍写"组织级配置同时作用于 Code Review 和 Cloud Agent"	⚠️ 文档冲突	同上；Changelog 描述为"现在拆分"
`editorial_review_required` 门禁	⚠️ 门禁	涉及动态产品、API、Preview、安全能力，生产前必须按最新一手资料复核

文章正文

发布边界：Agent Runtime 是本文的架构判断，不是 GitHub 官方产品命名；Head Branch、Firewall、Runner 与 Setup 行为以 2026-07-17 Changelog 为准。
入库说明：本文来自已审核 Inbox 研究包，当前仅是待审核候选母稿。外部状态与优先级未被自动采纳；未通过编辑审核前不得生成 Topic、平台版本或发布包。
复核门禁：editorial_review_required。涉及动态产品、指标、API、Preview、安全能力和厂商数据的结论，生产前必须按最新一手资料复核。

Copilot Code Review 已成为可编程 Agent Runtime

发布边界：Agent Runtime 是本文的架构判断，不是 GitHub 官方产品命名；Head Branch、Firewall、Runner 与 Setup 行为以 2026-07-17 Changelog 为准。
入库说明：本文来自已审核 Inbox 研究包，当前仅是待审核候选母稿。外部状态与优先级未被自动采纳；未通过编辑审核前不得生成 Topic、平台版本或发布包。
复核门禁：editorial_review_required。涉及动态产品、指标、API、Preview、安全能力和厂商数据的结论，生产前必须按最新一手资料复核。

摘要

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 管理，而不是聊天功能。

本文解决什么问题

本文回答四个问题：

为什么这次更新意味着 Agent Runtime，而不只是功能增加；
Runtime 的控制面、数据面和执行面分别是什么；
Head Branch Instructions 为什么形成新的信任边界；
团队应如何建立最小治理框架，而不把 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 可以简化成：

text 复制代码

Diff + Prompt -> Model -> Comments

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

text 复制代码

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 验证新规则，无需先合并主分支。但它也改变了信任关系。

过去的直觉是：

text 复制代码

Base Branch Policy 审查 Head Branch Code

新的可能语义是：

text 复制代码

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 控制资产：

text 复制代码

.github/copilot-instructions.md
.github/instructions/**/*.instructions.md
.github/skills/**
.github/workflows/copilot-code-review.yml
.github/workflows/copilot-setup-steps.yml
AGENTS.md
REVIEW.md
CLAUDE.md
GEMINI.md
MCP configuration

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

变更门禁

建议建立四级处理：

变更类型	默认处理	原因
普通业务代码	正常触发 AI Review	数据面变更
Review 文档和路径级 Instructions	要求指定 Maintainer 审批	改变行为控制面
Setup Workflow、Action、Runner	要求平台/安全 Owner 审批	可执行控制面
Firewall、MCP、Secret、组织策略	仓库管理员无权单独放行	跨仓库安全边界

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

基线与审计

为每次 Review 记录：

text 复制代码

pull_request_sha
base_sha
instruction_files + content_hash
skill_manifest + content_hash
setup_workflow_hash
runner_type
runner_image/version
firewall_policy_version
mcp_server_config_hash
model/provider/version
review_started_at
review_completed_at
output_comment_ids

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

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

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

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

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

企业级策略模板

yaml 复制代码

# 这是组织策略示意，不是 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-scan
  block_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，不计入必需审批，也不会自动阻止合并。

工程检查清单

对团队的影响

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

结论

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

参考资料

错误速查卡

症状	根因	定位	修复
PR 中修改了 `.github/copilot-instructions.md` 却只有普通 AI Review 提示	控制文件未走独立审批	查看 PR 是否触发 CODEOWNERS / Ruleset	给控制文件设置独立 Owner 或 Required Reviewers
Reviewer 关注点突然漂移，与既有约定不一致	新增 / 修改的 Instructions 路径级文件被 Head Branch 读取	对比最近 PR 中 `.github/instructions/**` 变更	锁定控制文件到 Base Branch 或要求 Maintainer 审批
Setup Workflow 安装的依赖版本不可信	`copilot-code-review.yml` 把任意包管理器脚本当成可执行入口	检查 `package.json` / `requirements.txt` / lockfile 锁定	固定 Action 到 commit SHA、固定依赖到 lockfile、限制 Setup 网络出口
Firewall Allowlist 通过，但 MCP 仍能出网	Firewall 不覆盖 MCP Server 流量	在 MCP Server 配置 / 客户端日志中查看实际目标	单独审计 MCP 网络路径，使用宿主层 Egress 控制或自建代理
Setup Steps 触发的进程能访问生产 Secret	Firewall 明确不覆盖 Setup Steps；Secrets 默认对 Setup 可见	审计 Setup Step 的环境变量与网络出口	最小权限 Secret 范围、Setup 步骤幂等且不可变
自托管 Runner 部署后 Firewall 突然失效	自托管 Runner 当前不支持平台 Firewall	检查 Runner 类型是否为 GitHub-hosted	改用 GitHub-hosted Runner，或自建网络层隔离
Code Review 与 Cloud Agent 行为不同步	两者的网络策略已经独立配置	在组织/仓库设置中分别审计 Code Review 与 Cloud Agent Runner	显式区分两个配置面，不要复用同一 Runner 设置
Review 输出与两天前的结果明显不同	Instructions / Setup / Runner / 模型任一层发生漂移	比对控制资产 content_hash、Runner 镜像、模型版本	把 Review 当作带外部依赖的构建任务，保存完整环境指纹
团队以为 AI Review 等于 Approve	Copilot 只输出 Comment Review，不计入 Branch Protection	查看 PR 是否需要人工 Approve 才能合并	单独设置 Branch Protection 的人工审批门槛
Instructions 多份文件相互覆盖	缺少统一优先级表与冲突扫描	在 Setup Workflow 中加入 instruction-conflict-scan	收敛入口文件、为路径级 Instructions 设置目录归属
第三方 Action 自动升级	引用了 Tag 而非 commit SHA	检查 Workflow 中的 `uses: owner/repo@vN`	固定到不可变 commit SHA，并定期刷新到可信版本
升级到 Head Branch Instructions 后 Fork PR 出现异常行为	Head Branch 指令可被 PR 自身修改，信任关系改变	在沙箱仓库上对比 Base/Head Branch 行为	关闭 Fork PR 的工作流写入权限、限制 Secrets 暴露、设置控制文件保护规则