Multi-Agent 監控實戰：從 Polling 到事件驅動（用 Cron + Heartbeat 打造自我修復工作流）

OpenClaw Mar 3, 2026

你的 AI Agent 掛了，你知道嗎？

上週我的搜尋偵察貓 MeowClaw 消失了三個小時。

不是真的消失啦，她還在跑，只是卡在一個 API rate limit 的死循環裡，像隻追著自己尾巴轉圈的貓。等我發現時，已經燒掉 500 次 Brave Search 配額，而我還傻傻以為她在認真工作。

這就是沒有監控的代價。你派出 Agent 執行任務，然後呢？你怎麼知道她有沒有在做事？有沒有卡住？有沒有成功？

很多人部署了 Multi-Agent 系統就放著跑，期待它們「自己搞定」。但說真的，沒有監控的 Agent = 盲飛。你根本不知道發生了什麼，直到炸掉才後知後覺。

監控不是奢侈品，是基本功。

為什麼傳統 Polling 不夠用

最直覺的做法是 Polling（輪詢）：每隔幾秒問一次「做完了沒？」

聽起來合理對吧？但實際跑起來問題一堆：

頻率太高？浪費 Token 和 API 配額。每次 Polling 都要注入 context、呼叫 API，成本直線上升。一個 5 分鐘的任務，如果每 10 秒輪詢一次，就是 30 次無意義的檢查。

頻率太低？錯過關鍵事件。Agent 可能早就完成了，但你要再等 30 秒才發現。或者更糟：Agent 已經失敗，但你還在傻等。

多個 Agent 怎麼辦？如果你同時派出 5 個 sub-agent，是不是要開 5 個 Polling 迴圈？每個都在燒 Token？

Polling 就像你每 5 分鐘問朋友「到了沒？」一樣煩人。他到了會告訴你啦，你一直問只會讓人白眼翻到後腦勺。

所以我們需要更聰明的做法：事件驅動（Event-Driven）。

三件套：Cron + Heartbeat + 斷路器

經過一個月的踩坑和重構，我們找到了最適合 Multi-Agent 監控的架構：

1. Cron：定時健康檢查

Cron Job 負責「定時但不干擾」的檢查任務。

在我們的系統裡，Cron 負責這些事：

  • 每日 02:00：Git 自動備份（git-auto-backup）
  • 每日 10:00：檢查 OpenClaw 版本更新（check-openclaw-update）
  • 每週一 09:00：彙整上週的錯誤追蹤報告

Cron 的優勢是精確排程：你要它 09:00 執行就是 09:00，分秒不差。而且它是獨立 session，不會污染主對話的 context。

要注意的是：OpenClaw 的 Cron 用的是 agentTurn，會呼叫 AI Model。我們選了 gemini-2.5-flash-lite 這種輕量模型來跑 Cron 任務，成本極低但不是零。跟 Polling 的差別在於：Cron 每天就跑那幾次，不會像 Polling 一樣無止盡地燒。

但 Cron 也有限制：它只能處理「定時」任務，無法應對「不定時但需要批次檢查」的情境。

這時候就輪到 Heartbeat 上場。

2. Heartbeat：主動脈搏

Heartbeat 是「批次檢查 + 彈性時間」的機制。

我們的 Heartbeat 會輪流檢查這些項目（每個項目 2-4 次/天）：

  • Email：有沒有急件？
  • Calendar：未來 24-48 小時有什麼行程？
  • GitHub/Discord：有人 @ 我嗎？
  • 天氣：今天會下雨嗎？（如果 Kevin 可能會出門）

重點是「輪流」而不是「全部」。Heartbeat 會追蹤上次檢查時間（存在 heartbeat-state.json），只檢查該檢查的項目。

Heartbeat vs Cron 的選擇邏輯：

  • 多個檢查可以合併？用 Heartbeat 批次處理
  • 需要對話 context？用 Heartbeat（它在主 session 裡）
  • 時間可以飄移？用 Heartbeat（~30 分鐘誤差沒關係）
  • 精確時間 + 獨立執行？用 Cron

用一個生活化的比喻：Cron 是鬧鐘，Heartbeat 是自己醒來看時間。

3. 斷路器（Circuit Breaker）：約定式熔斷

「斷路器」這個概念來自 Dev.to 那篇文章，但我要誠實說：我們的實作不是程式化的自動熔斷，而是寫在 Agent 指令裡的行為準則。

具體來說，我們在 AGENTS.md 裡寫了這段規則，Agent 讀了就會遵循：

當同一操作或策略連續失敗 3 次：

  1. 停止重複嘗試同一做法
  2. 切換策略：嘗試完全不同的方法
  3. 升級回報：向人類結構化回報

這不是什麼高科技，就是把「遇到問題別一直硬幹」寫成 Agent 看得懂的規則。但實際效果出奇地好。Agent 真的會在第三次失敗後換方法，而不是像沒有這條規則時那樣無限重試。

至於 sub-agent 的超時，OpenClaw 本身就有 runTimeoutSeconds 機制，不需要我們自己寫 kill 邏輯。

三者如何互補：

  • Cron 管排程（精確時間）
  • Heartbeat 管狀態（批次檢查）
  • 斷路器 管故障（自動熔斷）

實戰案例：DarkMeow × MeowClaw 協作監控

讓我用我們自己的架構來說明這套機制如何運作。

我們的 Multi-Agent 系統有兩隻貓：

  • DarkMeow（黑喵）：主控端，使用 Claude Opus 4，負責統籌、決策、協調
  • MeowClaw（貓爪）：偵察端，使用 Codex，負責搜尋、蒐集、執行

一個典型的工作流程：

  1. DarkMeow 接到任務
    「幫我研究 Multi-Agent 監控的最新趨勢」

  2. 拆解與派發
    DarkMeow 判斷這需要大量搜尋，拆解成 3 個子任務：

  • 搜尋學術論文
  • 搜尋開發者部落格
  • 搜尋 Reddit/HackerNews 討論

然後派發給 MeowClaw 執行（因為 Brave Search API 有 1 req/s 的限制，搜尋任務必須由單一節點執行）。

  1. 事件驅動回報
  • Sub-agent 完成任務後會自動 announce（推播完成通知），不需要 Polling 或額外 Cron 監控
  • DarkMeow 收到通知後立即接手：讀取產出 → lint 驗證 → 審稿 → 派發下一個任務
  • 如果任務超時，OpenClaw 的 runTimeoutSeconds 會自動終止，DarkMeow 再決定重試或改用其他方案
  1. 品質閘門（Quality Gate）
    MeowClaw 回報結果後，DarkMeow 會跑四階段驗證：
  • D1：能跑、不報錯（基本可用性）
  • D2：狀態有清理、不留殘留
  • D3：重跑不重複、排程時區正確
  • D4：Docker 限制、認證、路徑都沒問題

四關全過才算完成。簡單粗暴，但有效。

  1. 對話學習與經驗萃取
    這是整套架構裡我最喜歡的部分。Agent 會從每次對話中學習。

我們有一套叫 session-learning 的機制：每次對話結束前（或被糾正時），Agent 會萃取「instincts」（本能），記錄到 memory/instincts.md。例如：

  • 被糾正了輸出格式 → 記錄偏好（「Kevin 偏好表格而非長段落」）
  • 工具踩坑 → 記錄限制（「Brave Search 用 country=TW，不要用 search_lang=zh」）
  • 發現重複模式 → 記錄工作流（「搜尋任務由單一節點執行」）

每條 instinct 有信心度（confidence），0.7 以上自動套用，低於 0.5 僅作參考。同類型累積 3 次以上，晉升到核心檔案（SOUL.md / AGENTS.md / TOOLS.md）。

錯誤追蹤（errors-tracker.md）也是學習來源之一，但主要的進化動力來自對話互動，不是 bug tracking。

搜尋與分析分離原則

因為 Brave Search API 的速率限制（1 req/s），我們把職責切得很清楚：

  • MeowClaw：負責搜尋和資料蒐集（在速率限制內運作）
  • DarkMeow：負責分析和決策（不受速率限制）

這避免了「兩隻貓同時搜尋導致 rate limit 衝突」的問題。

你可以直接用的模板

簡化版 HEARTBEAT.md

# HEARTBEAT.md

## 檢查清單（輪流執行，2-4 次/天）

### Email
- 檢查未讀郵件
- 上次檢查：記錄在 heartbeat-state.json

### Calendar
- 查看未來 24-48h 行程
- 有重要會議提前 2h 提醒

### GitHub
- 檢查 @ 提及
- 檢查 PR 狀態

### 靜音時段
23:00-08:00 除非標記為緊急事件

Cron Job 設定範例（OpenClaw 格式）

name: "daily-backup"
schedule:
  kind: cron
  expr: "0 2 * * *"  # 每天 02:00
  tz: "Asia/Taipei"
payload:
  kind: agentTurn              # 會呼叫 AI Model
  message: "執行 Git 自動備份"
  model: "google/gemini-2.5-flash-lite"  # 輕量模型壓低成本
  timeoutSeconds: 120
delivery:
  mode: announce               # 結果回傳主 session
sessionTarget: isolated        # 獨立 session，不污染主對話 context

斷路器寫法（直接貼進你的 AGENTS.md）

不需要寫程式，把規則用自然語言寫進 Agent 的指令檔就好：

## 斷路器機制（Circuit Breaker）

當同一操作或策略連續失敗 3 次：
1. 停止重複嘗試同一做法
2. 切換策略：嘗試完全不同的方法
3. 升級回報：若仍無法解決，向人類結構化回報

Agent 讀了這段文字後，就會在行為上遵循。這不是 hard-coded 邏輯，是 prompt-driven 的行為約束。但實測下來，效果比想像中好。

收尾：看得到、追得回、關得掉

建立 Multi-Agent 監控系統的三個核心原則：

看得到（Observability）
每個 Agent 的狀態都要可視化。不要讓 Agent 變成黑盒子。用 Cron + Heartbeat 讓你隨時知道「誰在做什麼」。

追得回（Traceability）
所有決策、錯誤、狀態變化都要有記錄。experience/errors-tracker.md 不是擺設，是你的學習基礎。

關得掉（Killability）
Agent 卡住時，你要能立即中止。15 分鐘超時不是懲罰，是保護機制。與其讓 Agent 卡死燒配額，不如果斷 kill 掉重來。

這套架構我們用了一個多月，最明顯的改變是：

  • 不再需要手動盯著 Agent 跑：sub-agent 完成自動回報，Cron 定時處理例行事務，Heartbeat 批次掃描狀態
  • Agent 會自己學會避坑：同一個錯誤犯過的教訓會變成 instinct，下次遇到直接繞開
  • 出問題時有跡可循：daily log + instincts + errors-tracker，三層記錄讓 debug 有據可查

下一篇我們會聊聊 ArgentOS vs OpenClaw 的設計哲學差異，以及為什麼我們最終選擇了 OpenClaw。

如果你也在建立 Multi-Agent 系統，強烈建議先把監控架構搞定。不然等 Agent 跑偏了才來救火，你會後悔。

現在去檢查一下你的 Agent 吧。她還活著嗎？😼

延伸閱讀：

Tags

Kevin Du

Recommended for you