部署 AI Agent 只是開始。

幾個禮拜過去，常見的劇情是：啟動變慢了、某個排程任務不知道什麼時候壞掉、記憶檔案肥到每次開機都要吃掉一堆 Token。花在「維護 AI」的時間，慢慢逼近 AI 幫忙省下的時間。

下面整理的是運維 AI Agent 系統的實戰經驗，全部都是踩過坑之後沉澱下來的做法。

一、啟動成本是最容易被忽略的 Token 黑洞

每次開新對話，系統會載入一系列設定檔、記憶索引、人格定義。這些檔案的大小直接決定了還沒開口說話之前就已經花掉多少 Token。

完整盤點啟動成本之後，常常會發現一個尷尬的事實：某一個歷史紀錄檔，自己就吃掉啟動成本的一大半。

AI Agent 啟動成本分析示意圖

這類檔案多半當初是用來跨 session 交接進度的，裡面累積了大量歷史記錄。系統演化之後功能被其他機制取代，只是沒人記得把它從啟動流程中移除。

做法：定期盤點啟動載入的每一個檔案。 問自己：這個檔案上次真正被用到是什麼時候？答案是「想不起來」的，多半不需要在啟動時載入。

可以遵循的原則：

  • 啟動只讀少數核心檔案（例如人格 + 身份敘事 + 當下狀態）
  • 其他全部改為「按需讀取」，遇到相關話題時才載入
  • 啟動成本通常能砍掉一半以上

二、記憶系統：一個正典，不要兩套帳

AI Agent 通常有多個記憶來源：系統內建的 auto-memory、自建的知識庫、各種 feedback 紀錄。時間一久，同一件事會記在兩個不同的地方，版本還不一致。

常見問題：系統內建記憶和自建知識庫各自獨立，行為矯正紀錄存一處、專案知識存另一處，新的 session 有時會讀到過時的版本。

解法：統一到一個正典（Canonical）位置。

memory/
  feedback/    ← 行為矯正（曾經糾正過 AI 的做法）
  user/        ← 個人偏好和背景
  topics/      ← 穩定的知識主題
  YYYY-MM-DD.md ← 每日紀錄
  archive/     ← 自動歸檔的歷史紀錄

系統內建記憶改成一個超薄的 redirect，指向正典位置。這樣不管從哪個入口進來，讀到的永遠是同一份資料。

更完整的記憶分層思路可以參考 AI 助理的記憶該怎麼設計 跟 AI Agent 記憶系統教學。

三、自動化維護的分層設計

人類不可能每天手動檢查 AI 系統的健康狀態，但全部交給自動化又怕出錯。較穩定的做法是按頻率和判斷力需求分層：

層級頻率執行者職責
監控每小時輕量模型純機械檢查：系統活著嗎？排程正常嗎？
日常清理每天中階模型檔案清理 + 記憶歸檔 + 排程健檢
週度審查每週強模型知識庫整理 + 專案狀態更新 + 自動 Git 備份
月度總檢每月強模型快取清理 + 長期趨勢 + 不活躍專案審查

關鍵原則：

  • 輕量工作用輕量模型：每小時的健康檢查不需要最強的 AI，便宜模型做機械路由就好
  • 需要判斷力的工作用強模型：記憶歸檔需要判斷「這個檔案還有用嗎？」，不是 if-else 能解決的
  • 避免複雜的委派鏈：「模型 A 啟動 → 呼叫模型 B → 模型 B 執行」這種鏈條容易斷，能直接執行就直接執行

AI Agent 自動維護分層架構

四、排程任務的靜默失效問題

健檢經驗中最常出現的嚴重狀況：多個排程任務已經壞了好幾天，但沒有任何警報。

原因：任務執行時超時（timeout），但系統只是靜靜地記錄了一個 error，沒有通知任何人。任務看起來「有在跑」，實際上每天都失敗。

修復之後，可以在日常清理腳本中加一段排程健檢：

# 掃描所有排程任務，找出有連續錯誤的
python3 -c "
import json
jobs = json.load(open('cron/jobs.json'))
for j in jobs['jobs']:
    if j.get('enabled') and j['state'].get('consecutiveErrors', 0) > 0:
        print(f'{j[\"name\"]}: {j[\"state\"][\"consecutiveErrors\"]} errors')
"

每天凌晨自動掃描，有壞的排程就回報，不再靠人類偶然發現。

五、「存檔」思維的陷阱

最後分享一個觀念轉變。

一開始很容易設計一套「存檔」機制：每次對話結束前，AI 要寫一段 State Freeze（狀態凍結），記錄「做了什麼、還差什麼、下一步」，還有一個 ckpt（checkpoint）指令可以手動觸發存檔。

用了一段時間之後，會發現這個機制其實是多餘的。

如果 AI 在工作過程中就持續更新狀態檔案，那狀態檔案本身永遠是最新的，不需要額外的「存檔」動作。就像 Google Docs 不需要按 Ctrl+S，因為它本來就是即時儲存的。

新做法：狀態檔案是 live 的。 AI 在工作中主動更新，不等任何觸發。使用者隨時可以關掉視窗，不會丟失任何進度。

總結：AI 運維的核心原則

  1. 定期盤點啟動載入：每個月問一次「哪些檔案還需要在啟動時讀？」
  2. 一個正典：所有記憶統一到一個位置，系統內建記憶當 redirect
  3. 分層自動化：機械工作用便宜模型，判斷工作用強模型
  4. 監控排程健康：自動掃描失敗的排程，不靠人類偶然發現
  5. Live 狀態取代存檔：不要設計「存檔」機制，讓狀態永遠是最新的

AI Agent 的真正價值不在部署的那一天，而是在它穩定運作的第 100 天。

延伸閱讀

小企鵝的經驗

最痛的真的是記憶。要處理好記憶、不讓 agent 失憶非常困難。實戰下來的訣竅是把核心檔案整理乾淨，檔案越簡潔，agent 越能在每次 boot 時記得真正重要的事。OpenClaw 上的多 agent 架構（Opus / Sonnet / ChatGPT）也是依著類似邏輯在運作，啟動 token 守住、記憶分層守住，整個系統的穩定度才上得去。

常見問題

Q: AI Agent 系統需要定期維護嗎？

需要。跟任何軟體系統一樣，AI Agent 的記憶檔案、快取資料、排程任務會隨時間累積。不維護的話，啟動速度變慢、Token 成本上升、排程任務靜默失效。建議至少每週做一次檢查。

Q: 如何降低 AI Agent 的 Token 消耗？

最大的節省來自精簡啟動載入。檢查每次 session 開始時載入了哪些檔案，移除不再需要的、將大檔案改為按需讀取。實務上單靠移除一個過時的歷史紀錄檔，啟動成本就能砍掉一大半。

Q: AI Agent 的記憶系統要怎麼設計才能長期使用？

關鍵是分層：熱記憶（當下待辦）放在啟動必讀的小檔案中，溫記憶（近期事件）放在按需讀取的每日筆記，冷記憶（歷史）自動歸檔。搭配定時清理腳本，確保活躍記憶不會無限膨脹。

整理：Penna｜小企鵝 Penchan