GitHub Copilot SDK 更名后开发者需要关注哪些迁移信息

GitHub 在 2026 年 10 月 28 日宣布，GitHub Copilot SDK 正向 Microsoft Copilot SDK 过渡。对已有接入项目，最重要的信息是：官方没有要求用户立即修改现有实现。团队应关注后续仓库归属、包名、命名空间和文档变化，不能仅凭新品牌名称猜测新的安装坐标。

官方地址：https://github.com/github/copilot-sdk

假设一个团队已经把 SDK 接入内部助手，看到公告后很容易同时修改依赖、导入路径和部署脚本。更稳妥的做法，是先把公告转成一份可追踪的迁移卡：哪些信息已明确，哪些仍需要等待对应版本说明。这份文章讨论的是工程准备，不是已经完成迁移的实测报告。

先确认公告要求，而不是立即替换依赖

这次公告首先说明 SDK 的方向：它将承担 Microsoft Copilot harness 的可编程接口角色，该基础也被 Microsoft 和 GitHub 产品共同使用。公告同时说明迁移会分阶段推进，旧名称可能继续出现在部分包、命名空间与文档中；支持安排保持不变。以上是更名公告提供的范围，不能从中推出所有语言已经完成同步改名。

因此，现有项目的第一步可以只是登记公告和当前接入情况。正在运行的应用若没有独立的升级需求，不应为了让名字看起来一致就主动改写全部依赖。新项目则从官方仓库当前的语言说明入手，不根据品牌字样构造不存在的地址。

把名称变化与依赖坐标分开记录

仓库首页已经出现 Microsoft Copilot SDK 标题，但安装表仍列出既有坐标。这种并存与阶段性过渡相符。下面列的是官方仓库页面中可见的例子，用于辨认当前文档，不是对未来名称的预测，也不是要求读者现在执行更新。

不要把表中字符串里的 github 机械替换成 microsoft。安装包名、代码命名空间和仓库地址是不同类型的信息，迁移时需要各自的正式说明。仓库归属调整也不等于应用配置、账户权限和计费方式必然同时变化。

为现有项目准备一份最小迁移卡

可以先选一个已经接入 SDK 的服务，记录它实际使用的语言、锁定版本、依赖来源和运行环境。再列出 SDK 出现的位置：依赖文件、示例文档、内部模板、构建缓存配置等。这里是在做依赖盘点，不必立即改代码。

例如内部助手只使用一种语言，可以先把任务限定为这一语言的 SDK。不要为了“全团队统一迁移”同时更新没有使用的语言示例。团队共用脚手架时，则应先找出模板和真实项目之间的引用关系，否则模板虽然改了，存量服务仍然保持另一套依赖。

根据语言分别跟踪后续说明

当新的版本或迁移说明出现时，先检查它是否适用于项目正在使用的语言和版本。其他语言的安装变化可以作为提醒，但不宜直接照搬。类似地，主分支文档与项目锁定版本也可能处在不同阶段，阅读时要把目标版本写清楚。

官方仓库提供各语言目录、入门材料与 SUPPORT.md。建议团队保留公告链接，并从同一官方仓库继续进入对应语言资料；遇到旧名和新名共存，先核对它们分别指向品牌、包坐标还是文档标题，避免把正常过渡误当成配置故障。

如果后续材料没有明确新的替代坐标，就把该项留为待确认，不要先发布一份猜测的“新安装命令”。现有项目是否要升级，也应结合版本说明和自身功能需求决定，更名本身不能证明升级没有成本。

让升级任务有明确的完成条件

真正实施时，建议在独立变更里更新依赖并保留可回退基线。选用与业务相关的小场景检查初始化、会话处理、工具调用和错误处理，记录目标版本及结果。这些是本文提出的工程做法，不是公告中额外附带的强制迁移步骤。

部署文档和内部示例也应跟随已经采用的版本更新。应用尚未升级时，不应仅修改文档让它看起来已经使用新坐标。反过来，代码升级完成后还长期保留旧命令，会让后续维护者按另一套材料重新接入。

更名是否意味着旧项目立即不能运行？

这份公告没有提出这样的结论，并明确表示现有用户无需立即修改。具体版本问题仍以对应版本资料为准。

仓库首页换了标题，依赖名就必须跟着换吗？

不能这样判断。品牌标题与包坐标分别维护，需使用正式安装与迁移说明。

能否把这次消息理解为 SDK 所有能力都已正式可用？

不能。公告讨论方向与过渡，不替代各功能的可用状态和版本说明；预览能力与正式能力要分别确认。

参考：GitHub 2026 年 10 月 28 日公告、SDK 官方仓库与语言入口、官方支持说明。