跳到主要內容
maxstudioNews
產品DEV Community (Codex)約 9 分鐘

VS Code 推出獨立代理主機,讓 Claude 與 Codex 等 AI 程式碼助理執行更穩定

VS Code 1.129 版本引入了獨立的「代理主機」(Agent Host),讓 GitHub Copilot、Claude Code 和 Codex 等 AI 程式碼助理能在獨立程序中執行。這項改進解決了過去關閉 VS Code 視窗會中斷 AI 工作進度的問題,並支援多個視窗同時連接同一 AI 工作階段,提升了開發體驗與工作效率。代理主機透過標準化協議管理 AI 代理會話,確保狀態同步與持久性。

VS Code 推出獨立代理主機,讓 Claude 與 Codex 等 AI 程式碼助理執行更穩定
圖片來源:DEV Community (Codex)

當你將重構任務交給 GitHub Copilot、Claude Code 或 Codex 等 AI 代理時,它會開始一個漫長的處理過程,而你為了騰出空間關閉了 VS Code 視窗。直到今年夏天,這種做法都會中斷正在進行的工作,在舊的擴充功能主機路徑上依然如此。

過去,AI 代理在視窗的擴充功能主機內運行,正如 VS Code 團隊在其架構文章中所述,這「將代理的執行時間綁定到單一 VS Code 視窗」。VS Code 1.129 版本於 2026 年 7 月 15 日發布,引入了解決方案:代理主機(Agent Host),這是一個「專門用於運行 Copilot、Claude 和 Codex 等代理核心的獨立程序」。

隨後,九月份的兩個版本進一步允許該程序在其他地方運行。1.138 版本將代理會話置於本地 Dev Container 內,而 1.139 版本則將其擴展到 SSH、Tunnel 和 WSL 主機。當編輯器渲染代理的會話,而不是運行代理自己的命令列介面時,你所放棄的東西才是真正的重點。另一種相反的設計也存在,而我為自己的工具選擇了這種設計。

代理主機的文件簡潔而精確:「代理主機是一個專門運行代理核心並管理其會話的程序。」核心(harness)就是代理的運行時本身。根據架構文章,Copilot 核心基於 GitHub Copilot SDK 構建,而 Claude 核心則載入 Anthropic 的 Claude Agent SDK,並帶有一個將會話、工具和權限映射到主機模型的轉接器。

編輯器視窗不直接與代理通訊,而是透過代理主機協議(Agent Host Protocol, AHP)與主機通訊。AHP 是一個開放的 MIT 授權規範,它將自己描述為「AI 代理會話的同步多客戶端狀態」。架構文章稱其為「狀態優先」:主機將核心事件轉化為「持久、可顯示的狀態和有序的 Redux 式動作」。

訂閱的客戶端會獲得當前狀態的快照,然後是動作的有序串流。如果客戶端斷開後重新連接,它會重播錯過的動作。這是協議首頁上的一個訊息範例:{ "channel" : "ahp-chat:/demo" , "action" : { "type" : "chat/activityChanged" , "activity" : "Waiting for input" }, "serverSeq" : 1 }。

其中 serverSeq 是重要的欄位。主機為每個變更標記一個單調遞增的序號,並廣播給所有訂閱的客戶端,這樣兩個渲染相同會話的視窗就能同步到相同的狀態。

同一頁面也顯示了諸如 chat/turnStarted、chat/toolCallStart 和 chat/turnComplete 等動作。傳輸方式取決於主機的運行位置。根據文件,VS Code 在本地 IPC 中使用訊息埠,並透過 WebSocket 使用 AHP JSON-RPC 進行遠端連接。

主機可以是本地的公用程序,也可以是另一台機器上的獨立伺服器,透過 code agent host 啟動,文件也提到了 --tunnel 選項。

會話的生命週期超越視窗。文件明確指出:「當專案視窗關閉後,只要代理主機仍在運行,活躍的 AI 處理過程就能繼續。」對比同一頁面上的擴充功能主機路徑,視窗擁有會話,因此「關閉視窗會停止正在進行的工作」。

多個視窗,一個會話。1.129 版本的說明指出「同一個會話可以同時從多個 VS Code 視窗連接和渲染」,並且該主機正在推廣到編輯器視窗和代理視窗。代理主機上的代理也獲得了列出、讀取和創建會話的工具,以及向其創建的會話發送訊息的功能,這總會要求你的確認。

專案自己的工具鏈。當 chat.agentHost.devContainer.enabled 開啟時,具有支援的 Dev Container 配置的資料夾會在代理視窗中獲得一個「使用 Dev Container」動作,並且會話會在該容器中運行(1.138 版本)。這需要安裝 Docker。

在 1.139 版本中,相同的動作適用於 SSH、Tunnel 和 WSL 主機上的專案,只要遠端資料夾具有 Dev Container 配置且遠端主機已安裝 Docker。這兩個版本都表示該功能正在逐步推出,因此你的設定可能預設為關閉,且文件將 Dev Container 支援標記為「實驗性」。

更快的簿記。1.139 版本將會話元數據移至中央目錄。根據發布說明,對於大約 645 個會話,啟動後的首次列出時間從 1.3 秒縮短到 0.1 秒。政策執行。在 1.142 版本(10 月 14 日),當組織設定受管權限或開啟 sandbox.enabled 時,VS Code「要求代理主機中的 Copilot 核心用於完整的聊天會話」,以便強制執行這些政策。

同一版本也開始將 Copilot 核心作為新會話的預設選項推出,並引導需要沙盒化命令的 Windows 用戶使用代理主機會話。如果你想嘗試,發布說明中提到了這些設定:// settings.json { "chat.agentHost.enabled" : true , "chat.agents.claude.preferAgentHost" : true , "chat.agentHost.codexAgent.enabled" : true , "chat.agentHost.devContainer.enabled" : true }。

代價是,你所看到的是轉接器呈現的代理視圖,而代理的某些部分並不符合這個視圖。代理自己的介面是首先被犧牲的。主機上的 Claude 透過 Claude Agent SDK 運行,其底層仍運行 Claude Code 引擎。Anthropic 的 SDK 命令文件劃定了界限:你可以分派「無需互動式終端即可工作」的命令,而諸如 /theme 和 /terminal-setup 等命令不會出現在會話的命令列表中。即使你發送了這些命令,SDK 也會回應「在此環境中不可用」。

該 SDK 也需要額外下載。根據 1.138 版本,Claude 和 Codex 代理「依賴於未隨 VS Code 提供的 SDK」,首次需要時才會獲取。VS Code 的某些自身功能也無法繼承。第三方代理文件列出 Canvases 功能不支援 Claude 和 Codex。

主機上的 Codex 核心被標記為實驗性,透過 Copilot 訂閱使用它需要 Copilot Pro+,另一種選擇是使用 ChatGPT 訂閱登入。當 1.142 企業政策生效時,「Claude、Codex 和終端聊天功能將不可用」。

還有生命週期問題。架構文章指出:「對於本地會話,VS Code 必須保持運行,因為它管理本地代理主機。」對於遠端會話,文件告訴你必須保持遠端機器和提供會話的程序運行,並指出重新連接並不意味著主機關閉期間工作會繼續。架構文章還稱實作和規範「正在積極開發中」,並仔細界定了 AHP 的範圍:它標準化的是面向客戶端的會話模型,而不是代理如何推理、管理上下文或呼叫工具。

我開發了 Hermes IDE,因此請在閱讀本節時考慮這一點。它採取了相反的預設設計,並在 2026 年 9 月 27 日的 ADR 003 中闡述了原因。ADR 的論點是:每個供應商的終端介面不斷增加功能,因此渲染視圖會落後,並且必須為每個供應商重新構建。因此,每個新的 Hermes 會話都在真實終端中運行代理自己的 CLI,包括 Claude Code。

Hermes 有目的地觀察代理報告的內容(hook 負載、OSC 9/99/777 和 BEL 通知、退出代碼)以及 Git,僅為渲染和標記為猜測的狀態讀取終端串流,並且從不替你回答權限提示。只有當供應商提供穩定、有文件記錄的機器協議時,才允許結構化視圖,並且僅作為每個會話的選擇加入功能。

Codex 在 orders-types 上,Claude Code 在 orders-api 上,每個都在自己的終端和 hermes/ 工作樹中運行,並在側邊欄顯示狀態、上下文使用、成本和分支。與代理主機對應的部分是會話的持久性。根據 README,Rust 後端擁有一個背景會話主機,在 macOS 和 Linux 上,「即使 Hermes 退出、更新或崩潰,代理仍會繼續工作,你可以從中斷處重新連接。」

目標與 VS Code 的主機相同,但單位不同:持久化的是供應商的 CLI 程序及其終端,而不是協議會話。也有一個有趣的重疊。Hermes 的可選「Claude 代理視圖」運行相同的 Claude Agent SDK,在一個小型的每個會話橋接器中。這兩種工具都使用該 SDK 來渲染 Claude 視圖。不同之處在於你預設獲得哪一種。

終端優先設計也有其代價:README 僅承諾在 macOS 和 Linux 上提供背景會話,在 Windows 上則沒有此承諾。終端是一個位元組串流,因此某些狀態是推斷出來的。Hermes 會說明何時狀態是猜測,但標記為猜測的狀態仍然不是帶有 serverSeq 戳記的事件。

README 列出了 SSH 和 tmux 會話,但沒有描述在 Dev Container 內運行會話。如果你希望代理在專案的容器內運行,VS Code 現在已經支援。每個供應商的 CLI 都保留其自身的特性,你必須接受這些特性。

如果你習慣使用 VS Code、使用 Copilot、希望一個會話能從多個視窗可見,或者需要在遠端機器上的 Dev Container 內運行代理,那麼請選擇代理主機。它的協議能提供終端無法提供的功能:將每個 AI 處理過程和工具呼叫作為有序、類型化的事件。

如果你依賴供應商最新發布的命令,或者同時運行多個供應商的工具並希望每個工具都按照其文件所述的方式運行,那麼請選擇供應商自己的 CLI,無論是在 Hermes 還是普通終端中。Hermes 是免費的,在 BSL 1.1 許可下開源,並可在 macOS、Windows 和 Linux 上運行。

你可以在 GitHub 上下載或閱讀其程式碼。它不隸屬於 Nous Research、Anthropic、OpenAI、Microsoft 或任何代理供應商。我尚未對這兩種方案進行基準測試。

值得思考的問題是,你所依賴的介面是屬於編輯器還是屬於供應商。我認為這個故事中最有趣的部分是可觀察性。AHP 會話將每個 AI 處理過程和工具呼叫作為有序事件提供給你,而終端代理只會報告其 hook 和通知選擇報告的內容。了解 LLM 系統實際做了什麼,以及你可以信任哪些信號,正是《LLM 可觀察性袖珍指南》的主題,從追蹤和評估到 token 成本。

Share

覺得值得一看?分享給朋友。

以上為 AI 自動翻譯導讀。原文版權歸 DEV Community (Codex) 所有, 建議透過「閱讀原文」前往原始網站,以取得最完整資訊並支持原作者。

Newsletter

不用每天追,AI 重點每週寄給你

43 個來源、每 2 小時更新,太多看不完。電子報每週挑最值得看的幾則,附上 Max 的看法。

每週一封。Email 只用來寄電子報,每封信都能一鍵退訂。