前言：從一個助手走到一套系統

這 30 天，我用 ZoneTech 的實際營運問題，記錄如何把開源 Agent 框架 Hermes 接進一家 IT 委外公司。起點不是做一個聊天機器人，而是面對一組每天都會發生、又不能只靠某一個人記得的工作：財務要對帳、社群要追蹤、客戶要跟進、網站要觀察，工程交接還要留下證據。

最後形成的不是一個「什麼都會」的 Bot，而是一套有角色、有權限、有資料邊界、有排程，也有驗證閉環的機器人同事系統。

30 天的成果總覽

第一階段是把單一 Agent 打穩。模型路由、訊息平台、記憶、SOUL.md／USER.md，以及 Primary／Fallback，解決的是「它能不能穩定工作」的問題。

第二階段是把知識整理成可查詢、可維護的 Company Brain。Hermes 記憶、Wiki、Obsidian Vault 與 QMD 各有邊界；其中 Markdown 是原始資料，QMD 是衍生索引，不能把兩者當成兩套可以各自編輯的知識庫。

第三階段是讓工作自動發生。Cron 把財務日報、社群雷達、網站追蹤與認證檢查變成固定交付；但每一個自動化都必須有資料來源、失敗處理和輸出驗證。

第四階段是拆成多個部門 Bot。Profile 隔離、multiplex gateway、群組授權與 bot-to-bot 交接，讓不同角色可以各自擁有最小必要權限，而不是把公司所有資料塞進同一個上下文。

成本、品質與可維護性的取捨

模型不是越貴越好，也不是越便宜越划算。高頻、固定格式的任務，可以交給成本較低的模型；跨來源推理、長文與制度設計，才值得使用品質較高的模型。真正需要管理的不是單次 token 價格，而是錯誤重跑、人工覆核、資料外洩與錯誤決策的總成本。

我的分工原則是：機械收集先用腳本或 no_agent；需要固定格式的歸納使用 Luna；長文、文件和跨來源分析使用 Sol。Primary／Fallback 則要明確定義順序、身份去重與停止條件，避免主模型失效時，系統表面上繼續跑，實際上卻產出不一致的結果。

一人公司或小團隊的 10 步導入地圖

1. 先列出每天重複、可驗證的工作，不要從「做一個萬能 AI」開始。
2. 為每項工作寫清楚輸入、輸出、owner 和完成證據。
3. 先選一個低風險流程做端到端實驗。
4. 建立模型分工與成本上限，替每個任務指定適合的模型。
5. 把穩定的偏好與規則分開放進記憶、USER 文件或 Skill。
6. 建立單一原始知識庫，保留來源與更新時間。
7. 將腳本收集、模型歸納和對外發送拆成不同步驟。
8. 對帳、發布、權限與外部寫入都加入讀回驗證。
9. 再把不同角色拆成 Profile 或部門 Bot，設定最小權限。
10. 每次失敗都記錄根因，將可重複的解法沉澱成 Skill 或 SOP。

哪些事情還沒有「完成」

工程系統可以運作，不代表制度全部定案。LINE 的部分權限邊界、顧問 KPI，以及跨部門責任仍需要經營者核准；這些不能因為 Agent 已經能執行，就直接寫成正式規則。

同樣地，外部發送成功不等於客戶已經看到，exit code 0 也不等於任務完成。我的完成標準一直是三段式：本機變更確實存在、服務或排程確實載入、外部效果能被讀回確認。少了其中一段，就只能稱為草稿或部分完成。

結語：先做一個可驗證的閉環

導入 Agent 最容易犯的錯，是先追求功能數量，卻沒有定義失敗時誰負責。比較穩健的路徑，是從一個真實工作開始，建立資料邊界、模型選擇、執行紀錄和驗證方式，再逐步複製到其他流程。

對 ZoneTech 來說，這條路最後指向 AI 維運訂閱制：不是把一個模型包裝成服務，而是把可觀測、可交接、可持續改善的營運流程，做成企業可以長期使用的系統。

30 天系列的終點，不是「AI 已經取代所有人」，而是我們終於知道哪些工作適合交給機器人、哪些決策仍要由人核准，以及如何用證據確認兩者真的協作完成。