摘要GitHub 已经把基于 GitHub App 的 Copilot Extensions 全面下线官方指定替代方案是 MCPModel Context Protocol服务器。这篇文章复盘一次真实迁移从旧 Extension 的 API 面改成 MCP server中间踩了认证、工具命名、流式响应三个坑最后给出可复用的迁移清单。适合正在维护 Copilot 集成、或者想搞清楚 MCP 到底怎么接的后端开发者。1. 背景与痛点事情要从一封告警邮件说起。上周三早上我们的内部 Copilot 集成突然集体 404。翻了半天日志没头绪最后在 GitHub Changelog 里找到了答案基于 GitHub App 的 Copilot Extensions 已于 2025 年 11 月 10 日 23:59PST全面停用。官方时间线是这样的来源github.blog/changelog/2025-09-242025 年 9 月 24 日停止新建服务端 Extension2025 年 11 月 3 日至 7 日brownout 测试期服务间歇性中断2025 年 11 月 10 日全部 Copilot Extensions 停用要注意的是这次下线只影响服务端 Extension挂载在 GitHub App 上的那种。VS Code 客户端扩展和不含 Copilot Extension 功能的标准 GitHub App 都不受影响。我们中招是因为内部工具走的是服务端路线。GitHub 给的出路只有一个迁移到 MCP。也就是从给 Copilot 专供的私有协议换成一次构建、到处挂载的开放标准。这件事对 .NET 和 Python 开发者影响最直接——集成的骨架要重写。2. 技术原理旧 Extension 和 MCP 差在哪先把两种架构摆在一起看。旧 Copilot Extension 的本质是一个 GitHub AppGitHub 把用户消息以 webhook 形式推到你的服务端你返回特定格式的响应。认证走 GitHub App 的 token 体系能力发现靠 Extension 的私有约定。MCP 的思路完全不同你的工具是一个独立的 MCP server宿主Copilot、Claude Code、其他任何兼容 agent通过 JSON-RPC 与它握手动态发现工具列表调用时传结构化参数。宿主和工具之间是标准的客户端-服务器关系GitHub 只是把 Copilot 变成了众多 MCP 宿主之一。flowchartLRsubgraph旧架构[旧Copilot Extension已停用]|A1[Copilot宿主]--|webhook私有协议|B1[GitHubApp服务端]|endsubgraph新架构[新MCP Server]|A2[Copilot/VSCode]--|JSON-RPC握手|B2[MCPServer]||A3[ClaudeCode等其他宿主]--|同一套协议|B2|end关键差别有三点认证归属旧模式由 GitHub App 托管用户身份MCP 模式下认证是 server 自己的事OAuth 2.1 或 API key宿主只负责传递。能力发现旧模式靠注册时的静态配置MCP 用tools/list动态发现。可移植性旧 Extension 只能挂在 Copilot 上同一个 MCP server 可以同时被 Claude Code、VS Code Copilot 模式等多个宿主调用。这是这次迁移唯一的补偿——不再押注单一平台。3. 环境准备实测版本2026 年 9 月Python 3.12.6mcp SDKmcp1.9.4pip install mcp[cli]测试宿主VS Code 1.96 GitHub Copilot ChatMCP 支持已内置Claude Code 2.x用来做跨宿主验证建议先去 GitHub MCP Registrygithub.com/github/github-mcp-server 相关生态页逛一圈很多常见场景issue 管理、仓库操作已经有现成 server不一定需要自己写。确认没有现成的再动手。4. 实战实现把一个旧 Extension 改写成 MCP Server旧 Extension 里我们有一个工具查询内部发布系统里某个服务的当前版本。旧实现是接 webhook、解析用户自然语言、查库、拼响应。迁移时不要复用解析自然语言那部分——MCP 宿主自己会做意图映射你的 server 只需要提供干净的、参数明确的工具。用官方 Python SDK 重写# server.pyfrommcp.server.fastmcpimportFastMCPmcpFastMCP(deploy-info)mcp.tool()defget_service_version(service_name:str,env:strprod)-dict:查询指定服务在某个环境的当前版本。Args:service_name: 服务名如 gatewayenv: 环境名prod / staging / dev# 这里替换成你真实的查询逻辑return{service:service_name,env:env,version:2.14.3,deployed_at:2026-09-24T03:12:00Z,}if__name____main__:mcp.run()# 默认 stdio 传输然后在 VS Code 的mcp.json里注册{servers:{deploy-info:{command:python3,args:[/opt/tools/deploy-mcp/server.py]}}}重启 VS Code在 Copilot Chat 里输入deploy-info gateway 现在是什么版本宿主会自动发现并调用get_service_version。全程不需要你写任何自然语言解析。5. 效果验证迁移前后对比同一功能内部实测对比项旧 Copilot ExtensionMCP Server接入协议webhook 私有响应格式JSON-RPC标准协议可用宿主仅 CopilotCopilot、Claude Code、其他 MCP 宿主认证方式GitHub App 托管server 自管OAuth 2.1 / key意图解析服务端自己写宿主负责部署形态必须公网可达stdio 本地进程或远程均可迁移工作量—约 3 人日/工具跨宿主验证很重要。我们在 Claude Code 里挂同一个 server零改动直接跑通——这是旧架构做不到的。6. 踩坑记录坑一认证自己扛。旧 Extension 的用户身份由 GitHub App 透传MCP server 的认证完全自理。内部工具一开始图省事用了裸 API keycode review 被打回来。远程 MCP server 的规范推荐 OAuth 2.1 授权码流程SDK 里有现成的 provider 接口照着实现即可别自己发明。坑二工具描述就是提示词。第一版我把 docstring 写成了查询版本结果宿主在很多问法下不触发这个工具。MCP 宿主靠工具的 name description 参数 schema 来决定何时调用description 要写成给模型看的触发条件把常见问法变体覆盖进去。改完描述后触发率明显上升。这是整个迁移里性价比最高的一次修改。坑三stdio 下的日志会毁掉协议。调试时习惯性地往 stdout 打日志宿主直接解析失败断连——stdio 传输下 stdout 是协议通道日志必须走 stderr。官方文档写得很清楚指我第一次没读到建议一开始就用logging模块配置 stderr handler。坑四混合 App 要手动拆配置。如果你的 GitHub App 既是标准 App 又开了 Extension 功能必须在停用前手动关掉 Extension 配置否则连 Marketplace 上架状态都会受影响。我们有个边缘工具就是这种混合形态差点被连坐。7. 总结与展望这次迁移本质上是一次去专有化GitHub 把私有扩展机制换成了开放标准短期是返工长期换来跨宿主可移植性。给还在观望的人三个建议先查 MCP Registry 有没有现成的工具描述当提示词认真写远程 server 尽早把 OAuth 补上。你的团队迁移 MCP 了吗是直接用官方 GitHub MCP Server还是自建工具命名和权限控制上踩过什么坑评论区聊聊我整理进下一篇。
