首頁大翻新，Agent HQ 上線！回歸微軟后，GitHub 不再是你認識的 GitHub 了？

編譯 | 核子可樂、Tina

在 2025 年，對 GitHub 來說，更像是一場“回歸之后的再出發”。

一方面，它不再是一家獨立運作的公司，而是更深地回到了微軟體系之中，與 CoreAI 綁定；另一方面，一位新加入的負責人，開始在這個節點上，為已經走到一半的變革給出自己的理解與方向——他就是剛從 Vercel 離職、以 V0 等產品聞名業界的 Jared Palmer。

在他走馬上任的同一時間點上，GitHub 正在對外釋放兩條同樣重要的信號：

第一條，是在 Universe 2025 上正式發布的 Agent HQ——把 Anthropic 的 Claude Code、OpenAI 的 Codex、Google 的 Jules、Cognition、xAI 以及自家的 Copilot 等第三方編碼代理，統統拉進同一個“任務控制臺”；

第二條，則源自一條頗具殺傷力的吐槽推文：“整個 GitHub 首頁幾乎完全沒用”。

這條由開發者 Rhys 發出的帖子，在 X 上收獲了 280 萬次瀏覽、約 2 萬點贊、1100 多次轉推、近 500 條回復和超 1200 次收藏，直接把 GitHub 首頁推上了“公審臺”。圍繞這條吐槽，GitHub 隨后完成了首頁重構：讓首頁不再是“大家隨手點掉的一頁”，而是承接任務、PR 與最近活動的真實工作起點。

表面上看，這只是兩個互不相干的產品更新：一個是多代理管理，一個是入口體驗優化。但結合 Jared 在這場采訪中的講述來看，這兩件事其實共同透露出一個非常明確的方向——

GitHub 正在重新定位自己在 AI 時代中的角色：從代碼托管平臺，走向開發者與智能體共同工作的統一中樞。

簡單來說，首頁改的是入口，Agent HQ 改的是底座。兩者共同構成了 GitHub 在 AI 世代的下一條主線：讓開發者與智能體在同一個統一環境中協同工作。為了更好理解 GitHub 在這一輪演進中的思路，以及 Jared Palmer 如何從 V0 的實踐走向 Agent HQ 和 GitHub 的平臺化愿景，我們翻譯并整理了他最近的一次公開采訪。

以下是采訪翻譯：

Swyx：說起來，您提到過想要重新設計 GitHub 主頁，能具體說說嗎？

Jared Palmer：我們團隊有認真審視，根據反饋做了改進，讓新版主頁得以落地。

現在的版本，在頁面最上方增加了一個“任務區”，會集中展示你當前要處理的事項——最近的 PR、待你跟進的工作，同時也保留了很多人已經習慣的“最近訪問倉庫”等信息。整體的信息結構做了比較大的重構，不再只是一個“裝飾性首頁”，而是一個你每天點開 GitHub 時，真的會用、會依賴的起點。

老實說，我覺得還有不少可以繼續打磨的地方，但這次的改版已經讓人眼前一亮了，我自己也為團隊感到非常自豪。當然，產品永遠沒有“完成”的那一天。接下來我們也希望能和社區一起，不斷迭代這個首頁。

Swyx：目前您同時擔任 GitHub 高級副總裁與微軟 CoreAI 副總裁，身兼兩職會不會讓您有別扭的感覺？

Jared Palmer：我才上任十幾天，還處于適應階段，不過目前來講算是一切順利。

Swyx：在加入 GitHub 之前，您曾經創立 Vercel 并打造 AI SDK，并擔任 v0.dev AI 副總裁。能不能聊聊這段經歷？

Jared Palmer：沒問題。整個 AI 項目發展理念的基本脈絡，就是從早期的單一編程智能體到如今為所有編程智能體建設活動空間。我覺得這也基本概括了 Agent HQ 的核心理念。

過去這兩年，我專注于構建 Vercel、v0 和 AI SDK，并在今年夏季休息一陣之后加入了 GitHub，前段時間又推出了 Agent HQ 等項目。

我們希望 Agent HQ 不單成為智能體的活動空間，更成為開發者的聚集地，成為我們構建的全新協作環境的運轉中樞。

用 v0 的經歷打造 GitHub？

Swyx：在 GitHub，您能實現哪些原本 v0 做不到的事情？

Jared Palmer：GitHub 這個平臺體量可觀，坐擁 1.83 億用戶，其中有開發者近 1800 萬。而 v0 不僅關注單一語言，更是聚焦特定框架與問題域，通過內置渲染器為特定場景服務。有些朋友可能還不了解 v0，這是一款由 Vercel 開發，類似于 Lavable 的氛圍編程工具，但主要面向 Next.js 應用的生成。這種聚焦度讓團隊獲得了更大的自由空間，如激光般直搗希望實際的核心目標。而在 GitHub，我們開始為所有語言、框架和開發者構建活動空間，因此視野也更為廣闊。這種指向性的差異就是最大的區別。

Swyx：您幾乎涉足了編程智能體的整個發展過程，那您自己在其間的成長軌跡又是怎樣的？

Jared Palmer：我在很多場合下都不止一次回答過這個問題，而每次回憶好像都會解鎖大腦中不同的記憶片段——所以咱們不妨就從記憶檢索機制聊起。

智能體的記憶機制就很奇妙，類似于閑逛時偶爾會發現新路徑的感覺。總之大概的過程是這樣：當初 ChatGPT 甫一問世，就給從業者們帶來了巨大震撼，堪稱是改變世界且增長迅猛的革命性產品。

回顧自己的履歷，我意識到自己其實很早就開始在 Vercel 涉足 AI 領域，但最早的時候公司根本沒有 AI 部門或者團隊，我擔任的是所有框架的工程技術總監，并通過 Turborepo 等內部開發工具協助 Next.js 團隊進行內部測試，驗證服務器操作的初始實現。

那會就有人提議：與其開發待辦事項應用，為什么不打造一套實驗平臺？我立馬覺得這事可辦，于是側重出了 AI 實驗平臺，也就是如今 AI SDK 的組成部分。通過對各家模型提供商和組合方案的研究，我為 AI SDK 找到了這樣的定位：專注于我們擅長的用戶界面領域，同時不干擾用戶的其他操作。于是我們先發布演示平臺，隨后正式推出 AI SDK。到 2023 年夏天，整個原型開發由此進入快車道，公司內部也達成了全面轉向 AI 領域的共識。

記得當時代碼執行功能剛剛上線——名叫 Inter Code Interpreter，也就是代碼沙箱解釋器。我看到這項功能后，立刻萌生出一種雄心勃勃的構想，意識到如果能以某種工具調用機制在 4000 個 token 的上下文窗口內實現以下功能：根據提示詞直接進行代碼解釋、渲染 UI 界面、生成文檔或者直接在聊天框內生成內容，那么開發體驗絕對會進入全新的時代。比如生成不同類型的交互界面，或許還能串聯輸出，比如把代碼解析的輸入作為下一條提示詞中的一部分之類。這個想法雖然瘋狂，但本質上跟工具調用并無區別。

隨著技術發展逐漸明朗，我們開始內部商議，到底該不該向代碼解釋功能開放數據抓取能力。雖然現在大家覺得無所謂，但當時為它提供網絡訪問權限確實有點可怕。最終我們決定放棄代碼解釋功能，只保留最酷炫的 UI 生成方案。這種直接用提示詞就能輸出界面的能力，堪稱是 v0 項目的頓悟時刻。

最早的 v0 記得是在 2023 年 9 月發布的，而且觀感上更類似于 Midjourney。時間快進到產品上市九個月，我們的小團隊用了三個季度才達成百萬級別的 ARR（年度經常收入）。隨著模型持續迭代，我們也先后嘗試過更多新模型，但不知道為什么，GPT-4 Turbo 始終沒法成功接入。在轉用其他前沿模型之后，我們最終開始自研模型。

繼續快進十個月左右，我們重新回歸聊天功能，終于讓模型能夠處理聊天任務。到這個階段，我們意識到重構的最佳時機已經到來，v0 也由此迎來新版。這時候項目的營收開始猛增，短短 14 天 ARR 就增加了百萬，又過 14 天再度增加百萬。

我們不斷精進優化，更重要的是期間我們始終專注單一技術棧和框架。那時候其他團隊都在嘗試通用編程智能體，而我們堅持只關注 Next.js 前端與 Shadcn，這也讓團隊得以聚焦核心。

公平地講，Next.js 的統治地位讓這種定位獲得了強大的吸引力。而我們對包括 UI 庫和組件在內的各種細節進行專注打磨，也帶來了巨大優勢。我們還開始與各大前沿模型實驗室合作，確保他們的模型獲得愈發強大的 Next.js 生成能力。而我們也把自己開發的后訓練框架與其他模型實驗室共享，并對所有數據進行嚴格處理，確保處于最優狀態。

Swyx：那你們有沒有討論過在 v0 當中融合不同模型的優勢特性？

Jared Palmer：那肯定是有的，包括到底該提取各種模型的最佳特性并集于 v0 一身，還是提供模型選擇器以幫助客戶自由切換。我們確實反復討論過這些方案，最終發現這兩種方式各有優劣。打造自研模型或者說復合模型的優勢，在于可以自由組合這些元素。另外值得一提的是，搜索模型和生成模型完全不同，二者本質上屬于兩個獨立的子系統。搜索模型可以完全獨立于生成模型運行。

所以我們現在的解決方案是，不提供模型選擇器，而是通過自研復合模型實現不同優勢的結合。我認為這應該是更好的方式，一方面是可以把成果作為產品進行品牌化推廣，另外也能把我們的業務跟前沿實驗室的發布剝離開。

再說說模型品牌化，這么做的優勢是我們可以跟模型提供商合作發布，把很多工作交給他們。但相應的問題是，我們能夠提出的計費上限也就是零售價了，沒辦法進一步營造溢價空間。

Swyx：就是說我們很難通過高質量的客服等方式擴大服務收費。這就是理想與現實之間的兩難——我們既需要建立可持續的業務模式，擺脫對模型實驗室的依賴；同時還要切實保證效益提升，并想辦法把二者整合起來。

Jared Palmer：是的。好在如今我們已經轉向 GitHub，專注走上了模型選擇的道路。我們手頭能用的不光有 Copilot，還有第三方 Claude Code、Codex 和 Cognition，包括現在的 Agent HQ，可以說是魚與熊掌兼得了。這種形式的效果非常好，也符合用戶的最終需求。

沒錯，我認為已經不適合在模型層上做切換了，雖然當初我們的 AI SDK 就是這么起家的。

現如今，模型與智能體必須緊密綁定，達到高度平衡的狀態。一旦使用泛型接口松散綁定，所有模型就會快速退化成最小公約數的水平。接觸過智能體的朋友應該明白我說的意思，智能體對于抽象概念的處理遠遠超過聊天場景，其對應的是包含計算運行時和文件系統的循環系統。

這里再談談我對 AI 智能體的理解。這事我跟很多同行爭論過，在我看來智能體本質上就是用？加上 for 循環編排的 API 請求。只是如今的編程智能體已經涵蓋更多功能，比如 SDK、沙箱環境、文件系統、工具調用等等，這已經構建起了獨特的智能體生態圈，我個人稱之為編程智能體領域。甚至我認為 Claude Excel 智能體在本質上也是基于 Claude Code——我不太清楚具體的底層實現，但若真是如此也在意料之中。

再就是 Skills 模塊，本質上屬于 MCP 的捆綁版本。它同樣高度依賴大語言模型，比如讀取用戶提供的 Markdown 文件，參考文件目錄內容再自由發揮。這其實就是一種文件系統，對吧？

掌控 Agent HQ 后，會設置怎么樣的發展路徑？

Swyx：是的，這種新形態的文件系統真的很酷。最近兩年編程智能體一路發展，您也親歷了整個過程。那從您掌控的 Agent HQ 入手，您希望這個項目未來如何發展、又從各種智能體中觀察到了怎樣的趨勢？

Jared Palmer：這是個好問題。我認為 Agent HQ 和 GitHub 需要協同進化。

微軟的一大優勢，就是善于把同類成果更緊密地結合起來，比如新成立的 CoreAI 部門。再就是把 Visual Studio Code、GitHub 和部分 Azure 服務整合為一體。對我而言，Agent HQ 最酷的功能之一，也在于實現工作流的無縫銜接與流暢體驗。從演示中可以看到，當在 Agent HQ 中發起任務創建 PR 時，只需單擊即可在 VS Code 中直接打開該 PR，這種體驗太棒了。

關于 GitHub 的未來發展，我希望能借此探索在哪些觸點上更自然地引入 AI——比如如何解決合并沖突、能否自動彈出操作界面等等。這就是我對 AGI 的理解——深度融合。一旦操作出現錯誤，我們總會遭遇本地環境無法正常運行、工具卻一切正常的窘境。所以每次執行推送時，我都希望能直接添加評論或者啟動任務來解決這類問題。

我設想的是一種無縫銜接的工作流，讓開發者無論是在移動端、Web 端、GitHub.com 還是全局編輯器中都能保持專注狀態。這也是我接下來半年左右的主要研究方向。

Swyx：那 Dev Containers 呢，你覺得這項技術會不會成為行業標準？我不確定 Dev Containers 是微軟還是 GitHub 搞出來的，我把它的本質理解為一種沙箱環境，也是 Docker 容器的輕量版本。VS Code 對它支持得很好，但在 VS Code 之外好像還不太普及。那你們自己會用嗎？

Jared Palmer：其實我們自己就是用一些 K8s pod。這個問題屬于對運行時的選擇啦，微軟內部在這方面標準上還在進行討論。

目前有幾個競爭方案，我們應該會在下個周期內找到答案。但你說得沒錯，Dev Containers 確實提供不少酷炫的功能：預裝 VS Code，帶文件系統，支持沙箱機制，兼容安全協議，還能直接對接 GitHub Enterprise，且支持隨時打包部署。這些優勢確實都很令人心動。在我看來，Cognition 和 Codex 等服務的首要痛點就是倉庫配置——這恰恰是 Dev Containers 和 Dockerfile 擅長解決的問題。先運行這個、再運行那個，之后配置這個，最終執行那個……這也太麻煩了。

我猜遲遲解決不了的難點，在于無法預知倉庫內容——比如開發者是否打包了 ffmpeg 庫之類。如果只是 Next.js 庫，那直接執行 pm install 就行。當然，這些都有辦法做特殊處理，但通用容器本身仍然是個挑戰。

話雖如此，我覺得自動檢測和預判之類的工作還是有空間的。很早的時候我就想開發一款開源框架自動檢測工具，可惜這個想法始終沒能在公司里成為共識。我當時一直覺得，這樣的工具不就該開源嗎？自動檢測本就是人人都需要的基礎功能。但話說回來，好像大家各自開發也不太好，把默認偏好技術棧統一起來才是正道。

Swyx：好的。那您還有其他比較關注的協議或者標準嗎？比如 MCP 今年的表現就很亮眼，還有其他像 A2A、ACP 這類有趣的項目。

Jared Palmer：MCP 系統規模確實龐大，特別是在數字化轉型領域，正在成為許多企業客戶的核心解決方案，并借此實現上下文擴展。

我們前陣子還發布了智能體定制化功能，用戶可以在 Agent HQ 中通過提示詞等方式針對不同任務定制智能體，再讓這些智能體集成多任務處理器等組件。從平臺角度看，這里的可擴展空間非常大，也讓我倍感振奮。

Swyx：咱們繼續討論 AI 的話題。在計算機視覺應用方面，起步階段大家都很興奮，后來卻發現速度慢還不夠準確，占用的計算量也很大。好在改進的速度也是肉眼可見的。

Jared Palmer：沒錯，目前的開源視覺模型對極端案例的支持還不夠好，似乎還有深入探索的空間。

Swyx：那在代碼生成領域，許多人正思考如何從開發者協同到代理程度更高的演進路徑——類似于 Claude Code 環境那種。就目前的情況看，下一步該邁向哪里？

Jared Palmer：簡單講，就是要做得更好。魔鬼藏在細節里，成功率從 90% 提升到 95%、98% 乃至 99%，難度會呈指數級增長。要完成這波轉變還有很多工作要做。98% 和 99% 的準確率其實差距很大，大到每位用戶都能感知到。

而且很多做 AI 產品的開發者可能沒意識到，大部分參與者其實活在幻想中，對自家 AI 產品的糟糕表現渾然不覺。他們不會去認真測量無錯誤會話數量、請求丟失率、響應速率這些指標。Vercel 就一直非常重視且持續關注這方面指標，我們會每三個小時匯總關鍵指標和數據，其中無錯誤會話指標尤其重要，也決定著智能客服這類多輪交互應用的生死。

我記得 2024 年時曾經發過條推文：智能體技術的真正成熟不僅要依賴更智能的模型，更要依賴基礎設施供應商的可靠性升級。這類服務跟數據庫更新這類持續性服務不同，各廠商之間性能也存在差異，不同運行時長就是造成不同網關產品成功的原因，因此 OpenRouter 這類產品才能大獲成功。畢竟可靠性問題迫使我們不得不經常切換供應商，借此回避停機。簡而言之，我們當時的情況有點像玩游戲：所有數據實時涌入系統，我們只能根據數據波動調整工作狀態，猜測第二天會不會突然就崩了。

這種模式幫了我們不少，我覺得其他團隊也該把數據驅動方法用起來。

但令人驚訝的是，數據分析類工具仍然相對匱乏——至今我還沒見到那種既能輕松生成精準分析結果，又能像添加 Slack bot 那樣輕松使用的解決方案。

整個分析領域似乎仍停留在 BI 時代，這真的很奇怪。這個領域到現在還沒被充分開發，所以我一直在關注轉變到底何時到來。

Swyx：我還有個好奇的點，編程智能體能否應用于非編程領域？您有沒有親自實踐過，具體做的是什么？

Jared Palmer：今年夏天，我幫我爸設計了一套工作自動處理流程。他手頭有一堆 Excel 表格，就是財會那個方面的東西。我試著把 Claude Code 套用上去，結果它用 Python 生成了幾個腳本，雖然有點小問題，但連我爸都覺得效果相當不錯，整個流程跑起來也相當順暢。

另外還有帶智能體的瀏覽器，也很有破圈的潛質。

Swyx：那您用過哪些 AI 代理瀏覽器？

Jared Palmer：我目前主要用 Atlas，但還是更喜歡 Arc 瀏覽器的垂直標簽布局。專業用戶需要面對多種業務場景，所以需要頻繁切換上下文。我自己就經常會打開上百個標簽頁，為此還專門開發了開源工具 Chrome Dump。它能把所有打開的標簽頁導出為匯總，把內容整理成 Markdown 再批量關閉。我一直覺得關閉標簽頁應該像寫 Markdown 一樣簡單，但 Chrome 在性能方面還是有問題。我還嘗試過用 Tori 框架開發，但 Tori 明確限制開發瀏覽器功能，就挺遺憾的。

Swyx：最后一個問題，您提到過 StackTips。這到底是什么功能，開發難度為什么那么大？

Jared Palmer：這個得慢慢解釋。跟 Facebook 打過交道的朋友應該都聽說過 Fabricator 這款工具。我們都很熟悉 PR 這個概念，編寫代碼、提交記錄、發起 PR，合并后繼續工作。但當組織規模擴大之后，我們會發現有些人對 Git 操作方式有著近乎信仰般的執著——比如總在強調 rebase 和 merge 的區別。有些人覺得重寫提交歷史實現線性整合更重要，也有些人認為該先創建合并提交保留分支結構。總之我雖然沒在 Facebook 工作過，但之前曾經認真研究過構建系統。

Facebook 不僅自研過 Buck 構建工具，還開發過韌性的文件系統——對，他們不用 Git，而是采用自己的 Mercurial。如今這些系統已經高度定制化，形成了一個緊密耦合的整體。

Facebook 也不采用 PR 機制，他們有自己的開發哲學。最貼切的比喻是：想象每個 PR 都只包含單次提交。這樣不僅可以對提交做拆分處理，而且還能重新進行堆疊。在后續修改時，可以將變更置于 stack 的早期位置，而這些 stack 的本質就是提交差異。在堆疊之后，可以隨意合并最新提交或者其中的任意提交，提供更優雅的工作流程。這對單體倉庫或者超大規模代碼庫來說簡直是絕佳方案。

更進一步思考，我們甚至可以左右 stack 中的哪些差異需要 CI 測試——當然，這需要配合更復雜的配置。比如根據提交信息篩選，或者直接跳過某些分支。這最終會形成分組形式的代碼 stack，對于代碼審查非常友好，也能更從容地更新 stack 中的不同部分，簡直太懂開發者的心思了。

目前市面上已經有幾款工具支持這種模式，其中之一叫 Graphite。

整個 GitHub 社區一直翹首期盼這樣一項功能，所以我也在加入 GitHub 之后把它當成了頭等大事。而在回顧調查之后，我發現 GitHub 內部早就做過多次嘗試，最早一次是在 2020 年，2022 年的那次嘗試已經有了頗為成熟的方案。當時大家嘗試把所有工作都在客戶端完成，并在 GitHub PR 之外引入“stack”這一全新概念，只是因為風險稍高而放棄了。當時的內部討論覺得這樣的變革幅度太大，不適合推出。

目前我們已經召開過幾次內部會議，努力將其納入規劃路線圖，也期待跟大家分享更多進展。總之像 GitHub 這樣體量的平臺，要想支持全新功能絕非易事——既要考慮平臺體量，也涉及 Git 的實現機制。但我們確實在積極探索。