AI 编程控制面：模型、MCP、地域和审计怎么一起管
代码审查原本是 AI 开发工具里最克制的入口：模型看一眼 diff，留下几条评论，最后仍由人决定改不改。
7 月 29 日，GitHub 往前走了一步。Copilot code review 正式接入 agent skills 和 MCP server。它不只看代码，还能读取团队写在仓库里的规范，或者从工单、文档和服务目录里补上下文。
这一步看起来像“审查更懂业务”，实质上却在回答一个更麻烦的问题：当模型、上下文和工具越来越多，谁来决定它能看什么、用什么，以及出了问题以后怎么追？
代码审查不只看 diff 了
GitHub 建议把团队规范写进.github/skills下的SKILL.md。编码标准、内部工具用法、仓库特有的审查要求，都可以成为 Copilot review 的上下文。MCP 则负责把仓库外的信息接进来，比如 issue、项目文档或服务目录。
Copilot 的审查评论可以标注它使用了哪个 skill 或 MCP 上下文。来源：GitHub Changelog
这里有两个边界值得注意。
第一，代码审查里的 MCP 调用限定为只读。review bot 可以查资料，但不能顺手改掉外部系统。第二，评论会标注使用过的 skill 或 MCP 上下文。审查者至少知道这条建议从哪里来，而不是面对一句无法追溯的“AI 认为应该这样改”。
这比往提示词里塞一大段规范可靠。提示词通常是一次性的，也很难确认模型到底读了什么。把规范做成仓库资产，再把上下文使用情况留在评论里，团队才有机会复查和维护。
模型选择也被管理员接管
同一天，GitHub 还公布了 Copilot Business 和 Enterprise 的默认模型启用策略。
以后已经正式可用的 Copilot 模型，可以跟随组织或企业级策略自动开放，不必等管理员逐个勾选。新策略先进入 28 天的配置窗口，期间可以设置但不会生效，计划从 2026 年 8 月 26 日开始影响模型可用性。
GitHub 保留了几个限制：管理员显式启用或禁用过的模型不会被覆盖；开源权重模型，以及不在 GitHub 数据保留协议范围内的模型，也不会因为默认策略自动开放。
这件事的影响不在“少点几次开关”。默认开放能减少配置滞后，但也可能让一个尚未通过内部评测的新模型更快进入开发流程。默认关闭更稳，却会把审批和测试压力集中到平台团队。模型选择已经不是开发者个人偏好，而是一项需要记录和复盘的企业策略。
GitHub 随后扩展 Copilot app usage metrics，把会话、请求、prompt、token 和代码活动按用户、功能、模型、语言等维度汇总。管理员终于可以回答一些过去很模糊的问题：哪个模型在什么场景被使用，代码审查和 coding agent 的消耗有何差别，某个团队的增长来自真实工作还是试用。
速度和地域变成一个参数
Vercel 的 AI Gateway 从另一侧做了相似的事。它把模型服务的速度和地域收进统一参数，不要求业务代码绑定某个 provider 的私有配置。
fast mode 目前处于 beta。开发者在providerOptions.gateway中设置speed: 'fast'，网关会在存在快速 serving path 时使用它；没有可用快速路径，就回落到标准速度。
同一个speed参数可以跨模型请求快速服务路径。来源：Vercel Changelog
这个抽象省掉了 provider 适配，却没有消除代价。Vercel 明确提醒，fast variant 通常比基础模型更贵。延迟和 token 成本因此成了同一条路由策略上的两个旋钮。
区域推理更接近合规控制。请求可以把inferenceRegion指定为 US 或 EU；如果没有 provider 能在目标区域服务，请求会失败，不会偷偷改走全球路由。响应还会报告实际服务区域。
inferenceRegion把推理区域写进请求。来源：Vercel Changelog
不设置时仍然是全球路由，没有数据驻留保证。设置区域后，provider 可能收取更高费率，Vercel 给出的常见幅度约为 10%，并称不会额外加价转售。
平台收拢控制，不替团队做决定
GitHub 和 Vercel 都在把零散配置收进平台控制层：技能放在哪里，MCP 能不能写，哪些模型默认开放，请求走快速还是标准路径，推理留在哪个区域，最后都能被设置和审计。
但控制层不是把选项集中到一个后台就结束了。
Martin Fowler 站点上 Rahul Garg 对多 agent 工作流的复盘提到一个很实际的问题：主 orchestrator 的工作记忆会被无关 transcript、重复探索和中间噪声污染。他把是否需要共享同一套心智模型称为 “cognitive locality”。任务拆得过细，多个 agent 会重复重建上下文，平台接入再多工具也只是让噪声进得更快。
所以团队真正要管的，不只是模型名单。哪些规范值得进入每一次审查，哪些 MCP 数据可以读取，fast mode 的额外成本是否换来了交付时间，区域限制失败后能否明确退出，这些都需要自己的规则。
AI 编程平台正在“收权”，但这并不天然是坏事。控制点集中以后，边界更容易被看见，也更容易被审计。前提是团队没有把默认值当成答案：新模型先过内部任务，外部上下文坚持最小权限，高成本路径有预算阈值，每一次自动决策都留得下记录，也停得下来。