Copilot 代码审查接入 Agent Skills 与只读 MCP：团队规则如何进入 PR

GitHub 在 2026 年 7 月 29 日宣布，Copilot 代码审查对 Agent Skills 和 MCP 服务器的支持已从 public preview 进入正式可用，覆盖 Copilot Pro、Pro+、Business 与 Enterprise 用户。GitHub 更新日志确认的变化，不是 Copilot 突然“更会审代码”，而是团队可以把任务型规则和外部系统上下文接入 PR 审查。

GA 的是两类上下文接入，不是所有相关能力

本次 GA 的精确范围是 Copilot code review 对 Agent Skills 与 MCP server connections 的支持。GitHub 的代码审查概念文档仍把“把建议交给 Copilot cloud agent，让它另开 PR 修复”等关联能力标为 public preview；因此不能把这次公告扩大成整套 Agent 审查与修复链路都已正式可用。GitHub Code Review 文档也明确提醒，Copilot 不能保证找出 PR 中的所有问题，输出仍可能出错。

这一区分对团队采购和流程设计很重要：现在可以稳定评估“规则和上下文怎样进入审查”，但不应据此取消测试、人工批准或分支保护。

Skill 放任务型审查方法，MCP 取动态外部事实

Agent Skill 适合承载按需执行、可复用的审查流程。项目 Skill 位于 .github/skills/<skill-name>/SKILL.md，还可以引用补充文档、脚本与资源；GitHub 建议使用 code-review 这类面向审查的目录名，让 Copilot 更容易识别用途。Agent Skills 官方文档同时说明，Skills 是“任务相关时加载”，不是每次审查都会无条件执行。

团队可以把安全清单、API 兼容性检查、迁移注意事项、组件规范或发布前验证步骤放进 Skill。长期、始终生效的仓库规则则更适合放在 .github/copilot-instructions.md、路径级 instructions 或根目录 AGENTS.md。Copilot 审查 PR 时会从 head branch 读取这些 instructions 与 Skills，这意味着规则变更可以在同一个 PR 中被验证，但也意味着 reviewer 必须把规则文件本身当作变更面审查。GitHub 使用说明记录了这一分支读取方式。

MCP 处理的是另一类问题：从问题跟踪、文档系统、服务目录和事故工具中拉取当前上下文。仓库 MCP 配置由 Copilot cloud agent 与 code review 共用；PR 描述若包含 issue key、incident ID 等明确标识，Copilot 更容易找到相关上下文。换句话说，Skill 更像“按什么方法查”，MCP 更像“到哪里读当前事实”。

“只读 MCP”限制调用动作，不等于整套系统天然安全

GitHub 公告写明，Copilot code review 发起的 MCP tool calls 全部限制为只读。这能降低审查过程改写工单、文档或外部系统状态的风险，但“只读”描述的是代码审查这条调用路径，并不能推出 MCP 服务器、认证令牌或同一仓库中的其他 Agent 运行环境都只有只读权限。

MCP 仓库配置文档指出，配置完成后 Copilot 会自主调用已启用工具，不会逐次请求批准；官方因此建议只 allowlist 明确的只读工具，而不是默认开放全部工具。文档还说明当前这条链路只支持 MCP tools，不支持服务器提供的 resources 或 prompts，使用远程 OAuth 的 MCP server 也暂不受支持。

实际落地时，仓库管理员仍应采用最小权限令牌、明确工具白名单，并确认共享给 cloud agent 的同一套 MCP 配置是否符合更广的执行场景。只读调用是重要防线，不是权限设计的替代品。

评论归因能回答“用了什么”，不能证明“结论正确”

这次 GA 新增的可见变化是评论归因：当审查意见使用了 Agent Skill 或 MCP 上下文，评论会标注相关 Skill 或 MCP server。GitHub 使用说明还提供了更深一层的检查入口——从 PR 时间线打开关联 review session，在日志中核对调用过的 MCP server 与工具。

归因提升的是可追踪性：团队可以知道某条意见参考了哪个审查流程或外部上下文，也更容易排查“为什么没有用到预期规则”。它不能证明 Skill 被完整执行、外部数据没有过期、模型推理正确，或所有风险都已覆盖。Copilot 留下的是 Comment review，不是 Approve 或 Request changes，也不会计入 required approvals 或阻止合并；这些产品边界同样由代码审查操作文档明确说明。

Agent 生成后的交接，应把规则、证据与责任拆开

对已经使用编码 Agent 的团队，这次更新最有价值的不是增加一个自动 reviewer，而是把验证资产分层：

• 把稳定的仓库约定、路径规则和架构边界放在 always-on instructions 或 AGENTS.md。
• 把安全审查、迁移检查、API 兼容性和发布验证等任务型方法放进 review-focused Skill，并让描述清楚说明触发条件。
• 把工单、事故、服务目录和外部文档等持续变化的信息通过最小权限、只读工具接入 MCP，并在 PR 描述中提供可检索标识。
• 把评论归因与 session 日志当作“上下文使用记录”，而不是质量合格证；测试结果、代码所有者批准、安全扫描和合并门禁仍由团队负责。

本站判断是，Skills 与 MCP 让 Agent 生成后的审查更接近真实项目语境，也让交接证据更容易追踪；但当前官方材料没有提供独立准确率、漏报率或不同仓库类型的效果数据。团队更稳妥的做法，是先选择一类高频 PR 做受控试点，比较接入前后的有效评论率、误报、审查耗时和人工发现的问题，再决定是否扩大自动审查范围。