AI革命！OpenClaw创始人24小时清理5000+无效Issue，GitHub服务器险些崩溃

徽声在线报道

编辑：智云 星河

【徽声在线深度】仅耗时2天、成本不足千元、50个AI实例并行运作——OpenClaw创始人推出ClawSweeper工具，单日清理超5000个无效Issue，GitHub服务器因请求过载险些宕机，开源维护领域正式开启AI驱动的「智能自愈」新纪元。

AI制造的数字垃圾，终由AI自身净化

OpenClaw项目创始人、OpenAI资深工程师Peter Steinberger近日完成一项惊人壮举——

他带领团队仅用48小时开发出ClawSweeper系统，通过部署50个Codex智能体实现7×24小时不间断扫描。

在openclaw/openclaw仓库中，该系统单日处理超过5000个无效Issue，另有数千个待处理请求在队列中等待审核。

这个拥有36万Star的顶级开源项目，长期积压着数万条Issue和PR请求。

其中包含大量重复提交、版本过时、已在主分支修复未关闭，以及AI生成的低质量内容——这些数字垃圾如同虚拟坟场般堆积。

传统人工清理方式下，维护者需耗费整整一年才能完成清整。

Steinberger团队通过AI技术，仅用24小时就完成半数清理工作

当被问及运营成本时，Peter轻描淡写地表示：总支出不足1000美元

按单条Issue处理成本计算，平均每个仅需0.2美元。

令人意外的是，制约系统效率的并非AI模型性能，而是GitHub的API速率限制——服务器处理能力跟不上AI的运算速度

智能判官的审慎决策机制

ClawSweeper并非简单的「删除机器」，其设计理念体现着极致的保守主义。

该系统基于gpt-5.5架构，采用高推理强度（high reasoning effort）与快速服务层级（fast service tier）的配置方案；每个待审条目分配10分钟审查时限。

仅在满足以下7种严格条件时，系统才会执行关闭操作：已在主分支实现、当前版本无法复现、属于插件而非核心功能、内容重复或被更权威条目覆盖、描述模糊无法执行、内容混乱不可解析，以及超过60天未更新且缺乏有效验证数据。

除此之外的所有Issue均保持开放状态

系统特别设置三重保护机制：自动跳过项目维护者提交的条目（通过GitHub身份标识识别）、审查过程仅限只读权限、生成结构化审查报告而非直接操作。

审查报告以Markdown格式存储于items/<编号>.md路径，包含完整的逻辑推导过程。

真正的关闭操作需通过双重验证流程

系统进入apply_existing=true模式后，会重新抓取最新上下文并重新计算哈希值，确认Issue在审查期间未发生变更才会执行操作。

经人工抽检数百条关闭记录显示：系统决策准确率接近100%

README文件变身实时仪表盘

ClawSweeper最具创新性的设计，当属其「零成本监控体系」。

传统监控方案需要搭建Grafana+Prometheus组合，而该系统——

直接将README文件转化为动态仪表盘

系统运行期间持续更新仓库的README.md文件，以表格形式实时展示：开放Issue数量、本轮审查总量、建议关闭数量、已执行关闭数量，以及GitHub限流状态等关键指标。

任何访问仓库的用户都能直观了解AI判官的当前操作状态。

这种透明化设计使得整个清理过程完全可追溯、可验证。

对AI操作存疑的贡献者，可直接查阅对应items/71514.md文件中的完整审查逻辑。

开源维护的「自愈」革命

有人质疑这不过是高级自动化脚本，实则远不止于此。

当视野扩展至整个开源生态：

GitHub平台现存超4亿个代码仓库，所有活跃的大型开源项目都面临着「Issue坟场」的困境——

Kubernetes项目积累4万余个已关闭Issue，Linux内核邮件列表的待处理消息更是达到天文数字。

维护者的时间属于最稀缺资源，却大量消耗在机械性的「Issue有效性判断」工作中。

ClawSweeper的实践意义在于，它首次在百万Star量级的真实项目中证明：基于AI代理的大规模、保守型、可审计式Issue分诊系统完全可行

5000余条Issue的深度处理成本不足千元，单条仅需0.2美元。

更重要的是，AI系统具备7×24小时持续运作能力，且不受情绪波动影响。

当前制约系统效率的唯一因素，仅剩GitHub的API速率限制。

这标志着开源维护正式从「人工时代」迈向「自愈时代」

未来每个大型开源项目都可能部署类似ClawSweeper的智能代理，持续监控Issue质量、自动过滤无效内容，使人类维护者得以专注处理真正需要人工干预的高价值问题。

速率限制成为最后防线

系统监控面板上醒目显示着：「State: Apply throttled」——GitHub的API限流机制被迫启动

50个Codex智能体的高速运算能力，甚至让GitHub服务器发出「请求超载」警告。

在传统软件开发中，速率限制主要用于防范网络攻击。

如今却成为制约AI工作效率的唯一瓶颈。

制约因素不再是模型智能程度或决策准确性，而是基础设施的运算承载能力。

这或许预示着2026年的技术图景：基础设施发展滞后于AI进化速度

参考资料：

https://x.com/steipete/status/2047982647264059734

https://github.com/openclaw/clawsweeper