50 個 Codex 同時跑：一個人一天關掉 4000 個 GitHub Issue

GitHub issue 列表是一種特殊的技術債。它不像壞掉的程式碼那樣顯而易見，也不像未付的帳單那樣產生立即壓力。它就靜靜地躺在那裡——已經修好的 bug 還開著、重複的功能請求堆在一起、六個月前就沒人回覆的問題——每隔一段時間就有人說「我們應該來整理一下」，然後什麼事都沒發生。

Peter Steinberger 在 2026 年 4 月 25 日做了一件讓很多工程師覺得既解氣又有點不安的事：他造了一個叫 clawsweeper 的系統，讓 50 個 Codex agent 同時跑、全天候掃描 GitHub issue 和 PR，自動判斷哪些已經被實作、哪些根本不合理，然後直接關掉。一天之內，大約 4000 個 issue 被關閉，還有幾千個排隊等著處理。

Peter Steinberger 是誰

要理解這件事的分量，必須先知道這個人是誰。

Steinberger 是 PSPDFKit 的創辦人，這套 PDF 處理工具最終被部署在超過十億台裝置上。他同時也是 OpenClaw（最初叫做 Clawdbot）的創作者，一個後來開源的 GitHub 自動化工具。2026 年 2 月，他加入 OpenAI。

這不是一個在週末玩玩 API 的工程師。他有大型系統的實戰經驗，知道技術債在真實產品裡長什麼樣子，也清楚 GitHub issue 積壓對一個成長中的開源專案意味著什麼。他造的是他自己需要的工具。

clawsweeper 在做什麼

clawsweeper 的邏輯並不複雜，但規模是重點。

系統同時運行 50 個 Codex agent，這些 agent 持續掃描 GitHub repository 的 issue 和 PR。每個 agent 的工作是判斷兩件事：這個 issue 描述的問題是否已經在某個 commit 或 PR 裡被解決了？這個 issue 本身是否有意義，或者它是重複的、描述不清楚的、前提已經不成立的？

如果答案是「已解決」或「不合理」，agent 就關掉它。

50 個 agent 同時在跑，24 小時不間斷。唯一的瓶頸是 GitHub 的 rate limit——這大概是目前為止最誠實的技術告白：不是 AI 的能力到了極限，是 API 配額先到。

這個時間點有其意義

clawsweeper 出現的時機不是偶然的。

2026 年 2 月是多 agent 支援集中爆發的一個月：Grok Build 同時跑 8 個 agent、Windsurf 支援 5 個並行 agent、Claude Code 推出 Agent Teams、Codex CLI 基於 Agents SDK 上線、Devin 開放平行 session。同一個月內，所有主要 AI 開發工具都宣告「同時跑多個 agent」是標配能力，不再是實驗功能。

Codex 本身在 2026 年 4 月的增長數字也相當清楚：每週活躍開發者突破 400 萬，兩週內新增 100 萬用戶。NVIDIA 在一萬人試點後，把 Codex（GPT-5.5）推送給全體員工，Jensen Huang 在內部信裡用了「mind-blowing」和「life-changing」這樣的字眼。

在這個背景下，clawsweeper 並不是什麼超前的實驗——它是一個人把現有工具組合起來，做一件「本來就應該做但沒人去做」的事。

AI 接管的第一批任務不是最難的，是最無聊的

這是 clawsweeper 最值得注意的地方，也是容易被忽略的一點。

AI 代理程式能寫程式這件事，討論已經夠多了。但 clawsweeper 做的不是寫程式，它在做的是維護——一種工程師普遍知道重要、卻普遍不去做的工作。

一個大型開源專案的 issue 列表往往有幾千條。其中可能有三分之一早就被某個 PR 解決了，但沒人去更新狀態；另外一部分是重複提交；還有一部分是提問者兩年前就消失了、問題本身也早就不相關。整理這些需要時間、需要對 codebase 有足夠的理解、而且幾乎不會讓你在 performance review 裡加分。

這正是這類工作被積壓的原因：重要但不緊急、有價值但不顯眼。

clawsweeper 的出現說明了一件事：AI agent 的第一批大規模落地，很可能不是發生在最複雜的工程問題上，而是發生在這些「重要但沒人想做」的維護任務上。

但是，一天關 4000 個 issue 不是沒有代價

批量操作有批量操作的風險，這裡必須說清楚。

一天關掉 4000 個 issue，意味著每個 issue 平均獲得的審查時間極其有限。Codex 的 agent 在判斷「這個 issue 已被解決」時，依賴的是語意比對和 commit 歷史分析——這兩者都不是完美的。一個修復方向相同但實作細節不同的 commit，可能被誤判為「已解決」；一個措辭模糊的 feature request，可能被歸類為「不合理」。

這些都是潛在的 false positive。

更深的問題在於：關閉一個 issue 不等於解決了它背後的需求。如果一個真實的用戶痛點被 AI 判定為「已實作」然後關掉，這個用戶下次再提，可能就不會再提了。他只會默默地停用這個工具。

Codex 本身也有已知的限制。它被鎖在 OpenAI 的生態系統內，無法路由到 Claude 或 Gemini。在複雜的架構重構任務上，批評者指出它的分析仍然相對表淺，無法真正理解大型系統的設計意圖。Codex 的工作流也缺少內嵌程式碼編輯器，審查結果後若需要小修改，還是要切回 IDE 手動處理。

clawsweeper 的效率令人印象深刻，但「已關閉」和「已解決」之間的距離，值得每個計劃部署類似系統的工程師認真思考。

規模擴張的問題不是技術，是判斷

rate limit 是 clawsweeper 目前唯一的實際瓶頸。這句話說起來像是技術樂觀主義，但換個角度看，它也是一個警示。

當 AI agent 的執行速度不再受算力限制，而是受外部 API 限制，這意味著人類審查的窗口變得非常小。clawsweeper 在幾天內可能處理的 issue 數量，一個人工團隊可能需要幾個月。這種速度差異本身不是問題，問題是：在這個速度下，人類要在哪個環節介入，以確保「關閉」的決定是對的？

Steinberger 建的是一個工具，不是一個完全自主的系統——最終的責任仍然在人。但隨著 agent 的數量從 50 擴張到 500、5000，這個「人在哪裡介入」的問題只會更難回答，不會更容易。

目前的答案，大概是：先跑，再看有沒有人回來重開那些被錯誤關掉的 issue。這是實用的工程決策，但它也是一種賭注。

clawsweeper 是一個清楚的訊號：AI agent 正在接管工程維護工作，速度比預期快，規模也比預期大。接下來的問題不是「AI 能不能做這件事」，而是「我們有沒有準備好在這個速度下做出正確的判斷」。