GitHub 在 9 月 25 日更新了 Slack 与 Microsoft Teams 里的 Copilot：聊天窗口不只用来描述需求，Slack 里的文件、附件和消息链接、Teams 里的内联图片、转发消息以及频道与线程历史，现在都可以作为 Copilot cloud agent 的上下文。同一批更新还带来可延续到整个线程的模型切换、建 issue 前的重复检测，以及一条容易被忽略的可靠性修复——Slack 里被替换掉的旧会话，不再能继续对原来的仓库动手。
把编码 agent 放进 IM，收益和风险来自同一个地方：上下文不再只由你在 IDE 里敲的那句话决定，而是由一整段对话决定。谁在哪个线程里说过什么、贴过哪张图、转发过哪条消息，都会进入任务的起点。这次更新的重点，正是把这件已经发生的事补上控制手段。
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。
发生了什么：上下文、控制、可靠性三组变化
按官方 changelog 的分类，这次更新分三块。
上下文更宽。Slack 侧可以读取受支持的文件、附件和消息链接；Teams 侧新增内联图片、转发消息的上下文，以及频道与线程历史。两边都会在创建 issue 之前检查是否已有相似的 issue，并在结果里带上指向产出的直接链接，同时保留一条回到原始对话的链，用于追溯。
控制更多。你可以为下一条消息切换模型，并且这个选择会在该线程余下的对话里保持；Slack 侧还可以设置默认的负责人与仓库。这一条的意义在于把"用哪个模型"从一次性的临时选择变成线程级状态——同一个线程里，负责人不需要每条消息都重新选一遍。
可靠性修复。长任务的状态展示更清楚，中断或过期的回复有更好的处理，闲置后的重连更可预期。Teams 侧修掉了频道线程历史丢失、重复回答、Teams 转换后的图片处理错误，以及用户自有仓库和大频道下的行为不一致；Slack 侧修掉了实现计划恢复、仓库选择器和 code channel 的问题。
完整工作场景：一条线程从对话走到 PR
设想一次线上告警。值班同学在 Slack 频道里贴出报错截图和一段日志文件，并 @GitHub 描述现象。旧流程里，Copilot 只能基于这段文字行动，缺的文件要在后续对话里补，环境信息靠人复述；现在截图、附件和消息链接本身就是上下文的一部分，agent 可以从这些材料出发给出实现计划。
接下来它会先查一遍相似 issue，避免在已有工单之外再开一条重复的；确认后建 issue，把 issue 链路和原始对话互相挂上，再往下写代码、提 PR。整个过程里，模型选择会在这个线程中保持，不用担心下一条消息被换回默认模型。这就是这次更新描述的完整链路。
为什么"仓库切换安全"这条修复才是重点
在被列出的修复里，有一条值得单独拿出来看：Slack 侧修复了仓库切换的安全性，被替换掉的会话"不能继续在旧仓库里行动"。这句话描述的是一个真实存在的风险场景——当同一个人在同一段对话里换了目标仓库，先前那条会话如果没有被真正终止，它可能继续对已经不相关的仓库执行操作。
IM 里的 agent 与传统 IDE 插件的差别正在这里：IDE 里的会话天然绑定在当前打开的仓库上，而聊天里的会话绑定在对话上，仓库是对话中途选出来的一个变量。变量被改掉以后，旧会话是否还在生效，必须由产品来保证，而不是靠用户记得去关掉它。
这一点在多人协作里会放大。一个频道线程常常有多人接力：值班同学先描述问题，负责人在几条消息之后接手。如果仓库或模型只被当成会话开始时的参数，接手的人就必须先推断上一个人选了什么；把选择挂在线程上，等于把这段隐含状态显式化，代价是它也可能被上一个人意外改掉，所以团队需要约定何时该新开一条线程。
同一组修复里还有一条更细的：Teams 侧在处理用户自有仓库时行为更一致。这些都指向同一个结论——把编码 agent 放进 IM 之后，权限和范围的边界要在"会话"这一层管理，而不是在"人"这一层。
限制与人接管点
先说可用范围。这个功能处于 public preview，面向 GitHub Copilot Business 与 GitHub Copilot Enterprise 方案的组织；它会使用现有的 Copilot 额度，并且可以通过已有的 Copilot cloud agent 预算来管理开销。部分能力仍在逐步放量，未必已经出现在每个工作区。
要用起来，需要管理员先出手：Slack 侧要先启用 Copilot cloud agent 策略、安装或升级 Slack 的 GitHub app，然后用户关联 GitHub 账号并在对话里 @GitHub；Teams 侧除了启用 Copilot cloud agent，还要启用 cloud sandboxes，再安装或升级 Microsoft Teams 的 GitHub app。也就是说，这不是个人用户能自行打开的能力，把 Agent 接入团队 IM 仍然是一次需要管理员批准的变更。
需要说明边界：这次更新与 Copilot app 的本地沙箱、OpenTelemetry 支持不是同一件事，后者属于 GitHub Copilot 周报里并列的其他变更，本文不把它们算作本文事件。
人需要接管的地方有两处。一是建 issue 前的重复检测是辅助判断，不是保证，标题与描述的最终合并仍然由人决定；二是模型切换会在线程里延续，多人共用同一线程时，一个人改了模型，后面接手的人默认继承这个选择——这属于需要在团队里先约定好的行为。
如何试用
- 管理员先在组织设置里启用 Copilot cloud agent 策略，再安装或升级 Slack / Microsoft Teams 的 GitHub app。
- 在 Slack 频道里 @GitHub 并附上文件或消息链接，观察 Copilot 是否把这些内容纳入上下文。
- 用一次重复需求测试查重：在有相似 issue 的仓库里提出新需求，确认它先做检测再决定是否新建。
- 在 Slack 里切换一次模型，然后在同一线程继续提问，验证选择是否延续。
信息来源
- GitHub Changelog，2026-09-25，Updates to GitHub Copilot for Slack and Microsoft Teams：github.blog
- GitHub Changelog，2026-09-25，GitHub Copilot weekly releases — September 21：github.blog
HiFox ：将 Agent 变成真正的队友
另外，我们也在思考，AI 如何从个人提效走进团队协作。
HiFox 是一个让人和 AI Agent 在同一个工作现场协作的平台：你可以像给同事分派任务一样指派 Agent，在任务看板中跟踪进度、查看结果，让 Agent 成为团队里的队友。
👉 立即体验 Hifox：https://hifox.com
AI Coding 交流群
如果你也在用 AI 写代码，或者正在研究 Cursor、Claude Code 这些工具，欢迎加入以下交流群。群里平时会聊一些 AI 编程的实际用法、开发工作流，还有各种新工具和新玩法。