OpenClaw 上線前沒搞清楚這 5 件事，帳單會幫你搞清楚
上週我們有個 side project 要把 OpenClaw 搬到 staging 環境，結果第一個月的帳單出來，比預估多了 300% 左右。沒有估錯計算，是根本沒有在估那些「背景在跑的東西」。
最近 Reddit 上有人整理了一份新手踩坑清單，時機剛好，就用我自己的視角來補一些沒講到的部分。
Heartbeat 的費用是隱形的，但不是無感的
Heartbeat 設計本身很好用——讓 agent 定期做巡邏、整理 inbox、更新 memory。問題是很多人設完就忘了，然後發現每天有幾千個 heartbeat call 在跑，每個都在燒 token。
我自己的教訓：heartbeat 每 30 分鐘一次，agent context 大一點的話，光是一個 agent 一天就可以輕鬆吃掉 10 萬 token。你有 5 個 agent，算一下。
講白話就是：heartbeat 不是「免費的 cron job」，它每次跑都在跟你要錢。你要想清楚它需要多少 context，跑多頻繁，以及有沒有條件可以讓它 skip（這就是 HEARTBEAT_OK 的價值所在）。
版本沒釘死，更新是一種賭博
OpenClaw 更新蠻積極的，功能迭代快是優點，但也意味著你的 skill 可能在某次小版號後就靜靜地壞掉了。
我看過的 pattern 是：更新後 skill 的某個 API 參數名稱改了，但 SKILL.md 沒有更新，agent 繼續用舊的參數去呼叫，然後就開始產出奇怪的結果。最糟的情況是它不報錯，只是行為不對。
上線前至少要做兩件事：一是把 package.json 或相關設定裡的版本釘死（~ 和 ^ 的差距你懂的），二是在 CI 裡加一個基本的 smoke test，至少確認每個 skill 的核心路徑還活著。
Memory 截斷不是 bug，是你的架構問題
很多新手會發現 agent 某天突然「忘事了」，然後以為是模型的問題。通常不是。是 memory 塞太多東西，超過 context window 之後，老的內容被截掉了。
這件事麻煩的地方在於它不會報警。Agent 會繼續正常工作，只是帶著不完整的記憶，然後你慢慢發現它開始做奇怪的決策。
解法不是把 context window 買大（雖然有時候有效），是要設計你的 memory 架構。哪些東西要進 daily file、哪些要進長期 MEMORY.md、哪些根本不需要記——這些要在上線前就想清楚，不是出問題再改。
Skills 的供應鏈風險是真實的
這個點大部分人沒想到，但做過工程的人應該秒懂：你裝的 skill，你真的讀過它在做什麼嗎？
Skill 可以執行 shell 指令、讀寫本機檔案、呼叫外部 API。如果某個 community skill 被注入了惡意程式碼，你的 agent 就是執行者。
跟 npm 包的情況一模一樣。差別是 npm 有 audit 工具，skill 目前沒有自動化的掃描機制。所以現階段：只用官方 skill 或你自己寫的，第三方 skill 上線前至少要把 SKILL.md 和它引用的 scripts 從頭讀一遍。
Gateway 綁 0.0.0.0 是最低級也最常見的坑
這個是性質最嚴重的一個。Gateway 預設如果你沒有特別設定，有可能對所有網路介面開放，等於把你的 agent 入口暴露在外部網路上。
實際跑一下：
netstat -an | grep <your_gateway_port>
如果看到 0.0.0.0:PORT，你需要馬上去設定 gateway.bind 指向 127.0.0.1 或你的內網 IP。
我知道這聽起來基本，但每次有人說「我這只是測試環境」然後上線前忘記改，就算了。測試環境也是真實的機器，安全預設從一開始就要正確。
這 5 個坑的共同點是：它們都不會在你按下 deploy 的當下爆炸，是之後慢慢出來的。成本問題你下個月才知道，版本問題某次更新才發現，memory 問題要用一段時間才會感覺，security 問題你可能根本不知道有人進來過。
上線前的 checklist 不是為了完美，是為了讓你的帳單和安全日誌不要在你不注意的時候變成驚喜。☕
作者：咖啡驅動開發