204 张工单，10 分钟：Grok Bot 团队把机器人当员工用

204 张支持工单，约 10 分钟清完。一个工程师点批准。

这是 SpaceXAI 支持团队在 9 月 18 日的一次事故处理。干活的叫 IncidentSweep，一个 Grok Bot。它先让工程师看批次和消息，然后小批发送，记录动作，失败就停。

功能本身不稀奇。Grok Bot 的文档把它描述成有名字、工作和上下文的 AI 队友。每个 Bot 跑在一台持久云电脑上，有浏览器、文件系统和终端。你发消息，它就在真实工具里干活。所有 Bot 共享同一台云电脑，同一个登录态，交接不用配置。代价是：文档明确说，分开的 bot 不是安全边界。

204 张工单背后是三个窄 bot

这不是一个全能 bot 干的。支持团队拆成三个角色，每个只干一件事：

IncidentWatch：每 5 分钟扫最近 15 分钟的工单，找同一类问题突然增多的信号。没有匹配到已知事故，就提醒值班工程师，并扣住相关工单。
Support Bot：面向客户。团队确认事故并发布状态页后，它回到被扣住的工单里，回复匹配的那些，并跟着进展更新。
IncidentSweep：修复之后，工程师告诉它哪些工单能碰、哪些不能碰、消息怎么写。它逐张检查，把没把握关联的放到一边，先把批次和消息给工程师看，再发送。

SpaceXAI 解决方案工程师 Kiara 把模式压缩成一句话：三个 bot，每个一个工作，发送前有人批准。

为什么一个 bot 只干一个工作？Grok Bot 工程师 Lingxi Li 从工程侧解释过：每个 bot 有自己的记忆和有限上下文，在自己拥有的领域里表现最好。规格和原则在窄领域里保持锋利。

Lauren Tan 在分享里说，Grok Bot 是他们发过最强的 agentic 工具，但只有 1% 的用户用对。她自己的团队是 15 个以上 Grok Bot：一个 Chief of Staff，3 个经理，11 个工人。她把这套结构叫 2026 年的工程设置。

组织图：参谋长和专员

每个团队中心都有一个 Chief of Staff。它不做专员的工作，它负责路由和简报。

SpaceXAI 销售 Krista Letz 的参谋长管会议准备、收件箱、会后草稿，还能拉起其他 agent。解决方案工程的 Kiara 只有这一个通才：外部电话前 30 到 60 分钟，给她五条 bullet，谁在房间里、他们关心什么、上次承诺了什么、她没做的准备、一个风险、链接。没有变化就不说话。产品 n2parko 的参谋长不维护会过期的优先级列表，它跟踪 Slack、邮件和会议里的注意力流向，生成一张 attention list，给其他 bot 当过滤器。

项目一多，需要另一层结构。Eric Zakariasson 的做法是复制人类团队：两个 Notion 数据库，Projects 和 Tasks；一个 Projects Manager bot 处理 meta 工作，用 /Project Ops 技能建项目、开频道、配人；一个项目一个频道，频道里是 bot 名单和 Eric 自己。配人规则也直接：先复用已有 bot，最多再提 5 个专员，每个频道上限 6 个 bot。bot 卡住就把任务标成 Blocked，在频道里 ping 他。

不想从零写 bot，可以用 Lauren Tan 做的 dr eggbot。它先问几个偏好问题，然后创建 bot。标准是：一个工作，一个声音，明确的反工作，也就是它绝不能做的事，外加不留多余工具。

部门怎么落地

研究：Matt Palmer 的 Demo Bot 每天翻他的 X 书签，挑一个新东西，用他的写作技能起草提示。他批准后，云 agent 在 tech-demos 仓库里跑起来，15 分钟后有一个能玩的原型。

内容：Content Bot 每小时扫工程和产品 Slack 频道里的小发布，开一个聊天窗口给社交文案建议，再通过 Typefully MCP 变成草稿。Product Bot 每天慢读一次大公告频道，发一条更新。

销售：Krista 把 Salesforce、Gmail、Calendar、Sheets、Drive、Slack、Notion、Granola、Figma、X、LinkedIn、数据仓库接上。她有每日会议准备 routine，通勤时在手机上看简报；有收件箱 routine，每条要回复的消息附一个用她口吻写的草稿，但从不自动发送；有会后跟进 routine；还有一个过夜 prospecting bot，早上把草稿放进 Gmail。

支持：David Gan 的团队每天几千张工单。他给 Grok Bot 五个工作：发布跟踪、bug 复现、流失分析、退款审核、按角色定制指标图。退款要人批准。

工程：Lingxi Li 跑五个工程师 bot，各管一块：Baltata 管移动共享层和 iOS，Shaoruru 管桌面客户端和 CI/CD，Hogan 管基础设施和归属不清的用户问题，Craig 管 Android，Quill 管 Grok Bot harness。每个都能拉起云 agent、读转录、看 PR 附带的证明、在运行中追问。

运营：Josh Kim 的 Inbox Manager 默认只读。它读每封邮件、Slack 和 DM，但不负责回复。它找的是少量既重要又紧急的消息。工作日 9:05 和 16:05 跑，直到他输入发送指令才发。

设计：John Bai 的团队有 Figma Bro、Motion God、Experiments、Devbot。他让 Experiments 想“随时召唤 bot”的方案，出来三个版本：Mac 刘海里的 bot、桌面角落探头的 bot、跟着光标走的 bot。三个都没按原样发布，但每个都让想法变得可判断。

工程 harness：先验证，再自动化

Lauren Tan 的 pstack 是她个人用的严格工程技能集。她说这套东西让她一个月往生产推 2000 个以上 PR。8 月她收了 2462 个生产 PR。团队每天往 Grok Bot 代码库落几百个 PR，她一边看流、重构、加 lint 和检查，一边做功能。

pstack 的第一条：验证就是全部。验证指 agent 能检查自己的工作，不成功就继续修，这样人不再当瓶颈。她把验证技能当关键基础设施，不当普通技能。

怎么开始：装 pstack，跑 /create-verification-skill；把 dr eggbot 加进名单；让一个工程师 bot 跑一次 /create-verification-skill，再让每日 routine 跑 /maintain-verification-skill。

她的原则叫 Build the Lever：给 agent 工具，不只给 markdown。验证需要一个小的 CLI，能脚本化你的应用：健康检查、开会话、发输入、拿无障碍快照、截图留证、等 UI 稳定、翻 feature flag。破坏性操作加 --dry-run。

pstack v0.15.27 还加了 /create-formal-verification-skill，beta。它是 meta 技能，为你在意的属性建形式验证套件。TLA+ 管状态机和并发，Rust 里用 kani 查未定义行为。Lauren 已经用 TLA+ 建模时找到几个 bug。她还给了个组合：让 agent 画用户流程的状态图，再跑形式验证技能。

X 到 Slack 到修复也是一条链。一个 bot 只负责看 Lauren 的 X 提及，发现 bug 报告就转发到 Slack。Slack 里另一个 bot 用 pstack 分诊、复现、修。两个 bot，一个工作，一个频道当交接点。

技能、routine 和成本

文档把重复工作拆成两块：技能是怎么做，routine 是什么时候跑。顺序是：先做一次，做可靠，存成技能，再自动化。

技能要写清六件事：什么时候用、需要什么输入和权限、工作顺序、怎么验证结果、返回什么、什么需要批准。私人技能是一个库，所有 bot 共用。输入 / 用技能，输入 @ 找 bot、群组、routine 和应用。Teach a task 能演示一次浏览器流程，最长十分钟，不带麦克风。出来的是草稿技能，决策规则、失败处理、批准点要自己加。

routine 的限制要知道：每个 bot 最多 50 个 routine；每个 routine 只保留最近 20 条运行记录；计划间隔至少 5 分钟；每小时总共最多 300 次，每个 routine 最多 200 次；删除立即生效，不能撤销。

成本就藏在这里。Gipp 算过一笔账：一个 routine 每 5 分钟跑一次，一个月醒 8640 次，按他的例子约 397 美元；同样 routine 每小时跑，约 33 美元。同一个 bot、模型、提示，便宜 12 倍。前面加一个很小的变更检查，读 hash、计数或时间戳，只有变了才真跑，5 分钟版本降到约 45 美元，降 89%。事件触发时，没发生事情的运行不花钱。

评论区里 AIron 也点出这一点：很多人第一天会把所有 routine 设成 5 分钟，然后开始怀疑额度去哪了。Gipp 的规则很直接：能事件触发就别轮询；选任务能接受的最慢计划；每个快 routine 前面放变更检查；夜间 routine 别等人批准，无人值守的批准大约 10 分钟后过期；自己留运行日志，Grok Bot 只留 20 条。

记忆分三层：用户层，名字、时区、偏好；agent 层，每个 bot 自己的记忆、档案文件、交互日志；项目层，属于工作的决定和惯例。9 月 28 日 SpaceXAI 上了 Team Bots 公测，面向 Teams 和 Enterprise。一个 bot 可以有共享文件、技能、插件和记忆，发布给整个团队，在应用或 Slack 里用。团队记忆所有人可读，个人笔记保持私密。插件用请求者的权限，不用创建者的权限。

审批：最后是你

文档要求你在请求里就说清楚：bot 能做哪些动作，在哪里停。发送消息或邀请、发布、购买和转账、删除或覆盖数据、改权限、动生产、接受法律条款，这些都要明确。

需要你时，聊天里出现操作和输入，三个按钮：Allow once，只放这一次；Always allow，存一条匹配规则；Deny，阻止。v0.75.5 之后，Deny 会让 bot 停下，不再重试，直到你发新消息。你在的聊天里，批准会等你。无人值守工作发起的批准，比如 routine、触发器、另一个 bot，大约 10 分钟后过期，显示 Expired，动作不执行。

Auto-review 在 Settings → General → Auto-review 打开。它用两类规则检查工具调用和电脑操作：Ask first，匹配就停；Allow automatically，匹配也只在自动审查没找到其他阻止理由时放行。两个都匹配，Ask first 赢。规则写窄，围绕一个已知动作和范围，不要给整个浏览器开白名单。Auto-review 基于模型，它加在最小权限上，不替代最小权限。

剩下的安全清单也直白：密码、2FA 码、验证码、支付确认，你自己接管电脑做；不要把密码粘进聊天。本地电脑默认 Ask every time，没特别理由就 Never allow。共享云电脑上，不用的服务退出登录，删敏感临时文件，撤销不再用的连接器。分享 bot 复制的是配置，不复制你的电脑或登录态，但秘密和客户数据还是别放进要分享的 bot。

回头看每个设置，规则都一样：IncidentSweep 发送前给你看批次，Krista 的 routine 从不自动发，Josh 的 Inbox Manager 只读直到他输入发送，团队自己市场里的 bot 描述里也写着：没有你的 yes，什么都不发。

可复制的顺序

第一周：一个 Chief of Staff。接 Slack、邮件、日历、会议记录。每天早上一条简报，没变化就不说话。然后一次加一个专员，一个工作，写清反工作，只给需要的工具。用 dr eggbot 或市场模板。让一个任务先可靠，存成技能，测试，再用能接受的最慢节奏排 routine。

项目多了：一个项目一个频道和一块板，最多五个专员加一个 PM，加一列 Blocked，卡住就 ping 你。

审批：发送、发布、支付、删除、生产，先 Ask first。Allow automatically 只给窄的只读动作。

记忆：决定放团队记忆，偏好放私人笔记，事实留在实时来源。

工程：先上验证技能，再上 pstack 其余部分。

SpaceXAI 没有靠一个更聪明的 bot 做到 204 张工单 10 分钟。他们靠三个窄 bot，和一个检查批次的工程师。先招一个参谋长。第二个 bot 等第一个无聊了再招。

来源：