过去一周，AI 智能体圈连着发生了三件事，指向同一个方向。8 月 11 日，马斯克旗下 SpaceXAI 正式入局 AI 代理市场，推出可像真实同事一样处理工作的产品 GrokBot。微博8 月 14 日，SpaceX 豪掷 600 亿美元拿下 AI 编程公司 Cursor，监管文件显示收购于当地时间 8 月 14 日正式生效。微博8 月 17 日，开源项目 Rakazo 浮出水面，定位是 Open-source Grok Bot alternative。GitHub热闹看完了，对做智能体开发的人来说，真正值得停下来看的不是收购金额，而是这批产品第一次把"能干活的 Agent"的形态标准化了——以及第一批实测用户替所有人踩过的坑。
GrokBot 到底是什么：每个 bot 一台云电脑
GrokBot 的架构一句话就能说清：每个 Bot 背后是一台独立的云端 Linux 虚拟机，有自己的浏览器、文件系统和终端。知乎你把活派给它，它自己登录你现有的工具，一步步做完，你合上笔记本它还在跑。多个 bot 可以并行，互相通信、分工协作。
有两个容易被忽略的细节。一是有测试者发现，在应用商店发布页，发布者是 Cursor 的母公司。知乎这款产品虽然挂着 Grok 的名，登录用的是 Cursor 账号，实际上是收购完成前 Cursor 团队深度参与的产物。二是门槛不低：Grokbot 目前只有最顶级的 SuperGrok 或者 Cursor 套餐才能使用，200 美元/月。知乎
它的定位也和 Codex 云模式类似：把 harness 搬上云端，本地机只是入口。
实测的好话：三件事确实做对了
博主 AIGCLINK 花了几天做完整测试，给了几个正面评价，恰好是三个值得任何 Agent 开发者抄的设计。
第一，屏幕操作路线。GrokBot 像白领一样操作界面，这意味着哪怕一个 SaaS 系统没有开放 API，AI 员工照样能进去干活。国内大量内部系统没有 API，这条路线的现实意义比海外更大。
第二，teach a task：不写流程文档，你把这件事从头到尾做一遍给它看，它录下来变成可复用的自动化。海外社区里有位老师，把教学大纲、电子教材和课堂系统的权限交给 bot，演示了一遍怎么布置作业，一个小时就训练出了一个助教。写自动化的门槛，从"会写代码的人"降到了"会干这件事的人"。
第三，Skill 和 Routine 分离。xAI 官方文档给了一个很好记的区分：Skill 负责怎么做，Routine 负责什么时候做。知乎可以先通过演示教会技能，再挂上定时或事件触发，比如每天早上七点出简报、Slack 来了新消息自动回复。另外在一个 bot 上登录过 Gmail 或 GitHub，其他 bot 可以直接复用这个连接。
实测的坑：三个硬伤，全是工程问题
同一份实测里，吐槽同样狠，而且每一条都是开发者能听懂的具体问题。
坑一：不能选模型。派哪个模型干哪个活由系统自己决定，界面上没有开关。个人用户无所谓，团队要做成本核算或合规审计，直接卡死。
坑二：账单太糙。用量按周结算，超出部分按原始 token 成本计费，目前还没有花费上限。微博发布那周有人专门买了 Cursor Ultra 去测，后台仪表盘显示零用量，App 里却显示已经用掉 48%——计费系统自己都没对齐。
坑三：稳定性还是 beta。不同网站上表现差距明显，复杂的多步骤指令会被理解错。测试者的总结很直白：整体是 RPA 的重做版，是 ChatGPT work、Claude cowork 的阉割版，唯一的差异是提供了一个可显示的云端电脑。目前 Grok Bot 更像一个白领里的搬运工，从各种网站或后台之间搬运数据和内容，它挺合适的。微博指望它当真正的 AI 员工，还早。
社区一周跑出来的两条共识
GrokBot 公开测试不到一周，海外早期用户已经沉淀出两条高度一致的共识，比官方文档更值得参考。
第一条是信任边界：只生成草稿并加入队列，绝不自动发送。那张被大量转发的截图里，队列中有 36 条 LinkedIn 草稿，但实际发送数量是 0，全部在等待人工审批。知乎喜欢这个产品的人，恰恰是因为这条边界还在。
第二条是"首席幕僚"模式：不要同时和五个 bot 对话，只跟一个 bot 说话，让它负责把任务分发给其他 bot。有用户甚至让一个 bot 专门审计自己的整支 bot 团队，给出管理建议。
还有一个案例值得单独说：一位水管维修公司老板（本人不是开发者）用 24 小时实现了派工和办公室事务自动化，公司一个工程师都没有。但他随后发帖复盘了失败——招聘过一个 Bot，又开除了它，最后承认问题出在自己写了一份糟糕的"岗位说明书"。这可能是目前最诚实的实战反馈：bot 干不好，先检查你派活的描述。
为什么这个形态值得认真对待
有人说，这不就是 Manus 一年多以前做的事吗？没错，但这一波的区别在于：硅谷头部玩家集体下场了。OpenAI 收购 Ona 做云端持久化工作区，xAI 推 Grokbot，Anthropic 的 Claude Code 虽然还跑在本地，但 MCP 协议已经在往无状态方向转。知乎
上云的好处除了多 Agent 并行和训练推理一致性，还有一个很少被提到的点：防蒸馏。模型跑在本地时，每一步中间状态和 tool call 都留在本地；harness 上云之后，中间过程全锁在服务端，用户只能拿到最终结果。
而对开发者来说，这一波最大的收获是"AI 员工"形态的底层单位被定义清楚了：一个身份、一台机器、一组账号权限、一份持续的记忆。不管用谁家的产品，自己设计 Agent 时照着这四个单元对一遍，架构基本就不会跑偏。
不想把钥匙交出去？开源 Rakazo 给了第二条路
GrokBot 的方案要求你把公司账号的钥匙交给一朵美国云，绝大多数中国企业和数据敏感团队不会干。Rakazo 走的正是反方向：全部跑在你自己的机器上，模型自己挑，还能按 bot 分——便宜的做分拣，聪明的写正文。微博
它的核心设计几乎处处对着 GrokBot 的痛点来：
每个 bot = 一个会话 + 一台自己的电脑，Docker 沙箱里带真浏览器和 shell，也可以选 E2B（多人或公网部署）或 desktop（直接跑宿主机，隔离最弱，慎用）；
teach a task 同样支持，流程存成 Markdown 写的 routine，可读、可改、可以直接提交进 git；
权限自己配：哪些事 bot 能自己干、哪些必须先问你，全程 audit log 留在自己手里；
登录态和凭据不出沙箱：你接管一次手动登录，松手后 bot 接着用这个 session。微博
它自带 8 个预制"AI 员工"：销售外呼、收件箱清理、简历初筛、报销、Bug 复现、客户续约、投放监控，外加一个 Chief of Staff 专门调度其他 bot。对企业内部落地来说，可审计加数据在自己手里，比模型跑分实在得多。
该上车还是该观望：按情况分三档
想尝鲜的个人开发者：GrokBot 的早期测试值得申请，但别抱"AI 同事"的期望，把它当"云端搬运工"用——数据搬运、定时简报、盯库存这类持续检查型任务最合适。盯紧两个信号再决定投入：计费上限什么时候出、模型选择器什么时候出。
要在公司落地的团队：现阶段更稳的姿势是学 GrokBot 的架构（身份、机器、权限、记忆四件套），用 Rakazo 这类可自托管的方案做 PoC，把"只出草稿、人工审批"写进流程。
纯观望的人：记住三个观察点——国内会不会出类似产品、GrokBot 的多人协作功能什么时候补上、Rakazo 社区能不能跑出第二个成熟模板。这三个里任何一个落地，这一波才算真正进入可用期。
最后提一句：这波产品证明了一件事——Agent 的竞争焦点已经从"模型多聪明"转移到"harness 怎么管"。做智能体开发的人，与其追新模型发布，不如把这周的架构课吃透。
