08：什麼任務該派 AI Agent？從 DarkMeow 架構學到的決策框架
這是 Nerigate Build Log 系列的第八篇。前幾篇記錄了搬家和本地 LLM 實測——這篇開始談架構設計。
「AI Agent 可以幫我做所有事嗎？」
技術上，可以嘗試。實際上，你不應該這樣做。
我在過去幾個月裡建立並維護了一套雙 Agent 系統（DarkMeow 負責分析規劃、MeowClaw 負責搜尋執行），期間犯過不少錯誤，也慢慢摸出一套判斷邏輯：什麼任務適合 Agent，什麼不適合。
這篇把那套判斷邏輯整理成一個可以直接用的框架。
先釐清三個不同的東西
很多人在談「AI Agent」的時候，其實混在一起說了三種不同的東西：
Workflow 自動化：固定步驟、固定輸出。每次執行都走同一條路。典型例子：n8n 收到 webhook → 轉存資料庫 → 發送通知。
AI 增強 Workflow：固定骨架，但某些步驟加入 LLM 判斷。例如：收到 email → LLM 判斷分類 → 根據分類走不同路徑。
AI Agent：目標驅動。給它一個目標，讓它自己決定要採取哪些步驟。可以使用工具、搜尋資料、呼叫 API、甚至派發子任務。
三種東西，差很遠：
| Workflow | AI 增強 Workflow | Agent | |
|---|---|---|---|
| 成本 | 低 | 中 | 高 |
| 速度 | 快 | 中 | 慢 |
| 可預測性 | 高 | 中 | 低 |
| 適合場景 | 固定規則任務 | 需要判斷的流程 | 開放性目標 |
把所有事情都交給 Agent，然後抱怨它太慢、太貴、做出奇怪的決定——這是最常見的誤區。
我的決策框架：四個問題
面對一個任務，我會問自己四個問題：
問題一：步驟是固定的嗎？
如果每次執行的步驟都一樣，直接用 Workflow——n8n、cron job、或是簡單的 shell script 就夠了。
例子：每天早上 8 點抓 Yahoo 股市數據 → 存資料庫。這個任務步驟完全固定，完全不需要 AI。
問題二：需要「判斷」嗎？
步驟中有某個環節需要根據上下文決定——分類、摘要、優先級評估——就考慮「AI 增強 Workflow」。固定骨架，只在關鍵節點插入 LLM。
例子：收到 Discord 訊息 → LLM 判斷是否需要回應 → 是的話進入回應流程。
問題三：目標是開放性的嗎？
給的是目標、不是步驟清單——才真正需要 Agent。
例子：「研究 Proxmox 和 ESXi 的差異，給我比較報告。」搜尋、閱讀、整理、判斷，步驟事先不確定。這才是 Agent 的場景。
問題四：失敗的代價有多高？
Agent 會犯錯。如果犯錯的代價很高（影響客戶、刪除資料、發出對外通訊），需要謹慎設計確認機制，或者改用人工介入。
如果犯錯沒什麼大不了（草稿寫錯可以重寫），可以讓 Agent 試著做。
在 DarkMeow 系統裡的實際分配
根據這個框架，我現在的任務分配大概是這樣：
純 Workflow（n8n / cron）：
- 每日股市數據抓取
- GitHub 備份（每天凌晨 2 點）
- 版本更新檢查（每天上午 10 點）
- 狀態監控、資料庫寫入
AI 增強 Workflow：
- Discord 訊息分類與路由
- 電子報摘要與重要性判斷
- 任務優先級排序
Agent（DarkMeow / MeowClaw）：
- 研究任務（搜尋 + 整理 + 分析）
- 文件撰寫（草稿、Blog 文章）
- 需要多步驟協作的複雜任務
- 任何「目標明確但路徑不確定」的工作
人工處理：
- 對外客戶溝通（最終確認）
- 不可逆的重要操作（生產環境部署、資料刪除）
- 需要創意判斷的設計決策
80/20 法則：最終建議
一個實際有效的設計原則是：80% Workflow，20% Agent。
讓確定性流程走固定路徑，保持速度和可預測性。把 Agent 能力留給真正需要推論和判斷的那 20%。
這樣的系統跑起來穩，成本也可控。
反過來——如果你的系統 80% 是 Agent，你大概會發現它跑得很慢、費用很高、而且時常做出你沒預期到的事。
不是 Agent 不好，是工具要用對地方。
這是 Nerigate Build Log 系列的第八篇。
← 上一篇：07：本地 LLM 不等於免費，Crow-9B 實測
下一篇：09：把 AI 當成真正的團隊成員 →
