承接 MCP 2026-07-28 无状态化迁移清单 · Agent Gateway 治理调研日期2026-07-31本文目标用仓库内 Agent Skills 和经过允许列表约束的 MCP 工具给 Copilot Code Review 补上项目规则与外部上下文同时避免把“代码审查只读”误解为完整的权限边界。2026-07-29GitHub 宣布 Copilot Code Review 对 Agent Skills 和 MCP Server 的支持进入正式可用状态面向 Copilot Pro、Pro、Business 与 Enterprise。它解决了 AI 审查常见的两类盲区不了解仓库的特定规范以及看不到 Issue、文档、服务目录等外部上下文。这并不意味着“接上 MCP 就自动更安全”。官方同时说明代码审查中执行的 MCP 工具调用被限制为只读但仓库级 MCP 配置会同时被 Copilot cloud agent 和 Copilot code review 使用已配置的工具可以被 Agent 自主调用。审查运行时的只读约束很重要服务器、Token 和允许工具列表仍然必须各自守住最小权限。一、先分清产品能力和你的安全责任维度已核验事实你的工程决策Agent Skills可在仓库的 .github/skills 等目录放置独立的 SKILL.md代码审查可在相关时使用它哪些规则是全局指令哪些应只在特定改动中加载MCP 上下文Code Review 可使用 MCP 工具获取外部上下文审查中的调用是只读服务端是否真的只暴露读工具、Token 是否被限制到最小资源集合配置复用仓库 MCP 设置同时供 cloud agent 和 Code Review 使用是否为 cloud agent 与审查分别设计可接受的工具面默认工具GitHub MCP 与 Playwright MCP 默认启用是否需要保留、缩小范围或在审查中禁用可追溯性评论会标示它是否用了 skill 或 MCP 上下文如何抽查归因、错误引用与敏感数据泄露不要把“代码审查不可写”当作“整个 MCP Server 不可能造成风险”。如果服务端本身把读操作做成数据导出或者 Token 能跨项目访问读权限一样会越界。二、先用 Skill 固化审查标准再补 MCP 上下文仓库通用且每个任务都要遵循的简短规则适合放在 Copilot 自定义指令中只有在某类改动出现时才需要的大段步骤、示例或脚本适合做成 Agent Skill。这样审查器不会被无关说明淹没。一个面向 API 契约审查的最小 Skill 目录可以是.github/ skills/ code-review-api-contracts/ SKILL.mdSKILL.md 需要 YAML frontmatter 中的 name 与 description。下面示例没有预批准 shell也不要求 Copilot 运行脚本它只把团队的审阅标准写清楚--- name: code-review-api-contracts description: Review pull requests that change HTTP APIs, event payloads, or public schemas. Use this during code review when contract files or handlers change. --- # API contract review 1. Identify whether request, response, error, or event schemas changed. 2. Require an explicit compatibility note for any removed or renamed field. 3. Check that validation happens before side effects. 4. Ask for tests covering one normal request and one invalid request. 5. Do not infer production behavior from comments alone; cite the changed code or tests.实践上目录名应让用途一眼可见。GitHub 文档特别建议为想强制用于代码审查的规则使用 review-focused 的命名并指出相关的 .github/skills 中 Skill 可以被自动采用。三、MCP 接入的正确起点是“允许列表”不是 tools: [*]仓库管理员在 GitHub 的 Settings → Copilot → MCP servers 中配置服务器。官方文档建议允许列表化具体的只读工具因为 Copilot 能自主使用已暴露的工具不会逐次弹出确认。下面是一个示意配置它只提供查询运行手册和服务责任人的两个工具。URL、工具名和身份机制都需要替换为你自己的 MCP Server不要照抄到生产环境。{ mcpServers: { review-context: { type: http, url: https://mcp.example.internal/code-review, tools: [ search_runbook, get_service_owner ], headers: { Authorization: Bearer ${COPILOT_MCP_REVIEW_CONTEXT_TOKEN} } } } }几个必须同时满足的约束服务端只实现或只授权读取型工具不要只靠客户端提示词声明“请勿写入”。Token 只授予此 MCP 所需的最小项目、最小字段和只读 scope。仓库配置引用的 Agents secret / variable 名称需要以 COPILOT_MCP_ 开头。不要使用通配符工具列表。先用两三个可审计的工具跑通再根据真实审查价值扩展。目前 Copilot cloud agent 与 Code Review 只支持 MCP 的 tools不支持服务端提供的 resources 或 prompts使用远程 OAuth 的 MCP Server 也不在当前支持范围内。把这类限制写进接入设计避免上线后才发现上下文没有被加载。四、为什么“审查只读”仍要分开治理 cloud agent官方公告明确说 Code Review 中的 MCP 调用是只读但仓库级配置会被 cloud agent 和 Code Review 共享。GitHub 文档也提醒一旦配置 MCP ServerCopilot 可以自主使用该 Server 的工具。因此建议把权限拆成三层Pull request 触发 Code Review ├─ Skill只提供与本次 diff 相关的审查方法 ├─ MCP 客户端配置只允许明确列出的读工具 └─ MCP 服务端 / Token只允许必要的数据域和只读操作 Copilot cloud agent 使用同一配置 └─ 仍需单独评估每个工具在 agent 任务中的风险与数据范围最稳妥的办法不是相信某一层“应该是只读”而是让三层都无法执行写操作。若某个 MCP 对 cloud agent 有写入价值最好将它与代码审查用的读 MCP 分离或至少分离 Token、工具 allowlist 和服务端策略。五、按这个顺序上线才知道它到底帮了什么挑一个低风险规则。例如 API schema、迁移脚本或错误码约定不要一开始把整个架构手册写进一个 Skill。建立一台只读 MCP。从服务目录、内部文档或错误查询中挑两项最有助于审查、且不会泄露敏感数据的读取能力。用受控 PR 验证。准备一个刻意修改 API 字段的测试 PR并请求 Copilot 审查检查评论是否识别兼容性风险、是否标示使用了 Skill 或 MCP。查看会话日志。GitHub 文档说明可从 PR 时间线进入 review session确认实际启动的 MCP Server 与调用的工具这比只看最终评论更可靠。测试拒绝路径。尝试请求未列入 allowlist 的工具、跨项目数据或缺失 Secret 的配置确认服务器和权限都会拒绝。再量化价值。记录有多少评论被采纳、误报类型、平均审查时长和人工追问次数效果不好时先缩小 Skill而不是继续堆提示词。六、最容易踩的五个坑1把所有仓库规则塞进一个 Skill描述越宽泛越可能在不相关的 PR 中带来噪声。将“全局编码风格”与“数据库迁移审查”“公开 API 变更审查”等场景拆开。2使用通配符工具列表通配符工具列表tools: [*]看上去省事却把未来新增工具也自动暴露给 Agent。允许列表应当是版本化的安全面而不是一次性的便捷配置。3只依赖 Code Review 的只读限制代码审查的运行时限制无法替你收窄 MCP Server 的真实能力、数据范围和 cloud agent 的配置复用。读服务端也要有鉴权、审计和速率限制。4把外部文档当成可信指令MCP 返回的文档、Issue 或日志可能包含错误信息甚至提示注入。Skill 应要求审查器把外部内容视为证据来源而不是可执行指令最终评论要回链到代码、测试或可验证的事实。5忘记审视默认启用的工具GitHub MCP 和 Playwright MCP 默认可用不代表它们一定适合所有仓库。把默认项纳入首次权限评审明确保留、限制还是在代码审查中关闭。结语Agent Skills 让代码审查记住团队真正关心的标准MCP 让它在必要时带着外部上下文来审。两者组合的价值不在于“让评论更多”而在于让评论更可验证、更贴近风险。从一个只读 MCP、一个狭窄的审查 Skill 和一组受控 PR 开始。只有当工具列表、Token 范围、服务端策略和评论归因都可审计时外部上下文才会成为审查质量的增益而不是新的权限盲区。来源与延伸阅读Copilot code review: Agent skills and MCP now generally availableGitHub 官方公告发布于 2026-07-29。Adding agent skills for GitHub CopilotSKILL.md 结构、目录与代码审查适用规则。Configure MCP servers for your repository仓库 MCP 配置、工具允许列表、验证步骤与当前限制。协议升级深度实践MCP无状态化迁移清单网关、任务与鉴权将 MCP 的协议迁移与网关边界一起考虑。供应链防线深度实践GitHub Actions 的执行前拦截来了Agent CI/CD 还要补哪三道门把身份、权限、预算与审计放回服务端控制面。
承接 MCP 2026-07-28 无状态化迁移清单 · Agent Gateway 治理调研日期2026-07-31本文目标用仓库内 Agent Skills 和经过允许列表约束的 MCP 工具给 Copilot Code Review 补上项目规则与外部上下文同时避免把“代码审查只读”误解为完整的权限边界。2026-07-29GitHub 宣布 Copilot Code Review 对 Agent Skills 和 MCP Server 的支持进入正式可用状态面向 Copilot Pro、Pro、Business 与 Enterprise。它解决了 AI 审查常见的两类盲区不了解仓库的特定规范以及看不到 Issue、文档、服务目录等外部上下文。这并不意味着“接上 MCP 就自动更安全”。官方同时说明代码审查中执行的 MCP 工具调用被限制为只读但仓库级 MCP 配置会同时被 Copilot cloud agent 和 Copilot code review 使用已配置的工具可以被 Agent 自主调用。审查运行时的只读约束很重要服务器、Token 和允许工具列表仍然必须各自守住最小权限。一、先分清产品能力和你的安全责任维度已核验事实你的工程决策Agent Skills可在仓库的 .github/skills 等目录放置独立的 SKILL.md代码审查可在相关时使用它哪些规则是全局指令哪些应只在特定改动中加载MCP 上下文Code Review 可使用 MCP 工具获取外部上下文审查中的调用是只读服务端是否真的只暴露读工具、Token 是否被限制到最小资源集合配置复用仓库 MCP 设置同时供 cloud agent 和 Code Review 使用是否为 cloud agent 与审查分别设计可接受的工具面默认工具GitHub MCP 与 Playwright MCP 默认启用是否需要保留、缩小范围或在审查中禁用可追溯性评论会标示它是否用了 skill 或 MCP 上下文如何抽查归因、错误引用与敏感数据泄露不要把“代码审查不可写”当作“整个 MCP Server 不可能造成风险”。如果服务端本身把读操作做成数据导出或者 Token 能跨项目访问读权限一样会越界。二、先用 Skill 固化审查标准再补 MCP 上下文仓库通用且每个任务都要遵循的简短规则适合放在 Copilot 自定义指令中只有在某类改动出现时才需要的大段步骤、示例或脚本适合做成 Agent Skill。这样审查器不会被无关说明淹没。一个面向 API 契约审查的最小 Skill 目录可以是.github/ skills/ code-review-api-contracts/ SKILL.mdSKILL.md 需要 YAML frontmatter 中的 name 与 description。下面示例没有预批准 shell也不要求 Copilot 运行脚本它只把团队的审阅标准写清楚--- name: code-review-api-contracts description: Review pull requests that change HTTP APIs, event payloads, or public schemas. Use this during code review when contract files or handlers change. --- # API contract review 1. Identify whether request, response, error, or event schemas changed. 2. Require an explicit compatibility note for any removed or renamed field. 3. Check that validation happens before side effects. 4. Ask for tests covering one normal request and one invalid request. 5. Do not infer production behavior from comments alone; cite the changed code or tests.实践上目录名应让用途一眼可见。GitHub 文档特别建议为想强制用于代码审查的规则使用 review-focused 的命名并指出相关的 .github/skills 中 Skill 可以被自动采用。三、MCP 接入的正确起点是“允许列表”不是 tools: [*]仓库管理员在 GitHub 的 Settings → Copilot → MCP servers 中配置服务器。官方文档建议允许列表化具体的只读工具因为 Copilot 能自主使用已暴露的工具不会逐次弹出确认。下面是一个示意配置它只提供查询运行手册和服务责任人的两个工具。URL、工具名和身份机制都需要替换为你自己的 MCP Server不要照抄到生产环境。{ mcpServers: { review-context: { type: http, url: https://mcp.example.internal/code-review, tools: [ search_runbook, get_service_owner ], headers: { Authorization: Bearer ${COPILOT_MCP_REVIEW_CONTEXT_TOKEN} } } } }几个必须同时满足的约束服务端只实现或只授权读取型工具不要只靠客户端提示词声明“请勿写入”。Token 只授予此 MCP 所需的最小项目、最小字段和只读 scope。仓库配置引用的 Agents secret / variable 名称需要以 COPILOT_MCP_ 开头。不要使用通配符工具列表。先用两三个可审计的工具跑通再根据真实审查价值扩展。目前 Copilot cloud agent 与 Code Review 只支持 MCP 的 tools不支持服务端提供的 resources 或 prompts使用远程 OAuth 的 MCP Server 也不在当前支持范围内。把这类限制写进接入设计避免上线后才发现上下文没有被加载。四、为什么“审查只读”仍要分开治理 cloud agent官方公告明确说 Code Review 中的 MCP 调用是只读但仓库级配置会被 cloud agent 和 Code Review 共享。GitHub 文档也提醒一旦配置 MCP ServerCopilot 可以自主使用该 Server 的工具。因此建议把权限拆成三层Pull request 触发 Code Review ├─ Skill只提供与本次 diff 相关的审查方法 ├─ MCP 客户端配置只允许明确列出的读工具 └─ MCP 服务端 / Token只允许必要的数据域和只读操作 Copilot cloud agent 使用同一配置 └─ 仍需单独评估每个工具在 agent 任务中的风险与数据范围最稳妥的办法不是相信某一层“应该是只读”而是让三层都无法执行写操作。若某个 MCP 对 cloud agent 有写入价值最好将它与代码审查用的读 MCP 分离或至少分离 Token、工具 allowlist 和服务端策略。五、按这个顺序上线才知道它到底帮了什么挑一个低风险规则。例如 API schema、迁移脚本或错误码约定不要一开始把整个架构手册写进一个 Skill。建立一台只读 MCP。从服务目录、内部文档或错误查询中挑两项最有助于审查、且不会泄露敏感数据的读取能力。用受控 PR 验证。准备一个刻意修改 API 字段的测试 PR并请求 Copilot 审查检查评论是否识别兼容性风险、是否标示使用了 Skill 或 MCP。查看会话日志。GitHub 文档说明可从 PR 时间线进入 review session确认实际启动的 MCP Server 与调用的工具这比只看最终评论更可靠。测试拒绝路径。尝试请求未列入 allowlist 的工具、跨项目数据或缺失 Secret 的配置确认服务器和权限都会拒绝。再量化价值。记录有多少评论被采纳、误报类型、平均审查时长和人工追问次数效果不好时先缩小 Skill而不是继续堆提示词。六、最容易踩的五个坑1把所有仓库规则塞进一个 Skill描述越宽泛越可能在不相关的 PR 中带来噪声。将“全局编码风格”与“数据库迁移审查”“公开 API 变更审查”等场景拆开。2使用通配符工具列表通配符工具列表tools: [*]看上去省事却把未来新增工具也自动暴露给 Agent。允许列表应当是版本化的安全面而不是一次性的便捷配置。3只依赖 Code Review 的只读限制代码审查的运行时限制无法替你收窄 MCP Server 的真实能力、数据范围和 cloud agent 的配置复用。读服务端也要有鉴权、审计和速率限制。4把外部文档当成可信指令MCP 返回的文档、Issue 或日志可能包含错误信息甚至提示注入。Skill 应要求审查器把外部内容视为证据来源而不是可执行指令最终评论要回链到代码、测试或可验证的事实。5忘记审视默认启用的工具GitHub MCP 和 Playwright MCP 默认可用不代表它们一定适合所有仓库。把默认项纳入首次权限评审明确保留、限制还是在代码审查中关闭。结语Agent Skills 让代码审查记住团队真正关心的标准MCP 让它在必要时带着外部上下文来审。两者组合的价值不在于“让评论更多”而在于让评论更可验证、更贴近风险。从一个只读 MCP、一个狭窄的审查 Skill 和一组受控 PR 开始。只有当工具列表、Token 范围、服务端策略和评论归因都可审计时外部上下文才会成为审查质量的增益而不是新的权限盲区。来源与延伸阅读Copilot code review: Agent skills and MCP now generally availableGitHub 官方公告发布于 2026-07-29。Adding agent skills for GitHub CopilotSKILL.md 结构、目录与代码审查适用规则。Configure MCP servers for your repository仓库 MCP 配置、工具允许列表、验证步骤与当前限制。协议升级深度实践MCP无状态化迁移清单网关、任务与鉴权将 MCP 的协议迁移与网关边界一起考虑。供应链防线深度实践GitHub Actions 的执行前拦截来了Agent CI/CD 还要补哪三道门把身份、权限、预算与审计放回服务端控制面。
