微软于 9 月 30 日推出 Visual Studio Code 1.140 稳定版。本次更新的重点围绕 GitHub Copilot Agent 工作流展开，官方将其概括为六项亮点：Copilot harness（智能体运行框架）、多文件夹会话（实验性）、远程任务委派（实验性）、HydraFusion 模型编排（研究预览）、共享 worktree 文件夹（实验性）以及企业级 AI 管控。

Copilot harness 统一多端 Agent 行为

新版增强了 Copilot harness。该框架由 Copilot SDK 提供支持，运行在基于智能体主机协议（AHP）的专用智能体主机进程中。借助这一设计，VS Code、独立的 GitHub Copilot 应用以及 Copilot 命令行工具三端的 Agent 行为得以保持一致。

由于 harness 运行在独立的主机进程内，用户可以从多个 VS Code 窗口连接到同一个 Agent 会话，便于在不同视图间协同处理任务。在聊天输入框的 harness 选择器中即可切换，对多数用户而言它已可能是默认选项。

多文件夹会话：一个会话协调多个仓库

VS Code 1.140 引入了实验性的多文件夹会话功能。在此之前，一个多聊天会话中的每条聊天都共享同一个文件夹与代码检出，修改容易相互串扰。新版本允许同一 Agent 会话中的不同聊天分别绑定到不同的代码仓库或 Git worktree，彼此的终端、任务、代码变更、拉取请求与合并状态相互隔离，避免改动意外串联。

官方列举的典型场景包括：在主聊天中处理一个仓库、同时创建对等聊天处理第二个仓库；或者让主聊天为每个对等聊天创建同一仓库的独立 worktree，从而对比不同实现方案——每个方案各自拥有分支、改动与拉取请求。该功能默认关闭，需要在用户级 settings.json 中针对所用 harness 将多根目录开关设为启用。

远程任务委派与 HydraFusion 编排

远程任务委派方面，新版 Agent 能够发现远程主机，并依据操作系统、内存、CPU 与负载情况自动选择主机，随后创建远程会话执行任务，省去每次手动从列表挑选主机的步骤。

HydraFusion 则以研究预览的形式提供。它是一个自适应的模型编排系统，会为每项编码任务自动选择模型与工作流：既可以用单一模型解决问题，也可以升级到更强的模型，还能让另一个模型对结果进行批评与修订，从而在速度、成本与代码质量之间取得平衡，无需用户自行协调多个模型。

共享 worktree 与企业级管控

共享 worktree 文件夹同样是实验性功能。它通过在多个 worktree 之间复用被忽略的文件夹，避免重复的依赖安装与产物拷贝，从而降低磁盘占用与等待时间。

企业级 AI 管控则面向组织管理场景，确保团队中的每个人都遵循统一的 AI 版本要求与默认设置。其中的一项能力是设置默认的 Auto 档位，使 VS Code 中的 Auto 模型在不同档位间运行——可在效率、均衡与智能之间取舍，管理员可指定默认档位，但不限制开发者另行选择。

整体来看，VS Code 1.140 把 Agent 工作流从单窗口、单仓库推进到可跨仓库、跨远程主机协同的阶段。对于日常依赖 Copilot 进行本地开发的工程师而言，多文件夹会话与远程委派降低了多端协作的摩擦，而 HydraFusion 则把多模型协作的复杂度交给了系统本身。

微软于 2026 年 9 月 25 日正式推出重新设计的 Copilot 应用，将其从单一的对话助手扩展为集聊天、编程与自主智能体于一体的”超级应用”。新版应用采用三标签页结构：主页（Home）、代码（Code）与 Autopilot。

主页：把 Office 融进对话

主页将原有的 Copilot Chat 与 Cowork 协作功能合并，并直接内嵌了 Word、Excel、PowerPoint 等办公应用能力。用户无需切换应用，就能在对话中实时生成、编辑和协作处理真实文档、表格与演示文稿。微软还计划加入一个名为 Today 的个性化仪表盘，集中展示重要邮件、会议邀请和 Teams 消息线程等内容。

微软 AI 办公业务首席营销官贾里德·斯帕塔罗（Jared Spataro）表示：”正如 Office 定义了 PC 时代的工作方式，新的 Copilot 旨在定义 AI 时代的工作方式。”

代码：用自然语言造应用

代码标签页是这次更新中最出人意料的部分。它允许任何人通过自然语言描述，创建应用、追踪工具、数据看板或自动化流程，并将结果以云端托管的内部应用形式与同事共享。斯帕塔罗介绍，代码功能采用与 GitHub Copilot 相同的底层技术，运行在沙盒环境中，安全地托管在企业租户内部。该功能将在今年晚些时候面向 Microsoft 365 Premium 与 Pro 订阅用户开放预览。

Autopilot：会”自己干活”的数字同事

Autopilot 由此前代号 Scout 的个人 AI 助手改名而来，从桌面应用转为云端版本。它拥有自己的身份、记忆、计算能力和工作空间，基于 Microsoft IQ 构建，能够监控 Teams 频道、运行周期性任务、跟进后续事项。用户可以在 Teams、Outlook、聊天和文档中像@提及同事一样@提及它，背后则由权限管理、审计与治理机制支撑。

计费方式转向”按量”

在收费模式上，微软作出明显调整：常规的 Copilot 用户订阅许可证继续覆盖基础聊天及 Office 应用内功能；而 Cowork、代码与 Autopilot 等智能体功能则采用按使用量计费，企业需借助新推出的 FinOps for AI 工具来管理 AI 支出，防止用量失控。

新主页与代码标签页将在未来几周内通过微软 Frontier 抢先体验项目逐步推出，Autopilot 则于 9 月底进入私密预览。客观来看，Copilot 在消费市场的表现不及 Claude 与 ChatGPT，但微软的核心商业客户正逐渐表现出兴趣。消息公布后，微软股价上涨约 4%。

微软于 9 月 25 日晚间正式发布新版 Copilot“超级应用”，将聊天、编程与智能体三类 AI 能力整合进同一个界面。微软为其赋予的新定位是“为工作而生的 AI”，并将其对生产力的影响与 Office 相提并论。

三大核心：Home、Code、Autopilot

新版 Copilot 由 Home、Code 和 Autopilot 三个标签页构成。Home 将 Copilot Chat 与 Cowork 合并，是用户打开应用后的默认首页；微软还计划在 Home 中加入 Today 功能，以个性化仪表盘的形式汇总重要邮件、会议请求与 Teams 讨论串，帮助用户快速掌握工作进展。

Code 是该应用中颇受关注的新增能力。借助它，任何人都可创建应用、跟踪器、仪表盘或自动化流程，并以云端内部应用的形式分享给同事。微软表示，Code 采用与 GitHub Copilot 相同的底层技术，运行在沙盒环境中，也能安全托管在企业租户内。

Autopilot 则被微软称为“数字队友”，其前身是名为 Scout 的桌面应用；更名后的版本转向云端，使个人 AI 助手在用户离线时也能持续执行任务。它拥有独立的云端计算机实例，可监控 Teams 频道、定期执行工作任务并负责后续跟进。微软强调，Autopilot 运行在用户租户中，具备独立的身份、记忆与工作区，并以 Microsoft IQ 为基础理解组织的运作方式，用户可像 @ 同事一样 @ 提及它。

按用量计费的新模式

在收费方式上，Cowork、Code 和 Autopilot 等智能体功能采用按使用量计费的模式，调用 Astra、Fable 等模型同样按实际用量收费；常规的 Copilot 用户订阅许可证则覆盖 Chat 以及 Word、Excel、PowerPoint、Outlook 和 Teams 中的 Copilot 功能。微软通过自动模型选择器为不同任务匹配模型，并面向 IT 管理员推出 FinOps for AI 工具，用于控制 AI 支出、防止智能体用量失控。

上线节奏

据微软方面介绍，Home 和 Code 将在“未来几周”内向 Frontier 计划的早期 AI 功能体验用户推送，Autopilot 将于本月晚些时候进入私人预览，Code 还计划于今年晚些时候向 Microsoft 365 Premium 和 Pro 订阅用户开放预览。

作为微软 AI 助手的一次重要整合，新版 Copilot 建立在将消费者版与企业版应用合并的基础之上。在竞争日趋激烈的 AI 办公赛道，微软能否凭借这套“为工作而生的 AI”迎头赶上，仍有待市场检验。

微软于 9 月 17 日发布 Visual Studio Code 1.138 版本更新。本次更新的核心方向是强化人工智能智能体（Agent）在编辑器中的协作能力，包括支持在开发容器中运行智能体会话、扩展 Codex harness 运行环境，并预览一项会话清理功能。

智能体会话进驻开发容器

新版最值得关注的变化，是允许智能体在本地开发容器中运行。启用配置项 chat.agentHost.devContainer.enabled 之后，凡是带有受支持开发容器配置的本地文件夹，都会在文件夹菜单中出现“使用开发容器”选项。点击该选项，智能体会话便会在对应的容器中执行，不过使用该功能需要预先安装 Docker。

与以往智能体直接调用本机全部工具与依赖不同，容器内的智能体只能使用项目明确指定的工具和依赖项，并严格遵循项目配置的运行环境。这种设计让智能体的操作被限定在项目边界之内，减少了误触本机环境的隐患，也让“在同一套依赖下复现结果”变得更可靠。

Codex harness 打通 ChatGPT 与 VS Code

1.138 版本还扩展了 Codex harness 的支持范围，使同一段会话可以在 ChatGPT 应用与 VS Code 之间延续。用户既可以选择 GitHub Copilot 订阅，也可以选择 ChatGPT 订阅；若两类账户同时登录，还能在模型选择器中直接切换所使用的模型。

所谓 Codex harness，是指围绕 Codex 模型搭建的一整套运行环境与控制机制，负责把模型接入应用、工具与工作流。在 VS Code 中，Codex 能够调用编辑器的内置工具、扩展工具以及 MCP（模型上下文协议）工具。若使用的是基于 ChatGPT 的模型，Codex 还能在会话中直接调用图像生成工具。

会话清理功能进入预览

本次更新还以预览形态推出了会话清理功能。它能够让开发者对已经完成的工作做调整，同时把对话保留下来以备日后查阅。在合并了所有非活跃会话对应的拉取请求之后，智能体窗口会支持将相关会话标记为“已完成”。

整体来看，VS Code 1.138 把人工智能智能体从“对话窗”进一步推向“工程执行单元”：开发容器隔离、跨应用会话延续、可清理的会话管理，三者共同指向同一个目标——让智能体更可控、更可复现地参与到真实开发流程中。

评分是怎么来的

下表综合自掘金社区《2026 年热门 AI 编程工具横评》、极客日志及腾讯云开发者社区等多份实测，满分为 10 分，由一线开发者在代码补全、上下文理解、Agent 能力、响应速度、生态集成与中文支持等维度打分。

数据截至 2026 年 9 月，价格来自各产品公开定价与 CSDN 实测，评分为社区横评参考值，非官方基准。

国产工具为什么中文更强

中文支持一栏中，通义灵码、文心快码、Trae 均拿到 9.0 以上高分。原因在于这些工具针对中文技术文档、国内主流框架（如 Vue、Spring Cloud、微信小程序）做了专项优化，在中文注释理解、本地报错解读、国产接口调用上更顺手。Claude Code、Cursor 虽在代码生成与架构理解上领先，但中文语境下的“语感”仍逊一筹。

贵的一定好吗

单看综合分，Claude Code 以 9.3 居首，但其月费高达 100–200 美元，且响应速度评分仅 7.5；GitHub Copilot 月费约 10 美元、响应速度 9.5，对日常补全性价比极高。对预算敏感的个人开发者与初创团队，通义灵码、Trae 的免费档已能覆盖大部分场景。换言之，分数差距远小于价格差距，“够用且便宜”往往比“单项最强”更划算。

按角色怎么选

个人开发者快速验证创意，首选 Trae、通义灵码等免费且中文友好的工具；重度重构、复杂多文件任务，Claude Code 与 Cursor 的 Agent 能力更稳；企业团队追求管理成本与生态成熟，GitHub Copilot 仍是安全牌；深度依赖阿里、百度云生态的团队，可优先考虑通义灵码与文心快码的无缝集成。

AI 编程工具会取代程序员吗？

不会。当前工具擅长补全、生成与重构，复杂架构决策、业务理解与调试仍需人来把控。更准确的说法是“用 AI 的程序员取代不用 AI 的程序员”。

免费工具够用吗？

对个人学习与中小项目基本够用。免费档通常在并发、上下文长度与企业安全合规上有上限，规模化生产环境建议升级付费或私有化部署。

国内团队选哪个最稳？

重视中文与本地框架选通义灵码；已在微软生态用付费选 GitHub Copilot；要数据自主管私有化选支持本地部署的开源方案。可先用免费档跑通原型再决定。

本文基于掘金社区《2026 年热门 AI 编程工具横评》、CSDN 开发者实测及各家官方定价页（截至 2026 年 9 月）综合整理，评分为社区横评参考值，实际体验以个人项目为准。

砍掉旋钮，价格直接减半

熟悉罗技产品线的用户会觉得这套硬件似曾相识。此前推出的 MX Creative Console 由一块 LCD 键盘加一个独立旋钮控制器组成，主要服务视频剪辑、修图这类需要连续调参的创意工作，官方定价 199.99 美元。

MX Keypad 相当于把其中的键盘部分单独拿出来卖，去掉了旋钮模块，价格正好是 Creative Console 的一半。取舍很直接：失去了拖动时间线、缩放画面、调整笔刷大小这类连续参数的模拟控制手感，换来的是更低的价格和更小的桌面占用。

九个 LCD 按键之外，机身另有两个翻页按钮，可在最多 15 个页面之间切换，理论上能承载超过一百个动作。

配置交给 Logi Options+，按应用自动切换

所有自定义都通过免费的 Logi Options+ 应用完成。用户可以把快捷键、保存好的提示词、脚本和宏分别绑定到每个按键上。更实用的是应用感知配置文件：当用户从一个软件切到另一个软件时，键盘布局会自动跟着换。同一排物理按键在 VS Code 里是代码操作，在 Slack 里是斜杠命令，在 Chrome 里又变成另一套动作，罗技列出的支持名单还包括 IntelliJ IDEA、Figma 和 Zoom。

Logi Marketplace 提供插件、配置文件和图标包，软件内还带有图标编辑器，用户可以自行修改每个按键屏幕上显示的图案。

与 GitHub 联合开发，附赠三个月 Copilot Pro+

MX Keypad 是罗技与 GitHub 密切合作开发的产品，产品设计过程还吸纳了 GitHub 社区与罗技 MX Collective 社区的反馈。

出厂即带 GitHub 原生集成，覆盖 VS Code 和 GitHub Copilot 应用，罗技表示后续会继续扩展支持的工具范围。每一台 MX Keypad 都附赠三个月 GitHub Copilot Pro+，可在 Logi Options+ 中兑换，新老订阅用户均可领取。

罗技副总裁兼总经理 Anatoliy Polyanker 称，如今的编程能力取决于开发者能多轻松地在不断增加的 AI 工具之间来回切换，MX Keypad 把一个物理控制中心放在指尖，让 AI 工作流的编排更快、更直观。GitHub 开发者关系副总裁 Martin Woodward 则表示，好的开发者工具应该”不碍事”，MX Keypad 让使用 GitHub Copilot 变得像工作流的自然组成部分。

社区插件已覆盖 Claude Code 与 Codex

除了官方合作，第三方生态也已经跟上。罗技提到社区已经在 Logi Marketplace 发布了面向 Claude Code 和 OpenAI Codex 的插件，可在物理按键上实现智能体状态追踪与终端／CLI 控制——开发者能直接从按键屏幕看到某个 AI 智能体当前是否在运行。

想走得更远的开发者可以使用 Logi Actions SDK 自建插件，SDK 支持 C# 和 Node.js，并配有对 AI 友好的文档，编程智能体可以据此直接生成集成代码。罗技称这套体系可覆盖超过一亿台兼容的罗技设备。

9to5Mac 编辑在上手测试中做了一件颇有意味的事：把 MX Keypad 连到 MacBook Air 后，让 Codex 通过计算机操作能力自行在 Logi Options+ 里配置按键——用 AI 智能体去配置一块将来用于操作 AI 智能体的键盘。

规格与上市信息

MX Keypad 通过 USB-C 连接，需要 macOS 13 或更高版本，或 Windows 10 及以上系统。机身尺寸约 3.6×3.1 英寸，重 96 克，放在笔记本键盘旁边不占多少地方。

环保方面，石墨黑版本使用 64% 认证消费后再生塑料，浅灰版本为 49%，包装采用 FSC 认证森林及其他受控来源的纸材。

产品自 9 月 8 日起在部分市场通过 logitech.com 开售，提供石墨黑（Graphite）和浅灰（Pale Grey）两种配色，售价 99.99 美元。中国市场的具体上市时间与售价，罗技尚未公布。

30 分钟造出一款原生应用

这份指南面向的是初学者。按照微软给出的流程，开发者借助免费的 GitHub Copilot，便可以让 AI 智能体自动添加功能、运行测试、把应用打包成 MSIX 安装包，再提交到 Microsoft Store。整个过程免费，需要的人工干预很少，开发者不必再经历传统应用开发中那些繁重的编码环节。

不过，更值得关注的是微软随指南一并提供的 AI 辅助迁移方案，尤其是针对既有 WPF 与 UWP 应用的迁移指引。这折射出微软解决 Windows 长期”原生应用匮乏”问题的真实思路：让新应用更容易开发，让老应用更容易迁移，同时把两个过程中繁琐的活交给 AI。

专为 WinUI 而生的智能体

新应用开发流程建立在 VS Code、.NET 10、WinUI 项目模板、GitHub Copilot 以及 WinUI Agent 插件之上。需要区分的是，这里的 WinUI Agent 不同于微软此前主推的通用 Copilot 聊天机器人，它被赋予了针对 WinUI 设计、代码审查、UI 测试、应用打包与框架迁移等任务的专门能力。微软还建议将它接入 Microsoft Learn 的 MCP 服务器，以便在查询时获取最新的 WinUI 接口文档。

在迁移指引中，微软没有把工作简化为”查找替换”。以 WPF 为例，System.Windows.* 命名空间需要整体迁移到 Microsoft.UI.Xaml.*，微软为此给 AI 智能体提供了一整套涵盖控件、线程、窗口管理、DPI 与数据绑定的替换对照表，并附上初始提示词，告诉智能体应重点排查哪些问题。针对 UWP 到 WinUI 3 的迁移，微软直言 UWP 已不再处于积极开发状态，WinUI 3 与 Windows App SDK 才是后继方案。

从”3″中走出的生产平台

在 Build 2026 大会上，微软明确将 WinUI 称作”Windows 应用的生产平台”，并从名称中去掉了”3″字，向开发者传达一个信号：未来不会再推倒重来地重构整个框架。微软还承诺降低运行时内存占用、新增 DataGrid 与图表支持、改善与 WPF 的互操作，并进一步扩大开源——事实上，如今的 WinUI 已经完全开源。

微软自身也在用 WinUI 3 替换 Windows 11 中一批历史久远的界面组件，自动播放、打印管理等已率先改用新框架，后续还会有更多。微软强调，推广原生应用并非认为 WebView2 或 Electron 是糟糕的技术，其官方文档仍将 WebView2 视为混合开发的合理选择。颇具反差的是，Windows 11 自带的天气应用恰恰基于 WebView2 构建，在空闲状态下就会占用约 1.2GB 内存，约为苹果原生 macOS 天气应用的 5 倍。

你大概听过这样的说法：AI 正在让程序员变成“10 倍工程师”。但一份来自 ACM Queue 的研究却先问了另一个问题——程序员的时间，到底有多少在写代码？答案是，不到 14%。

2025 年，微软研究团队追踪了 450 多名工程师后发现，开发者平均每天花在写代码上的时间只有 14%。早前研究里，状态较好的工作日编码占比约 18%，状态差的工作日则跌到 11%。读文档、开会、理解旧系统、调试、测试、配置环境、做设计，才是占据他们日程的大头。

这个数字本身并不新鲜。新鲜的是，生成式 AI 铺天盖地宣传“自动写代码”时，恰好暴露了行业里长期被忽略的一个事实：把写代码速度翻倍，整体效率的提升也到不了 15%。因为写代码从来不是瓶颈。

02 微软团队总结的八大误区

这篇题为 *Eight Myths on Software Engineering and GenAI* 的论文由 Jenna Butler、Brian Houck、Margaret-Anne Storey 等微软与高校研究者共同撰写，逐条拆解了围绕生成式 AI 与软件工程的主流误解。

误区一：开发者大部分时间都在写代码。 如上所述，14% 的数字已经否定了这一点。

误区二：写代码是项目瓶颈。 如果编码只占 15%，即使 AI 把编码速度翻倍，对整体进度的推动也小于 15%。更麻烦的是，快速产出未经验证的代码会把压力转移到下游的代码审查、测试和集成，反而可能拖慢交付。

误区三：AI 生成的代码行数是衡量生产力的好指标。 比尔·盖茨曾把“用代码行数衡量软件生产力”比作“用飞机重量衡量飞行进度”。2014 年的一篇统计研究也指出，代码行数并未通过效度检验，作为指标用途有限。微软 CEO 在 2025 年 4 月提到公司“最多 30% 的代码由 AI 编写”，但这仍不能说明质量、速度或商业价值。

误区四：AI 对所有工程师的帮助都一样。 研究结果并不一致。有研究发现 GitHub Copilot 带来明显提升，也有研究显示开源资深开发者使用 AI 后完成任务的时间反而平均增加了 18%。有经验的开发者在熟悉任务上获益更大，但专业年限与提示词信心反而呈负相关。

误区五：AI 能把普通开发者变成 10 倍开发者。 很多研究基于孤立的小型任务得出“55% 生产力提升”的结论，但真实团队环境复杂得多。开发者之间的表现差异主要来自任务本身，而非恒定个人能力。

误区六：用好 AI 是开发者个人的事。 文章指出，真正改变生产力的是组织层面的系统工程，而不是每个人自己摸索提示词。

误区七：好用的 AI 工具自然会被采用。 Stack Overflow 2025 年调查显示，80% 的开发者用过 AI 工具，但只有 29% 相信其准确性。能力惩罚、伦理担忧、对“去技能化”的恐惧都会拖慢采用。

误区八：有了 GenAI，大企业就能以小团队速度创新。 初创公司依赖公开框架和代码，正是大模型训练数据的主要来源；而企业依赖专有遗留系统，AI 没见过这些代码，还要面对合规、安全、隐私和向后兼容的约束。

03 这对企业和团队意味着什么

研究者认为，当前围绕 AI 写代码的叙事，本质上是在优化一个本来就不够大的工作切片。如果组织真正想提升软件交付效率，重点应该放在：减少会议和上下文切换、改善遗留系统可理解性、把代码审查和测试流程做得更轻更快，以及建立可信的 AI 使用规范。

换言之，AI 可以是杠杆，但它撬动的支点不是键盘，而是整个工程系统的设计。

来源：ACM Queue / *Eight Myths on Software Engineering and GenAI*（2026 年 5 月）

原因不是苹果嫌麻烦，而是大模型让”找漏洞”这件事的产能突然爆了。如今的模型能自己发现漏洞、把多个漏洞串成攻击链、再写出可用的利用代码，审核团队根本跟不上提交速度。苹果自己也认这股力量——在 iOS 26.5.2 那批更新的安全说明里，它公开致谢了借助 OpenAI、Anthropic、Z.ai 等工具的研究者；其中安全公司 Calif.io 今年五月称，用 Anthropic 的 Mythos Preview 模型，五天就在 M5 芯片的 Mac 上做出了一个可用的内核内存破坏利用。

代价是真人也被误伤。七人小团队 Bynario 今年向苹果报了五个漏洞、去年报了八个（其中一个已在十一月的更新中被修复），结果提交权限被封。《金融时报》报道之后，苹果才重新联系上他们，开始复核手上的成果，包括一条可能让攻击者完全控制 Mac 的提权链。

说白了，这不是苹果一家的难题。GitHub 前几天也给自己的赏金计划分了层级，专门把认证过的研究员和刷量提交区分开。整个行业过去按”人能提交多少”设计的流程，正在被按”机器能提交多少”重新压测。

如果你在做安全研究，眼下更值得投入的或许不是找得更多，而是证明得更清楚——一份能跑通的复现，比十份看着像样的报告管用。

来源：9to5Mac（Marcus Mendes）、英国《金融时报》

这场电话会议在 7 月 29 日举行。纳德拉说：”Copilot 正在从聊天快速演进到 Cowork，再到 Autopilots。本季度，我们要把这些 Copilot 体验整合到一个超级应用里，包括代码能力……这是重要的一步，我期待很快分享更多细节。”

他同时明确，这款应用将”同时覆盖消费者与商业两类使用场景”。

四个产品，一个入口

根据《The Verge》记者艾玛·罗斯（Emma Roth）的报道，这款超级应用将把微软目前分散在各处的 AI 能力收拢到同一个入口下，具体包括四条产品线：

• Copilot 聊天助手：面向通用交互的对话机器人
• GitHub Copilot：面向开发者的编程助手
• Copilot Cowork：支持团队协作的办公层
• Autopilots：微软对自主智能体的称呼，可在无人逐步干预的情况下执行多步长任务

这一整合此前已有伏笔。《财富》杂志早在今年 5 月就报道过微软在秘密筹备一款超级应用，纳德拉此次的表态相当于官方确认。他在会议后段还提到，这将成为企业内不同岗位每天都会打开的旗舰应用。

对用户而言，好处比较直观：如果一个人平时要在写作用的 Copilot、写代码用的 GitHub Copilot、处理杂活用的智能体工具之间来回切换，合并之后就只剩一个应用。微软表示，目前 Copilot 付费席位已超过 3000 万个，这意味着相当规模的用户会直接感受到这一变化。

分散的品牌，也是要修的问题

对微软来说，整合的意义不止于产品层面。

过去两年，企业 IT 采购方普遍抱怨 Copilot 产品线过于混乱：不同的订阅方案、不同的管理后台、不同的账单条目，而员工眼里其实就是”工作里那个 AI”。把这些收进一个应用，等于把销售环节压缩成一份许可证和一个产品界面。

微软真正的结构性优势在于分发渠道——Copilot 已经嵌入 Windows、Office 和 Azure，但支离破碎的品牌形象一直在拖累采用率。因此这次的”超级应用”既是产品调整，也是一次品牌纠偏，把三类受众收敛到同一个认知模型里。

值得注意的是，纳德拉的措辞是”包括代码能力，在一个超级应用里”，这暗示编程助手仍会作为统一产品内的一项独立能力存在，而不是作为单独产品消失。微软尚未说明现有 GitHub Copilot 订阅用户是否会被自动迁移。

同行都在做同一件事

这个方向并非微软独有。Anthropic 的 Claude 已经提供了整合旗下全部工具的应用；OpenAI 也推出了 ChatGPT Work，把 ChatGPT 与编程工具 Codex 融合在一起，瞄准的正是微软借 Copilot 争取的同一批企业客户。

不过前车之鉴同样存在。OpenAI 自家超级应用的推出过程并不顺利，公司近期公开承认那款产品”确实有点乱”。微软能否避开同样的坑，还需要观察。

另一个潜在风险是，把四个各具特点的产品塞进同一个界面，最终体验可能反而不如单独使用时。微软在这方面战绩参半：Teams 作为合并产品是成功的，而统一 Outlook 与旧版邮件应用的努力则拖了很多年。企业管理员大概率会要求对”哪些 Copilot 能力对哪些员工开放”有细粒度控制权，而超级应用是否具备这一级别的策略管理，目前尚不清楚。

耐人寻味的是，纳德拉近期还表达过另一种倾向——微软正在从”应用”转向以智能体为中心。AI 时代仍然很新，围绕 AI 界面的设计趋势和最佳实践都还在剧烈变动。

作为对照，苹果至今没有任何走向超级应用的迹象，仍在持续推出各自独立的专用应用。这一策略未来是否会调整，同样值得关注。

从财务背景看，纳德拉的这番表态是在微软季度营收 900 亿美元的成绩单旁边给出的，AI 与云业务是主要增长引擎。选择在财报会议而非独立发布会上官宣，本身也说明微软把超级应用定位成一个营收故事，而非一次产品演示。

来源：9to5Mac（https://9to5mac.com/2026/07/30/microsoft-will-launch-new-super-app-for-copilot-soon/）、The Verge、Digital Trends