OpenClaw 效能
浪費 是指請求不需要的工作。大幅度的加速來自於刪除浪費，而非將相同的工作做得更快。快取是最後的手段：它只會隱藏浪費，直到其金鑰、失效或命中率出現問題，浪費便會重新出現。
1. 衡量
在 第一次 執行之前，於 PR 中寫下驗收規則：流程、工作負載、衡量指標、冷或暖、樣本數，以及視為成功或回歸的變化量。
| 流程 | 已提交的工作負載 |
|---|---|
| CLI 啟動 | pnpm test:startup:bench (:check 包含了預算) |
| Gateway 啟動 / 重啟 | scripts/bench-gateway-startup.ts, scripts/bench-gateway-restart.ts, scripts/perf/post-restart-burst-measure.ts |
| Chat 回合，每回合幀數 | scripts/bench-channel-turn.mts, scripts/perf/transcript-broadcast-measure.ts |
| Control UI 冷載入 | scripts/bench-control-ui-cold-load.ts, pnpm ui:check-performance (:base 用於比較) |
| Session 列表，多代理形狀 | scripts/perf/team-shape-fixture.ts, src/gateway/session-list-viewers.perf.test.ts |
| 並發性，SQLite 狀態 | scripts/bench-gateway-concurrency.ts, pnpm test:sqlite:perf |
- 優先計數： 在牆上時間之前，先計算每個動作的操作次數（SQL 語句、RPC 和幀、檔案讀取、目錄或註冊表載入、生成、渲染）。計數在負載主機上能保持穩定。一個應該是零的計數卻不是零，就是一個錯誤。
- 真實流程： 在被測試的 head 上使用獨立的 Gateway、真實傳輸、並包含慢速路徑。使用模擬的 Gateway、過時的建置或開發伺服器，則是在衡量別的東西。
- 樣本： 基準線和候選版本交錯進行 (ABAB)，每個至少 5 次，冷啟動和暖啟動分開；記錄中位數和 p95 及其分佈，序列化執行，並記錄主機負載。
- 可重複執行： 只有已提交的腳本才算數；當沒有腳本適用時，擴展現有的腳本。
- 效能分析： 對每個執行緒使用
node --cpu-prof，或對熱路徑使用瀏覽器效能追蹤。
當流程擁有已提交的工作負載、基準表和一則書面規則時，即完成。
2. 找出浪費
對每一個被計數的操作詢問：這個請求需要它嗎？OpenClaw 中反覆出現的浪費：
- 關鍵路徑上的急迫工作： registry 查找匯入了外掛載入器 (#133518, 47.07 秒 → 10.36 秒)；啟動時載入可選的執行環境 (#119374)。
- 每行或每次呼叫的重新計算： 每個歸檔行都進行同步讀取 (#156665, 56,700 次讀取 → 0)；每個 frame 都解析日誌模式 (#150042, 每 10,000 個 frame 從 539 降到 17 毫秒)。
- 重新檢查已准入的狀態： 對暖 handle 進行 schema、准入或新鮮度檢查 (#166102, #172676；SQLite 准入鏈中的 14 個 PR)。
- 對每個串流增量進行完整重新掃描： 每個 token 都重新處理整個回覆 (#158526, 在 256 KiB 下 CPU 從 5,342 降到 1 毫秒)。
- 重新讀取自己的寫入： 每次查找都進行兩次資料庫備份 (#161551, 從 772.8 降到 7.7 毫秒)；Doctor 對它剛檢查過的內容進行重新掃描和備份 (#174665, 約 26 秒降到 3.0 秒)。
- 重複的目錄或註冊表建置： 啟動時為每個代理重建目錄 (#116261, 從 24.9 降到 5.0 秒)；每次 miss 或 TTL 過期都重建 (#127178, #167008)。
- 等待可選資料： Usage 頁面等待 provider 方案並重試不相關的讀取 (#176358)。
- 防禦性複製與封裝： 每回合進行
structuredClone(#172940, 從 1.685 MiB 降到 0)；每次事件的邊界封裝 (#163818, 從 11,571 降到 500 奈秒/事件)。 - 每次呼叫都產生或分散： 每次解析都產生一個子程序 (#155779, 從 100 降到 0)。
- 渲染串聯與完整酬載： 每次更新都進行渲染 (#159400, 從 250 降到 79)；為了單一增量而重新發送完整行 (#165404, 從 21.75 降到 0.95 MB)。
當每個主要的計數都能追溯到發出該計數的程式碼，並且可以明確回答「是否需要」時，即完成。
3. 按此順序修復
- 刪除 浪費。刪除很少會回來；一次失敗的刪除可能移除了保護機制，因此請保留所有保護合約的檢查，並證明合約仍然有效。
- 在擁有者處執行一次： 呼叫者使用擁有者記錄的事實。
- 將預先準備的事實 攜帶通過熱路徑。
- 批次處理 獨立工作，並證明批次處理能保持 frame、延遲尾端和冷啟動穩定：合併曾三次被回退 (#162560, #173901, #175092)。
- 快取，並附上步驟 1–4 不適用的書面理由。遵循根本的「快取身份」，從擁有者的寫入中使其失效，限制大小，並加入一個交錯的工作計數測試。四個快取重新修復中有三個是靜默未命中：讀取者相互驅逐 (#115369 → #174741)，導致預算耗盡的預算 (#149773 → #149879)。
將工作移至 worker 或延遲執行會重新分攤成本；請同時計數主執行緒和總工作量。
當浪費從計數中消失，或者 PR 說明了在哪個步驟停止以及原因時，即完成。
4. 落地
- 在相同的規則下，對基準線和候選版本重新執行步驟 1 的工作負載。
- 每個使用者可見的指標都保持或改善： 延遲、p95/p99、frame、冷啟動、CPU、記憶體、計數。較差的指標需要擁有者在 PR 中明確接受。某個數據點移動 20% 就是一個停止信號，永遠不要歸結於「在分佈範圍內」：六個被回退的效能 PR 中有五個在其本體中顯示了自己的回歸。
- 回退沒有可衡量收益的變更。
- 證明存在於 PR 中，而非新的測試：前後對比的計數就是證據。僅當此類浪費之前曾經復發時，才擴展現有流程的工作計數測試；test-audit 擁有測試價值的所有權。
- PR 證據：工作負載命令、驗收規則、前後對比表（計數和時間、中位數和 p95、樣本數）、已移除的浪費，以及任何朝錯誤方向移動的指標。
當表格符合步驟 1 中寫下的規則時，即完成。
相關
測試套件速度：openclaw-test-performance。測試堆積增長：openclaw-test-heap-leaks。CI 容量：openclaw-ci-limits。