Hermes Agent /loop 功能概述
Hermes Agent 是一个开源的 AI Agentic（智能体）框架，其核心定位是作为模型与现实世界之间的操作层。它不仅赋予模型“双手”、终端访问权限、文件读写能力以及网页工具，还具备记忆功能和执行多步骤任务的能力。最关键的是，用户无需在每个回合中 babysit（保姆式监控），框架即可自主完成工作。近期团队推出的 /loop 功能彻底改变了 Agent 处理时间依赖型任务的方式。传统模式下，用户需要每隔几分钟手动输入“检查 again”；而引入 /loop 后，只需设置一次提示词（Prompt），Hermes Agent 就会按照设定的循环定时器自动唤醒，每次醒来时都会重新读取当前世界的最新状态，执行任务并汇报结果，随后进入休眠直到下一次触发。
"Hermes Agent is an open-source AI agentic framework that gives your models real hands, a terminal, file access... ability to run multi-step tasks without you babysitting every turn."
该功能的杀手锏在于其灵活的停止条件（Stop Conditions）。用户可以指定固定的运行次数，或者使用自然语言描述终止条件，例如“当部署上线时停止”。此外，还可以配置一个裁判模型（Judge Model）在每次唤醒后进行评估，或者让 Agent 自行判断任务何时完成。博主个人更倾向于后者，即由 Agent 自主决策。为了验证这一功能，本次演示将使用本地量化版的 Qwen3.8-27B 模型，该模型已通过 llama.cpp 服务运行。博主强调，由于 /loop 是较新的功能，用户必须确保 Hermes Agent 已更新至最新版本（通过 hermes update），否则无法使用该特性。
环境配置与循环参数设置
演示环境为 Ubuntu 系统，博主已安装最新版本的 Hermes Agent。首先创建了一个名为 loop demo 的配置档案（Profile）。在配置中，Provider 设置为 Custom，指向本地运行的 llama.cpp API。除了常规模型设置、上下文窗口和工作目录外，核心在于 /loop 的参数配置部分。这些参数定义了循环的行为逻辑：
| 参数名称 | 设置值/含义 | 作用描述 |
|---|---|---|
min_interval |
30 seconds | 最小间隔：循环唤醒的最快频率，防止过于频繁触发 |
max_takes |
100 wake ups | 最大次数：硬性停止条件，达到此唤醒次数后自动暂停 |
floor / ceiling |
30s - 2m | 自适应退避：控制自我节奏的缓冲区间 |
博主详细解释了 floor 和 ceiling 控制的自我节奏退避（Self-paced backoff）机制。初始状态下，Agent 每 30秒 检查一次状态；如果检测到没有任何变化（即内容未更新），它会逐渐降低频率，最终减缓至每 2分钟 检查一次。这种设计既保证了实时性，又避免了在状态静止时的资源浪费。博主确认配置文件已生效，并验证了模型能正常响应 Hermes Agent 的指令。
"The great thing is that this loop mechanism is quite customizable... It starts checking every 30 seconds and if nothing is changing, it slows down to once every 2 minutes."
模拟部署管道与测试场景构建
为了充分展示 /loop 的功能，博主构建了一个模拟部署管道（Simulated Deployment Pipeline）。这是一个简单的 Shell 脚本，旨在模拟真实世界中状态随时间变化的场景。该脚本定义了四个阶段：Queued（排队）、Building（构建中）、Deploying（部署中）和 Live（上线/完成）。每个阶段之间设有 60秒 的暂停时间，以模拟真实的处理延迟。
测试流程如下：
1. 启动 Shell 脚本，使其在后台运行并不断写入状态文件。
2. 并行启动 Hermes Agent。
3. 向 Agent 发送特定的 Prompt，指示其监控该状态文件。Prompt 的核心指令包括：
- 频率：每 30秒 检查一次状态文件。
- 动作：报告当前阶段（Stage）。
- 终止条件：当检测到状态为 Live 时，回复中包含 "loop complete"，随后循环自动终止。
这一设置完美契合了 /loop 的设计初衷：监控外部自主变化的状态。博主强调，整个过程中用户无需干预终端输入，所有操作均在后台自动完成。这种场景特别适用于 CI/CD 流水线监控、服务器状态检查等需要长时间等待且状态会周期性更新的任务。
循环执行过程与智能优化表现
随着模拟部署脚本的运行，Hermes Agent 的 /loop 机制开始自动工作。博主展示了完整的执行时间线：
- 首次唤醒：Agent 在启动后约30秒触发第一次唤醒，此时状态仍为初始阶段。
- Queued 阶段：Agent 读取文件，报告 "deployer still in progress"（部署仍在进行中），然后再次休眠。
- Building 阶段：60秒后，状态变为 Building。Agent 醒来读取最新内容，报告 "next stage is building"，随后休眠。
- Deploying 阶段：状态更新为 Deploying。Agent 继续监控并报告，未检测到 Live。
- Live 阶段（第5次唤醒）：状态最终变为
Live。Agent 检测到该条件，输出 "loop complete"，循环干净地关闭。
值得注意的是，博主发现了一个有趣的智能优化行为。在第5次唤醒时，Agent 并没有像之前那样直接读取文件内容，而是切换到了使用 stat 命令检查文件的修改时间（Modification Time）。这是因为 Agent 观察到之前的读取工具在面对未更改的内容时会进行去重处理（Deduplicating），从而意识到直接比较修改时间可能更高效。整个过程用户从未触碰终端，所有逻辑均由 Agent 在后台自主完成。
"Notice on wakeup five, it even got smart. It switched from reading the file directly to checking the file's modification time with stat... we never touched a terminal once."
/loop, /goal 与 Cron 的核心区别
博主最后澄清了 Hermes Agent 中三个容易混淆的命令：/loop, /goal, 和 cron。尽管它们表面相似，但解决的根本问题完全不同。理解这些区别对于正确使用框架至关重要：
| 命令 | 驱动方式 (Driver) | 适用场景 (Use Case) | 核心逻辑 |
|---|---|---|---|
| /loop | 定时器驱动 (Timer-driven) | 监控外部自主变化的状态（如部署进度、服务器负载） | Agent 定期醒来检查，直到满足特定条件或达到最大次数 |
| /goal | 裁判驱动 (Judge-driven) | 有明确目标且需要 Agent 持续努力直到完成（如代码调试、复杂推理） | Agent 针对特定目标反复尝试，由 Judge Model 评估是否达成 |
| Cron | 系统调度 (System Scheduler) | 需要在终端关闭后仍持续运行的任务（如定时备份、定期报告） | 脱离当前会话运行，独立于用户交互环境 |
博主总结了一条简单的规则：Watching something（监控某物）用 /loop；Fixing something（修复/解决某事）用 /goal；Scheduling something unattended（无人值守调度）用 cron。本次演示展示了 /loop 在本地 Qwen3.8-27B 模型上的完美运行，无需 API Key，实现了真正的零保姆式监控（Zero babysitting）。
"/loop is timer-driven. Use it when something external is changing on its own schedule... /goal is judge-driven... cron is for when the work needs to survive your terminal closing."