AI 将如何改变操作系统？第二部分：Windows

人工智能正在改变我们这些软件工程师构建软件的方式，开发者的工具偏好也随之迅速演变——例如，AI 编码平台已变得非常流行。同样，全球领先操作系统未来的版本也必将对智能体类工具提供更强的支持。

为了了解这一变化的全貌，我们采访了科技巨头微软的相关人士，他们详细介绍了 Windows 的发展规划，以及 AI 将在其中扮演的角色。

此前，该公司的一些 AI 措施曾让部分网民戏称其为“Microslop”。

Windows 团队的愿景颇具主张，既包括构建新的智能体原语，也包括对一些曾令开发者不满的决策进行调整。微软希望那些曾经远离该系统的开发者能够回归。

关键问题是：它能否成功？

欲了解更多，请参阅我们之前的一篇文章，重点讨论了对 GPU、NPU 和 DPU 的硬件支持、对本地优先型大语言模型的押注，以及对 AI 开发者工具的重视。

今天，我们将探讨：

1. 到底有多少开发者在使用 Windows？ 确切数据难以获得，但在初创公司中，macOS 显然比 Windows 更受欢迎；与此同时，Linux 也有可能在开发者中的普及度上赶超微软的这款操作系统。
2. 智能体身份与发现机制。 Windows 将原生支持智能体身份识别，并内置一个集中式的本地可用 MCP 服务器注册表，随系统一同发布。
3. 隔离智能体类工具。 微软正在打造一种与操作系统无关的隔离机制，使开发者能够更轻松地构建可安全运行各类工具的智能体。
4. 本地运行模型： Windows 正大力押注本地模型。WindowsML 是一个新的硬件抽象层，用于在 GPU、NPU 和 CPU 上构建并运行本地 AI 模型。未来，该操作系统计划在无需 NPU 的情况下预装小型语言模型（SLM）。我们还观看了一个令人印象深刻的演示：一款本地模型在搭载 NVIDIA 芯片的 Surface 笔记本上运行。
5. 在 Windows 上构建智能体： 该操作系统的其中一个目标是允许开发者使用一些自带框架和库来构建智能体，从而无需额外配置即可直接使用。
6. 更加贴近开发者： 过去，Windows 曾因一些备受争议的产品决策而饱受诟病，例如杂乱的开始菜单和搜索功能，这让许多开发者对其失去了兴趣。微软希望重新赢得他们的青睐，并正在积极回应相关批评——终于！
7. Windows 上的 Linux（WSL）： Windows 自带一个名为“适用于 Linux 的 Windows 子系统”（WSL）的嵌入式 Linux 环境，深受开发者欢迎。微软拥抱 Linux 的策略，或许正是吸引开发者从原生 Linux 和 macOS 转向 Windows 的关键，尽管这一思路看似反直觉。
8. Windows 与硬件： 自诞生之初，Windows 便致力于支持多种多样的硬件。最初它基于 x86 架构，但如今基于 ARM 的 Windows 终于开始成为一种颇具吸引力的替代方案。我们将探讨为何对 ARM 的支持迟迟未能落地，以及即将开展的 NVIDIA 合作。

我们采访了 Windows 团队的几位成员，深入了解微软针对该操作系统的战略考量：Pavan Davuluri（Windows 和设备部门执行副总裁）、Scott Hanselman（Microsoft CoreAI 和 GitHub 技术团队副总裁）以及 Logan Iyer（Windows 平台与开发者部门首席副总裁）。 非常感谢各位抽出时间！

1. 到底有多少开发者在使用 Windows？

尽管 Windows 仍以约 63% 的市场份额稳居主流个人电脑用户的首选桌面操作系统，但普遍感觉其在开发者群体中的受欢迎程度正在下降。

Windows 曾经深受开发者青睐……

一年前，《2025 年 Stack Overflow 调查》对专业用户的操作系统选择进行了统计。结果显示，总体而言，使用 Windows 的开发者仍是少数，但它依然是最受欢迎的单一操作系统。

尽管在调查中位居榜首，但使用 Windows 的开发者数量已远低于微软 XP 时代的峰值。与此同时，macOS 和各类 Linux 发行版也占据了相当可观的市场份额：

随后，Mac 开始迎头赶上……

此外，JetBrains 的一项调查也在去年询问了开发者在开发工作中使用的操作系统。结果如下：

有趣的是，有一半的开发者在开发时会同时使用不止一种操作系统。这项 JetBrains 调查表明，不少开发者会在不同操作系统之间切换工作。

调查还显示，macOS 已接近超越 Windows，成为开发工作中使用最广泛的独立操作系统。

……那么，Windows 在开发者市场的份额是否正在下滑？

就在上周，我和 Ivan 分别在 X 和 LinkedIn 上开展了两项社交媒体调查，这些调查很可能主要面向《The Pragmatic Engineer》的读者。

我们只提供了一个单选选项，不允许同时选择多个操作系统、Linux on Windows 或通过 WSL 使用 Linux。出乎意料的是，在近一万个有效回复中，Windows 仅位列第三，落后于 Linux：

根据现有研究，Windows 在开发者市场中的份额很可能正在下降，但具体降幅尚难确定。在风险投资支持的初创企业和大型科技公司内部，众所周知，近年来 Mac 已成为最受开发者青睐的开发机器，这在一定程度上得益于 M 系列芯片卓越的硬件性能，同时也因为这些企业在采购开发设备时并不刻意追求成本节约。

我们的社交媒体调查很可能过度反映了这一群体的倾向！

无论如何，微软都拥有它需要重新赢回的市场份额和开发者好感。从我们听到的信息来看，微软正在为此努力。

那么，《务实工程师》的读者们目前的操作系统使用情况如何呢？为了弄清楚这一点，请为您在软件开发时使用的主要操作系统投上一票。

投票结束后，您就可以看到结果：

接下来，我们就来看看下一版 Windows 打算如何在操作系统层面集成 AI 代理。

2. 代理身份与发现

在操作系统层面，代理越来越像普通用户。它们的会话可以持续数小时，使用多个程序，并占用诸如 UI 和剪贴板之类的系统资源。Windows 允许开发者构建能够与普通用户区分开来的代理型程序。

代理身份识别通过 Entra ID 实现，这是微软用于 Windows 中心化身份管理的工具。当代理拥有本地身份时，它会在任务管理器中显示为系统中的另一位用户。

如下图所示，任务按用户分组，任务管理器中有两位用户：kirupach（人类）和 V9-G4（代理）。所有针对人类用户的可观察能力现在也同样适用于代理用户。

代理必须在设计时就考虑到这种身份识别能力。试想一下，一个恶意的代理应用如何伪装成普通用户而不自报为代理——这在某种意义上正是病毒利用合法的系统功能来实现非法目的的方式。

因此，微软的防病毒软件 Defender 正在变得“代理感知”，并在 Windows 系统中扫描已知的本地代理活动，就像它扫描病毒一样。

代理发现：代理的实用性取决于它们能够交互的工具数量，而 Windows On Device Agent Registry（ODR）则是代理注册并发现可用 MCP 工具的中心化场所。

ODR 在本地管理和运行 MCP 服务器，并为文件资源管理器或系统设置等核心操作系统组件提供连接器。

假设您想开发一款专门的“照片整理代理”；该代理会根据主题对用户“照片”文件夹中的照片进行分类，首先运行图像分类器来识别照片的主题，然后将其归入相应的文件夹，如“聚会”、“户外”、“宝宝照片”等。

因此，“照片整理代理”需要具备读取和修改用户本地文件的能力，而这首先要由 Windows ODR 查找用于文件访问的 MCP 连接器。在发现文件资源管理器后，代理便通过文件资源管理器的 MCP 来访问并修改用户“照片”目录中的文件。

ODR 仍在开发中，目前仅向测试版用户开放，因此对其内部机制所知甚少，但 Origin Technology 的初步研究表明，ODR 存在一个有趣的实现细节。

研究人员通过对 ODR 行为的逆向工程证明，ODR 会将自身置于 MCP 客户端与其服务器之间充当代理。在我们更新后的“照片整理代理”示例中，情形如下：

“照片整理代理”以与上文依赖关系图相同的方式发现了文件资源管理器的 MCP 能力。然而，ODR 返回给代理的进程 ID 却是 ODR 自身：“照片整理代理”通过 ODR 与文件资源管理器的 MCP 进行通信！

通过将自身置于 MCP 客户端与服务器之间，ODR 可以检查往返的数据负载。这是一个非常有用的控制点，因为它使 Windows 能够检测潜在的危险行为。

不过，这种代理行为尚未得到微软的证实，其具体用途仍有待观察。

3. 隔离代理工具

工具是指代理用来在操作系统上执行操作的外部程序，例如原生的系统工具、第三方应用调用，甚至是代理自行编写的程序。赋予代理执行工具的权限可能意味着代码执行，因此确保代理工具在隔离环境中运行至关重要，以防止代理工具访问用户文件和会话。

微软执行容器（MXC）是 Windows 正在开发的一种新型代理隔离技术。开发者可以利用 MXC 在称为沙箱的隔离环境中启动代理工具，并通过 MXC 的隔离策略配置代理在沙箱内的访问权限。

隔离策略是基于 JSON 的配置文件，用于描述网络、文件系统、UI 和执行方面的限制。下图展示了 MXC 的工作原理：

假设您正在开发一款名为 OpenClaw 的代理应用。这款应用必然需要借助各种工具来完成任务，可能会涉及文件操作、网络请求、Shell 命令等。

这些操作都存在潜在风险，因此 OpenClaw 通过 MXC 的 spawnSandboxFromConfig() 方法来执行它们，该方法会启动一个新的受控进程，在其中安全地运行上述工具。

具体的进程隔离技术取决于隔离策略的配置。MXC 并不直接负责隔离，而是借助多种现有的隔离技术；例如，在 Mac 上，它会使用内置于 macOS 中的进程隔离层seatbelt。

速度与安全性的权衡：有些包含机制启动更快，运行成本更低。例如，启动新进程比启动新的 Windows 会话或新虚拟机更快。同时，在现有用户的 Windows 会话中运行新进程可能会暴露用户的文件系统。

MXC 允许开发者根据所运行操作的敏感度调整包含级别。Windows 中支持多种包含级别：

• 过程约束
• 会话约束
• 运行WSL容器
• 轻量化Hyper-V容器
• 完整虚拟机

选择合适的封闭层级是在爆炸半径和执行速度之间权衡。下面的简化示例展示了整个过程如何结合起来：

1. 策略对象指定容器化工作负载应如何被约束。它规定了网络、用户界面和文件系统的限制
2. createConfigFromPolicy 步骤配置整个容器。它取用包含策略对象、选定的隔离层（“进程”），并命名容器。
3. 应用随后会操作“WHAT RUNS”步骤中执行的内容
4. 最后，spawnSandboxFromConfig（） 运行容器并处理其输出。

Windows版OpenClaw作为原生应用并且是最早采用MXC进行隔离的代理之一。OpenClaw for Windows中的MXC包含配置作为标准Windows设置界面。

MXC 抽象化了代理的进程隔离，因此本例中的 OpenClaw 代理并不了解其工具运行的所有限制。因此，它可能会遇到试图执行其沙盒不允许的操作的情况。

结合代理身份，MXC将赋予企业对其代理的全舰队控制权。对于管理员，Microsoft将通过其提供MXC策略管理Intune企业设备车队管理产品。

MXC强制执行尚未被广泛采用，因此我们向Microsoft请教他们如何在内部使用MXC隔离自主代理的示例。他们与我们分享了一些使用案例：

这些案例说明了 Microsoft 如何自动化许多内部开发工作，以及 MXC 如何对代理隔离提供细致控制。MXC 正在开发中，但已能在 Windows、Linux 和 macOS 上运行。

因此，开发者能够统一地在操作系统中包含外部工具。

4. 本地运行模型

Windows ML是一个硬件无关的层，用于在Windows上本地运行AI模型。它的目标是为人工智能做DirectX对计算机图形学所做的事：抽象化硬件复杂度，无论底层模型的架构如何。

Windows ML 是 Microsoft 第二次尝试构建一个硬件无关层以运行机器学习模型的方案。DirectML，第一个尝试是一个用于在 GPU 上运行机器学习任务的库，这些 GPU 基于DirectX 12，Microsoft用于在Windows上运行游戏的图形库，于2019年发布。

那么，一个显而易见的问题是 Windows ML 有什么不同？他们说 Windows ML 相比 DirectML 有两个改进：

#1：更高层次的抽象和更好的硬件覆盖.DirectML 是一个底层库，开发者需要手动从简单的数学运算构建推理流水线，还要考虑内存布局等。

由于基于 DirectX，DirectML 仅支持 GPU。

相比之下，Windows ML 基于开放神经网络交换格式（ONNX），一种用于表示和运行神经网络的开放格式。使用所有流行机器学习框架构建的神经网络可以转换为称为ONNX图的ONNX格式，并运行于以下ONNX 运行时.

ONNX 运行时是一个开源的跨平台系统，用于训练和运行以 ONNX 格式定义的神经网络。Windows ML 为开发者提供了一个框架，能够运行在更广泛的硅片上，包括所有主流厂商的 GPU、NPU 和 CPU。

#2：没有驱动更新瓶颈：Windows ML 封装 ONNX 运行时，并通过提供硬件无关的 API 抽象化硬件特定的运行时优化。每个硬件厂商通过执行提供者（EPs）概念。

使用DirectML时，新的运行时优化必须通过驱动更新完成，这需要六个月才能获得有意义的采纳。

Windows ML根据用户硬件需求加载EP。例如，如果用户拥有NVIDIA GeForce RTX显卡，NVIDIA Tensor RTX 执行提供者下载并用于最大化GPU性能。

硬件厂商在使用Windows ML前，先构建并提交Microsoft PE进行认证和测试。大多数执行提供者现已上市也可在GitHub上获取。

小型语言模型（SLM）已内置于操作系统中。如果没有这些模型，开发者就不得不随应用一起分发模型，或者调用云端模型。即便借助 Windows ML 在本地运行模型应当更为便捷，但若只是想为应用添加一些简单功能，这样做仍然不值得付出额外的努力。

例如，过去在应用程序中对一段文本进行情感分析，需要调用云端托管的 AI 模型。这不仅会增加应用的运行成本，还可能导致延迟；而使用内置模型时，开发者可以假定这些模型已经存在，并像使用其他本地库一样直接调用。

比如，Aion-1.0-Instruct 模型已被集成到微软的浏览器 Edge 中。通过 Prompt API 调用，Aion 模型使开发者只需几行代码就能构建情感分析等应用。以下是来自 微软官网 的示例：

如今，即使是简单的 Web 应用，也能在无需持续支付 token 费用的情况下，具备由 LLM 提供支持的情感分析等功能。该演示仅使用 JavaScript，但预计在正式发布时，也将提供适用于原生应用及其他编程语言的版本。

团队能够自主运行自己的模型正变得愈发重要，尤其是在企业领域，这主要受成本攀升、模型可用性问题以及合规性要求等因素驱动。

在本地运行模型还开启了一种混合方案，这与我们 近期报道 的一种趋势高度契合：科技公司已成功将面向简单请求的 LLM 工作负载迁移至更低成本的模型，仅在需要高级推理时才使用前沿模型。

通过在本地运行模型，部分代理类任务可由本地 LLM 执行，而更复杂的任务则交由云端的前沿模型来完成。

在搭载 NVIDIA GPU 的新一代 Surface 笔记本上运行本地模型，确实令人印象深刻。在微软，Scott Hanselman 向我们展示了一款预发布版的 Surface 笔记本，该设备配备了 NVIDIA GPU，以本地模型的形式运行 Qwen，并与 GitHub Copilot 相连。

这款本地模型的生成速度高达每秒约 40 个 token！一旦此类笔记本广泛上市，与编码相关的应用场景便有望在本地运行，从而更具可行性。

5. 在 Windows 上构建智能体

除了 Windows 本身对智能体友好之外，微软还在投资智能体开发工具链，通过提供丰富的智能体开发框架，简化智能体应用的开发流程。