GitHub MCP实战：新协议、Elicitation与无状态服务器如何落地

在一场聚焦 MCP（Model Context Protocol）的技术分享中，一位同时身兼三重身份的 GitHub 工程师——GitHub MCP Server 开发者、Copilot Agent Harness 维护者、以及 MCP 协议维护者——分享了他在服务器端、客户端和协议规范三条战线同时推进 MCP 的一手经验。这些视角交叉在一起，揭示了 MCP 从实验走向规模化过程中真正的难点所在。

三顶帽子：从服务器到协议规范

分享者已经在 GitHub MCP Server 上工作了一年半以上，同时负责 Copilot 的 Agent Harness、CLI 等驱动多种 Copilot Agent 的底层设施，还成为了 MCP 协议的维护者之一。这种横跨服务器、客户端和规范三端的经历，让他对 MCP 生态有着不同于单一角色的理解。

他特别强调，正是因为同时接触客户端，扩展 GitHub MCP Server 才变得更有意思——服务器端的设计取舍，往往要放到客户端的真实调用场景中才能看清楚。

为了帮助客户端开发者有可测试的对象，他和团队在最新 MCP 规范正式发布前约三周，就把新规范的支持提前上线到 GitHub MCP Server。这次提前发布进展顺利，也为整个生态的迁移铺路。

支持新协议不难，难的是野生服务器的失败方式

在把新协议支持推进到 Agent Runtime 的过程中，分享者踩了不少坑。他直言：支持新协议本身很简单，官方 SDK 也非常出色，真正棘手的是大量野生 MCP 服务器存在未定义行为。

不同服务器的失败方式五花八门，错误信息各不相同。为此他们的核心策略是——一旦出现疑问，立刻快速降级回退，避免用户在别人尚未完成新规范迁移时被迫长时间等待。他明确指出，不能指望整个生态一夜之间全部升级。

从数据看，这套回退与迁移策略效果不错：几周前采用新协议的请求占比只有约 3%，如今已经攀升到约 20%，流量曲线持续上扬，且没有引发太多问题。

实践反哺规范：Skills over MCP 与 Server Cards

服务器与客户端的实战经验，直接反哺了他的第三个角色——协议维护者。他会有意识地收集运行中遇到的各类问题与挑战，把它们当作机会带到工作组，并吸纳社区输入。社区提出的问题既有认证服务器相关的，也有客户端未实现特定功能导致的。

他认为，拥有规模化运行服务器、以及在客户端实际发布功能的实践经验，对理解「哪里真正困难」极为关键。近期几项进展让他颇为兴奋：

• Skills over MCP 被投票通过，成为官方扩展；
• Server Cards 已经发布，将支持 MCP 的原生 Web 发现能力。

他判断，原生 Web 发现将极大改变 MCP 的分发与使用方式。

Server Cards 是 MCP 生态中用于描述某个 MCP Server 能力与元信息的标准化文档格式，类似于 API 的 OpenAPI 描述文件或应用商店的上架信息页。它包含服务器提供的工具列表、认证方式、适用场景等结构化信息，供客户端或平台在连接前进行发现与筛选。原生 Web 发现（Native Web Discovery）意味着用户或 Agent 可以通过标准化的 Web 机制（如 Well-Known URL）自动找到某个域名下部署的 MCP Server，而无需人工配置服务器地址。这对 MCP 的分发模式影响深远：开发者只需将 Server Card 发布到标准路径，任何支持该规范的客户端即可自动接入，类似于网站通过 robots.txt 或 sitemap.xml 向爬虫暴露自身信息的机制。

Skills over MCP 则是一种将 Agent 能力以 MCP 工具形式标准化暴露的扩展规范，允许不同平台的 Agent 之间以统一接口相互调用技能，推动跨系统的 Agent 互操作性。

现场演示：从原生 UI 到删库确认

分享中，他用 Copilot 的 auto 模型做了实时演示。调用 GitHub MCP 时，服务器返回了一个 MCP 原生 UI，直接展示他的 GitHub 用户卡片，而非纯文本。

随后他让 Copilot 创建了一个全新仓库，并感慨即便是从业者，也需要时不时停下来重新为「Agent 能瞬间创建全新项目」这件事感到兴奋。

最具看点的是删除仓库的演示。删库时弹出的对话框正是 MCP 中的 elicitation（信息征询）——服务器向用户发起提问。他一直想复刻 github.com 上删除仓库时要求输入仓库名确认的交互，因为删除是相当不可逆的操作。这次终于通过 elicitation 在 MCP 层实现了同样的确认体验。

MRTR：让无状态服务器也能支持 Elicitation

真正的技术核心，是新协议引入的 多轮往返请求（Multi-Round Trip Request，MRTR）。在旧版规范下，GitHub MCP 以及许多分布式部署的 MCP 服务器都无法支持 elicitation，因为它需要跨服务器通信来协调状态和 MCP 会话。

新机制的巧妙之处在于：一次 elicitation 的两次请求可以由完全不同的服务器处理。其中的 nonce 与 sealed 部分是关键——服务器可以加密一段连用户都无法读取的数据，让它随 metadata 在多轮请求间传递。这意味着：

• 敏感值可以保持保密与安全；
• 服务器依然能以完全无状态的方式跨大量机器部署。

用更直白的话说：一个工具在完成前可以发起追问，Agent 触发工具后，后端说「我还需要一样东西」，于是向用户提问、拿到回答、再继续返回最终结果。而所谓「继续」，实际上是带着携带答案的额外 metadata 再次调用同一个工具。

对没有做过服务器规模化的人来说，这个改动似乎不起眼，但正是它让分享者得以在无需后端跨服务器协调的前提下，为服务器发布 elicitation 功能。

无状态服务器（Stateless Server） 是分布式系统中的核心设计模式，指服务器在处理请求时不保存任何上下文信息，每个请求都完全独立。其优势在于可以在多台机器上任意横向扩展（Horizontal Scaling）——只需增加节点数量即可提升吞吐量，且任意节点宕机不影响服务整体可用性。GitHub 这类面向全球的平台通常将 MCP Server 部署在大量无状态实例背后的负载均衡器之后，这意味着同一会话的两次请求可能落到完全不同的物理机器上。

传统 Elicitation（服务器向用户追问）要求同一会话的后续请求必须回到同一台服务器，以恢复上一步的中间状态，这与无状态部署天然冲突。MRTR 通过将状态加密后外置到客户端传递的 metadata 中，绕开了这一限制：服务器无需"记住"上次的状态，只需解密随请求一同送来的 sealed 数据即可恢复上下文。这本质上是将"会话状态"从服务器内存转移到了经过加密保护的请求载荷中，兼顾了安全性与可扩展性。

更值得期待的是生态外溢

他对 MCP 更宏观的期待，是这些更有意思的特性将逐渐扩散到整个生态：更多人能够规模化运行服务器，更多人能够真正在规模下做出可交互的 Agent 体验。在他看来，这些进展有望把 MCP 进一步推向主流。

从这次分享可以看出，MCP 当前的关键突破点并不在协议是否炫酷，而在于能否在无状态、可横向扩展的真实生产环境中稳定运行。MRTR、Server Cards 与 Skills 扩展的组合，正是在为这个目标补齐拼图。