SOTA Sync
返回 FEED
AGENT2026-06-10

Hermes Agent 的 8 个 Loop：为什么它们会复合，以及哪个断裂最致命

一个框架的真正差异在 Loop 数

大多数 Agent 框架有一个 Loop：prompt → response → repeat。

Hermes Agent 同时跑 8 个 Loop，时间跨度从毫秒到数周。每个 Loop 服务不同目的，彼此相互增强。堆叠在一起，它们构成一个每次会话都在改进的复合系统。

这是 Hermes 7 周内达到 95,600 GitHub stars 的技术原因——不是功能多，是架构设计让这些功能相互喂给。

Loop 1 — 核心 Agent Loop

时间尺度：每次 turn 几毫秒到几分钟。

这是心跳，所有其他 Loop 都建立在此之上。核心循环在 run_agent.py（AIAgent 类，15,000+ 行代码）里：

接收用户消息
→ 追加到对话历史
→ 构建或复用缓存的系统提示词
→ 检查是否需要压缩（>50% 上下文）
→ 从历史构建 API 消息
→ 注入临时提示词层（预算警告、上下文压力）
→ 应用提示词缓存标记（Anthropic）
→发起可中断的 API 调用
→ 解析响应：
   → 有工具调用？执行，追加结果，回到第 5 步
   → 文本响应？持久化会话，刷写记忆，返回

三种 API 模式自动根据 provider 解析：Single / Streaming / Async。所有三种在 API 调用前后都收敛到同一个内部格式（OpenAI 风格的 role/content/tool_calls 字典）。

**工具执行：**单个工具调用在主线程执行；多个工具调用通过 ThreadPoolExecutor 并发执行，结果按原始调用顺序重新插入，不管完成顺序。

**迭代预算：**默认每会话 90 次迭代（可通过 agent.max_turns 配置）。达到 100% 时 agent 停止并返回摘要。子 Agent 获得独立预算，上限为 delegation.max_iterations（默认 50）。

**可中断调用：**API 请求在后台线程运行，同时监听中断事件。当收到中断（用户发新消息、/stop 或信号）时，API 线程被放弃。不完整的响应不会进入对话历史。

Loop 2 — /goal Loop

时间尺度：每个目标几分钟到几小时。

命名来自 Ralph Wiggum，受 Codex CLI 0.128.0 启发（Eric Traut，OpenAI）。核心思想：在多个 turn 之间保持一个目标活跃。辅助 judge 模型在每个 turn 后评估：完成了还是继续？

用户设置 /goal →
  Turn 1: agent 向目标努力
  Judge 评估：完成了？→ 否
  ↻ 继续向目标前进 (1/20)：[judge 的理由]
  Turn 2: agent 采取下一步
  Judge 评估：完成了？→ 否
  ...
  Turn N: agent 完成
  Judge 评估：完成了？→ 是
  ✓ 目标达成：[理由]

技术细节：

  • 默认 max_turns: 20（可通过 goals.max_turns 配置）
  • /goal resume 重置 turn 计数器并继续
  • /subgoal 在循环中追加接受标准，不重置
  • Judge prompt 重写时包含所有 subgoal——只有原始目标 AND 每个 subgoal 都达成才算完成
  • /goal 状态持久化在 SessionDB.state_meta

**Kanban 集成：**创建卡片时传 --goal 或设 goal_mode=True，worker 在 goal loop 里运行，judge 按卡片的 title + body 作为接受标准。

**关键设计：**judge 可以用比主模型便宜的模型，辅助任务不值得用旗舰模型。

Loop 3 — 自我改进 Loop

时间尺度：任务完成后运行（几分钟到几小时）。

这是让 Hermes 区别于大多数框架的 Loop。官方文档称其为"闭环学习循环"：

1. Agent 完成一个任务
2. Agent 回顾什么有效
3. Agent 发现可复用的模式
4. Agent 将流程存为 skill 文件
   → ~/.hermes/skills/[skill-name].md
5. 下次类似任务：Agent 通过搜索找到该 skill
6. Agent 将 skill 内容加载到上下文
7. Agent 用文档化流程更快执行
8. 如果流程在使用中改进，Agent 更新 skill

Skill 不是提示词模板，是完整流程，包含：触发条件、步骤、已知陷阱、验证步骤、所需工具和依赖。

**复合数学：**TokenMix 研究验证：拥有 20+ self-created skills 的 agent vs 全新 agent 实例，研究任务时间减少约 40%。

Loop 4 — Curator Loop

时间尺度：每 7 天运行一次（仅空闲时）。

Loop 3 创建 skills，Loop 4 维护它们。没有 Curator，Loop 3 最终会让系统降级——skill 索引会被噪音淹没。

定期检查：
  → 合并相似流程
  → 优化描述以提升可搜索性
  → 记录变更日志

触发条件： inactivity check（非 cron 守护进程），首次运行延迟一个完整间隔（在新型安装上给你时间review）。

默认行为：

  • prune_builtins: true：可归档未使用的内置 skills（30 天无使用后）
  • Hub-installed skills（来自 agentskills.io）永不触及
curator:
  interval_hours: 168        # 7 天
  min_idle_hours: 2           # 仅空闲时运行
  prune_builtins: true
  archive_after_days: 30

**为什么 Curator 对 Loop 3 不可或缺：**Tool Search（Loop 7）依赖准确的 skill 名称和描述。维护不善的描述会降级搜索准确性。没有 Curator，skill 会过期、重叠、污染上下文。

Loop 5 — 记忆 Loop

时间尺度：每个会话后及会话期间定期运行。

Hermes 的记忆跨越三层：

**第一层 — 会话记忆（活跃上下文）：**当前会话的对话历史，驻留 RAM 和 SQLite。

**第二层 — 持久记忆（MEMORY.md + USER.md）：**跨会话存活的事实、偏好和洞察。当 Agent 发现重要信息时自动写入。

memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200    # ~800 tokens
  user_char_limit: 1375      # ~500 tokens

**第三层 — 会话召回（FTS5 全文搜索）：**每个 CLI 和消息会话存在 SQLite（~/.hermes/state.db），带 FTS5 全文搜索。搜索返回实际消息——不是 LLM 摘要，没有截断。

**外部记忆 provider（8 个插件）：**Mem0 / Honcho / Hindsight / Holographic / RetainDB / ByteRover / Supermemory / OpenViking。内置记忆与外部 provider 加性共存。

Loop 6 — Kanban Dispatcher Loop

时间尺度：每 60 秒。

Kanban 系统是协调多个 Agent 和任务的编排层：

每 60 秒：
1. 扫描 kanban 板（SQLite ~/.hermes/kanban.db）
2. 找 Ready 状态的任务
3. 分配给可用的 worker
4. 追踪 Running 任务的 heartbeat
5. 检测僵尸进程（worker 挂了但卡还在 Running）
6. 回收僵尸卡（重置为 Ready 重试）
7. 检查重试预算（不无限重试）
8. 上报 Blocked 任务供人工 review

状态： Triage → To-Do → Ready → Running → Blocked → Done → Archived

**Human-in-the-loop：**任务进入 Blocked 状态时，执行暂停直到人工输入。审批按钮在 Telegram 和 Slack 中原生支持。

故意设计为单主机：kanban.db 是本地 SQLite 文件。Dispatcher 在同一台机器上 spawn workers。多主机不支持。想跨主机跑需要每台独立 board，用 delegate_task 或消息队列桥接。

Loop 7 — 压缩 Loop

时间尺度：当上下文使用超过阈值时触发。

Hermes 运行双压缩系统：

第一层 — Gateway Session Hygiene（85% 阈值）
  安全网。在 Agent 处理消息前触发。
  防止会话在一夜积累后（ Telegram ）过大导致 API 失败。

第二层 — Agent ContextCompressor（50% 阈值，可配置）
  主要压缩系统。在 Agent 工具循环内触发，
  可获取 API 报告的准确 token 数量。

压缩算法（四阶段）：

Phase 1 — 修剪旧工具结果（廉价，无 LLM 调用）
  >200 chars 的工具结果（在受保护尾之外）被替换为：
  [Old tool output cleared to save context space]

Phase 2 — 检查 Phase 1 是否足够
  重新估计 token。如果低于阈值：完成。
  如果仍超：进入 Phase 3。

Phase 3 — 总结中间对话 turn
  LLM 调用总结可压缩区域。
  受保护：前 3 条消息 + 最后 20 条消息。
  工具调用/结果对永不拆分。

Phase 4 — 创建新会话谱系
  压缩创建"子"会话 ID。
  记忆在压缩前刷写到磁盘（防止数据丢失）。

配置：

compression:
  threshold: 0.50         # 50% 上下文窗口时压缩
  target_ratio: 0.20
  protect_last_n: 20

Loop 8 — 子 Agent Loop

时间尺度：每个子 Agent 几分钟，并行执行。

delegate_task spawn 隔离上下文的子 Agent。每个子 Agent 独立运行自己的核心循环（Loop 1）。

**Token 成本注意：**每个子 Agent 运行自己完整的 Loop 1 会话。3 个并发子 Agent ≈ 3 倍单会话成本。routine 工作或 research 用便宜模型，把贵模型留给输出质量重要的父编排器。

父 Agent 收到复杂任务
  → Spawn 子 Agent 1（独立上下文，独立工具）
  → Spawn 子 Agent 2（独立上下文，独立工具）
  → Spawn 子 Agent 3（独立上下文，独立工具）
  
  最大并发：delegation.max_concurrent_children（默认 3）

角色：

  • leaf（默认）：不能再 delegate
  • orchestrator：可 spawn 自己的 workers
  • 受 delegation.max_spawn_depth 限制

8 个 Loop 如何嵌套

WEEKLY：
  Loop 4（Curator）运行 → 清理 Loop 3 的 skills
    → 提升 Loop 7（Tool Search in skills）准确性

DAILY：
  Cron 触发 →
    Loop 6（Kanban）分配任务 →
      Loop 2（/goal）在任务上启动 →
        Loop 1（Core）执行每个 turn →
          Loop 7（Compression）在上下文增长时触发 →
          Loop 8（Sub-agents）spawn 并行工作 →
            每个子 Agent 运行自己的 Loop 1
        Loop 3（Self-improvement）在任务完成后触发 →
          新 skill 保存
      Loop 5（Memory）写入持久事实

EVERY SESSION：
  Loop 5（Memory）注入 MEMORY.md + USER.md
  Loop 1（Core）运行 turns
  Loop 7（Compression）管理上下文
  Loop 3（Self-improvement）回顾并保存

复合链：

  • Loop 3（skills）让 Loop 2（/goal）更快，因为 Agent 有文档化流程
  • Loop 4（Curator）保持 Loop 3 干净，使 skills 保持可搜索
  • Loop 5（memory）给 Loop 1 关于你和你的偏好的上下文
  • Loop 6（Kanban）在并行中编排多个 Loop 2 实例
  • Loop 7（compression）保持 Loop 1 在长跑中可负担
  • Loop 8（sub-agents）倍增 Loop 1 的并行工作容量

**移除任何单个 Loop，其他都会降级。**移除 Loop 3，Agent 从不改进。移除 Loop 4，Loop 3 最终会让系统 bloated。移除 Loop 7，长会话崩溃。移除 Loop 5，每个会话都从冷开始。

一个 Loop 断裂最致命：Loop 3

最危险的失败模式：Loop 3 保存了一个坏的 skill。一个错误的流程在未来会话中被复用，复合错误。这就是为什么 Loop 4（Curator）和人工 review 都存在——Curator 捕获过时 skills，人工 review 捕获错误 skills。

配置参考：

# Loop 1 — Core
agent:
  max_turns: 90

# Loop 2 — /goal
goals:
  max_turns: 20

# Loop 4 — Curator
curator:
  interval_hours: 168
  min_idle_hours: 2
  prune_builtins: true
  archive_after_days: 30

# Loop 5 — Memory
memory:
  memory_enabled: true
  user_profile_enabled: true
  memory_char_limit: 2200
  user_char_limit: 1375

# Loop 7 — Compression
compression:
  enabled: true
  threshold: 0.50
  target_ratio: 0.20
  protect_last_n: 20

# Loop 8 — Sub-agents
delegation:
  max_concurrent_children: 3
  max_iterations: 50
  max_spawn_depth: 2

三步启动路线

第一步（5 分钟）：让 Loop 1 + Loop 5 跑起来

安装 Hermes，运行 hermes setup --portal。开始一个会话。记忆自动写入。Loop 1（核心）和 Loop 5（记忆）从第一条消息起就激活。

第二步（再 10 分钟）：加上 Loop 2

运行你的第一个结构化 /goal：

/goal [what you want done]
using [what sources to check]
with constraints: [what to avoid]
deliverable: [what "done" looks like]

第三步（再 30 分钟）：加上时间和编排

设第一个 cron job。很小的事：

每天早上 8 点给我发一条 Telegram 摘要，关于当天热门的 AI 新闻。

你现在有 5 个 Loop 在跑：Core (1) / goal (2) / Self-improvement (3) / Memory (5) / Compression (7)。

Kanban (6) / Curator (4) / Sub-agents (8) 随着你的使用量增长而激活。Curator 在 7 天后启动。子 Agent 在你使用 delegate_task 时 spawn。Kanban 在你追踪多个任务时激活。

你不需要在第一天配置全部 8 个。从 2 个开始。其余的随着你的系统扩展而来。

资源：

继续阅读