TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
GitHub Teams 整合 Copilot 代理：通知直接開 PR，審查留在團隊端
GitHub 在 2026 年 10 月 23 日把 Teams 裡的儲存庫通知與 Copilot 雲端代理收進同一個 App：在通知討論串標記 @GitHub 就能要求代理調查、修復並開出待審 PR。觸發修改需要儲存庫寫入權限，共用對話以 App 身分建立產物，規則集下還會多一道同意；通知不需 Copilot 授權，代理需要付費方案與雲端沙箱。舊版 GitHub App 將改名 deprecated 並在 11 月 16 日退役。
用 AI 摘要這篇文章：
GitHub 在 2026 年 10 月 23 日晚間 9 點 29 分（UTC，台北時間 10 月 24 日清晨 5 點 29 分）發布 changelog，宣布 Microsoft Teams 裡的 GitHub App 完成整合：儲存庫通知與 Copilot 雲端代理收進同一個入口。之後問題通知出現在 Teams 的頻道、群組或私訊時，團隊直接在通知下回覆並標記 @GitHub，就能要求代理調查問題、實作修復、開出待審的合併請求（PR）。約四十分鐘後官方又在 GitHub 社群討論區貼出配套說明，同一份公告也給出退役時程：舊版獨立 GitHub App 將改名為 GitHub (deprecated)，2026 年 11 月 16 日退役，用戶要在那之前換裝合併版，否則 Teams 裡的代理入口會跟著消失。
先把這則新聞的性質講清楚：雲端代理走進 Teams 並非這次才有。官方整合文件的版本史顯示，這份指南去年就存在，8 月 20 日的大改版將它推入公開預覽，當時還要求 Teams 用戶端先開啟開發者預覽才能安裝，這項前提已在 8 月 31 日解除。10 月 23 日真正換掉的東西是入口：原本只送通知的 GitHub notifications App 升級成同時能叫代理的 GitHub App，兩個舊 App 收斂成一個。
通知怎麼變成待審 PR：官方給出的三步路徑
官方公告的示範流程分三步：問題通知抵達 Teams，附帶通往錯誤回報的連結；使用者標記 @GitHub，要求代理調查問題、實作修復並開出 PR；團隊審查變更、執行測試，再決定要不要合併。公告同時點明這條路徑的適用範圍不只修 bug，實作新功能、擴大測試覆蓋、更新文件都用同一套。官方討論串還內嵌了一段示範影片，把通知抵達到 PR 開出來的完整過程跑過一次。
細節在官方整合文件裡。代理收到任務後，會拿通知連結的 issue 或 PR 加上整串對話當背景，在安全雲端沙箱裡非同步工作，完成時把結果貼回討論串。它的回應會列出工作儲存庫、issue 或 PR 連結、使用的模型與狀態摘要，讓發起的人當場核對目標有沒有指錯。之後團隊可以在同一串裡繼續標記補充要求，代理會納入前一次標記之後的新訊息往下修改；也可以到 GitHub 網站、終端機或慣用的程式編輯器接手它產生的工件。
不想直接改程式時，同一個入口也能把對話變成工作項目。官方文件寫明可以要求代理從 Teams 建立 issue，一次一個或一次多個都行，而且支援父子關係；適合討論已經收斂出結論、但還不適合動程式碼的場合。建立 issue 同樣會以整串討論當背景。
換句話說，這次整合縮短的是「看到問題」與「發起修復」之間的人工交接。工程師過去在 Teams 讀完討論後，要複製背景、切換入口、對代理重新交代一次來龍去脈；現在討論串本身就是任務說明。至於修改內容的品質，官方文件的態度寫得很直接：GitHub Copilot uses AI. Check for mistakes.（GitHub Copilot 使用 AI，請檢查錯誤。）。這句提醒背後的三條治理線，沒有一條因為入口變方便而跟著搬走。
三種 App 用戶三種待辦，授權分層才是前置成本
受影響的族群照官方公告可以分成三種，待辦各不相同：
- 原本就用 GitHub notifications App 的團隊：動作最輕，把 App 更新到最新版即可，官方明說既有通知能力會繼續運作。
- 原本用舊版 GitHub App 的團隊：有明確死線。這個 App 會改名為 GitHub (deprecated)、2026 年 11 月 16 日退役，官方要求這批用戶安裝合併版，才能繼續在 Teams 使用 Copilot。兩個 App 名稱相近，判斷自己裝的是哪個入口，要對照安裝清單裡的名稱，不能靠印象。
- 沒接任何 GitHub App 的團隊：不受這次變動影響。要不要採用是新的採購與政策決定，不存在被迫遷移的問題。完全不碰 Microsoft Teams 的 GitHub 使用者，同樣不在影響範圍內。
授權與政策層是真正的前置成本。官方討論串把分層講得很白：通知功能不需要 Copilot 授權；要使用代理，需要付費的 GitHub Copilot 方案（文件標示適用所有付費方案，例如每月 10 美元起的 Copilot Pro），而且所屬方案的雲端沙箱要處於啟用狀態。組織或企業成員可能還有兩道管理關卡：擁有者要先啟用雲端代理與雲端沙箱政策，成員才用得到。所以 Teams 裡看得到 App，與真的能發動代理工作，是兩件不同的事；導入前先盤點授權席位與政策開關，比急著試功能更省事。目前免費的 Copilot Free 與學生方案使用者，在這個入口同樣停在通知層，要發動代理得先升級到付費方案。
截至 10 月 27 日，這個整合在官方文件仍標示公開預覽（public preview），功能與條件都可能調整。
文件考古對照：公告與文件的安裝連結其實對不上
要看懂「換的是入口」，最有力的證據在 GitHub 開源文件庫的提交紀錄裡，整合指南的每個版本都有日期可查。把 8 月 20 日的大改版與現行版並排，代理的召喚語法、權限規則、沙箱機制幾乎一致，現行版只在回應細節多列一項「使用的模型」，8 月 31 日那次提交則移除了「Teams 用戶端需開啟開發者預覽」的前提。
這種穩定性對已經在用代理的團隊是好消息：要重學的東西很少，主要工作落在換裝與重新連結帳號，而不是重練整套操作。但並排也照出一個值得導入團隊留意的落差：公告要求換裝合併版 App，官方文件裡的安裝連結卻從 8 月 20 日以來從未更新，截至 10 月 27 日仍指向同一個商店頁，與公告內文給的連結不一致；文件最後一次修改停在 10 月 15 日，早於公告發布。依版本史判讀，文件連結指向的正是公告中將退役的舊版 GitHub App。要安裝合併版，以公告與其連結的官方討論串為準比較保險。
誰能發動、用誰身分、審查在哪：三條留在原位的治理線
入口變短之後，真正值得管理者與團隊看清楚的是官方文件裡的三條治理線。它們全部留在儲存庫與帳號端，沒有跟著聊天入口搬家。
發動權畫在寫入權限。官方文件明定：只有具備儲存庫寫入權限的人能觸發代理修改程式，任何對話參與者都可以補充意見；工作區訪客與儲存庫外部協作者則連啟動或引導代理工作都不行。這個切法很實際：客服可以描述使用者遇到的狀況，產品經理可以補充預期行為，但讓雲端代理替專案改程式的鑰匙，仍然只在具備寫入權限的成員手裡。若代理遲遲不動，問題可能不在模型聽不懂任務，而在帳號權限、組織政策或沙箱還沒開。
身分與審查跟著發起位置走。私人訊息裡，代理以你連結的個人帳號權限行動，開的 issue 或 PR 掛在你名下。群組或頻道這類共用對話裡，產物改以 App 身分建立，修改承接了多人討論，因此不會記在任何一個人頭上。審查強度也跟著身分變：在原本就要求至少一道同意的規則集（rulesets）下，App 身分開的 PR 預設再多需要一道同意才能合併，而且這項要求預設開啟。但書要看清楚：多出來的那道建立在「儲存庫原本就有同意要求」之上，原本不設審查關卡的儲存庫，不會因為 PR 來自代理就自動多一關。
討論串本身就是資料範圍。官方安全提醒值得逐字讀：代理會把整個討論串納為決策背景，而且這些內容會存進它產生的工件裡。好處是前因後果一起帶走，有人在同串講過某個修法不能採用，代理有機會一併考慮；代價是混進討論串的無關資訊，例如其他客戶的狀況，也會一起進入 PR 的脈絡。要縮小範圍，官方給的路徑是改用私人訊息或另開新討論串。發起位置在這裡就是資料範圍的選擇，交給代理多少東西，由你在哪裡標記它決定。
把三條線合起來看，這個整合對協作模式的實際改變是：參與問題討論的每個角色都離修復流程更近一步，但進入門檻的設計仍然把「討論」與「授權修改」分開。對導入 AI 代理已有驗收流程的團隊，這個入口可以接在既有流程前面，當成蒐集背景與發起任務的環節；還沒有驗收流程的團隊，先補齊審查規則再導入，會比先體驗功能再談治理穩當。
兩個容易把工作送錯地方的設定：目標指定與頻道預設
代理的工作目標有兩層來源。提示裡可以用參數明確指定，官方給的範例是 @GitHub Create a pull request to… 加上 repo=OWNER/REPO_NAME 與 branch=BRANCH_NAME。分支參數指的是既有分支，作為 PR 的基準；修正式版的問題與開發下一版功能，目標本來就該不同，這組參數就是拿來講清楚的。
沒指定時就落到預設層。頻道可以透過 @GitHub settings 設定預設儲存庫；還沒設定的頻道，最早在那裡發起工作時使用的儲存庫，會自動成為該頻道的預設。之後未指定儲存庫或分支時，代理就用頻道預設儲存庫與它的預設分支。官方也把私人訊息的規則分開寫：私訊不能套用頻道預設。多專案共用同一個頻道的團隊，值得在導入時就把預設儲存庫設好，或養成每次明確指定 repo 參數的習慣，避免名稱相近的問題被送進隔壁專案。
還沒確定的事，與這篇文章的回查時點
幾件事官方沒有講死。公開預覽狀態意味著功能與條件可能調整，這份文件 8 月底才剛改過一次前提，就是活生生的例子；11 月 16 日退役當天，舊 App 是直接停用還是先退到唯讀，公告並沒有細述。代理修改的實際品質取決於任務描述與儲存庫整備度，官方也沒有提供正確率之類的基準，文件頂部那句提醒就是全部態度。想反映使用狀況的團隊，官方把社群討論串開在公告下方，直接留言即可。另外，合併版 App 對既有通知設定的沿用只保證能力續用，個別通知選項要不要重新勾選，公告沒有逐一交代，更新後值得核對一遍。
時效上這篇文章有明確保存期限：距離退役日約三週，11 月 16 日前後值得回來對照官方 changelog 與整合文件，確認政策與入口沒有再變。已經在別處用 GitHub 代理的團隊，例如已經為代理整理過說明文件結構、或正在做多代理系統收編判斷的團隊，這次等於多了一個從訊息軟體直接發任務的起點；還在評估 AI coding 訂閱成本的團隊，可以併著 AI coding 方案額度與成本比較一起算授權帳。發動代理的入口越來越多，從實體快捷鍵到訊息討論串都算，入口選擇因此更該回到治理規則本身：誰能發動、用誰身分、開出來的 PR 要經過哪些人，這三件事在任何入口都值得先寫進團隊規範。
