GitHub 于 2026 年 8 月 21 日宣布，新的 GitHub Copilot experience in Slack 开放 public preview。这次更新的重点，是把原本在 terminal、IDE 或 GitHub 界面进行的 agentic coding 任务，带到团队已经用来讨论工作的地方。用户可以在 Slack 对话中叫出 GitHub，让 Agent 从讨论内容接续到 issue、代码和 Pull Request。
在 DM、channel 或 thread 中，团队成员可以使用 @GitHub 查询 code 和 activity，也可以 triage、更新、创建或加标签到 issue。如果要处理更完整的工作，Copilot 可以调查问题、制定计划、在 secure cloud sandbox 中实现和验证，完成后开出 PR，再把链接带回 Slack。这让「说明问题」和「开始执行」之间的距离缩短了。
GitHub 也把异步执行放在这次体验的核心。Agent 可以在用户离开后继续处理，用户之后可以从 Slack 直接接续，或转到 terminal、Copilot app 和 IDE 查看结果。对于跨时区或需要等待测试的团队来说，这种交接方式比把所有工作绑在一次即时 chat 更接近真正的工作流程。
另一个新元素是 Slack Code，一个专门给 coding agent 使用的 code channel。团队可以在 channel 里跟进计划、查看 diff、审阅 HTML artifacts、提出修改，其他成员也可以加入、补充上下文、重新导向或停止 Agent。这种共享 session 把 Agent 由个人助手变成一个可以被多人观察和调整的工作空间。
在治理方面，GitHub 表示 shared sessions 仍受现有 GitHub permissions 和 controls 约束，issue 或 PR 会以 Copilot app identity 归属。管理员需要开启 cloud agent policy、安装 GitHub Slack app 和连接账户；功能目前只向 Copilot Business 和 Enterprise 客户公开预览，使用量也沿用现有 entitlement 和 budget。团队还可以要求额外的 PR approval，才允许合并。
这个安排的工程意义，是把 Slack 由「通知和讨论层」推近「Agent orchestration 层」。不过它不是把审批责任完全交给对话：权限边界、sandbox、PR review、停止操作和 merge policy 仍然决定 Agent 可以做什么。企业如果只把 Agent 加进 channel，却没有定义谁可委派、哪些 repository 可用、哪些 action 必须批准，工作流程仍然会失控。
GitHub 公告没有提供跨团队的完成率或生产力 benchmark，而且功能仍是 public preview。因此较合理的解读，是 Slack 正在成为 coding Agent 的一个入口，而不是已经证明所有开发团队都应该把编程工作搬进 chat。值得观察的，是 shared session 能否改善上下文交接、团队审查和异步协作，而不会增加噪音或重复操作。
这次更新最值得注意的地方，是 Agent 的工作单位开始由「一个人的对话」变成「一个团队可以共同管理的执行 session」。当任务由 Slack 对话开始、在 cloud sandbox 执行、以 PR 结束，AI workflow 的核心就不再只是模型回复，而是权限、状态、审计和人机交接如何一起运作。
