Grok Bot 九篇指南:AI 助手怎样变成一支持续运行的多 Bot 组织

2026 年 8 月中旬到 9 月上旬，xAI 连续发布了九篇 Grok Bot 指南。主题从工程、客服、移动开发，一路延伸到设计、GTM、产品管理、模板和多 Bot 团队。单篇看，它们像一组用法案例；合在一起看，指向的是一个更大的产品变化。

这组内容不再只关心“Bot 能不能把一件事做完”，而是在回答另一类问题：它在哪里工作，带着什么上下文，由谁触发，完成标准是什么，进度存在哪里，遇到高风险动作时谁有最后决定权。

我的判断是，Grok Bot 正在把 AI 助手的产品单位从一次任务，推向一个持续运行的组织层。模型能力仍是底座，但九篇指南花更多篇幅讲的是角色、状态、反馈、节奏和权限。也正是这些部分，决定一群 Bot 是一串热闹的对话，还是一套能运转的工作系统。

Grok Bot 101 给出的定义很直接：它是一个能在计算机上执行动作的个人助手。关键变化来自一台持久云电脑。Bot 能够打开浏览器和应用，使用已经建立的连接，在真实界面里完成任务。

图 1｜Grok Bot 的持久云电脑把浏览器、应用与执行动作放进同一工作环境

这改变了 Agent 的工作边界。普通对话把结果交给人，人再去复制、登录、查询、填写和发送。Grok Bot 的设计是把这些动作留在同一个执行环境里。用户可以私聊它，可以让 Routine 定时触发，也可以让另一个 Bot 调用它。一次请求由此变成一个可能被其他任务、时间表和角色反复调用的工作节点。

Matt Palmer 在 Grok Bot 101 里还给出一个很有解释力的判断：如果一款应用能被拆成输入、逻辑和数据存储，它就可能被改写成 Bot。个人训练 CRM “Arnold”就是这个思路的例子。用户在聊天里输入训练数据，Bot 执行业务逻辑，再把长期记录保存下来。界面可以变，应用的三个基本部分没有消失。

图 2｜个人训练助手 Arnold 展示了输入、逻辑与长期数据如何组合成 Bot 应用

教学方式也贴着真实工作发生。Bot 可以通过文字指令学习，也可以观看一次任务录制。后续的工程、移动开发和 GTM 指南又把这些做法固化为 Skills 或 playbooks。经验不再只存在于某次对话的上下文中，而开始拥有可复用的载体。

但云电脑只解决了“能不能动手”。一个 Bot 即使能够操作所有应用，也不等于它应该承担所有工作。九篇指南紧接着做的事情，是划分角色。

工程篇没有设置一个包办所有代码工作的总 Agent，而是配置了五个领域 Bot。Lingxi Li 给出的理由是，Bot 聚焦单一领域时，携带的 specs 和 design principles 会更准确。Kevin Niparko 在 PM 篇表达了相近经验：角色分区让人更容易引用某个 Agent，可以并行工作，也能把记忆限制在相关范围内。

图 3｜五个工程 Bot 按领域分工，各自保留相关上下文与进度

移动应用的拆法更直观。Ryan Perry 把工作分成用户获取、创意、客户端工程、后端与 live ops、发布管理、QA 与 incident 六个席位。Ryan Perry 估算真正写游戏大约只占整体工作的 15%，其余大量任务散落在增长、运营、质量和发布环节。这个比例是他的实践框架，不是行业统计，但它揭示了为什么“给程序员加一个 coding agent”覆盖不了完整产品循环。

同一种结构还出现在设计和 GTM。John Bai 的设计团队有 Experiments、Motion God、Figma Bro 和 Devbot：有人探索交互，有人调 timing、spring 与 easing，有人读取并编辑真实 Figma 组件，有人把方案带进实现。Krista Letz 的 GTM 配置则由 Chief of Staff 协调会议准备、收件箱和会后草稿，再把 prospecting、account expert、media、data、product、forecasting、slides 和 sales coach 等工作交给对应角色。

图 4｜设计团队把实验、动效、Figma 与实现拆给四个专业 Bot

专业化不是给同一个模型换一组人设。它要求每个角色拥有不同的连接、记忆、Skill 和验收方式。工程 Bot 看测试、构建和部署；客服 Bot 看工单与退款规则；GTM Bot 看账户、会议和销售数据；设计 Bot 回到真实资产和人的品味判断。

角色一多，新的问题马上出现：上游怎样把结果交给下游？Handoff 是这些指南反复使用的接口。一个 Bot 可以把工作移交给另一个 Bot；在多团队实践里，一个项目对应一个频道和一组成员；在移动应用案例中，不同岗位能够把工作跨夜交接。协作不再靠人把每段输出复制到下一段对话。

对话有上下文长度，项目没有。工程篇为每个 Bot 配置共享 Notion 数据库，用来记录 PR、状态和待 review 项目。这样做一方面让 Bot 能跨过单次会话继续工作，另一方面让人不必翻长聊天就能扫描进展。

Eric Zakariasson 的多团队实验把这套结构做得更明确：一个项目等于一个侧栏频道，Projects Manager 根据 brief 创建频道、挑选成员，再用 Notion 的 Projects 和 Tasks 跟踪工作。团队通常控制在五个 Bot 加一个 PM 以内，已有 Bot 可以复用，新建角色需要批准；任务进入 blocked 状态时，再叫人处理。

图 5｜Notion Projects 看板保存每个 Bot 项目的阶段与进度

图 6｜任务看板把 blocked、in progress 与 done 变成人和 Bot 都能检查的外部状态

PM 篇提供了另一种状态。Kevin Niparko 所说的 attention list 不是预先写好的目标或待办，而是从邮件、Slack、会议、日历和实际注意力中涌现出来。它把“我们说重要什么”与“工作真正把时间花在哪里”放在一起比较。

这三种做法分别保存代码工作、项目协作和管理注意力，但机制相同：把共享状态放到一个人和 Bot 都能查询、更新、审阅的位置。记忆回答“这个角色知道什么”，外部状态回答“这项工作现在在哪里”。二者不能互相替代。

Grok Bot 101 里的跨 Slack、Notion、GitHub 搜索，以及 Arnold 的长期训练记录，也都建立在这个基础上。Agent 进入组织后，需要结构化、可维护的工作状态；无限增长的聊天记忆解决不了这个问题。

客服篇把 Routine 称为最大的 unlock：一段已经创建的工作流可以被改成每小时或每天重复的自动化。release tracking、bug reproduction、churn analysis、等待批准的退款和 custom reporting 不必每次重新发起，只要输入持续变化，Routine 就能按约定节奏检查。

图 7｜Routine 把任务说明、触发时间和运行历史固定在同一处

工程团队也用固定节奏运行。Bot 周期性检查 PR，低风险事项按规则处理，不确定或高风险变化留给人 review；运营 Bot Jenny 负责晨间 1:1、postmortem、onboarding 和夜间审计。Routine 让职责拥有时间结构，而不只是等待某个人想起来再发送消息。

Skill 保存的是做法。录制一次 Meta UI 操作、把工程验证步骤写清、根据反馈更新 playbook，都是把隐性的个人操作转成可复用程序。一个团队若每次都靠临时 prompt 重新解释流程，Bot 再多也只是在反复入职。

Template 再把这种工作方式向外传播。模板可以包含 instructions、相关 memories、Skills 和 plugins；它不会带走个人信息、内部连接、custom code、scripts 或 secrets，非标准 MCP 也需要单独设置。Matt Palmer 的“recipe, not meal”很准确：模板传递配方，无法复制已接好内部系统的数字员工。

图 8｜创建模板时会保留必要 memories 与 plugins，并排除个人或内部记忆

这条边界也解释了为什么模板安装前需要看 details。可复用性越强，越要清楚哪些能力来自公开 instructions，哪些依赖本地账号、权限和环境。

工程篇最值得保留的一句话，是Bot 团队要持续运行，必须拥有完整反馈闭环。一个工程 Bot 发起 cloud agent 后，还要看到测试、构建、部署、浏览器验证和截图。没有这些反馈，它只能确认自己产生了代码，不能确认功能真的工作。

图 9｜工程 Bot 返回 PR、测试状态和后续检查入口，形成可验证反馈

其他岗位的反馈载体不同。客服 Bot 从工单、用户描述和退款规则判断下一步；GTM Bot 从会议记录、账户信息和销售数据获得新输入；移动团队用获客与留存结果调整创意和产品；设计团队把实验放进真实产品资产，继续调整 timing、spring、easing 与 Figma 组件。

John Bai 对设计边界的描述尤其重要：这些 Bot 没有把设计变成 one-shot，只是让 loop 更紧。设计判断没有被一次生成替代，工具缩短的是从想法到原型、从原型到反馈、从反馈到下一版的距离。

图 10｜Figma Bot 把真实组件批量填入画布，让设计反馈回到生产资产

结果数字应该放在这个语境里理解。Ryan Perry 报告两个结果可直接追溯到他的 Bot 团队：cost per install 改善 15 倍，D7 retention 提升约 4 倍。Lingxi Li 则称自己的 cloud agents 从 15 个扩展到约 200 个，并创建了 2,000 多个 PR。这些是两位作者的公开运行案例，不是行业平均值；它们的价值在于说明，当角色、状态和反馈接通以后，Bot 可以进入真实业务循环，而不只生成中间材料。

持续运行意味着同一套动作会更频繁地发生。错误也会更频繁地发生。因此，Grok Bot 101 把 permissions、reviewer 和 allow/block lists 放进基础设置，而不是等到高级用例才讨论治理。

图 11｜Bot 设置把屏幕访问、Routine 与权限控制放在同一治理界面

支持篇的退款案例会先按规则分析，真正执行前等待批准。多团队实践中的 blocked 状态会提醒人介入，新建 Bot 也需要许可。PM 篇把外部邮件、购买和删除列为人的重要保留项。设计篇则保留人的品味、方向和最终质量判断。

图 12｜退款 Bot 先汇总建议，真正执行写操作前等待人工批准

这些例子说明，人并没有退出系统。人的位置改变了。它从逐步操作每个界面，转向定义目标、提供上下文、审查模板、设置权限、判断质量和处理例外。

这也是为什么一支 Bot 团队不能只靠更多角色和更多 Routine 扩张。项目进展要可见，完成要可验证，高风险动作要可叫停。少任何一项，所谓自治都可能变成把返工、噪音或风险提前放大。

读完九篇指南，我对“Agent 平台”的理解有一个变化。过去更容易把它看成模型外面的一组工具：浏览器、MCP、记忆、定时任务、子 Agent。单独列出来，它们确实只是功能。

但当这些功能组合起来，系统性质变了。云电脑提供执行环境，连接和记忆提供局部上下文，专业角色划分责任，Handoff 连接上下游，外部数据库保存进度，Routine 维持节奏，Skill 固化教法，反馈定义完成，权限处理例外。组合后的优化对象从某次回答移向一段工作如何长期存在。

这并不意味着每个任务都需要一支 Bot 团队。短任务、低频任务、尚未形成稳定验收的探索工作，继续用单个 Agent 更合理。值得改变的，是那些已经反复发生、跨越多个系统、需要多人接力，而且完成标准可以部分外显的工作。

对于这类工作，最先问的也不该是“要创建几个 Bot”。应该先问六件事。它在哪执行，读哪些上下文，谁负责哪段，状态放在哪里，怎样证明完成，什么情况必须停下来找人。角色数量只是这些答案的结果。

Grok Bot 九篇指南最有价值的地方，是把“AI 员工”这个容易空泛的说法拆回了具体工作。工程、客服、设计、GTM、移动开发和 PM 的任务各不相同，但它们都需要环境、角色、状态、节奏、反馈和权限。

如果你的 Agent 仍然每次从零开始、进度只留在聊天里、结果只能靠人重新检查，那么问题未必是模型不够强。先选一项低风险、重复发生的工作，把触发、外部状态、验收标准和升级路径写完整。等它能够被看见、被验证、被叫停，再考虑让它跑得更久、协作得更远。

持续运行不是一个开关。它是一套组织设计。