（系列：《AI 維運實戰：我用 Hermes 把 Agent 變成企業同事的 30 天》）
（主題：將 AI 模型整合進實際系統與產品的工程實踐）

Agent 接上 Telegram 後，下一個直覺是：把最強的模型設成預設值，答案應該就會最好。

我實際跑過排程、雷達、文件整理與跨來源分析後，發現這個想法只對一半。模型越強，通常越能處理模糊問題；但企業每天大量出現的工作，根本不需要每次都動用最高推理能力。

真正該問的不是「哪個模型最強」，而是「這份工作最低需要什麼能力」。

────────────────────────────────

單一模型的問題，不只是不省錢

早期使用單一模型很方便。Gateway、排程與臨時對話全部走同一條路，設定簡單，故障也容易追。

但任務增加後，差異立刻出現：

• 抓 API、讀 JSON、搬運資料，是機械工作。
• 把固定欄位整理成日報，需要穩定格式。
• 比對多份文件、找矛盾、設計制度，需要長上下文與推理。
• 修改正式流程，還要理解權限、風險與驗收邊界。

如果全部交給高階模型，簡單任務也會消耗同樣昂貴的推理資源。反過來，若為了省成本全部交給快速模型，跨來源工作常會得到「每段都像對的，合起來卻沒做出判斷」的報告。

這不是模型好壞，而是派工錯誤。

────────────────────────────────

我最後採用的三層分工

我的配置從單一模型，逐步拆成 DeepSeek Flash、GPT-5.6 Luna 與 GPT-5.6 Sol。分工不是按照品牌，而是依工作特性。

最後一列最重要。模型路由不只是「選哪個模型」，也包含「這一步是否需要模型」。能用程式精確完成的工作，就不要請模型猜。

例如社群雷達，我不讓高階模型從頭操作所有抓取。先由腳本收集原始 JSON，再交給模型做分類與歸納。這樣可以把非確定性的範圍縮小，也能保留原始資料供驗證。

────────────────────────────────

真實排程如何落地

目前我的 Hermes 排程裡，大量固定格式工作使用 openai-codex Provider 的 GPT-5.6 Luna。需要把 X 與 GitHub 多來源資料整理成技術、產品與商機判斷時，才會呼叫 GPT-5.6 Sol。部分已有乾淨 raw data 的摘要流程，則保留 DeepSeek Flash 作為快速統整或備援。

這裡有一個工程細節：模型必須綁在工作上，不能只寫在人的習慣裡。

每個 cron job 都應明確指定 model 與 provider。否則更改全域預設值後，原本設計給快速模型的高頻任務，可能悄悄改走高階模型；或者重要分析突然降級，表面仍成功，品質卻已改變。

模型名稱也不能脫離 Provider。相同名稱經不同入口呼叫，認證方式、上下文限制與可用狀態可能不同。我的路由表因此同時記錄任務、model、provider，而不是只記一個暱稱。

────────────────────────────────

我踩過的兩個判斷錯誤

第一個錯誤，是把「便宜」等同於「划算」。

如果快速模型產出的報告缺少關鍵關聯，最後還要人工重讀、重寫，總成本其實更高。尤其是公司制度、跨部門責任與多來源研究，錯誤不是文筆不好，而是可能做出錯誤決策。

第二個錯誤，是把「高階」等同於「所有工作都更可靠」。

財務欄位加總、檔案數量與重複資料判定，不該依賴模型能力。這些工作需要的是確定性與可重跑。正確作法是先用程式計算，再讓模型解釋結果；不能讓模型一邊讀、一邊心算、一邊生成結論。

────────────────────────────────

我的驗收方式

我不只看回覆是否流暢，而是看四件事：

1. 任務是否使用指定的 model 與 provider。
2. 固定格式是否完整，欄位有沒有漏。
3. 結論能否回指原始資料，而不是只有漂亮摘要。
4. 失敗時能否降級，且不把低品質結果冒充正式交付。

目前本機設定與排程紀錄可以讀到 Luna、Sol 與 DeepSeek Flash 的實際分工。這比口頭說「我們有模型路由」更有意義，因為派工規則已經落在可檢查的設定裡。

────────────────────────────────

今天的結論

企業導入 Agent，模型成本不是靠全面降級來控制，而是靠工作分級。

高頻、固定、低風險的工作，用快速模型。跨來源、長文件與高風險決策，用高階模型。純計算與搬運，乾脆不用模型。

最划算的模型，不是排行榜第一名，而是能以最低整體成本，穩定通過該任務驗收的那一個。

下一篇 D5：模型會工作之後，下一個問題是它能不能記住人與規則。我會拆開 MEMORY.md 與 USER.md，談什麼該記、什麼該忘，以及雜訊記憶如何讓 Agent 越用越笨。