GitHub Copilot Slack 還是 Teams？Cloud Agent 權限與協作流程比較

兩個整合的共同前提#

Slack 與 Teams 都是 GitHub Copilot cloud agent 的 public preview 入口，實際可用性仍受 Copilot 方案、組織政策、app 安裝和 cloud sandbox 設定影響。導入前先確認：

• 管理員已允許 Copilot cloud agent，且 cloud sandboxes 已啟用。
• Slack workspace 或 Teams tenant 已安裝 GitHub app。
• 使用者已連結 GitHub 帳號，並能存取目標 repository。
• 需要 agent 修改程式碼的人對目標 repository 具有 write access。
• 組織已決定 AI credits、sandbox 使用量和 pull request 審查責任由誰管理。

Slack 文件列出的功能包含研究、規劃、triage、修改程式碼、建立 issue 和 pull request；Teams 文件與 changelog 也以相同的 cloud agent 工作流為主。這些功能仍在預覽階段，啟用前要把「可以試用」和「允許在 production repository 觸發變更」分成兩個決策。

Slack 與 Teams 功能對照#

Slack：先看 thread 上下文與 Slack Code#

Slack 的重要邊界是 整個 thread 可能成為 agent 的決策脈絡。官方文件說，shared context 中的 Copilot 會使用整個 conversation，並把脈絡保存到產出的 artifacts；如果只想提供有限資訊，可以改用與 GitHub app 的 DM。這讓 Slack 很適合從事故 thread、bug 討論或設計辯論直接開始，但也代表不能隨便在原頻道貼入 secrets、客戶資料或不該進入 artifact 的內容。

當任務需要多輪規劃和 review 時，Copilot 可以建立專用的 Slack Code channel。團隊在該 channel 內查看 working repository、branch、狀態和產出，並讓其他成員加入、補充或停止 session。一次 code channel 只對應一個任務，完成後可封存；封存後歷史仍可檢索。

Slack 的另一個實務差異是 DM 與 shared context 的 agent 身分：DM 中的 agent 可以使用連結 GitHub 個人帳號的權限建立 issue 或 PR；shared context 則會用 app identity 建立 artifacts。若 repository ruleset 要求至少一次 approval，app identity 建立的 PR 可能需要額外 approval 才能合併。

Teams：先看頻道 repository 與會議脈絡#

Teams 的使用方式適合把 standup、incident room 或會議 chat 裡的 action item 直接交給 agent。官方 changelog 描述的流程是：在 channel、thread 或 DM @GitHub，由所有參與者加入脈絡和 steer；有 repository write access 的參與者才能觸發 Copilot 實際修改。

Teams 的 repository 邊界要在一開始設定清楚：public channel 可以設定 default repository，若沒有設定，第一次 session 使用的 repository 可能成為該 channel 的 default；DM 不使用 default repository。因此在跨團隊頻道或沒有固定 owner 的討論中，prompt 應直接寫出 OWNER/REPO 和 branch，不要讓 agent 依頻道名稱猜測目標。

Teams 也要特別確認組織管理者是否啟用了 cloud agent 和 cloud sandbox，並允許 Microsoft Public Developer Preview。即使 app 能安裝，政策或 sandbox 沒開仍不能把會議中的一句話直接變成程式碼變更。

權限、sandbox 與 PR approval 要分層檢查#

把「聊天整合」誤當成「新增一套超級權限」是最危險的誤解。導入前分三層確認：

1. 對話層：哪些成員能在 Slack 或 Teams 看見 thread、DM、code channel 與 agent 回覆？整個 conversation 是否包含不應送入 AI 的資訊？
2. GitHub 層：觸發變更的人對目標 repository 是否有 write access？app 能讀哪些 code、issues、pull requests、metadata，以及能否寫入 content 或 workflows？
3. 交付層：agent 的 PR 是否必須跑既有 checks、code review、branch protection 和額外 approval？誰負責在合併前檢查 diff、測試和安全影響？

Slack 與 Teams 都是在 secure cloud sandbox 中非同步工作，並可能消耗 AI credits；Teams changelog 另提醒 cloud sandbox 用量可以獨立計費和設置預算。不要用「只是聊天訊息」估算成本，也不要讓 sandbox 內的成功測試取代 repository 的正式 CI。

如果團隊已經在 GitHub Copilot app 內管理 client policy，也要把 app、CLI、Slack 和 Teams 的啟用邊界分開審查，可參考 GitHub Copilot app 的獨立存取政策。跨工具委派仍應維持 PR review 與檢查流程，這點和從 Linear 委派 cloud agent 的 draft PR 工作流 相同。

一個可重複的 Slack／Teams 委派流程#

不論入口是哪一個，先用同一份 prompt 結構降低 agent 猜測空間：

1
@GitHub 在 OWNER/REPO 的 develop branch 研究這個問題：<症狀與背景>
2

3
請先輸出：
4
1. 可能原因與要檢查的檔案
5
2. 不修改程式碼的驗證計畫
6
3. 完成條件與要執行的測試
7

8
只有在我確認計畫後，才建立 branch、修改程式碼並開 draft PR。
9
不要修改 secrets、部署設定或其他未列出的路徑。

接著依序做：

1. 確認 conversation 內沒有不應進入 artifact 的敏感資料。
2. 明確指定 OWNER/REPO、branch、範圍、不能碰的檔案與驗收條件。
3. 先讓 agent 回報研究與計畫；不要把第一個回覆視為已完成。
4. 有 write access 的成員才觸發修改，其他人負責補充脈絡和挑錯。
5. 在 GitHub 檢查 branch、diff、測試、Actions、dependency 變更與 PR 身分。
6. 依 repository ruleset 完成必要 review 和 approval，再決定是否合併。

怎麼選：按討論發生的位置決定#

可以用下面的判斷快速選入口：

• 選 Slack：問題通常從 Slack thread 開始，你需要 Slack Code 將長任務集中管理，或需要用 DM 限縮 agent 接收的上下文。
• 選 Teams：團隊以 Teams channel、會議 chat 和 Microsoft 組織政策為主要協作場所，需要把頻道 default repository 設定成固定工作區。
• 兩者都保留：不同部門使用不同聊天工具時，統一 prompt、repository write access、sandbox 預算、PR approval 和 GitHub review，不要讓兩套入口各自發明一種交付標準。

這個選擇不會替你決定哪個模型或 reasoning level 最適合；它只先把「在哪裡蒐集脈絡、誰能觸發、產出由誰審查」固定下來。若治理規則還沒有定義，先用測試 repository 導入，再擴大到 production codebase。

結論：入口可以不同，交付控制點要一致#

GitHub Copilot cloud agent 在 Slack 和 Teams 都能從對話開始研究、規劃、執行與建立 PR。Slack 的關鍵是完整 thread 上下文和 Slack Code；Teams 的關鍵是頻道 default repository、組織 preview 政策與會議脈絡。兩者都需要 paid Copilot、cloud agent／sandbox 啟用、repository write access、成本預算與人工 approval。

因此，先依團隊實際討論位置選入口，再用同一份 repository、branch、prompt、測試和 PR review 標準收斂風險。agent 能在聊天裡開始工作，不代表它可以跳過 GitHub 的權限、檢查與合併規則。

常見問題#