一个月 130 万美元的 token 消耗？拆解 OpenClaw 开源维护范式
轻量云煮鸡约 12 分钟导读：
OpenClaw 创始人 Peter Steinberger 的 CodexBar 截图显示，30 天 token 成本估算约 130 万美元，在开发者社区引发了激烈讨论。但真正值得关注的问题不是「烧了多少」，而是「烧出了什么」。
本文作者为 OpenClaw 项目 maintainer，基于一线维护经验，以 OpenClaw 的自动化维护系统 clawsweeper 为案例，拆解其如何通过分层决策、保守自动化、先建设后优化的设计思想，将维护队列从上万降至可管理量级，并探讨 token 成本下降后软件构建方式的根本性变化。
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
前言
OpenClaw 创始人 Peter Steinberger 的 CodexBar 截图显示，30 天 token 成本估算约 130 万美元，在开发者社区引发了激烈讨论。
Peter 发出的 CodexBar 截图：30 天 token 成本约 130 万美元
截图一发出来，他的 X 评论区就炸了。「请几个工程师不比烧 token 划算？」「OpenClaw 烧了这么多，bug 还不是一堆？」有一条最刻薄——「你在 OpenAI 有无限 token，我们可没有，炫耀这个有意思吗？」
clawsweeper诞生
clawsweeper 不是凭空出现的，它是从 Peter 自己处理海量 PR 的工作流里长出来的。
早在今年 2 月，他就发帖吐槽过怎么应对海量 PR 的涌入，并给出了自己的做法：并行启动 50 个 Codex 去分析每个 PR，提取意图、风险等信号，生成 JSON 报告；再把所有报告汇总进一个会话，统一做去重、关闭或 merge。
图：Peter 早些时候使用 50 个 Codex 分析处理 PR
这就是 clawsweeper 的雏形。它的演化路径很清楚：
一个原本靠人手反复执行的处理流程，先被写成一次性的并行脚本，流程被验证有效后，再逐步固化成常驻的自动化系统。
而 clawsweeper 比一次性脚本走得更远——Peter 把这套工作流做成了 bot 并开源。它不需要人去触发，自己跑在云端，每天自动分诊、处理。
一个注定挨骂的bot，结果没挨骂
对于 clawsweeper 这种自动化机器人，处理上必须非常谨慎：某个逻辑错误，或者 agent 处理过程中的一点不严谨，都可能一不小心把整个社区情绪给点燃了。
四月下旬，clawsweeper 第一次上线，同期还搭配了 clownfish——一个自动修复 main 分支 commit bug 的 bot（Peter 确实花了很多心思给 maintainer 的合并兜底）。
clawsweeper 上线同期，clownfish 也接入了自动修复 commit 的流程
Peter 一向把贡献者体验看得很重。OpenClaw 的提交门禁脚本和 CI 里，甚至有大量代码专门检查 changelog 有没有漏掉对贡献者的感谢。一个连「别漏了谁的感谢」都要写进门禁的人，不太可能让 bot 粗暴地把贡献者的劳动一关了之。
而后来的发展，也确实没有按最坏的剧本走。Peter 的 X 评论区没有出现预想中海量的「PR 被关」投诉，反而有不少贡献者认可关闭的理由：有人说「我的 PR 被关了，看了理由觉得心服口服」；也有人说「一大早收到好几封 PR 被关的邮件，但我挺高兴，这些 PR 确实重复了，关掉它们反而能让 maintainer 看到真正解决问题的 PR」。
贡献者 @juliabushcodes 的反馈：clawsweeper 关闭了大量重复 PR
仓库里曾经因为每人最多 10 个 PR 的限制而积压严重，这次清理帮了大忙。
关键就在于，clawsweeper 关闭 PR 时会附上一条完整的证据链——比如「这个修复在 main 上已经有对应实现了」——而不是冷冰冰地打一个 stale 标签。
这正是它和传统 bot 的本质区别，也是贡献者服气的原因。社群里的负面讨论，更多是外界对自动化的本能怀疑；而这些来自一线贡献者的反馈，才真正让我收起「这是不是在搞」的念头，开始认真想另一个问题：它到底是怎么做到的？
具体做法
降噪：清掉无效的PR和Issue
在传统项目里，maintainer 团队会有人专门分诊、打标签；其他 maintainer 拿到一个 PR，要读 diff、理解意图、检查测试、评估风险，一个 PR 花掉 30 分钟甚至几小时都很正常。OpenClaw 爆火后大量 PR 涌入，这套人工流程根本扛不住。
社区原本有个 bot 叫 Barnacle，能根据代码 diff 自动打标签，但它只会做机械匹配，碰到需要「读懂意图」的场景就无能为力。
clawsweeper 补的正是这块：它会核对一个 PR 要修的问题是不是已经在 main 里修好了，如果是就直接关闭；也会在多个处理同一问题的 PR 里挑出质量最高的那一个、关掉其余。maintainer 的处理队列从上万降到了可管理的量级。
提效：结构化输出加速判断
剩下的高价值 PR，才是 maintainer 日常的硬仗。即便 OpenClaw 热度已不如最高时期，社区 PR 仍维持在 3000 多个。
clawsweeper 用结构化的信息输出来加速 maintainer 的决策：一句话总结、PR 评级、真实行为证据、合并前风险、安全问题。其中最具实用价值的是「Risk before merge」——它常常能反映关键的设计决策变化。
例如，clawsweeper 对一个 A 级 PR（🦞 diamond lobster）给出的合并前风险提示是：
Compatibility-sensitive upgrade behavior remains: openclaw doctor --fix will rewrite existing HEARTBEAT.md files that exactly match known legacy docs templates, so maintainers should explicitly accept that migration even though custom-content cases are preserved.
这条提示点出的风险是：该 PR 执行 doctor --fix 时会去动用户已有的模板文件，属于需要谨慎对待的行为，maintainer 最好先确认这是不是预期内的改动。
有了这一层提示，maintainer 不必逐行读 diff 也能快速定位关键风险；但最终是否合并，仍然由人拍板。
当然，clawsweeper 能提示风险，不代表它能替人承担最终责任。有一个反例：某个改动让 model catalog 在每次请求时都重新 resolve，引入了明显的性能回归。
clawsweeper 的 review 事先就 flag 过「没有完整的性能证明（no full performance proof）」，但这条提示被疏忽了，PR 还是合了进去。被 review flag 过的风险，如果 maintainer 忽略，系统照样会出问题。
这正是「合并会带来的关键行为变化」——clawsweeper 把一个容易被忽略的副作用一眼挑了出来，提醒 maintainer 别漏掉。
上云：把合并的本地负担交给 agent
合并流程在 OpenClaw 也不轻松。
Peter 的主张是低摩擦：PR 大体可行但有小问题时，不来回找原作者改，而是 review 后直接起一个 coding agent 修完、跑测试、补 changelog，直接 push 合并。
随着项目体量的扩大，回归测试覆盖的范围和深度都在增加，但这也导致了本地跑 gate 的成本越来越高——早先 Mac Mini 跑一轮 7 分钟还能撑，如今低配机器根本扛不住，换成 GitHub CI 反馈闭环又太长。
clawsweeper 上云：把合并的本地负担交给 agent
Peter 的解法不是逼大家升级配置，而是把整条流程搬上云：在拿到云厂商的赞助后，clawsweeper 的 automerge 把「review→修复→门禁→push」全部放到云端，不再依赖 maintainer 本地算力。
传承：经验如何在开源里沉淀
前面这些功能——降噪、提效、上云——没有一个是第一天就设计好的。Peter 最早就是发一串提示词下去，本地先跑起来再说。
用 OpenAI 的话说，这其实就是 Harness Engineering：不是追求一开始就完美，而是先把东西扔进真实场景，再根据反馈一点点把流程和环境建起来。
而最让我觉得这件事更有意思的，是 clawsweeper 从一出生就是开源的。Peter 写下骨架，也提供了一个大家沉淀知识的容器。
贡献者和 maintainer 把各自的经验一点点添进去——完善面板、加固流程，有人甚至因为做得好被请进了 maintainer 群组，最后大家都从中受益。
这其实就是知识的传承，也是开源最迷人的地方。
激进的外表，保守的内核
clawsweeper 看起来很激进——自动扫 PR、自动关单、自动参与修复——但它的工程设计其实相
当保守。理解它的关键，是一句话。这句话听起来简单，但它的实现方式，才是 clawsweeper 真正的巧思所在：
让模型负责理解，让程序负责授权。
Review lane 与 Apply lane 分离的保守自动化结构
所谓保守自动化，不是少用 AI，而是让 AI 只在它擅长的位置发挥作用，把最终授权交给确定性程序和可审计的流程。
clawsweeper 的核心能力——扫描 PR、关闭无效 PR、做分诊——就建立在这条原则上，具体落在几条互相隔离的 lane 里。
发现交给模型，执行交给程序
clawsweeper 把分析和执行拆成两条独立的 lane：Review lane 只让 AI 读代码、出结论，不执行任何写操作；Apply lane 里没有任何模型参与，只根据 Review 的结构化报告和实时仓库状态做确定性校验，符合条件才执行关闭或合并。
这套分离带来的价值很直接——AI 的误判不会直接变成 GitHub 上的破坏性动作。
clawsweeper 的保守自动化边界：模型负责理解和提出建议，真正的 GitHub 写操作交给确定性程序执行。
自动修复搬上云，给 maintainer 减负
Repair lane 主要服务 automerge、autofix 这类 maintainer 命令，是唯一真正允许 Codex 动手修 bug 的一条 lane。
它的设计出奇简单——没有自己造一个 coding agent，而是直接用 Codex 来完成修复。
但直接给 Codex 放权显然不现实，所以它在外层套了一个确定性执行器：Codex 产出修复方案后，执行器会先验证仓库状态、检查权限和策略，确认无误后才真正写入。
如果让 Codex 直接拿着 GitHub Token 去执行，它可能误解目标 PR、push 到错误的分支、在 PR 上重复刷屏，甚至在 force commit 时覆盖掉贡献者的身份。
确定性执行器存在的意义，就是把这些高确定性要求的操作用脚本封装起来，挡住模型可能搞出的乱子。
兜底：逐个 commit 再审
最后一条 lane 针对每个 commit 做 review。它专门应对那些直接 push main 的 commit——比如主干上发现重大安全漏洞需要尽快修，或者发布流程中验证测试失败、捕获了回归需要立刻处理。
这类变更如果攒进一个 PR 慢慢合，等待期间冲突只会越积越多。
Commit Review lane 补上「直接进 main」留下的审查缺口：它的 prompt 更聚焦于单次 commit 会不会引起功能回归，一旦发现问题，就激活 Repair lane 再发起一轮自动修复。
把审查报告变成升级攻略
如果说前面那些功能主要是为 maintainer 服务的，那么接下来这个功能，更多是用来帮助和指引贡献者的。
最能体现这一点的，就是评级系统。clawsweeper 给出的报告里，会附上一个「甲壳生物宇宙」的评级，从 S 级的 🦀 challenger crab、A 级的 🦞 diamond lobster，一路到 F 级的 🧂 unranked krab 和 N/A 的 🌊 off-meta tidepool。这套机制把提交 PR 变得有点像玩游戏：
PR ratingOverall: 🐚 platinum hermit...Rank-up moves:Confirm that per-phase image timeout semantics are acceptable for existing deployments.
这其实戳中了一个很多人忽略的痛点：不少贡献者提交了 PR，却根本不知道怎样才能让它变得更高质量。
clawsweeper 把一份冷冰冰的审查报告，变成了一份「升级攻略」——贡献者照着 Rank-up moves 就能知道这个 PR 还差在哪，围绕证据、补丁质量去改进，像升级打怪一样获得正反馈，进而更愿意主动提改进。
所以它既在帮 maintainer 省事，也在帮整个社区建立「什么是一个好 PR」的共识：把这件原本要靠经验积累的事，结构化地讲给每一个贡献者听。
对 maintainer 这边，评级也顺手提供了一个优先级——可以先处理那些准备得更充分的高质量 PR，加快落地速度。
这些token到底买到了什么
clawsweeper 初看确实让人觉得对 token 太大手大脚了：社区每天还在涌入大量 PR，每个都要审，每个 commit 都要再审一遍——合并前不是已经审过了？
不过这里得先厘清口径：130 万是 CodexBar 按官方 API 价估算出来的，而 Peter 在 OpenAI，内部算力的实际核算要低得多，并没有真掏出这么多现金（他还提过，单是关掉 fast 模式就能明显降本）。
但这不影响要害——token 该不该省当然值得讨论，只是在 clawsweeper 这个场景里，有比 token 更贵的东西：maintainer 的注意力。
再加上有 OpenAI 的支持和赞助，OpenClaw 既有条件、也愿意为这种「质量保险」买单。换句话说，这些 token 买到的，是把 maintainer 从重复劳动里解放出来。
而且 clawsweeper 也不是只会闷头烧 token 的粗放机器，它的设计里其实藏了不少省钱的小心思：
它会看一个 PR、Issue 活不活跃来决定多久扫一次，活跃的勤一点、沉寂的就放慢；每份报告都记一个内容快照，没变化就不重复 review；
不同任务也配不同档位的模型，分类垃圾、过滤 spam 这种小事用最便宜的，只有最核心的 review 和修复才上最强的。这些加起来，能省掉相当一部分本来会白烧的调用。
顺着这个思路再往前推一步：如果有一天 token 真的不再是约束呢？
Peter 在那条推特里问的，正是这个问题：「How would we build software in the future if tokens don't matter?」——如果未来 token 不再重要，我们会怎样构建软件？
token 成本下降后人和 agent 的三层分工
这更像一个思考实验：如果调用 AI 的边际成本趋近于零，软件构建方式会发生什么根本性变化？
clawsweeper 某种程度上已经把这个实验跑了一遍——当不必计较成本，agent 能不能去做那些「人可以做、但不应该花时间做」的事？
回头看它在各种场景里发挥的作用，会发现这些活儿大致落在三层，分界就是任务的「摩擦度」：
- 低摩擦任务：（分类垃圾、过滤 spam、格式检查）：更适合自动化，通常不需要人参与；
- 中摩擦任务：（PR 分诊、风险提示、代码审查建议）：AI 辅助判断，人做最终决策；
- 高摩擦任务：（架构设计、方向决策、社区治理）：仍然由人负责。
这三层不是固定的。随着模型能力进步、token 成本继续下降，原本需要人做的部分工作会逐渐被推向低摩擦区域。
Scaling law 目前还没有失效的迹象——与其说 Peter 在炫耀自己有无限 token，不如说他在用一个最极端的条件做实验：当约束放松之后，最优解会长什么样？
结语
clawsweeper 的本质，就是把那些「人可以做、但不应该花时间做」的事情，变成一套自动化流水线，从而把 maintainer 的注意力彻底释放出来，去做只有人能做的事。
那对我们这些旁观者来说，能从中学到什么？
对于不同规模的团队，clawsweeper 提供了可迁移的设计原则：
- 分层决策：让模型负责理解，让程序负责授权。AI 的输出不直接变成破坏性动作。
- 保守自动化：高风险写操作必须经过确定性校验，不因为追求自动化而放弃安全边界。
- 先建设后优化：先把核心流程跑通、验证假设，之后再针对真实瓶颈做成本优化。
- 确定性执行：对仓库状态检查、权限校验、分支操作等环节用脚本封装，挡住模型可能的误操作。
你可能不需要 50 个并行 Codex，但你或许需要一个 bot 帮你做 PR 的初步分类。
你可能不需要 GPT-5.5 high reasoning 去审每一个 commit，但你或许需要一个便宜的模型帮你过滤掉明显的垃圾。
你可能不需要 10+ 层确定性校验，但至少可以在高风险操作之前，加一层人类确认。
规模不同，原则相通。而且随着 token 成本继续下降，今天 OpenClaw 这种「奢侈」的做法，很可能会慢慢变成越来越多团队的默认选项。