代理連上遠端主機，就能直接使用專案環境嗎？關鍵要看它實際在哪裡執行，取得哪些工具、檔案與權限。VS Code 1.139 將 AI 代理的 Dev Container 工作階段擴及 SSH、Tunnel 與 WSL 主機，讓代理可在專案容器內使用所配置的工具與相依套件。這項更新適合已有遠端開發流程的團隊評估，實際能否使用仍取決於版本、容器設定、遠端 Docker 與組織政策。VS Code 1.139 更新紀錄

一、VS Code 1.139 把代理容器工作階段延伸到哪些遠端主機？

新增範圍是 SSH、Remote Tunnel 與 WSL 主機上的 Dev Container 專案；功能從 Agents 視窗啟動，並非所有遠端連線都會自動改在容器中執行。

Dev Container 是一種專案開發環境設定方式，將工具、執行環境與相依套件寫入設定檔，讓專案能在容器中建立相對一致的工作環境。1.139 把既有的本機容器代理工作階段延伸到遠端專案：SSH 主機、Tunnel 主機，以及 Windows Subsystem for Linux（WSL，Windows 的 Linux 子系統）主機都列入支援範圍。這是功能可用位置的擴大，不代表代理會自動替團隊建立遠端主機或容器映像。

啟動入口在桌面版 VS Code 的 Agents 視窗。選取已連線的資料夾，再從資料夾選單選擇「Use Dev Container」；VS Code 會依專案的 Dev Container 設定啟動容器並在其中執行代理工作階段。遠端資料夾須有受支援的設定檔，位置為 .devcontainer/devcontainer.json 或 .devcontainer.json。遠端主機則必須安裝並執行 Docker，且 Docker CLI 可從該主機的 PATH 找到。Agents 視窗操作說明

可用入口仍有範圍限制：這個容器工作階段功能目前只在桌面版 Agents 視窗提供，並標示為實驗性功能。VS Code 採分階段推出，帳號或安裝版本即使符合條件，chat.agentHost.devContainer.enabled 也可能尚未預設啟用。若團隊允許試用，可在設定中手動開啟後確認；若設定受組織政策管理，則應先詢問管理者，不宜把「更新到 1.139」當成全員立即可用的保證。遠端代理工作階段文件

「Dev Container 工作階段仍屬實驗性，可能變更或移除。」（Microsoft VS Code 文件中文意譯）

這個註記會影響採用節奏。個人可用非敏感專案先熟悉流程；團隊若把它納入正式開發流程，還要評估設定變動、支援方式與替代流程。官方版本說明可確認功能支援範圍，並沒有提供獨立的安全性或效能測試結果，因此不宜把版本更新直接解讀為更安全或更快。

二、代理進入容器後，遠端開發流程改變在哪裡？

改變的是代理執行工作時使用的工具與相依套件位置；VS Code 編輯器、遠端主機和容器各自仍有不同職責。

可把連線拆成三個位置理解：本機 VS Code 提供介面與工作階段管理；SSH、Tunnel 或 WSL 連線抵達放置專案的遠端主機；遠端主機上的 Docker 再依專案設定啟動 Dev Container。代理工作階段在容器工作區中執行時，可使用容器配置的語言執行環境、編譯器、測試工具與套件。VS Code 官方說明指出，遠端容器必須由遠端主機上的 Docker 啟動，容器中的代理可以使用專案所配置的工具與相依套件。遠端 Dev Container 說明

這對開發流程的價值，常出現在「我的電腦能跑、你的電腦不能跑」這類環境差異。若依賴版本、作業系統工具或建置步驟已寫進 Dev Container 設定，代理可在同一套容器環境裡修改程式、執行測試或建置，減少另外在筆電和遠端主機各裝一份工具鏈的工作。對需要使用遠端 CPU、記憶體、內網服務或特定 Linux 環境的專案，工作階段也能靠近程式碼與測試資源。

但容器不會自動消除環境差異。專案若依賴容器外的資料庫、授權服務、硬體裝置或私有套件來源，仍需設定網路連線、憑證與服務端點；映像建置失敗、Docker 權限不足或套件來源無法連線，代理也無法越過這些條件。若容器設定沒有列入實際開發所需工具，團隊仍需更新設定、重建映像並維護版本。工具鏈一致是設定與維護的成果，並非只勾選一個選項就會發生。

流程圖以箭頭連接本機 VS Code、透過 SSH、Tunnel 或 WSL 抵達的遠端 Docker 主機，以及執行代理工作階段的 Dev Container。
代理工作的工具與相依套件來自容器設定，容器則由遠端主機上的 Docker 啟動。

導入時也要分清楚這次新增與既有遠端代理功能的差別。VS Code 的遠端代理工作階段原本就能透過 SSH 或 Tunnel 在遠端機器上啟動；1.139 的新資訊是把 Dev Container 工作階段帶到遠端 SSH、Tunnel 與 WSL 專案。前者讓代理在遠端主機的工作環境處理專案，後者讓它進一步使用容器設定的工具。若專案不需要容器內特定工具，既有遠端主機工作階段可能已足夠；若團隊靠容器固定版本、依賴與建置流程，新功能才可能減少重複準備。遠端工作階段操作文件

三、容器邊界與代理權限要怎麼檢查？

不能只憑「在容器裡執行」就認定主機和資料已隔離；掛載、憑證、Docker 權限、Tunnel 驗證與代理核准方式都會影響實際風險。

容器提供一個獨立的執行環境，實際邊界仍由設定決定。先檢查 Dev Container 的 mounts、工作區掛載和相關 volume：代理需要讀寫哪些目錄？是否把主機家目錄、SSH 金鑰、雲端憑證或整個 Docker socket 掛進容器？掛載越多，容器內的程式與代理可接觸的主機資源越廣。也要確認環境變數和 .env 等機密是否會進入容器，並盤點代理在專案內讀取的程式碼、終端輸出和診斷內容會傳送到哪些模型或工具。VS Code 的安全說明提醒，代理執行的命令可能使用工作階段所屬使用者的權限，工作區內容與終端資料也可能成為模型上下文。VS Code AI 開發安全說明

遠端 Docker 的權限尤其要釐清。負責啟動容器的 Docker 服務位於放置專案的遠端主機，須確認 Docker CLI 連到預期的主機與服務，帳號有權執行哪些操作，誰管理 Docker 群組、映像來源、建置快取與更新。若開發容器能存取 Docker socket 或主機敏感路徑，便不能把它視為已和主機切開的沙盒。這些設定可能是為了建置需要而加入，導入代理前應逐項知道它們帶來的存取範圍。

Tunnel 也需要身份驗證。VS Code 官方文件提醒，Tunnel 應要求 GitHub 或 Microsoft 帳號驗證；匿名 Tunnel 若網址被他人取得，對方可能連到主機並啟動代理工作階段。若同時啟用自動核准，未授權者還可能觸發使用你憑證的命令執行。因此應確認使用者身分、Tunnel 分享範圍與代理核准模式，避免把任何可取得網址的人都當成可信使用者。遠端代理工作階段安全提醒

工作區信任與代理核准是另外兩道檢查。未知專案應先以受限模式檢視，確認程式碼、開發容器設定、擴充套件和 MCP（Model Context Protocol，模型上下文協定）工具來源，再給予工作階段所需權限。對敏感檔案可要求人工核准，終端命令採逐次或限於工作階段的核准方式，完成後檢閱差異再整合。VS Code 的文件特別提醒，自動核准會降低操作摩擦，但也可能讓具破壞性的命令在缺少人工檢查時執行。AI 開發安全建議

「若 Tunnel 允許匿名存取，取得網址的人可能連線到主機並啟動代理工作階段。」（Microsoft VS Code 文件中文意譯）

這些檢查與「容器是否有漏洞」不是同一題。容器的執行邊界、代理能讀寫的檔案、命令可用的使用者權限、遠端服務的網路可達性，都要分開盤點。部署規則也可能要求特定映像、代理帳號或機密管理方式，需由維運與資安負責人共同確認。

四、哪些遠端開發情境適合先試用？

選擇入口應依現有主機位置、連線管理方式與容器責任人決定；三種連線都支援遠端容器代理，但各自要滿足不同的連線與維護條件。

連線方式適合的既有情境導入前要確認
SSH已用 SSH 管理的 Linux 開發機或伺服器SSH 帳號權限、網路可達性、遠端 Docker 與 CLI
Remote Tunnel需要透過 Tunnel 連回開發主機的團隊Tunnel 已啟動、要求 GitHub 或 Microsoft 驗證、分享範圍受控
WSLWindows 開發者把專案放在 WSL Linux 環境WSL 主機上的 Docker、專案路徑和既有容器流程

遠端 Docker 負責人明確、Dev Container 已被日常使用、代理任務常需專案指定的編譯或測試工具，通常是值得先試的情境。這時可觀察的問題很具體：代理是否能成功啟動容器、是否找到正確版本的工具、測試結果是否和團隊既有流程一致，改動能否被正常檢查與提交。若專案只在主機上執行一兩個通用命令，容器建置與維護成本可能超過省下的準備時間。

對有嚴格網路分區或敏感憑證的團隊，先看政策能否允許代理工作階段接觸該環境。代理能在遠端主機跑，不代表它的請求、工具或上下文都留在公司網路；具體資料處理取決於所用代理、模型供應者、VS Code 設定及組織方案。應先檢查資料處理政策、網路出口限制、帳號權限與稽核需求，再挑可公開或測試用的專案驗證。官方文件說明功能行為與安全控制，未提供各組織合規或資安審核結論。

維運成本也落在團隊的既有責任上：誰更新基礎映像和語言版本、誰維護相依套件、誰處理主機磁碟與 Docker 快取、網路變更後由誰排查建置失敗？若只有一位工程師能維護設定，其他成員遇到容器啟動錯誤就會卡住。把常見故障訊息、映像更新節奏與回退方式寫進團隊流程，通常比先把所有專案切換過去更實際。

比較表以三欄呈現 SSH、Remote Tunnel 與 WSL 的常見主機情境、連線或驗證條件及 Docker 前提。
三種入口都能連到遠端容器工作階段，選擇時要核對各自的主機與連線條件。

五、導入前的五項檢查能判斷哪些成本？

先從一個不含敏感資料的代表性專案驗證版本、容器、遠端 Docker、網路和權限，再依可用性與維護負擔決定是否擴大。

  1. 版本與入口：確認使用桌面版 VS Code 1.139 或更新版本，Agents 視窗可用，並查看 chat.agentHost.devContainer.enabled 是否啟用。功能仍在實驗階段且分批推出，組織政策或帳號狀態也可能影響選項。
  2. 專案設定：檢查 .devcontainer/devcontainer.json 或 .devcontainer.json 是否符合目前專案需要，建置步驟能否取得依賴套件，是否有必要的代理設定與工作目錄。檔案存在不等於設定可以成功建置。
  3. 遠端主機：在 SSH、Tunnel 或 WSL 對應主機確認 Docker 服務正常、Docker CLI 位於 PATH，且磁碟、記憶體與網路足以建立映像及執行測試。發生錯誤時，確認有能力讀取容器啟動輸出並追查。
  4. 權限與資料：盤點工作區掛載、Docker 權限、機密注入方式、Tunnel 身分驗證、工作區信任與代理核准設定；使用權限較低且不含正式憑證的測試帳號，檢查代理能否讀取或修改不應觸及的檔案。
  5. 維護與回退：指定容器映像、相依套件和遠端主機的維護人，估算更新與排錯所需工作，並保留回到原本遠端主機工作階段的方式。用實際建置或測試任務比較結果，記錄啟動是否穩定、工具是否齊全、人工介入次數與維護問題。

試用要回答的是具體工程問題：容器啟動成功率如何？代理找到的工具版本是否正確？測試能否連到需要的服務？權限設定能否符合組織要求？映像維護的工作量是否可以接受？如果這些條件都能被團隊持續管理，遠端容器代理才可能減少環境重複準備。若主要瓶頸在網路、映像或主機權限，應先處理這些根因，功能本身不會代替維運。

小範圍試用順序

先選一個可丟棄或可還原、沒有敏感資料的代表性專案，核對遠端 Docker 與容器設定；再用一項真實的建置或測試任務驗證工具、網路與權限；最後記錄代理完成任務所需的人工介入、排錯時間和映像維護工作。試用前先約定停止條件，例如容器需要過寬掛載、Tunnel 無法要求驗證，或團隊無法維護專案映像，就暫不擴大範圍。

  • 確認 VS Code 版本、Agents 入口與功能設定。
  • 檢查 Dev Container 專案設定、遠端 Docker、網路與工具需求。
  • 盤點權限、資料存取、映像維護責任及回退方式。
  • 以不含敏感資料的代表性專案執行實際建置或測試，再評估是否擴大。

常見問題

從桌面版 Agents 視窗對已連線的遠端資料夾選擇「Use Dev Container」，並先確認功能設定與容器條件。

常見問題

Q1：VS Code 1.139 的遠端 Dev Container 代理功能在哪裡使用？

在桌面版 VS Code 的 Agents 視窗建立工作階段，選擇已設定的 SSH、Tunnel 或 WSL 遠端資料夾，再從資料夾選單選擇「Use Dev Container」。功能採分階段推出，若設定未啟用，可依組織政策手動開啟 chat.agentHost.devContainer.enabled。

Q2：遠端主機需要具備哪些條件？

遠端主機需要安裝並執行 Docker，Docker CLI 可從主機的 PATH 找到；專案則須包含 .devcontainer/devcontainer.json 或 .devcontainer.json。SSH、Tunnel 或 WSL 連線本身也必須已能在 Agents 視窗使用。

Q3：使用 Dev Container 是否代表代理已與主機隔離？

不代表完全隔離。工作區掛載、Docker socket、容器使用者、機密和網路權限都會影響容器可接觸的資源；應依專案設定與組織政策逐項檢查，並對代理命令採取符合風險的核准方式。

Q4：Tunnel 可以不登入就開放給團隊共用嗎？

不建議。VS Code 官方提醒，匿名 Tunnel 的網址若被取得，其他人可能連到主機並啟動代理工作階段。Tunnel 應要求 GitHub 或 Microsoft 帳號驗證，並限制可使用的人員。

Q5：哪些專案適合先試？

可先挑容器設定已成熟、工具鏈明確、遠端 Docker 有維護負責人，而且可用非敏感資料測試的專案。若專案需要高敏感憑證、特殊網路權限或大量主機掛載，先完成權限與資料流程審查再評估。