我已經不再直接使用 Codex 或 Claude Code 了。
我改用 OpenClaw 作為我的編排層。我的編排器 Zoe 會產生 Agent、撰寫提示詞、為每項任務挑選適合的模型、監控進度,並在 PR 準備好合併時透過 Telegram 通知我。
過去 4 週的成果:
- 一天 94 個 commit。這是我生產力最高的一天——我有 3 通客戶電話,但一次也沒打開編輯器。平均每天大約 50 個 commit。
- 30 分鐘內 7 個 PR。從想法到實際上線的速度極快,因為編碼和驗證大多已自動化。
- Commits → MRR:我正在用這個系統開發一個真正的 B2B SaaS 產品——結合創辦人主導的銷售,實現大部分功能需求當天交付。速度能將潛在客戶轉化為付費用戶。

我的 Git 記錄看起來就像剛雇用了一個開發團隊。但實際上只有我一個人,從管理 Claude Code 轉變為管理一個 OpenClaw Agent,而這個 Agent 又管理一群其他的 Claude Code 和 Codex Agent。
成功率:系統幾乎不需要任何干預就能一次性完成所有中小型任務。
成本:Claude 約每月 $100 美元,Codex 約每月 $90 美元,但你可以從 $20 美元開始。
以下是為什麼這比直接使用 Codex 或 Claude Code 更好的原因:
>Codex 和 Claude Code 對你的業務幾乎沒有背景了解。
它們只看到程式碼,看不到你業務的全貌。
OpenClaw 改變了這個局面。它扮演你與所有 Agent 之間的編排層——它將我所有的業務背景(客戶資料、會議記錄、過往決策、哪些有效、哪些失敗)存放在我的 Obsidian 筆記庫中,並將歷史背景轉化為精準的提示詞給每個編碼 Agent。Agent 專注於程式碼,編排器則專注於高層策略。
以下是這個系統的高層運作方式:

上週 Stripe 發表了他們稱為「Minions」的背景 Agent 系統——由集中式編排層支援的平行編碼 Agent。我無意間也做出了同樣的東西,但它是在我的 Mac mini 上本機運行的。
在我告訴你如何設定之前,你應該先了解為什麼需要一個 Agent 編排器。
為什麼單一 AI 無法兩者兼顧
上下文視窗是 零和遊戲。你必須選擇放入什麼內容。
塞滿程式碼 → 就沒有空間放業務背景。塞滿客戶歷史 → 就沒有空間放程式碼庫。這就是兩層系統有效的原因:每個 AI 只載入它所需要的內容。
OpenClaw 和 Codex 的上下文截然不同:

透過上下文實現專業化,而不是透過不同的模型。
完整的 8 步驟工作流程
讓我用上週的真實案例來說明。
步驟 1:客戶需求 → 與 Zoe 進行範圍界定
我與一家代理商客戶通話。他們希望能在團隊中重複使用已經設定好的配置。
通話結束後,我與 Zoe 討論了這個需求。因為我所有的會議記錄都會自動同步到 Obsidian 筆記庫,所以我幾乎不需要額外解釋。我們一起界定了功能範圍——最終決定建立一個範本系統,讓他們可以儲存和編輯現有的配置。
接著 Zoe 做了三件事:
- 增加額度 以立即解除客戶限制——她擁有管理員 API 權限
- 從正式資料庫提取客戶配置——她擁有唯讀正式資料庫存取權(我的 Codex Agent 永遠不會有這個權限),以檢索他們現有的設定,並將其納入提示詞中
- 啟動一個 Codex Agent——附帶包含所有背景的詳細提示詞
步驟 2:啟動 Agent
每個 Agent 都會獲得獨立的工作目錄(隔離分支)和 tmux 會話:
1# 建立工作目錄 + 啟動 Agent2git worktree add ../feat-custom-templates -b feat/custom-templates origin/main3cd ../feat-custom-templates && pnpm install45tmux new-session -d -s "codex-templates" \6 -c "/Users/elvis/Documents/GitHub/medialyst-worktrees/feat-custom-templates" \7 "$HOME/.codex-agent/run-agent.sh templates gpt-5.3-codex high"
Agent 在 tmux 會話中執行,並透過腳本記錄完整的終端機日誌。
以下是我們啟動 Agent 的方式:
1# Codex2codex --model gpt-5.3-codex \3 -c "model_reasoning_effort=high" \4 --dangerously-bypass-approvals-and-sandbox \5 "你的提示詞在這裡"67# Claude Code8claude --model claude-opus-4.5 \9 --dangerously-skip-permissions \10 -p "你的提示詞在這裡"
我過去會使用 codex exec 或 claude -p,但最近改用 tmux:
tmux 好處更大,因為 任務中的重新導向 非常強大。Agent 方向錯誤?不用殺掉它:
1# 錯誤的做法:2tmux send-keys -t codex-templates "停下來。先專注於 API 層,而不是 UI。" Enter34# 需要更多上下文:5tmux send-keys -t codex-templates "結構定義在 src/types/template.ts 裡。使用那個檔案。" Enter
任務會記錄在 .clawdbot/active-tasks.json 中:
1{2 "id": "feat-custom-templates",3 "tmuxSession": "codex-templates",4 "agent": "codex",5 "description": "客戶自訂電子郵件範本",6 "repo": "medialyst",7 "worktree": "feat-custom-templates",8 "branch": "feat/custom-templates",9 "startedAt": 1740268800000,10 "status": "running",11 "notifyOnComplete": true12}
完成後,會更新 PR 編號與檢查狀態。(更多細節請見步驟 5)
1{2 "status": "done",3 "pr": 341,4 "completedAt": 1740275400000,5 "checks": {6 "prCreated": true,7 "ciPassed": true,8 "claudeReviewPassed": true,9 "geminiReviewPassed": true10 },11 "note": "所有檢查皆已通過。準備好合併。"12}
步驟 3:持續監控
一個 cron 工作每 10 分鐘執行一次,負責監管所有 Agent。這基本上就是改良版的 Ralph Loop,稍後會再詳細說明。
但它不會直接輪詢 Agent——這樣成本太高。而是執行一個腳本,讀取 JSON 註冊表並檢查:
1.clawdbot/check-agents.sh
這個腳本 100% 確定性且極度節省 token:
- 檢查 tmux 會話是否存活
- 檢查追蹤分支上是否有開啟的 PR
- 透過
gh cli檢查 CI 狀態 - 若 CI 失敗或有重大審查意見,自動重新啟動失敗的 Agent(最多 3 次)
- 僅在需要人工介入時發出警示
我不用一直盯著終端機。系統會告訴我何時該查看。
步驟 4:Agent 建立 PR
Agent 會提交、推送,並透過 gh pr create --fill 開啟一個 PR。此時我 不會 收到通知——單單 PR 還不算完成。
完成的定義(你的 Agent 必須知道這一點):
- PR 已建立
- 分支已同步到 main(無合併衝突)
- CI 通過(語法檢查、型別檢查、單元測試、E2E)
- Codex 審查通過
- Claude Code 審查通過
- Gemini 審查通過
- 已包含截圖(如果 UI 有變更)
步驟 5:自動化程式碼審查
每個 PR 都會經過三個 AI 模型審查。它們各自能發現不同問題:
- Codex 審查者——在邊界情況上表現出色。進行最徹底的審查。能夠找出邏輯錯誤、遺漏的錯誤處理、競爭條件。誤報率非常低。
- Gemini Code Assist 審查者——免費且非常實用。能夠發現其他 Agent 遺漏的安全性問題、可擴展性問題。並提供具體的修復建議。安裝它完全不用考慮。
- Claude Code 審查者——大多沒什麼用,往往過於謹慎。經常出現「考慮加入...」的建議,通常都是過度設計。除非標記為重大問題,否則我會跳過所有內容。它很少自行發現重大問題,但會驗證其他審查者標記的內容。
三者都會直接在 PR 上發布評論。
步驟 6:自動化測試
我們的 CI 管線執行大量自動化測試:
- 語法檢查和 TypeScript 檢查
- 單元測試
- E2E 測試
- 針對預覽環境(與正式環境相同)的 Playwright 測試
我上週新增了一條規則:如果 PR 變更了任何 UI,必須在 PR 描述中包含截圖。否則 CI 會失敗。這大幅縮短了審查時間——我可以直接看到變更內容,而不必點進預覽環境。
步驟 7:人工審查
這時我會收到 Telegram 通知:「PR #341 準備好審查。」
到這個階段:
- CI 已通過
- 三個 AI 審查者已核准程式碼
- 截圖顯示了 UI 變更
- 所有邊界情況都已記錄在審查意見中
我的審查只需 5-10 分鐘。許多 PR 我甚至不讀程式碼就直接合併——截圖已經告訴我所有需要的資訊。
步驟 8:合併
PR 合併。一個每日 cron 工作會清理孤立的工作目錄和任務註冊表的 JSON。
Ralph Loop V2
這本質上就是 Ralph Loop,但更勝一籌。
Ralph Loop 會從記憶體中提取背景、產出結果、評估成效、儲存學習。但大多數實作每次執行相同的提示詞。提煉出的學習雖然能改善未來的檢索,但提示詞本身保持不變。
我們的系統則不同。當 Agent 失敗時,Zoe 不會只用相同的提示詞重新啟動它。她會帶著完整的業務背景來檢視失敗原因,並找出如何解決問題:
- Agent 的上下文用完了?「只專注在這三個檔案上。」
- Agent 方向錯了?「停下來。客戶要的是 X,不是 Y。這是他們在會議中說的。」
- Agent 需要釐清?「這是客戶的電子郵件,以及他們公司是做什麼的。」
Zoe 會一路監管 Agent 直到任務完成。她擁有 Agent 所沒有的背景——客戶歷史、會議記錄、我們先前嘗試過的方法、以及失敗原因。她運用這些背景在每次重試時寫出更好的提示詞。
但她也不會等我指派任務。她會主動尋找工作:
- 早上: 掃描 Sentry → 發現 4 個新錯誤 → 啟動 4 個 Agent 進行調查和修復
- 會議後: 掃描會議記錄 → 標記出客戶提到的 3 個功能需求 → 啟動 3 個 Codex Agent
- 晚上: 掃描 Git 記錄 → 啟動 Claude Code 來更新變更日誌和客戶文件
我可以在客戶電話後出門散個步。回來就看到 Telegram 訊息:「7 個 PR 準備好審查。3 個新功能,4 個錯誤修復。」
當 Agent 成功時,模式會被記錄下來。「這個提示詞結構對帳單功能有效。」「Codex 需要先知道型別定義。」「一定要包含測試檔案路徑。」
獎勵訊號是:CI 通過、三個程式碼審查通過、人工合併。任何失敗都會觸發循環。隨著時間推移,Zoe 能寫出更好的提示詞,因為她記得哪些東西實際上線了。
選擇正確的 Agent
並非所有編碼 Agent 都一樣。快速參考:
Codex 是我的主力工具。後端邏輯、複雜錯誤、多檔案重構,以及任何需要跨程式碼庫推理的工作。它較慢但徹底。我 90% 的任務都用它。
Claude Code 速度更快,在前端工作上表現更佳。它的權限問題也較少,因此非常適合 Git 操作。(我以前多用它來驅動日常工作,但 Codex 5.3 現在更好也更快了)
Gemini 有另一項超能力——設計敏銳度。對於美觀的 UI,我會先讓 Gemini 產生 HTML/CSS 規格,然後交給 Claude Code 在我們的元件系統中實作。Gemini 設計,Claude 建造。
Zoe 會為每個任務挑選合適的 Agent,並在它們之間傳遞輸出結果。帳單系統的錯誤交給 Codex。按鈕樣式的修正交給 Claude Code。新的儀表板設計則從 Gemini 開始。
如何設定
將整篇文章複製到 OpenClaw,然後告訴它:「在我的程式碼庫中實作這個 Agent 群集設定。」
它會讀取架構、建立腳本、設定目錄結構,並配置 cron 監控。10 分鐘內完成。
沒有課程要賣給你。
沒有人預料到的瓶頸
這是我目前遇到的極限:RAM。
每個 Agent 需要自己的工作目錄。每個工作目錄需要自己的 node_modules。每個 Agent 會執行建置、型別檢查、測試。五個 Agent 同時執行意味著五個並行的 TypeScript 編譯器、五個測試執行器、五組載入記憶體的相依套件。
我的 Mac Mini 只有 16GB,最多只能同時執行 4-5 個 Agent 就會開始使用交換記憶體——而且還得祈禱它們不會同時進行建置。
所以我買了一台 Mac Studio M4 max,配備 128GB RAM($3,500 美元)來驅動這個系統。預計三月底到貨,到時我會分享是否值得。
下一步:一人百萬美元公司
我們將從 2026 年開始看到大量一人百萬美元公司。對於那些懂得如何建立遞迴自我改進 Agent 的人來說,槓桿效應巨大。
這就是它的樣貌:一個 AI 編排器作為你自己的延伸(就像 Zoe 之於我),將工作委派給處理不同業務功能的專業 Agent。工程、客戶支援、營運、行銷。每個 Agent 專注於自己擅長的事。你則保持高度專注和完全掌控。
下一代創業者不會為了做到一個人搭配正確系統就能完成的事而雇用 10 人團隊。他們會像這樣打造——保持小規模、快速行動、每日交付。
現在市面上有太多 AI 生成的垃圾內容。太多關於 Agent 和「任務控制中心」的炒作,卻沒有建構任何實際有用的東西。華麗的展示,卻沒有實際效益。
我試著做相反的事:少一點炒作,多一點建立真實業務的記錄。真實的客戶、真實的收入、真實的上線 commit,也有真實的損失。
我正在打造什麼?Agentic PR——一人公司,挑戰企業公關領域的既有業者。Agent 幫助新創公司獲得媒體報導,而不需要每月 $10,000 美元的顧問費。
如果你想看看我能把這件事做到什麼程度,歡迎繼續關注。





