本文由 Andrea Griffiths 撰写，AI 辅助翻译为中文。如有翻译问题，欢迎在 mainbranch-zh 仓库提交 PR。

MCP 规范 7 月 28 日定稿前，GitHub 开发者现在能做什么

MCP 候选版本已于 5 月 21 日发布，规范将于 7 月 28 日定稿。最好的准备不是等发布公告，而是现在就让你的仓库对智能体可读。

MCP 规范的下一版会在 7 月 28 日定稿。候选版本不是还没来，它已经在这里。接下来两周，你最该做的不是等发布公告。

而是准备好你的仓库。

很多 MCP 内容都从协议讲起：它是什么、客户端和服务器如何通信、为什么 tool calling 很重要。这些背景有用。但如果你是在 GitHub 工作流里和智能体一起构建，实际问题要小得多：

怎样才能让这个仓库更容易、更安全、更可预测地让智能体参与工作？

我会从这里开始。

真正发布了什么

MCP 7-28 是协议发布以来最大的一次修订，而且包含破坏性变更。

initialize 握手没了。协议层的会话没了。任何请求都可以落到普通负载均衡器后面的任意服务器实例上。扩展现在是一等公民，前两个官方扩展覆盖了用于服务器渲染 UI 的 MCP Apps 和用于长时间工作的 Tasks。授权机制更接近 OAuth 和 OpenID Connect 在真实部署中的样子。Roots、sampling 和 logging 已被弃用。还有一套正式的生命周期政策，这意味着未来版本在至少给出十二个月的弃用窗口之前，不应该破坏你的代码。

如果你已经在发布 MCP 服务器，这一段就是你的待办清单。读一遍草案 changelog，用 SDK betas 跑你的服务器，现在就规划迁移。如果你是基于 2025-11-25 的实验性 Tasks API 构建的，这次迁移不是可选项。

值得关注的变化

MCP 已经成了一个很清楚的信号：智能体开发正在从孤立的 demo 走向可复用的开发者基础设施。

有意思的地方不只是智能体能调用工具。协议正在把工具怎样描述、上下文怎样传递、权限怎样工作、行为怎样验证都正式化。一个规范提案现在没有在一致性测试套件中对应的场景，就不能达到 Final 状态。这就是基础设施成熟时的样子。

这对 GitHub 开发者很重要，因为大多数智能体工作最后都会碰到同一片区域：仓库、issue、pull request、CI、文档、认证边界，还有维护者的预期。

如果 7 月 28 日会让更多开发者开始认真对待 MCP，最好的准备就是现在让你的项目对智能体更可读。

7 月 28 日之前该试什么

先从仓库说明开始。

如果你的项目还没有 AGENTS.md，写一个。它就是普通 Markdown，已经有超过 60,000 个开源项目在用，30 多个编码智能体会读取它。

把它写得实用一点。告诉智能体怎么 build、test、lint 和浏览仓库。把人类维护者通常会在 review 评论里说明的约定写进去：源文件在哪，哪些命令可以安全运行，什么不能碰，改动该怎么验证。GitHub 审阅了数千份 AGENTS.md 文件，发现最好的文件会给出带 flags、可以直接复制粘贴的准确命令。不是“跑一下测试”。

然后挑一个工具真的能帮上忙的工作流。不是十个工具。一个就够。

好的第一批候选工作流都是可重复、低风险的：搜索文档、检查包 metadata、验证配置、运行一个已知的测试命令，或者根据仓库规范总结一个 issue。你不是要让智能体自主行动。你要做的是把一次交互讲清楚，让另一位开发者也能理解并复现。

接着，定义信任边界。

这个工具能读什么？能写什么？需要凭证吗？失败时会发生什么？如果答案是“智能体自己会想办法”，那这个约定还不够清楚。新规范在这里帮了你一半。MCP 7-28 对授权的加固，假设你知道每个工具被允许碰什么。把这些写下来的团队，会比那些还在反向推导自己权限的团队更快采用它。

一份简单的仓库就绪 checklist

在规范定稿前，问问自己：

一个新贡献者能理解智能体该怎样在这个仓库里工作吗？
build、test 和 lint 命令是否写清楚了，并带有准确的 flags？
有没有一个现实的工作流可以变成 MCP 工具？
输入和输出是否明确？
权限和失败模式是否有文档？
不靠感觉，也能在 CI 里测试它吗？

最后一个很重要。智能体工作流不会因为听起来厉害就变得可用于生产。团队能检查、约束和测试它们时，它们才会真正有用。

如果你更愿意跟踪进度而不是通读内容，这里有同一份 checklist 的交互版。它会在浏览器里保存你的进度，把每个服务器项连到相关的规范文档，还能复制成 Markdown，让你把它作为 issue 开到自己的仓库里。

下载可打印的仓库就绪 checklist（PDF）

现在就做那些无聊的工作

智能体开发的下一阶段不只关乎更聪明的模型。它关乎模型和开发者已经在用的系统之间更好的接口。

对 GitHub 项目来说，这意味着那些无聊的工作突然很重要：仓库说明、工具 schema、权限边界、示例和测试。

这是个好消息。你不需要等到 7 月 28 日才开始。今天就能让你的项目更容易被智能体和人类使用。

规范定稿之后，收获最多的团队会是那些已经知道希望智能体做什么、边界在哪里、以及怎样判断它是否奏效的团队。