我从 Hermes 文档里挖出了 6 个"反直觉"的设计

上一篇文章写完之后，我又把 Hermes 的文档翻了一遍，专门看"技巧与最佳实践"这一节。

结果发现——这个章节不是给你塞技巧的，是告诉你它为什么这样设计。

读完之后我整理了 6 个"反直觉"的设计细节，忍不住想说。

一、"不要手把手教，让它自己探索"

文档里有这么一句话：

不要说"打开 tests/test_foo.py，看第 42 行，然后……" 说"找到并修复失败的测试"

一开始我觉得这不是废话吗？谁会手把手教 agent。

但仔细回想了一下我自己的使用习惯——我还真经常这么做。

遇到问题，我会习惯性地把解决路径拆得很细："你先做什么，然后做什么，最后做什么"。

为什么？

因为我不信任它能自己想清楚。

但 Hermes 的设计逻辑是：你应该信任 agent 的工具能力。

它有文件搜索、有 terminal 访问、有代码执行能力——你拆解步骤反而限制了它。正确的用法是告诉它目标，让它自己规划路径。

这其实是一个关于"信任边界"的问题。

你手把手教，是在缩小它的行动空间，也是在消耗你自己的时间。

二、上下文文件是"设置一次，永久生效"

文档里提到了一个细节，很多人可能没注意：

如果你反复输入相同的指令——比如"我们用 tab 不用空格"、"测试用 pytest"、"API 地址是 /api/v2"——这些不需要每次都说一遍。

放进项目根目录的 AGENTS.md，每次会话 agent 会自动读取，永久生效。

这条看起来简单，但细想有点意思。

大多数框架把"项目规则"当作 context 的一部分，需要你每次手动注入。

Hermes 的做法是把规则沉淀到文件里，让 agent 自己去读。

好处是什么？

• 减少重复指令
• 规则不会因为某次忘记说而出错
• 新开一个 session，规则依然在

而且它还兼容 .cursorrules 文件——如果你之前用 Cursor 或 Windsurf，这些规则不用重写，Hermes 直接读。

这本质上是把"项目知识"持久化的思路。

三、记忆和 Skill 是两件不同的事

文档里明确区分了记忆（Memory）和 Skill：

• 记忆：存"是什么"，事实、环境、偏好
• Skill：存"怎么做"，流程、最佳实践、可复用方案

一开始我觉得这个区分有点学究气，用起来差不多吧？

后来仔细想了一下，发现这个区分有实际意义。

记忆是 agent 自己积累的，它在干活过程中发现什么，就往记忆里写。Skill 是你主动创建的，或者让 agent 从某个流程里提炼出来的。

记忆像是经验沉淀，Skill 像是标准操作手册。

而且 Skill 有个很实用的设计：它用了"渐进式加载"（progressive disclosure）。

Level 0 只加载 skill 列表，Level 1 加载完整内容，Level 2 只加载某个具体文件——不是把所有 skill 内容全塞进 context。

用到的才加载，不用不占空间。

四、"不要破坏 Prompt 缓存"——这条很多人不知道

文档里有一条成本优化的建议：

保持系统 prompt 稳定，同一会话的后续消息会命中缓存，成本显著降低。

这背后是什么原理？

大多数 LLM 提供商（OpenAI、Anthropic 等）会对系统 prompt 的固定前缀做缓存。如果你每次消息都改变系统 prompt（加了新的上下文文件、改了配置），缓存就失效，每次都要重新计算。

所以 Hermes 的建议是：在一个会话里尽量保持上下文一致，不要频繁切换模型或修改配置。

会话中途切换模型听起来很方便，但实际上每次切换都会导致缓存失效，成本反而更高。

这条技巧的价值不在"省多少钱"，在于它提醒了一件事：

AI 对话也有"性能优化"的概念，不是越灵活越好。

五、会话中途可以切换模型，但代价要清楚

说到切换模型，文档里其实支持在会话中途用 /model 切换。

但紧接着就给了两条忠告：

• 复杂推理用前沿模型（Claude Opus、GPT-4o）
• 格式化、重命名等简单任务切换到更快的模型

这其实是一个很务实的建议。

我一直以为应该"选一个好模型，一直用它"，但实际上：

• 复杂任务确实需要强模型
• 简单任务用强模型是浪费

文档里还有个更狠的功能：/compress。

长会话积累了大量 token 之后，运行这个命令，agent 会对对话历史做摘要，保留关键上下文，大幅减少 token 消耗。

这不是压缩，是"提炼"。

六、安全设计不是摆设，是真的在认真考虑危险场景

文档里有几条安全相关的建议，我挑两条说。

第一条：不要在有终端访问权限的 bot 上设置 GATEWAY_ALLOW_ALL_USERS=true。

这条看起来简单，但很多人图省事就会这么干。文档用了"永远不要"这个词，很绝对。

第二条：关于"始终允许"审批。

危险命令审批有四个选项：once（仅一次）、session（本次会话）、always（始终允许）、deny（拒绝）。

文档的建议是：选 "always" 之前仔细考虑，因为它会永久将这个命令模式加入白名单。在熟悉之前，先用 "session"。

然后它还加了一句：

命令审批是你的安全防线。不要在生产环境中禁用此功能。

这句话我比较认同。

安全功能最怕的是"用起来麻烦所以关掉"，Hermes 的做法是把审批流程做得很细致——它知道你可能会嫌麻烦，所以给了不同级别的选项，但底线是"不要关掉"。

最后说两句

翻完这堆技巧，我最大的感受是：

Hermes 的设计者真的在认真想"怎么让一个人用好这个工具"。

不是功能越多越好，不是所有功能默认全开。

它把很多选择权交给你，但同时告诉你每个选择的代价是什么。

用好 Hermes，不在于你会用多少高级功能，而在于你理解了多少它的设计逻辑。

理解了，你用起来会越来越顺。 没理解，就容易卡在"明明功能很强但就是用不好"的阶段。

以上是我读官方技巧文档的个人解读，供你参考。