我的 OpenClaw 養蝦記：3 個 Agent 跑通 100% 自動化閉環

作者：Just Jason
日期：2026年2月26日 上午11:35
來源：WeChat 原文

✦整理版優先睇

速讀 5 個重點 高亮

用 OpenClaw 搭 3 個 Agent，跑通 100% 自動化閉環，一人團隊不再係口號

整理版摘要

作者 Jason 係一個獨立開發者，平時要兼顧產品開發、寫文案同埋客戶溝通。佢受 Elvis 嘅 Agent Swarm 方法論啟發，喺自己部 Mac 上用 OpenClaw 搭咗 3 個 Agent——編排器、編碼助手 Winnie、文案助手 Amy——成功實現由任務派發到交付審核嘅全自動化閉環。佢發現關鍵突破唔係「Agent 識得寫代碼」，而係監控腳本加自動重試加 Telegram 通知構成咗一條零人工幹預嘅生產線，就算佢唔喺電腦前面，Agent 都會繼續開工。

呢篇文章詳細記錄咗佢嘅實戰經驗，包括 3 隻蝦嘅分工配置、100% 自動化閉環嘅運作機制（派發、執行、巡檢、狀態流轉）、喺真實項目 Voice Real-time Translation 上嘅效率提升數據、技術架構用蝦塘比喻拆解、月成本約 $50-80（參考 Elvis 約 $190），仲有佢踩過嘅 4 個大坑。佢強調「養蝦」嘅本質係維護一個可持續運轉嘅生態，而唔係追求單次調用嘅驚豔。

總結嚟講，一個人加 AI Agent Swarm 就等於一個團隊，但前提係要花時間「養」好呢個生態——分層上下文、專業化分工、賬號隔離、零 Token 監控、遞歸改進同人在迴路，呢 6 條原則係成功嘅基石。

  • 3 個 Agent（編排器 + Winnie + Amy）可以跑通由任務派發到 PR 提交嘅全自動閉環，人只需做最後 5-10 分鐘嘅決策同審查。
  • 關鍵方法係用 OpenClaw 做編排層，每個 Agent 喺獨立 tmux session 同 worktree 執行，配合 check-agents.sh 零 Token 巡檢同自動重試。
  • 同直接使用 Codex 或 Claude Code 最大嘅差異係分層上下文：編排器持有業務全局，Agent 專注執行，避免上下文窗口被填滿。
  • 實戰中 Voice Real-time Translation 項目嘅開發效率由 2-3 日一個功能提升到 2-4 小時，可以並行處理 3-5 個任務。
  • 想複製呢套做法，首先要搭建基礎設施（OpenClaw + tmux + git worktrees），再按專業配置 Agent（Winnie 編碼、Amy 文案），最後完善巡檢同賬號隔離機制。
值得記低
連結 docs.openclaw.ai

OpenClaw 官方文檔

Agent 編排平台嘅完整安裝同配置教學。

開啟
連結 x.com

Elvis 嘅 Agent Swarm 方法論原文

Elvis 喺 Twitter 分享嘅 Agent Swarm 完整方法論，包括 8 步工作流同成本數據。

開啟
連結 openai.com

OpenAI Codex 官方文檔

Codex API 嘅使用指南同限額說明。

開啟
連結 docs.anthropic.com

Anthropic Claude API 文檔

Claude Sonnet 4-5 等模型嘅 API 參考。

開啟
結構示例

結構示例

結構示例 text 
# 派 Winnie 修 Bug~/.openclaw/swarm/spawn-agent.sh winnie fix-auth-bug \  "Fix the login validation bug in auth.ts"# 派 Amy 寫文案~/.openclaw/swarm/spawn-agent.sh amy blog-launch \  "寫一篇產品發佈博客，目標讀者：開發者"
整理重點

一場需求評審會後嘅驚喜

作者開咗兩個半鐘頭需求評審會，返到 Mac 前面發現 Telegram 刷咗一屏——唔係羣組吹水，而係佢兩隻「蝦」Winnie 同 Amy 自動彙報工作進度：Winnie 修好咗 Voice Real-time Translation 嘅 bug 並提咗 PR，Amy 出咗微信公眾號文案初稿。佢用 15 分鐘就搞掂 review 同發佈。

呢件事嘅起點係作者讀到 Elvis（@elvissun）嘅一篇深度分享——Elvis 透過 OpenClaw 做編排層，由 AI 助手統一調度多個編碼 Agent，稱之為 Agent Swarm。Elvis 嘅公開數據令人坐唔住：單日最高 commit 94 次，30 分鐘內完成 7 個 PR，月成本約 $190。

上下文窗口係零和遊戲

Elvis 嘅核心觀點係：填滿代碼就冇空間放業務上下文，填滿客戶歷史就冇空間放代碼。解決方案唔係揾更大嘅窗口，而係分層——編排層持有業務全局，編碼層專注執行。呢個方向同作者之前提出嘅「Architect/Coder/QA 三角色協同」一樣，只不過 Elvis 已經喺生產環境跑通咗。

整理重點

我嘅 3 隻蝦：邊個做咩

作者將搭 Agent Swarm 比喻為養蝦：搭好蝦塘（基礎設施）、放蝦苗（配置 Agent）、投飼料（派任務）、巡塘（監控腳本）、收蝦（收 PR 同內容）。核心唔係某一次操作嘅精彩，而係維護一個可持續運轉嘅生態。

  • 編排器（Main Orchestrator）——塘主：接收意圖、拆解任務、決定派俾邊個，仲可以讓 Agent 之間協作，例如 Winnie 做完功能後自動叫 Amy 寫更新日誌。
  • Winnie（coding-assistant）——編碼蝦：人設係「先結論後步驟，優先可執行方案，唔做大規模重構」。用 openai-codex/gpt-5.3-codex 模型，擅長後端邏輯、全棧開發、重構、Bug 修復同測試。
  • Amy（copywriting-assistant）——文案蝦：人設係「輸出可直接發佈，擅長新媒體文案，A/B 兩版，避免空話」。主力模型同 Winnie，fallback 用 claude-sonnet-4-5，擅長中英雙語、短視頻、SEO、小紅書、微信、Twitter。

專業化分工比通用 Agent 更有效

三者分工明確：Bug 修復、新功能開發、代碼重構、API 文檔交俾 Winnie；博客文章、社交媒體、用戶指南交俾 Amy。關鍵係先將「可標準化派發」嘅任務跑通，再逐步擴展。

整理重點

100% 自動化閉環點樣跑通

呢個係文章嘅核心部分，分為派發、執行、巡檢同狀態機四個環節。

  1. 1 派發：可以透過 CLI 腳本（spawn-agent.sh）或者 Telegram Bot 消息觸發，系統會寫入 active-tasks.json、創建獨立 tmux session、啓動 Agent 並記錄日誌。
  2. 2 執行：Agent 喺自己嘅 tmux session 入面讀取任務、拉取代碼到獨立 worktree、自主編碼或寫作、運行測試，完成後自動 gh pr create --fill。
  3. 3 巡檢：check-agents.sh 係 100% 確定性 Shell 腳本，零 LLM token 消耗，每 10 分鐘 cron 運行一次，檢查 session 存活、PR 狀態、CI 結果，自動重試最多 3 次。
  4. 4 狀態機：任務狀態可追蹤，例如 running → done、running → blocked、running → ci-failed → respawning → running，只有最後 review 需要人工介入。

整條鏈路唯一需要人嘅環節係最後 5-10 分鐘嘅 review。其餘全部自動化。呢個就係「100% 自動化閉環」嘅含義——人只做決策，唔做執行。

整理重點

實戰驗證：Voice Real-time Translation

作者用呢套 Swarm 實際管理嘅項目之一係 Voice Translation（macOS 實時語音翻譯器），解決 Teams 標準版有字幕冇翻譯嘅痛點。項目由 2025 年 8 月開始，已經穩定運行半年。

效率從 2-3 日一個功能提升到 2-4 小時

引入 Swarm 後工作方式發生質變：早期作者自己寫代碼，一個功能要 2-3 日；重構後 Winnie 寫代碼，作者做 review，一個功能 2-4 小時；Swarm 接入後可以並行處理 3-5 個任務。

真人案例：作者開需求評審會期間，喺 Telegram 叫 Winnie 修復藍牙設備切換時嘅音頻丟幀問題。兩個半鐘頭後會議結束，Winnie 已經提咗 PR 並附上通過嘅測試用例。與此同時，Amy 喺另一個 session 完成咗一篇微信公眾號文案初稿。一個下午，兩個交付，人工介入總共 15 分鐘。

整理重點

蝦塘技術架構同成本

  • 基礎設施：OpenClaw 2026.2.25 做框架，tmux sessions 做隔離，git worktrees 提供獨立代碼副本，Telegram Bots 做通訊，SQLite + Gemini Embedding 做記憶庫。
  • 模型配置：Winnie 同 Amy 主力用 openai-codex/gpt-5.3-codex，Amy fallback 用 claude-sonnet-4-5，記憶用 gemini-embedding-001。兩個 Codex 賬號輪換避免限額觸頂。
  • 監控工具鏈：active-tasks.json 做任務註冊表，check-agents.sh 每 10 分鐘 cron 巡檢，logs/ 目錄記錄全部輸出。
  • 賬號隔離：作者本地開發用一個賬號，Agent 用另外兩個賬號，避免爭奪限額。自建代理統一管理 API 調用。

Token 消耗遠超人類手動使用，必須賬號隔離

成本方面，Elvis 公開月費約 $190（Claude $100 + Codex $90），作者現階段每月 $50-80，因為任務密度冇咁高。但重點係產出比——一個初級開發者月薪遠超 $190，而呢兩隻蝦 7×24 在線，冇社保、唔請假、唔需要管理。硬件方面，RAM 係瓶頸，16GB Mac 可支持 4-5 個併發 Agent，128GB Mac Studio M4 Max 先係 Elvis 推薦配置。

  1. 1 網絡代理幹擾：本地 Stash 代理劫持 DNS，要 bypass *.argotunnel.com 或強制 HTTP2。
  2. 2 Codex Device Auth 失敗：用 https_proxy="" codex login --device-auth 繞過代理。
  3. 3 Token 過期：Codex OAuth token 約 10 日有效，需 check-agents.sh 加入 token 檢查並定期刷新備份。
  4. 4 新舊版本共存：統一用 ~/.openclaw/，清乾淨舊版 ~/.clawdbot/ 避免端口衝突。

最後作者總結咗 6 條核心理念：分層上下文、專業化分工、賬號隔離、零 Token 監控、遞歸改進、人在迴路。佢強調 Agent 做 80% 執行，人做 20% 決策，完全無人介入唔係目標，高效協作先係。

尋日下午，我開咗兩個半鐘嘅需求評審會。

等我返到 Mac 前面，發現 Telegram 已經刷咗一版 message——唔係 group 吹水，而係我兩隻「蝦」喺度匯報工作進度：Winnie 話 Voice Real-time Translation 有個 bug 已經修好咗仲提咗 PR；Amy 話微信公眾號嘅文案初稿已生成，等我過目。

我衝咗杯咖啡，用咗 10 分鐘 review Winnie 嘅 PR，再用 5 分鐘執咗 Amy 啲措辭，merge、publish，搞掂。

一句講曬：當你用到 3 個 Agent 跑通由派 task 到交貨審核嘅完整閉環時，「一人團隊」就唔再係口號，而係每日都在發生嘅事。

圖片

如果你得 30 秒，先睇呢 3 句：

  1. 1. 我用 OpenClaw 喺本地 Mac 上起咗 3 個 Agent（orchestrator + coding 助手 Winnie + copywriting 助手 Amy），佢哋可以自主接收任務、執行工作、提交 PR、互相協作。
  2. 2. 關鍵突破唔係「Agent 識寫 code」，而係監控 script + 自動 retry + Telegram 通知構成咗一條零人手幹預嘅閉環——我唔喺電腦前面，佢哋都仲喺度做嘢。
  3. 3. 每個月成本大約 $190，等於請咗一個 7×24 嘅兩人小團隊。但前提係：你要花時間「養」好呢個生態。

件事嘅起點，係我喺 Twitter 上讀到 Elvis（@elvissun）嘅一篇深度分享。

Elvis 唔再直接用 Codex 或者 Claude Code 寫 code，而係用 OpenClaw 作為編排層，由 AI 助手統一調度多個 coding Agent。佢叫呢套系統做 Agent Swarm。佢公開嘅數據令我坐唔住：

指標
數據
單日最高 commit
94 次（平均每日大約 50 次）
30 分鐘內完成
7 個 PR
同一日開客戶會議
3 個（全程冇開過 editor）
月成本
Claude $100 + Codex $90 ≈ $190

佢嘅 8 步 workflow 涵蓋咗由客戶需求到 merge 上線嘅完整週期：需求收集 → orchestrator 確定範圍 → 生成 Agent（獨立 worktree + tmux session） → cron 循環監控（零 token） → Agent 開 PR → 三路 AI Code Review（Codex + Gemini + Claude） → 自動化測試 → 人手審核查 merge。

但真正令我決定動手嘅，係佢提出嘅一個核心觀點：

Context window 係零和嘅。塞滿 code，就冇位放業務 context；塞滿客戶歷史，就冇位放 code。解決方法唔係揀更大嘅 window，而係分層——編排層 hold 住業務全局，編碼層專注執行。

呢個同我之前喺《開工第一日你一定要睇明嘅 AI Coding 新秩序》入面寫嘅「Architect/Coder/QA 三角色協作」係同一個方向——只不過 Elvis 已經喺 production 環境跑通咗。

圖片

二、我嘅 3 隻蝦：邊個係邊個，做咩嘢

「養蝦」呢個比喻唔係我發明嘅，但的確好貼切。

起 Agent Swarm 嘅過程就好似養蝦：整好蝦塘（基礎設施）、放蝦苗（配置 Agent）、俾飼料（派 task）、巡塘（監控 script）、收蝦（收 PR 同內容）。核心唔係某次操作有幾精彩，而係 maintain 一個可持續運作嘅生態。

我而家個蝦塘有 3 隻蝦：

2.1 Orchestrator（Main Orchestrator）——塘主

佢係成個 Swarm 嘅中樞，負責接收我嘅意圖、拆解任務、決定派俾邊個。

更重要嘅係，佢可以令 Agent 之間協作：例如 Winnie 做完一個新功能之後，orchestrator 可以自動叫 Amy 寫更新日誌同發佈文案——成條鏈路唔需要我手動駁。

2.2 Winnie（coding-assistant）——編碼蝦

佢嘅人設係「先講結論再講步驟，優先揀可行方案，唔做大規模重構」。

配置項
詳情
Agent ID
coding-assistant
工作空間
~/.openclaw/agents/coding-assistant/workspace
模型
openai-codex/gpt-5.3-codex
通知通道
Telegram Bot: justjason5788
擅長
後端邏輯、全棧開發、重構、Bug 修復、測試

2.3 Amy（copywriting-assistant）——文案蝦

佢嘅人設係「輸出可以直接出街，擅長新媒體文案，A/B 兩個版本，避免廢話」。

配置項
詳情
Agent ID
copywriting-assistant
工作空間
~/.openclaw/agents/copywriting-assistant/workspace
模型
openai-codex/gpt-5.3-codex（fallback: claude-sonnet-4-5）
通知通道
Telegram Bot: jasonwenanbot
擅長
中英雙語、短片/新媒體、SEO、小紅書/微信/Twitter

三者之間嘅分工邏輯好明確：

任務類型
指派 Agent
原因
Bug 修復
Winnie
理解 code + 精準修復
新功能開發
Winnie
完整實作週期
代碼重構
Winnie
跨檔案改動能力強
博客文章
Amy
SEO 優化 + 吸引力
社交媒體
Amy
平台原生風格
API 文檔
Winnie
技術準確性優先
用戶指南
Amy
可讀性優先

唔係所有任務都適合自動化。關鍵係先將「可以標準化派發」嘅任務跑通，再逐步擴展。

三、100% 自動化閉環：到底點樣跑通

呢篇文嘅核心。我先畫一張全景圖，再逐步拆解每個環節。

圖片

3.1 派發：一個 message 觸發一個 Agent

派發有兩種方式。

方式一：CLI 派發（適合批量或 script 觸發）

# 派 Winnie 修 Bug
~/.openclaw/swarm/spawn-agent.sh winnie fix-auth-bug \
  "Fix the login validation bug in auth.ts"

# 派 Amy 寫文案
~/.openclaw/swarm/spawn-agent.sh amy blog-launch \
  "寫一篇產品發佈博客，目標讀者：開發者"

方式二：Telegram message 派發（適合隨時隨地）

喺 Telegram 度 send message 俾對應嘅 Bot，orchestrator 會自動 routing。呢個亦係我最常用嘅方式——開會空隙、地鐵上、湊仔時，拎出電話 send 一個 message 就得。

每次派發，系統內部會做 4 樣嘢：

  1. 1. 寫入 active-tasks.json（task registry）
  2. 2. 創建獨立 tmux session（互不幹擾）
  3. 3. 通過 openclaw agent --agent <id> --message '<prompt>' --local 啟動 Agent
  4. 4. 日誌輸出到 ~/.openclaw/swarm/logs/<session>.log

3.2 執行：Agent 喺 tmux 入面自主工作

呢個係最關鍵嘅一步，亦係「養蝦」同「用工具」嘅本質分別。

Agent 啟動後，喺自己嘅 tmux session 入面獨立運行：

  • • 讀取 task context 同相關記憶
  • • 拉 code 到獨立 worktree（唔影響主 branch）
  • • 自主編碼或寫作
  • • 自主跑 test
  • • 完成後自動 gh pr create --fill

成個過程唔使我睇住個 mon。我可以去開會、煮飯、湊仔——佢哋喺 background 不停做。呢個就係由「操作工具」到「管理團隊」嘅躍進。

3.3 巡檢：零 Token 嘅確定性監控

好多人會問：你點知 Agent 做曬未？做啱唔啱？卡住咗點算？

答案是 check-agents.sh——一個 100% 確定性嘅 Shell script，零 LLM token 消耗。

佢嘅邏輯好簡單（正因為簡單，所以穩定）：

  1. 1. 讀取 active-tasks.json 入面所有活躍 task
  2. 2. 逐一檢查 tmux session 仲喺唔喺度
  3. 3. 通過 gh pr list 檢查 PR 同 CI status
  4. 4. 自動標記失敗 task，觸發 retry
  5. 5. 超過 3 次 retry 就標記為 failed 並 send alert
  6. 6. 淨係需要人手介入先 send notification

配合 cron 每 10 分鐘 run 一次，呢套巡檢就好似蝦塘裏面嘅自動增氧機——你唔使 24 小時睇住，但佢一直喺度運作。

3.4 狀態機：由 running 到 review-ready

Task 嘅狀態流轉係可以追蹤嘅：

running → done (成功完成)
running → blocked (需要人工輸入)
running → ci-failed → respawning → running (自動重試)
running → session-dead → respawning (tmux 掛了，自動恢復)
running → failed (超過 3 次重試，人工介入)
done → review-ready (CI + review 全過)

成條鏈路入面，唯一需要人嘅環節係最後 5-10 分鐘嘅 review。其餘全部自動化。呢個就係「100% 自動化閉環」嘅意思——唔係「零人手」，而係「人淨係做決策，唔做執行」。

四、實戰驗證：Voice Real-time Translation 項目

齋講架構冇用，要用真實項目驗證。

我用呢套 Swarm 實際有份管理嘅項目之一，就係之前文章寫過嘅 Voice Real-time Translation（macOS app 叫 VoiceTranslation）——一個專門解決 Teams 標準版「有字幕冇翻譯」呢個痛點嘅 macOS 實時語音翻譯器。

呢個項目由 2025 年 8 月 11 日第一次 commit，到而家已經穩定運行咗半年，經歷過兩次關鍵重構（API Provider 管理重構 + 權限處理同音頻質素監控重構）。引入 Agent Swarm 之後，工作方式有咗質嘅變化：

階段
工作方式
典型效率
早期（2025.08-2025.12）
我自己寫 code，間中先用 Claude 輔助
一個功能 2-3 日
重構後（2026.01-2026.02）
Winnie 寫 code，我做 review
一個功能 2-4 個鐘
Swarm 接入後（2026.02.25 起）
派 task 之後去開會，返嚟 review
並行處理 3-5 個 task

上星期嘅一個真實 case：

我喺開需求評審會，順手喺 Telegram send 咗一個 message 俾 Winnie：

「VoiceTranslation 嘅 Core Audio Tap 喺藍牙裝置切換時偶爾會 drop frame，check 嚇 AudioStreamBasicDescription 嘅採樣率同步 logic，修復之後跑 unit test。」

兩個半鐘之後會議結束，Winnie 已經開咗 PR，附帶咗修復 code 同通過咗嘅 test case。我 review 咗 5 分鐘，merge。

同一時間，Amy 喺另一個 tmux session 入面完成咗一篇微信公眾號文案嘅初稿。我改咗幾處措辭，都 publish 咗。

一個下晝，兩個 delivery，人手介入總共 15 分鐘。

圖片

五、蝦塘嘅水電同增氧：技術架構全解

為咗令冇咁技術嘅讀者都明，我用「蝦塘」嘅比喻來對照每一層 component。

5.1 蝦塘本體（基礎設施）

組件
蝦塘比喻
實際作用
OpenClaw 2026.2.25
蝦塘整體框架
Agent 編排平台，統一調度所有 Agent
tmux sessions
養殖池隔板
每個 Agent 獨立運行空間，互不幹擾
git worktrees
獨立餵食區
每個 Agent 有自己嘅 code copy
Telegram Bots
對講機
人同 Agent 嘅實時通訊通道
SQLite + Gemini Embedding
蝦嘅記憶
每個 Agent 獨立記憶庫，累積經驗

5.2 飼料（模型配置）

模型
用途
選擇理由
openai-codex/gpt-5.3-codex
Winnie + Amy 主力
Codex 喺 coding task 上完成度最高
anthropic/claude-sonnet-4-5
Amy 嘅 fallback
中文內容質素更佳
gemini-embedding-001
記憶系統向量搜索
Embedding 質素同成本平衡

兩個 Codex 帳號輪住用，避免單一帳號限額爆煲：

"order": {
  "openai-codex": [
    "openai-codex:second",
    "openai-codex:default",
    "anthropic:manual"
  ]
}

5.3 增氧系統（監控工具鏈）

文件
作用
運行方式
active-tasks.json
Task registry，追蹤所有 Agent 狀態
實時更新
spawn-agent.sh
一鍵派發 script
按需調用
check-agents.sh
零 token 巡檢 script
cron 每 10 分鐘
logs/
 目錄
每個 session 嘅完整輸出 log
持續寫入

5.4 帳號隔離策略

呢個係好易忽略但極之重要嘅細節：

賬號
用途
隔離原因
k******g@gmail.com
淨係用本地 macOS Codex CLI
我日常開發用，唔參與 Agent
j********g@gmail.com
OpenClaw Agent 主帳號
Agent session 獨立消耗
w********2@gmail.com
OpenClaw Agent 後備
限額輪換，避免爆上限

點解要隔離？因為 Agent 嘅 token 消耗量遠超人類手動使用。如果共用一個帳號，Agent 用爆限額之後我自己就用唔到了。

5.5 自建 proxy：成本控制嘅隱藏關鍵

我嘅 Anthropic 同 Gemini API 唔係直接 call 官方 endpoint，而係經自建 proxy 訪問（BaseURL: https://cc.junxinzhang.com）。好處係：統一管理所有 API call 嘅 log、實時監控成本、有異常時可以快速切換。

六、成本帳：養蝦到底要幾多錢

6.1 參考數據：Elvis 嘅公開成本

項目
月費
Claude API
~$100
Codex API
~$90
合計~$190/月

6.2 我嘅實際成本

我而家仲喺測試同 tune 嘅階段，task 密度冇 Elvis 嗰種「日均 50 commit」嘅 level。目前月成本大約 $50-80。

但核心唔係「用幾多錢」，而係產出比。一個初級 developer 嘅月薪遠遠超過 $190。而呢兩隻蝦 7×24 在線，冇社保、唔請假、唔使 management。當然，佢哋唔會主動提出需求——呢個就係「人在 loop」嘅價值所在。

6.3 硬件限制

配置
並行 Agent 上限
體驗
16GB Mac
4-5 個
夠用，但接近上限會 lag
128GB Mac Studio M4 Max
充分並行
Elvis 推薦配置

瓶頸係 RAM，唔係 CPU。每個 Agent 嘅 tmux session + worktree + model context 都會食 RAM。

七、踩過嘅坑（幫你慳返啲冤枉路）

唔講踩坑記錄嘅文章係唔完整嘅。以下係我搭建過程中最痛嘅幾個：

7.1 網絡 proxy 幹擾 Cloudflare Tunnel

問題：cloudflared 不停報錯「there are no free edge addresses left to resolve to」，QUIC timeout 不斷。

根因：本地 Stash proxy（port 7890）hijack 咗 DNS，將 Cloudflare edge 解析到假 IP 198.18.0.x。QUIC 用 UDP，proxy 冇辦法正確 forwarding。

解法：喺 Stash config 入面 bypass *.argotunnel.com；或者喺 cloudflared 加 --protocol http2 強制 TCP。

教訓：本地有行 proxy 嘅朋友要特別注意——任何需要 UDP/QUIC 嘅服務都可能俾 proxy 幹擾。

7.2 Codex Device Auth 喺 proxy 環境下失敗

問題：執行 codex login --device-auth 點都做唔完 authentication 流程。

解法：https_proxy="" codex login --device-auth，繞過 proxy 就掂。Business workspace 仲要 admin enable 咗 device code auth 先得。

7.3 Token 過期令 Agent 靜默失敗

問題：Codex OAuth token 有效期大約 10 日。過期之後 Agent 唔會報錯，只會靜靜雞停咗——呢個係最陰濕嘅 bug，因為你以為蝦仲做緊嘢，其實已經罷咗工。

解法：喺 check-agents.sh 入面加 token 有效性檢查。定期 refresh token 並 sync 去 OpenClaw。Backup 機制：~/.codex/auth.json.kiyo.bak。

7.4 新舊版本共存搞到 CLI 衝突

問題：本地同時有 ~/.clawdbot/（舊版 Clawdbot 2026.1.24-3）同 ~/.openclaw/（新版 OpenClaw 2026.2.25），兩套 CLI、兩套 Memory DB、兩個 Gateway port，互相干擾。

解法：統一以 ~/.openclaw/ 為準，唔再用舊版。記住要清乾淨，如果唔係 background process 可能霸住 port。

八、由「用工具」到「養生態」：6 條核心理念

圖片

總結呢段實踐，我提煉咗 6 條核心原則：

  1. 1. 分層 context：Orchestrator hold 住業務全局，Agent 專注執行。唔好俾一個 Agent 又識業務又寫 code——咁會好快食曬 context window。
  2. 2. 專業化分工：Winnie 寫 code，Amy 寫文案，各有各做。撈亂用一個通用 Agent 做曬所有嘢，效果遠差過專業化配置。
  3. 3. 帳號隔離：我本地開發用一個帳號，Agent 跑 task 用另外嘅帳號，互不幹擾、互不搶限額。
  4. 4. 零 Token 監控：確定性 script 巡檢，淨係需要時先消耗 API。監控本身唔應該係 LLM task——呢個係好多人容易犯嘅錯。
  5. 5. 遞迴改進：成功嘅 prompt pattern 記錄入 memory，失敗嘅都記錄原因同修復方案。每一次執行都係為下一次累積經驗。
  6. 6. 人在 loop：Agent 做 80% 嘅執行工作，人做 20% 嘅決策同審查。完全無人介入唔係目標，高效協作先係。

寫在最後

「養蝦」唔係一個精確嘅技術詞，但佢捉到一個本質：

AI Agent 嘅價值唔係在於單次 call 有幾驚豔，而在於持續運作嘅生態。

整好蝦塘、揀好蝦苗、配好飼料、裝好增氧機——然後你可以去做更重要嘅事：諗業務方向、同客戶對齊需求、做技術決策。嗰啲可以標準化拆解同重複執行嘅工作，交俾蝦去做。

我而家個 Swarm 仲喺早期階段，接下來會繼續推幾樣嘢：

  • • 設定 cron 定時 run check-agents.sh
  • • 測試 Winnie → Amy 嘅跨 Agent 自動協作鏈路
  • • 引入三路 AI Code Review（Codex + Gemini + Claude）
  • • 擴展更多 Agent 角色：SEO 專家、數據分析
  • • 持續累積 memory，令每隻蝦越養越聰明

如果你都喺度研究 Agent Swarm，或者對 OpenClaw 有實戰經驗，歡迎交流。

一個人 + AI Agent Swarm = 一個團隊。呢個唔再係願景，而係每日都在發生嘅事。

相關閲讀

OpenClaw 系列

AI 工程系列

參考資料（官網/官方）

  1. 1. OpenClaw 官方文檔
    https://docs.openclaw.ai/
  2. 2. Elvis（@elvissun）：Agent Swarm 方法論原文
    https://x.com/elvissun/article/2025920521871716562
  3. 3. OpenAI Codex 官方文檔
    https://openai.com/codex
  4. 4. Anthropic Claude API 文檔
    https://docs.anthropic.com/
  5. 5. Google Gemini Embedding API
    https://ai.google.dev/gemini-api/docs/embeddings
  6. 6. Apple WWDC24 - Core Audio Taps（VoiceTranslation 項目參考）
    https://developer.apple.com/videos/play/wwdc2024/10153/

昨天下午，我開了兩個半小時的需求評審會。

等我回到 Mac 前面，發現 Telegram 已經刷了一屏消息——不是羣聊灌水，而是我的兩隻"蝦"在彙報工作進度：Winnie 說 Voice Real-time Translation 的一個 bug 已修復並提了 PR；Amy 說微信公眾號的文案初稿已生成，等我過目。

我泡了杯咖啡，花了 10 分鐘 review 了 Winnie 的 PR，又花 5 分鐘調了 Amy 的措辭，合併、發佈，完事。

一句話結論：當你能用 3 個 Agent 跑通從任務派發到交付審核的完整閉環時，"一人團隊"就不再是口號，而是每天在發生的事。

圖片

如果你只有 30 秒，先看這 3 句：

  1. 1. 我用 OpenClaw 在本地 Mac 上搭了 3 個 Agent（編排器 + 編碼助手 Winnie + 文案助手 Amy），它們能自主接收任務、執行工作、提交 PR、互相協作。
  2. 2. 關鍵突破不是"Agent 能寫代碼"，而是監控腳本 + 自動重試 + Telegram 通知構成了一條零人工干預的閉環——我不在電腦前，它們也在幹活。
  3. 3. 月成本約 $190，相當於僱了一個 7×24 小時的兩人小團隊。但前提是：你得花時間"養"好這個生態。

這件事的起點，是我在推特上讀到了 Elvis（@elvissun）的一篇深度分享。

Elvis 不再直接使用 Codex 或 Claude Code 寫代碼，而是通過 OpenClaw 作為編排層，由 AI 助手統一調度多個編碼 Agent。他管這套體系叫 Agent Swarm。他的公開數據讓我坐不住了：

指標
數據
單日最高 commit
94 次（平均每天約 50 次）
30 分鐘內完成
7 個 PR
當天開客戶會議
3 個（全程沒打開編輯器）
月成本
Claude $100 + Codex $90 ≈ $190

他的 8 步工作流覆蓋了從客戶需求到合併上線的完整週期：需求收集 → 編排器確定範圍 → 生成 Agent（獨立 worktree + tmux session） → cron 循環監控（零 token） → Agent 創建 PR → 三路 AI Code Review（Codex + Gemini + Claude） → 自動化測試 → 人工審查合併。

但真正讓我決定動手的，是他提出的一個核心觀點：

上下文窗口是零和的。填滿代碼，就沒空間放業務上下文；填滿客戶歷史，就沒空間放代碼。解決方案不是找更大的窗口，而是分層——編排層持有業務全局，編碼層專注執行。

這和我之前在《開工第一天你必須看懂的 AI Coding 新秩序》裏寫的"Architect/Coder/QA 三角色協同"是同一個方向——只不過 Elvis 已經在生產環境跑通了。

圖片

二、我的 3 只蝦：誰是誰，幹什麼

"養蝦"這個比喻不是我發明的，但確實很貼切。

搭 Agent Swarm 的過程就像養蝦：搭好蝦塘（基礎設施）、放蝦苗（配置 Agent）、投飼料（派任務）、巡塘（監控腳本）、收蝦（收 PR 和內容）。核心不在某一次操作的精彩，而是維護一個可持續運轉的生態。

我目前的蝦塘裏有 3 只蝦：

2.1 編排器（Main Orchestrator）——塘主

它是整個 Swarm 的中樞，負責接收我的意圖、拆解任務、決定派給誰。

更關鍵的是，它能讓 Agent 之間協作：比如 Winnie 做完一個新功能後，編排器可以自動讓 Amy 寫更新日誌和發佈文案——整條鏈路不需要我手動銜接。

2.2 Winnie（coding-assistant）——編碼蝦

它的人設是"先結論後步驟，優先可執行方案，不做大規模重構"。

配置項
詳情
AgentID
coding-assistant
工作空間
~/.openclaw/agents/coding-assistant/workspace
模型
openai-codex/gpt-5.3-codex
通知通道
Telegram Bot: justjason5788
擅長
後端邏輯、全棧開發、重構、Bug 修復、測試

2.3 Amy（copywriting-assistant）——文案蝦

它的人設是"輸出可直接發佈，擅長新媒體文案，A/B 兩版，避免空話"。

配置項
詳情
AgentID
copywriting-assistant
工作空間
~/.openclaw/agents/copywriting-assistant/workspace
模型
openai-codex/gpt-5.3-codex（fallback: claude-sonnet-4-5）
通知通道
Telegram Bot: jasonwenanbot
擅長
中英雙語、短視頻/新媒體、SEO、小紅書/微信/Twitter

三者之間的分工邏輯很明確：

任務類型
指派 Agent
原因
Bug 修復
Winnie
代碼理解 + 精準修復
新功能開發
Winnie
完整實現週期
代碼重構
Winnie
跨文件變更能力強
博客文章
Amy
SEO 優化 + 吸引力
社交媒體
Amy
平台原生風格
API 文檔
Winnie
技術準確性優先
用戶指南
Amy
可讀性優先

不是所有任務都適合自動化。關鍵是先把"可標準化派發"的任務跑通，再逐步擴展。

三、100% 自動化閉環：到底怎麼跑通的

這是這篇文章的核心。我先畫一張全景圖，再逐步拆解每個環節。

圖片

3.1 派發：一條消息觸發一個 Agent

派發有兩種方式。

方式一：CLI 派發（適合批量或腳本觸發）

# 派 Winnie 修 Bug
~/.openclaw/swarm/spawn-agent.sh winnie fix-auth-bug \
  "Fix the login validation bug in auth.ts"

# 派 Amy 寫文案
~/.openclaw/swarm/spawn-agent.sh amy blog-launch \
  "寫一篇產品發佈博客，目標讀者：開發者"

方式二：Telegram 消息派發（適合隨時隨地）

在 Telegram 裏發消息給對應的 Bot，編排器自動路由。這也是我最常用的方式——開會間隙、地鐵上、帶孩子時，掏出手機發一條消息就行。

每次派發，系統內部會做 4 件事：

  1. 1. 寫入 active-tasks.json（任務註冊表）
  2. 2. 創建獨立 tmux session（互不干擾）
  3. 3. 通過 openclaw agent --agent <id> --message '<prompt>' --local 啓動 Agent
  4. 4. 日誌輸出到 ~/.openclaw/swarm/logs/<session>.log

3.2 執行：Agent 在 tmux 裏自主工作

這是最關鍵的一步，也是"養蝦"和"用工具"的本質區別。

Agent 啓動後，在自己的 tmux session 裏獨立運行：

  • • 讀取任務上下文和相關記憶
  • • 拉取代碼到獨立 worktree（不影響主分支）
  • • 自主編碼或寫作
  • • 自主運行測試
  • • 完成後自動 gh pr create --fill

整個過程不需要我盯屏幕。我可以去開會、做飯、帶孩子——它們在後台持續工作。這就是從"操作工具"到"管理團隊"的躍遷。

3.3 巡檢：零 Token 的確定性監控

很多人會問：你怎麼知道 Agent 幹完了？幹得對不對？卡住了怎麼辦？

答案是 check-agents.sh——一個 100% 確定性的 Shell 腳本，零 LLM token 消耗。

它的邏輯非常簡單（也正因為簡單，才穩定）：

  1. 1. 讀取 active-tasks.json 中所有活躍任務
  2. 2. 逐一檢查 tmux session 是否存活
  3. 3. 通過 gh pr list 檢查 PR 和 CI 狀態
  4. 4. 自動標記失敗任務，觸發重試
  5. 5. 超過 3 次重試則標記為 failed 並告警
  6. 6. 只在需要人工介入時才發通知

配合 cron 每 10 分鐘運行一次，這套巡檢就像蝦塘裏的自動增氧機——你不需要 24 小時盯着，但它一直在工作。

3.4 狀態機：從 running 到 review-ready

任務的狀態流轉是可追蹤的：

running → done (成功完成)
running → blocked (需要人工輸入)
running → ci-failed → respawning → running (自動重試)
running → session-dead → respawning (tmux 掛了，自動恢復)
running → failed (超過 3 次重試，人工介入)
done → review-ready (CI + review 全過)

整條鏈路裏，唯一需要人的環節是最後 5-10 分鐘的 review。其餘全部自動化。這就是"100% 自動化閉環"的含義——不是"零人工"，而是"人只做決策，不做執行"。

四、實戰驗證：Voice Real-time Translation 項目

光說架構沒用，得拿真實項目驗證。

我用這套 Swarm 實際參與管理的項目之一，就是之前文章裏寫過的 Voice Real-time Translation（macOS 應用名 VoiceTranslation）——一個專門解決 Teams 標準版"有字幕無翻譯"痛點的 macOS 實時語音翻譯器。

這個項目從 2025 年 8 月 11 日首次提交，到現在已經穩定運行半年，經歷了兩次關鍵重構（API Provider 管理重構 + 權限處理與音頻質量監控重構）。在引入 Agent Swarm 後，工作方式發生了質變：

階段
工作方式
典型效率
早期（2025.08-2025.12）
我自己寫代碼，偶爾用 Claude 輔助
一個功能 2-3 天
重構後（2026.01-2026.02）
Winnie 寫代碼，我做 review
一個功能 2-4 小時
Swarm 接入後（2026.02.25 起）
派發任務後去開會，回來 review
並行處理 3-5 個任務

上週的一個真實案例：

我在開需求評審會，順手在 Telegram 給 Winnie 發了一條消息：

"VoiceTranslation 的 Core Audio Tap 在藍牙設備切換時偶爾丟幀，查一下 AudioStreamBasicDescription 的採樣率同步邏輯，修復後跑 unit test。"

兩個半小時後會議結束，Winnie 已經提了 PR，附帶了修復代碼和通過的測試用例。我 review 了 5 分鐘，合併。

與此同時，Amy 在另一個 tmux session 裏完成了一篇微信公眾號文案的初稿。我調整了幾處措辭，也發了。

一個下午，兩個交付，人工介入總共 15 分鐘。

圖片

五、蝦塘的水電和增氧：技術架構全解

為了讓不那麼技術的讀者也能理解，我用"蝦塘"的比喻來對照每一層組件。

5.1 蝦塘本體（基礎設施）

組件
蝦塘比喻
實際作用
OpenClaw 2026.2.25
蝦塘整體框架
Agent 編排平台，統一調度所有 Agent
tmux sessions
養殖池隔板
每個 Agent 獨立運行空間，互不干擾
git worktrees
獨立投餵區
每個 Agent 有自己的代碼副本
Telegram Bots
對講機
人與 Agent 的實時通信通道
SQLite + Gemini Embedding
蝦的記憶
每個 Agent 獨立記憶庫，積累經驗

5.2 飼料（模型配置）

模型
用途
選擇理由
openai-codex/gpt-5.3-codex
Winnie + Amy 主力
Codex 在編碼任務上的完成度最高
anthropic/claude-sonnet-4-5
Amy 的 fallback
中文內容質量更優
gemini-embedding-001
記憶系統向量搜索
Embedding 質量與成本平衡

兩個 Codex 賬號輪換使用，避免單賬號限額觸頂：

"order": {
  "openai-codex": [
    "openai-codex:second",
    "openai-codex:default",
    "anthropic:manual"
  ]
}

5.3 增氧系統（監控工具鏈）

文件
作用
運行方式
active-tasks.json
任務註冊表，追蹤所有 Agent 狀態
實時更新
spawn-agent.sh
一鍵派發腳本
按需調用
check-agents.sh
零 token 巡檢腳本
cron 每 10 分鐘
logs/
 目錄
每個 session 的完整輸出日誌
持續寫入

5.4 賬號隔離策略

這是一個容易被忽略但極其重要的細節：

賬號
用途
隔離原因
k******g@gmail.com
僅本地 macOS Codex CLI
我的日常開發，不參與 Agent
j********g@gmail.com
OpenClaw Agent 主賬號
Agent session 獨立消耗
w********2@gmail.com
OpenClaw Agent 備用
限額輪換，避免觸頂

為什麼要隔離？因為 Agent 的 token 消耗量遠超人類手動使用。如果共用一個賬號，Agent 跑滿限額後我自己就用不了了。

5.5 自建代理：成本控制的隱藏關鍵

我的 Anthropic 和 Gemini API 不是直接調用官方端點，而是通過自建代理訪問（BaseURL: https://cc.junxinzhang.com）。好處是：統一管理所有 API 調用日誌、實時監控成本、異常時可快速切換。

六、成本賬：養蝦到底花多少錢

6.1 參考數據：Elvis 的公開成本

項目
月費
Claude API
~$100
Codex API
~$90
合計~$190/月

6.2 我的實際成本

我目前還在測試和調優階段，任務密度沒有 Elvis 那種"日均 50 commit"的級別。當前月成本大約 $50-80。

但核心不是"花多少錢"，而是產出比。一個初級開發者的月薪遠不止 $190。而這兩隻蝦 7×24 小時在線，沒有社保、不請假、不需要管理。當然，它們不會主動提需求——這也是"人在迴路"的價值所在。

6.3 硬件邊界

配置
併發 Agent 上限
體驗
16GB Mac
4-5 個
夠用，但接近上限時會卡
128GB Mac Studio M4 Max
充分併發
Elvis 推薦配置

瓶頸是 RAM，不是 CPU。每個 Agent 的 tmux session + worktree + 模型上下文都在吃內存。

七、踩過的坑（省你走彎路）

不說踩坑記錄的文章是不完整的。以下是我搭建過程中最痛的幾個：

7.1 網絡代理干擾 Cloudflare Tunnel

問題：cloudflared 持續報錯 "there are no free edge addresses left to resolve to"，QUIC timeout 不斷。

根因：本地 Stash 代理（端口 7890）劫持了 DNS，將 Cloudflare edge 解析到假 IP 198.18.0.x。QUIC 使用 UDP，代理無法正確轉發。

解法：在 Stash 配置中 bypass *.argotunnel.com；或者在 cloudflared 中添加 --protocol http2 強制 TCP。

教訓：本地跑代理工具的同學特別注意——任何需要 UDP/QUIC 的服務都可能被代理干擾。

7.2 Codex Device Auth 在代理環境下失敗

問題：執行 codex login --device-auth 始終無法完成認證流程。

解法：https_proxy="" codex login --device-auth，繞過代理即可。Business 工作空間還需管理員啓用 device code auth。

7.3 Token 過期導致 Agent 靜默失敗

問題：Codex OAuth token 有效期約 10 天。過期後 Agent 不報錯，只是靜默停止工作——這是最陰險的 bug，因為你以為蝦還在幹活，其實已經罷工了。

解法：在 check-agents.sh 中增加 token 有效性檢查。定期刷新 token 並同步到 OpenClaw。備份機制：~/.codex/auth.json.kiyo.bak。

7.4 新舊版本共存導致 CLI 衝突

問題：本地同時存在 ~/.clawdbot/（舊版 Clawdbot 2026.1.24-3）和 ~/.openclaw/（新版 OpenClaw 2026.2.25），兩套 CLI、兩套 Memory DB、兩個 Gateway 端口，互相干擾。

解法：統一以 ~/.openclaw/ 為準，舊版不再使用。切記清理乾淨，否則後台進程可能佔端口。

八、從"用工具"到"養生態"：6 條核心理念

圖片

總結這段實踐，我提煉了 6 條核心原則：

  1. 1. 分層上下文：編排器持有業務全局，Agent 專注執行。不要讓一個 Agent 又懂業務又寫代碼——這會快速吃光上下文窗口。
  2. 2. 專業化分工：Winnie 寫代碼，Amy 寫文案，各司其職。混用一個通用 Agent 做所有事的效果遠不如專業化配置。
  3. 3. 賬號隔離：我本地開發用一個賬號，Agent 跑任務用另外的賬號，互不干擾、互不搶限額。
  4. 4. 零 Token 監控：確定性腳本巡檢，只在需要時消耗 API。監控本身不應該是 LLM 任務——這是很多人容易犯的錯。
  5. 5. 遞歸改進：成功的 prompt 模式記入 memory，失敗的也記錄原因和修復方案。每一次執行都在為下一次積累經驗。
  6. 6. 人在迴路：Agent 做 80% 的執行工作，人做 20% 的決策和審查。完全無人介入不是目標，高效協作才是。

寫在最後

"養蝦"不是一個精確的技術詞，但它抓住了一個本質：

AI Agent 的價值不在單次調用的驚豔，而在持續運轉的生態。

搭好蝦塘、選好蝦苗、配好飼料、裝好增氧機——然後你可以去做更重要的事：思考業務方向、和客戶對齊需求、做技術決策。那些能被標準化拆解和重複執行的工作，交給蝦去做。

我目前的 Swarm 還在早期階段，接下來會繼續推進幾件事：

  • • 配置 cron 定時運行 check-agents.sh
  • • 測試 Winnie → Amy 的跨 Agent 自動協作鏈路
  • • 引入三路 AI Code Review（Codex + Gemini + Claude）
  • • 擴展更多 Agent 角色：SEO 專家、數據分析
  • • 持續積累 memory，讓每隻蝦越養越聰明

如果你也在琢磨 Agent Swarm，或者對 OpenClaw 有實操經驗，歡迎交流。

一個人 + AI Agent Swarm = 一個團隊。這不再是願景，而是每天在發生的事。

相關閲讀

OpenClaw 系列

AI 工程系列

參考資料（官網/官方）

  1. 1. OpenClaw 官方文檔
    https://docs.openclaw.ai/
  2. 2. Elvis（@elvissun）：Agent Swarm 方法論原文
    https://x.com/elvissun/article/2025920521871716562
  3. 3. OpenAI Codex 官方文檔
    https://openai.com/codex
  4. 4. Anthropic Claude API 文檔
    https://docs.anthropic.com/
  5. 5. Google Gemini Embedding API
    https://ai.google.dev/gemini-api/docs/embeddings
  6. 6. Apple WWDC24 - Core Audio Taps（VoiceTranslation 項目參考）
    https://developer.apple.com/videos/play/wwdc2024/10153/