深入了解 Windows 团队如何将 AI 集成到其操作系统中：例如，他们正在为代理添加类似于用户身份的标识。这是我在操作系统层面上看到的第一个对 AI 代理有明确立场的方法——其他操作系统肯定也会采取类似措施。深入阅读：https://newsletter.pragmaticengineer.com/p/windows-and-ai…

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

来源：https://newsletter.pragmaticengineer.com/p/windows-and-ai
AI 正在改变我们软件工程师构建软件的方式，开发者的工具偏好也随之迅速演变——例如 AI 编程工具如今已非常流行。同样地，未来全球领先操作系统的版本无疑将提供更多对代理工具的支持。

为了了解变化如何发生，我们与科技巨头微软的团队进行了交流，他们详细分享了 Windows 的计划以及 AI 将如何发挥作用。此前，该公司的 AI 努力曾被一些用户在线戏称为“微软懒懒”（Microslop）。

Windows 团队的愿景具有明确的立场，包括构建新的代理原语，以及扭转一些曾让工程师感到困扰的决策。微软希望那些曾避开该系统的开发者回归。最大的问题是：它会成功吗？

如需更多信息，请查看之前的一篇文章，了解领先 Linux 发行版 Ubuntu 由于 AI 而发生的变化（https://newsletter.pragmaticengineer.com/p/ubuntu-and-ai），重点关注 GPU、NPU 和 DPU 的硬件支持、对本地优先 LLM 的押注以及对 AI 开发者工具的关注。

今天，我们将讨论：

1. 到底有多少开发者使用 Windows？ 很难获得确切数字，但 macOS 在初创公司中似乎远比 Windows 受欢迎，而 Linux 在开发者中的流行度也可能即将超越微软的操作系统。
2. 代理身份与发现。 Windows 原生支持代理身份识别，并内置本地可用的 MCP 服务器集中注册表。
3. 隔离代理工具。 微软正在构建一个操作系统无关的隔离机制，这应该能让开发者轻松构建安全运行工具的代理。
4. 在本地运行模型： Windows 正大力押注本地模型。WindowsML 是一个新的硬件抽象层，用于在 GPU、NPU 和 CPU 上构建和运行本地 AI 模型。该操作系统计划未来无需 NPU 即可提供小型语言模型（SLMs）。我们还看到了一个令人印象深刻的演示，展示了一个本地模型在使用 NVIDIA 芯片的 Surface 笔记本电脑上运行。
5. 在 Windows 上构建代理： 该操作系统的一个目标是允许使用开发者可以放心其可用性的、有主见的框架和库来构建代理。
6. 更友好开发者： Windows 曾因有问题的产品决策而饱受诟病，导致开始菜单和搜索功能混乱，令许多对该操作系统失去兴趣的开发者感到沮丧。微软希望他们回归，并正在解决这些批评——终于！
7. Windows 上的 Linux（WSL）： Windows 内置了一个名为 Windows Subsystem for Linux (WSL) 的 Linux 子系统。它在开发者中相当受欢迎。Windows 拥抱 Linux 可能正是让开发者从原生 Linux 和 macOS 转换过来的策略，尽管这一策略听起来有违直觉。
8. Windows 与硬件： 从早期开始，Windows 就一直致力于支持广泛的硬件。该操作系统最初基于 x86，但 Windows on ARM 终于开始看起来像一个不错的替代方案。探讨 ARM 支持为何花了这么长时间，以及即将到来的 NVIDIA 合作。

我们与 Windows 团队的人员进行了交谈，以了解微软操作系统战略背后的思考：Pavan Davuluri（Windows 与设备执行副总裁）、Scott Hanselman（Microsoft CoreAI 和 GitHub 副总裁、技术成员）和 Logan Iyer（Windows 平台与开发首席副总裁）。

尽管 Windows 仍然是主流电脑用户最流行的操作系统，根据 Statcounter（https://gs.statcounter.com/os-market-share/desktop/worldwide/#monthly-202508-202608）的数据约占 63% 的市场份额——但强烈的共识是，它在开发者中的受欢迎程度已下降。

一年前，2025 年 Stack Overflow 调查询问了专业用户对操作系统的选择。结果发现，只有一小部分开发者使用 Windows——尽管它仍然是最受欢迎的单一操作系统。尽管在调查中排名第一，但使用 Windows 的开发者数量实际上远低于微软 XP 时代的巅峰时期。与此同时，macOS 和各种 Linux 发行版也显示出可观的市场份额。

此外，JetBrains 的一项调查（https://devecosystem-2025.jetbrains.com/#methodology-and-data）去年也询问了开发者的开发操作系统使用情况。结果如下：

有趣的是，一半的开发者使用多个操作系统进行开发。这项 JetBrains 调查表明，许多开发者在工作中会切换操作系统。调查还发现，macOS 作为最常使用的独立开发操作系统，正接近超越 Windows。

就在上周，我本人和 Ivan 在 X (https://x.com/GergelyOrosz/status/2099592997742477655?s=20) 和 LinkedIn (https://lnkd.in/p/eNqJZypD) 上进行了两项社交媒体调查，这些调查很可能主要展示给了同样是 The Pragmatic Engineer 的读者。我们提供了一个单一选择——没有选项可以选择多个操作系统、Windows 上的 Linux 或通过 WSL。我们惊讶地发现，在近 10,000 份综合回复中，Windows 排在 Linux 之后位列第三：

你使用什么操作系统来构建软件？基于 9,937 份回复，调查于 2026 年 9 月进行

根据当前研究，Windows 在开发者市场的份额很可能正在萎缩，但很难判断下降了多少。在风投支持的初创公司和大型科技公司内部，Mac 多年来一直是最受欢迎的开发者设备，这已是一个公开的秘密，部分原因是 M 系列 CPU 卓越的硬件性能，也因为这些公司在购买开发者设备时不打算省钱。我们自己的社交媒体调查很可能过度代表了这一群体！

无论如何，微软既需要赢回市场份额，也需要赢回开发者的青睐。根据我们从他们那里听到的信息，微软正在尝试这样做。

那么，《The Pragmatic Engineer》的读者们对操作系统的使用情况如何呢？为了弄清楚这一点，请为你主要用于开发软件的操作系统投票。投票后，你可以查看结果：

接下来，让我们深入了解 Windows 的下一版本如何在操作系统层面集成 AI 代理。

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

代理识别通过 Entra ID (https://learn.microsoft.com/en-us/entra/agent-id/agent-users) 实现，这是微软在 Windows 中用于集中身份管理的工具。当代理具有本地身份时，它在系统中的行为就像另一个用户，在任务管理器中可见。下面，任务按用户分组，任务管理器中有两个用户：kirupach（人类）和 V9-G4（代理）。现在，为人类用户提供的所有可观测性功能也适用于代理用户。

任务管理器显示人类用户和代理用户（kirupach 和 V9-G4）。来源：微软

构建代理时必须考虑此代理识别功能。想想一个流氓代理应用程序如何可以冒充用户而不自行注册为代理——从某种意义上说，这就是病毒的操作方式，利用合法的操作系统功能达到非法目的。这就是为什么微软的防病毒软件 Defender 正在变得“代理感知”，并像扫描病毒一样扫描 Windows 以检测已知的本地代理活动。

Microsoft Defender 的 AI 资产功能可以扫描已知的代理活动。来源 (https://techcommunity.microsoft.com/blog/microsoftthreatprotectionblog/the-next-frontier-in-endpoint-security-securing-local-ai-agents-with-microsoft-d/4524651)：微软

代理发现： 代理的效用取决于其能够交互的工具，Windows On Device Agent Registry（ODR (https://learn.microsoft.com/en-us/windows/ai/mcp/odr-tool)）是代理注册和发现可用 MCP 工具的集中场所。ODR 在本地管理和运行 MCP 服务器，并为文件资源管理器或系统设置等核心操作系统组件提供连接器。

假设你想构建一个专门的“照片整理代理”；该代理按主题整理用户照片文件夹中的照片，首先运行图像分类器来理解照片的主题，然后将它们放入相关文件夹，如“聚会”、“户外”、“宝宝照片”等。

因此，“照片整理代理”需要能够读取和更改用户的本地文件，这首先需要 Windows ODR 找到文件访问功能的 MCP 连接器。发现文件资源管理器后，代理使用文件资源管理器 MCP 访问和修改用户照片目录中的文件。

当代理访问依赖项时的 ODR 和内置 MCP

ODR 仍在开发中，仅供测试人员使用，因此对其内部细节知之甚少，但 Origin Technology 的初步研究 (https://www.originhq.com/research/msft-odr-mcp) 揭示了 ODR 一个有趣的实现细节。通过逆向工程 ODR 行为，研究人员证明 ODR 将自身置于 MCP 客户端和其服务器之间的代理位置。在我们更新的“照片整理代理”示例中，这看起来是这样的：

不止是一个注册表：ODR 还充当 MCP 客户端和服务器之间的代理

“照片整理代理”发现文件资源管理器 MCP 功能的方式与上面依赖项图中相同。然而，ODR 发送给代理的进程 ID 是 ODR 自身：“照片整理代理”通过 ODR 与文件资源管理器 MCP 通信！

通过将自己置于 MCP 客户端和服务器之间，ODR 可以检查往返的负载。这是一个有用的控制点，因为它使 Windows 能够检测潜在的危险行为。然而，这种代理行为尚未得到微软的证实，因此如何使用它还有待观察。

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

微软执行容器（MXC (https://blogs.windows.com/windowsdeveloper/2026/06/02/windows-platform-security-for-ai-agents/)）是 Windows 正在开发的新代理隔离技术。开发者可以使用 MXC 在称为沙箱的隔离环境中生成代理工具，并且代理在沙箱环境内的访问权限是通过 MXC 包容策略（Containment Policies (https://github.com/microsoft/mxc/blob/main/docs/sandbox-policy/0.8.0/policy.md)）配置的。

包容策略是基于 JSON 的配置文件，描述网络、文件系统、UI 和执行限制。下图说明了 MXC 的工作原理：

代理在包含环境中使用 MXC 运行代码，支持不同的隔离技术和操作系统

假设你正在构建一个像 OpenClaw 这样的代理应用程序。此应用程序必然需要使用工具来完成工作，并且可以使用文件操作、Web 操作、shell 命令等。这些都是潜在的危险操作，因为 OpenClaw 通过 MXC 的 spawnSandboxFromConfig() 方法执行它们，该方法生成一个新的受控进程，这些工具可以在其中安全运行。所使用的进程隔离技术取决于包容策略配置。MXC 本身并不执行隔离，而是为此使用多种现有的隔离技术；例如，在 Mac 上，它会使用 seatbelt（https://theapplewiki.com/wiki/Dev:Seatbelt），这是 Mac 操作系统内置的进程隔离层。

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

MXC 允许开发者根据所运行操作的敏感度调整隔离级别。Windows 中提供多个隔离级别：

• 进程隔离
• 会话隔离
• 运行 WSL 容器
• 轻量级 Hyper-V 容器
• 完整虚拟机

选择正确的隔离级别是在影响范围和执行速度之间的权衡。下面的简化示例展示了所有这些如何协同工作：

开发者如何使用 MXC 隔离代理

1. 策略对象指定容器化工作负载应如何被约束。它指定了网络、UI、文件系统限制。
2. createConfigFromPolicy 步骤配置整个容器。它接受包容策略对象、选择的隔离级别（“process”）并为容器命名。
3. 然后，应用程序操作“运行内容”步骤中将执行的内容。
4. 最后，spawnSandboxFromConfig() 运行容器并处理其输出。

Windows 版的 OpenClaw 作为原生应用程序 (https://docs.openclaw.ai/platforms/windows) 发布，是首批采用 MXC 进行隔离的代理之一。Windows 版 OpenClaw 中的 MXC 包容配置被打包为标准的 Windows 设置屏幕。

OpenClaw Windows 应用程序的包容配置界面。来源：微软

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

OpenClaw 代理尝试在其沙箱外部执行操作。来源：微软

速度与安全性的权衡是关键： 由于 MXC 支持多个隔离级别，代理应用程序的开发者必须选择合适的级别。例如，使用“session”隔离（新的 Windows 会话）意味着代理工具在更安全的环境中运行，无法访问用户的文件系统，但启动更慢。另一方面，“process”隔离启动更快，但新进程可以访问用户在该会话中的文件系统。正确选择隔离级别可确保代理工具以适当的安全级别运行。

跨平台隔离： MXC 被设计为操作系统无关的。在 Mac 上，MXC 使用 seatbelt 进行隔离。在 Linux 上，MXC 使用 seccomp-bpf。这意味着开发者可以编写一次代理逻辑，并在多个平台上安全运行，而无需为每个平台重写隔离逻辑。这显著降低了跨平台代理应用程序的开发负担。

Windows 的下一步计划： Windows 团队计划使 MXC 成为未来 Windows 版本中的标准组件。他们还计划提供更高级的隔离选项，如基于虚拟化的安全 (VBS) 隔离，以满足高安全性场景的需求。

开发者工具改进： 微软还在改进 Windows 上的开发者工具链，包括更好的 WSL 2 集成、更新的 Visual Studio 和 VS Code 版本，以及针对 AI 开发工作流的新工具。目标是让 Windows 再次成为 AI 代理开发的首选平台。

总结： 微软通过 Windows 正在采取一种全面且“有主见”的方法，将 AI 代理集成到操作系统中。从代理身份识别、发现到隔离，Windows 正在为代理构建必要的基础设施。虽然挑战依然存在，特别是赢回开发者的信任，但这些新功能表明了微软的承诺。其他操作系统可能会效仿，但目前，Windows 在操作系统级 AI 代理支持方面正在设定高标准。