GitHub 和 Vercel 在 7 月 23 日给出了同一个方向的两个切面：MCP 不再只是把文档、仓库和服务状态接到聊天窗口里，它开始承载部署、购买、分派 issue、生成 PR 这类会改变系统状态的动作。
这不是一句“智能体更强了”就能解释清楚的产品更新。真正的变化在工程边界上。协议要更容易横向扩容，工具要能触碰生产系统，平台还得说明什么时候自动执行、什么时候交给人审。MCP 走到这一步，开发团队要看的已经不是演示里能不能跑通一次，而是失败时谁能看见、谁能阻止、谁负责回滚。
无状态协议先解决部署形态
GitHub Changelog 把背景说得很直白：MCP 协议将在 2026 年 7 月 28 日转向无状态核心，GitHub MCP Server 已经提前支持新版规范。无状态的价值不在概念，而在少掉一类服务端负担。GitHub 这次提到的实现变化包括移除 Redis session，让初始化阶段不再写数据库，每次调用也不再读会话数据。
它还把一部分原本需要读取请求体的场景移到 HTTP 头上处理。GitHub 仍然要做日志和 secret scanning，但新版协议能从保证存在的头部字段拿到需要的值，减少对每个 payload 做深度检查的必要。对大规模远端 MCP Server 来说，这比“连接更快”更重要：服务器越接近公共基础设施，越不能把状态和检查成本堆在每次调用路径上。
工具调用正在触碰生产系统
Vercel 的更新更接近应用层。Vercel MCP 现在可以把代码直接部署到新项目或已有项目，工具会接收文件、创建项目、识别框架、安装依赖并构建，最后返回一个可以打开和分享的 URL。对开发代理来说，这等于把“写完代码”后的最后一段 CI/CD 也放进对话里的工具调用。
更敏感的是购买能力。Vercel MCP 支持升级团队到 Pro、购买 v0 或 AI Gateway 预付额度、购买 SIEM add-on，以及购买并注册域名。Vercel 在这里加了几条边界：它会说明价格、一次性或周期性收费；价格不明确时跳到相关价格或账单页面；真正购买前需要确认；执行者还要有团队账单权限和有效支付方式。这个设计承认了一件事：当代理能花钱时，确认和权限不再是体验细节，而是安全机制的一部分。
GitHub 把代理放进协作流
同一天，GitHub 还宣布 Copilot cloud agent for Linear GA。Linear issue 可以直接分派给 Copilot，代理会分析 issue、在 GitHub Actions 支撑的临时开发环境里工作、打开 draft pull request，并把进度写回 Linear 活动流。团队还可以在 Linear 里选择模型、指定自定义 agent、设置 base branch 和 working branch，并通过评论继续给运行中的会话补充指令。
GitHub Issues 的代理自动化控制则说明了另一侧边界。代理可以给 issue 打标签、设字段、改类型、关闭 issue 或分派负责人；GitHub 给这些动作加上理由、置信度和可审批建议。高置信度动作可以自动应用，中低置信度动作可以先进入建议面板。GitHub 同时提醒，approvals 是工作流便利，不是服务器端安全边界；如果代理本身有改 issue 的权限，它仍然可以直接执行。
采用速度取决于审计边界
把这些更新放在一起看，MCP 和开发代理正在从“帮我查、帮我写”进入“帮我改系统”。协议无状态化让服务更容易做成远端基础设施，部署和购买让工具调用产生真实外部效果，Linear 和 Issues 集成把代理放进团队日常协作，而不是单独的实验台。
这也给平台团队提了一个更硬的验收口径。能不能接 MCP 不是重点，重点是每个工具动作有没有最小权限、确认点、理由记录、可检索日志和明确的失败出口。对普通研发团队来说，短期内最值得放开的任务不是“让代理自己管一切”，而是部署预览、低风险元数据整理、带审查的 PR 草稿这类边界清楚的工作。越接近生产、账单和权限变更，越要把自动化阈值写进系统，而不是留在提示词里。