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 的核心就不再只是模型回覆，而是權限、狀態、審計和人機交接如何一起運作。
