背景与概述:一次面向开放互操作性的战略转向 在 2025 年,GitHub 正式宣布将于 2025 年 11 月 10 日停用基于 GitHub App 的 Copilot Extensions,转而支持和推广 Model Context Protocol(MCP)作为与 AI 助手和代理集成的通用标准。此项变更意味着过去依赖 GitHub App 作为后端扩展托管方式的 Copilot Extensions 将不再受支持,开发者需要尽快评估替代路径。官方明确指出,客户端侧的 VS Code Copilot Extensions 不受影响,标准的 GitHub Apps(不包含 Copilot Extension 功能)仍然有效。与此同时,GitHub 还在时间线上安排了创建新扩展的阻断、事前的 brownout 测试窗口以及最终的全面停用时刻,旨在为社区提供必要的缓冲期与测试机会。 为什么 GitHub 做出这个决定:兼容性与重复开发的成本 GitHub 给出的核心理由是互操作性与可扩展性问题。以往的 Copilot Extensions 只能在 GitHub Copilot chat 中工作,开发者若想要让工具在其他 AI 助手(例如 Claude Code 或其他支持 MCP 的宿主应用)中可用,往往需要为每个平台重复构建集成。
Model Context Protocol 提供了一种统一的服务器端协议,开发者只需搭建一次 MCP 服务器,就可以在多个兼容的宿主应用中复用,从而降低重复开发和维护成本。这不仅利于第三方工具的广泛适配,也让平台方可以专注于统一的集成能力,而不是维持多个彼此不兼容的扩展生态。 受到影响的对象与不受影响的范围 受直接影响的是以 GitHub App 形式实现并注册为 Copilot Extensions 的后端服务。对于这些服务的维护者和使用者来说,需要在官方停用前制定迁移计划或替代方案。另一方面,几类场景并不受影响:本地或客户端侧的 VS Code Copilot Extensions 仍然受支持,用户可以继续在编辑器内使用现有功能;没有 Copilot Extension 功能的标准 GitHub App 也不会因本次变更被下架;同时,混合应用(既包含普通 GitHub App 功能又启用了 Copilot Extension 配置)的维护者被要求在截止日期前禁用 Copilot Extension 设置以保持其在 Marketplace 的可见性。 关键时间点与迁移窗口 为了降低对现有生态的冲击,GitHub 公布了几个重要日期。
2025 年 9 月 24 日起,创建新的服务器端 Copilot Extensions 将被阻止;2025 年 11 月 3 日到 7 日安排了 brownout 测试窗口,期间可能会出现临时性服务中断,用以验证停用流程与兼容性;最终在 2025 年 11 月 10 日 23:59 PST,所有 Copilot Extensions 将被完全停用。对于依赖这些扩展的企业与开发者而言,brownout 期是进行迁移演练、负载测试与用户沟通的关键时机。 如何评估影响:优先级判定与功能映射 在接到停用通知后,团队应第一时间对现有的 Copilot Extensions 进行全面审计。审计工作包括但不限于功能清单、调用频率、用户覆盖范围、数据流向、认证方式以及与 GitHub 的依赖点。基于这些信息,确定哪些功能必须快速迁移,哪些可以延后重构。将现有功能映射到 MCP 能力集时,需要关注工具调用类型、上下文暴露范围、文件系统或代码仓库访问需求以及身份与权限模型。
部分功能可能通过现有的 MCP 标准直接实现,而另一些则需要在 MCP 服务器中做额外的功能层封装或桥接服务。 迁移策略建议:从短期应急到长期架构 在短期内,若你的扩展为企业关键路径,优先考虑以下策略以减少中断风险。可以将最关键的后端逻辑迁移到一个独立的服务层,该服务能够同时接收来自 GitHub 的 webhook 与 MCP 协议调用,以便逐步切换流量。对于混合应用,务必遵循 GitHub 指引,在截止日期前禁用 Copilot Extension 配置以保留 Marketplace 条目。中长期来看,建议直接构建或采用 MCP 服务器作为统一的接口层,支持多宿主应用,同时设计良好的抽象以便未来可以接入更多的 AI 助手。复用已有的身份认证、日志、审计与配额控制模块能显著缩短整体交付时间。
技术实现的关键考量:认证、安全与数据治理 迁移到 MCP 或构建 MCP 服务器时,安全与合规不应被忽视。首先需要明确身份与权限边界,确保 MCP 服务在代替原有 Copilot Extension 时不会无意中扩大访问范围。建议继续使用 GitHub 提供的细粒度 OAuth 或 App 身份验证模型,并在 MCP 层增加额外的访问控制策略,例如按功能的最小权限模型。其次,数据治理方面要审查代码上下文、敏感元数据与调用日志的存储与泄露风险。企业应明确哪些数据可被发送到外部模型或宿主应用,哪些数据必须在本地保留或进行脱敏处理。最后,性能与配额问题同样重要,MCP 服务器需要具备良好的速率限制、重试与熔断机制,以应对高并发的工具调用场景。
测试与灰度发布:利用 GitHub 的 brownout 窗口进行验证 官方安排的 brownout 测试窗口为开发者提供了宝贵的实战机会。建议在该窗口之前完成最小可运行的 MCP 实现,并在受控环境中进行灰度发布。利用小规模真实用户进行功能验证,重点监控调用延迟、失败率、授权错误以及用户体验差异。通过这些数据调整回退策略与熔断阈值。在 brownout 期结束后,应整理测试结论、修复关键缺陷并准备在完全停用日之前完成最终迁移或公布替代方案的上线计划。 用户沟通与市场维护:透明度决定信任成本 对外沟通策略在迁移过程中至关重要。
向现有用户明确时间线、可能的服务影响以及替代路径,能够显著降低支持请求和用户流失。对于企业客户,建议提供专门的迁移指南、技术支持通道以及可能的延长过渡期安排。对于 Marketplace 中的第三方开发者,遵从 GitHub 的要求禁用 Copilot Extension 配置可以避免被移除出列表,同时应在 Marketplace 页面上更新说明,提示用户未来集成的方式。透明且及时的信息发布不仅体现了责任感,也有助于维持品牌与开发者生态的长期信任。 备选方案与短期替代:VS Code 插件与自建桥接器 并非所有组织都适合立即迁移到 MCP。有些团队可能选择将关键功能转为客户端侧的 VS Code Copilot Extension 来维持工作流,尤其是那些对低延迟或本地资源访问有强烈依赖的场景。
另一个常见的短期解决方案是自建桥接器服务,该服务接受原有 Copilot Extension 的调用并将其转发到新的 MCP 后端或替代的服务商。桥接器可以在过渡期内降低变更成本,给团队更多时间完成长期架构的重构。 对生态的长期影响:开放标准如何重塑工具市场 Model Context Protocol 的推广可能会在长期重新塑造开发者工具与 AI 助手之间的关系。一个通用、可移植的服务器端协议降低了单一平台锁定的风险,鼓励工具提供商构建可跨宿主应用的能力包。用户将更容易在不同 AI 助手之间迁移和比较服务,而工具供应商的创新也更容易被多个宿主应用采纳。对于 GitHub 来说,支持 MCP 既是响应生态需求的举措,也是向更开放互操作环境转型的战略选择。
常见问题解答式提醒:优先行动的四个主题 评估优先级、保护企业关键功能、确保合规与安全以及利用 brownout 窗口进行实战验证是迁移过程中反复出现的关键主题。开发团队应将这些主题整合进迁移计划,与产品、法律与运维团队保持紧密协作。对于决定继续投资 Copilot 生态的企业,尽早构建可复用的 MCP 层不仅能满足眼前需求,也为未来多宿主的场景打下基础。 结语:从被动应对到主动拥抱互操作性 GitHub 停用 Copilot Extensions 的决定虽然会给许多团队带来短期的重构成本,但从战略视角看,这一调整推动了开放标准和互操作性的进一步发展。把握好时间窗、合理制定迁移计划、重视安全与用户沟通,将帮助企业在过渡中最小化风险并在未来享受跨平台生态带来的红利。对于开发者而言,MCP 提供了一个机会:用一次工程投入,换来多宿主、多助手的长期价值与更广泛的用户触达。
。
