GrokBot 很惊艳，但我还是弃用了它
上周，我用 GrokBot 来编排跑在 T3 Code 里的各种智能体（agent），一共合并了 78 个 PR。此前我的最好成绩是 35 个。可到了周末，趁我睡觉的时候，我那 16 个崭新发亮的机器人烧掉了 100 美元。钱基本都花在机器人醒来、思考一番、然后决定没什么要告诉我的。等周一该干活了，我整套设置已经瘫痪：我撞上了消费上限，每个机器人、每个例行任务、每个 webhook 都触发失败。不出所料，我提高了上限；也不出所料，在我把数据全部导出、彻底离开这个平台之前，机器人就把额度吃光了。我越来越确信，养一支全天候在线的智能体团队才是正确的工作方式。这个想法确实很好，原因我下面会讲。而 GrokBot 是我们目前最接近「能用」的实现。但它还差得远，问题出在架构上。
我最初为什么想要一支团队
编程智能体已经能完成大量工作。真正让我疲惫的是工作周边的一切：搞清楚哪些 PR 在等审查、一夜之间来了什么、接下来该做什么。我想把这部分脑力负担从自己身上卸下来，交给系统。GrokBot 正是为此而生。每个机器人都是一个智能体，有自己的聊天窗口，在云端有一台自己的小 Linux 电脑；装上桌面应用后，它还能在你的机器上执行命令。机器人可以按计划运行例行任务，也能在 webhook 触发时运行，它们甚至能重新配置彼此。
于是我一口气雇了 16 个，每个负责我工作的一个领域：收件箱、GitHub、Bug、博客、调研等等。有一个 Config bot，它的全部工作就是配置其他机器人；还有一个 Vault bot，是唯一被允许写我笔记的。当某个项目需要同时用几个机器人时，我就把它们拉进一个群聊：「好，在这个房间里我们只做这个项目。」
接着我把它们接入了我的编程环境。我用 T3 Code 写代码，这是一个桌面应用，能并排运行 Claude Code 和 Codex 的线程——因为我的 Anthropic 和 Codex 订阅、以及我喜欢的模型都在那里。我不想通过公网隧道把 T3 暴露到云端：那样的话，任何人只要拿到 URL，或者某个机器人的上下文里被注入了提示，就能在我的电脑上执行命令。
所以我在自己电脑上跑了个小脚本，完全不涉及 AI，只在每个编程会话结束、失败或者需要我介入时，去 ping 一下 GrokBot 的 webhook。这一步会唤醒我的 T3 Code bot，由它来通知我，或者通过桌面应用反过来在我电脑上执行操作。
运行顺利时是什么样子？那一周大部分活儿靠两个例程撑着。一个 GitHub bot 盯着我的 PR，一旦收到"已批准"的评审结果，就通知负责这个 PR 的编程会话去合并。它自己从不直接合并任何东西，其中一个 PR 在批准后两分钟就合并了。另外，每个工作日有三次，我的收件箱、日历和日志 bot 会把查到的东西整理成报告，Vault 再把这些报告变成一张按优先级排序的看板。我不再到处找下一件该做的事，直接做就是了。
78 个 PR 就是这么来的：bot 和我的编程会话协同干活。GrokBot 功不可没：它跑在云端，却照样能用你自己的电脑。我可以随意更换 bot 所在的机器，不用重建任何东西，这方便得有点离谱。登录不会把密码交出去。bot 需要登录凭证或 API key 时，会给你一个输入框让你粘贴，bot 永远看不到具体内容。它很快。快到我会留在聊天窗口里等它追问澄清问题，而不是转身去干别的，这一点比我预想的更重要。它也是我用过最好的 X 爬虫。可惜对 DevRel 来说，这一点至关重要。
有那么几天，感觉像在经营一家小公司。然后感觉像是成了这家公司唯一的项目经理。
"好的，我回头再跟你说"
我交给 bot 的活儿越多，漏掉的也越多，而大部分纰漏都始于同一句话："好的，我回头再跟你说。"然后这个 bot 就再也没下文了，因为没有任何东西会去唤醒它。它的下一次执行，只能等我自己碰巧再给它发消息。
举一个普通的日子。10 月 9 日星期五，我的 24 个编程会话跑完了。bot 准时通知了我其中 17 个，另外 3 个通知晚了。剩下 4 个我压根没收到消息。同一天，一个编程任务失败了两次，没有人告诉我。第二天下午，我让负责协调编程会话的 bot 先把所有合并都压住，等我们处理好一个失败的检查再说。
这个“暂缓”状态根本没有传到各个线程里，46 分钟后，一个 PR 就直接绕过了那道检查合并了。那次运气好，没出问题。群聊确实有帮助，但大约 15% 的情况下，机器人会在自己的一对一频道里回复，而不是在群里。16 个机器人同时说话，我根本看不过来每个频道，而且机器人跟我说过的事，它不会再跟我说第二遍。那个 100 美元的周末也是同一个毛病。我的通知器在每个编码线程的每个阶段都会触发，每个事件都会唤醒一个机器人。于是那个周五，我和机器人们一起设计了一个过滤器：一小段普通代码，用来判断哪些事件值得唤醒人，砍掉了大约 80% 的流量。一个机器人接了这个活并把它做出来了，但没人把它打开，所以编码事件每天仍然会唤醒机器人 500 到 750 次。我发现后的那个早上就修好了，但用量没法撤销。（而且这已经是 200 美元的套餐了。我升级了两次，因为 20 美元的用量就是个笑话，后来 60 美元的也是。）云电脑也脾气古怪。它空闲时会休眠，所以定时任务会晚跑 12 到 80 分钟，不可预测的重启还会把我登出。于是这个本该帮我分担脑力负担的系统，又把负担原样还给了我。我在扩大工作量，结果在缝隙里丢掉了更多。
为什么：GrokBot 自己的团队是这么解释的
在 SpaceX 负责 GrokBot 的 Lee Robinson 在斯坦福做了一场讲座，讲它是怎么构建的，讲得很好，也很坦率。我几乎所有的抱怨都出现在他那张“未解决问题”的幻灯片上。
每次唤醒都是一次模型推理。所有能唤醒机器人的东西（你、例行任务、webhook、另一个机器人、后台任务完成）都通过一个路由器进入那个对话的队列，一次一轮。然后模型会问，用幻灯片上的话说，“有什么值得说的吗？”如果没有，就“允许安静”。只有一个工具 SendToUser 能真正触达你。
这是防止机器人聒噪的聪明办法。但这意味着沉默也要花掉一次完整的模型推理。即使我们修好了过滤器，一个“任务完成”事件还是会唤醒我的 T3 Code 机器人，而它往往会判断这条消息不值得提。我在为这种推理付费，而它基本上只是在决定：“嗯，我觉得我们不该说话。”
这也让跟进变成了一种主观判断。
GrokBot 可以让 bot 订阅它正在等待的工作，但要不要订阅由模型自己决定，而我的 bot 决定得极不稳定。记忆会在你看不到的地方被重写。每轮对话后，后台会跑一遍流程，更新一份“最多 100 条事实、4000 字符”的画像，外加一些“很快淡出”的短期笔记。除非我亲自去读那份画像，否则永远不知道 bot 记住了什么。记忆在你看不到的地方被重写——没有差异对比、没有历史记录，没法审计 bot 对你项目的认知，也没法纠正，只能等它之后行为古怪时再猜原因。
这就是上面几乎每一次失败背后的共同模式。这些都不是模型质量问题，换更大的上下文窗口或更好的提示词也解决不了。每次唤醒都是一次模型调用；每次调用都要悄悄决定，这条新闻值不值得你花钱；而它对要不要跟进、记不记得住、开不开口所做的每一个判断，你都看不见，也无法可靠地推翻。用「员工」这个思路本身是好的。但底下的架构仍然是一堆被人格化的判断组成的，按 token 计费，你一旦不盯着它，它就把脑力负担又扔回给你。
它自己的记忆文件。每个 bot 都能看到每一个技能。模型被训练成「在有几百个技能时挑对的那个」。这挺厉害，但也意味着我的日历 bot 能看到我的 GitHub bot 用过的每个技能。每个 bot 是一个对话配一个队列。帮手在后台干重活，但你对话的那个 bot 扛着你交给它的全部任务。我那些忙碌的 bot 变成了瓶颈，还跟丢了进展。
Lee 对剩下的问题很坦诚。关于协调：「多个 agent 共用一台电脑、一份记忆，会撞上经典的分布式系统问题。」关于何时开口：「消息太多是噪音，太少你又看不出它在干嘛。」关于成本：「只有空闲 agent 几乎不花钱、活跃 agent 也便宜，全天候运行才成立。」
这就是我那一周，浓缩成三张幻灯片。他团队的答案是 Lee 从 Cursor 带到 SpaceX 的一条原则：「删掉产品。」并假设「今天的模型永远是它们最差的样子」，随时准备随模型变强而重建。我同意模型会越来越聪明。我只是不认为更聪明的模型该去负责管道。
要做到这一点，第一部分：管道
我想要的是不牺牲确定性的抽象。让每个模型都只干很小的活，周围的一切交给普通代码：
-
跟进是记录，不是口头承诺。 当某个机器人把工作转交出去时，系统会把它记下来、让机器人订阅，并在任务完成或失败时唤醒它。指望 AI“记得”给你发消息，迟早出事。
-
每个等待都有兜底。 每个跟进任务都有截止时间。如果负责执行的助手崩了，这本身也是一条消息，正在等它的机器人会收到通知。“我稍后回复你”不能没有下文。
-
事件优先，别靠时钟。 我越来越确信，定时任务（cron job）通常是错误的选择。它既浪费资源，又容易漏掉事情：我那 20 个每晚按机器人跑的定时任务，是我这一周第二大开销。机器人应该响应真实事件，而且该由普通代码——而不是模型推理——来决定哪些事件值得唤醒谁。我的原则变成了“一切走 webhook，不花 token”。
-
小决策用小块模型。 有些判断确实需要模型：这件事值不值得唤醒机器人？该通知谁？这条消息是否开启了一个新项目？这不是前沿大模型该干的活。像 TypeSafe 的 Jev 这类决策模型，专门回答这种范围窄、有类型约束的问题。我测试时，一个典型回答耗时不到 200 毫秒，65 次调用花不到十分之一美分。分类器只提供建议，由代码做决定：谁有权做什么，由代码强制执行；分类器在我自己的例子上验证通过之前，它的答案只是提示。
-
默认保持安静。 后台工作进程从不主动发消息。（我有个写代码的机器人，看它干活实在难受。）当机器人真跟我说话时，那是简短、克制的动作，还带长度限制——因为我之前的机器人太啰嗦了。
-
每个任务用全新实例。 给每个任务写清楚描述，只配它需要的工具和技能，就这样。这样就不会有哪个忙碌的机器人变成瓶颈。
我正在做一个开源替代方案，看看这些想法能走多远。但说实话，我更希望它们被大家已经在用的工具采纳。
需要什么，第二部分：活儿该落在哪里
底层管道能保证承诺不丢，但它不会告诉你正在发生什么。到那周结束时，为了搞清楚状况，我得翻遍 16 个聊天频道，还要去查那些我看不见的记忆文件。聊天记录和隐藏记忆是很糟糕的数据库。一个团队需要的是文件柜，而不只是一个群聊。
我确实特意搭建了一个文件柜。Vault 把我的优先级看板放在一个文档应用里，而不是聊天里，这样我随时能打开，机器人也能读回来。这个安排出问题时派上了用场。那个应用的 MCP 服务器开始把数据库读取截断在 2,000 个字符，于是看板停止刷新了——而且我能看到它停了。反过来，当机器人在聊天里忘掉一个承诺时，什么都不会变，所以也没有任何东西提醒我。
那个应用是 Agent-Native Content，而 Agent-Native 是我团队在 Builder 打造的产品。我有偏见，但这也正是我把看板放在那里的原因。Agent-Native 是我们开源的智能体应用框架。Mail、Content、Slides 和 Design 各自配有专属智能体，专为一件事打造，外加一个 MCP 服务器。你在应用里工作，它的智能体——或者任何通过 MCP 接入的外部智能体——操作同一份状态。一个通用机器人可以把活儿交给专为它打造的应用，而你可以打开应用看看发生了什么。而且因为它是开源的，当我的看板出问题时，我直接在上游修好了那个截断问题。
GrokBot 很了不起。它让我实打实地体验了一周：一个永远在线的团队能做到什么，我想要的是能长久维持的那个版本。Agent-Native 只是众多选项之一。无论你基于什么来构建，分工都是一样的：让模型负责推理、写作和编码，把路由、队列、后续跟进和状态管理留给普通代码。我花了 100 美元学到这一课，所以你就不用再交学费了。