你第一次打开 Grok Bot 的插件目录，搜索 X，找到对应插件并点击。本地浏览器会弹出一个登录页面。你登录之后，连接就建立好了。
你不需要钻进系统的代码里，也不需要安装 MCP server 的 JSON，或者粘贴 API 凭据。你像登录任何网站或应用那样登录一下，Grok Bot 就准备好了。我让它回顾我在 X 上的帖子和我感兴趣的内容，然后每天给我一份与我相关的新闻和故事简报。
我还通过工作账号把它连上了 Freshdesk，并搭了一个客服 Bot，每十五分钟检查一次有没有新开的支持工单。要复现这样一个真实的工作流，一个我曾投入大量时间和精力处理的工作流，它所需要的只是我在浏览器里登录一下。
这种配置上的轻松，才是这里真正的新东西。Grok Bot 把智能体的配置变成了点几下鼠标加一次登录。
Grok Bot 用起来就像拆开一台新 MacBook。打开、开机，干活需要的东西都齐了。OpenClaw 这类系统则像 Linux：它们给你更多选择，也让你更自由地围绕自己想做的事去定制系统，但这种灵活性伴随着更高的复杂度和更多的配置开销。
本周发布的 OpenClaw 2.0 大幅缩小了这一差距。它的 Quick Start 可以复用已有的 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 运行时，并支持接入其他编码智能体 harness 的路径，所以这已经不必再手工拼装了。区别在于这些组件的呈现方式。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 让人觉得像人，与其说是语气（它听起来仍然像个 LLM），不如说是交互的连贯与简单。我用 Claude Code 或 Codex 时，仍然要大量考虑上下文窗口的管理：还剩多少上下文，对话什么时候需要压缩，什么时候该开一个新线程。这些顾虑在 Grok Bot 内部也许依然存在，但并没有被当作界面的一部分呈现出来。我可以把注意力放在与 Bot 进行自然语言对话的层面上，而不是去管理 LLM 底层的机制和局限。
Grok Bot 最有用的连接器特性之一，是支持同一服务的多个账号。我同时连上了个人和工作的 Google Calendar 账号。我既有一份全职工作，又有两个年幼的孩子，日程很难清楚地分成工作和个人两类。Grok Bot 给了我一天的完整视图，而不是让我在两个不同的界面之间切换去查看安排。有一点需要明确说明：我创建的每个 Bot 共享同一台计算机、同样的文件、浏览器会话和登录状态。不同的 Bot 只是组织上的边界，而不是安全边界。
这又引出 Grok Bot 另一个我非常喜欢的微妙的用户体验决策：系统是围绕使用它的个人来设计的，而不是让个人去迁就系统。
Grok Bot 里的一切都旨在让你在自己已有的工具和场景中接入数字生活，而不必重新学习一整套新的生态。我用 Gmail 账号已经 20 年了，也许更久，而 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 分配一项工作和一个角色，有助于我把大类工作分开：支持归客服 Bot，编码归 Agentic Engineer。但在单个 Bot 内部，不相关的任务仍然在同一个持续的对话中进行。时间一长，就越来越难分辨哪些假设、指令和上下文仍然属于手头的任务。Bot 本身是一条清晰的边界；而其内部的各个任务则不是。
我的结论
写这篇文章时，我用 Grok Bot 快一周了。我每天都在用它，但它并不是我工作中或工作之外的主要智能体界面。我发现它在我的工作和个人项目中技术层面周边的领域相当有用。比如行政事务、总结、搜索新闻、项目管理和任务管理。这些浅层工作往往会妨碍更深入的技术工作。
如果你是工程师，我认为 Grok Bot 可以成为你的某种“数字幕僚长”，不需要任何培训或太多配置就能在工作中发挥作用。但我也怀疑 Grok Bot 短期内会撰写你大部分的 pull request。