深入 Hermes：代理迴圈、上下文、記憶、閘道與 Cron 任務如何協同運作
一份關於永遠線上的 Hermes 代理背後架構的概念指南。
當你在心中將 Hermes 的內部組件分開時，操作它就會變得更容易。一個請求並非直接從 Telegram 傳送到模型再返回。它會經過一個閘道、被關聯到一個會話、組裝成上下文、由代理迴圈處理，然後儲存供日後使用。排程任務則透過不同的入口進入同一個系統。
這個架構很簡單，不需要閱讀程式碼就能理解，但理解它會改變問題的診斷方式。一個糟糕的答案可能是模型問題、上下文問題或記憶問題。一則遺失的訊息可能是閘道或會話問題。一個重複的排程結果可能是 cron 的設計問題。
鳥瞰視角
中心是代理迴圈。圍繞它的是四個支援系統：
- 上下文建構決定模型現在能看到哪些資訊。
- 會話與閘道管理將訊息連接到正確的對話。
- 記憶在活動上下文之外保存選定的知識。
- Cron 排程在沒有即時使用者訊息的情況下，在定義的時間建立工作。
持久性記錄（通常儲存在 SQLite 等資料庫中）將這些元件在重新啟動後連接起來。
代理迴圈
代理迴圈是 Hermes 處理任務的循環。它接收一條訊息和已組裝的上下文，呼叫模型，檢查結果，並可能呼叫一個工具。工具結果被加入到工作上下文中，然後再次呼叫模型。這個過程會持續，直到模型產出最終答案，或者安全與迭代限制終止了這個迴圈。
簡化的順序如下：
- 接收一個事件或訊息。
- 識別會話和使用者。
- 建構模型上下文。
- 要求模型採取下一步行動。
- 如果請求了，則執行一個允許的工具。
- 將結果加入上下文。
- 重複直到任務完成。
- 儲存回應和相關狀態。
這說明了為什麼基於工具的任務比單一答案消耗更多的 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 Architecture EXPLAINED: Memory, Context & Gateways，Hugging Face。根據完整逐字稿與架構導覽改編與重組。