承接 MCP 2026-07-28 無狀態(tài)化遷移清單 · Agent Gateway 治理調(diào)研日期2026-07-31本文目標(biāo)用倉庫內(nèi) Agent Skills 和經(jīng)過允許列表約束的 MCP 工具給 Copilot Code Review 補(bǔ)上項(xiàng)目規(guī)則與外部上下文同時避免把“代碼審查只讀”誤解為完整的權(quán)限邊界。2026-07-29GitHub 宣布 Copilot Code Review 對 Agent Skills 和 MCP Server 的支持進(jìn)入正式可用狀態(tài)面向 Copilot Pro、Pro、Business 與 Enterprise。它解決了 AI 審查常見的兩類盲區(qū)不了解倉庫的特定規(guī)范以及看不到 Issue、文檔、服務(wù)目錄等外部上下文。這并不意味著“接上 MCP 就自動更安全”。官方同時說明代碼審查中執(zhí)行的 MCP 工具調(diào)用被限制為只讀但倉庫級 MCP 配置會同時被 Copilot cloud agent 和 Copilot code review 使用已配置的工具可以被 Agent 自主調(diào)用。審查運(yùn)行時的只讀約束很重要服務(wù)器、Token 和允許工具列表仍然必須各自守住最小權(quán)限。一、先分清產(chǎn)品能力和你的安全責(zé)任維度已核驗(yàn)事實(shí)你的工程決策Agent Skills可在倉庫的 .github/skills 等目錄放置獨(dú)立的 SKILL.md代碼審查可在相關(guān)時使用它哪些規(guī)則是全局指令哪些應(yīng)只在特定改動中加載MCP 上下文Code Review 可使用 MCP 工具獲取外部上下文審查中的調(diào)用是只讀服務(wù)端是否真的只暴露讀工具、Token 是否被限制到最小資源集合配置復(fù)用倉庫 MCP 設(shè)置同時供 cloud agent 和 Code Review 使用是否為 cloud agent 與審查分別設(shè)計(jì)可接受的工具面默認(rèn)工具GitHub MCP 與 Playwright MCP 默認(rèn)啟用是否需要保留、縮小范圍或在審查中禁用可追溯性評論會標(biāo)示它是否用了 skill 或 MCP 上下文如何抽查歸因、錯誤引用與敏感數(shù)據(jù)泄露不要把“代碼審查不可寫”當(dāng)作“整個 MCP Server 不可能造成風(fēng)險”。如果服務(wù)端本身把讀操作做成數(shù)據(jù)導(dǎo)出或者 Token 能跨項(xiàng)目訪問讀權(quán)限一樣會越界。二、先用 Skill 固化審查標(biāo)準(zhǔn)再補(bǔ) MCP 上下文倉庫通用且每個任務(wù)都要遵循的簡短規(guī)則適合放在 Copilot 自定義指令中只有在某類改動出現(xiàn)時才需要的大段步驟、示例或腳本適合做成 Agent Skill。這樣審查器不會被無關(guān)說明淹沒。一個面向 API 契約審查的最小 Skill 目錄可以是.github/ skills/ code-review-api-contracts/ SKILL.mdSKILL.md 需要 YAML frontmatter 中的 name 與 description。下面示例沒有預(yù)批準(zhǔn) shell也不要求 Copilot 運(yùn)行腳本它只把團(tuán)隊(duì)的審閱標(biāo)準(zhǔn)寫清楚--- 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.實(shí)踐上目錄名應(yīng)讓用途一眼可見。GitHub 文檔特別建議為想強(qiáng)制用于代碼審查的規(guī)則使用 review-focused 的命名并指出相關(guān)的 .github/skills 中 Skill 可以被自動采用。三、MCP 接入的正確起點(diǎn)是“允許列表”不是 tools: [*]倉庫管理員在 GitHub 的 Settings → Copilot → MCP servers 中配置服務(wù)器。官方文檔建議允許列表化具體的只讀工具因?yàn)?Copilot 能自主使用已暴露的工具不會逐次彈出確認(rèn)。下面是一個示意配置它只提供查詢運(yùn)行手冊和服務(wù)責(zé)任人的兩個工具。URL、工具名和身份機(jī)制都需要替換為你自己的 MCP Server不要照抄到生產(chǎn)環(huán)境。{ 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} } } } }幾個必須同時滿足的約束服務(wù)端只實(shí)現(xiàn)或只授權(quán)讀取型工具不要只靠客戶端提示詞聲明“請勿寫入”。Token 只授予此 MCP 所需的最小項(xiàng)目、最小字段和只讀 scope。倉庫配置引用的 Agents secret / variable 名稱需要以 COPILOT_MCP_ 開頭。不要使用通配符工具列表。先用兩三個可審計(jì)的工具跑通再根據(jù)真實(shí)審查價值擴(kuò)展。目前 Copilot cloud agent 與 Code Review 只支持 MCP 的 tools不支持服務(wù)端提供的 resources 或 prompts使用遠(yuǎn)程 OAuth 的 MCP Server 也不在當(dāng)前支持范圍內(nèi)。把這類限制寫進(jìn)接入設(shè)計(jì)避免上線后才發(fā)現(xiàn)上下文沒有被加載。四、為什么“審查只讀”仍要分開治理 cloud agent官方公告明確說 Code Review 中的 MCP 調(diào)用是只讀但倉庫級配置會被 cloud agent 和 Code Review 共享。GitHub 文檔也提醒一旦配置 MCP ServerCopilot 可以自主使用該 Server 的工具。因此建議把權(quán)限拆成三層Pull request 觸發(fā) Code Review ├─ Skill只提供與本次 diff 相關(guān)的審查方法 ├─ MCP 客戶端配置只允許明確列出的讀工具 └─ MCP 服務(wù)端 / Token只允許必要的數(shù)據(jù)域和只讀操作 Copilot cloud agent 使用同一配置 └─ 仍需單獨(dú)評估每個工具在 agent 任務(wù)中的風(fēng)險與數(shù)據(jù)范圍最穩(wěn)妥的辦法不是相信某一層“應(yīng)該是只讀”而是讓三層都無法執(zhí)行寫操作。若某個 MCP 對 cloud agent 有寫入價值最好將它與代碼審查用的讀 MCP 分離或至少分離 Token、工具 allowlist 和服務(wù)端策略。五、按這個順序上線才知道它到底幫了什么挑一個低風(fēng)險規(guī)則。例如 API schema、遷移腳本或錯誤碼約定不要一開始把整個架構(gòu)手冊寫進(jìn)一個 Skill。建立一臺只讀 MCP。從服務(wù)目錄、內(nèi)部文檔或錯誤查詢中挑兩項(xiàng)最有助于審查、且不會泄露敏感數(shù)據(jù)的讀取能力。用受控 PR 驗(yàn)證。準(zhǔn)備一個刻意修改 API 字段的測試 PR并請求 Copilot 審查檢查評論是否識別兼容性風(fēng)險、是否標(biāo)示使用了 Skill 或 MCP。查看會話日志。GitHub 文檔說明可從 PR 時間線進(jìn)入 review session確認(rèn)實(shí)際啟動的 MCP Server 與調(diào)用的工具這比只看最終評論更可靠。測試拒絕路徑。嘗試請求未列入 allowlist 的工具、跨項(xiàng)目數(shù)據(jù)或缺失 Secret 的配置確認(rèn)服務(wù)器和權(quán)限都會拒絕。再量化價值。記錄有多少評論被采納、誤報類型、平均審查時長和人工追問次數(shù)效果不好時先縮小 Skill而不是繼續(xù)堆提示詞。六、最容易踩的五個坑1把所有倉庫規(guī)則塞進(jìn)一個 Skill描述越寬泛越可能在不相關(guān)的 PR 中帶來噪聲。將“全局編碼風(fēng)格”與“數(shù)據(jù)庫遷移審查”“公開 API 變更審查”等場景拆開。2使用通配符工具列表通配符工具列表tools: [*]看上去省事卻把未來新增工具也自動暴露給 Agent。允許列表應(yīng)當(dāng)是版本化的安全面而不是一次性的便捷配置。3只依賴 Code Review 的只讀限制代碼審查的運(yùn)行時限制無法替你收窄 MCP Server 的真實(shí)能力、數(shù)據(jù)范圍和 cloud agent 的配置復(fù)用。讀服務(wù)端也要有鑒權(quán)、審計(jì)和速率限制。4把外部文檔當(dāng)成可信指令MCP 返回的文檔、Issue 或日志可能包含錯誤信息甚至提示注入。Skill 應(yīng)要求審查器把外部內(nèi)容視為證據(jù)來源而不是可執(zhí)行指令最終評論要回鏈到代碼、測試或可驗(yàn)證的事實(shí)。5忘記審視默認(rèn)啟用的工具GitHub MCP 和 Playwright MCP 默認(rèn)可用不代表它們一定適合所有倉庫。把默認(rèn)項(xiàng)納入首次權(quán)限評審明確保留、限制還是在代碼審查中關(guān)閉。結(jié)語Agent Skills 讓代碼審查記住團(tuán)隊(duì)真正關(guān)心的標(biāo)準(zhǔn)MCP 讓它在必要時帶著外部上下文來審。兩者組合的價值不在于“讓評論更多”而在于讓評論更可驗(yàn)證、更貼近風(fēng)險。從一個只讀 MCP、一個狹窄的審查 Skill 和一組受控 PR 開始。只有當(dāng)工具列表、Token 范圍、服務(wù)端策略和評論歸因都可審計(jì)時外部上下文才會成為審查質(zhì)量的增益而不是新的權(quán)限盲區(qū)。來源與延伸閱讀Copilot code review: Agent skills and MCP now generally availableGitHub 官方公告發(fā)布于 2026-07-29。Adding agent skills for GitHub CopilotSKILL.md 結(jié)構(gòu)、目錄與代碼審查適用規(guī)則。Configure MCP servers for your repository倉庫 MCP 配置、工具允許列表、驗(yàn)證步驟與當(dāng)前限制。協(xié)議升級深度實(shí)踐MCP無狀態(tài)化遷移清單網(wǎng)關(guān)、任務(wù)與鑒權(quán)將 MCP 的協(xié)議遷移與網(wǎng)關(guān)邊界一起考慮。供應(yīng)鏈防線深度實(shí)踐GitHub Actions 的執(zhí)行前攔截來了Agent CI/CD 還要補(bǔ)哪三道門把身份、權(quán)限、預(yù)算與審計(jì)放回服務(wù)端控制面。