AI守护者：50个Codex引擎全天候运转，单日清理5000+无效议题，开源项目迈入自主维护新时代
AI造成的杂讯，理当由AI自我清理。
就在不久前，OpenClaw创始人兼OpenAI工程师Peter Steinberger完成了一项令人瞩目的突破——
他仅用48小时便构建了一个名为ClawSweeper的系统，激活50个Codex实例，实现全天候不间断扫描。
在24小时内，该工具直接清除了openclaw/openclaw仓库中超过5000个无效议题，另有数以千计仍在等待处理队列中。
这个拥有36万Star的开源巨兽，此前积压了上万个议题和请求。
重复的、过时的、早已在主分支修复却无人处理的、以及AI生成的冗余内容——这些杂讯如同数字垃圾场般堆积。
任何人工维护者面对此景都会感到力不从心。
按照人工处理效率，清理完这些积压约需要整整一年。
而Steinberger借助AI技术，仅用一天就完成了半数工作。
当被问及本轮扫描的开销时，他的回答轻描淡写：不足1000美元。
这意味着，5000多个议题的深度审查与关闭，平均每个成本不足0.2美元。
而使整套系统减速的单一因素，并非模型不够智能，而是GitHub的API速率限制——服务器无法跟上AI处理节奏。
别以为ClawSweeper是一个鲁莽的执行者。
恰恰相反，Steinberger将其设计理念概括为四个字——极致谨慎。
该系统的核心运行在gpt-5.5上，采用高推理努力和快速服务层配置；每个待审条目的Codex审查超时设置为10分钟。
它仅在以下7种情况下才会关闭一个议题：已实现在主分支、当前主分支无法重现、应归属ClawHub的skill/plugin而非core、重复或已被更权威条目取代、在该仓库内具体但不可执行、内容过于混乱不可执行、以及超过60天且缺少足够数据验证bug。
除此之外，一律保持开放状态。
还有一层保障机制：ClawSweeper不会触碰维护者自己发布的条目。
它会先检查GitHub中的身份标识，只要是项目主人、成员或协作者发布的议题，就直接跳过，不会自动关闭。
更谨慎的是，Codex在审查时根本没有写权限。
它只能在只读环境中查看代码、分析上下文、做出判断，然后将结果整理成一份结构化的markdown报告，存储到items/<编号>.md中。
真正的评论和关闭动作，并不会在审查阶段直接执行。
系统要等到进入apply_existing=true模式后，重新抓取最新上下文，再对快照哈希进行重新计算，确认这条议题在提案生成之后没有发生变化，才会真正动手。
Steinberger亲自人工抽检了数百条关闭记录，结果：准确率几乎完美。
ClawSweeper最令人惊叹的设计，或许不是它的关闭逻辑，而是其「监督系统」。
传统做法是什么？
搭建Grafana，配置Prometheus，制作一套精美的后台面板。
Steinberger表示：不需要。README就是我的仪表盘。
ClawSweeper在运行过程中，会实时更新仓库的README.md文件。
当前有多少开放议题、本轮审查了多少条、提议关闭多少条、已执行关闭多少条、GitHub限流到了哪一步——全部以表格形式清晰地展示在README中。
任何人打开GitHub仓库主页，就能看到这个AI裁决者此刻正在执行什么任务。
它让整个清理过程变得完全透明、完全公开、完全可追溯。
任何对「AI擅自关闭我的议题」有疑虑的贡献者，都可以直接点击对应的items/71514.md，查看Codex给出的完整审查理由。
你可能会想，这不就是一个自动化脚本吗？
格局放大一些。
GitHub上有超过4亿个仓库，其中活跃的大型开源项目几乎都面临同一个噩梦——议题坟场。
Kubernetes有4万多个已关闭议题，Linux内核的邮件列表积压更是天文数字。
维护者的时间是世界上最稀缺的资源之一，而大量时间被浪费在「判断这个议题到底还需不需要存在」这种机械劳动上。
ClawSweeper的意义在于，它首次在一个真实的、百万Star级别的仓库中证明：使用AI代理进行大规模的、谨慎的、可追溯的议题分诊，是完全可行的。
5000多个议题的深度审查加关闭，总花费不到1000美元。按单个议题计算，成本大约0.2美元。
而且它7×24小时不休息、不抱怨、不带情绪。
唯一让它慢下来的，只有GitHub API的速率限制。
从某种意义上说，这标志着开源项目从「人工维护」迈向「自愈」的起点。
未来，每一个大型开源仓库可能都会运行一个类似ClawSweeper的机器人，持续监控议题质量，自动过滤杂讯，让人类维护者只需关注那些真正需要人类判断的高价值问题。
有个细节特别值得关注。
ClawSweeper的面板上赫然写着：「状态：应用限流」——GitHub的API限流把它卡住了。
50个Codex并行扫描的速度太快，快到GitHub的服务器开始说「你慢点，我跟不上了」。
在传统软件开发中，速率限制是为了防止攻击。
但现在，它成了AI工作效率的唯一瓶颈。
不是模型不够聪明，不是判断不够准确，纯粹是基础设施跟不上AI的速度。
这大概就是2026年最真实的写照：管道追不上AI。