GitHub Universe 2026 舊金山現場回顧：兩場主題演講聚焦智能體工作流與開源社羣

我會在未來幾天再寫一篇文章，介紹這些公告。這篇則聚焦於 GitHub Universe 這場活動，以及兩場重點演講。

目錄

• 我在三藩市分享的更新
• 變更背後的數字
• Copilot 應用程式
• 跨儲存庫的 Projects
• 工具之間的工作階段延續性
• Copilot Automations
• 審查及合併
• 較小型的平台更新
• 安全
• 企業存取權限及預算
• 重建 Git
• Octoverse：開發者如何使用這些工具
• 閉幕主題演講：開發者的樂趣與硬件
• 保護開源維護者
• DevOps 是 Agent 的先決條件
• 人類判斷與速度
• Chopin 與協作規劃
• 科學與新一代
• 閉幕致詞
• 我會帶回甚麼

我親身出席了在三藩市舉行的 GitHub Universe 2026。由闡述 GitHub 架構全面革新的開幕主題演講，到以開源社羣、維護者及開發者的樂趣為主題的閉幕演講，內容實在太豐富，單憑記憶根本無法完整吸收。我再次觀看了第一天的開幕主題演講和第二天的閉幕主題演講，並做了詳細筆記。

重看一遍，讓我把兩天的公告連繫起來。在 Copilot 應用程式中，Projects 協調跨儲存庫的工作，而 Fusion 負責選擇模型。Automations 會回應正式環境的訊號，程式碼審查會檢查結果，而 GitHub 正在重建支撐這一切的 Git 基礎架構。不過，閉幕演講提供了不可或缺的另一面：開源維護者如何保護儲存庫，避免遭受 AI 垃圾拉取請求轟炸；為甚麼 DevOps 的成熟度才是使用程式碼 Agent 的真正先決條件；以及協作式多人規劃如何取代各自孤立的單人提示詞。

我的體會是，GitHub 希望連繫整個交付流程，包括 Agent 寫程式碼之前的工作，以及它開啟拉取請求之後很久仍要處理的部分。作為技術主管，我關心的正是這個角度：功能如何部署至正式環境、由誰判斷是否準備就緒、如何保護維護者，以及平台需要具備甚麼才能支援這些工作。

我在三藩市分享的兩項更新

這趟行程也讓我有機會分享兩項自己一直在做的事情。除了主題演講中的公告，這些是我在三藩市分享的兩項小型 Copilot 更新。

第一項是我的 VS Code 擴充功能 Copilot Insights 5.5.0。我加入了 Model Costs 探索工具和 token 成本估算器，讓開發者比較模型費率，並瞭解不同選擇如何影響預計的 AI 額度用量。估算值與帳戶實際用量分開處理。在 Universe 聽到大量關於模型選擇的討論，令這個問題顯得格外切合當下：某個特定選擇對我手上的工作及所需使用的額度有甚麼影響？

在 LinkedIn 閲讀我最初分享的 Copilot Insights 更新。

我亦分享了自己獲得Microsoft Pro Badge: GitHub Copilot - Proficient。我平時不太會分享徽章，但這次獲得這枚徽章，我很高興。我欣賞它着重有意識、務實地使用 Copilot：進行不改變原有行為的重構、編寫能驗證有用事項的測試，以及減少花在重複性邏輯上的時間。這與我從兩場主題演講中得到的體會相呼應：成果仍然需要我們留意並作出判斷。

在 LinkedIn 閲讀我最初分享獲得徽章的貼文。

數據説明 GitHub 為何正在改變技術堆疊

Jay Parikh 開場時談到 GitHub 上的活動規模。平台現有超過2.25億名開發者；過去一年，每秒都有一名新開發者加入，這已是連續第二年出現這種情況。

2026 Octoverse 報告讓我們更全面瞭解這些活動：

統計期間值得留意：Octoverse 的統計年度由2025年10月1日至2026年9月30日。這些數字並非2026整個曆年的總數；Actions 工作數與 Actions 分鐘數亦是不同的指標。

活動量自1月起上升，並在6月前後急劇加快。GitHub 將這個時間走勢與更好的模型、更強大的 Agent 執行框架、可延續多日的持續工作階段，以及更多在雲端環境中執行的工作聯繫起來。

有一項比較值得留意：在今年建立的儲存庫中，設有 Agent 設定檔的儲存庫，平均提交次數是沒有設定檔的八倍。這項數據反映活動量，但有其侷限：提交次數不能衡量軟件是否實用，而沒有 Agent 設定檔的儲存庫仍可能使用 AI。

Jay 亦提到三個讓這些數字更有意義的項目：Ersilia 用於藥物探索的開源 AI 工具、OpenQuake 的地震危害及風險評估軟件，以及 Matt Pocock 的 AI Skills，讓用戶在不同編碼 Agent 之間分享指示。這些例子涵蓋科學研究，以至改善開發者日常使用的工具。

在 Copilot 應用程式中，從 issue 到可運作的軟件

Jay 描述了一種交付流程：同事的要求、程式碼變更或生產環境訊號，都可以在任何環節啟動工作。開發者負責確立方向和作出決定，Agent 則負責實作及驗證。他以速度、智能和質素三方面構想這個流程：高效完成工作、延續上下文和學習成果，以及在發布前找出缺陷。

Cassidy Williams 透過 GitHub Copilot 應用程式和一個咖啡店應用程式，具體展示了這個構想。

她的任務是開發 Coffee Passport 功能：顧客到訪不同地點、收集印花，集齊護照印花後即可獲得獎勵。在實作功能前，團隊需要釐清怎樣才算一次到訪，以及重複到訪時會怎樣處理。

這是開始示範的好地方。如果團隊尚未就規則達成共識，Agent 就無法實作正確的行為。

這款應用程式將 Agent 工作階段、議題、外部工具及專案工作整合在同一個桌面介面中。其工作畫布包括瀏覽器、終端機及自訂檢視畫面。Cassidy 示範 Agent 如何在瀏覽器畫布中與執行中的應用程式互動，以測試護照功能，然後在 VS Code 中開啟相關變更，檢查程式碼。

對我而言，實用之處在於實作與檢查保持連繫。可運作的預覽有助確認功能是否運作正常；差異內容仍須仔細檢視。

連接器將缺少的背景資訊帶入工作階段

Cassidy 透過已連接的服務取得需求問題的答案。Copilot Connectors 使用由 GitHub 管理、經驗證的 MCP 連線，讓你只需驗證一次支援的服務，即可在各個支援的 Copilot 介面使用其工具。

主題演講及公告資料提及 Slack、Work IQ、Sentry、Vercel、Netlify 和 Cloudflare 等服務。GitHub 亦強調更廣泛的生態系統，包括 Datadog 和 Figma。重點是在 Agent 執行工作的地方，取得需求、討論、部署資訊及生產環境訊號。

Connectors 目前處於公開預覽階段。它們適用於支援的應用程式、CLI、VS Code、流動裝置及雲端介面，但目前尚不支援在 GitHub Actions 上執行的工作階段，例如將議題指派給 Copilot。將它們加入現有工作流程時，這項分別十分重要。

Copilot Fusion 決定如何使用模型

Cassidy 接着詢問應使用哪個模型。Copilot Fusion 透過路由器和編排器處理這項決定，評估任務並選擇執行模式。

主題演講中説明的三種模式如下：

• 單一：由一個模型處理任務。
• 級聯：一個模型草擬答案，再由評審模型評估；系統亦可轉交能力更強的模型處理。
• 評議：其他模型檢視草稿，並根據它們的意見修訂內容。

你可以選擇投入程度：Standard、High 或 Max。Standard 適用於日常工作；High 會加入編排，以處理較大型的任務；Max 則優先採用更深入的推理。相比每次處理功能的不同步驟時都手動切換模型，這種方式對我更實用。

GitHub 表示，Fusion Max 在 Artificial Analysis Coding Agent Index 中取得 60 分，與 Opus 5.5 Max 相差不超過兩分，而成本只有一半，每項任務所需時間亦減少 40%。這些是基準測試結果，因此在假設能獲得相同節省之前，我會先在自己的儲存庫中評估同樣的取捨。

Fusion 説明文件亦説明，它會遵從方案及管理員的模型政策，並按使用的模型收費，而且本身不會啟動子 Agent。Projects 編排和模型編排是兩項獨立功能。使用付費 Copilot 方案的用戶，在 November 30, 2026 前可享 Fusion 模型費用 30% 折扣。

Copilot Dreaming 處理已過時的指示

第二次重看時，我想特別記下的一個細節是 Copilot Dreaming。

Cassidy 解釋，咖啡應用程式已由 Java 改用 SvelteKit，但部分指示仍描述舊有實作方式。Dreaming 提議透過 pull request 更新相關指引。她像審閲其他改動一樣檢視差異，亦展示 Copilot 根據她的偏好和團隊做法學到的記憶。Dreaming 示範約在 12:40 開始。

我喜歡這個例子，因為自訂指示需要維護。描述上月架構的指示檔，可能令 Agent 一直做錯事。透過可供審閲的改動提出更新，是處理這項維護工作的實際方法。

Dreaming 正處於公開預覽階段，並設有方案和模型限制：需要 GPT-6.1 Sol 存取權，不適用於 Copilot Pro 和資料駐留環境，而且執行時會消耗 AI 點數。指示檔的改動會以 pull request 提交；學到的記憶則可以自動更新。

Projects 協調跨儲存庫的功能開發

Burke Holland 接着介紹 Copilot Projects，利用 Fourth Coffee 的儲存庫開發一項功能，讓顧客只需輕按一下，就能再次訂購平日慣常選擇的飲品。

他將儲存庫加入作為背景資料，然後提供設計稿、一段 Slack 討論，以及一段與法律和合規團隊的 Teams 對話。由於這項功能涉及個人化，後者尤其重要。工作進行期間，他可以繼續加入背景資料，無須等待個別 Agent 工作流程完成。

Projects 提供一個協調器，負責協調一個或多個儲存庫中的 Agent，同時集中管理目標和背景資料。工作階段可以在本機或雲端執行，產生的 pull request 會顯示在專案概覽中。開發者可以追蹤進度，並調整工作方向。

示範內容亦不止於程式碼。Burke 展示了使用技能生成並儲存在媒體庫中的短篇宣傳影片，並介紹一項自動化流程，可在新功能推出時製作這些影片。這把實作工作與另一項通常需要另行安排的交付工作連繫起來。

Projects 在當日宣佈開放使用，並處於公開預覽階段。對於擁有多個儲存庫的團隊，集中檢視背景資料、工作階段和相關 pull request，讓這項功能有一個超越個別 Agent 工作範圍的專屬空間。

同一工作階段可在不同工具間延續

Damian Brady 的示範由一部手機開始。預先訂購功能在咖啡店關門前停止接受訂單，做法本來符合預期，卻沒有向顧客解釋原因。

他開啟 Copilot 工作階段，在雲端沙盒中修正問題，之後再於 VS Code 繼續同一工作階段。工作階段亦可在 Copilot 應用程式、CLI 和網頁版之間延續，因此切換介面時無須重新開始任務。

Jay 解釋，這使用的是同一套 Copilot 執行框架，目前已在 Microsoft 全面推出。他亦宣佈，開發者可以透過 Microsoft Foundry 使用這套執行框架建立 Agent。

Damian 提到自己時間和注意力有限，點出了實際限制。Agent 一旦有清晰方向，開發者便應能先處理其他事情，在需要作出決定時再回來。

自動化流程把正式環境訊號連接至可重複執行的工作

下一個示範由一個正式環境錯誤開始。咖啡網站的資訊按鈕傳回 500 錯誤，Damian 隨後在自訂畫布中開啟 Sentry 的詳細資料。

他可以建立 issue，或請 Copilot 調查。Copilot Automations 會將回應轉化為可重複使用的工作流程，讓工作流程可以手動執行、透過 API 執行、按時間表執行，或因應事件觸發。雲端執行代表即使手提電腦關閉，工作流程仍可繼續執行。

控制選項是示範的重要部分：選擇可用工具、允許自動化流程建立 pull request，但不授予合併權限，並設定 AI 額度上限。共享自動化流程讓團隊重用這套設定。

Damian 亦在一個訂閲儲存庫中展示了一組專用自動化流程。其中一個負責監察訊號並建立 issue；其他流程則負責分流 issue、透過螢幕截圖重現問題、實施修正，並根據原始要求驗證修正。

這種分工讓每個自動化流程各有明確任務，並產生下一個流程可用的輸出。公佈內容亦提到，自動化流程會從結果中學習，並提出改進建議供審核。自動化文件確認支援可自我改進的自動化羣組，以及可設定的工具和支出上限。對這些工作流程作出的變更，應與應用程式的變更一樣接受審核。

試行時，我亦會考慮現行雲端自動化要求：合資格的付費方案、私人或內部儲存庫，以及 AI 額度和 GitHub Actions 使用量。

審查與合併也必須跟上步伐

GitHub 表示，自 Copilot Code Review 推出以來，已找出 2 億項問題。在 Universe 大會上，GitHub 推出了 Code Review Max，並提供 Lite 和 Balanced，適用於需要更深入檢查的變更。

GitHub 表示，Max 在 ReviewBench 的高嚴重程度問題評測中取得最高 F1 分數。我關注的是快速審查可能錯過的缺陷，例如跨多個已變更檔案的相互影響，或細微的安全問題。以團隊過往的審查紀錄測試 Max，有助瞭解這種深入檢查在哪些情況下最有成效。

Damian 展示了 Copilot 在人工審查前，先審查一個咖啡服務 pull request。組織啟用付費使用功能後，即使組織成員沒有 Copilot 訂閲，也可使用 Code Review；目前此方式透過 GitHub.com 提供。審查可能會消耗 AI 額度和 GitHub Actions 執行分鐘數。GitHub 文件説明瞭審查級別和使用權限要求。

堆疊式 pull request 讓相關變更更易審查

Coffee Passport 的工作拆分為一組堆疊式變更：資料變更、服務端點，以及依賴這些項目的使用者介面。每個部分都可以分開審查，整組合併或按連續的一組合併時，則可由底層開始。

這讓審閲者可以查看較小的差異，同時仍能看清各項變更之間的依賴關係。當 Agent 能夠比一般人輕鬆審閲的速度更快地開發大型功能時，原生支援就格外重要。堆疊式 pull request 文件介紹了相關工作流程及 gh stack 擴充功能。Octoverse 報告指出，預覽版於 July 30 推出，截至 September 已有超過 264,000 名開發者使用。堆疊式 PR 於 October 6 正式推出，時間早於 Universe。

Agent Merge 協助 pull request 完成合併

Damian 回到他在手機上開始處理的修正工作，並啟用了 Agent Merge。示範中，Agent Merge 會在背景處理後續工作，例如審核意見、CI 失敗和衝突；符合要求後即可啟用合併。Agent Merge 示範約於 28:40 開始。

這補上了我認為 Agent 工作流程中的一個缺口：開啟拉取要求只是完成工作的一個階段。分支會持續變更、檢查可能失敗，審核者也會要求修改。Agent Merge 會處理這些後續變更，而工作何時可以合併，則由儲存庫檢查和合併權限決定。

目前 GitHub.com 的監察及修復工作流程涵蓋失敗的 Actions 檢查和合併衝突，但不支援來自分叉儲存庫的拉取要求及堆疊式拉取要求，並將自動合併視為獨立設定。若要期待整套流程可在無人看管下執行，我會先確認這些限制。

較小型的平台更新也值得在這篇回顧中一併介紹

Universe 公告頁面列出多項更新，與同一工作流程相關：

• \nGitHub CLI 附件：可重複使用的 --attach 旗標，讓用戶可將本機圖片和影片直接附加至議題、拉取要求和留言。透過終端機建立的工作，也可以附上問題重現影片或架構圖。
• \nIssue Artifacts：計劃、研究、連結和其他產出物都會保留在議題中，讓人更容易找到實作背後的考量。
• \n儲存庫拉取要求檢視：更新後的檢視畫面有助瀏覽待處理工作、瞭解其狀態，以及找出接下來需要處理的事項。

例如，CLI 附件工作流程支援附加多個檔案：

gh pr create \
  --title "Explain when order-ahead is unavailable" \
  --body "Adds a customer-facing explanation before the cafe closes." \
  --attach ./order-ahead-demo.mp4 \
  --attach ./order-flow.png

檔案儲存在本機後，Agent 產生的螢幕截圖或錄影便可成為審核證據的一部分，尤其是當它能展示修正是否符合原始要求時。

安全性必須納入 Agent 工作流程

Damian 示範了程式碼掃描發現項目，並向 Agentic Autofix 提供其位置、漏洞類型和修復背景資訊。指派某項發現後，系統便建立了一個附有建議修正方案的拉取要求。

較廣泛的安全性公告涵蓋工作流程的不同階段，從本機變更到安裝相依項目，再到推送程式碼。

用於調查發現項目的 Security 畫布

Copilot app 的安全性擴充功能會將程式碼掃描警示帶入 Security 畫布，用戶可在其中要求解釋、要求修正，並檢視產生的變更。它亦可在開啟拉取要求前審查本機變更。

擴充功能文件説明瞭兩項值得留意的分別：此功能目前處於公開預覽階段，而且顯示的是程式碼掃描警示，不包括 Dependabot 或秘密掃描警示。要求修正會變更本機工作副本；警示是否已解決，仍由一般審核和掃描程序決定。

AI Scan 將涵蓋範圍擴展至 CodeQL 以外

GitHub 展示了全儲存庫掃描，以及將待處理的發現項目指派給 Copilot；亦展示了 AI Scan 如何掃描 CodeQL 未涵蓋語言和框架中的拉取要求。

就拉取要求功能而言，文件列出的語言和框架例子包括 PHP、Shell/Bash、Terraform、Dockerfiles、JSP 和 Blazor。這些發現僅供參考，目前無法透過規則集強制執行合併要求。對於正規劃安全關卡的團隊而言，這是一項重要細節。

Push protection 可偵測非結構化機密資料

Damian 推送了一個包含機密資料的本機提交，並展示 AI 偵測如何在提交到達儲存庫前將其封鎖。這項功能把保護範圍擴展至非結構化機密資料，例如不符合已知供應商模式的密碼。

AI 偵測機密資料推送保護功能現正公開預覽。必須同時啟用推送保護及 AI 機密資料偵測。GitHub 的文件説明安全性授權要求及額外的 AI 點數消耗，這些都應納入推出計劃。

套件防火牆及可達性分析應對相依性風險

套件防火牆會在代理程式、開發者工具或 CI 執行器安裝惡意或高風險 npm 套件前將其封鎖。公開預覽會根據套件發布時間及惡意軟件安全公告等政策評估下載項目。

可達性分析會檢查應用程式程式碼至有漏洞相依套件函式的呼叫路徑，協助排列現有 Dependabot 警示的優先次序。目前支援 JavaScript 及 TypeScript 儲存庫，亦正公開預覽。

這項靜態分析會提供呼叫路徑供團隊調查，並協助排列修復待辦事項的優先次序。單憑可達性分析，既不能證明程式在執行時確曾執行，也不能證明漏洞可被利用，因此仍須根據嚴重程度及其他證據決定優先次序。

企業存取方式改變，但使用仍需預算

GitHub Enterprise 客戶現可使用 Copilot 功能，無需另購 Copilot 訂閲，並按所用 AI 點數付費。公告涵蓋 Copilot 應用程式、程式碼審查、自動化功能，以及更廣泛的 Copilot 功能。

公告中的推出詳情值得留意：新方式可透過 GitHub Sales 使用，自助服務稍後推出，而現有 Copilot Business 及 Copilot Enterprise 客戶可以保留原有方案，或在準備就緒時轉換。

更簡便的存取方式應有助推廣使用，而工具權限及 AI 點數預算則讓企業團隊可以控制使用量的增長。

重建 Git 是其中一項最重大的公告

Jay 承認，GitHub 在年內一度面對效能及可靠性問題。增長解釋了部分壓力，但他明確表示這並非藉口。

GitHub 表示，今年至今已增加四百萬個 CPU 核心、160 PB 高速儲存空間及 50 Tb/s 網絡容量。公司亦預計於 2027 年初完成更大規模的遷移，改用多區域 Azure 部署。

April Leonard 接着解釋，單靠增加容量並不能解決 Git 瓶頸。每個 Agent 工作階段都可以建立分支、讀取歷史記錄並推送變更。單是 9 月，開發者和 Agent 便產生了超過 70 億次提交。

幾乎所有儲存庫都已遷移至 Azure，但對大約 100 個最繁忙的儲存庫而言，數據中心之間即使相差 25 毫秒也會造成影響。初步改進將寫入協調方式由鎖定整個儲存庫，改為鎖定正在更新的分支。這令在不同分支工作的 Agent，寫入吞吐量提升至原來的三至四倍。

下一代架構遵循三項原則：簡化基本元件、分離儲存與運算，以及盡量減少協調。Azure Blob Storage 保存持久資料的權威來源。臨時服務節點會快取資料，並可按需求擴展。專用的複製日誌服務則負責處理仍處於關鍵路徑上的小型參照交易。

測試結果相當顯著：

• 5,000 個 Agent 以單一儲存庫為目標時，系統維持每秒 7,200 次寫入；GitHub 稱這是目前吞吐量的 180 倍。
• GitHub 在新架構上重播其最繁忙開源儲存庫 24 小時的流量，只用了一分鐘。
• 讀取負載測試工具本身先達到上限，新架構則尚未達到上限。

這些是已公佈的測試結果，並非對每個儲存庫的吞吐量保證。主題演講中有一段早期用戶分享，邀請了 OpenClaw 的 Peter Steinberger；GitHub 預計所有用戶會在 2027 年初前轉用新架構。

基礎設施工作還包括處理數萬億個 token 的 AI 閘道、提示詞快取及執行框架改進、增加 Actions 容量並強化控制平面、增設網絡邊緣站點、將舊有數據中心與 Azure 之間的回程網絡容量提升至四倍，以及 TLS 優化。主題演講錄影涵蓋了基礎設施部分，另有GitHub 的書面公告。

這就是早前示範所依賴的基礎設施。如果 Agent 把時間花在等待 Git、CI 或平台可用，協調 Agent 的效益就會大打折扣。

Octoverse 展示開發者如何使用這些工具

Octoverse 報告的其餘內容補充了背景資訊，我不希望在只回顧主題演講的摘要中略過這些內容。

Agent 越來越常負責產生初稿

到 9 月，超過 40% 的拉取請求以可偵測到由 Agent 撰寫的初稿為起點，高於 3 月的 17%。單是 9 月，這類拉取請求便約有 1.1 億個。

約 87% 由 Agent 初稿開始的拉取請求修改了多個檔案；未偵測到 Agent 參與的拉取請求則為 79%。兩週內合併的 Agent 參與拉取請求比例，從 2 月的 83% 升至 9 月的 90%；對照組則維持在約 86%。

Copilot 每月活躍用戶中，55% 使用 Agent 功能，高於一年前的 35%。雲端 Agent 使用量按年增長 230%，Agent 聊天則增長 85%。這些數字反映觀察到的工作流程，而對照組仍可能包含未被偵測到的 Agent 使用情況。

隨着實作活動增加，審查及安全活動也同步增長：AI 輔助審查及 GitHub Advanced Security 的使用量均增加超過 90%，而推送保護執行了 58 億次掃描，接近前一年的四倍水平。

模型選擇已呈多元化

9月，明確選擇模型的 Copilot 用戶中，有 61% 使用多於一個模型，較四個月前的 50% 為高。付費方案的開發者使用了 47 個不同模型，5月時則為 29 個；沒有任何模型佔符合條件請求的比例超過 25%。

報告按模型的預定用途分類列出例子：

每 100 個由開發者選擇模型的請求中，有 38 個交由通用模型處理，37 個交由推理與規劃模型處理，25 個交由輕量模型處理。這項分析不包括自動選擇及其他幾類流量；它反映的是使用情況，而非模型質素。

另外，63% 的付費 Copilot 開發者在 9 月至少使用過一次自動模型選擇。Fusion 背後的研究預覽版 Project HydraFusion，為近 60,000 個工作階段進行了路由。這有助解釋 GitHub 為何投資於代開發者選擇模型，同時保留明確選擇模型的功能。

增長遍及更多國家及行業

9 月開發者人數最多的十個國家和地區如下：

美國和印度的開發者人數各增加了超過一千萬，巴西則增加了 3.28 million。去年預測中列出的每個國家和地區，距離其 2030 年預測值的差距都已縮短至少 20%；美國已縮短 38.6%，印度則為 28.3%。

按向公開儲存庫推送的次數計算，排名前十的國家和地區依次為美國、印度、中國、巴西、德國、英國、南韓、法國、日本和加拿大。這與開發者總人數的排名不同。

新的行業分析採用 NAICS 對公開儲存庫進行分類。自 2022 年以來，採礦、建築、醫療保健和農業均大幅增長。在行政服務、採礦、醫療保健和農業領域，提及 AI 的儲存庫超過 40%，但可偵測到由 Agent 開啟的 pull request 不足 3%。建築領域中，約 25% 的儲存庫提及 AI，約 9% 有由 Agent 開啟的 PR。

分開呈現 AI 提及情況與由 Agent 開啟的 PR，有助呈現兩種不同的採用情況。報告中其他較廣泛的例子包括尼泊爾的災害警報、航天器軟件、研究工具，以及工業能源分析。開發者工具以外，也有不少實用軟件。

語言選擇亦可能反映 Agent 的預設設定

按貢獻者人數計算，TypeScript 仍然排名第一，其次是 Python 和 JavaScript。從 2025 年 9 月至 2026 年 9 月，三者的每月貢獻者人數分別增加了 3.62 million、3.23 million 和 1.82 million。Rust 的貢獻者人數增加一倍，是主要程式語言中百分比增長最快的。

GitHub 預測，到 2027 年 9 月，TypeScript 和 Python 的每月貢獻者人數將各接近 13 million。

報告亦提出，Agent 的預設設定可能影響語言選擇。在新儲存庫中，有可觀察到 Agent 訊號的儲存庫，以 TypeScript 為主要語言的比例為 35%；沒有此訊號的則為 24%。在我看來，這進一步説明使用 Agent 開始專案時，指定語言和架構限制的價值。

開源既提供基礎，也提供工具

Octoverse 將社羣及獨立項目，與單一供應商或產品主導的程式碼儲存庫區分開來。兩者的分別在於策略控制權，而非項目是否接受社羣貢獻。

以下是按貢獻帳戶增幅排列的完整增長最快名單：

參與度最高的排名綜合星標數、複刻數，以及提出拉取要求或建立問題的不同用戶數：

推理引擎、執行環境和社羣平台，與開發者直接使用的 Agent 和編輯器並列。兩者都依賴有人維護其他專案賴以構建的程式碼。

閉幕主題演講：開發者的樂趣、可改裝硬件，以及 AI 的人性一面

第一天聚焦平台架構、企業管治和 Git 吞吐量；Universe 2026 的閉幕主題演講則把話題帶回 GitHub 的起點：開源、社羣維護者，以及建構軟件的樂趣。

Martin Woodward 開場時，先提到 2026 年令人切身感受到的情況：新的前沿模型每隔幾星期便推出一次，各地的遙測數據屢創紀錄，開發者正感受到步伐急速。對於總覺得自己跟不上時代，他的答案很簡單：從實踐中學習。

可改裝的徽章，以及無人注視時展現的文化

這種實踐精神的核心，是每位與會者在三藩市佩戴的實體大會徽章。這款 2026 年徽章由 Arm 合作打造，是一件令人驚嘆的硬件：搭載雙核心 Raspberry Pi RP2350 Cortex 處理器，配備加速計、環境感測器、藍牙無線電，以及一個運行 MicroPython 的彩色屏幕。

Martin 分享了一段徽章背後的即興故事，令我印象深刻。2025 年大會期間，颱風吹襲一間零件供應商，加上全球供應短缺，屏幕延遲至活動前一晚才送抵。GitHub 工程師、經理和社羣成員沒有取消徽章派發，而是在三藩市辦公室通宵手工組裝電路板、焊接屏幕，讓與會者可以在早上 8:00 領取徽章。

正如 Martin 所説：「無人注視時發生的事，就是文化。」本週討論了各種企業功能和雲端規模，但以社羣為先的初創精神，仍是 GitHub 的獨特之處。

從網頁模擬到 Copilot app 中的 MicroPython

為了讓沒有硬件的與會者和收看直播的開發者也能參與，GitHub 發佈了完整的網頁徽章模擬器。這個模擬器由暑期實習生 Charlie Nicholson 製作；他運用模擬器框架和約 $95 的 Copilot 額度，打造出一個可在瀏覽器直接執行遊戲的模擬器，例如 Flappy Mona。

Martin 接着在 GitHub Copilot app 中展示這個徽章專案。他在連接徽章存放庫的即時畫布中展示了一款 Breakout 遊戲，並表示這是他用一個提示詞創作的。

這裏重要的技術細節不在於提示詞，而在於 harness。Martin 解釋，Copilot app 的畫布可以存取 MicroPython 偵錯環境，讓 Agent 檢視執行情況並為遊戲除錯。這樣一來，它便有了驗證循環，而不只是生成程式碼。

正如 Martin 所指出，這個緊密的驗證循環，正是 Agent 產生錯誤語法與交付可用軟件之間的分別。

舞台上的邊緣機器學習：在瀏覽器中訓練決策樹

Martin 接着展示 Breakout 示範，介紹一個邊緣機器學習應用：即使沒有機器學習專業知識，也能為徽章製作計步器。

他透過 Bluetooth 將徽章的加速計原始遙測數據串流至瀏覽器畫布。在台上，他即場收集不同動作狀態的訓練樣本：靜止站立、正常步行，以及手臂擺動、充滿「大型主題演講的氣勢」（他開玩笑稱之為「星期五剛把程式碼合併到 main 分支的人會有的步姿」）。

他利用以瀏覽器為基礎的訓練流程，根據加速計數據集訓練決策樹分類器，再透過 Bluetooth 將生成的模型直接部署到徽章韌體。徽章成功即時分辨真正步行與任意手勢。

這是一個有趣的示範，但也説明瞭一個實際要點：Agent 工具可讓開發者透過實驗涉足陌生領域，例如嵌入式邊緣機器學習。學習仍然來自收集數據、測試結果，以及瞭解其失效之處。

AI 壓力下的開源：維護者疲勞、低質素拉取要求，以及新的防護措施

主題演講接着轉向業界最棘手的討論：當編碼 Agent 令建立拉取要求幾乎不費分毫，開源維護者會面對甚麼情況？

Octoverse 報告指出，目前 GitHub 上超過 40% 的拉取要求，其初稿都是由 Agent 起草；3 月時比例為 17%。Martin 承認，雖然這種速度加快了原型製作，但也帶來令人頭痛的另一面：「這些 PR 並非全部都是好東西。建立內容比以往容易，不代表你手上的內容已準備好提交。有些只是壞主意，有些甚至稱不上是主意。你懂的，都是些垃圾內容。」

傳統上，開源之所以能運作，是因為編碼本身存在一定阻力。貢獻者提交程式碼前，必須花時間瞭解程式碼庫、熟悉專案文化、閲讀文件並遵循貢獻指引。這種阻力自然發揮了質素篩選作用。

編碼 Agent 大幅消除了這道門檻。如今，好心的貢獻者會使用 Agent，在數十個儲存庫提交拉取要求和流於表面的安全報告，卻沒有閲讀專案指引或核實修正內容。對開源維護者而言——他們大多在下班後義務付出時間——處理低投入的 AI 貢獻已成為令人疲憊、又沒有報酬的負擔。

維護者防護措施：WIP 上限、貢獻者豁免及 PR 權限

為了保障維護者，Martin 介紹了旨在恢復平衡的儲存庫控制措施。部分措施早於 Universe 已推出；最新更新則進一步靈活設定哪些人須受限制：

1. 每個儲存庫的進行中工作（WIP）上限：維護者可限制沒有寫入權限的用戶可開啟的拉取要求數量，鼓勵貢獻者先完成現有變更，再開啟另一項拉取要求。
2. 豁免資深貢獻者：10 月 28 日的更新允許按帳戶年期或過往已合併的拉取要求設定豁免。符合任何一項已設定條件，即可豁免該貢獻者。這項功能與暫時性互動限制分開。
3. 控制 PR 存取權限：自2 月起，維護者可以限制只有協作者才能提交 PR，或停用 PR。停用 PR 會隱藏 PR 分頁，包括現有的 PR；重新啟用後便會恢復存取權限。這不只是暫停接收新提交。

Martin 將這項政策變更的界線説得很清楚：

「開源代表可以自由檢視、改編和分享，而無須徵求許可。但這不代表可以把自己的意志強加於他人。」

作為一名同時管理內部共用程式碼和公開開源程式庫的技術主管，我認為這些控制措施早就應該推出。如果平台不向維護者提供保護自己時間的工具，他們只會選擇離開。

為何 DevOps 才是 AI Agent 的真正先決條件

缺乏引導的 AI 生成內容令維護者不堪重負，但主題演講展示了具備成熟營運流程的維護者如何有效運用 Agent。

Martin 認出台下的 Home Assistant 成員 Franck Nijhof，並表示該專案已合併超過 5,000 個 PR。他亦談到 GitHub 如何支援 Cloud Native Computing Foundation (CNCF) 生態系統中的 Copilot Agent。

Martin 講述了 Jorge Castro 分享的一個典型例子，內容涉及 OpenPrinting。OpenPrinting 的維護者對印表機驅動程式和通訊協定有深厚而專門的知識，但他們最主要的痛點在於基礎設施：管理容器更新、確保相依項保持最新，以及在多種架構上維護 CI/CD 管道。他提到，Hive 自動化框架在四個 OpenPrinting 程式庫中負責營運維護，讓領域專家可以專注於自己喜歡的驅動程式程式碼。

這個例子再次印證一個基本事實：擅長 DevOps 的團隊最有條件善用 AI。

為了讓人類開發者快速交付而建立的自動化檢查、嚴格程式碼檢查、整合測試套件和分支保護，正是自主 Agent 所需的同一套防護措施。若在沒有自動化測試或完善 CI 的程式碼庫中執行 Agent，它只會不斷累積未經驗證的變更。

Actions 仍然是驗證工作的支柱。根據已發布的 Octoverse 報告，在該報告年度內，Actions 每秒執行 1,440 項工作（每日約 1.24 億項），是上一年度的三倍以上。

純粹追求速度的極限：「為何稱之為工作」

Martin 談到把純粹的編碼速度視為唯一成功指標的誘惑：

他的意思是，只有在我們建構的東西正確時，更快交付才有幫助。我們仍然需要由人來理解問題、指導工作，並反思結果究竟令事情變得更好還是更糟。界定何謂良好仍然是工作的一部分；Agent 無法替我們承擔這份責任。

這種判斷也反映了開發者與模型的互動方式。遙測數據顯示，開發者並非只依賴單一前沿模型。在每 100 個由開發者選擇模型的請求中，25 個交由快速、輕量的模型處理（例如 Gemini 3.8 Flash、Claude Haiku 5.5 或 GPT-6 Luna），37 個交由推理模型處理，38 個交由通用模型處理。這些數字不包括自動選擇；它們反映的是請求所佔比例，而非所有開發者工作的分類。

選擇範圍亦延伸至編輯器介面。Copilot 的使用範圍涵蓋終端機、CLI、Copilot app、網頁、流動裝置、VS Code、Visual Studio、Eclipse 和 IntelliJ。繼 WWDC 上公佈消息後，原生 Copilot 整合亦已擴展至 Apple 的 Xcode。

GitHub Next 與 Chopin：重新思考與 Agent 協作規劃

Maggie Appleton 是 GitHub Next（GitHub 的先進研究與原型設計實驗室）的設計師兼工程師。她在閉幕主題演講中分享的內容，是其中最引人注目的環節之一。

Maggie 探討了每位使用編碼 Agent 的工程師都經歷過的問題：現時的 Agent 規劃方式並不理想。

她的批評針對四種具體的失效情況：

1. 多項選擇式盤問：規劃通常在小型終端機 CLI 或桌面聊天視窗中進行，令開發者不斷回答一連串多項選擇題。到第九條問題時，認知疲勞便會出現，開發者最終只會點擊「選項 A（建議）」——Maggie 稱之為憑感覺作決策。
2. 文字牆：問卷完成後，Agent 會吐出數頁密集的 Markdown 內容。閲讀大量技術文字令人疲累，細微的架構錯誤亦會被掩蓋。
3. 單人模式下的孤立：現時的 Agent 工作階段，是個別工程師與 LLM 之間私下的一對一對話。隊友看不到正在生成的規劃，也無法瞭解已接受哪些架構取捨。
4. 等到 PR 才徵求意見，為時已晚：由於工程師缺乏協作規劃工具，他們通常會讓 Agent 實作整個功能，再提交 pull request 徵求隊友意見。但到了 pull request 階段，整個開發週期已經太遲，才提出「我們真的應該開發這個功能嗎？」或「這是合適的後端架構嗎？」等問題。在已消耗 token 後才重寫或捨棄程式碼，純屬浪費。

Chopin 原型：多人協作畫布、主動研究與決策審計記錄

為瞭解決這個問題，GitHub Next 開發了Chopin，這個實驗性原型以作曲家 Frédéric Chopin 命名。

Chopin 重新構想了 Agent 規劃方式：多位開發者和智能 Agent 在同一份文件中協作，於即時協作工作空間共同工作：

• 共享情境：規劃畫布直接連接至程式碼儲存庫，並向整個團隊開放。多位工程師可以同時聊天、撰寫需求和完善規格。
• Agent 主動研究：Chopin Agent 不會被動等待指示，而是閲讀團隊的討論並預先判斷需求。Martin 和 Maggie 討論多人徽章遊戲應使用 Bluetooth 還是 Wi-Fi 時，Chopin 主動研究 Bluetooth LE 的傳輸距離限制，整理技術取捨，並生成行內資料流程圖，説明同步方式。
• 以視覺原型取代文字牆：討論用戶介面時，Chopin 會生成可互動、可點擊的模擬稿，展示不同狀態（例如動畫風景遊戲畫面，或大型無障礙計數器）。工程師可以在撰寫任何正式程式碼前，先點擊瀏覽不同狀態。
• 附有決策歸屬資訊的決策卡：示範把各項選擇記錄成決策卡。Maggie 或 Martin 選擇某個選項時，文件會記錄由誰在何時作出決策。若開發者兩個月後想知道為何選擇某個方案，記錄會指出可向誰查詢，並提供相關的規劃背景。
• 直接轉換為任務：團隊同意計劃後，Chopin 會把工作拆分為模組化實作任務，並開啟相應的拉取要求。

Maggie 和 Martin 隨後在各自的識別牌上玩協作式 10,000 步遊戲。兩人靠近後，示範成功達成共同目標，為一場探討規劃的討論帶來恰如其分、讓人親身參與的結尾。

對工程團隊而言，這種做法比各自孤立地向 Agent 發出提示詞健康得多。它讓軟件規劃回歸應有的樣貌：由團隊共同參與，Agent 協助研究和視覺原型製作，而人類作出並承擔決策。

科技以外的軟件：科學、低階系統與新一代

主題演講亦探討了開源實踐如何改變傳統商業軟件以外的領域。

專業、科學及技術服務業在 GitHub 上增至原來的五倍，成為核心科技以外增長最快的開源領域。研究儲存庫已悄然成為已發表學術文獻背後可供核實的記錄鏈。

為支援研究人員，GitHub 特別介紹原生引用支援（讓用戶可直接在儲存庫中使用標準學術引用格式），以及ORCID ID 整合，把軟件成果連結至經核實的研究人員身份。

GitHub Campus Program 現已涵蓋 60 個國家的近 2,500 所學術機構，並有逾 100 位活躍 Campus Experts 和 500 位校友協助學生掌握 git、AI 工具和開源。

Martin 邀請 Jocelyn Velarde 分享她投身開源的歷程。她是 UC Davis Neuroprosthetics Lab 的訪問本科研究員，也是 MLH 教練。

Jocelyn 仍在墨西哥蒙特雷讀高中時，便主動電郵聯絡 Tec de Monterrey 的 Dr. Miriam Alanis，並運用線性判別分析（LDA）機器學習，製作了一隻由腦電圖（EEG）控制的腦機介面（BCI）機械義手。

她目前在 UC Davis 參與「Brain to Voice」項目，解碼神經訊號，為 ALS 患者恢復即時語音。她專注的技術範疇是跨異構運算平台的低階系統工程，以盡量減低音訊串流延遲；這項工作需要深入理解硬件和系統。

她給有志成為工程師的人一些簡單實用的建議：訂立明確目標、尋找能提供支援的社羣（例如 Campus Experts 和 MLH），並勇於直接聯絡導師。

結語：故事由你書寫

最後的主題演講以一貫的黑客式玩味作結。Martin 把識別牌放進一隻毛絨「Ship It」松鼠公仔內，在台上訓練手勢辨識模型以偵測拋擲和掉落，並邀請觀眾參加即時滯空時間比賽。他在會場內拋擲 Mona、Copilot 和 Octocat 毛絨公仔，同時由識別牌追蹤滯空時間。

歡樂氣氛背後，Martin 想向開發者傳達一個嚴肅的訊息：

Martin 表示，AI 令我們更容易建立以往因缺乏時間或技能而無法開發的應用程式。他鼓勵我們擴大學習對象的圈子，突破認知界限，並透過實踐學習。創意、判斷力和品味，仍然需要由我們注入。

「在這個新時代，AI 不會撰寫故事。故事由你來寫。」

我從 Universe 帶走的收穫

Jay Parikh 在 Universe 開幕時表示，截至目前編寫的所有軟件，可能只相當於未來五年人類和代理程式所建構內容的 1%。Martin Woodward 則在閉幕時提醒我們，缺少人的判斷力和用心，單純加快建構速度，只會累積未經核實的粗劣內容。

在兩場主題演講中，Universe 2026 的真正主線並非代理程式正在取代開發人員，而是 GitHub 正在改進交付流程的每一個環節，讓代理程式輔助工程變得易於管理、可問責且可持續。

第一天介紹了技術工具：

• Copilot Projects 用於協調跨儲存庫的功能開發。
• Copilot Fusion 用於在推理、通用和快速級別之間處理多模型路由。
• 從頭重建 Git；據報一項測試中，5,000 個代理程式以一個儲存庫為目標，持續達到每秒 7,200 次寫入。
• Automations 和 Code Review Max 用於在發佈前發現回歸問題和安全漏洞。

第二天介紹了運作原則：

• 透過 WIP 上限和互動門檻，保護維護者免受自動化垃圾內容困擾。
• 認清 DevOps 和 CI/CD 的成熟度，是大規模部署代理程式的嚴格先決條件。
• 把規劃從私人的終端機問卷移到 Chopin 等多人協作畫布上。
• 以緊密的驗證循環和人類問責，確保交付品質。

對我自己的團隊和客戶而言，我帶走了一份明確的實施清單：

1. 使用 Copilot Projects 試行跨多個儲存庫的功能：選擇一項範圍明確、涉及兩至三個服務的功能。設定明確的 AI 額度預算和工具存取權，並從最初的議題開始，一直追蹤工作至審查和合併。
2. 擴大代理程式規模前，先加強驗證關卡：如果儲存庫沒有自動化 linting、合適的單元和整合測試，以及順利通過的 CI 檢查，就不要授予代理程式合併權限。OpenPrinting 的例子再次説明，部署代理程式時也必須一併考慮運作維護。
3. 啟用儲存庫防護措施：為外部貢獻者設定合適的限制，並按社羣需要設置豁免，以鼓勵專注的貢獻並避免維護者疲勞。
4. 讓規劃公開透明：不要再讓工程師透過私下的一對一 LLM 提示詞規劃複雜功能。使用共享規格、視覺原型和明確的決策紀錄，讓整個團隊瞭解正在建構甚麼，以及原因。

Fusion、Automations 和 Chopin 等工具會繼續發展，但工程主管的基本責任始終不變：界定何謂良好、建立安全防線，並確保每項進入正式環境的決定都能由人解釋。

感謝閲讀這篇文章，希望你覺得內容有趣！

歡迎追蹤我，以便在新文章發佈時收到通知 🙂