如果你的團隊已經讓 Copilot 雲端代理（cloud agent）幫忙修 bug、補文件或準備 release，下一個問題會很快出現：這些由代理開出的拉取請求（pull request，PR）要怎麼從內部系統啟動、搜尋、審查，最後在發布摘要（release notes）裡保留清楚的責任線索？
GitHub 在 2026-05-13 推出給 Copilot 雲端代理使用的 Agent tasks REST API 公開預覽，讓 Copilot Business 與 Copilot Enterprise 使用者可以用程式介面（API）啟動雲端代理任務。2026-06-18 的兩個小更新補上同一個實務缺口：author:@me 搜尋會把 Copilot 代表你開的 PR 一起列出；自動產生發布摘要時，GitHub 也會把「要求 Copilot 開 PR 的開發者」和 @copilot 一起列出。
這件事看起來像署名細節，實務上會影響稽核、績效歸因與事故回溯。當代理開始從內部入口、排程或 migration 工具批次開 PR，團隊需要知道哪個人、哪個系統、哪個任務模板啟動了它，也要能用同一個搜尋或 release 流程找回來。
6/18 更新：作者搜尋與發布摘要都補齊歸因
GitHub 的作者搜尋更新說明：在任何 PR 搜尋裡使用 author:[username] 或 author:@me，會同時回傳真人直接建立的 PR，以及 Copilot cloud agent 受該使用者指示建立的 PR。github.com/pulls 的 Created by me 這類預設檢視也會自動納入代理建立的 PR。目前這項改動適用 github.com UI 與 GitHub Mobile；GitHub 公告說 REST API 與 GraphQL API 會在 2026-07-16 跟進。
同一天的發布摘要更新則處理 release 階段：自動產生發布摘要時，GitHub 會列出上次 release 後合併的 PR。現在如果某個 PR 是由 Copilot cloud agent 建立，發布摘要會把要求 Copilot 開 PR 的開發者列在 @copilot 旁邊。官方範例從「by @copilot」變成「by @monalisa with @copilot」。這項發布摘要歸因已對 GitHub 上所有 repository 與所有方案開放。
這對工程團隊有三個直接影響：
- 待審 PR 比較不會漏掉：工程師用
author:@me或 Created by me 檢視時，可以看見自己直接開的 PR，也能看見 Copilot 代開的 PR。 - 發布與事故回溯更容易追人：release manager 不必只看到代理帳號，可以追到原本要求代理執行的人。
- 內部自動化要補中繼資料：如果任務是從開發者入口或排程啟動，任務描述、觸發系統、發起者、PR 連結與發布摘要試跑（release notes dry run）都要留下來。
這些歸因更新讓 Copilot 代理 PR 更容易被找回與解釋，但不代表所有方案都能用 Agent tasks REST API 啟動任務；API 權限仍要回到官方文件與自己的組織設定確認。
Agent tasks REST API 到底做什麼？
Agent tasks REST API 讓你用程式啟動 Copilot 雲端代理任務。GitHub 在 5 月公告裡說明，Copilot 雲端代理會在自己的背景開發環境中工作，能修改與驗證程式碼，最後開 PR；任務啟動後，也可以透過 API 追蹤進度。
適合先試的場景集中在「範圍清楚、可重複、最後一定進 PR review」：
| 場景 | API 怎麼用 | 需要先設的邊界 |
|---|---|---|
| 批次 refactor 或 migration | 由腳本對多個 repository 逐一啟動任務 | 每個 repo 單獨 PR、限制檔案範圍、失敗時停止擴散 |
| 內部開發者入口 | 使用者填表後建立 repo、補樣板或生成初始設定 | 表單要記錄發起者、owner、預期驗證方式 |
| 例行 release 準備 | 排程啟動低風險整理、文件更新或 release notes 草稿 | 作者搜尋與發布摘要要保留人與 @copilot 歸因，PR 不可自動合併 |
| 安全修補與依賴升級 | 對已知 pattern 建立修補 PR | 先跑測試、授權掃描與安全掃描，再交給 reviewer |
任務越像工程 ticket，越適合交給 API。任務若需要產品取捨、資料庫遷移、金流、權限模型或法務判斷，就應該只讓代理產生草稿、測試或檢查清單，主要決策仍由人負責。
授權與方案：導入前先驗證自己的租戶
5 月 API 公開預覽公告列出當時支援的授權方式：傳統個人存取權杖（classic personal access token）、細粒度個人存取權杖（fine-grained personal access token）與 OAuth token。GitHub App 安裝存取權杖（installation access token），以及 Copilot Pro、Pro+ 使用者支援，在該公告中列為後續項目。
同時，GitHub 文件現在說明 Copilot 雲端代理適用於付費 Copilot 方案（paid Copilot plans），並可研究程式庫（repository）、建立實作計畫、在分支（branch）上修改程式碼，讓使用者檢視差異（diff）、迭代，準備好後建立 PR。
這裡要分清楚兩件事：
- 雲端代理能不能用：看 Copilot 方案、repository 設定與組織是否停用。
- 能不能用 REST API 程式化啟動任務：看 API 公開預覽的資格、token 類型、組織政策與當前文件。
所以不要只把 token 放進 CI secrets 就開始批次呼叫。先用一個低風險 repository 驗證：誰能產生 token、token 能存取哪些 repo、任務進度如何查、PR 由誰建立、發布摘要如何顯示、管理員是否能停用或限制。
和 GitHub Actions、Copilot app 怎麼分工？
GitHub Actions 適合執行明確流程；Agent tasks REST API 適合從系統端啟動需要理解程式碼的代理任務；Copilot app 則適合人類開發者在桌面工作階段裡陪同代理完成 issue、PR 或檢查項目。
| 入口 | 適合放的任務 | 不適合拿來做什麼 |
|---|---|---|
| GitHub Actions | 測試、lint、build、deploy、掃描、固定 release workflow | 要代理自行理解需求並改程式 |
| Agent tasks REST API | 內部入口、排程、批次 migration、低風險 release automation | 沒有 owner、沒有驗證、需要即時人類判斷的大型變更 |
| GitHub Copilot app | 從 issue、PR、失敗檢查或桌面工作階段開始的互動式代理開發 | 大量跨 repo 批次觸發或純後台排程 |
比較穩的架構是：Actions 負責觸發與 gate，Agent tasks API 負責啟動代理改碼，Copilot app 留給需要人類密切陪同的任務。若你正在整理 GitHub 上的代理工作流權限，可接著看 Agentic Workflows 安全檢查表；若重點是桌面工作階段與工具搜尋，可看 Copilot app GA 導入指南。如果你想從 CI 紅燈後的單一修補流程開始試，先用 GitHub Actions 失敗可用 Copilot cloud agent 一鍵修 釐清哪些錯誤適合交給代理。
任務模板要先寫清楚
API 的主要風險是任務描述太鬆、範圍太大、一次開太多 PR，最後審查者（reviewer）無法消化。建議每個任務模板至少包含：
- 目標與非目標。
- 可修改與不可修改的路徑。
- 單次任務最大檔案數或最大 diff 範圍。
- 必跑測試、lint、安全掃描或授權掃描。
- PR 標題、摘要、風險說明與未完成事項格式。
- 發起者、審查者、系統來源與任務 ID。
- 測試失敗、API 失敗、代理卡住時的關閉條件。
範例方向：
Upgrade usages of the deprecated internal logging helper to the new logger API.
Only modify files under packages/web/src and packages/shared/src.
Do not change business logic, generated files, migrations, billing, auth, or encryption code.
Run the related unit tests and lint.
Open one pull request with changed call sites, test result, unresolved failures, and release-note impact.
If tests fail for unrelated reasons, record the failure and stop instead of expanding the diff.這種寫法把代理限制在工程師能審的範圍內，也讓發布摘要與 PR 歷史能追到清楚脈絡。
7 天試點：先證明它沒有增加審查負擔
| 天數 | 要做的事 | 驗證重點 |
|---|---|---|
| Day 1 | 選一個低風險 repo，確認 Copilot 方案、雲端代理狀態與 API token 類型 | token 權限是否過大、是否能停用、是否能追任務進度 |
| Day 2 | 用已完成的小型維護任務重跑一次 | 代理是否產出可審查 PR，並避免製造更大的 diff |
| Day 3 | 加上 Actions 測試與掃描關卡 | PR 未通過關卡時不得進 release |
| Day 4 | 從內部入口或腳本啟動一個任務 | 發起者、系統來源、任務 ID 是否寫入 PR 或內部紀錄 |
| Day 5 | 測 author:@me / Created by me 檢視與發布摘要試跑（release notes dry run） | 代理建立的 PR 是否能被搜尋找回，發布摘要是否正確顯示開發者與 @copilot |
| Day 6 | 測 API 失敗、任務卡住、CI 紅燈與 PR 關閉流程 | reviewer 是否知道何時重跑、關閉或改由人工處理 |
| Day 7 | 回看 PR 大小、通過率、返工時間與審查者回饋 | 決定擴大、限縮到特定任務，或暫停導入 |
若你同時使用 Copilot Auto mode，也要把模型路由與成本回饋放進同一份紀錄。雲端代理任務通常比一般 Chat 更長，錯誤路由、工具權限與測試不足會被放大。
結論：把 API 當成會開 PR 的自動化入口
Agent tasks REST API 的價值，是讓 Copilot 雲端代理能被內部系統、排程與開發者入口啟動，進入可追蹤的 PR 流程。6/18 的作者搜尋與發布摘要歸因更新，則讓這條流程在待審、搜尋與 release 階段更容易看見人與代理各自扮演的角色。
Mason 的建議很直接：先從低風險、可回滾、可測試、可審查的任務開始。把 API 權限、任務模板、PR gate、CI、reviewer、author:@me 檢查、發布摘要歸因與停用條件一起設計好，再考慮跨 repo 批次任務。否則 API 會把代理任務變得更容易啟動，也更容易把審查負擔推到 release 前一刻。
參考資料
- GitHub Changelog：Copilot-authored pull requests now included in author searches
- GitHub Changelog：Generated release notes credit you for Copilot pull requests
- GitHub Changelog：Start Copilot cloud agent tasks via the REST API
- GitHub Docs：About GitHub Copilot cloud agent
- GitHub Docs：GitHub Copilot cloud agent