TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
GitHub Copilot 自動化開放共享，額度計費移交儲存庫
GitHub 在 10 月 28 日同日開通兩條團隊 AI 自動化路徑：共享 Copilot Automations 把個人雲端工作移交儲存庫共有，額度改記擁有者帳上、行動掛 Copilot 身分；Agentic Workflows 正式版把 Markdown 工作定義編譯成 GitHub Actions 設定。本文拆解適用方案、私有庫限制、審查負擔與費用責任。
用 AI 摘要這篇文章：
GitHub 在 10 月 28 日的 Universe 2026 更新潮裡，於台北時間晚間 11 時 30 分前後用兩則相隔五分鐘的 changelog 回答了同一個問題：團隊想讓 AI 自動處理重複工作，這份工作該放在哪裡。前一則公告宣布 GitHub Agentic Workflows 正式版上線；五分鐘後的另一則宣布共享 Copilot Automations 開始推出，把原本綁在個人帳號上的雲端自動化，交給整個儲存庫共同擁有。同日還有多則 Automations 更新，補上成本上限與自我改善機制，等於一天之內把「團隊級 AI 自動化」的兩條官方路徑一次鋪完。
先把結論放在前面：兩條路徑真正的分界，在於工作定義存在哪裡。共享 Copilot Automations 把定義放在 GitHub 雲端設定裡，換來的是儲存庫等級的擁有權、計費與身分歸屬；Agentic Workflows 則把定義寫成儲存庫裡的 Markdown 檔案，編譯成 GitHub Actions 的執行設定，沿用你既有的執行器與政策。方案門檻也畫得很開：前者需要付費 Copilot 方案、且只支援私有與內部儲存庫；後者對 GitHub Free 都開放，但預設引擎要另外的 Copilot 授權。下面把兩條路徑的事實逐一攤開。
共享自動化把四件事從個人身上換到儲存庫身上
Copilot Automations 的基本單位，是一段提示詞、一組觸發條件和一份可用工具清單，Copilot 在雲端自主執行，官方列的例子包括 issue 一開就重現錯誤、pull request 標記為 ready 時擷取變更截圖、監控工具偵測到生產事故就自動展開調查。問題出在它一直是個人資產：更新前的個人自動化，只有建立者看得到、改得動，用的是建立者的身分與 AI 額度。拿來準備自己的站會摘要沒問題，拿來撐整個團隊依賴的流程，就把風險綁在單一成員身上。
共享版本把四個歸屬一次換掉。誰看得到：有儲存庫讀取權限的人都看得到；誰改得動：有寫入權限的人都能編輯；額度記誰帳上：AI 額度改記到儲存庫擁有者，也就是組織，或個人帳號擁有者的 Copilot 訂閱；在 GitHub 上的行動掛誰身分：以 Copilot 的身分歸屬，不再掛在任何人名下。建立者離開團隊後流程照常運作，變更歷史也記錄了提示詞、工具與觸發方式怎麼演進。
兩個前置條件值得記住。組織擁有的儲存庫要跑共享自動化，管理者必須先啟用「允許由組織付費的 Copilot 雲端代理」政策，這道門檻的意義很直接：費用換人付，同意權就換管理者把關。另外，自動化可以在 github.com、GitHub Copilot 應用程式或 VS Code 建立，VS Code 端需要 1.144 版之後的版本並開啟對應設定。建立時要在類型欄選 Shared，這個類型事後不能改，個人用途要升級成團隊流程，只能重新規劃一個新的共享自動化。目前共享功能正逐步推向 Copilot Pro、Pro+、Max、Business 與 Enterprise 方案，公告也明說實際看到的時間可能不同。
共享之前先看三條界線：公開庫、版本控制與帳單
官方文件裡有三條界線，是判斷適用範圍的關鍵，也最容易在新聞摘要裡被漏掉。
界線一是儲存庫類型。Automations 只在私有與內部儲存庫提供，公開儲存庫不支援。換句話說，開源專案的維護者想讓 AI 自動分類 issue 或分析測試失敗，手上只有 Agentic Workflows 這一條路。
界線二是版本控制。官方文件直接寫明，自動化存在儲存庫內容之外，不會 commit 進 Git，不隨程式碼版本化，也不經 pull request 管理。它的變更歷史在 GitHub 介面裡看，審查流程因此與程式碼審查分家。還要留意工具的影響範圍：GitHub 工具只能在單一儲存內行動，但來自 MCP 伺服器的工具不受這個範圍限制，能碰到伺服器設定與憑證允許的任何地方，接外部工具前先盤點它連得到什麼。
界線三是帳單。每次執行都會啟動一個 Copilot 雲端代理 session，同時消耗 AI 額度與 GitHub Actions 分鐘數，分鐘數另外記在儲存庫擁有者帳上。額度上限可以在建立或編輯時設定：單次上限最低 30 AI credits、到量即停；每日、每週與每月上限則是擋下新的執行，不會中止已經在跑的執行。同日另一則更新還把觸發與工具整批補上：新增 24 個 GitHub 事件觸發（涵蓋 issue、pull request、討論與安全警示）、20 個 GitHub 工具（包括合併 pull request、重試工作流程執行）與自訂 MCP 伺服器工具，並開放從外部系統用 API 觸發。官方舉的例子，是讓 Jira 工單、Sentry 新 issue 或 PagerDuty 事故直接啟動對應的自動化。
同一則更新也讓自動化可以串接成多步驟流程。每個觸發條件多了「可由誰觸發」的選項，預設只有使用者的事件會啟動，改成使用者也加 Copilot 之後，另一個自動化開的 pull request 也能觸發下一關；再配合「自動化執行成功」「自動化執行失敗」兩個新觸發，就能把調查、修復、回報排成一條鏈。另外，自動化在工作中碰到缺工具這類問題時，可以對自己或其他自動化提出改進建議，維護者會收到通知，自行決定套用或駁回，官方同日也有以「從結果學習並自我改善」為題的獨立公告。
就連個人自動化，執行紀錄也是全庫透明
官方文件對兩種類型的差異有一份直接對照：
| 項目 | 個人自動化 | 共享自動化 |
|---|---|---|
| 誰能看到自動化本體 | 只有建立者 | 有讀取權限的所有人 |
| 誰能看到執行紀錄 | 有讀取權限的所有人 | 有讀取權限的所有人 |
| 誰能編輯 | 只有建立者 | 有寫入權限的所有人 |
| AI 額度記在誰身上 | 建立者本人 | 儲存庫擁有的組織或使用者 |
| 在 GitHub 行動的身分 | 建立者的身分 | Copilot 的身分 |
值得注意的是第二列：就算是個人自動化，執行紀錄對有讀取權限的人完全透明，提示詞、session 日誌與產生的變更都看得到。共享自動化則在審查上多一道保險：若儲存庫原本就要求至少一份 pull request 審查，共享自動化開出的 pull request 預設要多一份審查；管理者可以在規則集裡關掉這項額外要求，但在傳統分支保護規則裡關不掉。個人自動化這邊則沿用既有的審查邏輯，以建立者的身分行動，和本人自己開的 pull request 一樣不能自行審查通過。此外，為了降低提示注入風險，沒有寫入權限的使用者觸發的 GitHub 事件預設被忽略，外部貢獻者開的 issue 不會直接驅動 Copilot 行動；自動化開的 pull request 也不會自動觸發 Actions 工作流程，要等有寫入權限的人確認。這套設計與 10 月 26 日上線的輔助權限機制方向一致：讓模型參與審查與執行的同時，把最後的把關留在人的手上。
Agentic Workflows 轉正，工作定義就是儲存庫裡的一份 Markdown
另一條路徑的正式版，把工作定義放回儲存庫裡。Agentic Workflows 讓你用自然語言 Markdown 描述任務，工具把它編譯成標準的 Actions YAML，讓寫程式代理在 GitHub Actions 裡處理需要理解與判斷的工作，官方點名的場景是 issue 分類、CI 失敗分析、文件更新與測試撰寫。因為產物就是 GitHub Actions，你已經在用的執行器群組與政策限制直接沿用，不必另外重建一套管理方式。引擎可以選 GitHub Copilot，也可以換成自己的寫程式代理（例如照Claude Code 的組態方法接上）。
這個專案的成熟度有清楚的時間軸可以對照：2026 年 2 月 13 日進入 technical preview，6 月 11 日轉 public preview，10 月 28 日正式版。它是 GitHub Next 的開源專案，放在 github/gh-aw 儲存庫，採 MIT 授權，2025 年 8 月建立。正式版在 github.com 上對 GitHub Free、Team 與 Enterprise 開放，但要留意官方的附帶條件：用預設的 Copilot CLI 引擎驅動工作流程，仍然需要 Copilot 授權，平台開放與模型免費是兩件事。入門路徑官方也備好了：quickstart 指南帶你裝 CLI 擴充功能跑起第一條工作流程，GitHub Next 的 agentics 儲存庫提供現成範本，涵蓋 issue 分類、相依套件管理、程式碼審查與報表。
官方文件自己也把兩條路徑接在一起：about-automations 頁結尾就寫著，想知道「怎麼把自動化存成程式碼、用 pull request 審查、或換別的寫程式代理來跑」，請去看 Agentic Workflows。換句話說，Automations 與 Agentic Workflows 在官方敘事裡本來就是同一種需求的前後兩個答案，分別對應定義放雲端設定與定義放儲存庫檔案兩種管理方式。
正式版補上自架執行器、預算預測與五層防護
正式版相對 public preview 的增量，集中在部署與隔離兩端。部署端，新增 Actions Runner Controller（ARC）與 Docker-in-Docker 支援，可以把代理工作流程放到自架執行器上跑；模型面，清單已更新、可以逐工作流程挑選模型供應商，也加入依任務類型與難度調配的模型路由。隔離端，代理可以跑在 Cloud Hypervisor 或 NVX 微型虛擬機裡，並用 enclave 防止跨儲存庫工作流程的資料外漏。
安全設計是五層疊起來的：代理存取 GitHub 內容時遵守 integrity filter 規則；預設以唯讀權限執行；在代理工作流程防火牆（Agent Workflow Firewall）後方的沙箱容器裡跑；輸出經 safe outputs 流程驗證；最後由專責的威脅偵測工作掃描所有擬議變更，掃完才進入套用程序。「AI 產出的變更要先經另一道檢查」已經是這波代理工具的共同設計，Google 的 Elephant-Goldfish 讓另一個代理先審設計，走的也是同一條路線。
預算面，gh aw forecast 從實驗功能轉正，納入威脅偵測消耗的額度與每月區間，讓估算貼近實際帳單，但官方也提醒預測與帳單保證是兩回事。這個專案自己就是現成的使用案例：10 月 27 日上架的 v1.0.1 版，release notes 頁尾就掛著由專案自身的 agentic workflow 生成的紀錄，引擎 copilot、約 15 AI credits，版本說明文件本身就是代理跑出來的產物。
Accenture 的數字，當引句讀而不是當基準讀
正式版公告裡唯一的量化證言，來自 Accenture 策略、架構與創新團隊的資深經理 Ben Alton。他的說法是：團隊裡一位 lead 光自己的開發工作每週就省下約 29 小時；團隊量測的開發速度平均翻了一倍以上；AI 現在貢獻了團隊 91% 的 commits；生產環境錯誤從每天約 11,000 件降到 1,000 件以下；工程師可以同時推進四到五個工作項目。
這些數字的性質要放對位置。它是發布頁上的客戶引句：單一團隊、自我量測、沒有附方法學，也沒有第三方覆核。把它當成「這種工作方式可能長到什麼規模」的線索合理，把它當成導入預期的基準就超過了引句能承載的範圍。同一則引句裡「從需求到實作附驗證證據」的工作流程描述，比省時數字更能反映這套工具被用在什麼位置。
現在能做什麼，與三件還沒定案的事
判斷起點可以照管理現況走。團隊已經在 Copilot 付費方案裡、工作集中在私有儲存庫、想要的是把日常調查流程交給大家共同維護，那就等共享 Automations 推到自己的方案。上線後先挑一種事件試跑，建立時直接選 Shared 類型，並確認組織政策與 AI 額度上限都先設好。團隊已經用 Actions 管測試與部署、需要自架執行器或政策一致，或者專案本身是公開儲存庫，那就從 Agentic Workflows 的官方範本庫開始讀，gh aw add-wizard 可以直接把範本加進專案。
三件事目前還沒有定案。共享 Automations 的推出時程是漸進的，公告明說各方案實際可用時間可能不同，能不能用要以自己的方案頁面為準。AI credits 的單價與各方案內含量，兩篇公告都沒有載明，要往 Copilot 與 Actions 的計費文件查，估算時別忘了 Actions 分鐘數是獨立計的一條。Agentic Workflows 換用其他代理引擎時，模型費用與使用資格跟著各供應商的條件走，這部分由引擎供應商側自己規範。以上事實以 10 月 28 日的官方公告與同日文件為基準，共享功能的推出狀態與 gh-aw 的版本節奏，值得在一個月內回頭再看一次。
兩條路徑會並存一陣子，而它們的差別終究是治理選擇：你要讓 AI 工作的定義活在 GitHub 的雲端設定裡，由儲存庫付費、以 Copilot 的名義行動；還是讓它活在你的檔案裡，走你已經信任的審查與執行基礎。把這個問題答對，功能清單上的差異都是次要的。
