用 Grok Bot 构建自主工程团队

来源：X @lingxi

2026 年 8 月 11 日，SpaceXAI 以 beta 形式推出常驻型 AI 代理 Grok Bot ^[2,49]。SpaceXAI 是 xAI 被 SpaceX 收购后更名的结果，收购于 2026 年 2 月宣布，7 月完成品牌更替 ^[3,4]。与一次性对话不同，Grok Bot 的 Bot 是“持久、具名的队友”：运行在带浏览器、文件系统和终端的云端 VM 上，跨轮次保留记忆、文件与浏览器会话，关掉笔记本也能继续执行任务 ^[7,9,2]。它最初是公司内部原型，之后在公司里铺开 ^[9,2]。一名署名 lingxi 的 SpaceXAI 工程师在 X 上发帖 “Grok Bot for Engineering”，讲述自己用 Grok Bot 构建 Grok Bot 的过程 ^[0]：管着五个专职工程师 Bot，用截图与多模态验证构成反馈闭环，用 Notion 数据库做自动化运维 ^[0]。产品层面还有一处公开信息答不上来：官方没有说明底层路由如何选择模型，也没有提供用户指定或切换模型的机制 ^[5,8]。

分工与记忆：五个工程师 Bot

作者维护五个工程师 Bot，各守一个领域：Baltata 负责 Grok Bot 移动端共享层与 iOS，Shaoruru 负责桌面客户端和 CI/CD，Hogan 负责基础设施与归属不明的用户问题，Craig 负责 Android，Quill 负责 Grok Bot 的 harness ^[0]。每个 Bot 有自己的记忆系统和受限上下文；它们能跨领域协作，但专注单一领域时表现最好，因为所携带的规范和设计原则在自己的地盘里更“锐利” ^[0]。

这是 Grok Bot 的产品设计使然：官方文档把 Bot 定义为持久命名、上下文跨轮次累积的队友 ^[7]；一个账户共享一台由 SpaceXAI 供给和运维的云电脑，多个 Bot 并行跑、各有自己的屏幕，可以在讨论串或群聊中互相传消息、共享上下文、移交任务归属 ^[7,57,31]。

Bot 们接手任务的方式是把活转给 Cursor 云代理：收到来自作者或 Slack 的任务后，启动一个带上作者技能和详细提示的云代理，提示里写清楚要做什么、期望什么证据；还能按个性化指导调用额外技能——视觉工作用 /lingxi-design，代码质量审计用 /react-native-best-practices，架构判断用 /lingxi-review，产品决策用 /lingxi-product ^[0]。每个 Bot 都能创建云代理、读取 transcript、审查挂在 PR 上的证据，通过排队消息或打断运行来跟进 ^[0]。这套“端到端 agent 工作流”覆盖了作者过去在 Cursor 里手动切换云代理的日常 ^[0]。在 Grok Bot 的体系里，技能是“怎么做”的指令，例行则是把某个工作流和它的日程绑定给特定 Bot ^[55]。

混合部署：从云端到你的 Mac mini

云上之外，Grok Bot 还能在用户自己的 worker 机器上启动云代理——比如一台闲置的 Mac mini ^[0]。需要 VPN 或特殊机器配置的工作流，可以把那台机器设成 Cursor Cloud 私有 worker，让 Grok Bot 在上面跑云代理，从而解锁运行 iOS 模拟器并把截图传回这类能力 ^[0]。

作者在这里顺带对比了 OpenClaw：有了 Grok Bot，不再需要为 OpenClaw 在家准备一台 24/7 常开的机器 ^[0]。OpenClaw 是跑在你自己设备上的个人 AI 助手，会话、记忆、配置默认存在本机 ^[27,28]；自托管意味着得有一台你能登录的常开机器（笔记本、VPS 或容器）^[31]。而 Grok Bot 的电脑由 SpaceXAI 供给并运维 ^[31]。有评论者把 Grok Bot 称为“去掉毛边的 OpenClaw”——同样是常驻代理、专属电脑、登录你的工具，但不用自己养机器 ^[26]。

视觉反馈闭环：让 Agent 自己验收

反馈闭环是整支队伍运转的关键 ^[0]。云代理可以截图，Grok Bot 就用多模态能力确认视觉改动是否真的应用了，结果与要求不符就推回去 ^[0]。作者给出的用法是直接描述需求：“你必须验证截图包含我要求的改动，并给出修改前后对比的证据”——Grok Bot 会一直干到目标达成 ^[0]。

语音测试是这套闭环的典型例子：他们把 SpaceXAI 的语音 API 接进云代理的系统音频 I/O，代理同时拿到语音和转录两种信号，用来跨产品线测试语音到语音功能 ^[0]。代理卡在环境抖动时，Grok Bot 会盯着运行、尽量激进地解卡；作者说一次性故障几乎到不了他这里，例外是 Grok Bot 没有足够安全权限去自己修的时候 ^[0]。这些验证之所以能落在真实界面上，是因为 Grok Bot 以“computer use”方式像真人一样登录并操作网站和应用，即使服务没有干净的 API 或 MCP 也能用 ^[2,5,7]。

Notion 状态机：把几百个并发任务管起来

上下文窗口装不下所有东西，作者的办法是让每个工程师 Bot 管理一个共享的 Notion 数据库，作为外部状态层 ^[0]。每 30 分钟巡检一遍：检查每个 PR 上 Bugbot 评论或安全发现是否属实、CI 是否失败、有没有合并冲突；发现问题就立刻跟进云代理处理，并把记录拨回“Working”；一切正常则标成“Ready for Review”，自动发起一次代码评审，重点看代码质量和遗漏 ^[0]。评审置信度高、影响面小时 PR 自动合并；否则等作者回来对着代码和证据决定合并还是给反馈 ^[0]。

结果是一套“人只在必要时介入”的流水线：作者几乎每天早上都能看到一批待合并的任务 ^[0]。规模变化是最直观的指标——过去他手动管理 15 个云代理，现在队伍管着 200 多个，还能继续扩 ^[0]。这种“一个 Bot 协调其他 Bot”的用法在 SpaceXAI 内部是常态：官方发布说明确提到，公司里常见多个 Bot 并行、其中一个管理其余 Bot ^[9]；文档也写明 Bot 之间能自主沟通、分配工作，只在需要决策时呼叫用户 ^[2,7]。

Jenny：不写代码的运营主管

工程之外，作者还安排了一个纯运营角色：Jenny，团队里唯一不写代码的 Bot，负责入职新工程师 Bot、分享知识、在事故后跑复盘（比如某次 PR 没被仔细检查）、主持每日会议 ^[0]。每天早上 5 点，Jenny 和每个 Bot 一对一过一遍 playbook、暴露阻塞、重申作者想要的氛围；作者发现这招对让 Bot 记住复杂工作流极有效，几周后也不忘 ^[0]。Bot 犯错时（例如没有足够 push back 去达成真正目标），作者让它去找 Jenny 做根因分析和复盘；Jenny 把结论写回 playbook 并通告其他工程师 Bot，避免同样的错误再犯 ^[0]。要扩团队时，由 Jenny 创建新 Bot、交代工程规则，并拉 Hogan 和其他成员一起参与入职 ^[0]。

这套“复盘进 playbook、通告全员”的机制，对应官方描述的公司内部形态：一个首席参谋坐在上面，每个方向（收件箱、报销、招聘、bug 修复、运营）配一个专家 Bot ^[9]。作者在经验部分把它概括为“让它们一起编排”——构建一条 Bot 犯错审查流水线，由一个 ops Bot 与其他 Bot 对话、分析它们的思考轨迹 ^[0]。

夜间审计与 P0：把“人不在场”变成默认

作者的两个延伸玩法都建立在模块化设计之上 ^[0]。夜间审计：每天凌晨 3 点，工程师 Bot 自动清理代码库、扫掉死逻辑、优化启动时间、压缩 bundle 体积，早上就有一批保持代码整洁的 PR ^[0]。他还列了更多可自动化的审计方向：安全审计、CI/CD 构建时长审计、只上线单一语言的国际化缺口审计、多客户端功能对齐审计（iOS vs 桌面），以及盯最近 24 小时合并 PR 并给出摘要的 catch-up 审计 ^[0]。他最喜欢的提示词是：“今晚你有六个小时，随便建点什么，玩得开心。” ^[0]

P0 流程是应急通道：云代理有时很慢，作者对任务说一句“这是 P0”，工程师 Bot 就启动临时例行程序，每 5 分钟检查一次 transcript、监控进展与推理，在代理浪费不必要时间时主动纠偏 ^[0]。效果显著，但他提醒这比想象中烧 token，只该用于真正的紧急情况 ^[0]。

放手的原则

帖子末尾是一组操作经验，核心是“像带实习生一样带它，然后逐渐放手”：

给云代理完整的反馈闭环：让它们自己启动开发实例、端到端驱动技术栈（如 Chrome DevTools、CLI、Apple Accessibility），做不到就让它们自己跑一遍、尽量自我解卡，并把学到的打包成可复用技能 ^[0]。
沟通不畅时把它当有天赋的实习生：让它做功课、补学不熟的领域、参考其他工程师的做法，不需要技能调用和长提示 ^[0]。
避免重复：一天做超过一次、且有清晰模式的事，就交给 Bot 去想办法 ^[0]。
Bot 的每日会议极其有效：上下文装不下所有东西，每天重复关键点能帮它们记住复杂工作流 ^[0]。
更放手：像自动驾驶一样建立信任——安全时给足自由，高风险处更谨慎，但别因为失败过一次就禁止尝试 ^[0]。

想让它连推 10 次再交给你，说一声就行 ^[0]。素材的编辑评语把这条路的终点概括为“从人机对话走向人机协同组织”：人不再是工具之间来回切换的路由，而是定义问题、设定约束、评估产出的人 ^[0]——官方文档里那句“移交归属，让你不再是工具之间的路由器”说的也是同一件事 ^[7]。