深入 Hermes：代理迴圈、上下文、記憶、閘道與 Cron 任務如何協同運作

一份關於永遠線上的 Hermes 代理背後架構的概念指南。

當你在心中將 Hermes 的內部元件分開時，操作它就會變得更容易。一個請求並非直接從 Telegram 傳送到模型再返回。它會經過一個閘道、被關聯到一個工作階段、組裝成上下文、由代理迴圈處理，然後儲存供日後使用。排程任務則透過不同的入口進入同一個系統。

這個架構很簡單，不需要閱讀程式碼就能理解，但理解它會改變問題的診斷方式。一個糟糕的答案可能是模型問題、上下文問題或記憶問題。一則遺失的訊息可能是閘道或工作階段問題。一個重複的排程結果可能是 cron 的設計問題。

鳥瞰視角

中心是代理迴圈。圍繞它的是四個支援系統：

• 上下文建構決定模型現在能看到哪些資訊。
• 工作階段與閘道管理將訊息連接到正確的對話。
• 記憶在活動上下文之外保存選定的知識。
• Cron 排程在沒有即時使用者訊息的情況下，在定義的時間建立工作。

持久性記錄（通常儲存在 SQLite 等資料庫中）將這些元件在重新啟動後連接起來。

代理迴圈

代理迴圈是 Hermes 處理任務的循環。它接收一條訊息和已組裝的上下文，呼叫模型，檢查結果，並可能呼叫一個工具。工具結果被加入到工作上下文中，然後再次呼叫模型。這個過程會持續，直到模型產出最終答案，或者安全與迭代限制終止了這個迴圈。

簡化的順序如下：

1. 接收一個事件或訊息。
2. 識別工作階段和使用者。
3. 建構模型上下文。
4. 要求模型採取下一步行動。
5. 如果請求了，則執行一個允許的工具。
6. 將結果加入上下文。
7. 重複直到任務完成。
8. 儲存回應和相關狀態。

這說明了為什麼基於工具的任務比單一答案消耗更多的 Token。每次工具呼叫都可能產生另一輪模型回合，其中包含先前的訊息和新的結果。

上下文是建構出來的視圖，而非完整的歷史

模型有一個上下文視窗：它在一個請求中能夠考慮的文字量是有限制的。因此，Hermes 無法無限期地發送每一則訊息、檔案、記憶和工具結果。

上下文建構會選擇並排序與當前步驟最相關的材料。它可能包含身分指令、使用者資訊、最近的對話輪次、較早輪次的摘要、相關的記憶、技能指令和工具結果。

順序很重要。關鍵行為和安全指令必須清晰。大型工具輸出應被截斷或摘要。如果不相關的材料塞滿了上下文，模型可能會忽略使用者的實際請求。

上下文問題常常看起來像是智慧問題。在更換模型之前，先檢查模型是否真的能夠取得正確的事實和指令。

壓縮讓長時間的工作階段保持可用

當一個對話增長到超出實用限制時，Hermes 會壓縮較舊的材料。壓縮會建立一個較短的表示形式，包含重要的決策、事實、未解決的問題和任務狀態。

一個好的壓縮提示應保留：

• 使用者的目標；
• 決策及其理由；
• 重要的事實和約束條件；
• 涉及的文件或工具；
• 未完成的任務；
• 不應重複的錯誤。

它應移除問候語、重複內容、過時的嘗試和低價值的敘述。

壓縮是有損的：一些細節會消失。因此，重要的持久性資訊應移入明確的記憶或專案檔案中，而不是僅僅依賴工作階段摘要。

閘道連接外部頻道

閘道從 Telegram 或 Slack 等服務接收訊息，並將其轉換為 Hermes 能理解的事件。它也會將最終回應發送回原始頻道。

閘道必須將每條進來的訊息映射到正確的工作階段。一個 Telegram 主題、Slack 討論串和桌面聊天可能需要獨立的歷史記錄，即使它們使用同一個 Hermes 實例。

閘道也是一個安全邊界。它必須驗證使用者、保護 Token，並避免接受來自公共網際網路的任意指令。如果訊息送達但 Hermes 沒有回應，請在指責模型之前，先檢查閘道日誌、認證、網路連接性和工作階段路由。

SQLite 與持久狀態

一個輕量級的資料庫可以儲存工作階段、訊息、cron 定義和其他營運狀態。該資料庫允許 Hermes 重新啟動而不會忘記哪些對話或排程存在。

持久性仍然需要備份。單一 VPS 上的一個資料庫檔案可能因磁碟故障、意外刪除或失敗的遷移而遺失。在系統處於一致狀態時備份資料庫和設定，並測試還原。

並非每個檔案都屬於資料庫。技能和身分檔案可以保持為普通文字，因為它們更容易檢查和進行版本控管。重點是要知道對於每種類型的狀態，哪個位置是權威來源。

長期記憶是被選定的知識

記憶不同於對話歷史。歷史記錄了說過什麼；記憶記錄了以後應該重要的事。

Hermes 可以檢索與當前任務相關的記憶，並將其插入上下文中。好的記憶條目是簡潔、可歸因且穩定的。像「對使用者面對面的說明使用繁體中文」這樣的偏好，比「使用者今天在旅行」這樣的臨時筆記更加持久。

記憶需要維護。矛盾或過時的條目可能導致持續的錯誤。自動寫入記憶的系統應提供一種檢查、更正和刪除它的方法。

Cron 任務進入相同的管道

一個 cron 任務在排程的時間建立一個事件。不是使用者發送訊息，而是排程器提供提示和相關設定。然後代理迴圈像處理其他工作一樣處理它，並透過指定的閘道或儲存位置傳遞結果。

由於可能沒有人在看，排程任務需要更嚴格的邊界。它們應定義時區、超時時間、最大範圍、模型選擇、傳遞目的地，以及當不需要任何動作時的行為。

Cron 任務在可能的情況下應保持等冪（idempotent）。等冪意味著執行同一個任務兩次不會產生有害的重複。一份報告可以安全地重新產生；但一筆款項或一個公開貼文則不行。

診斷正確的層級

這個架構提供了一個實用的故障排除順序：

• 沒有訊息送達： 檢查外部服務和閘道。
• 出現錯誤的對話歷史： 檢查工作階段映射。
• 模型忽略已知的事實： 檢查上下文建構和記憶檢索。
• 長時間的工作階段遺失決策： 檢查壓縮，並將關鍵事實提升到持久性檔案中。
• 工具重複或進入迴圈： 檢查代理迴圈限制和工具錯誤輸出。
• 排程未執行： 檢查 cron 狀態、時區和服務運作時間。
• 結果已執行但無處可去： 檢查設定的傳遞閘道。

這種分層方法將模糊的除錯過程替換為基於具體證據的調查。

架構支援安全成長

Hermes 不是一個神秘的智慧程序。它是一系列可理解的元件，圍繞著一個模型組合而成。這對操作者來說是個好消息：每個元件都可以被觀察、測試、備份和限制。

代理迴圈提供行動力，上下文提供即時知識，壓縮控制規模，記憶提供連續性，閘道提供觸及範圍，cron 任務提供主動性。當每一層都有明確的歸屬和限制時，Hermes 可以從一個個人聊天助手成長為一個可靠的永遠線上系統。

動手實作：追蹤一次唯讀回合如何通過 Hermes 執行期

• 成果： 觀察一個使用工具的回合、確認它成為可恢復工作階段，並把證據對應到入口、代理迴圈、工具結果與持久化。
• 時間： 15–20 分鐘。
• 風險： 低。任務只讀取一個一次性資料夾，不會寫入或執行外部動作。

開始之前

• 確認一般對話正常，並選擇不含敏感資料的小型資料夾。
• 事先知道至少一個頂層檔名，才能核對回答。
• 保持核准機制開啟；本實作不需要 YOLO 模式。

以下狀態地圖已依本儲存庫釘選的 Hermes 版本（4aa499ff）核對。<設定檔主目錄> 代表目前使用中的 HERMES_HOME：預設設定檔是 ~/.hermes，其他設定檔則位於 ~/.hermes/profiles/ 下的對應目錄。

狀態	權威位置	安全檢查方式
工作階段與訊息	<設定檔主目錄>/state.db	使用 hermes sessions list、恢復與工作階段搜尋；不要手動修改 SQLite。
內建記憶	<設定檔主目錄>/memories/MEMORY.md 與 USER.md	審查精簡的持久項目；工作階段開始時取得的是凍結快照。
Cron 定義	<設定檔主目錄>/cron/jobs.json	使用 Cron 的列出、暫停、恢復、更新與移除功能控制；排程器運作時不要手動編輯 JSON。
每次 Cron 執行證據	<設定檔主目錄>/cron/output/<job-id>/<timestamp>.md	任務宣稱成功或失敗時，檢查實際執行成果。

Cron 路徑定義在 cron/jobs.py，工作階段持久化定義在 hermes_state.py。變更 Hermes 釘選版本後要重新核對，因為儲存契約可能演進。

動手完成

執行一次必須使用檔案系統證據且範圍明確的回合，再檢查工作階段持久化：

hermes chat -q "只讀取目前資料夾。說出一個頂層檔案，說明哪項工具結果證明它存在，且不要變更任何內容。"
hermes sessions list
hermes --continue

在恢復的工作階段送出追問：

用四行標籤描述剛完成的回合：
入口、代理迴圈決定、工具證據、持久化工作階段結果。
只使用本工作階段中實際發生的內容，不要宣稱看不到的實作細節。

最後執行會遮蔽敏感值的執行期健康檢查：

hermes status --deep

驗證成功

• 回答中的檔案確實存在，且引用工具證據而非猜測。
• hermes sessions list 顯示完成的工作階段。
• hermes --continue 恢復足夠上下文，能正確描述前一個回合。
• hermes status --deep 完成，且沒有顯示秘密內容。

發生問題時

• 沒有工具證據時，改在只有一個明顯且非敏感檔案的資料夾重試，並明確要求唯讀檢查。
• 無法恢復時，確認同一個設定檔正在使用，並檢查 hermes sessions list。
• 供應商有回覆但工具失敗時，先執行 hermes doctor 並檢查 hermes logs，不要立刻更換模型。
• 分開判斷入口、供應商、工具與持久化問題，不要直接重新安裝。

安全、隱私與成本

檔名與內容可能進入模型上下文，因此只使用一次性資料夾。不要使用 --yolo；拒絕任何非預期寫入。一個工具回合可能需要多次模型迭代，token 用量高於單純回答是合理現象；持續循環則不是。任務無法收斂時中斷並檢查日誌。

官方參考

• 架構
• 代理迴圈內部機制

---

來源影片： Hermes Architecture EXPLAINED: Memory, Context & Gateways，Hugging Face。根據完整逐字稿與架構導覽改編與重組。