GitHub在2026年7月17日更新Copilot code review：它现在会从Pull Request的head分支读取AGENTS.md、copilot-instructions.md等自定义规则文件，并新增对REVIEW.md、GEMINI.md和CLAUDE.md的支持。对于同时使用Codex和Copilot的团队，这意味着一部分仓库规范终于可以沉淀成共享的AI协作规则。本文给出一份可直接修改的AGENTS.md模板，并说明分支验证、规则冲突和安全边界。

同一个仓库里，如果有人使用Codex改代码，有人使用GitHub Copilot审查Pull Request，最容易出现的问题不是模型能力不足，而是两个工具拿到的规则不同。

你在对话里告诉Codex：

• 不要顺手重构无关文件；
• 修改后必须运行单元测试；
• 数据库变更必须附带回滚方案；
• Review时优先检查权限、并发和兼容性。

换到Copilot code review时，这些要求又要重新解释一遍。时间一长，团队规则散落在提示词、README、聊天记录和个人经验里，AI给出的修改与审查自然很难一致。

GitHub在2026年7月17日发布了一项更新：Copilot code review现在会读取更多仓库级规则文件，其中包括AGENTS.md。

这项变化的价值，不是“又多支持了一个Markdown文件”，而是团队可以开始把一部分AI协作规则放回代码仓库，与代码一起评审和演进。

本文依据GitHub和OpenAI官方资料整理，未把官方公告之外的行为包装成实测结论。不同套餐、组织策略和功能灰度可能影响实际可用范围，请以仓库中的实际界面为准。

这次更新具体改变了什么

根据GitHub官方公告，Copilot code review此次有四项值得注意的变化。

1. 从PR的head分支读取规则

Copilot code review现在从Pull Request的head分支读取自定义指令，而不是只从base分支读取。

官方列出的范围包括：

• copilot-instructions.md
• *.instructions.md
• agent skills
• AGENTS.md

这意味着可以在功能分支中修改规则，发起PR后观察代码审查结果，再决定是否把规则合并进主分支。

以前如果规则只能从base分支生效，就容易出现一个尴尬过程：为了验证新规则，先要把规则本身合并。现在可以把“修改规则”和“验证规则”放在同一个PR周期中完成。

2. 增加对更多规则文件的支持

Copilot code review还会读取：

• REVIEW.md
• GEMINI.md
• CLAUDE.md

已经维护这些文件的团队，不必为了Copilot完整复制一套规则。

不过，“能够读取”不代表不同AI工具一定会产生完全相同的结果。模型、上下文选择和审查能力不同，同一条规则仍可能得到不同的执行结果。

3. 可以配置独立的准备步骤

仓库可以在.github/workflows/copilot-code-review.yml中配置Copilot code review运行时需要的环境，例如安装依赖、准备工具或选择runner。

如果不存在这个文件，GitHub说明它会回退到已有的copilot-setup-steps.yml。

4. 代码审查默认启用防火墙

GitHub同时宣布，Copilot code review现在默认在防火墙后运行，并允许仓库或组织单独配置网络访问。

需要注意：官方明确说明，自托管runner目前不支持这项防火墙能力。使用自托管runner的审查任务会继续运行，但不能据此认为它获得了同样的网络隔离。

为什么这对Codex用户也有意义

OpenAI官方把AGENTS.md描述为面向编程智能体的开放格式说明文件。

Codex会自动把适用范围内的AGENTS.md加载进上下文，用它了解仓库结构、构建测试命令、工程规范、禁止事项和完成标准。

现在Copilot code review也开始读取这个文件，团队就有机会建立一个最小共享层：

• Codex修改代码时知道哪些边界不能越过；
• Copilot审查代码时知道团队真正关心哪些风险；
• 人类评审者可以直接在PR里查看规则是否发生变化；
• 新成员不必从零猜测团队对AI的使用方式。

但这里必须划清边界：

AGENTS.md可以共享规则，不会让Codex和Copilot变成同一个工具，也不能保证两者输出完全一致。

最适合共享的是具体、可验证、与仓库直接相关的规则；不适合共享的是“写得更专业”“尽量完善”“使用最佳实践”这类无法验收的空泛要求。

一份AGENTS.md应该写清哪五类信息

---

第一类：项目范围

告诉智能体主要代码在哪里，哪些目录是生成文件、第三方代码或历史模块，不应随意修改。

第二类：构建与测试命令

不要只写“修改后运行测试”，而要给出仓库里确实可用的命令。

第三类：修改边界

明确禁止顺手重构、扩大依赖、改变公共接口或覆盖人工修改等行为。

第四类：审查重点

把团队真正关心的问题写出来，例如鉴权、输入校验、并发、事务、兼容性和敏感信息泄漏。

第五类：完成标准

定义什么叫“完成”：代码通过哪些检查、是否需要补测试、是否必须更新文档、哪些风险必须写进PR说明。

可直接修改的AGENTS.md模板

下面是一份通用模板。示例命令只是结构演示，必须替换成仓库中真实存在的命令，不能直接照搬运行。

# AGENTS.md

## Repository scope

- Application code lives in `src/`.
- Tests live in `tests/` and should mirror the source structure.
- Do not manually edit generated files under `dist/` or `generated/`.
- Avoid changes to `legacy/` unless the task explicitly includes it.

## Setup and validation

- Install dependencies: `npm ci`
- Run lint: `npm run lint`
- Run unit tests: `npm test`
- Run type checks: `npm run typecheck`
- For a focused change, run the narrowest relevant test first, then the full required suite.

## Change boundaries

- Make the smallest change that satisfies the task.
- Do not refactor unrelated modules.
- Do not change public APIs without calling out the compatibility impact.
- Do not add a new dependency when the existing stack can solve the problem.
- Preserve user-authored changes that are outside the current task.

## Review priorities

When reviewing a pull request, prioritize:

1. Authentication and authorization regressions.
2. Missing input validation or unsafe deserialization.
3. Data loss, transaction and concurrency risks.
4. Backward compatibility of public interfaces.
5. Missing tests for changed behavior.

Do not report formatting preferences already enforced by automated tools.
Do not invent a defect without pointing to the relevant code path and failure condition.

## Definition of done

- Relevant tests pass.
- New behavior has regression coverage when practical.
- User-visible or API behavior changes are documented.
- Remaining uncertainty and unverified assumptions are listed in the final summary.
- Security-sensitive changes require human approval before merge.

这份模板最值得保留的不是具体命令，而是结构：范围、验证、边界、审查重点和完成标准。

如何在一个PR里验证新规则

GitHub改为从head分支读取规则后，可以采用下面的验证流程。

第一步：在功能分支修改AGENTS.md

只加入一两条能够观察结果的规则，例如：

## Review priorities

- Every database schema change must include a rollback note.
- Ignore formatting issues already covered by the formatter.

不要一次加入几十条规则，否则很难判断究竟是哪一条产生了效果。

第二步：让PR包含一个可验证场景

例如PR修改数据库结构，但先不写回滚说明。随后请求Copilot code review，观察它是否指出该问题。

这里的目的不是故意提交问题代码，而是在隔离分支中验证规则能否影响审查行为。

第三步：检查规则是否过宽

如果AI开始对所有文件都要求数据库回滚说明，说明规则的适用范围没有写清。

可以改成：

- For files under `migrations/`, require a rollback note in the pull request description.

把“原则”改成“文件范围＋触发条件＋预期动作”，通常比继续堆解释更有效。

第四步：规则与代码一起接受人工评审

由于Copilot code review读取的是PR head分支，PR作者也可能修改影响审查行为的规则文件。

因此，对于外部贡献、自动化账号或安全敏感仓库，人工评审时应把AGENTS.md、REVIEW.md和其他指令文件的变化单独列为检查项。

这是基于新读取机制给出的工程安全建议，并非GitHub公告声称已经发生了某类攻击。

不建议写进AGENTS.md的内容

1. 密钥和环境凭证

不要把API Key、Token、Cookie、数据库密码或内网地址写进规则文件。

AGENTS.md会进入智能体上下文，也会跟随仓库版本历史长期保存。

2. 无法验证的空话

例如：

- 请写出最优雅的代码。
- 尽量保证没有Bug。
- 使用最先进的架构。

这些要求缺少可判断条件，既无法稳定执行，也无法在Review中验收。

3. 绕过安全和测试的指令

不要为了让AI“更快完成”而写入跳过测试、忽略权限检查或自动批准合并等要求。

4. 一次性任务背景

只对当前PR有效的需求、临时日期和一次性决策，应该放在Issue、PR描述或当前提示词中，而不是永久留在仓库规则里。

AGENTS.md、REVIEW.md和工具专用文件怎么分工

文件	建议存放内容
AGENTS.md	多个编程智能体都需要的仓库结构、命令、修改边界和完成标准
REVIEW.md	代码评审清单、风险等级和PR反馈规范
CLAUDE.md、GEMINI.md	只有对应工具才需要的特殊说明
copilot-instructions.md	Copilot专用行为或与GitHub工作流紧密相关的要求
copilot-code-review.yml	Copilot code review运行环境、依赖准备和runner配置

GitHub已经确认Copilot code review能够读取这些文件，但官方公告没有说明它对嵌套AGENTS.md的优先级是否与Codex完全一致。

Codex支持仓库级和子目录级AGENTS.md，更靠近当前目录的规则会覆盖更上层的规则；不要未经验证就假设Copilot code review也采用完全相同的层级解析方式。

发布前检查清单

在把AGENTS.md合并进主分支前，至少检查以下内容：

• 命令在当前仓库真实存在，不是从模板照抄；
• 修改边界能够通过文件范围或行为判断；
• 没有密钥、Token、Cookie和客户数据；
• 没有要求智能体绕过测试或安全检查；
• Review规则不会重复格式化工具已经处理的问题；
• 新规则已在独立分支中用可验证场景测试；
• 指令文件本身已经经过人工评审；
• 工具差异和仍未验证的行为已经明确标注。

写在最后

GitHub这次更新给出的信号很明确：AI编程正在从“每次聊天重新写提示词”，转向“把团队规则放进仓库并随代码演进”。

AGENTS.md不再只是某一个智能体的使用说明。对于同时使用Codex和Copilot code review的团队，它可以成为一层共享的工程上下文。

但共享文件不等于共享能力，更不等于自动获得可靠审查。

真正决定效果的，仍然是规则是否具体、命令是否可执行、结果是否能验证，以及人类是否保留最终合并权。

参考资料：GitHub官方更新、OpenAI Codex文档、OpenAI使用Codex说明。