這篇要分享的是參考 Hermes Agent 的關鍵設計邏輯，重新蓋一套地端小模型可以跑的輕量 Agent 框架，技術棧選的是 Ollama（ornith-1.5:9b） 當地端推論引擎，搭配 LangChain Deep Agents 當作 Agent 的骨架。一樣先不談怎麼實作，任務只有一個 — 把架構圖攤開來，一格一格講清楚它在做什麼。

整體框架設計

左邊是「Agent layer（代理層）」，右邊是「Harness units layer（執行單元層）」，右下角寫著「Mini Hermes」— 沒錯，這就是把 Hermes Agent 的核心蒸餾出來，做成一個可以自己實作的簡化版框架。

整個框架的流程概念可用幾個步驟講完：

1. 使用者丟一句話進來
2. 主代理決定要用哪個技能
3. 交給對應的執行單元做事
4. 每個執行單元做完都要被審查
5. 審查沒過或拿不定主意就找人
6. 最後彙整成一份輸出
7. 這次執行的結果會回頭讓主代理下次反應更快更準

把設計拆開來看，一格一格講

Agent layer

Main Agent（with channels），圖上的黃色方塊，是直接面對使用者的角色。「with channels」代表 Main Agent 本身不綁定任何特定的溝通介面 — 不管使用者是從 CLI 打字進來、從網頁表單送出去、還是從 Telegram 丟訊息過來，對 Main Agent 來說都是同一種「請求」。Channel 只是接口，真正的判斷邏輯只有一份，這樣以後想加一個新的入口（比如 Line、Discord），不用重寫整套 Agent 邏輯，只要多接一個 channel adapter 就好。

Main Agent 收到請求之後，不會自己硬做，而是丟給下一格 — Skill Select。

Skill Select，這格的角色類似「總機」或「分診台」。它要判斷這句話到底屬於哪一類任務，然後決定要往右邊哪一個（或哪幾個）執行單元送。

Harness units layer：真正幹活的地方

Skill Select 判斷完之後，會用藍色箭頭把任務發到右邊三種（或更多，圖上用「⋯」表示可以無限擴充）執行單元：

• OOO workflow：多步驟、有前後順序的流程型任務。比如「幫我查資料、整理、然後寫成報告」這種需要串好幾步的工作。

• OOO tool：單一目的的工具呼叫。比如查天氣、算匯率、讀一個檔案，這種一次呼叫就有結果的動作。

• OOO utility：輔助性質的小工具，通常是給前兩者用的底層能力，不太會被使用者直接點名要用。

這裡刻意用「OOO」當前綴，是因為每一種類別底下實際上會有很多個具體的實作（很多個 workflow、很多個 tool），圖上畫三格加點點，代表這是一個可以持續擴充的元件，不是只寫死三個東西。

每一格執行單元旁邊都黏著一個紫色的 Review。這不是可有可無的裝飾 — 每一個執行單元的輸出，在往下一步走之前，一定要先過審查。

Human function（若需要）：人不是預設步驟，而是保險絲

三個 Review 的輸出，最後都匯流到藍色的 Human function（if needed）。注意這格名字裡特別寫了「if needed」— 人力介入是例外路徑，不是常態路徑。也就是說，只有當 Review 判斷「這個我拿不準」或「這個風險太高不能自動放行」的時候，才會真的把工作丟給人。

值得注意的是圖上那條從 OOO workflow 頂端繞出去、經過「Feedback loop（if needed）」再進到 Human function 的線 —— 這代表人工介入之後，結果是可以再回頭進入 workflow 重跑一次的，不是人看完就結束了。這是一個「單次任務內」的小迴圈：

審查沒過 → 找人 → 人給意見 → 重新執行 → 再審查

Final Output 與底部的大迴圈

所有執行單元（不管有沒有經過人工介入）最終都會往下彙整到 Final Output。這格代表這次任務，不管中間繞了幾層審查、有沒有人插手，最後都要收斂成一個結果丟回去。

而真正有意思的是 Final Output 之後接的那個黃色框：Feedback loop：gets faster and more accurate over time。這條線繞了一大圈，從 Final Output 一路連回最一開始的 Main Agent。

這跟前面 Human function 那個「if needed」的小迴圈不一樣，這是跨任務的學習迴圈 —— 每完成一次任務，系統要把這次的經驗（不管是 Skill Select 的判斷對不對、Review 抓到了什麼問題、人工介入時給了什麼修正）沉澱下來，讓下一次遇到類似的請求時，Main Agent 判斷更快、Skill Select 選得更準。

這兩個迴圈疊在一起，就是整張圖真正的核心精神：單次任務靠審查跟人力兜底品質，跨任務靠回饋機制讓系統本身變聰明。

對照 Hermes Agent 的幾個面向，想想要怎麼做

大致抓出在 Hermes Agent 幾個值得拆解的設計面向：

Channel（溝通管道）

對應圖上 Main Agent（with channels）。設計上的重點是「讓核心邏輯跟輸入輸出介面脫鉤」。自研 Agent 打算用 LangChain Deep Agents 當骨架，核心就是同一個 agent graph，外面隨便接：可以是本機 CLI 拿來測試，也可以包一層簡單的 Web UI。Channel 這層要做的事情很單純 — 把不同來源的訊息，轉成統一格式丟進 Main Agent，回覆的時候再轉回去。

Memory（記憶）

圖上沒有畫出獨立的「Memory」方塊，但它其實藏在底部那個「越用越快越準」的 Feedback loop 裡。沒有記憶，這條迴圈就是空話 — 系統要嘛得把每次的請求 / 選用的技能 / 審查結果 / 人工修正 存下來，下次才有東西可以「學」。

這裡打算分兩層發想：

• 短期記憶：同一個對話 Session 裡的上下文，讓 Skill Select 判斷的時候不會失憶。

• 長期記憶：跨對話 Session、跨任務累積下來的經驗，用來讓 Main Agent 跟 Skill Select 的判斷隨時間變準。

地端模型跑的話，長期記憶大概率會落在一個本機資料庫，或乾脆是結構化的紀錄檔（例如：Memory.md）。

Planning and Execution（規劃與執行）

對應 Skill Select 加上右邊整個 Harness units layer。Skill Select 負責「規劃」— 決定這個請求該拆成什麼任務、丟給誰；真正的「執行」則發生在 workflow / tool / utility 裡面。

這裡想借鏡 LangChain Deep Agents 本身就有的概念：用一個顯式的計畫（類似 todo list）把多步驟任務拆開來，而不是讓模型每次都憑感覺一步步硬幹。規劃跟執行分開想，除錯的時候也比較好定位問題到底出在「判斷錯了要做什麼」還是「做的過程出錯」。

Skill / Tool Using（技能與工具使用）

對應 OOO workflow / tool / utility 這三大類本身。設計上刻意把它們分成三種顆粒度，而不是全部混在一起叫「tool」，是因為它們的使用時機跟複雜度真的不一樣：

之後實作的時候，這一層就是 Skill 註冊表的概念 — 每加一個新能力，先想清楚它屬於哪一類，再決定要不要幫它另外掛一個獨立的 Review 邏輯。

Workspace（工作區隔離）

這也是選 LangChain Deep Agents 實作的原因之一，它本身就有 workspace 的概念，可以讓 Harness unit 在自己的工作區裡讀寫，不影響系統環境，執行完再把結果收斂回主流程。

小結

這篇把整張架構圖一格一格對過一遍，其實已經把接下來要開發的東西定義得差不多了：

• Main Agent 要做成 channel-agnostic 的入口
• Skill Select 負責路由，Harness units 負責執行
• 每個執行單元的輸出都要過 Review，過不了才找人
• Skill / Tool 要按照顆粒度分類管理