GitHub Teams App 整合通知與 Copilot：從問題通知開 PR，誰能授權改程式？
GitHub 於10月23日把 Teams 通知 App 與 Copilot 雲端代理整合，讓問題通知接成 PR。整理帳號權限、共用對話身分、討論脈絡保存、付費方案與11月16日舊 App 退役遷移。
GitHub 的問題通知已經送到 Teams，團隊也在同一串訊息裡討論原因，工程師卻還得複製背景、換個入口，再請代理開始處理。通知與實作之間，仍有一次人工交接。
GitHub 在 2026 年 10 月 23 日更新 Teams App，把儲存庫通知與 Copilot 雲端代理放進同一個入口，讓團隊回覆通知並標記 @GitHub，就能要求調查、測試或建立程式修改。
這次更新的重點是合併通知與工作入口，Teams 裡的代理協作先前已有提供；官方整合文件在本次查詢時仍標示公開預覽，使用也需要付費 Copilot 方案與相關管理設定。
同一段對話可以讓多人補充資訊，但誰能要求改程式、代理用誰的身分建立 PR，以及整串討論會留下什麼，都受到明確規則限制。PR 是把修改交給團隊審查的合併請求。
我的判斷是，已使用通知 App 的團隊值得趁這次整合整理交接流程，但應先確認資料範圍與儲存庫規則。舊版獨立 App 預定十一月十六日退役，也讓選對入口成為實際維護工作。
從一則問題通知如何變成待審修改開始，才能看清楚方便的聊天入口後面，哪些授權與審查仍留在原位。
GitHub 通知如何接成一項代理工作？
新 App 讓通知出現在頻道、群組或私人聊天後，團隊直接標記 GitHub，利用相連的問題與對話背景開始調查、修復或建立 PR。頻道是團隊共用的討論空間，一則通知下的討論串則保留針對該問題的來回訊息。
十月二十三日公告的例子，是問題通知抵達後，使用者請代理調查、修正並建立合併請求。團隊再審查、測試與合併，通知入口與程式交付因而連成同一條路徑。
以一個假設的登入錯誤為例，團隊先在通知下補充發生條件，再要求代理調查。代理便有機會利用相連問題及討論內容開始工作，減少工程師把背景重新搬到另一段對話的需要。
這次合併的是通知與 Copilot 入口，並非雲端代理第一次進入 Teams。新 App 延續通知功能，讓看到問題的人可以在原位置發起後續工作，較接近交接方式的改變。
代理接到任務後，會在雲端隔離環境非同步工作，完成時回報結果。非同步表示團隊不必守著同一個畫面等待，仍可以在討論串補充要求，或到程式編輯器接續處理產物。
對話交接縮短了，開始執行之前仍要知道它會修改哪個儲存庫與分支。
預設儲存庫與分支，如何避免把工作送錯地方？
連接帳號後，代理會依指定或預設儲存庫工作，未指定分支時則使用該儲存庫的預設分支。儲存庫是保存專案程式與歷史的位置，分支則讓一份修改沿特定版本開始。
因為團隊可能管理多個專案，這個選擇會直接決定工作送到哪裡。相似的錯誤名稱可能出現在不同產品裡，若只在聊天說「修好登入」，代理需要知道要讀哪個專案。
官方整合文件允許在提示裡明確指定儲存庫與既有分支。分支參數決定 PR 的起點，因此修正式版問題與修改下一版功能，可能需要不同目標。
在頻道中，也可以透過設定入口選擇預設儲存庫。若頻道尚未設定，文件說明第一次工作使用的儲存庫會成為該頻道預設，之後未指定時便可能沿用。
因為後續工作可能沿用這個選擇，頻道用途需要和專案目標對得上。若團隊把多個產品放在同一頻道討論，明確指定目標能減少依賴預設值的誤會，特別是通知並非每次都來自同一專案。
官方把頻道預設與私人訊息的規則分開，不能把頻道設定直接當成所有聊天共用的預設。開始工作時顯示的儲存庫、問題連結與狀態摘要，便是確認目標的可見線索。
目標選對後，還要分清參與對話與授權修改所需的權限。
群組裡誰能提供意見，誰能要求改程式？
對話參與者可以補充資訊，但觸發程式變更需要儲存庫寫入權限，訪客與外部協作者也有額外限制。寫入權限代表帳號被允許對該專案提交變更，並不會因為加入 Teams 聊天而自動取得。
這個區別很符合協作情境。客服可以說明使用者遇到什麼，產品經理可以補充預期行為，卻不代表每個能讀到問題的人，都能讓雲端代理替專案修改程式。
文件也限制工作區訪客與儲存庫外部協作者啟動或引導 Teams 裡的代理工作。這是這個整合入口的限制，不能只憑對方平常能參與程式討論，就推定他也能使用相同操作。
因此，討論串可以提供共同背景，授權仍回到連結帳號與專案權限。若代理無法開始，不一定是模型聽不懂任務，也可能是帳號、組織政策或執行能力尚未開啟。
權限文件也把一般通知整合與雲端代理的額外能力列開。顯示連結預覽需要讀取資料，而建立程式修改還需要內容寫入等能力，兩者的作用不同。
權限表還列出雲端代理啟動工作所需的工作流程讀寫能力。這使 App 從通知工具擴展成能發起執行的入口，管理者應依實際任務理解新增權限，而不是把所有授權都歸在顯示通知。
把這些權限按用途理解，比只看到一個授權視窗就全數同意更清楚。團隊要知道 App 是來呈現問題，還是也要代表它建立可合併的修改。
有權開始工作之後，代理建立修改時採用的身分，會影響後續審查規則。
私人訊息與共用對話，為何使用不同身分？
私人訊息可使用所連個人帳號權限，共用對話則以 App 身分建立產物，符合條件的規則集還會增加合併前批准要求。因為修改承接了多人共同討論，App 身分讓它不必被當成其中一人單獨完成的工作。
在私人訊息中，代理可以依個人帳號已具有的權限建立問題或合併請求。進入群組或頻道時，產物則由 App 身分建立，讓工作來源與共同討論的情境對應。
規則集是儲存庫管理者設定的變更條件，例如修改合併前需要幾人批准。官方說明，在原本至少要求一次批准的相關規則下，共用對話的 App 產物預設再多需要一次批准。
因為附加條件與原本的批准規則相連，不能擴大成所有 App 產物永遠多一關。團隊應對照自己已啟用的規則，判斷建立後要由誰完成審查，避免工作停在沒有安排接手人的狀態。
代理開 PR，團隊仍要做合併決定
PR 把修改內容、討論與檢查結果放到一起，讓團隊決定是否納入專案。代理產生程式後，原本的審查與測試責任仍然存在，不會因為要求從聊天發出就消失。
這也能接回 AI 程式驗收流程，分清模型產出、測試證據與人工產品判斷各自負責什麼，讓聊天入口不會縮短必要的驗收。
延伸閱讀：AI 程式驗收教學：人工審查、測試與逐步上線，各自能抓到哪些錯誤
如果原本專案要求測試成功與指定人員批准，團隊仍需讓待審修改走完那些條件。通知與代理合在一起提供較短的交接路徑，並沒有替管理者移除原本的合併規則。
身分與批准保留了責任界線，而代理取得的討論內容也需要同樣清楚。
整串討論如何成為脈絡，又會保存在哪裡？
官方文件說代理會把整個討論串納入背景，這些脈絡也會存入產生的工作產物，想縮小範圍可改開新串或私人訊息。這裡的範圍是工作所在的討論串，不代表整個頻道的所有資料都被擷取。
使用完整討論串的好處，是需求與先前嘗試能一起傳到代理。若成員剛說明某個修法不能採用，代理就有機會把這個限制一起考慮，減少重複提出相同方案。
但討論也可能含與程式工作無關的資訊。若有人在同一串混入其他客戶狀況，再要求代理建立問題或 PR，這些背景可能進入產物，所以發起位置本身就是資料範圍的選擇。
重新開串可以聚焦一項工作，私人訊息則能減少共用討論帶入的背景。這不表示私人訊息內容完全不會保存，而是讓這次交給代理的材料範圍更清楚。
持續修改時，代理會納入前一次標記之後的新訊息。團隊可以在同一串補充要求，讓討論與實作一起前進，但新增條件最好明確對應原任務，避免把另一項工作混進同一份修改。
它也能把對話轉成一個或多個問題，包含父子關係。若當下還不適合直接改程式，先建立可追蹤的工作項目，是保留討論結果的另一條路徑。
資料範圍決定後，團隊還要讓兩邊管理設定允許這條工作路徑。
付費方案、雲端沙箱與管理員要先開哪些能力？
使用需要付費 Copilot 與 Teams 帳號，雲端沙箱及代理政策也要啟用，Teams 管理者則須允許 App 與對話脈絡同意設定。雲端沙箱是代理在遠端執行工作時使用的隔離環境，讓任務不必直接跑在每位成員的電腦。
依二〇二六年十月二十六日查閱的官方文件，這個整合仍標示公開預覽，功能與條件可能調整。它所指的付費方案是程式開發用的 Copilot，不能直接拿一般會議助理的授權判斷能否使用。
對組織與企業成員，擁有者可能還要先啟用雲端沙箱與雲端代理政策。使用者即使已能在其他地方聊天，也不代表這條需要遠端執行工作的入口已獲准。
Teams 端則要讓應用程式政策允許 GitHub App。官方介紹頁另要求資源特定同意，也就是 RSC，讓使用者可以對指定對話授權 App 使用其背景，而非只靠一般安裝狀態推定可讀內容。
因為通訊工具接入與程式執行由不同政策管理，這兩邊設定都會影響工作能否開始。若只完成其中一邊，使用者可能看得到 App，卻無法順利開始程式任務。
團隊安裝 App 之後，成員仍須連接自己的帳號，並按提示選擇需要的組織與專案。安裝一次給團隊使用，與每個人已完成身分連結，是不同步驟。
這些前提成立後，已安裝不同舊 App 的使用者，才知道該更新原入口還是改裝合併版。
十一月十六日舊 App 退役前，團隊該整理什麼？
既有通知 App 可更新到新版，舊的 GitHub App 則將改名並退役，使用者應依公告切換到合併入口並重新核對帳號與預設目標。公告說，既有通知能力會繼續運作，並要求通知 App 使用者更新到最新版。
另一個舊 App 將改名為 GitHub (deprecated)，預定二〇二六年十一月十六日退役。使用這個入口的團隊，要安裝合併版才能繼續在 Teams 使用代理，不能只看名稱相似就以為已完成更新。
我會先確認團隊實際裝的是哪個入口，再檢查新 App 顯示的連結帳號、儲存庫與可用工作。這能把遷移工作落在真實通知與任務上，避免只靠安裝清單判斷完成。
若團隊原本也在評估 ChatGPT 的 Teams 工作入口，應按用途分開看。這次新整合的交付物是程式問題、雲端代理工作與待審修改，會接到既有程式儲存庫規則。
延伸閱讀：ChatGPT 進入 Slack、Microsoft Teams：@ChatGPT 與 Team Tasks 完整指南
遷移的成果應是通知、討論、程式修改與人工審查能接在同一條路徑。可以先選一則已知問題通知確認目標與權限，再決定是否發起代理任務，讓方便的入口也保留清楚的責任。
常見問題 FAQ
GitHub Teams App 需要付費 Copilot 嗎？
官方文件要求付費 Copilot 方案，組織也需啟用雲端代理與沙箱能力，不能只憑 Teams 帳號就開始程式任務。
同一討論串的人都能要求修改程式嗎？
提供背景與觸發程式變更的權限不同，後者需要儲存庫寫入權限，訪客與外部協作者也受到文件列出的限制。
合併版會自動合併 PR 嗎？
官方公告描述的路徑仍由團隊審查、測試與合併。代理建立 PR 是把修改送審，不等於已完成合併或正式部署。
