長時間運作的 OpenClaw 閘道若架在 24/7 macOS Mac mini 上，上下文膨脹速度往往快過試算表：每則 Slack 串流都會附加工具轉錄、每次失敗指令可能帶冗長的 stderr 重試，而附件預覽又會在對話狀態裡塞進體積可觀的 base64。到了第三週，維運常觀察到 p95 延遲超過 8 秒，但 CPU 仍低於 45%——代表瓶頸多半是供應商正在吞 megabyte 級的重複文字，而非模型「算更難的題」。本篇說明如何 裁剪對話記憶、限制工具輸出、讓每輪 token 上限對齊供應商合約，並在真硬體上演練變更。請與 權杖預算與工具節流、JSON 與環境變數整理、以及 閘道 doctor 診斷 併讀，避免裁剪政策與鑑權或路由表互相打架。
你會拿到決策矩陣、可寫進稽核的數字起點（token 上限、留存視窗、日誌輪替大小）、macOS 特有陷阱，以及給平台工程師的常見問答。
判斷記憶體是否為瓶頸的訊號
當首字元時間變長、但 CPU／GPU 仍低，多半是提示詞過胖。另一個徵兆是每 90 秒出現磁碟寫入尖峰——閘道把整串對話快照到磁碟，即使通道閒置也在燒 IOPS。
財務友善的計數器建議同時追：每輪平均提示詞 token、每小時附加的工具 stdout 位元組、根卷可用空間百分比、以及被標成「助理忘記先前決策」的重開工單。沒有這四條序列，你很難向財務證明「裁剪這一刀」真的省錢。
事故當下請先凍結功能：留存已去識別的轉錄，標出重複的工具負載，再考慮回滾上一版摘要提示詞。
文件化「破窗」暫時提高留存的票號；否則團隊在上市週會默默關掉裁剪，月底帳單翻倍卻無人知道是哪個開關。
客服分流時請區分「每天第一則訊息就慢」與「只有長串後才慢」：前者偏冷啟動或 DNS／憑證設定，後者才像裁剪缺口。
若你已導入 工具節流，仍要檢查摘要工作是否與節流器共用同一個佇列——否則互斥鎖會讓兩邊一起餓死。
矩陣：摘要 vs 硬截斷
| 策略 | 品質 | 成本 | 風險 |
|---|---|---|---|
| 每 N 輪呼叫 LLM 做摘要 | 連貫性高 | 多耗模型呼叫 | 摘要可能丟合規數字 |
| 硬截斷＋釘選系統事實 | 較便宜 | token 開銷低 | 釘選不完整時使用者覺得「失憶」 |
| 混合：只摘要工具雜訊 | 平衡 | 中等 | 需要 schema 感知的去識別 |
2026 年多數團隊採混合：保留使用者決策與票號原文，把超過 4 KiB 的 shell 日誌壓成短摘要。
能通過稽核的數字預設值
起步建議：保留最近 30 輪使用者可見對話原文，更舊內容壓成不超過 900 token 的條列式備忘；單一工具附件預覽在 base64 前先截到 64 KiB；根卷可用空間低於 12% 時拒收新附件。
摘要背景工作同時最多 3 個 worker，避免壓縮本身餓死互動回覆。
供應商維護窗口前 15 分鐘起，暫時把摘要頻率降 50%，降低與廠商 brownout 疊加的機率。
用含 200 輪的 replay 檔紅隊：若超過 2% 的合成工作階段遺失釘選合規句，代表摘要提示詞仍漏風。
裁剪常數應以 Git 版控；值班不應靠記憶猜「事故當下線上到底是哪組數字」。
調整常數後請交叉檢查 環境與 JSON 設定檔 是否在所有 plist 路徑同步，避免一半行程讀舊上限、另一半讀新上限。
macOS 磁碟、LaunchAgent 與日誌
launchd 工作若把冗長轉錄寫進 ~/Library/Logs，APFS 容器耗盡的速度常出乎習慣 ext4 的團隊意料。建議單檔輪替上限 256 MB、保留 5 代。
裁剪與本機 fork 上限要一起設——細節見 節流指南 的併發上限，避免摘要 worker 無限 fork。
硬體採購慢時，可租雲端 Mac mini 演練壓縮：MacHTML Apple Silicon 主機常見約 每日 16.9 美元，含 SSH／VNC 即時看磁碟與延遲。
變更裁剪常數後請重啟閘道 LaunchAgent，並用 doctor 探測 確認 RPC 健康，再宣告釋出完成。
若同機還跑本機向量索引，記得把 embedding 快取與對話快照分卷，避免單一 APFS 容器在深夜壓縮 job 撞在一起。
Keychain 內的供應商權杖輪替時，暫時下調摘要併發，直到每份 plist 都讀到新權杖為止。
裁剪時的通道體驗
Slack 與 Teams 使用者通常能接受摘要，前提是副本說明原因。當單次壓縮丟棄超過 40% 原始 token 時，發模板化通知並連到內部留存 FAQ。
產品常喊「無限記憶」——請翻成明確預算：展示每多 1,000 提示詞 token 一週平均多花多少美元，再提案用釘選事實區塊扛過摘要。採用釘選的團隊在內部調查中，月費常降約 18–28% 而滿意度變化不大。
對外機器人在壓縮後加一行「記憶已整理」，提醒使用者冗長免責聲明可能需要重新確認——在受規管產業尤其關鍵。
裁剪後請避免把原始工具 stderr 原樣轉貼回通道，以免以為已去識別的機密復活。
多語團隊共用閘道時，依工作區語系標頭本地化摘要通知，降低誤解。
摘要執行中節流「正在輸入」類事件，避免客戶端在背景 job 期間狂送狀態更新而放大供應商負載。
遙測與財務友善指標
匯出裁剪前後的提示詞 token 直方圖；若差距低於 25%，多半是摘要靜默失敗。
每次壓縮跑批次請帶 Git SHA，讓財務能把帳單尖峰對到「哪一版提示詞」而不是盲怪供應商。週對週尖峰超過 12% 時，建議 48 小時內召開無責檢討，同時原始日誌仍在留存期內。
當可用空間低於 15% 超過 10 分鐘 應呼叫基礎設施 on-call，避免閘道在壓縮中途無法寫入。
結構化稽核日誌建議保留 90 天，並用關聯 ID 把使用者訊息與壓縮版本綁在一起。
儀表板同時追「首次即答」成功率與平均提示詞 token，避免產品只優化延遲卻默默炸成本。
每季人工抽樣 35 條最長串；自動分桶仍常把供應商變慢誤標成記憶體問題。
刪除上下文時的安全注意
切勿把完整提示詞與壓縮標記一起寫進一般日誌；事故包應只存雜湊過的對話 ID。凌晨三點的偵錯 dump 仍要去識別 API 金鑰。
GDPR 與 SOC2 稽核常問「如何證明使用者在破壞性裁剪前已被告知」；橫幅與同意時間戳應與壓縮 job 索引並存。
若懷疑外洩，請輪替共用供應商金鑰，並暫時收緊摘要併發直到每份 LaunchAgent plist 都換新鍵。
針對「立即摘要」端點做滲透測試：確認身分驗證與速率限制存在，避免攻擊者把壓縮變成 CPU 耗竭。
最後演練故障轉移：先快照磁碟上的串流存放區，模擬壓縮寫入中途失敗，確認閘道寧可拒絕啟動也不要提供截斷後不一致的歷史——這能避免最糟的一類客服票：徹夜部署後使用者看到自相矛盾的回覆。
常見問題
裁剪應每則訊息執行還是每小時？
熱門通道建議每則訊息；安靜工作區可改每小時，降低 churn。
裁剪能取代節流嗎？
不能，兩層都要。
為何要在實體 Mac mini 上演練？
macOS 排程、磁碟壓力與鑰匙圈行為與 Linux CI 不同。
Apple Silicon Mac mini 仍是演練 OpenClaw 記憶政策最忠實的舞台：長時間錄影的熱行為可預測、日誌輪替走原生檔案系統、LaunchAgent 時間與生產一致。MacHTML 提供含 SSH／VNC 的雲端 Mac mini 租用，讓平台團隊能驗證裁剪、節流與 doctor 探測而無需新一輪資本採購——演練期開機取證，綠燈後關機即可。
在雲端 Mac mini 上演練 OpenClaw 記憶政策
租用 Apple Silicon 容量，在真實 macOS 上測試轉錄裁剪、磁碟輪替與閘道 doctor。先看定價，再依說明以 SSH 接入。