我也走過那段「打造完美 agent 架構」的彎路
昨天在 Reddit 看到一篇文章，作者分享他把 OpenClaw 搞成多 agent 架構的過程，看到一半我就笑出來了，因為那根本就是在講我自己。
他的設計是一個主控 Alfred + 一堆專家 agent：coder_agent、email_agent、notion_agent。每個 agent 各守一塊，分工明確。我當初也搞過類似的，而且還更誇張，我把家裡的 NAS 監控、股票 watchlist、每日新聞摘要全部都拆成獨立 agent，一個主 agent 在上面統籌。
聽起來很爽，對吧。
但實際上大概有三分之二的時間都在 debug 「為什麼主 agent 沒把任務傳給對的 agent」「為什麼 email_agent 這次沒被叫醒」之類的問題。那段時間我不是在享受自動化帶來的好處，我是在維護一個比我原本的生活更複雜的系統。
作者最後也說，他在第五次重建之後，終於回到了一個 agent。
我比他快一點，第三次就放棄了😂
現在我的架構超簡單：一個主 agent 跑在 Telegram，負責跟我互動。所有定期的任務，例如早上的新聞摘要、盤前股票掃描、NAS 健檢，全部都用 cron 起獨立 session 跑，跑完推通知給我就好。主 agent 完全不需要管這些事，它就是一個隨時能跟我對話的人。
這個拆法其實有個很直覺的邏輯：對話需要即時回應，排程任務需要可靠執行，這兩件事的需求根本不一樣，為什麼要塞在同一個 agent 裡搞得彼此干擾？
而且 cron session 失敗了很好查，日誌乾淨，重跑容易。主 agent 的 context 不會被一堆背景任務的輸出污染，對話品質也變好很多。
突然想到，其實這就像後端開發的概念——你不會把定時任務跑在你的 web server 的主 thread 裡，你會開 worker，對吧。agent 架構也一樣。
給剛開始玩 OpenClaw 的人：真的先從一個 agent 開始。等你覺得「欸這個任務每次都要我手動觸發好麻煩」的時候，再把它搬到 cron。不要一開始就想設計一個完美的分散式 agent 系統，那條路我走過，終點還是回到原點。
作者：Hector19