GitHub 已将两项重要的 Copilot 代码审查功能移至通用版本：代理技能和模型上下文协议服务器上下文。 7 月 29 日发布的变更日志条目称，这些功能现在可供 Copilot Pro、Pro+、Business 和 Enterprise 用户使用。

这一变化比新模型的发布要小，但对于试图让人工智能审查在真实存储库中发挥作用的工程团队来说可能更重要。 Copilot 代码审查现在可以通过存储在存储库或组织中的自定义审查指令进行指导，并且它可以通过 MCP 服务器从外部系统提取只读上下文。实际上，这意味着人工智能审核可以由团队的架构规则、安全期望、内部约定、票务数据、文档和服务目录条目来决定，而无需每个团队都构建独立的审核机器人。

Copilot 代码审查发生了什么变化

代理技能是 GitHub 的机制，用于为 Copilot 代码审查提供比通用提示更具体的说明。团队在 .github/skills 下的 SKILL.md 文件中定义这些技能。这些文件可以存在于存储库或组织级别，因此平台团队可以发布共享指南，而各个项目可以添加本地规则。

这很重要，因为代码审查质量通常取决于差异中不明显的上下文。审阅者可能需要知道服务使用特定的重试模式，数据库迁移必须遵循生产操作手册，或者面向客户的 API 必须保持向后兼容性。代理技能为团队提供了第一方 GitHub 路径，以便为 Copilot 的审核行为编码该上下文。

第二部分是 MCP 服务器支持。 Copilot 代码审查可以连接到 MCP 服务器，以从第三方或内部系统检索外部上下文。 GitHub 特别指出了问题跟踪器、文档系统和服务目录等来源。这将代码审查变成了更加互联的代理工作流程：审查可以考虑拉取请求以及周围的产品和操作信息。

GitHub 表示 Copilot 代码审查进行的 MCP 工具调用仅限于只读访问。这个限制是很重要的。可以检查工单或服务文档的审核助理比可以在审核期间改变问题、更新生产元数据或触发工作流程的审核助理更容易管理。

为什么这对工程团队很重要

大多数人工智能代码审查工具都面临着同样的问题：它们可以读取差异，但不能自动理解组织。他们可能会标记表面的风格问题，同时忽略项目特定的风险。或者他们可能会建议违反内部标准的更改，因为这些标准存在于分散的文档、Slack 线程、服务目录和部落知识中。

GitHub 的举动是朝着让 AI 审查基础设施感知迈出的一步。可以通过访问团队的安全期望来审查涉及身份验证路径的拉取请求。可以根据服务所有权和文档检查对服务依赖项的更改。与问题相关的 UI 更改可以根据问题的接受标准进行解释。

对于个人开发者来说，直接的效果可能是更有针对性的审核意见和更少的通用建议。对于工程经理和平台团队来说，更大的价值是标准化。团队无需要求每个审阅者记住每条内部规则，而是可以对审阅上下文的基线进行一次编码并将其应用于各个存储库。

还有维护负担。存储在 Markdown 中的技能比自定义自动化更容易采用，但它们仍然需要所有者。如果指令变得过时，Copilot 可能会继承过时的假设。如果范围太宽泛，评论可能会变得嘈杂。如果它们过于规范，可能会阻碍合法的例外情况。该功能并没有消除审查治理；它为团队提供了一个必须管理治理的新表面。

MCP 从协议故事转向产品表面

此公告与 MCP 规范本身最近的更改不同。 7 月 29 日的 GitHub 更新是关于 Copilot 代码审查中的产品可用性，而不是协议修订。这种区别很重要，因为当协议成为广泛使用的开发人员工作流程的一部分时，企业采用通常会加速。

MCP 主要被讨论为代理工具的管道：AI 系统通过通用接口连接到外部上下文和功能的一种方式。 GitHub 的全面发布表明该协议正在成为日常软件交付界面的一部分，包括拉取请求审查。

这种转变将提高对 MCP 感知基础设施的期望。将审核工作流程连接到内部系统的团队需要考虑身份验证、日志记录、访问范围、工具描述、服务器可靠性和审计跟踪。只读工具调用可以降低风险，但并不能消除了解人工智能系统可以看到哪些数据以及该上下文如何影响建议的需要。

这就是该公告与更广泛的 AI API 网关市场的联系。随着代理工作流程在模型提供者、IDE、代码主机和内部数据系统之间分散，团队需要更清晰地控制使用哪些模型和工具、哪些密钥可以访问以及如何归因使用情况。当组织需要跨多个 AI 服务进行集中式 API 密钥管理、AI 使用分析、模型路由、计费可见性和团队 API 治理时，Model Gate 等平台就非常有用。 GitHub 的发布强化了同样的操作模式：AI 功能不再是孤立的聊天框；它们是连接的工作流组件。

实际后果和悬而未决的问题

对于 GitHub 客户来说，实际的下一步是决定代理技能应该存在于何处以及由谁来维护它们。存储库级技能可能适用于专门的系统。组织级技能更适合共享规则，例如安全编码实践、日志记录约定、可访问性标准或依赖策略。

考虑 MCP 连接的团队应从低风险上下文源开始。文档和服务目录自然是首选。问题跟踪器可能很有用，但它们可能包含敏感的客户或事件信息，因此在将它们连接到代码审查之前应审查访问边界。只读限制有所帮助，但可见性仍然是一种访问形式。

还有一些未解决的细节，团队需要在自己的环境中进行测试。 GitHub 的变更日志确认了代理技能和 MCP 上下文的普遍可用性，但现实世界的审核质量将取决于技能的编写程度、连接的 MCP 服务器以及 Copilot 如何优先考虑竞争的上下文片段。从公告中还不清楚团队将如何衡量这些审查是否减少了缺陷、加快了审查周期，或者只是将审查工作转移到了维护指令上。

然而，方向是明确的。人工智能代码审查正在变得可配置、情境化并与企业系统连接。这使得它更有用，但在操作上也更严肃。受益最多的团队将是那些将代理上下文视为其工程平台的一部分而不是一次性提示的团队。