Grok Bot 实测：不靠新模型，Personal Agent 团队为什么长成这个样子

最近 Personal Agent 是 AI 圈里绕不开的话题。大家想要的是一个能长期跟着自己的私人助手：知道你在忙什么、记得你的习惯、能打开软件处理杂事。
xAI 拿出的 Grok Bot 更直接——索性给你一支 Personal Agent Team。

你可以像老板一样安排几个机器人员工，研究、写作、日程各管一摊。它们有自己的名字、分工和工作背景，可以并行干活，也能被拉进同一个群聊，互相发消息、交接任务。

过去两个月里，各种 Personal Agents 冒得很快，用户也抢得凶，但 Grok Bot 的增长还是压过不少对手。2026 年 8 月 11 日测试版上线，两个月后付费周用户达到 80 万，其中 10 月比前一个月翻了一倍多。马斯克自己也说：I've never seen anything grow this fast.

我们自己也深度用了一圈。坦白说，Grok Bot 并没有拿出什么“新东西”：模型能力没有超过 Opus 5.5，性价比也没有超过 DeepSeek，云电脑这个形态更是 Manus 先配上的。

知名科技播客主理人 Lenny Rachitsky 最近聊 Grok Bot 时也提到，自己已经把不少原本交给 Cowork 和 Codex 的工作搬到了 Grok Bot。可当别人问，那些事情用其他工具不也能做吗？他也承认：从技术上说，确实可以。

换句话说，Grok Bot 既没有发明什么重器，也不是靠模型进步带来增长。它真正做成的，是把个人用户的真实场景和已有技术结合到一块，再通过产品化设计拿下实打实的个人用户群，而且留存还很能打。

这基本就是今天所有 Personal Agents 想象中自己的样子。所以下面结合实测，看看它到底是怎么做到的。

真正的把 Agent 当同事

Grok Bot 最明显的一个设计思路，是遵循“同事化”。

什么叫同事化？用 Grok Bot 产品负责人 Roman Ugarte 的话来说，“同样的情况下，你希望一个人类同事怎么做？”

这套思路落到产品设计上，最直观的变化是：用户给 AI 分配工作的方式变了。

面对 Codex 这样一个什么都能做的聊天框，用户往往得自己想清楚：这次让它扮演谁，需要补哪些背景，调用什么 skill，应该按什么标准交付。

而 Grok Bot 则是让用户面对 Bot 扮演的同事。研究员 Bot 负责找资料，作者 Bot 负责出稿，助理 Bot 负责安排时间。只要你愿意，还可以给 Bot 用上真实同事的名字和头像。

看见这些熟悉的同事，用户更容易想到怎么分配任务。比如我就搭了一个 AI 大佬小队，每个人各管一摊。

分工之外，也把记忆拆开

同事化还带来一个好处：不同 Bot 可以各自攒自己的工作记忆。

我们想让一个同事记住什么，往往和他的职责有关。研究员 Bot 需要熟悉你长期关注的领域、信得过的资料来源，以及判断一份研究是否靠谱的标准；作者 Bot 需要了解你的文风、结构偏好，还有怎么去掉 AI 味。就像公司里不同岗位的人，各有各的经验。

Grok Bot 的设计，会让你做某类事时自然去找专门的 Bot，而不是在一个无所不能的聊天框里从零描述。同一个 Bot 长期负责同一类工作，用户对这类工作的要求，就会在一次次合作中攒下来。每个 Bot 都可以保留自己的角色背景、稳定偏好和过往工作记忆。

我就可以把老黄 Bot 打造成英伟达研究专家，以后有项目或文章涉及英伟达，就让他参与。他做过的报告、网站，也会存进自己的资料库。一个项目会结束，但同类工作还会反复出现。把相关记忆留在长期负责它的 Bot 身上，而不是埋在某一次会话里，之前讲清楚的要求、反复改过的地方，才有机会持续发挥作用。

用 Bot 管理 Bot

Bot 一多，怎么协调就成了问题。

Grok Bot 产品负责人 Roman 回忆，内部试用初期，大家通常会先建五到十个 Bot。后来有用户把表现最好的私人助理“提拔”成领导，平时有事先找它，再由它把任务分派给其他 Bot。有意思的是，有的 Bot 收到升职通知后，还会追问能不能加薪、提高 token 预算。

可见 Agent Team 玩到最后，其实是在复刻人类组织的结构。

这种安排最初是用户自己摸索出来的。团队没有急着把它规定成标准流程，而是先观察外部用户会不会走到同一步。发现相似做法后，才开始在产品里鼓励这种模式。同事化因此又多了一层意思：角色让每个 Bot 有明确职责，领导 Bot 则接走了一部分协调工作。Bot 会越来越多，用户需要操的心，却不该跟着增加。

那么多个 Bot 之间到底怎么联动？两种方法。

第一种，在对话框里 @ Bot。我让 Musk、纳德拉和老黄一起想办法做空英伟达。可以看到，Bot 之间会互相私信，最后由领导 Agent 汇总回复。

第二种方法就是 拉个群聊，让 Bot 在群里，用上自己的知识记忆畅所欲言。我让 Bot 们在群里讨论如何实现 AGI，大家都推荐 Karpathy Bot 作为主力。

而且，Grok Bot 的群聊并不是表面功夫，而是真的在推进项目。Karpathy Bot 发出研究报告后，还建议不在群里的 Simon Bot 对他的想法进行实测。

这有点像 DeepSeek 前几天讨论的 Super-agent 思路：Agent 可以有很多分工，但用户不该因此多出一份管理它们的工作。拆解任务、分派工作、跟进进度和汇总结果，都应尽量由系统自己完成，人只在需要补充信息、作出判断或验收结果时介入。

Agent 可以越来越多，占用人的注意力却不该跟着增加。

给 Agent 一台电脑，而不是和你共用

既然把 Agent 当同事，那至少得给它准备一台电脑。Roman 吐槽得很实在：你很难想象新同事第一天入职，要和你共用一台电脑。但如今不少人和 AI 合作，恰恰就是这样。

共用同一个桌面时，你想打开网页，它要操作软件，两边互相干扰；即便任务能在后台跑，用户还得操心电脑能不能关机、断网了怎么办。而且以目前 Agent 的能力，一个干净的、没有人类打扰的工作环境，可能反而更能发挥作用。

Grok Bot 把这支机器人团队的工作环境放到了云端。那里有持续运行的电脑、浏览器、文件系统和可用工具，和用户自己的设备完全分开。

我让 Karpathy Bot 打开浏览器，去研究总结真人 Karpathy 的网页内容，整个过程就在它自己的云端环境里完成。

还有用户会进一步把 Grok Bot 当成协调者，在它的云电脑上安装编程 CLI，由 Grok Bot 接收需求，再把具体开发工作交给专门的编码代理。

Grok Bot 的云电脑也不是简单发一台机器，它还考虑了不少实际场景。它支持临时接管：遇到必须登录的网站，可以先由人工登录，再交给 Bot 操作。有些系统会拒绝数据中心 IP，Grok Bot 于是提供了本地网络出口，云端浏览器的联网请求可以经用户自己的电脑转发，目标网站看到的是本地网络的公网 IP。这样一来，登录不上或者频繁验证的问题就少了很多。

很多时候，我们研究 API、MCP 等等，这对面向 Agent 的生态很有用，也确实高效。但现实是，眼下的生态主要还是面向人类。在面向 Agent 的生态成熟之前，先给 Agent 一台电脑，可以绕开很多问题。

模型黑盒，一把双刃剑

Grok Bot 还有一个争议比较大的点：用户没法指定模型，甚至不知道用了什么模型。运气好可能是 Opus 5.5，运气差可能是 Flash 模型。

对模型控制欲强的用户来说，这很让人抓狂。他们习惯了研究模型的能力、速度和价格，也愿意为重要任务选择更强的模型。

但对另一类小白用户来说，省掉模型选择，恰恰是吸引力所在。他们可能只想要一份日报，或者做个网页，这些任务未必都需要最贵的模型。至于该用哪个模型、思考深度和上下文长度该怎么选，他们并不想逐一研究。为了把一件事交给 AI，还得先学会模型路由，多少有点本末倒置。

当然，这倒是给厂商留下优化空间：路由做得好，可以压住推理成本，让有限的额度完成更多工作；但如果路由做不好，生成质量差，就会直接造成用户流失。

模型黑盒能降低使用门槛，却也要求厂商承担更多交付责任。用户可以把选择模型的工作交出去，但交回来的结果，仍然得值得这份信任。

写到这里，再回头看 OpenClaw，会发现龙虾留下的启发还没有被消化完。给模型配上电脑、工具和持续工作的环境，人们对 AI 的期待，也从回答眼前的问题，延伸到了接手长期的工作。

从 Personal Agent，到 Grok Bot 这样一支有岗位、有记忆、能互相交接的小队，这个想象还在继续生长。单个 Agent 能做多少事，逐渐变成了多个 Agent 怎样一起做事，以及人该怎样和它们相处。

这也解释了开头那个疑惑。模型、记忆、云电脑、多 Agent 协作，拆开来看都不算新鲜。但技术上能够做到，和普通人每天愿意使用，之间还隔着不少工作。搭环境、接工具、补背景、盯进度，这些原本散落在用户手里的麻烦，每被产品接走一点，把工作交给 AI 就容易一点。

用户未必需要一种前所未有的能力，却很需要有人把已有的能力安排妥当。毕竟，为了让 AI 替自己干活，先给自己增加一份伺候 AI 的工作，怎么算都不太划算。