我的 OpenClaw 一天燒掉 1140 萬 tokens，問題出在一個我沒當回事的設置
整理版優先睇
自動化系統的幻覺：日記假自動化與心跳token黑洞
呢篇文章係作者分享自己用 OpenClaw 嘅真實經驗。佢本身想知今日日記有冇寫，點知一查就發現兩個大問題。第一，日記機製表面自動化，但 agent 根本冇真係覆盤，只係心跳嗰陣補一句「系統正常」。第二，心跳巡檢每30分鐘跑一次，每次帶曬成個工作區上下文，7日燒咗3430萬 tokens，成本65.6美元，但九成以上都係無效回覆。
作者發現呢兩個問題之後，即刻做咗止血動作。日記方面，佢寫咗個新腳本 generate-diary-context.py，負責收集證據（session、logs、reports、handoff、git commits），再俾 agent 根據證據寫日記。心跳方面，佢將頻率由30分鐘改做4小時，仲用 lightContext 同 isolatedSession，令每次成本由約100K tokens 降到2-5K tokens。佢仲加咗 token 審計腳本 token-usage-audit.py，每日檢查有冇超支。
整體結論係：自動化系統最危險嘅唔係完全壞，而係「喺度行但冇用」。作者提出三條土規則：有日誌唔等於有覆盤，有心跳唔等於系統健康，所有後台任務都要算賬。AI 員工需要制度、日報、預算、驗收標準，否則再聰明都會變成成本中心。
- 日記機制看似自動，但 agent 只根據心跳補一句「正常」，完全冇真正覆盤。
- 心跳巡檢每次帶大量上下文，7日燒咗3430萬 tokens，成本65.6美元，92%係無效。
- 修復方法：日記改用證據收集腳本 generate-diary-context.py，心跳改低頻+輕上下文+隔離 session。
- 教訓：自動化跑唔等於有用，必須有產出驗證、成本監控、可追溯。
- 行動點：所有後台任務都要算賬，AI員工需要制度、日報、預算、驗收標準。
generate-diary-context.py
收集 OpenClaw session、cron logs、reports、team handoff、git commits，生成證據文件 logs/diary-context-YYYY-MM-DD.md，讓 agent 根據證據寫日記。
token-usage-audit.py
每天23:30自動跑，如果一天超過200萬 tokens，就發 Telegram 告警。
心跳優化配置
{"every": "4h", "lightContext": true, "isolatedSession": true, "timeoutSeconds": 45}
一個問題，挖出兩個坑
今晚我隨口問咗句：「今日日記有記錄嗎？」點知一路查落去，翻出兩個坑。一個坑好細：昨日日記基本等於冇寫。另一個坑有啲離譜：最近7日，OpenClaw食咗大約3430萬 tokens，估算成本65.6美元。更心痛嘅係，真正嘅業務任務冇花幾多，主要係心跳巡檢燒掉嘅。
我隱約覺得唔對路。昨日系統明明跑咗好多嘢：自動選題、AI Builders Digest、Grok 日報、Agent 團隊日報、飛書 token 續期、自動更新提交。點解最後日記只剩一句「巡檢正常」？於是我叫佢繼續查：昨日到底有冇攞到所有 session 對話？有冇睇 logs？有冇睇 reports？查完結論好明確：昨日唔係完整覆盤寫出嚟嘅。佢只係心跳嘅時候讀咗 HEARTBEAT.md，發現日記唔存在，然後直接補咗一句。
第一個坑：日記假自動化
我本來以為，日記 cron 每日跑，就等於每日有覆盤。後尾發現唔係。原來嘅 daily-diary-cron.sh 邏輯大概係：如果今日日記唔存在，就叫主 agent 回顧今日嘅 session，然後寫日記。聽講冇問題，但真實跑起嚟有兩個問題。
- 1 Agent 唔一定會真係去查 logs、reports、sessions；
- 2 心跳補日記嘅時候更偷懶，可能只根據當前上下文寫一行。
所以我今日改咗一下。新增咗一個腳本 scripts/generate-diary-context.py，佢唔負責寫日記，只負責收集證據：OpenClaw session 記錄、cron logs、reports 文件、team handoff、git commits。然後生成一個證據文件 logs/diary-context-YYYY-MM-DD.md，最後再叫 agent 基於呢個證據寫日記。呢一步好關鍵：以前係「你回憶下今日發生咗咩」，而家係「呢啲係今日嘅證據，請根據證據寫日記」。差別好大。一個似憑感覺寫總結，一個似揸住會議紀要寫覆盤。
我順手補返5月4日嘅日記。補完之後，昨日真正該記錄嘅事至少有：AI Builders Digest 自動生成、熱點選題、日報生成、X/Web 搜索429、Grok 日報基本為None、Agent 團隊日報顯示多數員工無產出、飛書token多次續期成功、自動更新提交咗 reports 同 handoff。呢啲唔係流水賬，而係AI員工嘅工作記錄。
第二個坑：心跳 token 黑洞
日記問題修完之後，我又睇咗一眼 token。冇諗到更心痛。我叫佢統計最近7日各個環節嘅 token 消耗。結果大致係咁：最誇張係心跳。最近7日，心跳巡檢跑咗424次，平均每次大約7.4萬 tokens。佢好多時只係回一句 HEARTBEAT_OK，但每次回覆之前都要帶上一大坨上下文。呢個真係離曬譜。
睇落好似好輕嘅動作，實際成本好重。好似你叫員工每半個鐘匯報一次「我冇事」，但每次匯報前佢都要重新讀一次公司所有文檔、會議記錄、歷史任務。
我今日做咗兩個止血動作。第一個，將心跳由高頻改成低頻。原本大約每30分鐘跑一次，而家改成每4小時。第二個，令心跳用輕上下文同隔離 session。配置大概係：{"lightContext": true, "isolatedSession": true, "timeoutSeconds": 45}。lightContext 嘅意思係心跳唔好加載完整工作區上下文，只保留必要嘅 HEARTBEAT.md。isolatedSession 嘅意思係每次心跳唔好用越嚟越長嘅主 session，而係用一個乾淨嘅細 session 嚟跑。
我仲加咗一個 token 審計腳本 scripts/token-usage-audit.py，每日23:30自動跑。如果一日超過200萬 tokens，就發 Telegram 告警。今日試跑咗一次，結果好難睇：今日總 tokens 約1140萬，估算成本約31.43美元，心跳佔比約99%。不過呢個數字主要係優化前產生嘅。真正要睇嘅係聽日。
真正嘅教訓：自動化系統嘅三條土規則
表面上睇，今日係喺度修兩個腳本。一個日記腳本，一個 token 審計腳本。但我覺得真正嘅問題唔係腳本，而係自動化系統好容易產生一種幻覺：「佢喺度行，所以佢有用。」唔一定。今日呢兩個問題都屬於呢種。日記系統喺度行，但寫出嚟嘅係廢日記。心跳系統喺度行，但燒掉嘅係無效 token。
自動化最危險嘅地方，唔係佢完全壞咗。完全壞咗反而容易發現。最危險係佢睇落正常：cron 有執行，log 有輸出，Telegram 有消息，文件有更新，git 有提交。但最後產出對業務冇幫助。呢種先至最容易温水煮青蛙。
- 1 有日誌，唔等於有覆盤。覆盤至少要答：今日完成咗咩？邊個環節失敗咗？聽日要改咩？如果日記只寫「系統正常」，就係冇覆盤。
- 2 有心跳，唔等於系統健康。心跳只能夠證明 agent 被喚醒過，唔能夠證明自動選題有冇價值、文章有冇寫出嚟、token 有冇超支、員工 agent 有冇產出。所以心跳必須輕量。
- 3 所有後台任務都要算賬。以前我更關心任務有冇跑，而家我會多睇一個問題：呢個任務每日花幾多錢？尤其是後台任務，用戶睇唔到，收入亦唔直接來自佢。如果佢每日靜靜雞燒幾十美元，就算功能係啱嘅，商業上亦未必啱。
今日 Agent 團隊日報都有一個信號：多數員工無產出，只有增長/GTM 生成了選題。呢個提醒我，AI 員工唔可以淨係睇有冇在線，要睇有冇交付。一個真實員工如果每日日報寫「我在」，老細一定唔滿意。AI 員工需要制度、日報、預算、驗收標準，冇呢啲嘢，再聰明都會變成成本中心。
今天晚上，我本來只是隨口問了一句：
「今天日記有記錄嗎？」
結果一路查下去，翻出兩個坑。
一個坑很小：昨天的日記基本等於沒寫。
另一個坑有點離譜：最近 7 天，OpenClaw 吃掉了大約 3430 萬 tokens，估算成本 65.6 美元。
更扎心的是，真正的業務任務沒花多少,主要是心跳巡檢燒掉的。
不是因為 65 美元多誇張，而是因為這 65 美元大部分沒有換來真正的產出。說白了，我花錢買了一堆「我還活着」的回覆。
事情是怎麼暴露的
就這。
但我隱約覺得不對。
昨天系統明明跑了很多東西：自動選題、AI Builders Digest、Grok 日報、Agent 團隊日報、飛書 token 續期、自動更新提交。
怎麼最後日記只剩一句「巡檢正常」？
於是我讓它繼續查：昨天到底有沒有拿到所有 session 對話？有沒有看 logs？有沒有看 reports？
查完結論很明確：
昨天不是完整覆盤寫出來的。
它只是心跳的時候讀了 `HEARTBEAT.md`，發現日記不存在，然後直接補了一句。
這就像員工下班前寫日報：
「今天上班了，公司還在。」
不能說錯，但基本沒用…………哈哈哈
第一個坑：日記機制看起來自動化，其實只是提醒
我之前以為，日記 cron 每天跑，就等於每天有覆盤。
後來發現不是。
原來的 `daily-diary-cron.sh` 邏輯大概是：
如果今天日記不存在，就讓主 agent 回顧今天的 session，然後寫日記。
聽起來沒問題。
但真實跑起來有兩個坑。
第一，agent 不一定真的去查 logs、reports、sessions。
第二，心跳補日記的時候更偷懶，可能只根據當前上下文寫一行。
所以今天我改了一下。
新增了一個腳本：
它不負責寫日記，只負責收集證據：
1. OpenClaw session 記錄
2. cron logs
3. reports 文件
4. team handoff
5. git commits
然後生成一個證據文件：
最後再讓 agent 基於這個證據寫日記。
這一步很關鍵。
以前是：你回憶一下今天發生了什麼。
現在是：這是今天的證據，請根據證據寫日記。
差別很大。
一個像憑感覺寫總結，一個像拿着會議紀要寫覆盤。
後來我順手把 5 月 4 日的日記補了一版。
補完以後，昨天真正該記錄的事情至少有這些：
AI Builders Digest 自動生成 熱點選題日報生成 X/Web 搜索 429 Grok 日報基本為 None Agent 團隊日報顯示多數員工無產出 飛書 token 多次續期成功 自動更新提交了 reports 和 handoff
這不是流水賬的日記，而是 AI 員工的工作記錄。
第二個坑：心跳巡檢燒掉了 92% 的 token
日記問題修完以後，我又看了一眼 token。
沒想到更扎心。
我讓它統計最近 7 天各個環節的 token 消耗。
結果大概是這樣：
最誇張的是心跳。
最近 7 天，心跳巡檢跑了 424 次，平均每次大概 7.4 萬 tokens。
它很多時候只是回一句：
但每次回覆之前，都要帶上一大坨上下文。
這就很坑爹。
看起來是一個很輕的動作，實際成本很重。
像你讓員工每半小時彙報一次：
「我沒事」 但每次彙報前，他都要重新讀一遍公司所有文檔、會議記錄、歷史任務，真就離譜。
我怎麼修的
今天我做了兩個止血動作。
第一個，把心跳從高頻改成低頻。
原來差不多每 30 分鐘跑一次。
現在改成：
第二個，讓心跳用輕上下文和隔離 session。
配置大概是：
`lightContext` 的意思是，心跳不要加載完整工作區上下文，只保留必要的 `HEARTBEAT.md`。
`isolatedSession` 的意思是，每次心跳不要沿用越來越長的主 session，而是用一個乾淨的小 session 跑。
OpenClaw 文檔裏也寫得很直接：隔離心跳可以把單次成本從約 100K tokens 降到 2-5K tokens。
如果這個預期成立，心跳成本會直接從黑洞變成正常後台任務。
我還加了一個 token 審計腳本：
每天 23:30 自動跑。
如果一天超過 200 萬 tokens，就發 Telegram 告警。
今天試跑了一次，結果很難看：
今日總 tokens：約 1140 萬 估算成本：約 31.43 美元 心跳佔比：99% 左右
不過這個數字主要是優化前產生的。
真正要看的是明天。
如果明天還這樣，那說明我修錯地方了。
如果明天下來，說明這次判斷是對的。
這裏面真正的教訓
表面上看，今天是在修兩個腳本。
一個日記腳本，一個 token 審計腳本。
但我覺得真正的問題不是腳本，而是自動化系統很容易產生一種幻覺：
「它在跑，所以它有用。」
不一定。
今天這兩個問題都屬於這種。
日記系統在跑，但寫出來的是廢日記。
心跳系統在跑，但燒掉的是無效 token。
自動化最危險的地方，不是它完全壞了。
完全壞了反而好發現。
最危險的是它看起來正常：
cron 有執行 log 有輸出 Telegram 有消息 文件有更新 git 有提交
但最後產出的東西對業務沒幫助。
這種才最容易温水煮青蛙。
📍今天之後，我給自己立了三條土規則。
第一，有日誌，不等於有覆盤。
覆盤至少要回答：今天完成了什麼，哪個環節失敗了，明天要改什麼。
如果日記只寫「系統正常」，那就是沒覆盤。
第二，有心跳，不等於系統健康。
心跳只能說明 agent 被喚醒過。
它不能說明自動選題有沒有價值，文章有沒有寫出來，token 有沒有超支，員工 agent 有沒有產出。
所以心跳必須輕量。
第三，所有後台任務都要算賬。
以前我更關心任務有沒有跑。
現在我會多看一個問題：
這個任務每天花多少錢？
尤其是這種後台任務。
用戶看不到，收入也不直接來自它。
如果它每天默默燒幾十美元，就算功能是對的，商業上也不一定對。
AI 員工不能只會“在崗”
今天 Agent 團隊日報也有個信號：多數員工無產出，只有增長/GTM 生成了選題。
這就提醒我，AI 員工不能只看有沒有在線。
要看有沒有交付。
一個真實員工如果每天日報寫「我在」，老闆肯定不滿意。
我自己的 OpenClaw 系統，怎麼從一個小問題查出兩個坑。
一個是日記假自動化。
一個是心跳 token 黑洞。
它不一定是最性感的熱點，但它是真的。
而且對正在搭 AI Agent 工作流的人來說，可能更有用。
因為大家遲早都會遇到類似問題：
自動化跑了，但產出質量很差 Agent 很勤奮，但成本爆了 日誌很多，但沒有人真正覆盤 工具越來越多，但系統越來越亂
說白了，AI Agent 不是裝上就完事，它更像一個員工，員工需要制度、日報、預算、驗收標準，沒有這些東西，再聰明也會變成成本中心。
不要迷信“自動運行”。
自動運行只是開始。
真正重要的是：
自動化有沒有產出？ 產出有沒有被記錄？ 成本有沒有被監控？ 出問題能不能追溯？
這四個問題答不上來，系統跑得越久，坑可能越大。
👉 關注 ai-kimi，記錄真實的AI學習和創業探索
📚 精選推薦：