GitHub Copilot Code Review GA：MCP 驱动的安全上下文注入

GitHub 的 Copilot code review 对 Agent skills 和 MCP servers 的支持已于 2026 年 7 月 29 日正式发布。真正有价值的并不是“AI 能审查更多代码”，而是它划定的边界：仓库指令和外部上下文可以影响审查结果，但 Copilot code review 发起的 MCP 调用始终保持只读。GitHub 还会标明哪些评论使用了 skills 或 MCP 上下文。

这就变成了一个实际的控制平面问题：如何在补充项目上下文的同时，避免悄悄把 code review 变成拥有修改权限的 Agent？

一个安全的初始设计包含四层：

• 在仓库中进行版本管理的审查策略。

• 用于获取工单、架构说明或服务目录的只读外部上下文。

• 提供来源标识，让审查者能够看到哪些评论依赖了这些上下文。

• 在修改代码、标签、issue 或部署之前，必须经过人工批准。

模型仍然可能给出错误的评论。只读访问并不能保证评论正确，但它确实可以缩小错误工具调用的影响范围。

把审查策略放在代码旁边

GitHub 规定的格式是：在 .github/skills 下创建特定 skill 的目录，并在其中放置一个 SKILL.md 文件。一开始应使用范围明确、可测试的指令，而不是塞进一整本庞大的工程手册。例如：

.github/skills/api-review/SKILL.md

---
name: api-review
description: "Review changes to public HTTP APIs"
---

When a pull request changes a public endpoint:

- Check backward compatibility for field removal, type changes, and enum narrowing.
- Require an explicit migration note for response-shape changes.
- Check that authorization behavior is covered by a test.
- Treat generated client updates as evidence, not as proof of compatibility.
- If the repository does not contain enough evidence, say what is missing instead of guessing.

这里最重要的词是“证据”。Skill 应该告诉审查者去哪里查找、需要验证什么，而不是强迫审查者得出某个结论。文件应该足够精简，以便像审查生产配置一样审查它。

增加上下文，而不是授予权限

MCP 可以把代码审查连接到 issue 跟踪系统、文档平台或服务目录等系统。应该使用这些连接来回答以下问题：

• 关联的 issue 实际要求实现什么行为？

• 这个 endpoint 是否仍受支持？

• 哪个服务负责变更后的 schema？

• 是否已经批准了弃用日期？

不要把检索到的上下文当作授权决策。工单可能已经过时，文档可能与仓库内容相矛盾，服务目录也可能落后于实际情况。审查应该明确呈现信息来源以及其中的不确定性。

一条有用的审查评论应该是这样的：

这个 PR 修改了 POST /v2/orders，将 currency 设为必填字段。关联的迁移 issue 表明，旧客户端将继续支持到 9 月。我没有找到针对缺少 currency 的请求所编写的兼容性测试；请补充测试，或者说明为什么该 issue 已经不再适用。

这比“这是一个 breaking change，把它回滚掉”安全得多。

把来源标识视为审计信号

GitHub 表示，使用 Agent skills 或 MCP 上下文生成的评论会带有来源标识。在审查分流过程中，可以利用这一信号：

来源标识并不是正确性评分。当某条评论看起来很权威时，它只是告诉你应该检查哪些内容。

一份简短的上线检查清单

在为所有仓库启用这一功能之前，先选择一个低风险项目进行测试：

• 只为一种审查类别添加一个 skill，例如 API 兼容性。

• 只连接一个只读 MCP server。

• 将凭据存储在仓库的 Agents secrets 中，不要写入 SKILL.md 或 workflow。

• 创建包含已知正确、已知错误以及存在歧义变更的 pull request。

• 记录审查者是否找到了预期问题、引用了正确的信息来源，并明确表达了不确定性。

• 检查所有连接的工具，确保它们都无法创建、编辑、合并、添加标签或执行部署。

• 检查每一条依赖上下文的评论所附带的来源标识。

对于一个简单的测试矩阵：

这无法解决什么问题

只读 MCP 限制的是修改操作，而不是幻觉。仓库中的 skills 可能变得过时或相互矛盾。外部上下文会增加延迟，同时引入新的授权面。即使一条评论引用了真实存在的工单，它仍然可能误解具体实现。

因此，应该衡量整个工作流，而不只是评论数量：由维护者确认的有效发现、误报率、信息来源过期的次数、解决一项发现所需的时间，以及审查者需要纠正 Agent 理解的频率。GitHub 的公告只确认了该功能的可用性和行为，并没有对审查准确率进行独立评估。

实际原则很简单：为审查 Agent 提供更多证据，但把最终决定权留在仓库测试和人工审批流程中。

在你的 code review 工作流中，你会首先接入什么：issue 上下文、架构文档，还是服务目录？

GitHub：Copilot code review 对 Agent skills 和 MCP servers 的支持

GitHub Docs：为 Copilot 配置 MCP servers

GitHub Docs：关于 Agent skills

如果要采取进一步措施，你可以考虑屏蔽此人和／或举报滥用行为。