VS Code 1.138 發佈：AI 代理走進開發容器

微軟於 2026 年 9 月 16 日發布 Visual Studio Code 1.138，這套以 MIT 授權開源的編輯器在 GitHub 累積 192,782 顆星標與 42,926 個分支。此版本的核心變動是讓 AI 代理工作階段在專案自身的開發容器（Dev Container）中執行，同時擴展 Codex 支援至跨應用續接與訂閱切換，並加入完成後自動標記的會話清理機制。相關功能以代理主機（Agent Host）為基礎，讓同一個工作階段能從多個 VS Code 視窗連接。

VS Code 1.138 是微軟 2026 年 9 月 16 日發布的月度更新，星標 192,782。它讓 AI 代理工作階段在專案開發容器中執行，並擴展 Codex 支援與會話清理。

這批更新的共同主題，是把代理從聊天視窗推向專案的實際環境。上一版的代理主機已把代理執行框架放進獨立行程，透過代理主機協定（AHP）管理，使同一工作階段可被多個視窗共用。1.138 沿著這條路線往下走，處理的是執行環境、訂閱來源與狀態整理三個層次的問題。

VS Code 1.138 是什麼？

它是 VS Code 於 2026 年 9 月 16 日發布的正式版本，屬每月更新。重點為代理工作階段在開發容器中執行、Codex 訂閱可切換及完成後自動清理。

Visual Studio Code 由微軟與社群在名為 Code - OSS 的儲存庫共同開發，再以微軟產品授權包裝成公開發行的版本。儲存庫同時承載程式碼、問題追蹤與迭代計畫，並以每月一次的節奏發布正式版，開發者可透過 nightly 的 Insiders 版本提前測試尚未完成的功能。

1.138 的更新說明由該公司自行以 GitHub Copilot 生成，官方在文件中明言內容可能有誤，這種做法本身也反映生成式工具已進入產品發布流程。版本於 9 月 16 日上線，屬於漸進式推送，使用者需要主動檢查更新才會立即取得。

VS Code 的專案背景與規模為何？

專案於 2015 年 9 月建立，由微軟與社群共同維護，以 MIT 授權開源。儲存庫累積 165,801 次提交、2,578 位貢獻者，是最活躍的開發者工具專案之一。

儲存庫建立於 2015 年 9 月 3 日，正值開源編輯器競爭激烈的時期。專案的做法是把核心編輯器以 MIT 授權開放，微軟自身的發行版再疊加專有元件，形成開源核心與商業發行並行的結構。這種安排讓社群能持續貢獻語法支援與擴充套件，同時保留品牌與服務的商業空間。

規模是理解這個專案影響力的關鍵。165,801 次提交、2,578 位貢獻者與 5,243 個分支，說明它並非由單一團隊推動，而是長期吸納外部修補的結果。最新一次提交與本文取材時間相差不到一日，倉庫活躍度維持在極高水位。

VS Code 1.138 有哪些核心新功能？

四項為主要亮點：代理工作階段可在本地開發容器執行、Codex 支援訂閱切換與跨應用續接、會話可自動標記清理，自動化改為預設啟用。

官方把版本重點歸納為三項，實際變動則更廣。第一項是代理工作階段可在本機資料夾的開發容器中執行，讓代理使用專案設定的工具鏈與相依套件，而非開發者電腦上的版本。第二項是 Codex 支援擴展，代理可選擇以 GitHub Copilot 或 ChatGPT 訂閱登入，並在模型選擇器中切換而不中斷對話。

第三項是會話清理預覽功能，系統可在代理負責的拉取請求全部合併後，建議把工作階段標記為完成，並可設定寬限期後自動刪除。此外，自動化（Automations）改為預設啟用並支援匯出與匯入，方便團隊共享重複性任務的設定。這些改動都圍繞同一個目標：讓代理產出的事務在專案中留下可管理的痕跡。

代理工作階段如何在開發容器中執行？

啟用 chat.agentHost.devContainer.enabled 後，具備開發容器設定的資料夾會出現選項，代理即在該容器執行，需先安裝 Docker。

做法是讓代理與專案的執行環境對齊。當設定開啟後，本機資料夾若帶有受支援的開發容器設定，資料夾選單便會出現使用開發容器的動作，選取後代理工作階段即在該容器內運行。容器內具備專案設定的執行環境與相依套件，代理不需要依賴開發者電腦上另行安裝的版本。

這項功能的實際意義在於版本與環境的落差。真實專案常見依賴特定版本的函式庫或系統工具，開發者本機未必與之一致，代理若在錯誤環境中執行測試，產出的結果便不可靠。把工作階段綁進容器，等於讓代理在與團隊相同的條件下工作。官方同時說明此功能為漸進推送，部分使用者可能需要手動開啟設定才能試用，且機器須先安裝 Docker。

Codex 支援擴展帶來什麼改變？

Codex 可用 Copilot 或 ChatGPT 訂閱登入，在模型選擇器切換而不遺失對話；工作階段可在 ChatGPT 應用與 VS Code 間續接，並取用內建與 MCP 工具。

這項變動同時處理帳號與工具兩件事。在帳號方面，開發者可選擇以 Copilot 訂閱或 ChatGPT 訂閱驅動 Codex，若同時登入兩者，可在模型選擇器中切換而不失去當前對話；僅使用 ChatGPT 訂閱且未登入 Copilot 的使用者，則需開啟另一項設定。這種安排讓訂閱選擇與工具選擇分離，使用者不必為了換模型而重開工作階段。

在工具方面，Codex 可直接取用 VS Code 提供的完整工具集，涵蓋內建工具、擴充套件與 MCP 工具；若使用 ChatGPT 訂閱的模型，還可在工作階段內直接使用其圖像生成功能。官方亦把快速對話延伸到工作區，開發者可要求 Codex 附加本機資料夾，並選擇直接使用或建立隔離的工作樹，原本的對話與原生執行緒會一併轉為工作區工作階段，標題、歷史、當前請求、所選模型與權限模式都會保留。

會話清理機制如何運作？

當不活躍工作階段的拉取請求全部合併，Agents 視窗會建議標記為完成，並可設定寬限期後刪除。兩項清理設定預設關閉，需使用者主動啟用。

機制設計成先提示、後自動化。預設情況下，系統只會在會話清單顯示標記完成的建議，並以首次使用指引說明操作位置；若要進一步自動化，可設定在拉取請求合併後自動把不活躍工作階段標記為完成，另設一段寬限期後再刪除。這兩項自動清理設定預設皆為關閉。

保留對話與整理介面之間的取捨，是這項功能的出發點。代理工作階段的數量會隨使用時間快速累積，若沒有一致的收尾流程，清單很快就失去可用性。官方另外加入狀態徽章，可在 macOS 的 Dock、Linux 啟動器或 Windows 工作列上提示哪些工作階段有新結果或待輸入，讓使用者不必切回主視窗也能掌握進度。

VS Code 1.138 的數據表現如何？

儲存庫累積 192,782 顆星標、42,926 個分支、21,240 項開放問題與 3,542 位關注者，共 165,801 次提交及 391 個版本標籤。

數據反映的是一個由社群長期共同維護的專案。42,926 個分支對應 192,782 顆星標，比例約為四點五比一，明顯高於一般工具型專案，說明有相當比例的使用者會直接修改原始碼，這與專案本身即為開發工具的性質相符。21,240 項開放問題看似龐大，但放在逾百萬行程式碼與每日數百次提交的節奏下，屬長期運作的正常水位。

版本標籤累積 391 個，對應近十一年的月度發布，節奏相當穩定。主要語言為 TypeScript，官方在各平台提供可執行檔，並保留自行編譯的完整文件。最新一次提交與本文取材時間相差不到一日，倉庫維護活躍度維持在高位，這對依賴編輯器作為日常工具的開發者而言，是比星標數字更實際的指標。

出處連結有哪些？

本文資訊整理自 microsoft/vscode 官方儲存庫，功能說明取自 1.138 官方更新公告，統計數據引自 GitHub API 公開端點。

本文所有功能描述與統計數據均取自 microsoft/vscode 官方 GitHub 儲存庫，包括 README 的專案說明與 MIT 授權聲明，以及 1.138 版本的官方更新公告。星標、分支、開放問題、關注者與提交數量引自 GitHub API 公開端點，版本與發布日期取自官方發布紀錄，數據截至 2026 年 9 月下旬。

常見問題有哪些？

以下整理三個關於 VS Code 與 1.138 版本的常見疑問，涵蓋開發容器功能的前置條件、Codex 訂閱的選擇方式，以及會話清理是否會自動刪除紀錄。

總結：VS Code 1.138 適合什麼團隊？

1.138 適合在真實專案中使用 AI 代理的開發團隊，尤其是相依套件版本敏感、需要代理在一致環境中執行測試，或已在團隊內共享自動化設定的團隊。

把代理工作階段綁進專案的開發容器，是 1.138 最實際的改動。它處理的不是模型能力，而是環境一致性這個長期被忽略的環節。當代理使用的函式庫版本與團隊成員一致，測試結果才有比較的基礎，代理產出的程式碼也才具備進入正式流程的條件。

除此之外，訂閱切換與會話清理屬於使用體驗層面的補強。前者讓工具與付費來源分離，後者回應代理工作階段快速累積的問題。對已把代理納入日常開發流程的團隊，這些改動能減少摩擦；對尚未導入代理的使用者，1.138 也提供了一個觀察開源編輯器如何整合 AI 工作流程的樣本。