ClawSweeper：用保守策略清理 GitHub 議題與 PR 堆積的維護機器人

它解決什麼問題，誰需要它

開源專案的議題與 PR 會隨時間堆積，無人認領的舊議題、被取代的 PR、缺少資訊的回報，最後都變成維護者必須手動篩選的雜訊。ClawSweeper 的定位是保守的維護機器人，不是一個見什麼關什麼的自動關閉工具。它服務的對象是 OpenClaw 這類有多個公開 repository、且維護者時間有限的團隊。從 README 的措辭可以看出，它刻意強調「proposal-only」與「guarded」：審查只提出建議，套用動作有防護，Codex 在審查階段不會拿到寫入憑證。這表示它預設的受眾是那些對自動化行為有高度戒心、需要完整稽核軌跡的維護者。如果你只想要一個簡單的「關閉超過 30 天的議題」腳本，ClawSweeper 的架構會顯得過度設計。

每週掃描與事件驅動的雙軌機制

ClawSweeper 的運作有兩條軌道。第一條是排程掃描，每週一次檢查所有開啟的議題與 PR。第二條是事件驅動，目標 repository 可以用 repository_dispatch 轉送特定的 issue 或 PR 事件，讓單一項目獲得低延遲的審查。這個設計解決了排程掃描的延遲問題，但只對有設定事件轉送的專案有效。每次審查會產生一個 markdown 報告，存放在 records/<repo-slug>/items/<number>.md，內容包含決策、證據、建議給維護者的留言、執行中繼資料與 GitHub 快照雜湊。報告不是寫完就丟，它會同步一個帶標記的公開審查留言，並在原位編輯，而不是重複張貼新留言。如果審查開始時還沒有完整的留言，它會先貼一個狀態佔位，之後再取代成最終審查。這表示維護者永遠只會看到一個留言，而不是一串歷史。

關閉前的多層防護：快照、標籤與作者檢查

自動關閉不是看到建議就執行。Apply 模式會重新抓取 GitHub 的即時狀態，檢查標籤、維護者作者身份、配對的 issue/PR 狀態、快照漂移，以及 repository profile 規則。這些檢查在每次 GitHub 變更前都會重新執行，避免因為審查與套用之間的時間差而誤關。報告會記錄 GitHub snapshot hash，套用時比對是否與審查時一致。如果目標已經被關閉，報告會移到 records/<repo-slug>/closed/；如果被重新開啟，則移回 items/ 當作過期工作。這個「先驗證再動手」的流程，是它與一般自動關閉機器人的最大差異。但要注意，它只關閉「unchanged, high-confidence, policy-allowed」的項目，這表示很多議題即使建議關閉，也不會自動執行，需要維護者手動確認。

維護者命令：從 review 到 automerge 的權限階梯

維護者可以透過留言命令控制 ClawSweeper 的行為。README 列出四個主要命令：@clawsweeper review、@clawsweeper fix、@clawsweeper autofix、@clawsweeper automerge。這些命令代表不同的權限等級：review 只是重新審查，fix 與 autofix 涉及修復，automerge 則直接合併。它還提到一個可選的 GitHub App webhook，可以在 GitHub Actions fallback 啟動前先確認維護者的留言命令。這表示命令處理有兩層：webhook 是低延遲的入口，Actions 是備援。有趣的是，它強調「readiness is not merge authority」，意思是即使審查認為某個 PR 可以合併，也不代表它有權限合併。這個設計把審查與執行分開，避免機器人越權。但對於不熟悉這個流程的維護者，需要花時間理解哪些命令會觸發什麼動作。

決策包與標籤投影：把結構化輸出帶回 GitHub

ClawSweeper 不只產出文字報告，它還讓 Codex 產生結構化的決策包，存放在 records/<repo-slug>/decision-packets/<number>.json。這個 JSON 包含問題、理由、選項、建議與可能的負責人。重點是，標籤與報告文字不會重建決策，決策只存在於這個檔案中。這避免了從非結構化文字推斷意圖的風險。另外，它會把審查結論投影成 GitHub 標籤，例如 current-main reproduction、source reproduction、linked open PRs、queueable fixes、good first issue 等。這些標籤只是輔助維護者過濾，不會觸發任何自動行為。為了避免標籤寫入造成 GitHub updated_at 變化，讓排程器誤判為新的目標端活動，它會在報告中記錄 labels_synced_at。這個細節顯示它對 GitHub API 行為的掌握，但也增加了狀態管理的複雜度。

部署與設定：自我託管不是選項，是必要條件

README 明確表示，OpenClaw 託管的實例不是公開審查服務，也不為第三方 repository 提供免費審查。如果你想在自己的專案使用，必須 fork 這個 repository，在自己的組織中部署，並設定自我託管實例。這代表你需要處理 Cloudflare Worker、R2 儲存、openclaw/clawsweeper-state repository，以及 Codex 的模型服務連線。部署門檻不低，尤其是它依賴多個外部服務。你可以用 scripts/hydrate-state.ts 把分散在 R2 與 state repository 的資料結合成本地狀態，但這只是為了除錯或分析，不是簡化部署。整體架構偏向為 OpenClaw 內部運作設計，外部使用者需要投入時間閱讀 docs/README.md 的架構與操作指南。如果你沒有專職的 DevOps 人力，這個部署成本可能超過它帶來的維護效益。

限制與替代方案：何時它不適合

ClawSweeper 最大的限制是它只對「unchanged, high-confidence, policy-allowed」的項目自動關閉。這表示很多議題即使有明確的關閉建議，還是需要維護者手動處理。對於議題量極大的專案，這可能無法顯著減少維護負擔。另一個限制是它依賴 Codex 進行修復與決策，這表示你需要付費的模型服務，而且 Codex 的輸出品質會直接影響建議的可靠性。如果預算有限，或者你不想引入 AI 依賴，這可能不是好選擇。替代方案是 GitHub 原生的自動關閉機制，例如 stale bot，它根據時間與活動自動標記或關閉議題。stale bot 的運作方式完全不同：它沒有審查報告、沒有決策包、沒有快照驗證，純粹以時間為依據。如果你只需要清理長期未活動的議題，stale bot 的設定成本遠低於 ClawSweeper。但如果你需要的是「為什麼要關閉」的證據鏈，ClawSweeper 是少數提供完整稽核軌跡的選擇。

維護成本與授權：你能承受它的運作複雜度嗎

從 repository 的結構來看，ClawSweeper 的維護成本不低。它需要同步 Cloudflare Durable Object store、R2 的 ledger 與 assets、state repository 的 jobs 與 results，還有 Codex 的執行緒。每次升級都可能影響這些元件的相容性，因為它依賴多個外部服務的 API。它使用 MIT 授權，這表示你可以自由修改與重新發布，但沒有義務回饋上游。這對商業使用是友善的，但你必須自己承擔修復 bug 與更新依賴的責任。README 提到 state branch 只保留 jobs、results、notifications 等，main branch 作為 dashboard renderer，這表示狀態管理有明確的分工，但也代表你需要理解這兩個 branch 的關係才能正確操作。如果你沒有時間追蹤這些細節，採用它可能比手動清理議題更花時間。

編輯結論

ClawSweeper 適合那些擁有大量公開議題與 PR、且願意投入時間設定自我託管實例的開源維護團隊。它不適合只想裝一個現成服務、不打算維護自己的部署的專案。採用前應先確認：你能接受每週一次而非即時的掃描頻率嗎？你能承擔 Cloudflare Worker、R2 與 state repository 的運維成本嗎？最重要的是，先閱讀 VISION.md 與 docs/README.md，確認它的保守關閉策略與你的專案治理風格相符。若你只需要簡單的自動關閉，ClawSweeper 的複雜度可能超出需求。

官方來源

1. Official documentation
2. Official README
3. Project repository
4. Release notes