對話已轉成 GitHub 任務，但你不確定它是否用了正確的討論上下文或倉庫？
最快解法：先在小範圍、低風險任務試點，逐項核對預覽資格、身份、上下文、倉庫綁定與中斷恢復；不要把聊天執行成功當成程式碼可放行。涉及 Xcode 的交付，另以真實 macOS 環境驗證建置。
這篇適合準備從 Slack 或 Microsoft Teams 發起 GitHub issue、PR 或編碼任務的開發團隊，也適合管理 Copilot cloud agent、雲端沙箱與應用策略的企業管理員，以及需要處理長任務、切換倉庫與恢復流程的平台工程師。
最後更新於 2026 年 9 月 27 日；資格與功能狀態核對自 GitHub 9 月 25 日更新公告、Slack 接入文件及 Teams 接入文件。
啟用前：公開預覽資格與租戶策略
GitHub 在 2026 年 9 月 25 日公告 Slack 與 Microsoft Teams 的 Copilot 更新，並將相關功能列為公開預覽；公告亦指出，部分能力會分批推出。更新公告和各自的接入文件對可用資格的說明並不完全一致。不要從公告的一句資格描述推定整個組織都能使用；請以官方最新文件和你的租戶實際可見狀態交叉確認。
| 核對項目 | Slack 路徑 | Microsoft Teams 路徑 | 驗收判定 |
|---|---|---|---|
| 預覽與資格 | 對照 Slack 接入文件及租戶中可見的功能 | 對照 Teams 接入文件及租戶中可見的功能 | 文件口徑不一致時先記錄差異，不自行推斷資格 |
| 管理員與應用策略 | 確認 GitHub 應用和組織存取政策允許試點 | 確認 Teams 整合及 GitHub 組織政策均已核准 | 無法證明應用可存取範圍時，不連正式倉庫 |
| Agent 執行前提 | 核實目標倉庫是否可供 cloud agent 使用 | 核實目標倉庫是否可供 cloud agent 使用 | 依組織存取政策及雲端 Agent 防護設定確認 |
連線前也要確認雲端沙箱的前置條件與防護設定。Slack 或 Teams 提供的是任務入口，不代表雲端 Agent 已取得所有倉庫權限；可用功能、倉庫存取和管理員政策是不同層次，不能用「已連線」取代權限驗收。
首次連線：身份、執行者與目標倉庫
先記錄試點帳號實際連結的 GitHub 身份，再檢查它對目標倉庫和分支具有什麼權限。私訊與共享頻道也要分開測：頻道裡的發話者、連線的 GitHub 帳號、Agent 任務執行所依據的身份，不應被當成同一件事。
接著核對預設倉庫、目標分支及頻道設定。預設值只是方便操作的起點，不能假設每個新任務都會自動選到正確目標。用明確指定倉庫的低風險任務確認實際行為，並保留管理員設定和試點帳號的核驗紀錄。若工作流程需要區分沙箱與主機責任，可參考這篇雲端執行環境與 Mac 的責任邊界。
首個任務：討論上下文與產物溯源
Slack 與 Microsoft Teams 如何接入雲端 Agent？
依照各自的官方接入文件完成應用連線和必要授權，再從非正式或低風險倉庫建立代表性任務。Slack 和 Teams 的接入文件是操作依據；如果文件列出的選項在租戶介面中不存在，先確認資格和推出狀態，不要以猜測補齊步驟。
測試內容不要含敏感資料。Slack 任務要檢查附件和訊息連結是否如官方描述進入任務上下文；Teams 任務則核對圖片與轉傳內容的處理方式。不要只看 Agent 給出的摘要，要記錄原始討論位置、建立出的 issue 或 PR，以及產物是否回鏈到正確討論。
整段討論都會成為任務上下文嗎？
不要預設所有訊息都會完整、無差別地交給 Agent。官方更新說明了新的上下文能力，但你仍要在自己的租戶中確認哪些訊息、附件或連結實際出現在任務脈絡裡。尤其要把整段執行緒可能成為決策上下文的風險納入資料治理：參與者可能無意間加入憑證、客戶資料或未公開規格，因此試點頻道應先設清楚內容邊界。
注意：把「Agent 正確理解了其中一句訊息」和「整段討論都可作為安全輸入」視為兩種不同結論。前者要以產物回鏈驗證，後者涉及頻道資料治理，不能靠單次成功任務推定。
協作期間：倉庫切換、模型與 PR 歸屬
更新後的操作選項要逐項試，不要把介面變更直接當成穩定承諾。特別是模型切換後的選擇是否沿用到目前對話、Slack 預設負責人或倉庫等設定是否符合預期，都應在任務紀錄中註明實際觀察結果；若結果不清楚，重開一個隔離的測試對話再比對。
Teams 建立 PR 後，從 PR 頁面確認所屬倉庫、分支和源對話連結；Slack 也以相同方式核對 issue 或 PR 的歸屬。切換倉庫後，另開一項明確指定目標的測試任務，確認舊對話沒有繼續沿用先前倉庫。對 Copilot cloud agent 而言，任務建立成功只代表產物流程有進展，不代表程式碼已通過審查、確定性測試或合併門禁。GitHub 對雲端 Agent 行為與限制的說明也應納入你的審查流程。
中斷恢復：任務狀態與重複操作
在低風險任務中演練停滯、過期回覆、閒置後重新連線與倉庫切換，再按官方文件描述及租戶實際試跑記錄核對狀態。每次都保存可觀察到的計畫狀態、對話訊息和最終產物；文件沒有明確承諾的恢復能力，不要寫成保證行為。
對話中斷後，怎樣檢查是否重複執行？
先搜尋同一討論對應的任務、issue 或 PR，確認是否存在重複產物；再比對目標倉庫、分支和對話來源。若對話顯示閒置或回覆過期，先確認原任務狀態，再決定是否重送，不要只因聊天畫面沒有新回覆就再次派工。若發現舊倉庫的會話仍活動、產物無法對應來源，或狀態無法辨識，就暫停自動重試，保留記錄並由負責人手動處理。
擴大、限制或暫停：用證據決定範圍
完成試跑後，使用下列分支作決策，不以「大家覺得好用」替代驗收：
- 若預覽資格、管理員政策、GitHub 身份、倉庫權限、上下文來源、PR 歸屬及恢復紀錄都能核對，且任務可以人工審查與回退，才把試點擴到更多低風險倉庫。
- 若身份與倉庫可確認，但對話上下文或恢復行為仍有不確定性，就限制在非敏感討論和指定倉庫，保留人工派工與合併門禁。
- 若產物無法回鏈原討論、舊倉庫任務仍可能活動，或租戶資格與政策尚未確認，暫停擴大試點，先補齊權限與狀態證據。
- 若交付必須依賴 Apple 工具鏈，另行驗證真實 macOS/Xcode 建置、測試與產物流程；Xcode 建置系統文件可作為建置流程的官方參照，但 Slack 或 Teams 整合本身不等於提供 macOS 建置環境。需要評估遠端建置時，可參考遠端 Mac 與 Xcode 交付驗收說明。
對比評分可直接用狀態標記：通過代表有可查證的設定或產物；待補證代表功能可見但記錄不足；阻擋代表身份、倉庫、上下文或恢復狀態無法確認。只要有一項阻擋，就不要把該試點當成可自動放行的程式碼流程。
Slack 與 Teams 適合把討論接到 GitHub 任務，但雲端 Agent 沙箱不等於可驗收的 macOS/Xcode 主機：前者可能無法證明真實 Apple 工具鏈建置結果，也不能取代團隊對倉庫權限與合併的把關。若你只需要暫時測試整合，現有雲端流程可以先做低風險試點；若交付必須經過真實 macOS/Xcode 建置，租用 Mac 可避免把聊天任務環境誤當成建置驗收環境。你可先比較 MacPull 租用方案，再按專案需要決定是否使用；不需要 Apple 工具鏈的團隊，無須為 Slack 或 Teams 整合額外配置 Mac。