Visual Studio Code 1.122 今日發布，頭條故事簡單但意義重大：BYOK（自帶金鑰）不再需要 GitHub 登入。這不是小的 UX 改善 — 這是解鎖 VS Code AI 功能給受監管、氣隙與網路受限環境的變更，這些環境過去完全無法使用 GitHub Copilot。再加上日趨成熟的 Agents Window、企業級 OpenTelemetry 訊號，以及 Custom Endpoint 提供者從預覽邁向穩定，本次發行讀起來更像企業平台公告，而非每月的小版本發行。
氣隙 BYOK：改變對話的變革
在 1.122 之前，在 VS Code 中使用您自己的語言模型 API 金鑰 — 即使該金鑰指向零外部流量的內部部署端點 — 都需要 GitHub 登入。GitHub 身分就是那道閘門。對政府機關、國防承包商、在分段網路中營運的金融機構，或任何有嚴格第三方驗證限制的組織，那個相依性是硬性阻礙。
該相依性現已從交談、工具與 MCP 伺服器中移除。
透過命令選擇區 → 管理語言模型設定提供者 — Anthropic、Azure、Gemini、OpenAI、Ollama、OpenRouter 或自訂端點 — VS Code 的交談檢視即無需 GitHub 即可使用。要求直接送到您設定的提供者。登入提示被抑制。
這帶來的能力：
- 透過私人端點的 Azure OpenAI。 透過 VNet 整合或私人 DNS 區域執行 Azure OpenAI 的組織，可將 VS Code 直接指向那些端點。沒有資料離開租用戶。不需要對外 GitHub 驗證。
- 內部部署 Ollama 部署。 在內部伺服器執行 Llama 或 Mistral 模型的團隊，現在有完整支援、穩定的路徑可在 VS Code 交談中使用這些模型。
- 受限的政府/國防網路。 GitHub.com 完全被封鎖的環境，現在只要其選擇的 LLM 端點可在內部連線，即可部署 VS Code AI 功能。
- 完整的離線工作流程。 將 BYOK 與 VS Code 的可設定遙測策略（
TelemetryLevel）結合，您可以在網路邊界內完全執行有意義的 AI 輔助開發體驗。
仍需 GitHub 登入的部分： 行內建議與 Next Edit Suggestions (NES)。BYOK 涵蓋交談、工具與 MCP 伺服器 — 不涵蓋即時 completion 引擎。對多數氣隙使用案例，這是可接受的取捨。主要想要 AI 交談協助與代理工具而非即時 completions 的開發者，會得到他們所需的一切。
公用程式模型的麻煩： VS Code 使用較小的「公用程式模型」處理背景任務 — 交談標題生成、提交訊息生成、回饋流程。當您登出時，那些預設公用程式模型無法連線。VS Code 1.122 會顯示通知，提示您為公用程式任務設定 BYOK 模型（chat.utilityModel、chat.utilitySmallModel 設定）。您可以設定它們以取得完整 AI 功能，或如果您只需要交談，可關閉通知。
Custom Endpoint 提供者邁向穩定
與氣隙 BYOK 直接相關：Custom Endpoint 提供者在 1.122 從預覽邁向穩定。
此提供者讓您連接任何實作 Chat Completions、Responses 或 Messages API 的模型 — 與 OpenAI、Anthropic 與 Azure 使用的相同協定家族。這意味著由 vLLM、TGI 或 LM Studio 提供服務的自架 LLM、自訂 API 後方的企業 AI 平台，或透過閘道存取的 Azure OpenAI — 全部現在都是 VS Code 穩定版中第一級的 BYOK 提供者。
實際後果：現在有一條完整受 Microsoft 支援、生產穩定的路徑，可對任何內部控制的 LLM 端點執行 VS Code 交談。這縮小了技術上可行與官方支援之間的差距 — 對企業 IT 與合規團隊是重要的區別。
細緻的 BYOK 提供者管理
管理 BYOK 提供者過去意味著編輯原始 JSON 設定來輪替金鑰、新增模型或清理提供者。1.122 在語言模型編輯器中直接提供目標動作：
- 更新 API 金鑰 — 不動 JSON 即可輪替金鑰
- 新增模型 — 以額外模型擴充提供者群組
- 重新命名群組 — 就地清理提供者群組名稱
- 刪除 — 完全移除提供者群組
單獨來看這些是小型 UX 改善。整體而言，它們訊號出 Microsoft 將 BYOK 視為主流工作流程，而非進階使用者的應急出口。當企業組織跨團隊設定並輪替多個 BYOK 提供者的金鑰時，這些動作降低了作業摩擦與 JSON 編輯造成設定錯誤的風險。
Agents Window：成熟為真正的工作流程工具
Agents Window — 用於探索、迭代與檢閱 AI 代理工作階段的專屬配套面板 — 在 1.122 中以兩項新增持續其預覽演進：
工作階段懸停詳情。 將游標懸停在工作階段清單中的任何工作階段，可看到其標題、使用的框架（以圖示表示）、專案、工作樹與變更的檔案 — 無需點入工作階段。對管理跨專案多個並行代理工作階段的開發者，這是有意義的可用性改善。
從 Agents Window 管理模型。 「交談：管理語言模型」現在可直接從 Agents Window 取得。這很重要，因為 Agents Window 日益成為代理模式工作發生之處 — 能在不切回主編輯器視窗的情況下設定 BYOK 模型，讓工作流程保持連貫。
對評估 VS Code 代理能力能否取代 Cursor 或 Claude Code 等獨立代理程式碼工具的組織：Agents Window 是長期答案。它仍是預覽，但每次發行都新增讓它更適合生產使用的功能。本機 VS Code 框架目前仍是 Insiders 專屬（sessions.chat.localAgent.enabled），但走向很明確。
OpenTelemetry 訊號：代理變得可觀測
這項變更容易在發行說明中被忽略，但對企業治理意義重大。
本機代理工作階段現在对 OpenTelemetry 發出標準 github.copilot.* 屬性命名空間，與 GitHub Copilot CLI OpenTelemetry 慣例對齊。新訊號涵蓋：
- 存放庫內容
- 代理類型
- 結構化工具參數
- Hook 結果
為何這對 IT 與 DevOps 團隊重要：
如果您的組織執行 OpenTelemetry 管線 — 饋送至 Datadog、Grafana、Azure Monitor、Splunk 或任何相容後端 — VS Code 代理活動現可流入與應用程式遙測相同的可觀測性基礎結構。這使得：
- 成本可見性。 追蹤每個開發者、團隊或專案的 LLM 權杖消耗。
- 安全稽核軌跡。 知道哪些工具執行、哪些 MCP 伺服器連線、哪些 Hook 執行 — 而不只是某個代理工作階段發生過。
- 合規證據。 對受監管環境，代理活動的結構化稽核記錄是治理需求，而非可有可無。
- 效能基準。 使用相同度量基礎結構，衡量 AI 輔助開發相對於非 AI 工作階段的實際生產力影響。
與 GitHub Copilot CLI 慣例的屬性對齊也很有意義：如果您的組織同時使用 VS Code 代理與 CLI 式代理工具，遙測現在說著共同語言。這是跨開發工具鏈集中代理監控的基礎。
沙箱行為精緻化
設定： chat.agent.sandbox.enabled
此處變更微妙但值得了解。過去以「繞過核准」或 Autopilot 模式執行的命令會先在沙箱中嘗試；若失敗，VS Code 會自動在沙箱外重試。由於核准已被繞過，此重試迴圈並未提供真正的安全利益 — 只讓行為更難理解。
新行為： 終端機沙箱化僅在使用「預設核准」時套用。
這是安全模型的務實釐清：
- 預設核准 = 套用沙箱化 → 安全與實用性的真正平衡
- 繞過核准 / Autopilot = 無沙箱化 → 使用者已明確承認風險，沙箱重試會是誤導的戲碼
對為代理使用設定策略的組織，此釐清很重要。如果您要求開發者對敏感存放庫使用預設核准，沙箱化提供真正保護。如果開發者啟用了繞過核准，就沒有沙箱 — 這是誠實且可預期的，即便需要在其他地方額外的治理控制。
整合式瀏覽器：裝置模擬與截圖到交談
整合式瀏覽器新增兩項功能，為本次發行畫下句點：
裝置模擬。 整合式瀏覽器現已支援開箱即用的裝置模擬 — 螢幕尺寸、行動/觸控模擬、自訂使用者代理。透過瀏覽器分頁溢位選單中的「顯示模擬工具列」選項啟用。對 Web 開發者，這消除了為測試回應式版面而切換到 Chrome DevTools 或獨立瀏覽器視窗的需求。值得注意的是，代理可透過 Playwright 程式碼以程式方式觸發裝置模擬，讓自動化行動回應性檢查成為代理驅動測試工作流程的一部分。
截圖到交談。 將目前瀏覽器檢視區的截圖直接附加到 VS Code 交談作為內容。實際使用案例立竿見影：對壞掉的版面截圖、附加到交談，並要求 Copilot 診斷 CSS 或版面問題，無需離開編輯器。
組織應採取的行動
如果您在氣隙或網路受限環境中營運： 將 1.122 評估為讓 VS Code AI 功能可行的發行。盤點您的內部 LLM 端點情況 — Azure OpenAI 私人端點、內部部署 Ollama 或自訂端點 — 並測試 BYOK 設定。該能力現已穩定且受支援。
如果您大規模管理 VS Code 部署：
檢視 VS Code 部署設定中的 TelemetryLevel 設定。若 AI 功能過去因 GitHub 登入要求而被封鎖，那些封鎖可能需要重新考慮。相反地，確保 BYOK 設定治理到位 — 您不會希望開發者將 VS Code 指向未經審查的外部端點。
如果您在 VS Code 中執行代理工作負載：
為代理工作階段設定 OpenTelemetry 匯出。即使您暫不監控，現在建立資料管線可在代理使用規模擴大前給您基準。github.copilot.* 屬性命名空間是應對應到現有 OTel 基礎結構的訊號。
如果您是 Web 開發者： 開啟裝置模擬工具列。這是生活品質改善，從除錯工作流程中移除一次內容切換。
未改變的部分
- 行內建議與 NES 仍需 GitHub 登入。 BYOK 不會取代 Copilot 的即時程式碼 completions。
- 現有 GitHub Copilot 訂閱者不受影響。 不需登入的 BYOK 是 GitHub 驗證不可能的情境下的附加能力。
- Agents Window 仍為預覽。 生產關鍵的代理工作負載應據此評估。
- 遠端開發 SSH/WSL/Dev Containers 不受 AI 與 BYOK 變更影響。1.122 中唯一的遠端開發注意事項是 32 位元 ARM Linux 主機的 EOL。
更宏觀的圖像：VS Code 作為企業 AI 基礎結構
Microsoft 正面臨代理程式碼工具 — Cursor、Claude Code、OpenAI Codex — 的真實競爭壓力，這些工具動作快並吸引開發者目光。VS Code 1.122 的企業導向變更並非巧合。它們是對一個特定問題的回答：為什麼受監管的組織應標準化於 VS Code，而非評估替代方案？
跨近期發行建構的答案：VS Code 是與企業身分、合規與可觀測性基礎結構整合的選項。不需 GitHub 登入的 BYOK 處理資料主權。OpenTelemetry 對齊處理治理。穩定版的 Custom Endpoint 處理自架 LLM 部署。沙箱行為釐清處理安全策略透明度。
這是 Microsoft 跨其企業產品組合應用的模式 — 不是在原始能力上逐功能競爭，而是建構企業 IT 在大規模部署 AI 工具前所需的治理、合規與整合掛鉤。對需要 VS Code 嵌入現有安全架構而非繞過它的組織，1.122 讓那個對話輕鬆許多。
與 Build 2026 把 Windows 描述為代理平台 — 代理在可重設、可稽核的環境中執行而非鬆散於開發者桌面 — 的論述結合，VS Code 1.122 的可觀測性與受控執行功能指向一致的企業 AI 開發架構。編輯器、平台與治理基礎結構正在同步建構。
準備好最佳化您的開發者工具了嗎？
Big Hat Group 協助組織以 Intune、Windows 365 與 GitHub Copilot 大規模標準化與部署 VSCode。無論您是在為受監管環境評估 BYOK、建立開發者生產力基準，還是跨工程團隊擴展 GitHub Copilot，我們每次參與都帶來實戰專業。
聯絡 Big Hat Group 以討論您的開發者工具策略。
Big Hat Group 是 Microsoft 合作夥伴，專精於現代端點管理、Windows 365 與開發者生產力工具。