如果你也在折腾 Hermes Agent，大概率有过这种体会：任务交出去，它确实会跑，但一看日志，几十步的 Agent Loop 里，大半步数都耗在无效推理、重复工具调用，甚至原地打转。更麻烦的是，不同的运行模式下（桌面版、Bot、CUA），同一个 Agent 的执行流程完全不是一个节奏，出了问题你根本不知道卡在哪一环。所以我把 Hermes 的执行流程从头到尾拆了一遍，从 Loop 的核心结构、四个关键节点，到我在真实环境里跑通的配置和踩坑记录，一次性说清楚。
这篇文章适合两类人：一类是刚装好 Hermes Agent、想搞明白“它到底怎么一步步干活的”新手；另一类是用过一段时间、但总感觉 Agent 不够聪明、或者经常跑到一半就停住的进阶玩家。我会用一条真实任务线串起整个拆解——让 Agent 整理 Obsidian 笔记、生成日报、再通过企微 Bot 推送给指定人，这条路跑下来，Agent Loop 的每个环节都会暴露得明明白白。
1. 先搞清楚：Hermes Agent Loop 到底在“循环”什么
1.1 一个 Agent Loop 的循环单元：Observe-Think-Act
很多教程上来就讲工具调用、讲 Function Calling，但我觉得这是本末倒置。你连 Loop 在循环什么都没搞明白，学再多工具配置也是白搭。
Agent Loop 的每个循环单元，本质就是三件事：Observe（观察）、Think（思考）、Act（行动）。注意，这不是我发明的概念，而是所有基于 LLM 的智能体框架共同遵守的范式。Hermes 把它做成了显式的循环结构，每跑完一轮 Observe-Think-Act，环境状态就变了一次，新的状态又会被喂进下一轮循环，直到 Agent 判定任务完成或者达到预设的最大步数。
有个生活化的类比：你让一个实习生去整理档案柜。他会先打开柜子看看（Observe），发现档案没分类，于是想“那我先按年份分吧”（Think），然后动手搬档案（Act）。搬完几份，他会停下来再看看柜子里现在什么样（下一轮Observe），再决定下一步是继续搬还是调整策略。这就是 Agent Loop。
Hermes 的循环里有一个关键设计：每一轮循环结束后，模型上下文里都会追加这一轮的“观察结果”和“行动结果”，下一轮推理天然带着上一轮的“记忆”。这个机制让 Agent 有连续性，但也埋下了一个雷——上下文会越滚越大，后面我会单独讲。
1.2 Hermes 里 Loop 运行的三个触发模式
Hermes 的执行流程会根据触发模式变化，这点很多人没注意。常见的有三种：
- 指令模式（Command Mode)：你输入一段话，Agent 从零开始一个 Loop，跑完就结束。这是最经典的“一问一答”式 Agent。
- Bot 模式（Bot Mode）：比如接入企微机器人，Agent 是常驻的，每条消息进来都会触发一个新的 Loop。v0.21 版本的 bot mode 已经比较稳定，核心特点是事件驱动，循环跟消息生命周期绑定，而不是跟整个进程绑定。
- CUA 模式（Computer Use Agent）：这个最猛，Agent 可以直接操作你的电脑界面，移动鼠标、敲键盘、点击按钮。它的 Loop 里多了一个环节——截屏观察，也就是用视觉模型理解屏幕状态，再把操作指令映射到系统输入上。
三个模式对应着三种不同的循环节奏。指令模式是“短跑”，Bot 模式是“接球就投”，CUA 模式是“边看边摸”。我之前就是没搞清这个区别，在桌面版里试图用指令模式驱动一个本该常驻的企微机器人，结果每次都要手动唤醒，体验非常割裂。
1.3 为什么说“Loop 跑得好不好”决定了 Agent 的上限
大模型本身的能力当然重要，但放进 Agent 框架里，模型只是循环里的一个“推理器”。你给它再强的模型，如果 Loop 结构混乱——比如该观察的时候不观察、该停的时候不停、上下文的利用率很低——输出质量照样一塌糊涂。
我做过一个对比实验：同一个任务（从二十篇 Obsidian 笔记里提取待办事项并生成周报），分别跑在两套 Prompt 和 Loop 配置下，前者用了 84 步才完成，中间至少 30 步在做重复的全文滚动；后者把 Loop 结构优化了一下，35 步跑完，结果还更干净。这说明什么？说明在 Agent 的世界里，流程即能力。你把 Loop 的每个环节理顺了，体验是呈指数级提升的，而不是一点点改善。
所以，别再单纯盯着模型参数了，把时间花在理解 Hermes 的执行循环上，回报率高得多。
2. 核心拆解：Hermes Agent Loop 的四个关键节点
2.1 节点一：目标解析与上下文注入
Loop 开始的第一件事，不是让模型直接干活，而是把用户输入变成“可执行的目标”。Hermes 在指令模式下，会先做一次目标解析：把原始输入拆成任务描述、约束条件、输出格式三部分，再把这三部分拼进 system prompt 和 user message 里，形成第一版完整上下文。
这个阶段有个非常容易踩的坑：上下文注入太满。有些人习惯把几十页知识库文档全部塞进上下文，美其名曰“让 Agent 有足够信息”，结果模型在一堆冗余信息里找重点，推理质量直线下降。我的经验是：目标解析阶段只注入与当前任务直接相关的上下文，其他内容放到后续的工具调取环节，让 Agent 按需取用。Hermes 本身支持在 Prompt 里设置上下文过滤器，按标签或者关键词筛选笔记库内容，实测下来比全量注入效果好得多。
这一段在日志里通常长这样：
{ "step": 0, "event": "context_build", "injected_sources": ["note://2024-05/inbox", "note://knowledge-base/agent-rules"], "token_usage": 3120 }注意这里的injected_sources，它告诉你哪些资料被注入到了首轮上下文。我每次跑完会扫一眼这个字段，如果发现 Agent 把无关笔记也拉进来了，我就会到筛选器配置里去收紧关键词。
2.2 节点二：推理与计划生成
目标明确了，Agent 进入推理阶段。在 Hermes 里，这一步不是直接输出一句“好的，我来执行”，而是生成一个结构化的行动计划。你可以在日志里看到类似这样的内容：思考过程、计划步骤、依赖的工具列表、预期结果。
我习惯把 Hermes 的推理温度调低到 0.2 左右，尤其在 Loop 里，温度太高会让 Agent 每轮的决策飘忽不定，同一个错误能反复犯三次。如果你想让它更有创造性，可以把温度调回 0.7，但代价是 Loop 的不确定性急剧增加——适合头脑风暴类任务，不适合执行类任务。
另外一个重要的参数是max_steps。我见过有人把这个值设成 200，觉得步数越多越能完成复杂任务，实际上这等于告诉 Agent“你可以随便瞎跑”。我常用的做法是反着来：先设一个偏小的步数上限（比如 20 步），跑完看日志，统计它实际用了多少步，然后逐步调整到“刚好能完成 + 20% 冗余”。以我自己的经验，40 步以内的任务占绝大多数，超过 80 步的任务通常不是任务真的复杂，而是流程设计有问题。
推理阶段还有一个隐藏机制——自省回调。每次执行行动前，Hermes 会花一小段 token 评估“当前计划是否仍然合理”，如果环境反馈跟预期偏差太大，它会主动修改计划而不是硬着头皮继续。这个机制非常实用，我建议你在配置里显式开启，虽然每个 Loop 会多消耗几百个 token，但相比盲目执行导致的反复尝试，性价比高多了。
2.3 节点三：工具执行与结果回传
计划有了，就该动手了。Hermes 的工具调用层，走的是标准的函数调用协议：模型输出一个结构化参数，框架负责真实执行，然后把执行结果回传给模型作为下一轮的 Observed 状态。注意这里的“结果回传”，不是简单地把工具输出塞进上下文就完事了，Hermes 会做三件事：
- 结果裁剪：把超长输出截断到预设长度（我一般设 2000 字符），防止上下文爆炸。
- 结构化压缩：把 JSON 输出精简成摘要，同时保留关键字段。
- 状态标记：标记结果是“成功”“失败”还是“部分成功”，方便模型判断下一步。
这一步我最想强调的是：不要忽视工具调用的超时设置。Hermes 的默认工具超时是 120 秒，看起来挺长，但在一些外部 API 响应慢的情况下，Agent 会挂在等待上，整个 Loop 一动不动。我吃过大亏，后来统一调成 30 秒超时，超时后直接返回“工具超时”标记，让 Agent 决定是重试还是换方案，整个 Loop 的韧性一下就上来了。
工具调用这块，Hermes 背后接的是一堆适配器：文件系统、数据库、HTTP 请求、剪贴板、自动化脚本等等。我自己最常用的是三个：一个是文件系统工具（读写 Obsidian 库）、一个 Search API 工具（检索本地文档）、还有一个自定义的命令行工具（跑脚本）。一套工具跑顺之后，Agent 的“行动能力”比裸 GPT 强太多。
2.4 节点四：记忆写入与上下文压缩
这是整个 Loop 里最被低估的节点，也是普通使用者和资深玩家拉开差距的地方。每次 Loop 到尾声，Hermes 会做两件事：把重要信息写入长期记忆，并对当前对话上下文做压缩。
长期记忆这块，Hermes 支持向量库存储。它能自动提取当前任务里的关键实体（人名、日期、决策点），写入到本地向量库，后续相关任务可以直接召回这些记忆。我最初没开这个，结果每次让 Agent 处理同一批笔记，它都要重新读一遍全文，浪费大量 token。开了持久记忆之后，第二次跑相同主题的任务，上下文构建阶段会自动拉取上次的结论，Loop 步数直接砍半。
上下文压缩更是个技术活。你可能遇到过这种情况：Agent 跑着跑着突然失忆，前面说过的事情不承认。这就是上下文压缩策略太激进导致的。Hermes 默认的压缩策略是在 token 数达到阈值（比如 8000）时，把前面的对话总结成摘要，把原文从上下文中移出去。这个策略本身没问题，但摘要质量直接决定了 Agent 后续的表现。
我踩过一个坑：当时把压缩阈值调得很低，结果 Agent 每几轮就把前面内容压缩一次，重要细节被压没了，Loop 开始“胡说八道”。后来我把阈值调回 16000，并且把“关键任务事实”设置为不可压缩字段，问题才解决。一句话，给压缩留足余量，给关键信息上保护锁。
记忆和压缩，就像一个 Agent 的“长期记忆”和“短期工作记忆”，两者协调好了，Loop 才真正具备持续工作的能力。
3. 实操：从安装到跟踪一次完整的 Hermes Agent Loop
3.1 环境准备与安装要点
说了这么多原理，来点能直接落地的。先说说安装部署。
Hermes Agent 在 Windows 和 Ubuntu 上我都装过。Windows 下，我推荐直接装桌面版，安装包从官方渠道下载即可。有一点要提醒：安装目录不要带中文和空格，这问题在后续加载外部工具时候会坑到你——之前有朋友把 Hermes 装到C:\Program Files，某些插件根本加载不了，改到D:\tools\hermes后一切正常。
Ubuntu 下建议用脚本装，装完手动配 Python 环境。我在 Ubuntu 20.04 下踩过一个坑：Hermes 依赖的某个版本库跟系统自带的 Python 3.8 冲突，后来用 virtualenv 单独建环境解决。官方文档里虽然写了依赖列表，但实际装的时候，还是建议把版本锁定在文档推荐的组合，不要随手pip install --upgrade，血泪教训。
安装完后，第一步不是急着写 Prompt，而是跑一遍自检命令，确认模型端点的连通性。我这边用的模型后端是 DeepSeek 的 API，原因是性价比高，在 Agent 高频调用的场景下成本优势很明显。如果你用的是 OpenAI 或者其他兼容端点，配置方式类似，都是在 Hermes 的配置中心里改 base_url 和 api_key。
3.2 用日志跟一条真实 Loop 的运行轨迹
为了讲清楚 Loop 长什么样，我跑了一条实际任务，把日志结构也稍微脱敏贴出来。
任务很简单：让 Hermes 扫描 Obsidian 里最近三天的笔记，整理出待办事项，生成一份日报，推送到企微 Bot。
第一轮 Loop 的日志长这样：
[Loop 1/32] Observe -> 发现 12 篇笔记，时间范围: 最近 3 天 [Loop 1/32] Think -> 计划: 先过滤非笔记文件，再逐个扫描内容提取待办 [Loop 1/32] Act -> 调用 filesystem.search 工具，参数: {path: "vault/inbox", date_range: "3d"} [Loop 1/32] Result -> 返回 12 个文件路径，token 消耗: 842注意，第一轮它没有一上来就“读所有文件”，而是先用搜索工具拿到文件清单。这是标准做法——先把范围缩小，再逐个深入。如果第一轮就直接调 read_all，那基本可以断定 Agent 的 Prompts 没写好，效率会非常低。
继续往下，到第 7 轮，日志里出现了上下文压缩事件：
[Loop 7/32] Mem -> 写入长期记忆: 关键实体 { "date": "2025-02-14", "tags": ["日报", "待办"] } [Loop 7/32] Context -> 压缩前 8400 tokens -> 压缩后 3100 tokens这就是我前面说的记忆写入节点。如果你发现 Loop 到了十几轮，上下文 token 数还在直线往上涨，没有出现压缩事件，说明你的压缩阈值设得太大了，得调下来。
到第 24 轮，它开始调用企微 Bot 工具发送日报：
[Loop 24/32] Act -> 调用 wecom.bot_send，参数: { receiver: "<userid>", content: "...日报摘要..." } [Loop 24/32] Result -> 发送成功，message_id: "123456789"到这里，任务基本完成。后面几轮是一些收尾工作，比如确认发送状态、写执行总结。我数了一下，整条任务用了 32 步，比我的预期步数上限（40 步）少了不少，这是因为开了 long-term memory 和 Skill 系统（下面讲）。
3.3 Skill 如何改变 Loop 的执行路径
Hermes 的 Skill（技能）是个很实用的设计，用好了能让 Loop 步数直线下降。
什么叫 Skill？简单说，就是把一组固定动作打包成一个可复用的技能。比如“扫描笔记提取待办”这件事，如果让 Agent 每次自由发挥，它可能要 10 多步，反复思考怎么读文件、怎么提取、怎么汇总。但如果提前写好一个 Skill，把它封装成一次调用，整个 Loop 就会变成：
[Loop 1/15] Think -> 使用已有Skill: weekly_report [Loop 2/15] Act -> 调用 skill.weekly_report.run一步到位。这就是把“会做的事”沉淀成“固定工具”，也是我前面说的流程能力。我强烈建议凡是重复执行过两次以上的任务，都写成 Skill。磨刀不误砍柴工，前期花点时间定义 Skill，后面每一次 Loop 都是赚的。
Skill 的定义文件是 YAML 格式的，核心包含：触发条件、输入参数、执行步骤、以及输出格式。我自己的经验是，Skill 的描述字段务必写清楚“这个技能适合做什么、不适合做什么”，因为模型靠描述来触发技能，描述含糊的话，它会在该调用的时候不调用，或者在不该调用的时候乱调。
我之前在 Windows 上更新桌面版后，遇到过 Skill 全部不生效的怪问题。后来发现是更新过程中旧配置文件残留，导致 Skill 目录指向了不存在的路径。解决办法是把旧的 config 目录整个备份后删掉，重新初始化，再导入之前导出的配置。类似的“更新后功能异常”，优先怀疑配置残留，别急着重装。
4. 常见问题与排查技巧实录
4.1 Loop 死循环：Agent 反复执行同一个动作
这是“Agent Loop 深拆”被问得最多的问题。症状很典型：日志里同一个工具调用出现十几次，参数都不带变的，Agent 像卡住了一样不停重试同一个失败动作。
我的排查顺序是这样的：
- 先看工具返回的错误信息，如果错误是“权限不足”或“文件不存在”，那大概率是环境配置问题，而不是 Agent 的问题。
- 再看超时设置，如果工具返回“超时”，Hermes 默认会重试一次，如果还是超时，它可能陷入“超时-重试-再超时”的循环。把超时时间调长一点，或者给 Agent 配置“超过 2 次失败直接换方案”的指令。
- 检查模型的温度设置，温度过高会让 Agent 的决策不稳定，容易反复横跳。
我以前遇到过一个案例，Agent 反复调用搜索工具，搜索同一个不存在的关键词，根本不换词。后来发现是 Prompt 里没有“如果搜索结果为空，尝试变换关键词”这条指令。所以排查死循环时，别只怪框架，很多时候是指令没给全。
我还习惯在 Hermes 里开一个“循环护栏”功能：当检测到同一个动作连续执行超过 3 次时，强制插入一条反思指令，Log 里会多一行Interrupted: duplicate action detected。这个选项在高级配置里，普通的默认配置没有开启，我是建议手动打开的。
4.2 上下文越滚越大导致响应变慢
这个问题用户体感最深——Loop 跑到一半，响应速度明显变慢，每一步要等好几秒。打开日志一看，context token（上下文 token）已经上万了。
要解决，从三方面入手：
- 调低上下文压缩阈值。比如说默认 16000 压缩，你可以改成 8000。压缩频率高一点，但单次压缩不会丢太多细节。
- 启动“重要信息保护”。Hermes 允许你指定关键字段不可压缩，比如任务主目标、用户原始输入、最终输出格式。这样即便压缩，核心信息也不会丢。
- 控制工具返回长度。有些工具搜索出来的结果能给你返回几万字，模型全得消化，自然越来越慢。我在工具配置里统一加了
max_output_chars: 2000，对大部分任务来说这个长度足够了。
另外一个被很多人忽略的：定期清理长期记忆。向量库写满了乱七八糟的旧记忆，会让每次召回变慢，还会引入噪音。我每个季度清一次，把已经完成项目的记忆锁定归档，Query 时排除归档范围。
4.3 企微 Bot 会话用户 ID 加密问题怎么处理
这个问题在热词里出现频率很高，我单独拿出来说。
用 Hermes 接入企微 Bot 时，Webhook 回调消息体里的from字段拿到的不是明文用户 ID，而是一串加密后的字符串。很多人第一反应是找 Hermes 的配置开关，但这里的关键是：加密是企微平台的安全策略，跟 Hermes 本身无关。你需要做的是解密。
企微官方文档里的加密逻辑是 AES-256-CBC，密钥就是你在企微管理后台配置的那个 EncodingAESKey，Token 和 Secret 用于生成签名。解密之后得到的 JSON 串里，userid字段才是你要的真实用户 ID。
我在 Hermes 里是这么处理的：写一个解密模块，挂在回调处理函数前面，先验签再解密，最后把真实 userid 传给后续的 Agent Loop。
from Crypto.Cipher import AES from Crypto.Util.Padding import unpad import base64, hashlib, json def decrypt_wecom_msg(encrypt_msg, encoding_aes_key, token, receive_id): key = base64.b64decode(encoding_aes_key + "=") cipher = AES.new(key, AES.MODE_CBC, key[:16]) decrypted = unpad(cipher.decrypt(base64.b64decode(encrypt_msg)), AES.block_size).decode("utf-8") # 企微解密结果格式: random_msg_len + msg + receive_id # 再按官方规则截取出msg部分 ...这段逻辑你拿去运行时，要注意两点：一是 AES 的 key 和 IV 都用 EncodingAESKey 解码后的前 16 字节；二是解密后的数据要校验末尾的receive_id，跟当前接收方 ID 一致才算成功。踩过坑的人都知道，很多人卡在“解密报错 UnicodeDecodeError”上，八成是没做 PKCS7 padding 的移除。
我把这个解密逻辑封装成了一个 Skill，发给 Hermes 当作“企微消息解析器”，这样 Bot 模式里 Agent 收到消息后，第一步就用这个 Skill 处理加密内容，拿到真实用户 ID，再走后续流程。
4.4 桌面版无法更新及 Skill 不生效的处理
Windows 桌面版无法更新是个经典问题了。我遇到过两次，一次是“检查更新时提示网络错误”，一次是“下载完安装包安装失败”。
前者的常见原因是连接更新服务器不稳定，可以过几小时再试，或者更换网络环境。后者要复杂些，通常是旧版进程还在后台运行，安装程序没权限覆盖文件。解决办法很简单：任务管理器里把所有 Hermes 相关进程结束掉，再以管理员身份运行安装程序。
Skill 不生效的情况，我前面提过配置残留的问题。还有一个常见情况：你在 Agent 的当前会话里新加了一个 Skill，必须重启会话才会加载到模型可用的工具列表里。这不是 Bug，是热加载机制的限制。你要是发现新增的 Skill 怎么都调用不了，先别怀疑配置，重启一次会话再试。
我自己的建议是：每次做重要配置变更后，先跑一个 1 分钟内的冒烟测试任务，确认核心 Loop 正常，再做正式任务。这个习惯帮我省了不少排查时间。
5. 最后再分享一点我的个人心得
这篇文章写到这里，基本上把 Hermes Agent Loop 的关键环节都拆开了。说实话，我自己玩 Agent 最深的体会就一句话：别把 Agent 当黑盒，把它当流程来管理。你每多理解一点 Loop 内部发生的事情，调试 Agent 的能力就强一分。
我推荐你在 Hermes 里养成一个习惯：跑完任务后，花三分钟扫一眼日志，看几个关键指标——总步数、上下文压缩次数、工具调用的失败类型、以及最后一步是不是真的在“收尾”。这四个指标基本能告诉你这次任务跑得“健康”不“健康”。
还有一个小技巧：把常用的“日报生成”这类任务做成 Skill，同时把企微消息解密也做成 Skill，然后组合成一个超级 Skill，我现在跑类似任务，Loop 步数基本能控制在 15 步以内，而且输出稳定度非常高。一开始配置这些会花点功夫，但长期来看，节省的时间和 token 都会成倍地补回来。
