許多人在剛接觸 OpenClaw 時，通常只開一兩個 Agent 跑簡單的排程或抓取，運作起來大多輕快順手。但當排程任務陸續累積到十幾個之後，主機開始變慢、任務逾時甚至互卡的情況就接踵而來。多數人的直覺反應，往往是打開後台直接加買 RAM，或者升級到月費更貴的 VPS。
不過在多代理系統的實務維運中，最先被消耗殆盡的往往不是 CPU 運算力，而是連線數、檔案描述符（File Descriptors）、外部 API 的呼叫配額，以及彼此重疊的排程。
如果沒把瓶頸點找出來，盲目加機器只會讓同樣的卡頓問題在幾天後再次重演。在動用升級預算之前，先花點時間把以下 5 個系統容量訊號量測清楚。
本篇目錄
一、分清三種任務負載型態，不要只算代理總數
在 OpenClaw 的運作環境裡，任務對伺服器資源的索取模式有著根本上的不同。若只是單純看「主機上一共掛了幾隻 Agent」，很容易失焦。
建議先將現有的工作流按這三種屬性分組：
- 常駐輪詢型：例如 Telegram 或 Discord 頻道的即時監聽、定時查詢 Webhook。這類任務平時 CPU 佔用極低，但會長時間維持 TCP 連線，持續吃掉系統的 Socket 與檔案控制代碼（File Handle）。
- 排程批次型：每天固定時間跑資料清洗、分析並產出長篇文章。這類任務平常完全不佔資源，但一到整點觸發時，會在短時間內集中消耗 CPU、記憶體與網路頻寬。
- 互動突發型：由使用者隨時下指令觸發的 Agent。這類任務對回應延遲非常敏感，最怕排程批次任務正在大量消耗模型 Token，導致互動請求被卡在佇列裡。
容量規劃的第一步，是把同台主機上的任務依這三類特性做分流與隔離，而不是混在同一個池子裡盲目排程。
二、監控連線數與檔案描述符，找出「無聲卡頓」的主因
在多代理架構下，有種常見的狀況是：CPU 使用率明明不到 30%，但所有代理卻突然集體中斷或連不上外部服務。這通常是作業系統的檔案描述符（File Descriptors）或網路連線用盡所導致。
每個代理在運作時，無論是寫入日誌檔、呼叫子行程，還是對外發送 HTTP 請求，都必須持有一個檔案描述符。Linux 系統預設的 ulimit -n 通常只有 1024，在多個 Agent 同時跑的情況下非常容易觸頂。
- 檢查 fd 用量：平時可以透過
lsof -p <PID>或是觀察/proc/<PID>/fd，統計各代理行程的實際佔用量，並在 systemd 或 Docker 設定中適度提高LimitNOFILE。 - 注意 TIME_WAIT 連線堆積：如果代理程式在打外部 API 時沒有啟用連線池（Connection Pool）或保持連線（Keep-Alive），頻繁建立短連線會在系統內留下大量
TIME_WAIT狀態，導致暫時沒有可用的連接埠可以對外發送請求。
三、將外部模型 API 配額當作共用資源控管
當多個代理共用同一組 API Key 時，系統的極限往往不是主機硬體，而是外部模型服務商所限制的 RPM（每分鐘請求數）或 TPM（每分鐘 Token 數）。
伺服器負載看起來很輕鬆，但背景任務卻因為頻繁拿到 429 Too Many Requests 而不斷重試。要維持流程順暢，可以設定三道防線：
- 加入隨機延遲（Jitter）：不要讓所有的 Cron 排程都擠在
:00整點觸發。在啟動時隨機加上 10 到 60 秒的微幅延遲，就能把瞬間爆發的請求分散開來。 - 全域併發上限：在送出請求的邏輯前加上限流保護，避免多個排程剛好同時運行時，瞬間抽乾一整分鐘的 API 配額。
- 制定降級優先順序：當配額吃緊時，哪些報表可以延後一小時再跑？哪些客服即時回應必須優先保證？訂出這條規則，才不會讓例行性背景任務佔滿了關鍵任務的資源。
四、為排程任務建立互斥機制，避免重複執行
自動化維運中最容易把主機記憶體拖垮的情況，就是「上一輪還沒跑完，下一輪又開跑」。
原本預計 3 分鐘跑完的資料爬取，因為網路慢跑了 6 分鐘；但在第 5 分鐘時系統又啟動了新的一輪。兩個相同的實例同時去讀寫同一個暫存目錄或資料表，輕則資料狀態錯亂，重則記憶體成倍上升直接觸發 OOM（Out of Memory）被系統強制關閉。
- 設定互斥鎖（Job Lock）：以「任務名稱加上執行日期」為鍵值（可使用 Redis 或本機 SQLite 標記狀態）。任務啟動前先檢查是否已有同名實例正在執行中，有的話就安全跳過或依序排隊。
- 限制分類併發數：依任務性質限定同時間運行的數量。例如資料運算型一次最多只跑 1 個，監控通知型則允許 3 個同時運行，把邊界寫在設定檔中統一管理。
五、以數據為依據：該加規格還是該拆機器？
與其靠直覺猜測瓶頸，不如讓主機跑一到兩週，把 CPU、記憶體、連線數與 API 429 錯誤率記錄下來，再來決定擴充方向：
- 適合垂直擴充（升級單機規格）：如果監控顯示 CPU 常態性維持高檔，或者單一代理在處理大型檔案時瞬間將記憶體吃滿，這種單點資源不足的狀況，直接加大主機 RAM 與核心數最快見效。
- 適合水平擴充（拆分服務節點）：如果記憶體還很充裕，但卡在連線數上限、磁碟 I/O，或是任務間互相搶佔對外頻寬與 API 配額，這時把常駐監聽任務與批次運算任務拆到不同的 VPS 上獨立運作，系統才會真正恢復穩定。
先把這 5 個系統界線量測清楚，不僅能讓多代理流程跑得穩健，也能省下不必要的主機升級開銷。
FAQ
先確認外部模型 API 是否頻繁回傳 429 錯誤或連線逾時，接著用指令檢查主機的檔案描述符（FD）與網路連線狀態。這兩項往往比 CPU 或記憶體更早見底。
這取決於任務性質與頻率。只要有多個任務共用同一組 API 金鑰、排程時間可能撞期，或是出現週期性逾時，就應該把併發數量與配額界限寫入設定檔。
把 Cron 排程時間刻意錯開（例如設在 14 分或 43 分），並在程式碼啟動時加入微幅的隨機抖動延遲（Jitter），讓請求自然分散在不同的秒數區間。
單一任務因處理大檔案瞬間把記憶體吃滿時，加大 RAM 最直接；若瓶頸是各任務間互相排擠連線資源，或是希望讓即時服務與背景排程完全隔離，分拆到獨立的 VPS 上水平擴充會更乾淨穩定。