代碼審查原本是 AI 開發(fā)工具里最克制的入口模型看一眼 diff留下幾條評論最后仍由人決定改不改。7 月 29 日GitHub 往前走了一步。Copilot code review 正式接入 agent skills 和 MCP server。它不只看代碼還能讀取團隊寫在倉庫里的規(guī)范或者從工單、文檔和服務目錄里補上下文。這一步看起來像“審查更懂業(yè)務”實質(zhì)上卻在回答一個更麻煩的問題當模型、上下文和工具越來越多誰來決定它能看什么、用什么以及出了問題以后怎么追代碼審查不只看 diff 了GitHub 建議把團隊規(guī)范寫進.github/skills下的SKILL.md。編碼標準、內(nèi)部工具用法、倉庫特有的審查要求都可以成為 Copilot review 的上下文。MCP 則負責把倉庫外的信息接進來比如 issue、項目文檔或服務目錄。Copilot 的審查評論可以標注它使用了哪個 skill 或 MCP 上下文。來源GitHub Changelog這里有兩個邊界值得注意。第一代碼審查里的 MCP 調(diào)用限定為只讀。review bot 可以查資料但不能順手改掉外部系統(tǒng)。第二評論會標注使用過的 skill 或 MCP 上下文。審查者至少知道這條建議從哪里來而不是面對一句無法追溯的“AI 認為應該這樣改”。這比往提示詞里塞一大段規(guī)范可靠。提示詞通常是一次性的也很難確認模型到底讀了什么。把規(guī)范做成倉庫資產(chǎn)再把上下文使用情況留在評論里團隊才有機會復查和維護。模型選擇也被管理員接管同一天GitHub 還公布了 Copilot Business 和 Enterprise 的默認模型啟用策略。以后已經(jīng)正式可用的 Copilot 模型可以跟隨組織或企業(yè)級策略自動開放不必等管理員逐個勾選。新策略先進入 28 天的配置窗口期間可以設置但不會生效計劃從 2026 年 8 月 26 日開始影響模型可用性。GitHub 保留了幾個限制管理員顯式啟用或禁用過的模型不會被覆蓋開源權(quán)重模型以及不在 GitHub 數(shù)據(jù)保留協(xié)議范圍內(nèi)的模型也不會因為默認策略自動開放。這件事的影響不在“少點幾次開關(guān)”。默認開放能減少配置滯后但也可能讓一個尚未通過內(nèi)部評測的新模型更快進入開發(fā)流程。默認關(guān)閉更穩(wěn)卻會把審批和測試壓力集中到平臺團隊。模型選擇已經(jīng)不是開發(fā)者個人偏好而是一項需要記錄和復盤的企業(yè)策略。GitHub 隨后擴展 Copilot app usage metrics把會話、請求、prompt、token 和代碼活動按用戶、功能、模型、語言等維度匯總。管理員終于可以回答一些過去很模糊的問題哪個模型在什么場景被使用代碼審查和 coding agent 的消耗有何差別某個團隊的增長來自真實工作還是試用。速度和地域變成一個參數(shù)Vercel 的 AI Gateway 從另一側(cè)做了相似的事。它把模型服務的速度和地域收進統(tǒng)一參數(shù)不要求業(yè)務代碼綁定某個 provider 的私有配置。fast mode 目前處于 beta。開發(fā)者在providerOptions.gateway中設置speed: fast網(wǎng)關(guān)會在存在快速 serving path 時使用它沒有可用快速路徑就回落到標準速度。同一個speed參數(shù)可以跨模型請求快速服務路徑。來源Vercel Changelog這個抽象省掉了 provider 適配卻沒有消除代價。Vercel 明確提醒fast variant 通常比基礎模型更貴。延遲和 token 成本因此成了同一條路由策略上的兩個旋鈕。區(qū)域推理更接近合規(guī)控制。請求可以把inferenceRegion指定為 US 或 EU如果沒有 provider 能在目標區(qū)域服務請求會失敗不會偷偷改走全球路由。響應還會報告實際服務區(qū)域。inferenceRegion把推理區(qū)域?qū)戇M請求。來源Vercel Changelog不設置時仍然是全球路由沒有數(shù)據(jù)駐留保證。設置區(qū)域后provider 可能收取更高費率Vercel 給出的常見幅度約為 10%并稱不會額外加價轉(zhuǎn)售。平臺收攏控制不替團隊做決定GitHub 和 Vercel 都在把零散配置收進平臺控制層技能放在哪里MCP 能不能寫哪些模型默認開放請求走快速還是標準路徑推理留在哪個區(qū)域最后都能被設置和審計。但控制層不是把選項集中到一個后臺就結(jié)束了。Martin Fowler 站點上 Rahul Garg 對多 agent 工作流的復盤提到一個很實際的問題主 orchestrator 的工作記憶會被無關(guān) transcript、重復探索和中間噪聲污染。他把是否需要共享同一套心智模型稱為 “cognitive locality”。任務拆得過細多個 agent 會重復重建上下文平臺接入再多工具也只是讓噪聲進得更快。所以團隊真正要管的不只是模型名單。哪些規(guī)范值得進入每一次審查哪些 MCP 數(shù)據(jù)可以讀取fast mode 的額外成本是否換來了交付時間區(qū)域限制失敗后能否明確退出這些都需要自己的規(guī)則。AI 編程平臺正在“收權(quán)”但這并不天然是壞事?？刂泣c集中以后邊界更容易被看見也更容易被審計。前提是團隊沒有把默認值當成答案新模型先過內(nèi)部任務外部上下文堅持最小權(quán)限高成本路徑有預算閾值每一次自動決策都留得下記錄也停得下來。