我最近被一个场景狠狠干了一下。

不是复杂重构。 不是多文件联调。 就是一句很普通的话：把 index.html 里那张图片的宽度从 800 改成 400。

结果 Hermes 跑了将近2小时。

日志很典型：

• 先读文件

• 再想该用哪个工具

• 然后尝试生成修改方案

• 接着验证

• 不放心，再读一遍

• 再改一轮

• 再验证一轮

API 不慢。 网络没炸。 模型也不是完全拉胯。

（连续的通配符*在读取文件）

真正的问题是：Hermes 的默认配置，适合“通用 Agent”，不适合“直接改文件”。

尤其是 HTML 这种任务，很容易触发一个尴尬局面：

它明明只需要像一个利索的工程助手，快速读、快速改、快速验； 但默认配置却让它更像一个准备写调研报告的全能顾问。

所以我就讲一下这次我优化的一些方法，希望可以帮助到hermes很慢的朋友（PS：我是先安装了openclaw，然后安装hermes时做了迁移）。

目标很明确：让 Hermes 在 HTML 修改场景下，少绕路、少空想、少反复，像个会干活的工程工具。

---

一、先别怪模型，先认清 HTML 小改动为什么会被拖慢

Hermes 默认是按“广义 Agent”设计的。

这意味着它天生会做几件事：

• 尽量思考完整

• 尽量选择最合适的工具

• 尽量验证结果

• 尽量保留上下文连续性

这些设计在大任务里是加分项。

比如排查线上 bug、写一整页功能、跑多步调研，这种“先想清楚再动手”的风格很值钱。

但到了 HTML 小修改场景，问题就来了。

你要的其实不是“全面规划能力”，而是下面这套动作：

• 快速定位文件

• 快速改一处

• 快速确认没改错

• 结束

而 Hermes 默认配置里，恰好有几件事会把这个链路拉长：

1. 工具太多

CLI 默认 hermes-cli 预设工具很全。

对复杂任务当然好。 但对“改一个 HTML 属性”这种场景，工具越多，模型越可能先犹豫：

• 用 file 还是 terminal？

• 要不要 browser？

• 要不要再顺手检查别的资源引用？

• 要不要先生成补丁再验证？

工具多，不一定让它更快，反而可能让它更像在开会。

2. 思考强度默认不低

reasoning_effort 默认是 medium。（PS：很多人为了效果，模型都设置xhigh，这个其实也会增加耗时）

这意味着模型会更愿意多想几步。

对于“改业务逻辑”“拆需求边界”是好事。 对于“把文件进行微小调整”这种任务，就是过度慎重。

3. 迭代预算太宽

agent.max_turns 默认是 60。

这个值对开放式任务很友好。 但对小修复，它等于给了模型很大的“反复试、反复验、反复再想一轮”的空间。

4. 上下文经常太脏

如果你前面刚拿 Hermes 干过别的事，比如：

• 看文档

• 跑搜索

• 读了一堆日志

• 分析了一坨报错

那你当前会话的上下文，很可能已经不再适合做“小文件快改”。

这时候模型不是单纯在改 HTML。 它是在一大坨历史上下文里，努力判断“这次是不是也要那么谨慎”。

5. 简单活也在用主模型硬扛

如果你一直用同一个主模型处理所有事情，那简单任务也会走同一套重型链路。

这在“本地 HTML 小修改”里很浪费。

因为这种任务本来就更适合：

• 低思考

• 快工具调用

• 少轮次完成

也就是说，慢的根源，很多时候不是模型不行，而是默认配置把简单活做复杂了。

---

二、第一刀：先把工具范围砍小，别让它每次都开全家桶

这是我觉得最值的一刀。

Hermes 做 HTML 小改动时，最常见的高效链路其实就两类：

• file

  ：读文件、patch、写文件、搜索

• terminal

  ：执行命令、跑校验、看目录、做简单验证

大多数场景下，这就够了。

如果你每次都让它带着 web、browser、vision、image_gen 一起上，它就更容易把一个本地修改任务，当成一个“要不要顺手调查更多信息”的综合任务。

最快的做法：按会话收缩工具

hermes chat -t terminal,file

这个方式最稳。

因为它不会动你的全局配置，只对当前这次会话生效。

如果你经常就是拿 Hermes 干本地改文件，还可以改 CLI 的平台工具配置。

platform_toolsets:
  cli: [terminal, file, skills, todo]

这里有两个细节要注意：

• 别再写顶层 toolsets: 了。

   这个键现在已经是 deprecated。

• 如果你的目标是“本地 HTML 快改”，browser 通常不该是默认工具。只有你真要做像素级、交互级页面检查时，再临时加回来。

这一步解决的是：工具选择成本。

工具范围一小，Hermes 的动作会明显更直接。

---

三、第二刀：把思考强度从“研究员”降回“工程师”

Hermes 当前示例配置里：

agent:
  reasoning_effort: "medium"

官方说明也写得很清楚：这个值控制模型在回答前要做多少“thinking”。

对 HTML 小修改，我的建议很直接：

默认改成 low

agent:
  reasoning_effort: "low"

如果你现在就是做这种非常机械、边界极清楚的小修改，甚至可以继续往下压：

agent:
  reasoning_effort: "minimal"

为什么这一步有用？

因为 HTML 小修复的关键，不是“思考深度”，而是“执行路径短”。

比如：

• 改一个宽度

• 改一个 class

• 替换一张图

• 调整一段 CSS

• 补一个 meta 标签

这些都更接近确定性编辑任务。

你不需要它像架构评审一样想半天。 你需要它像一个熟练开发一样：读、改、验、收工。

如果你是交互式 CLI，也可以直接在会话里临时调：

/reasoning low

这一步解决的是：过度思考。

---

四、第三刀：把 max_turns 收紧，别给它 60 轮反复自证

Hermes 示例配置里，默认是：

agent:
  max_turns: 60

官方注释写得也很直白：

• 20~30 更适合 focused tasks

• 50~100 更适合 open exploration

HTML 小修改显然属于前者。

所以更合理的配置应该是：

agent:
  max_turns: 20

如果你想更激进一点：

agent:
  max_turns: 12

这一步的价值，不是为了“卡死模型”，而是为了告诉它：

这不是一个值得无限展开的任务。

你给 60 轮，它就更容易：

• 再验证一遍

• 再换一种改法

• 再多做一次保险检查

• 再补一层解释

你把预算收紧，它会更倾向于第一时间选择最短执行链。

对 HTML 修改来说，这种约束不是副作用，反而是优化。

这一步解决的是：迭代失控。

---

五、第四刀：让简单任务别再硬吃主模型，开 Smart Model Routing

如果你的主模型本来就是为了复杂任务准备的，那它在小任务上浪费时间，其实很正常。

Hermes 在示例配置里已经给了这个入口：

smart_model_routing:
  enabled: true
  max_simple_chars: 160
  max_simple_words: 28
  cheap_model:
    provider: openrouter
    model: google/gemini-2.5-flash

它的意思很简单：

• 简单请求，走便宜快模型

• 复杂请求，还是回主模型

这特别适合下面这种命令：

• 把某个 class 名改掉

• 替换一张图的尺寸

• 修一个 HTML 属性

• 调一下 CSS 间距

• 在一个文件里补一段标签

这些请求的共同点是：

• 指令短

• 目标明确

• 不需要长链推理

• 更考验执行速度，而不是聪明程度

如果你不做这层路由，Hermes 就会把“改一个宽度”和“排查一个复杂页面问题”都交给同一个大脑。

这当然不经济。

这一步解决的是：简单任务模型过重。

---

六、第五刀：把上下文管起来，小修复要单开干净会话

这一步最容易被忽视。

很多人会以为“都在同一个项目里，同一个会话接着做就行”。

错。

对 HTML 小修改来说，脏上下文本身就是性能问题。

Hermes 的自动压缩默认是：

compression:
  enabled: true
  threshold: 0.50
  target_ratio: 0.20
  protect_last_n: 20

这套默认值对通用协作没问题。

但如果你在一个已经很长的会话里，突然插进一句：

把 index.html 里那张图片宽度从 800 改成 400

模型每轮都得先背着前面那堆历史跑。

更糟的是，默认还会保护最近 20 条消息。 这会让“刚才那些复杂讨论”继续影响当前这次简单编辑。

我的建议是两步一起做

1）HTML 小修复单开新会话

直接 /new，或者新开一轮 hermes chat。

这比你在老会话里硬拖着上下文干活，通常更快。

2）把压缩阈值调得更激进一点

compression:
  enabled: true
  threshold: 0.35
  target_ratio: 0.15
  protect_last_n: 12

这套值不是唯一答案。 但它的思路很关键：

• 更早压缩

• 少保留无关尾部

• 给简单任务更干净的近场上下文

如果你恰好用的是支持 prompt caching 的链路，这种“干净会话 + 稳定前缀”的方式，通常也更容易吃到缓存收益。

说白了，这一步解决的是：上下文污染。

---

七、还有一刀是 bonus：如果模型老爱说不爱做，开 tool_use_enforcement

这个配置不是每个人都必须动。

但如果你用的是某些第三方兼容接口，或者模型经常出现这种行为：

• 先描述自己打算怎么做

• 讲一段计划

• 再犹豫一下

• 迟迟不调用工具

那就该试试这个：

agent:
  tool_use_enforcement: true

代码里这个配置的语义也很明确：

• auto

  ：默认，只对部分模型自动注入

• true

  ：所有模型都强制注入执行导向提示

• false

  ：不注入

• list

  ：按模型名子串匹配

它的作用不是让模型更聪明。 而是让模型更少出现“嘴上说会做，手上不调用工具”的情况。

对本地 HTML 修改这种任务，这一步有时能明显减少空转。

---

八、我自己会怎么配：给 HTML 小修改单独准备一套轻量配置

如果你经常用 Hermes 干这类活，我建议直接准备一个偏“本地快修”的配置口径。

你不一定要做成独立 profile。 但至少要形成一套稳定默认值。

比如我会更倾向于这样：

agent:
  max_turns: 20
  reasoning_effort: "low"
  tool_use_enforcement: true

compression:
  enabled: true
  threshold: 0.35
  target_ratio: 0.15
  protect_last_n: 12

smart_model_routing:
  enabled: true
  max_simple_chars: 160
  max_simple_words: 28
  cheap_model:
    provider: openrouter
    model: google/gemini-2.5-flash

platform_toolsets:
  cli: [terminal, file, skills, todo]

然后真正开工时，再配合这类启动方式：

hermes chat -t terminal,file

这套组合的核心思想只有一句话：

把 HTML 小修改，从“广义 Agent 任务”重新降级成“聚焦编辑任务”。

一旦你这么做，Hermes 的行为会明显更像你想要的样子：

• 少解释

• 少摇摆

• 少反复读

• 少绕远路

• 更快落到文件修改本身

---

九、结尾：Hermes 慢，不一定是 API 慢，更可能是你把小活配成了大活

很多人碰到 Agent 慢，第一反应都是：

• 模型不行

• 接口不行

• 网络不行

但这次我踩下来最大的感受是：

Hermes 在 HTML 修改场景下，很多“慢”其实是配置慢，不是推理慢。

工具太宽，动作会犹豫。 思考太重，执行会变慢。 轮次太松，验证会泛滥。 上下文太脏，简单任务也会被拖进复杂链路。

而你一旦把这 5 个旋钮调顺：

• 工具收窄

• 思考降级

• 轮次收紧

• 简单请求分流

• 上下文做减法

Hermes 处理 HTML 小修改，才会真的像个工程助手，而不是像个准备写方案会的顾问。

---

最后留一个问题。SOUL.md文件的配置，默认是通用的，你还要根据自己对hermes的使用要求，进行定义。

你现在给 Hermes 的默认配置，更像“全能顾问”，还是“本地快修工程师”？