不满足于 Copilot，微软给你捏了个24 小时在线的「虾同事」

你准备好和它共事了吗？

作者｜桦林舞王

编辑｜靖宇

当地时间 6 月 2 日，微软在 Build 2026 开发者大会公布了模型、硬件、代理控制规范等一系列产品。但其中，比较引人注目的，是 Scout——一个 7x24 小时在线的 AI 助理。

Scout 不是一个对话框，不是一个插件，而是一个真实出现在你 Teams 联系人列表里的「数字同事」，可以帮你准备会议材料、整理邮件、安排日程，全天候在线，永远不需要喝咖啡休息。

已经有了 Copilot，为什么微软还要用 OpenClaw，给白领牛马再配一个 AI 助手？

01

从「工具」到「同事」

在理解 Scout 之前，必须先回头看看微软这段时间在干什么。

过去几年，微软几乎把「Copilot」这个词用到了极致。Word 里有 Copilot，Teams 里有 Copilot，GitHub 里有 Copilot，甚至 Windows 本身也有 Copilot。结果是什么？用户需要在五个不同入口之间来回切换，这些体验不共享状态，不共享身份，甚至入口在哪里都找不清楚。

这是个真实存在的企业用户痛点，不是产品经理假想出来的。

5 月 29 日泄露的一份内部计划显示，微软正试图把所有这些分散的 Copilot 体验整合进一个超级应用，包括 Copilot Chat、GitHub Copilot、Copilot Cowork、代号为 Autopilot 的工作流引擎，以及今天正式亮相的 Scout。目标是今年夏末推出统一入口。

Scout 在这个版图里扮演的角色，是最接近「人」的那个。

Scout 融合在 Teams 中｜图片来源：微软

它不是嵌在应用里的功能，而是以一个真实的联系人身份存在于 Teams 中。你可以给它发消息，它会回，它会记住你上次说了什么，它会主动提醒你。从交互设计的逻辑来说，这是一次刻意的选择——微软想让你感觉，你在和一个「人」协作，而不是在调用一个功能。

这个区别，比听起来要重要得多。

驱动 Scout 的底层是 OpenClaw，一个微软主导的开源 Agent 框架。

同一天，微软还发布了自研推理模型 MAI-Thinking-1，一个拥有 350 亿活跃参数的中等规模模型，定位不是「最强」，而是「够用且便宜」。这些拼在一起，构成了微软在 Agent 时代的技术底座。

02

「永远在线」背后的真正赌注

Scout 最被反复强调的特性，是它的「持久记忆」。

用传统 AI 助手，你每次打开对话窗口，它都不记得你是谁，你昨天说过什么，你这个项目的背景是什么。你需要不断重新解释上下文，这本身就是一种隐性的时间成本。

Scout 的设计逻辑完全相反。它在你的 Microsoft Entra 身份下运作，有自己独立的受管凭证，在 Microsoft Purview 的保护框架内工作，包括敏感标签和数据防泄漏策略。它「记得」你，不是因为它在偷偷存储数据，而是因为它被设计成一个有完整身份的企业成员，而不是一个无状态的查询接口。

用户可以自定义模型、性格和接入的软件｜图片来源：微软

这背后有一个非常清醒的商业逻辑。用户在 Scout 上投入的时间越多，它学到的工作习惯越多，用户就越难迁移到其他工具。这是企业软件里经典的「护城河」策略，只不过这次护城河是用 AI 的记忆建造的。

从用户实际使用场景来看，Scout 目前最核心的能力集中在会议准备、日程协调、邮件整理这几个高频但低创造力的任务上。这些任务有一个共同特点——它们每天都会发生，但几乎没有人喜欢做。一个永远在线、永远不嫌烦的 Agent 来接管这部分工作，理论上是非常准确的产品定位。

微软在发布会演示中展示的一个场景是这样的：你有一个下午两点的重要客户会议，早上九点 Scout 会主动推送一份摘要，包含对方公司最近的动态、你们上次交流的重点、以及这次会议你可能需要准备的资料。你不需要去找它，它自己过来找你。

这不是「更聪明的搜索」，而是「提前思考」。

03

OpenClaw 的裂缝

不过，Scout 的发布并不是没有争议。

问题出在 OpenClaw 身上。这个 Agent 框架在早期测试中被发现存在安全漏洞——研究人员记录了 Agent 在收件箱内不稳定运行的情况，还有允许外部网站接管本地执行环境的严重缺陷。Slashdot 社区的讨论里，有人直接点出，OpenClaw 的工具链审查存在明显疏漏。

这是一个真实的技术风险，不是挑剔。

微软的回应是双管齐下。

一方面，Scout 在企业侧有完整的安全治理框架——独立的 Entra 身份、受限的任务凭证、Purview 保护范围内的数据处理，凭证信息不出现在日志和诊断记录里。

另一方面，微软宣布会向 OpenClaw 开源项目做上游贡献，帮助修复底层框架的已知问题。同日发布的 Microsoft Execution Containers SDK，也专门针对 Agent 工作流提供了安全沙箱隔离能力。

但这里有一个微妙的张力——微软选择把 Scout 建在一个开源框架上，这本身是一个开放的信号，意味着它愿意把技术栈暴露在社区审查下。代价是，早期的问题也会更透明地被放大。

如何在开放和安全之间找到平衡，大概会是 Scout 在企业推广中最长期的挑战。

04

Copilot 和 Scout 的边界

有一个问题，很多企业客户今天应该都在想：

我现在已经在用 Copilot 了，Scout 是要替换它吗？

微软官方给出的解释是，Copilot 是「应用内工具」，Scout 是「个人助手」。前者嵌在具体的产品功能里，后者是一个独立的 Agent 成员。

听起来很清晰，但实际操作中，边界真的那么分明吗？当 Scout 帮你整理了 Teams 会议记录，Copilot 也在 Teams 里做类似的事情，用户怎么决定问谁？

这个困惑不是微软第一次遭遇。Google 在消费端也面临类似问题——Gemini 和 Google Assistant 长期共存，产品定位的重叠让用户无所适从。微软在企业侧聚焦工作场景的策略，确实比通用家庭助手更容易做出差异化，但两个「Copilot 系」产品之间的边界，还需要时间来真正清晰。

更有意思的是，Scout 的出现对整个行业的「期望值」有一个放大效应。当企业用户开始习惯一个能记住他们偏好、主动提醒、适应工作习惯的 Agent，他们就会把同样的期望，带入所有的数字交互里——包括外部客户支持、B2B 销售跟进、甚至招聘流程。那些还在用每次重新开始对话的机器人的公司，会显得格外落后。

这才是 Scout 更深远的影响，不只是微软自己的产品，而是整个企业软件行业都必须重新思考，什么叫「够用的 AI 体验」。

微软今天用 Build 2026 告诉所有人，它不满足于只是 OpenAI 最大的投资方，它要自己造模型，自己造框架，自己造 Agent，然后把这个 Agent 变成每一个企业员工的默认同事。

Scout 能不能真正在企业里站稳脚跟，取决于它接下来的安全表现、和 Copilot 体系的整合进度，以及用户愿不愿意真的把它当成一个「可以信赖的同事」对待。

但有一点是确定的——当一个 AI 的名字出现在你的 Teams 联系人列表里，和你的真实同事排在一起，这件事本身就已经改变了什么。

*头图来源：微软

本文为极客公园原创文章，转载请联系极客君微信 geekparkGO

极客一问

你愿意让一个 AI「同事」

帮你处理工作邮件和会议安排吗？