Visual Studio Code 1.122 今日发布，头条消息直截了当却意义深远：BYOK（Bring Your Own Key，自带密钥）不再要求 GitHub 登录。这不是一次小的体验改进——它是为受监管、气隙和受限网络环境解锁 VS Code AI 功能的关键变更，这些环境此前根本无法使用 GitHub Copilot。再加上日趋成熟的 Agents 窗口、企业级 OpenTelemetry 信号，以及自定义端点提供方从预览进入稳定版，本次发布更像是一份企业平台公告，而不是一次月度小版本发布。

气隙 BYOK：改变对话的变更

在 1.122 之前，在 VS Code 中使用自带的语言模型 API key——即便该 key 指向的是一个零外部流量的本地端点——也需要 GitHub 登录。GitHub 身份就是那道闸门。对政府机构、国防承包商、在分段网络中运营的金融机构，或任何对第三方认证有严格限制的组织而言，这种依赖是一道硬性障碍。

该依赖在 chat、工具和 MCP 服务器中现已被移除。

通过 Command Palette → Manage Language Models 配置提供方——Anthropic、Azure、Gemini、OpenAI、Ollama、OpenRouter 或自定义端点——VS Code 的 Chat 视图即可在无需 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 覆盖 chat、工具和 MCP 服务器——不包括实时补全引擎。对大多数气隙场景而言，这是一个可接受的折中。主要想要 AI 聊天辅助和代理式工具（而非实时补全）的开发者，正好能得到所需。

实用模型的小麻烦： VS Code 使用更小的"实用模型"来执行后台任务——聊天标题生成、提交信息生成、反馈流程。当你处于未登录状态时，这些默认实用模型不可达。VS Code 1.122 会弹出通知，提示你为实用任务配置 BYOK 模型（chat.utilityModel、chat.utilitySmallModel 设置）。你可以配置它们以获得完整 AI 功能，或如果只需要聊天，则忽略该通知。

自定义端点提供方进入稳定版

与气隙 BYOK 直接相关：自定义端点提供方在 1.122 中从预览进入稳定版。

该提供方让你接入任何实现了 Chat Completions、Responses 或 Messages API 的模型——即 OpenAI、Anthropic 和 Azure 所使用的同一协议族。这意味着由 vLLM、TGI 或 LM Studio 托管的自托管 LLM、位于自定义 API 之后的企业 AI 平台，或通过网关访问的 Azure OpenAI——现在都已成为 VS Code 稳定版中的一级 BYOK 提供方。

实际后果：现在有了一条完全受 Microsoft 支持、生产稳定的路径，可让 VS Code 聊天对接任何受内部控制的 LLM 端点。这补上了"技术上可行"与"官方支持"之间的鸿沟——这一点对企业 IT 和合规团队至关重要。

细粒度 BYOK 提供方管理

管理 BYOK 提供方过去意味着编辑原始 JSON 配置来轮换密钥、添加模型或清理提供方。1.122 在 Language Model 编辑器中直接暴露了针对性操作：

  • 更新 API 密钥——无需改 JSON 即可轮换密钥
  • 添加模型——为提供方组扩展更多模型
  • 重命名组——原地整理提供方组名称
  • 删除——整体移除某个提供方组

单独看这些都是小的体验改进。合在一起，它们表明 Microsoft 正把 BYOK 当作主流工作流，而非高级用户的应急手段。随着企业组织跨团队配置和轮换多个 BYOK 提供方密钥，这些操作降低了运维摩擦以及 JSON 编辑带来的配置错误风险。

Agents 窗口：正成长为一个真正的工作流工具

Agents 窗口——一个用于探索、迭代和审查 AI 代理会话的专用伴随面板——继续其预览演进，在 1.122 中加入两项新功能：

会话悬停详情。 将鼠标悬停在会话列表中的任一会话上，即可看到其标题、所用框架（由图标指示）、项目、工作区及变更的文件——无需点进会话。对于跨项目同时管理多个并发代理会话的开发者而言，这是一项有意义的易用性改进。

从 Agents 窗口管理模型。 “Chat: Manage Language Models"现在可直接从 Agents 窗口调用。这很重要，因为 Agents 窗口日益成为代理模式工作的发生地——能够在不切回主编辑器窗口的情况下配置 BYOK 模型，让工作流保持连贯。

对于评估 VS Code 代理能力能否取代 Cursor 或 Claude Code 等独立代理式编码工具的组织而言：Agents 窗口是长期答案。它仍是预览版，但每个版本都增加了让它更适合生产使用的功能。本地 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 token 消耗。
  • 安全审计轨迹。 了解哪些工具运行过、哪些 MCP 服务器连接过、哪些 hook 执行过——而不仅仅是发生过某次代理会话。
  • 合规证据。 对受监管环境而言，结构化的代理活动审计日志是治理要求，而非锦上添花。
  • 性能基线。 使用同一指标基础设施衡量 AI 辅助开发相对于非 AI 会话的真实生产力影响。

与 GitHub Copilot CLI 约定的属性对齐也很有意义：如果你的组织同时使用 VS Code 代理和基于 CLI 的代理工具，遥测现在讲同一种语言。这是在整个开发工具链实现集中式代理监控的基础。

沙箱行为细化

设置： chat.agent.sandbox.enabled

此处的改动很微妙但值得理解。此前，以 Bypass Approvals 或 Autopilot 模式执行的命令会先在沙箱中尝试；如果失败，VS Code 会自动在沙箱外重试。由于审批已被绕过，这种重试循环并无真实安全收益——只会让行为更难推理。

新行为： 终端沙箱仅在 Default Approvals 模式下生效。

这是安全模型的一次务实澄清：

  • Default Approvals = 启用沙箱 → 真正平衡安全与可用
  • Bypass Approvals / Autopilot = 不启用沙箱 → 用户已明确承认风险，沙箱重试只是误导性的戏码

对于制定代理使用策略的组织而言，这一澄清很重要。如果你要求开发者对敏感仓库使用 Default Approvals，沙箱能提供真实保护。如果开发者启用了 Bypass Approvals，则没有沙箱——这既诚实又可预测，即便它需要在别处补充治理控制。

集成浏览器：设备模拟与截图到聊天

集成浏览器新增两项功能：

设备模拟。 集成浏览器现支持开箱即用的设备模拟——屏幕尺寸、移动/触控模拟、自定义 user agent。通过浏览器标签页溢出菜单中的"Show Emulation Toolbar"选项启用。对 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 用于实时代码补全。
  • 现有 GitHub Copilot 订阅者不受影响。 免登录 BYOK 是一项附加能力，用于 GitHub 认证不可行的场景。
  • Agents 窗口仍是预览版。 生产关键的代理工作负载应据此评估。
  • 远程开发 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 是与企业的身份、合规和可观测性基础设施相集成的选项。免登录的 BYOK 解决数据主权问题。OpenTelemetry 对齐解决治理问题。稳定版自定义端点解决自托管 LLM 部署问题。沙箱行为澄清解决安全策略透明度问题。

这正是 Microsoft 在其企业产品组合中一以贯之的模式——不在原始能力上逐特性竞争，而是构建企业 IT 在规模化部署 AI 工具前所需的治理、合规和集成钩子。对于需要让 VS Code 嵌入既有安全架构、而非绕过它的组织而言，1.122 让这场对话变得容易得多。

结合 Build 2026 关于"Windows 作为代理平台"的叙事——代理在可重置、可审计的环境中运行，而非松散地跑在开发者桌面上——VS Code 1.122 的可观测性和受控执行功能指向一套连贯的企业 AI 开发架构。编辑器、平台与治理基础设施正在并行构建。

准备优化你的开发者工具？

Big Hat Group 帮助组织规模化地标准化和部署 VSCode，结合 Intune、Windows 365 和 GitHub Copilot。无论你是在为受监管环境评估 BYOK、建立开发者生产力基线，还是在工程团队中推广 GitHub Copilot，我们都为每次交付带来实战经验。

联系 Big Hat Group，探讨你的开发者工具策略。

Big Hat Group 是一家 Microsoft 合作伙伴，专注于现代终端管理、Windows 365 与开发者生产力工具。