Grok Bot 已经开始接入微软账号。
9 月 1 日，Grok Bot 官宣可直接连接用户的微软账号，通过新插件访问 Outlook、Calendar 和 OneDrive，支持读取、写入并执行操作。几小时后，马斯克转发相关消息，并写道：「Grok Bot 已升级。」
这次更新没有发布会，也没有演示视频，但权限层面的变化已经很明确：Grok Bot 可以拿到邮箱、日历和网盘的访问能力，代用户发邮件、调整会议，并把文件上传到 OneDrive。
消息传出后，外界很快把它与微软 Copilot 直接联系起来。不过，xAI 官方文档显示，Outlook 和 OneDrive 连接器早在今年 5 月就已经出现在 Grok 文档中。换句话说，读取和写入微软账号的能力并不是这次才出现，真正变化的是获得这些权限的主体，从原来的聊天场景转向了「Bot」。
三个插件分别能做什么
从动作层面看，Grok Bot 这次接入的是三类能力。
Outlook 邮件插件权限最完整。它支持搜索邮件、读取正文和附件，也支持起草、发送、回复所有人、转发，还能把邮件移动到其他文件夹做整理。Grok 生成的文件也可以直接添加到草稿附件中。
对应的关键权限包括 Mail.ReadWrite、Mail.Send 以及 offline_access。后者意味着用户完成一次授权后，不需要反复登录。
日历则由单独的连接器和单独的授权处理。它可以按日期查询事件、查看多人空闲时间、创建和修改会议，包括参会人和重复规则，也能代用户对会议做出接受、拒绝或待定的回复。
OneDrive 的能力相对有限。官方列出的范围是浏览文件夹、读取文档、上传由 Grok 生成的内容。如果要对 OneDrive 中的文件做全文搜索，还需要额外连接 SharePoint 连接器。并且，这部分功能只向 Grok Business 和 Enterprise 开放，个人账号不在官方连接流程内。
按官方能力边界概括，邮件可收可发也能整理，日历可建可改可回复，网盘则主要是查看和上传。
权限早在 5 月就有，变化出在 Bot 形态
既然连接器 5 月就已经存在，为什么这次又集中引发关注，原因在于接入方式变了。
5 月时，这些连接器主要服务于传统聊天场景。用户在 grok.com 中发出问题，例如查询上周某封供应商邮件的内容，Grok 会调用 Outlook 返回结果。对话结束后，权限虽在，但执行逻辑仍围绕即时问答展开。
8 月 11 日，Grok Bot 进入早期测试。它不再只是待在聊天框中的助手，而是运行在一台常驻云电脑中，带有浏览器、文件系统和终端，能够登录网站、保存会话、并行运行任务，甚至在用户合上笔记本后继续工作。
这次更新，本质上是把 5 月那批连接器做成了云电脑里的插件。同样的权限，被放进了完全不同的执行环境中。
此前更像是「帮我查一下邮件」，现在则可以变成 Bot 在夜里自行读取整晚邮件，判断哪些需要回复，起草内容后放入草稿箱，等用户第二天确认。执行者从等待提问的聊天界面，变成了一个持续在线的云端 Bot。
微软与谷歌对开放边界的处理并不相同
Grok Bot 进入的，正是 Copilot 最核心的 Microsoft 365 场景。再往前推 6 天，Grok 4.6 刚宣布上线 Microsoft Foundry，由 Azure 托管并销售。因为时间接近，外界很容易把两件事连在一起看。
但从技术路径看，两者并不是一回事。
Foundry 面向企业采购模型，与个人账号授权没有直接关系。Outlook 插件走的是微软面向第三方开放的标准授权流程，和用户把微软账号授权给其他应用的逻辑一样，最终交出权限的是用户自己，而不是微软代为放行。
这一点也构成了微软平台开放的代价：只要标准接口对外开放，第三方就可能进入其核心工作流区域。
谷歌的处理方式则更谨慎。Google 账号帮助页明确写到，如果浏览器是通过自动化软件而非真人控制，或浏览器嵌入在其他应用程序中，系统可能阻止登录。Grok Bot 云电脑中的浏览器正好处在这类边界上。
已有用户在 Grok Bot 中登录 Google 时遇到阻止提示。但这并不意味着谷歌封禁了 Grok。xAI 官方文档仍然列有 Gmail、Google Drive 和 Google Calendar 的 OAuth 连接器。
也就是说，谷歌限制的是 Bot 在云浏览器里模拟真人登录，保留的是用户通过 OAuth 正式授权的路径。
智能体竞争已经进入微软账号体系
围绕微软账号入口布局的并不只有 Grok Bot。
微软自己的 Copilot 本来就已经嵌入 Outlook。在 Build 大会上，微软还推出了可常驻 Outlook 监看邮件的 Autopilot「Scout」。
Anthropic 也提供 Microsoft 365 连接器，支持读取 SharePoint、OneDrive、Outlook 和 Teams。不过，发送邮件、修改日历、写文件这类操作，需要租户管理员单独放行，而且只支持工作账号，不能连接 @outlook.com 个人邮箱。
开源方向则有 OpenClaw。其社区平台 ClawHub 上已经出现多项 Microsoft Graph 技能，官方 Outlook 技能下载量超过 6600 次，覆盖 OneDrive 的 microsoft365 技能也有上千次下载。不过这一路径要求用户自己在 Azure 注册应用并管理 token。
几条路线都在争夺同一件事：把自己的智能体接入用户的微软账号。
Grok Bot 这次的区别在于，它把「常驻云电脑」和「第一方插件」绑定在了一起。马斯克当天还补充说：「Grok Bot 在自己的云端电脑上 7×24 小时运行，所以你关不关笔记本都不影响。」
这意味着用户不需要自行配置 Azure，也不需要保持本地电脑开机，完成一次授权后，Bot 就能在云端持续执行任务。
审批点仍在，风险边界也很直接
虽然委托权限发生在个人账号层面，但邮箱、日历和网盘中承载的往往是真实工作往来。误发邮件、误删会议，带来的损失并不抽象。
xAI 目前在产品中保留了审批节点。
官方演示中，一个名为 Inbox Manager 的 Bot 在夜间完成任务后，会在第二天早上留下提示：「收件箱清零，5 封草稿留着等你看。」
另一个名为 Sales Outbound 的 Bot 展示得更具体。用户给出一句任务指令后，它会从 Google Sheet 筛选潜在客户，在网上做调研，并从 Hex、Sumble、Salesforce 补全信息，再按用户口吻起草邮件和 LinkedIn 触达序列。
一夜运行结束后，Bot 交回的结果包括：52 个客户账号、3 个相似客群、4 个因近期联系过而被主动跳过的人，以及 36 封排好队的草稿，已发送邮件为 0。
只有当用户确认「前 10 封看着不错，发吧，以后每周跑一次」，它才会继续发送，并把任务保存为每周例程。
也就是说，最终拍板权仍在用户手里。
授权按钮背后，是 AI 员工的入场券
对普通用户来说，智能体时代真正关键的，未必是模型跑分，而是几个更基础的问题：内容发出前是否需要确认，操作过程是否可追溯，权限能否一键撤销，发错或删错后是否还能补救。
邮箱、日历、网盘，是知识工作中最底层的三个入口。谁先拿到这些授权，谁就更容易占据工作流中的默认位置。
而所谓 AI 员工的「入职」，往往就发生在用户点下授权按钮的那一刻。授权之前，用户真正交出去的是什么，仍然需要看清。