ClawSweeper：给 OpenClaw 仓库配一个保守的议题清扫机器人
ClawSweeper 会扫描所有问题和 PR，并建议我们可以关闭哪些内容以及原因。每个 PR/Issue 每周运行一次。
秒懂
- 它是什么？
- ClawSweeper 是一个为 OpenClaw 系仓库设计的维护机器人，定期扫描 issue 和 PR，只建议关闭高置信度的陈旧提案，并支持有边界的自动修复。它拒绝做通用自动关闭器，而是把审查和操作严格分开。
- 适合谁用？
- ClawSweeper 适合维护 OpenClaw 系或 steipete 系公开仓库的团队，尤其是那些 issue 积压严重、又不想冒风险自动关闭提案的维护者。它不适合需要通用审查服务的第三方项目，OpenClaw 托管的实例也不对公众开放。
- 能商用吗？
- 可以。MIT 是宽松许可证：你可以使用、修改并销售基于它的软件，只需保留版权和许可证声明。
- 还在维护吗？
- 在维护。仓库最近一次提交在 1 天前。
- 用什么语言写的？
- 主要是 TypeScript（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
它解决的是维护者的注意力问题
开源仓库的 issue 和 PR 会越积越多，其中不少是重复提案、过时补丁、或者作者已经放弃的修改。维护者每天要花大量时间判断哪些可以关掉，哪些还值得看。ClawSweeper 的目标就是自动完成这部分筛选。它每周扫描一次所有打开的 issue 和 PR，生成一份报告，建议哪些可以关闭，并说明理由。它只对未改动、高置信度、且符合仓库策略的提案执行关闭操作，其余一律只给建议。这个工具不是给所有 GitHub 用户用的，它的生产目标仓库是 openclaw/openclaw、openclaw/clawhub、openclaw/clawsweeper 和 openclaw/fs-safe。其他公开的 openclaw/* 和 steipete/* 仓库可以通过配置 profile 或使用保守的通用回退审查来接入。如果你不是这些组织的维护者，你只能自己 fork 部署。
核心机制：报告与评论分离，操作前二次检查
ClawSweeper 的工作方式可以拆成三层。第一层是审查，它按计划任务或 GitHub 事件触发，对每个 issue 或 PR 生成一份持久化的 markdown 报告，存放在 records/<repo-slug>/items/<number>.md 里。报告包含决策、证据、建议的评论正文、运行时元数据和 GitHub 快照哈希。第二层是评论同步，它在每个 issue 或 PR 上维护一条带标记的公开评论，评论会被原地编辑，而不是反复追加。PR 评论里还藏有隐藏的 verdict 和 action 标记，这样后续的修复和自动合并流程可以直接读取结构化信息，不需要解析人类可读的正文。第三层是应用，也就是真正执行关闭或评论。这一步会重新获取 GitHub 的实时状态，检查标签、作者身份、issue 与 PR 的配对状态、快照是否漂移，以及仓库 profile 规则。任何 GitHub 变更在执行前都会再次核对目标状态。这种设计把审查和操作隔离开，审查阶段 Codex 完全没有写权限，只有应用阶段才可能动仓库。
部署和配置：fork 后自托管，命令从 README 来
ClawSweeper 不是一个可以免费试用的公共机器人。README 明确写了，OpenClaw 托管的实例不提供第三方仓库的免费审查。想用就得 fork 这个仓库，部署到自己的组织里，然后配置成自托管实例。配置的核心是 profile 规则，它决定了哪些仓库可以被审查、关闭策略是什么。运行时通过命令触发，比如 @clawsweeper review、@clawsweeper fix、@clawsweeper autofix 和 @clawsweeper automerge。这些命令可以放在 issue 或 PR 评论里。另外还有一个可选的 GitHub App webhook，可以在 GitHub Actions 回退机制启动之前先响应维护者的命令。对于需要 Codex 参与的修复循环，ClawSweeper 支持本地审查分支范围，仓库凭证和 GitHub 访问都留在本地，只有 Codex 连接配置好的模型服务。部署时还要考虑状态存储，canonical 审查记录放在 Cloudflare Durable Object 里，快照到 R2，操作日志和资产也在 R2。state 分支保留 jobs/、results/、notifications/、apply-report.json 和 repair-apply-report.json，main 分支则是 dashboard 渲染器的源码。scripts/hydrate-state.ts 可以把这些来源合并成本地数据。
局限：保守是特性，也是短板
ClawSweeper 明确不是通用自动关闭机器人。它只关闭未改动、高置信度、且策略允许的提案。这意味着很多明显过时但略有改动的 PR 它不会碰，维护者仍然需要手动处理。另外，它的审查依赖 Codex 模型服务，如果模型服务不可用或者配置错误，整个审查流程就会卡住。文档里提到 review 是 proposal-only，apply 是 guarded，但并没有说明如果 Codex 返回了错误格式的输出会怎样，只提到确定性代码会验证决策包 JSON 的 intent。另一个实际限制是，它只对 openclaw/* 和 steipete/* 的公开仓库提供通用回退审查，其他仓库必须配置明确的 profile，否则不会获得任何审查。如果你期望一个开箱即用、能处理任意 GitHub 仓库的工具，ClawSweeper 会让你失望。
替代方案：与 Stale bot 的哲学差异
最常见的替代品是 GitHub 官方的 stale 机器人，或者 probot/stale。Stale bot 的做法是给长期未活动的 issue 和 PR 打上 stale 标签，等待一段时间后再关闭。它完全基于时间阈值，不分析内容，也不生成理由。ClawSweeper 则相反，它用 Codex 读取 issue 和 PR 的上下文，生成根因分析，并给出为什么可以关闭的明确证据。Stale bot 适合那些只需要按时间清理的仓库，配置简单，行为可预测。ClawSweeper 适合那些希望关闭决策有依据、且能自动修复代码的仓库。代价是 ClawSweeper 的部署复杂度高得多，依赖 Cloudflare Worker、R2、Codex 和 GitHub App，而 Stale bot 只需要一个 GitHub App 和几行配置。如果你只想要简单的过期清理，Stale bot 是更轻的选择。
维护与升级成本：版本节奏快，文档是入口
ClawSweeper 的版本更新很频繁，最近发布有 v0.1.0 在 2026 年 5 月 3 日，v0.2.0 在同一天，v0.3.0 在 6 月 15 日。这意味着项目还在快速迭代，API 和配置可能不稳定。升级时你需要关注 docs/README.md 的文档索引，它按任务和受众组织了架构、配置、dashboard、策略和操作指南。特别是 docs/steerable-repair-automation.md，它涵盖了 issue 到 PR 的完整流程、PR 修复、GitCrawl 摄入、Codex 线程、CrabFleet 控制、完成门槛、配额、dashboard 和恢复。许可证是 MIT，可以自由 fork 和修改，但如果你改了代码并部署，你需要自己维护 fork 与上游的同步。状态存储依赖 R2 和 Cloudflare Durable Object，这意味着运行成本不是零，而且你需要处理 Worker 的配额和 R2 的存储费用。
结论：谁该用，谁不该用
ClawSweeper 适合那些维护 OpenClaw 系或 steipete 系公开仓库的团队，尤其是 issue 积压严重、希望自动化关闭陈旧提案、并且愿意接受复杂部署的维护者。它不适合需要通用审查服务的第三方项目，也不适合只想按时间清理的轻量场景。如果你决定自托管，先验证三点：一是 fork 后能否按 docs 配置好事件派发和定时任务，二是确认 Codex 模型服务的连接方式，三是检查 state 分支与 R2 存储的读写权限。ClawSweeper 的保守哲学意味着它不会主动清理所有垃圾，它只处理证据充分、政策允许的关闭，所以别指望它替代人工维护，它只是把重复劳动压缩到最小。
编辑结论
ClawSweeper 适合维护 OpenClaw 系或 steipete 系公开仓库的团队，尤其是那些 issue 积压严重、又不想冒风险自动关闭提案的维护者。它不适合需要通用审查服务的第三方项目，OpenClaw 托管的实例也不对公众开放。如果你决定自托管，先验证三点：一是 fork 后能否按 docs 配置好事件派发和定时任务，二是确认 Codex 模型服务的连接方式，三是检查 state 分支与 R2 存储的读写权限。ClawSweeper 的保守哲学意味着它不会主动清理所有垃圾，它只处理证据充分、政策允许的关闭，所以别指望它替代人工维护，它只是把重复劳动压缩到最小。
社区笔记