你第一次打开 Grok Bot 中的插件目录。你搜索 X，找到那个插件，然后点击它。一个登录界面在你的本地浏览器中打开。你登录，然后就连接上了。
你不需要深入系统的代码。你不需要安装 MCP 服务器的 JSON，也不需要粘贴 API 凭据。你像登录任何网站或应用一样登录，Grok Bot 就准备好了。 我让它审阅我的 X 帖子以及我感兴趣的内容，然后每天给我一份与我相关的新闻和故事的简报。
我还通过我的工作账户把它连接到了 Freshdesk，并设置了一个支持机器人，每十五分钟检查一次新打开的支持工单。要复刻一个真实的工作流程——一个我曾投入时间和精力的流程——它所需要的只是让我通过浏览器登录。
这种设置的简便性才是这里真正的新东西。 Grok Bot 把智能体配置变成了几次点击和一次登录。
Grok Bot 感觉就像拆开一台新 MacBook。 你打开它，开机，就拥有了开始工作所需的一切。像 OpenClaw 这样的系统感觉像 Linux：它们给你更多的可选性和更多的自由，让你围绕自己想做的事来定制系统，但这种灵活性伴随着更多的复杂性和更多的设置开销。
本周发布的 OpenClaw 2.0 大幅缩小了这一差距。 它的快速开始可以复用现有的 Claude Code 或 Codex 登录，其浏览器应用把大量设置、插件管理和自动化移入了一个图形化或对话式界面。
但根本区别依然存在：OpenClaw 给你一个归用户所有的 Gateway，由你选择如何运行、在哪里运行，而 Grok Bot 则作为产品的一部分提供并运营这台计算机。换句话说，Grok Bot 是一台托管的智能体计算机，而 OpenClaw 是一个归用户所有的智能体平台。
Bot 是原子单元
但 Mac 与 Linux 的类比只能带你走到这一步。
Grok Bot 并不比 OpenClaw 更难编程，但它在不同的抽象层级上可编程。 使用 OpenClaw 时，定制意味着更接近代码、配置、工具、技能、插件和基础设施。在 Grok Bot 中，Bot 本身成为程序的原子单元。你赋予 Bot 专门的职责，把它们连接到不同的工具，并将它们组合成一个更大的系统，Grok Bot 称之为“群聊”。
自编程诞生以来，编程一直在向更高的抽象层级发展。我们从机器码和打孔卡，走到汇编，再走到我们今天视为较低级的语言如 C，然后走到像 Python 这样的高级语言。在这一演进的每一步，程序员都能表达更多的意图，同时把更多的细节委托出去。Grok Bot 把这一演进的轨迹又向前延伸了一步：界面是英语，而被编程的东西不再是一个函数或服务，而是一个“Bot”。
上升到更高抽象层级的意义在于，它让编程计算机的能力可以为那些可能永远不会写代码、但能用相对精确的英语清楚表达自己想要什么的人所用。所需的技能从语法和实现转向精确地指定意图。
昨天我创建了一个 Claude Bot，它在 Grok Bot 的虚拟计算机中安装并登录了 Claude Code CLI。这让我不禁思考，这个模型究竟能走多远。我可以接入 Codex 和其他智能体 CLI，然后把它们组装成 Grok Bot 内部的一个智能体工程师委员会。 OpenClaw 也能支持类似的配置，而且 OpenClaw 2 现在自带原生 Codex 运行时，并为其他编码智能体框架提供了受支持的路由，所以这不再是你必须手动接线的事情。区别在于这些组件是如何呈现的。Grok Bot 将智能体呈现为一等的、人类可读的构建块，而 OpenClaw 则让更多底层机制暴露在外。
这是我对 Grok Bot 与其他智能体平台关键差异的初步印象。过去大约五天里，我一直搭配一个 Cursor Pro+ 账户使用它。
Grok Bot 的港口之旅
对我而言，拟人化是 Grok Bot 的关键差异点之一，也是让它用起来如此令人愉悦的原因之一。每个 Bot 都可以有自己的名称、角色、身份和描述。这是 Grok Bot 这道大餐上的一抹人性化点缀，但它又不仅仅是点缀。它有助于在系统内部建立认知上的区分，让你更容易组织自己的工作。
我的 Agentic Engineer Bot 就是它在实践中的样子。我没有把它绑定到单一模型或工具上，而是让它能够访问多个智能体工程系统，并定义了针对给定任务路由到正确系统的准则。我的路由规则把视觉、设计和前端工作指向 Claude Code，把调试和细致的代码阅读指向 Codex，把更简单的任务交给 Grok Build CLI。
当我的 Grok Bot 生态系统中任何地方出现与编码相关的事情时，我不必停下来决定该把它发给哪个 CLI。我把它委托给 Agentic Engineer，由它根据任务和我给出的准则来选择工具。 这个拟人化的角色给了我一个可以依循的心智模型。我会根据我所知道的他们具备的技能，去思考谁应该主导这项工作，就像我与人类团队合作时一样。
Grok Bot 让人觉得像人的地方，与其说是它的语气（它听起来仍然像一个大语言模型），不如说是交互的连续性和简洁性。 当我使用 Claude Code 或 Codex 时，我仍然会大量考虑上下文窗口管理：还剩多少上下文、对话何时需要压缩、我应该在什么时候开一个新线程。这些问题在 Grok Bot 内部可能依然存在，但它们并没有作为界面的一部分呈现出来。我可以把注意力集中在与 Bot 的自然语言对话这一层面上，而不是去管理大语言模型的底层机制和限制。
Grok Bot 最有用的连接器功能之一是支持同一服务的多个账户。我同时连接了我的个人和工作 Google Calendar 账户。作为一个有全职工作和两个年幼孩子的忙碌的人，我的一天并不能整齐地划分成工作和个人日历事件。Grok Bot 让我对一整天有一个统一的视图，而不是让我不得不访问两个不同的界面来查看我计划了什么。有一点值得明确说明：我创建的每个 Bot 都共享同一台计算机、文件、浏览器会话和登录状态。不同的 Bot 是组织边界，而不是安全边界。
这引出了关于 Grok Bot 的另一个微妙的用户体验决策，我非常喜欢：系统是围绕使用它的个人来设计的，而不是要求个人去适应系统。
Grok Bot 中的一切设计都是为了让您能够在您已经使用的工具和环境中连接您的数字生活，而不必重新学习一个全新的生态系统。我有一个用了 20 年、甚至更久的 Gmail 账户，而 Grok Bot 只需轻松点击几下就能连接到那个环境，这让人感到愉悦。
虚拟浏览器还将 Grok Bot 扩展到了其插件目录之外。Freshdesk 不是我安装的原生连接器。我在虚拟浏览器中打开它，从本地机器的 1Password 中转移了我的登录信息，并在那里完成了身份验证。一旦该会话存在，支持 Bot 就可以每十五分钟检查一次 Freshdesk，确保我没有错过新的工单。实际上，一个普通的网站变成了可自动化的浏览器工作流，然后变成了一个循环执行的工作流。值得注意的是，这并不是连接器或 API 意义上的集成：xAI 自己警告说，浏览器工作流可能会遇到界面变更、会话过期和 CAPTCHA，并建议在存在连接器的情况下使用连接器。在智能体出现之前的世界里，这种集成需要数周才能构建完成。
此外，虚拟浏览器的一大优点是它运行在云端的持久计算机上。
Grok Bot 的常开计算机
给智能体一台自己的计算机并不是一个新想法。我在地下室的台式机上运行 OpenClaw，所以它也有一台持久运行的机器。区别在于，我有责任让那台机器保持运行。当我家里停电时——夏季雷暴时经常发生——台式机会关机，OpenClaw 会一直离线，直到我亲自去那里重新启动它。OpenClaw 也可以在云端运行，OpenClaw 2.0 甚至通过 Hostinger 提供一键托管部署。但除非我选择那样的托管选项，否则我仍然要负责选择和操作主机、保持其更新并保持其可用。
Grok Bot 把我的家庭实验室安排变成了一个托管产品。它的计算机由我托管和维护，因此我不必管理硬件、电源、远程访问或恢复。优势不仅仅在于智能体有一台计算机；我的 OpenClaw 也有一台计算机。而在于我不必操作和维护它所依赖的计算机。
这种托管的持久性也体现在我在设备之间无缝切换的方式上。我可以在 MacBook 上与 Grok Bot 交互，在 iPhone 上继续同一段对话，并发现同样的工作还在等着我，就像我从未离开过一样。当我切换设备时，我不必建立远程连接或重建 Bot 的环境。
一台永不关机的计算机也有其缺点。状态会累积，有时你想要一个干净的状态。Grok Bot 为此提供了两个杠杆。Update 会重建计算机，同时保留其持久状态，而 Reset 会将其返回到上次同步的持久状态，这可能意味着丢失任何尚未同步的近期工作。
但便利性的每一个好处也都伴随着成本和权衡。
权衡：控制与认知负荷
Grok Bot 的抽象和便利是否有帮助，取决于具体任务。如果我正在进行深度实现工作——比如构建新东西、推理代码或检查程序逻辑——那么把机制从视野中移除未必有帮助。对于这类用例，深入技术细节本身就是工作。
Grok Bot 在软件工程周边的工作中表现得更明显：产品管理、设计、销售产品以及内部沟通。在这些情况下，我更关心定义结果和委派工作，而不是关注每一个实现决策，只要工作完成后我能清晰地验证结果。同样的抽象在深度技术工作中可能感觉受限，但当底层机制不是我需要关注的重点时，它就变得解放了。
没有模型选择器很方便，直到任务不需要前沿级别的智能。有时我宁愿故意为简单工作选择一个更小、更快的模型，把最强的模型留给需要更深推理的任务。我个人喜欢高效利用资源的想法，即使我没有为此额外付费。Grok Bot 在幕后做出路由决策，所以我无法看到或控制它们。同样的设计在消除又一个配置选择的同时，也消除了一种平衡能力、速度和使用量的有用方式。Grok Bot 没有给我那个可以拉的杠杆。
这种控制的缺失不仅限于模型选择。在 Claude Code 或 Codex 等工具中，我可以开启新线程、压缩对话、管理我向前携带多少上下文，并就如何使用我的配额做出深思熟虑的选择。这些杠杆会带来额外的认知开销，但它们也给了我控制上下文和使用量的方式。Grok Bot 对我隐藏了这些决策。体验更简单，但我影响自己多快消耗可用容量的方式更少。还有一个额外风险：在任务中失去心智在场感，因为完成任务对我的要求没那么多了。
此外，拟人化在一个层面上澄清了任务边界，却在另一个层面上模糊了它们。给每个 Bot 一份工作和一个角色，有助于我把宽泛的工作类别分开：支持属于 Support Bot，而编码属于 Agentic Engineer。但在单个 Bot 内，不相关的任务会通过同一个持续对话继续进行。随着时间推移，可能更难分辨哪些假设、指令和上下文仍然属于当前任务。Bot 本身是一个清晰的边界；其中的各个任务则不是。
我的结论
写这篇文章时，使用 Grok Bot 快一周了。我每天都在用它，但它不是我在工作或工作之外的主要代理界面。我发现它在我工作和个人项目中技术方面的周边领域相当有用。
比如行政管理、总结、搜索新闻、项目管理和任务管理。所有那些可能妨碍更深技术工作的浅层工作。
如果你是工程师，我认为 Grok Bot 可以作为一种“数字幕僚长”对你有用，它不需要任何培训或太多设置就能在工作中发挥作用。但我也怀疑 Grok Bot 会在短期内撰写你的大部分拉取请求。