防止 Hermes 智能体令牌浪费并守护本地工作流的操作指南

如何管理无用技能，防止其蚕食内存

Hermes 在完成任务后会自动提取并存储技能。虽然这种自主性令人欣慰，但如果听之任之，m.txt 文件很快就会充斥着重复的逻辑和垃圾代码。未经管理的内存会增加模型的认知负荷，最终浪费您的金钱和时间。

为了维护技能库的“水质”，必须从系统提示词（System Prompt）入手。强制要求“所有技能必须按 IPO (Input-Process-Output) 结构记录”。通过明确环境变量、执行命令和预期结果，可以有效降低智能体随后胡言乱语的概率。每周一早晨，请打开 ~/.hermes/skills/ 目录。将内容与现有技能重叠的文件合并，并将带有特定文件夹路径的代码替换为 $PROJECT_ROOT 等变量。仅靠这种简单的过滤，就能减少不必要的推理步骤，节省近 40% 的总令牌（Token）消耗。

分离配置文件，防止项目间知识混淆

一旦智能体将 A 项目的设置应用到 B 项目，麻烦就大了。Hermes 将所有对话和元数据存储在 state.db 中，作为自由职业者，应根据业务性质隔离此数据库。如果知识混淆，智能体会陷入混乱，而您则会浪费时间进行调试。

在终端中使用 hermes profile create <项目名> 命令创建独立的实例。然后在项目根目录下放置智能体专属的行为指南 SOUL.md，并在 config.yaml 中将 terminal.backend 设置为 local，准备工作即告完成。每次开始会话时，使用 /title 命令标明任务名称，这样以后通过 SQLite 查询过去的解决模式时会容易得多。建立这种结构不到 5 分钟，但当您承接类似项目时，它将成为减少一半初始设计时间的宝贵资产。

混合使用 Claude 与本地模型以节省 API 成本

在所有问题上都使用 Claude 3.5 Sonnet 是对钱包的不尊重。我们需要一种级联策略：仅在架构设计等需要高度思考的任务中使用付费模型，而将简单的代码实现或日志分析交给本地模型。

如果您想将月度预算控制在 5 万韩元左右，请掌握好模型切换的时机。早晨可以使用 Claude，但一旦开始简单的重复性编码，应立即输入 /model custom 命令切换到本地的 Qwen 2.5 Coder 32B。彻夜运行的自动化任务或简单的数据清洗应 100% 由本地模型承担。经常输入 /usage 检查是否超过预算的 80%。一旦超过限额，必须明确规定“从现在起仅使用本地模型”，以防止 API 费用暴涨。

通过沙箱和人工审批阻断幻觉传递

最危险的事情莫过于智能体将错误信息当成真理塞进技能库。一旦内存被污染，它就会持续输出错误的结果。在尊重自主性的同时，必须严格控制可能破坏系统的写入权限。

首先，在 config.yaml 中将 terminal.backend 设置为 docker。首要任务是将智能体隔离开来，无论它做什么都只能在容器内进行。其次，运行一个通过 pytest 自动验证智能体所编写代码的 bash 脚本，确保只有通过测试的代码才能进入内存。最后的堡垒是您自己。修改系统提示词，要求智能体在调用 save_skill 时必须经过用户批准。只有这重三重过滤运作起来，才能防止智能体的幻觉蔓延到您的系统文档中，并保持 99% 的可靠性。

将工作日志转化为盈利指标的数据提取

积累在 state.db 中的数据不仅仅是文本堆砌，更是反映您工作效率的指标。利用 Python 的 sqlite3 库，提取最近一周内每个会话的令牌消耗量和生成的技能数量。

建立一个将提取的数据转换为 Markdown 并存储在个人知识库中的例程。这样哪个项目成本高、哪个逻辑被频繁复用便一目了目。这不仅仅是记录，更是下次项目报价时的强力依据。比起善用智能体，更重要的是将智能体留下的痕迹精炼为值钱信息的能力。如此管理下的 Hermes 将不再仅仅是一个工具，而是吸收了您工作风格的“第二大脑”。