GitHub Teams 应用合并通知与代码代理，旧入口怎样过渡

GitHub 在 2026 年 10 月 23 日公布了 Teams 应用整合安排：原先名为 GitHub notifications 的应用成为同时提供通知与 Copilot 的合并入口。已经使用通知应用的团队更新即可；使用旧 GitHub 应用的团队需要安装合并应用。公告称旧应用将改名为 GitHub (deprecated)，并于 2026 年 11 月 16 日退役。

官方公告地址：https://github.blog/changelog/2026-10-23-turn-notifications-into-code-with-github-copilot-in-teams/

先认清自己安装的是哪个入口

先在 Teams 中确认已安装应用的身份，而不是只看图标或聊天里的简称。两种旧入口的处理方式不同：

用一个小任务完成过渡

合并应用安装后，在其中提及 @GitHub，按提示连接 GitHub 账号并选择仓库。新入口把 Teams 通知与代码代理关联起来：团队可以围绕问题发起调查和修复，代理创建拉取请求，后续由团队处理。

实际采用时，建议先选一个影响范围小、完成条件清楚的问题。例如明确某个页面在何种输入下出现异常，并说明希望恢复的行为。这个任务描述建议是团队使用方法，不代表公告承诺代理能自动解决任意缺陷。

把合并与上线继续留给团队审核

应用入口合并可以缩短协作距离，却不能代替变更审核。建议迁移负责人记录“使用哪个入口、关联哪个仓库、谁接手 PR”这三个事项；审阅者再按原有工程流程检查修改范围与测试结果，决定是否合并。

更新后会不会丢掉通知能力？公告明确原通知能力继续工作。是否需要等到旧应用退役当天再切换？建议提前安排小范围过渡，避免关键协作依赖单一旧入口。是否自动迁移所有仓库连接和订阅？公告没有作出这种全面承诺，应按合并应用中的连接提示处理。

参考：GitHub 官方 Teams 应用整合公告。