<!-- Source: https://hermesbible.com/flows/8-loops-inside-hermes-agent -->

概覽

大多數代理框架只有一個循環：提示 → 回應 → 重複。Hermes Agent 同時運行8 個循環，時間尺度從毫秒到每週不等。每個循環服務不同的目的，每個都讓其他循環更有效率。疊加在一起，它們創造了一個隨每次對話複利成長的系統。

本篇文章涵蓋 Hermes Agent 內部的每一個循環，解釋它們如何嵌套，並展示當任何一個循環失敗時會發生什麼。所有技術細節都經過官方 Hermes Agent 開發者文件驗證。

什麼是代理架構中的循環？

循環是一個週期：執行 → 檢查 → 決定 → 重複或停止。

每個代理至少有一個。核心循環向模型發送訊息、取得回應、檢查工具呼叫、執行它們，然後回到起點。沒有它就沒有代理——只是一個單獨的 API 呼叫。

框架之間的差別在於它們運行多少個循環、在什麼時間尺度上，以及這些循環是否互相餵料。代理系統中存在四種類型的循環：

大多數框架實作了類型 1 和 2。少數實作了類型 3。Hermes 原生實作了全部四種，加上跨代理和時間協調的編排循環。

循環 1——核心代理循環

時間尺度： 每輪從毫秒到分鐘。

這是心跳。其他一切都在它之上運行。核心循環位於 run_agent.py（AIAgent 類別）。每輪遵循以下序列：

1. 接收使用者訊息（或來自 /goal 判斷的延續）
2. 追加到對話歷史
3. 建立或重用快取的系統提示（prompt_builder.py）
4. 檢查是否需要壓縮（>50% 上下文）
5. 從歷史建立 API 訊息
6. 注入臨時提示層（預算警告、上下文壓力）
7. 應用提示快取標記
8. 發出可中斷的 API 呼叫
9. 解析回應——有工具呼叫？執行、追加結果、回到第 5 步。文字回應？持久化對話、刷新記憶體、返回。

工具執行： 單一工具呼叫在主執行緒中運行。多個工具呼叫透過 ThreadPoolExecutor 平行執行，結果按原始呼叫順序重新插入，不論完成順序。

迭代預設： 每次對話預設 90 次迭代（可透過 agent.max_turns 設定）。達到 100% 時，代理停止並返回摘要。子代理有獨立的預算，上限為 delegation.max_iterations（預設 50）。

可中斷呼叫： API 請求在背景執行緒中運行，同時監聽中斷事件。被中斷時，API 執行緒被放棄，部分回應不會進入歷史。

沒有這個循環會怎樣：一切都完蛋。這是核心。

循環 2——Ralph 循環（/goal）

時間尺度： 每個目標從分鐘到小時。

核心概念：跨多輪保持一個目標存活。一個輔助判斷模型在每輪後評估——完成還是繼續？

User sets /goal →
  Turn 1: agent works toward objective
  Judge evaluates: done? → no
  ↻ Continuing toward goal (1/20): [judge's reason]
  Turn 2: agent takes next step
  ...
  Turn N: agent completes
  Judge evaluates: done? → yes
  ✓ Goal achieved: [reason]

關鍵細節：

• 預設 max_turns：20（可透過 goals.max_turns 設定）
• /goal resume 將回合計數器重置為零並繼續
• /subgoal 在循環中途新增驗收標準，不重置
• 判斷提示被改寫以包含所有子目標——只有當原始目標和每個子目標都達成時才算完成
• 目標狀態持久化在 SessionDB.state_meta
• 判斷在輔助客戶端上運行（可以是較便宜的模型）

/goal [description]     # start
/goal status            # check progress
/goal pause             # pause, preserve context
/goal resume            # continue, reset counter
/goal clear             # end
/subgoal [text]         # add criteria mid-run
/undo [N]               # take back last N turns

沒有這個循環會怎樣：代理完成一輪就停止。沒有多步推理，沒有持續性目標。每個任務都需要逐輪監督。

循環 3——自我改進循環

時間尺度： 在完成的任務後運行（分鐘到小時）。

這是讓 Hermes 不同的循環。官方文件將它描述為「一個封閉的學習循環」。

1. 代理完成一個任務
2. 代理回顧哪些方法有效
3. 代理識別可重複使用的模式
4. 代理把流程儲存為技能檔案 → ~/.hermes/skills/[skill-name].md
5. 下次類似任務：代理透過搜尋找到該技能
6. 代理把技能內容載入上下文
7. 代理使用記錄的流程更快地執行
8. 如果流程在使用中被改進，代理更新該技能

技能不是提示範本——它們是包含觸發條件、逐步流程、已知陷阱、驗證步驟和所需工具的完整流程。代理使用 skill_manage 工具建立和更新它們。

複利數學： 根據已驗證的使用者基準，擁有 20+ 個自建技能的代理比全新實例的研究任務時間減少約 40%。每個完成的任務都可能建立或優化一個技能，所以第 3 個月跟第 1 天不一樣。

Nudge 系統： 循環由「nudges」觸發——定期檢查會生成 AIAgent 的背景分支。分支在自己的提示快取中運行，永遠不會觸碰活躍的對話。

沒有這個循環會怎樣：每次對話都從零開始。第 90 天的輸出品質等於第 1 天。

循環 4——Curator 循環

時間尺度： 每 7 天運行一次（預設），在閒置期間。

技能會累積。不維護的話，你最終會有一堆狹窄的近乎重複的技能，污染目錄並浪費 token。Curator 解決了這個問題——當 interval_hours 過期且代理已閒置 min_idle_hours 時，它生成一個背景分支來掃描技能、封存未使用的、合併相關流程，並優化描述以提升可搜尋性。

curator:
  interval_hours: 168        # 7 days
  min_idle_hours: 2           # only runs when idle
  prune_builtins: true        # can archive unused built-in skills
  archive_after_days: 30      # unused threshold

hermes curator status        # check last run
hermes curator pause         # skip next run
hermes curator resume        # re-enable

重要的保證：它由非活動檢查觸發（不是 cron daemon），首次運行在新安裝時延後一個完整間隔，它永遠不會自動刪除（最壞情況是可恢復的封存），Hub 安裝的技能永遠不碰。

沒有這個循環會怎樣：技能膨脹。代理累積了數百個重疊的技能，上下文被污染，搜尋返回錯誤的結果。

循環 5——記憶體循環

時間尺度： 每次對話後和對話期間定期。

記憶體在三個層級運作：

• 第 1 層——對話記憶體： 當前對話的歷史，存放在 RAM 和 SQLite 中。
• 第 2 層——持久化記憶體（MEMORY.md + USER.md）： 跨對話生存的事實、偏好和見解，當代理識別到重要資訊時自動寫入。
• 第 3 層——對話回溯（FTS5）： 每個 CLI 和訊息對話都儲存在 SQLite（~/.hermes/state.db）中，全文搜尋返回實際訊息——無 LLM 摘要、無截斷。

memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200    # ~800 tokens, injected every turn
  user_char_limit: 1375      # ~500 tokens, injected every turn

外部記憶體提供者（8 個外掛）： Mem0（知識圖譜 + 語意檢索）、Honcho（雙方辯證）、Hindsight、Holographic、RetainDB、ByteRover、Supermemory 和 OpenViking。內建記憶體繼續與它們並行工作——外部提供者是附加的。

沒有這個循環會怎樣：代理在每次對話之間忘記一切。你每次都重新解釋你的偏好和專案。

循環 6——看板調度器循環

時間尺度： 每 60 秒。

看板系統是協調多個代理和任務的編排層。每 60 秒它掃描看板（~/.hermes/kanban.db），找到就緒的任務，分配給工作者，追蹤執行中任務的心跳，偵測並回收殭屍卡片，檢查重試預算，並報告已阻斷的任務等待人工審查。

狀態：分類 → 待辦 → 就緒 → 執行中 → 已阻斷 → 完成 → 已封存。

hermes kanban swarm

swarm 啟動一個根編排器 + 平行工作者 + 有門檻的驗證器 + 有門檻的綜合器 + 一個共享黑板。當任務進入已阻斷狀態時，執行暫停等待人工輸入（Telegram 和 Slack 原生支援審批按鈕）。

看板刻意設計為單機——kanban.db 是一個本地 SQLite 檔案，調度器在同一台機器上啟動工作者。對於多機設定，每個主機運行一個獨立的看板，透過 delegate_task 或訊息佇列橋接它們。

沒有這個循環會怎樣：多代理工作變成手動協調。崩潰的任務無人知曉，沒有重試也沒有可見性。

循環 7——壓縮循環

時間尺度： 當上下文使用量超過閾值時觸發。

Hermes 運行一個雙重壓縮系統：在 85% 時有一個 Gateway Session Hygiene 安全網（粗略的基於字元的估計，在代理處理訊息前觸發），以及在 50% 時的 Agent ContextCompressor（主要系統，可存取精確的 API 回報 token 數）。

演算法有四個階段：

1. 修剪舊的工具結果（便宜，不需 LLM 呼叫）——保護尾部之外超過 200 字元的結果被替換為佔位符。
2. 檢查第 1 階段是否足夠——重新估計；如果低於閾值，完成。
3. 摘要中間回合——一個 LLM 呼叫摘要可壓縮區域。保護：前 3 則訊息 + 最後 20 則。工具呼叫/結果對永遠不會被分割。
4. 建立新的對話血統——壓縮建立一個「子」對話 ID；記憶體在壓縮前刷新到磁碟以防止資料遺失。

compression:
  enabled: true
  threshold: 0.50         # compress at 50% of context window
  target_ratio: 0.20      # how much of threshold to keep as tail
  protect_last_n: 20      # recent messages always preserved

context:
  engine: "compressor"    # default, lossy summarization
  # engine: "lcm"         # plugin, lossless context management

沒有這個循環會怎樣：長時間對話碰到上下文限制，API 呼叫失敗，多輪 /goal 運行在 15-20 輪後變得不可能。

循環 8——子代理循環

時間尺度： 每個子代理從分鐘起，平行執行。

delegate_task 生成帶有隔離上下文的子代理。每個子代理獨立運行自己的核心循環（循環 1），可以使用 /goal、建立技能、寫入記憶體和運行壓縮。子代理向父代理返回摘要，保持父代理的上下文精簡。

delegation:
  max_concurrent_children: 3
  max_iterations: 50      # budget per sub-agent
  max_spawn_depth: 2      # orchestrator nesting limit

Roles:
  leaf (default): cannot re-delegate
  orchestrator: can spawn its own workers

# Batch (parallel):
delegate_task(tasks=[
  {goal: "research topic A", ...},
  {goal: "research topic B", ...},
  {goal: "research topic C", ...}
])

Token 成本說明： 每個子代理運行自己的完整循環 1 對話——3 個平行子代理 ≈ 3 倍你的單次對話成本。對日常子代理工作使用較便宜的模型，把昂貴的模型留給父編排器。

沒有這個循環會怎樣：每個任務都在一個上下文中循序執行。平行研究、多角度分析和同時的程式碼審查都在單一代理上形成瓶頸。

循環如何嵌套

這些循環不是獨立運行的——它們互相嵌套並跨越時間尺度：

每週：
  循環 4（Curator）運行 → 清理循環 3 產生的技能
    → 提升循環 7（Tool Search 在技能中的）準確度

每日：
  Cron 觸發 →
    循環 6（看板）分配任務 →
      循環 2（/goal）在任務上開始 →
        循環 1（核心）執行每一輪 →
          循環 7（壓縮）在上下文增長時觸發 →
          循環 8（子代理）生成用於平行工作 →
            每個子代理運行自己的循環 1
        循環 3（自我改進）在任務完成後觸發 →
          新技能被儲存
      循環 5（記憶體）寫入持久化事實

每次對話：
  循環 5（記憶體）注入 MEMORY.md + USER.md
  循環 1（核心）運行每一輪
  循環 7（壓縮）管理上下文
  循環 3（自我改進）回顧並儲存

複利鏈： 技能（循環 3）讓 /goal（循環 2）更快。Curator（循環 4）保持技能乾淨且可搜尋。記憶體（循環 5）給核心循環關於你的上下文。看板（循環 6）編排平行目標。壓縮（循環 7）讓長時間運行保持可負擔。子代理（循環 8）倍增容量。移除任何單一循環，其他循環都會退化。

Hermes 如何與其他循環架構比較

不是每個框架都實作了相同的循環：

• GenericAgent（12.4K stars）使用最小的種子程式碼（~3K 行、9 個原子工具）自我演化。它的目標模式使用時間預算而不是回合預算，據稱 token 消耗低 6 倍。
• DSPy（25K+ stars，Stanford NLP）把提示當作程式並針對指標優化它們——它透過編譯來優化提示，而 Hermes 透過技能建立來優化流程。

Hermes 的優勢：所有 8 個循環都是原生的、整合的，設計上互相餵料。大多數框架只實作 2-3 個，其餘留給使用者。

每個循環的 Token 成本

不是每個循環都花相同的 token。最便宜：看板（零）、Curator（極少）、壓縮（淨節省）。最貴：子代理（倍增器）、/goal（最多 20 倍核心回合）和核心循環（基礎成本）。

優化優先級： 為 /goal 判斷和壓縮使用輔助模型；降低不需要深上下文的設定檔的記憶體字元上限；為每個設定檔設定實際的 max_turns（研究用 20，只有編碼才用 50）；啟用 Tool Search 避免載入未使用的定義；用便宜的模型跑日常 cron。用 /usage 測量你的實際數字。

從這裡開始

你不需要在第一天設定所有 8 個循環——你從 2 個開始，其他隨著系統擴展上線。

• 第 1 步——讓循環 1 + 循環 5 運行（5 分鐘）： 安裝 Hermes，執行 hermes setup --portal，開始一個對話，跟它說話。核心和記憶體從第一則訊息就啟動。
• 第 2 步——加入循環 2（10 分鐘）： 執行你的第一個結構化 /goal，帶有目標、來源、限制和交付物。自我改進（循環 3）在目標完成後自動觸發。
• 第 3 步——加入時間和編排（30 分鐘）： 設定一個小型 cron（例如每天早上 Telegram 新聞摘要）。你現在有 5 個循環在運行。看板、Curator 和子代理隨著使用量增加而啟動。

真正的洞察

代理框架由它們的循環定義。一個循環（提示 → 回應）是聊天包裝器。兩個循環（+ 重試）稍微好一點。一個有全部 8 個的框架是一個操作系統。

複利發生在這些循環的交集中，而不是任何單一個循環。一個能改進自己的流程又維護它們又記得你的偏好又編排平行工作又管理自己的上下文的代理，跟一個只是回應提示的代理是根本不同的工具。這就是 Hermes Agent 的循環架構。

---

最初由 YanXbt 撰寫。技術細節經過 Hermes Agent 開發者文件（v0.16.0）和來源參考驗證，包括 run_agent.py、context_compressor.py、gateway/run.py 和 Curator 模組。