Build a Self-Cleaning Multi-Agent Fleet with Claude + Grok Bot

Setup guidance · Source text。Setup starter: hand to assistant to confirm grouping strategy, cleanup rules, quota gating, and outcome registry before implementation

This block is the prompt. Ads are never placed here.

「grok bot周额度又浪费一半？」这是我 10-20 晚上问的。Grok Bot 是一个桌面 agent 应用，可以开很多个常驻 agent，按周给额度；第二天就要重置，剩下的还有一大截。我跟 Claude 说：把今天剩下的额度去派重活啊。
那一夜我们是真的满载：主 Bot 夜间泵连着跑回测、积分估值、早期机会、网页日报，19 个项目 Bot 并行做深度尽调，总控手里还有一份夜间任务书。早上一看，总控交了 23 份文件，项目 Bot 交了 52 份尽调。
额度读数呢？0 点 42%，早上 7 点 49%。一整夜，只多用了 7 个点。
一单只花零点几个百分点，几十个 agent 一夜也就几百单，临时冲一夜根本吃不完一周的额度。要真用起来，得长期开着更多并行 agent、派长任务。而要长期开着一堆 agent 不乱，光会「建」不够，建谁都会。决定这套东西能不能长期跑的，是删、清、停，以及每个活对结果负责。
下面是我现在这套骨架，能照抄。
侧栏里的 32 个 agent
现在侧栏里一共 32 个 agent，分 4 组：总控 2 个、工人 2 个、持仓项目 10 个、观察项目 18 个。
总控只有一个在干活，就是主 Grok Bot。另一个是早期自建的旧总控，还没清掉，后面单独说。工人两个：探路兵和重活工人。剩下的是一个项目一个 Bot，每天自己去查官网、X、链上，有变化才报，没变化就闭嘴。
分组最早不是这样。原来叫「情报 / 探路 / 挖矿」之类，我看了一眼就觉得别扭——挖矿不就是持仓吗，干嘛单独一组？于是挖矿 Bot 直接并进持仓组。
增删只走一个入口
agent 一多，最怕的是谁都能随手建、随手删，过两周没人说得清哪个是干嘛的。所以所有增删改都收进一个统一入口，我叫它 agent 控制器：
 
规矩就三条：默认只演练（dry-run），加 --apply 才真动；每次动作写一条回执；Claude 在命令行里调它，ChatGPT 通过 MCP 工具调同一个入口，但经 ChatGPT 真建、真删，必须带上我的原话。ChatGPT 那一侧其实还没实际调用过，口子先留着。
有个细节挺关键：分组其实存在账号服务端，本地只是缓存。控制器是通过调试端口调用 app 自己的侧栏命令去改名、建组、挪 agent、排序的，改完重载侧栏，再读一遍核对。新建 agent 时先放进对应角色组，再发角色说明包。每天清理之后自动跑一次「需要时再归组」，缓存显示没漂移就不碰 app。
还有一条保护：调试端口没开，或者主 Bot、探路兵正在答题，就不重启 app。重启会把正在答的单打断，这个代价比分组乱一会儿大得多。
每天凌晨 3:40，自己收摊
清理是这套东西里我最看重的一块。每天凌晨 3:40，自动删掉没价值的项目 Bot。
删除条件很朴素：项目已退出满 3 天，或者休眠满 14 天，或者是「孤儿」——不在跟踪名单里。孤儿也不是见一个删一个：我明确标了 ACTIVE/WATCH 的、项目库里标持有或重点的、还有仓位的、5 天内还在出报告的，都不动。
每次最多删 5 个。删之前先把整段对话备份到本地，再写一条「墓碑」记录。墓碑用来防止删掉的 Bot 被别的流程重建，后面坑里会讲。
10-21 第一次清孤儿，删了 9 个，留下 8 个等我定去留，多半是持仓或者我之前标过观察的。脚本敢删，也会在该停下来的时候留给我定。
 
例行活按种类各自排期
雷达里的例行 Grok 活，以前是一个大轮转，现在按种类各自排期：每类活有自己的最短间隔、每日上限、优先级和配额角色。回滚也简单，删掉这段配置，自动回到旧轮转。
持仓快讯最快 1 小时一次、每天最多 16 次，有新情况直接进我的待办；夜里关掉，因为会推手机，早 7 点自动恢复。其他几类：早期机会、积分估值、回测、网页日报（技术社区 + Hacker News，外加 GitHub 爆发仓库预筛），还有逐个项目的深度尽调。
积分估值现在必须给出单账号期望值数字，低于 100 美元不算合格。回测是线索满 14 天后回查结果，按来源算命中率和提前天数，教训再喂回积分估值。
为什么非要数字？探路兵历史上 108 条收口，67 条因为 Bot 自评档位不够被挡在核验之外，98 条停在「观察」，只有 3 条升级。定性自评加门槛，结果就是几乎没产出。后来探路兵的发现层我也关了，它和雷达重复，近 12 次有 9 次没有下游。
额度门禁：按百分点记账
额度不按 token 记，按服务商显示的「百分点」记，因为那才是真正会被卡住的东西。
我在 9-19 定过一个调子：付费的周额度要用狠一点，空着就是浪费。所以门禁是用到 99% 才停，留 1% 应急。离重置不到 24 小时、还剩 30% 以上，就提速：监控类每 5 分钟一次，发现类每 10 分钟一次。比一周的时间进度落后 15 个点以上，节奏加快 3 倍。
另外有一条死规矩：发出去但没拿到结果的单，永远不重发，同一个任务号一直锁着。24 小时后它不再占当天额度，72 小时后不再堵这条通道。宁可少一单，也不要重复下单。
踩过的四个坑
 
Bot 空转，周额度白白作废
开头那句话问的就是这件事。
主因两个：雷达有 23 点到 7 点的暂停规则，夜里 Bot 直接闲着；本地 Grok Bot 一次只答一单，这是真实吞吐上限。当晚中途 Claude 又发现 Bot 空着，我那句话现在还记得：「我都跟你说了，明天额度就重置了……然后你又发现 Grok 是空闲的」。
修法就是开头那三路满载。但满载一夜也只用了 7 个点，本周还有一半左右在重置时作废。结论很清楚：别指望临时冲量，要长期开更多并行 agent、派长任务。
CLI 和 Bot 是两个独立额度池
用 Grok CLI 并行跑了 20 个活，Bot 的读数还是 42%，一动不动。两边连重置日都不一样。
既然是另一个池，就给它另一种活：行为不变的重构。CLI 在内核沙箱 strict 模式下跑，只能写自己的工作目录；先放金丝雀文件验证它读不到外面，外部读取一律 Operation not permitted。先后 12 个大脚本重构，每个都经过独立逐函数审查加测试复跑才合进本地 main。另外补了 3 份测试，其中一份测出 10 个真 bug。
旧总控清不干净
10-21 我问：所以我现在还是有两个总控对话吗？
实际派活的只有主 Bot。10-18 起改成单一总控，派活工具会直接拒绝发给旧总控。但旧总控身上还挂着当初替几个项目建的每日例行任务，结果写进它自己的对话里。直接删，这些例行任务的结果就一起没了。要清干净，得先把例行任务搬到对应的项目 Bot，再归档。这个我还没做完。
单个 agent 老被打断
夜里一条「建新 agent」的指令插进了总控对话，把总控打断了：0:52 之后它就停了，19 个项目 Bot 的尽调队列也清空，Bot 差点又闲下来。01:18 补了一条「继续」，把重活工人和项目 Bot 第二轮都交给它调度，才接上。
根子在于主 Bot 一次只答一单，雷达、夜间任务、人工插单全挤在一个对话里，互相打断。我的态度是：有必要就开新 agent。于是有了「重活工人」专接长任务。它是主 Bot 自己建的，第一单是只读审计 agent 控制器和清理脚本的代码，回了 8 条发现，全部修进了代码。
这个坑还连带出两个小坑。一个是删 Bot 时要逐个打开对话，app 的本地缓存把主 Bot 和探路兵的副本挤掉了，夜间泵 7 分钟读不到探路兵的结果；手动重开恢复，之后加了自动恢复。另一个更隐蔽：删掉的一个观察项目 Bot，几小时后被另一个每 6 小时跑一次的同步流程当成「新对象」重建了，因为同步不看墓碑。修法是让同步读墓碑，墓碑项目不再自动重建。
让总控自己派活
10-20 晚我跟 Claude 说得很直接：你应该跟 grok bot 总控对话，其他的派活消耗额度让她搞，这样才能节省你的，消耗他的。
我对分工的判断一直是这样：总控自己拆活派活，Claude 只做判断、验收、写回。AI 是可替换的工具，事实和结果写回文件才算数，聊天记录不算。
那晚 Claude 只发了一份夜间任务书。总控自己派了两路持仓研究、两轮新机会、两轮回测、两批内容选题、重活工人 10 单，还有几个项目 Bot 的深度简报。02:06 交夜报，23 个文件，全程只读，所有线索标「未核实」。
它还顺手查出两个我们自己没发现的运维问题：一个定时任务的间隔配置被改大后，雷达全量扫描停了两天多；告警通道也哑了。也越过一次界：重活工人在规定目录外多写了一个文件和三个临时文件。总控在夜报里自己报了出来，没删，留给我定。
每个活都要对结果负责
所有 AI 长期活都登记在一张表里，每条写清楚要让什么变好（outcome）、机读指标和门槛。现在登记了 44 条，和 Grok 相关的 23 条。
每日体检按指标判：推动了结果、无结果第 N 天，或者 UNKNOWN。读不到就是 UNKNOWN，既不算成功也不触发停机。连续 14 天无结果（中间没有 UNKNOWN）、上线也满 14 天的活，体检自动停掉，记一条带恢复方法的回执，在我待办里写一行。
这个原则借自 Marty Cagan 的《INSPIRED》：活对结果负责，不对产出负责。举两个例子：「团队精简」这条活，指标是 14 天内有没有一次被真正采用的精简；「私有群信号」那条活每天都送到了，但没人确认，按规则它会被停。送到了不等于有用。
还缺的东西
拿网上常见的多 agent 做法对照了一下：一个总管 Bot 分派、几个专职 Bot 各管一摊、共享记忆文件、Bot 之间直接发消息。总控加项目 Bot 分组、额度门禁、结果登记和自动停、每日清理，这几样我们走得更远。
但缺的也很明确，按影响排：派活大部分还是 Claude 和本机脚本通过界面一条条发进去的，既吃 Claude 额度，又依赖界面锁和调试端口，挺脆；没有全队共享的任务板；Bot 之间直接发消息还没验证；干活的 Bot 太少，排队串行。
下一步就照着这几条补：让派活真正落到 Grok 自己手里，多开几个能并行接长活的工人。Bot 能做的事很多，本机的活也可以给它，不用限制它的能力，对我有用就行。
给 AI 搭团队，「建」谁都会。能让它长期跑下去的，是删得掉、清得干净、停得下来，每个活都对结果负责。
关于作者：Leo ([@runes_leo](https://x.com/runes_leo))，AI x Crypto 独立构建者，用 Claude Code、Codex 等多个 AI 搭建数据分析与自动化系统。
leolabs.me：文章 · 社群 · 开源工具 · 独立项目 · 全平台账号
Leo Insider：付费内容周更，当前支持 X 入口订阅。
Learn in public, Build in public.

Read the full skeleton first, then confirm your Grok Bot supports multiple persistent agents and debug-port access; implement grouping, unified entry, cleanup rules, scheduling/gating, and outcome registry in order.