X / READING NOTE
如果今天从零搭建 Hermes，我会从哪里开始
这篇社区作者文章主张：先让最小的 Hermes 系统稳定完成真实工作，再根据使用证据增加复杂度，并通过只读审计持续改进。
AI 总结与分析 · 请结合原文核验
这篇是《如果今天从零搭建 Hermes，我会从哪里开始》。已读到全文，是社区作者的搭建思路，不是官方更新公告。
核心：不要先堆功能，先让一套最小系统稳定完成真实工作，再根据使用证据增加复杂度。
文章涉及 14 个方面，最值得抓住的是这五点：
1. 信息放对地方，比“记住更多”重要
- 人格与通用行为 → SOUL。
- 跨会话偏好、稳定事实 → Memory。
- 项目规则 → 项目上下文。
- 可复用操作流程 → Skill。
- 讨论过程 → 会话历史。
不要把整个项目和所有操作细节都塞进永久记忆，也不要把整套知识库常驻在提示词里。
2. 临时分工用子 Agent，长期职责才拆 Profile
独立调查、并行研究、第二视角审查，适合临时委派。只有需要长期独立的记忆、技能、配置和定时任务，才值得创建专门 Profile。
作者特别提醒：Profile 分开，不等于文件系统被安全隔离。
3. 先手动跑通，再自动化
一个流程必须在全新会话里，仅靠明确的输入、说明和持久化资料就能完成，才适合定时运行。
作者建议：机械工作交给脚本，需要判断的部分才调用模型；外部能提供事件通知时，优先考虑事件触发，而非一直轮询。
4. 降成本先测量，不要凭感觉删功能
重点看：每次对话默认携带多少上下文、工具定义是否过多、Skill 是否不必要地自动加载，以及模型是不是在重复做确定性的机械处理。
我的理解：优化的不只是模型单价，更是哪些步骤根本不需要调用模型。
5. 最后加的不是功能，而是只读审计
文章结尾建议让 Hermes 检查：哪些东西闲置、重复、过期、费用不必要地高，哪些资料放错了位置，以及备份和恢复准备是否充分。
强调的是：先列可验证事实和改进建议，按影响排序，得到批准后再修改。 不是让 Agent 自行重写整套系统。
我的判断
这篇更像“防止 Agent 配置越用越臃肿”的指南，而不是安装教程。最有价值的标准是：
每增加一个模型、技能、插件或 Agent，都应该说清楚：它解决了哪个已经出现的问题？
中文翻译 · 基于原文快照
目录
如果我的 Hermes 配置明天全部消失，必须从一次全新安装开始重建，我不会先把自己知道的每个 Skill 都重新装上，不会创建十几个 Profile，也不会把所有服务重新连接一遍。
安装只是让 Hermes 运行起来。更难的是决定，哪些东西值得围绕它建立起来。
我想要的是一套组织有序、连接顺畅、顾及成本、能够恢复、易于维护，而且在实际使用后还能协助检查自身的配置。
因此，我会分层重建 Hermes。
不是用上每项功能，不是接入每个集成，也不是第一天就把复杂度拉满。
在宣布配置完成之前，我会先对以下 14 个方面作出决定：
基础：稳定的底座
模型：主要智能与路由
记忆与上下文：信息应该放在哪里
Agent 结构：谁负责工作
工具与权限：Hermes 可以做什么
Skills：可复用的操作流程
插件、MCP 与集成：外部能力
项目与知识：持久的工作空间
自动化：会再次运行的工作
多 Agent 工作流：独立推理与协调
成本与 Token 优化：智能用在了哪里
可靠性与恢复：检查与还原
安全与维护：边界与日常维护
让 Hermes 审计自身：根据真实使用改进
你不必把这 14 个方面全都做到极致。
真正有用的问题更简单：现在该加入什么，什么应该等等，以及什么信号能说明下一层已经值得加入？
第一阶段：搭好基础
1. 基础：先让一套干净的 Hermes 配置正常运行
在考虑记忆、多 Agent 工作流、MCP 或自动化之前，我会先确保那些看似枯燥的基础是牢靠的。
从这些开始：
一套可以正常运行的 Hermes 安装
一个主 Profile
一个明确的工作目录
一个能完成正常对话的提供商和模型
对配置与凭据存放位置的基本了解
这就够了。
Profile 也很重要，但我不会过早增加它的数量。Hermes Profile 会分隔由 Hermes 管理的状态，例如配置、记忆、会话、Skills、cron 任务、日志及相关 Profile 数据。
但这不会自动让该 Profile 变成文件系统沙箱。
之后涉及终端和文件访问时，这一区别很重要。
我的起步原则是：
只使用一个主 Profile，直到某项工作确实需要自己的长期状态。
也要清楚 Hermes 正在从哪个工作目录操作。Profile 身份和工作目录是两项不同的决定。一个 Profile 可以承载 Agent 的状态，而终端工作则从完全不同的位置开始。
初期有用的检查包括：
hermes setup
hermes config
hermes status
hermes doctor
不要在自己不了解的基础上构建系统的其余部分。
2. 模型：先选好一个大脑
Hermes 将处理 Agent 主对话的模型，与支撑压缩、视觉、审批、路由、标题、Skill 搜索和其他后台任务的辅助模型工作区分开来。
先选一个你信任的主模型来承担主要工作。
让辅助模型槽位保持默认的自动行为，直到成本、延迟或任务质量给了你调整它们的理由。
Hermes 也可以维护备用提供商和模型路由。当你不希望限流、提供商故障、凭据问题或其他符合条件的故障中断整个工作流时，配置这些备用路径就有了价值。
本地还是云端，是取舍，不是高下之分。当硬件和工作流确实适合本地推理时，就用本地；当能力、便利性或硬件限制更重要时，就用云端。
我的顺序是：
先确定主模型。
之后再考虑便宜或快速的辅助模型路由。
当连续运行很重要时，再设置备用路径。
确实有理由使用本地模型时，再用本地。
先选好一个大脑，再做路由。
第二阶段：把信息放在正确的位置
3. 记忆与上下文：别把所有东西都放进“记忆”
这是我最早会理顺的方面之一，因为它几乎影响后续的一切。
Hermes 有好几个可以存放信息的地方，而它们不能相互替代。
我是这样理解它们的：
SOUL：Agent 是谁，以及它通常应该如何行事。
内置记忆：值得跨会话保留的少量长期事实和偏好。
项目上下文：属于特定项目或工作空间的规则、约定和信息。
会话历史：对话的实际记录，可以在之后恢复和搜索。
外部记忆：当内置系统已无法完成你所需的工作时，可选用的检索层。
Hermes 支持 HERMES.md、.hermes.md、AGENTS.md 及其他兼容格式的项目上下文文件。我会把属于工作本身而非个人的指令，放在上下文文件里。
“总结写短一些”这样的偏好，可以放进持久记忆。
“这个仓库里的所有报告都必须引用一手来源”这样的规则，则应该放在更贴近项目的位置。
制作这份报告的详细流程，很可能应该放在 Skill 中。
至于你用来理清这一切的那场 200 条消息的对话，仍然是一个会话，不是永久记忆。
Hermes 也支持外部记忆提供商，但我不会仅仅为了让配置显得更高级就装一个。
先从内置记忆和良好的项目上下文开始。
只有当你能清楚说明缺少的是什么工作时，才加入外部记忆，例如更大规模的语义检索、有意在 Agent 之间共享记忆，或你确实需要的其他提供商特有行为。
4. Agent 结构：先用一个 Agent，直到另一个值得承担长期职责
一套全新的 Hermes 配置不需要组织架构图。
先用一个主 Profile，让它负责整个系统。
当这个 Agent 临时需要独立协助时，Hermes 已经有委派机制。被委派的子 Agent 会获得全新的对话和自己的工作上下文，完成界定清楚的任务后，再把结果返回给父 Agent。
这不同于另建一个永久 Profile。
以下工作适合委派：
并行研究
独立审查
分开的编码或调查分支
会向主对话灌入过多上下文的工作
当专门的 Agent 需要有自己持久、独立的运行状态时，再创建另一个永久 Profile 或 Bot：
独立的记忆。
独立的 Skills。
独立的日程。
独立的凭据。
独立的模型或配置。
一个明天仍然由它负责的角色。
原则很简单：
临时的独立工作交给委派，持久的状态则单独分开。
Bot Mode、嵌套委派、Kanban 和常驻专门团队，应放到以后，等到确实有协调问题需要解决时再引入。
第三阶段：有意识地添加能力
5. 工具与权限：决定 Hermes 实际可以触及什么
工具把模型能力转化为行动。
Hermes 可以配置文件、网页搜索、浏览器自动化、终端命令、代码执行、记忆、cron、委派、项目等多种能力。
不要因为将来也许会用到，就把一切都启用。
要问：
这个工作流需要读取什么？
它需要修改什么？
它需要 shell 或代码执行吗？
这些命令会在哪里运行？
哪些动作应该停下来等待批准？
执行位置这个问题很重要。
Hermes 通过本地终端运行命令时，使用的是你的操作系统用户权限。这与在隔离沙箱中运行不是一回事。
如果工作流需要更强的边界，Hermes 也支持隔离程度更高的后端。
能力和隔离是两项不同的决定。
审批也是如此。Hermes 对危险命令有审批控制，而对于 cron 或其他非交互运行等无人值守的工作，则有单独的处理行为。
这里一个有用的检查命令是 hermes tools --summary。
如果你说不清某项能力为什么被启用，就该质疑它是否应该留在这套配置中。
6. Skills：在收集更多之前，先用好 Hermes 自带的内容
Skills 可能是最容易堆砌过度的一层，因为它们很有意思。
Hermes 已经自带了庞大的 Skill 库。
安装外部技能包之前，先了解现有内容。
举几个目前的例子：
hermes-agent：用于使用、配置、扩展和编排 Hermes
grounded-citations：用于需要可验证来源的研究
google-workspace 和 notion：当工作涉及这些服务时，用于生产力工作流
github 配合 software-development Skills：用于编码工作流
humanizer：用于润色面向公众的文字
这些只是例子，不是通用的入门必装包。
另一个重要方面，是 Skills 如何加载。
普通已安装的 Skills 采用渐进式披露。Hermes 先看到精简的索引，等任务需要时才加载完整 Skill。
大多数时候，这正是我想要的方式。
Hermes 也提供更强的预加载选项。
对于单次 CLI 会话，可以通过 --skills 预加载某个 Skill。
如果某个 Profile 的每次新会话确实都需要一套流程，Hermes 支持持久化的 skills.auto_load 配置。
要谨慎使用。
自动加载 Skill 会从会话一开始就放入它的完整指令。对于职责非常固定的 Profile，这可能很有用，但也会牺牲一部分按任务加载所带来的上下文优势。
我使用 Skill 的顺序是：
先用自带的 Skills。
确实缺少某项能力时，再添加外部 Skill。
当 Hermes 学会了与你的工作相关、可重复使用的流程时，再创建自定义 Skill。
只有那些确实适用于该 Profile 几乎所有工作的流程，才自动加载。
然后定期检查已安装的内容，别让 Skill 文件夹变成杂物抽屉。
7. 插件、MCP 与集成：加入能完成任务的最小扩展层
用能解决问题的最小扩展层。
先考虑内置能力或直接集成：如果 Hermes 已经能够清晰直接地支持这项能力，就用它。
Skill：适用于 Hermes 已有工具、主要缺少可复用流程的情况。
MCP：适用于外部 MCP 服务器已经提供你所需工具的情况。
插件：适用于你需要更深入 Hermes 原生层面的东西，例如自定义工具、钩子、命令、提供商、集成行为或 Desktop 功能。
当外部工具服务器已经提供所需能力时，MCP 很有用，而且 Hermes 允许筛选这些工具，而不是自动暴露服务器提供的一切。
插件 可以更深入 Hermes 本身，也正因如此，我会审查插件请求获准做哪些事。
此外还有邮件、日历、GitHub、Notion、浏览器工具和云存储等常规集成。
等服务进入真实工作流时，再连接它。
如果 Hermes 从不碰你的日历，那就不必仅仅因为有连接器，就把日历纳入配置。
第四阶段：给真实工作一个落脚点
8. 项目与知识：给重要工作一个长期存放的位置
重要且反复进行的工作，应有自己的项目或工作空间。
这个项目应有持久保留的指令。
Hermes 通过 AGENTS.md 等文件及其他受支持的上下文格式来支持项目上下文。这样，工作空间可以说明自己的规则，不必让你每次打开新对话都重复一遍。
让这些文件保持精炼。
项目上下文用于存放 Hermes 在该处工作时应始终掌握的信息。
我不会把整个知识库都粘贴到这里。
大型参考文档、源文件、数据集、笔记及其他材料，可以继续作为普通文件或知识来源，在任务需要时由 Hermes 读取。
这样可以缩小始终加载的上下文，也让项目更容易维护。
原则是：
把指令放在工作附近，让参考资料能被工作取用，但不要强行把每一份参考资料都塞进提示词。
当你需要更强的项目组织、Desktop 分组、Kanban 或 worktree 约定时，Hermes 也支持具名 Projects 和多文件夹工作空间。
这些层协同工作时是什么样子
以定期制作的研究简报为例。
主 Profile 负责这项工作。
项目上下文定义主题、来源规则、输出格式，以及简报应该保存在哪里。
记忆承载少量长期偏好，例如简报应该有多简洁。
Skill 保存可重复使用的研究与核验流程。
已启用的工具提供网络研究和文件访问能力。
等工作流能在全新会话中可靠运行之后，再用 cron 每天早上执行它。
如果三个独立研究分支会使主上下文负担过重，就通过委派处理这些分支并返回研究结果。
提供商备用路径能避免模型路由依赖单一提供商。
完整的 Hermes 备份保护逐渐积累起来的配置。
之后，自我审计会检查 Skill 是否仍有用、cron 任务是否健康、闲置工具是否增加了负担，以及工作流是否有哪一部分应该简化。
这就是分层的意义。
它们不是十四项互不相干的功能。
而是同一套运行体系内部的不同职责。
第五阶段：让稳定的工作可以重复执行
9. 自动化：不要给仍需人盯着的工作流设置定时任务
Hermes 的定时任务在全新的 Agent 会话中运行。
这意味着，明天的 cron 任务不能依赖藏在你今天对话中的上下文。
这是一种有益的压力。
它迫使工作流变得能够持久运行。
在安排任何定时任务之前，先手动运行，直到指令、项目上下文、Skill、输入、输出位置和失败条件，从全新会话的角度看也都清楚合理。
然后选择最轻量的路径。
如果工作需要研究、判断、写作或使用工具，那么 Agent cron 任务可能合适。
如果工作纯粹是机械处理，Hermes 支持无 Agent 的 cron 任务：运行脚本并交付输出，而不唤起 LLM。
如果外部系统已经可以在情况变化时通知 Hermes，那就使用 webhook 或事件驱动的激活方式，而不是无休止地轮询。
我的自动化原则是：
把稳定的部分自动化，不要把混乱自动化。
一个好用的周期性工作流，比二十个你已经不记得为何创建的定时任务更有价值。
10. 多 Agent 工作流：当独立性确实有帮助时，再使用更多 Agent
不要问：“我应该有多少个 Agent？”
要问：“这项工作的哪些部分能从独立上下文或并行推理中获益？”
由此可以形成一些有用的模式：
主管与执行者：一个 Agent 对结果负责，并将边界明确的工作委派出去。
研究者与写作者：研究单独进行，避免资料收集挤占写作上下文。
制作者与审查者：一个 Agent 创建内容，另一个用全新的视角检查结果。
并行专家：多个 Agent 同时调查真正独立的不同部分。
这些是工作流模式，不是 Hermes 的特殊模式。
而且有时，答案并不是再加一个 Agent。
机械处理通常更适合交给代码或普通工具，而不是再启动一轮推理循环。
设计中也应该包含人的判断。
如果一项动作面向公众、成本高昂、具有破坏性、涉及敏感事项，或确实取决于个人偏好，就保留人工审批节点，不要把决定埋在执行者链条的某个角落。
更多 Agent 可以增强能力。
也可能增加协调成本。
只有当独立工作的收益值得引入额外系统时，再加入它们。
第六阶段：让系统更便宜，也更容易运维
11. 成本与 Token 优化：开始删东西之前，先测量
依据测量优化，而不是凭直觉。
hermes prompt-size 会显示全新会话在对话开始之前的固定提示词开销。
这个基线可能包含：
Skills 索引
记忆和 Profile 材料
项目上下文
已启用工具的 schema
然后，/usage 会显示当前会话已消耗的用量。
当长会话变得过大时，/compress 可以压缩较早的对话历史。
这些视图比“感觉 Hermes 很贵”能告诉你的更多。
然后寻找架构上的浪费。
主模型是否在做本可交给更快辅助模型的零碎工作？
闲置的工具集是否增加了 schema 负担？
安装的 Skills 是否远远超过实际使用的数量？
是否把本应按任务加载的流程设为了自动加载？
是否让 LLM 在执行本应由无 Agent 脚本完成的确定性检查？
是否让一个巨大的对话承载了本应移入项目、Skill、全新会话或委派任务的工作？
最便宜的 Token，往往是工作流原本就不需要花掉的那个。
先测量，再优化。
第七阶段：让系统经得住问题
12. 可靠性与恢复：知道怎样把系统恢复回来
这一部分，我绝不会留到“以后再说”。
一套认真使用的 Hermes 配置，会积累你在意的东西：配置、凭据、记忆、Skills、会话、Profiles、日程、集成和运行历史。
你应该在真正需要之前，就准备好恢复计划。
Hermes 提供了几个恢复层，而它们解决的是不同问题。
当主推理路径在符合条件的情况下失败时，提供商备用路径能派上用场。
会话和日志帮助检查实际发生了什么。
hermes doctor 帮助诊断配置与依赖问题。
hermes backup 会创建完整的 Hermes 主目录备份，包含更全面的配置，也包含凭据。
hermes import 用于恢复这份完整备份。
Profile 导出的范围则更窄。它适合迁移或分享单个 Profile，并会剔除凭据，而不是像整机完整备份那样工作。
检查点和 /rollback 又是另一个独立层。它们用于恢复受支持的项目或文件更改，不能替代完整的 Hermes 备份。
这些是不同的恢复任务。
我还会至少保存一份最新的完整备份，并把它放在不会受我所防范的机器或存储故障影响的位置。
如果备份只放在那块同样快坏掉的硬盘上，就算不上什么恢复计划。
13. 安全与维护：让系统中各个活动部件保持可理解
你不需要开展一个安全工程项目，但应该知道谁能访问什么。
密钥等秘密信息应该放在受支持的秘密信息或认证存储中，而不是散落在提示词和项目指令里。
审批行为应该经过有意识的设定。
你应该了解执行后端。
安装第三方 Skills、插件和 MCP 服务器，应当是因为它们有工作要做；之后也应像维护第三方软件一样维护它们。
有用的维护入口包括：
hermes update
hermes config check
hermes config migrate
hermes security audit
Skill 更新和审计命令
插件和 MCP 检查工具
安全审计很有用，但要正确看待它：它是在受支持依赖范围内进行的有限供应链扫描，不是证明整套配置安全的证书。
审批和文件写入保护也是如此。
它们降低风险。
但不会把宿主机上的本地执行变成完整沙箱。
如果你已经记不起某个插件为什么安装、某个工具属于哪台 MCP 服务器、某份凭据来自哪里，或某个周期性任务正在做什么，那系统就已经在提醒你该维护了。
第八阶段：让使用经验改进配置
14. 最后一层：让 Hermes 审计自身
最后，我会让系统协助检查自身，而不是再加一项功能。
Hermes 提供了足够多面向读取的信息，可以对自己的环境做出有意义的审计。
一次有用的审计可以查看：
当前 Profile 和配置
主模型和辅助模型路由
备用路径配置
提示词大小基线
记忆和项目上下文的放置位置
已安装及自动加载的 Skills
已启用的工具集
插件和 MCP 服务器
cron 任务及其失败情况
日志及 doctor 的诊断结果
备份与恢复状态
更新和安全状态
目的不是让 Agent 悄悄重写整个系统。
目的是让 Hermes 向你展示真实使用揭示了什么。
我会给它类似这样的指令：
审计这套 Hermes 配置，但不要更改任何内容。检查当前 Profile、模型路由、提示词大小基线、记忆和项目上下文、已安装及自动加载的 Skills、已启用工具、插件、MCP 服务器、cron 任务、近期失败、日志、备份准备情况、审批设置，以及更新和安全状态。告诉我哪些东西看起来没有使用、重复、陈旧、不必要地昂贵、缺失，或处于错误的层级。把你能验证的事实与建议区分开。按实际影响对改动排序，然后在修改任何内容之前等待批准。
搭好配置。
用它做真实工作。
然后，让证据告诉你什么值得改变。
我实际上会先搭建什么
完整的路线图很重要，但我仍然不会一次把所有内容都配置好。
第一个小时
专注于：
一套可以正常运行的 Hermes 安装
一个主 Profile
一个明确的工作空间
一个主模型
关于 SOUL、记忆和项目上下文的基本决定
只启用第一项真实工作所需的工具
运行一次 hermes doctor 检查，并解决其中的重要问题
然后停止配置，开始使用 Hermes。
实际工作一周后
添加那些已由真实使用证明值得加入的东西：
更清晰精炼的项目上下文
用于重复流程的自定义或外部 Skills
一个有用的集成
第一个稳定的自动化流程
提示词和用量测量
一份真正的完整备份
当这套配置确实值得增加复杂度时
再考虑：
辅助模型路由
备用路径链
外部记忆
持久化的 Skill 自动加载
更多插件和 MCP
专门的 Profiles
更深入的多 Agent 协调
隔离或远程执行
事件驱动的自动化
更完善的检查点和恢复流程
持续进行
维护系统：
更新
备份
审计
清理
根据实际使用进行改进
这才是我会信赖的重建方式。
不是模型最多的配置。
不是 Agent 最多的配置。
也不是 Skill 文件夹最大的配置。
一套强大的 Hermes 配置，应该让每一层都有职责，让有用的工作在聊天结束后仍然留存，让恢复成为可能，并且让你能够准确说清楚：为什么下一块组件值得加入。
原文快照 · 完整 · 非原站实时页面
目录
If my Hermes setup disappeared tomorrow and I had to rebuild it from a clean install, I would not start by reinstalling every Skill I know, creating a dozen profiles, or reconnecting every service.
Installation gets Hermes running. The harder part is deciding what deserves to exist around it.
I want a setup that is organized, connected, cost-aware, recoverable, maintainable, and able to help inspect itself after real use.
So I would rebuild Hermes in layers.
Not every feature. Not every integration. Not maximum complexity on day one.
These are the 14 areas I would make decisions about before I called the setup done:
Foundation: stable base
Models: primary intelligence and routing
Memory & Context: where information belongs
Agent Structure: who owns the work
Tools & Permissions: what Hermes may do
Skills: reusable procedures
Plugins, MCP & Integrations: external capability
Projects & Knowledge: durable workspaces
Automation: work that runs again
Multi-Agent Workflows: independent reasoning and coordination
Cost & Token Optimization: where intelligence is being spent
Reliability & Recovery: inspection and restoration
Security & Maintenance: boundaries and upkeep
Make Hermes Audit Itself: improve from real usage
You do not need to max out all 14.
The useful question is simpler: what belongs now, what should wait, and what signal tells you the next layer has earned its place?
Stage 1: Build the base
1. Foundation: get one clean Hermes setup working
Before memory, multi-agent workflows, MCP, or automation, I would make sure the boring foundation is solid.
Start with:
one working Hermes install
one main profile
one known working directory
one provider and model that can complete a normal conversation
a basic understanding of where configuration and credentials live
That is enough.
Profiles matter too, but I would not multiply them early. A Hermes profile separates Hermes-managed state such as configuration, memory, sessions, Skills, cron jobs, logs, and related profile data.
It does not automatically turn that profile into a filesystem sandbox.
That distinction matters later when terminal and file access enter the picture.
My starting rule:
One primary profile until something genuinely needs its own long-lived state.
Also know the working directory Hermes is operating from. Profile identity and working directory are separate decisions. A profile can own the agent state while terminal work starts somewhere completely different.
Useful first checks:
hermes setup
hermes config
hermes status
hermes doctor
Do not build the rest of the system around a foundation you do not understand.
2. Models: choose one brain first
Hermes separates the model handling the main agent conversation from auxiliary model jobs that support things like compression, vision, approvals, routing, titles, Skill search, and other background tasks.
Start with one primary model you trust for the main work.
Let auxiliary slots stay on their default automatic behavior until cost, latency, or task quality gives you a reason to change them.
Hermes can also maintain fallback provider and model routes. Those become worth configuring when a rate limit, provider outage, credential issue, or another qualifying failure should not stop the whole workflow.
Local versus cloud is a tradeoff, not a hierarchy. Use local when the hardware and workflow justify local inference. Use cloud when capability, convenience, or hardware limits matter more.
My order:
Primary model first.
Cheap or fast auxiliary routing later.
Fallbacks when continuity matters.
Local when there is a real reason for local.
Choose one brain first. Route later.
Stage 2: Put information in the right place
3. Memory & Context: stop putting everything into “memory”
This is one of the first areas I would get right because it affects almost everything that follows.
Hermes has several places information can live, and they are not interchangeable.
I think about them like this:
SOUL: who the agent is and how it should generally behave.
Built-in memory: small durable facts and preferences worth carrying across sessions.
Project context: rules, conventions, and information that belong to a specific project or workspace.
Session history: the actual record of a conversation that can be resumed and searched later.
External memory: an optional retrieval layer when the built-in system no longer performs the job you need.
Hermes supports project context files including HERMES.md, .hermes.md, AGENTS.md, and other compatible formats. Context files are where I would put instructions that belong to the work rather than the person.
A preference like “keep my summaries short” may belong in durable memory.
A rule like “all reports in this repository must cite primary sources” belongs much closer to the project.
A detailed procedure for producing that report probably belongs in a Skill.
And the 200-message conversation where you figured all of this out is still a session, not permanent memory.
Hermes also supports external memory providers, but I would not install one just to make the setup feel more advanced.
Start with built-in memory and good project context.
Add external memory only when you can clearly explain the missing job, such as larger semantic retrieval, deliberate shared memory between agents, or another provider-specific behavior you actually need.
4. Agent Structure: one agent until another one earns a permanent job
A fresh Hermes setup does not need an org chart.
Start with one primary profile and let it own the system.
When that agent needs temporary independent help, Hermes already has delegation. A delegated subagent gets a fresh conversation and its own working context, completes the bounded job, then returns the result to the parent.
That is different from creating another permanent profile.
Delegation makes sense for things like:
parallel research
an independent review
separate coding or investigation branches
work that would flood the main conversation with too much context
Create another permanent profile or Bot when the specialist needs a durable operating life of its own:
Separate memory.
Separate Skills.
Separate schedules.
Separate credentials.
Separate model or configuration.
A role it will still own tomorrow.
The rule is simple:
Temporary independence gets delegated. Durable state gets separated.
Bot Mode, nested delegation, Kanban, and persistent specialist teams belong later, when there is a real coordination problem to solve.
Stage 3: Add capability deliberately
5. Tools & Permissions: decide what Hermes can actually touch
Tools are what turn model capability into action.
Hermes can be configured with capabilities for files, web search, browser automation, terminal commands, code execution, memory, cron, delegation, projects, and more.
Do not enable everything because you might use it someday.
Ask:
What does this workflow need to read?
What does it need to change?
Does it need shell or code execution?
Where will those commands run?
Which actions should stop for approval?
The execution question matters.
Hermes running commands through the local terminal is running with the permissions of your OS user. That is not the same thing as running inside an isolated sandbox.
Hermes supports more isolated backends when the workflow needs that stronger boundary.
Capability and isolation are separate decisions.
The same is true for approvals. Hermes has approval controls for dangerous commands and separate behavior for unattended work such as cron or other non-interactive runs.
A useful check here is hermes tools --summary.
If you cannot explain why a capability is enabled, question whether it belongs in the setup.
6. Skills: use what Hermes already ships with before collecting more
Skills are probably the easiest layer to overbuild because they are fun.
Hermes already ships with a large bundled Skill library.
Learn what is already there before installing external packs.
A few current examples:
hermes-agent for using, configuring, extending, and orchestrating Hermes
grounded-citations for research that needs verifiable sourcing
google-workspace and notion for productivity workflows when those services are part of the job
github plus software-development Skills for coding workflows
humanizer for cleaning public writing
Those are examples, not a universal starter pack.
The other important part is how Skills load.
Normal installed Skills use progressive disclosure. Hermes sees a compact index, then loads the full Skill when the task calls for it.
That is what I want most of the time.
Hermes also gives you stronger preload options.
For one CLI session, you can preload a Skill with --skills.
For a profile where a procedure truly belongs in every new session, Hermes supports persistent skills.auto_load configuration.
Use that sparingly.
Auto-loading a Skill puts its full instructions into the session from the start. That can be useful for a profile with one very consistent job, but it also gives up some of the context advantage of task-specific loading.
My Skill progression:
Use bundled Skills first.
Add an external Skill when a real capability is missing.
Create a custom Skill when Hermes learns a repeatable procedure specific to your work.
Auto-load only procedures that genuinely belong in almost everything that profile does.
Then periodically inspect what is installed instead of letting the Skill folder become a junk drawer.
7. Plugins, MCP & Integrations: add the smallest layer that solves the job
Use the smallest extension layer that solves the problem.
Built-in or direct integration first: if Hermes already supports the capability cleanly, use it.
Skill: if Hermes already has the tools and mainly needs a reusable procedure.
MCP: if an external MCP server already exposes the tools you need.
Plugin: if you need something more native to Hermes, such as custom tools, hooks, commands, providers, integration behavior, or Desktop functionality.
MCP is useful when external tool servers already expose the capability, and Hermes lets those tools be filtered rather than automatically exposing everything a server offers.
Plugins can go deeper into Hermes itself, which is exactly why I would review what a plugin is asking permission to do.
Then there are normal integrations such as email, calendar, GitHub, Notion, browser tooling, and cloud storage.
Connect the service when it enters a real workflow.
If Hermes never touches your calendar, your calendar does not need to be part of the setup just because a connector exists.
Stage 4: Give real work somewhere to live
8. Projects & Knowledge: give serious work somewhere permanent to live
Serious recurring work gets a project or workspace.
That project gets durable instructions.
Hermes supports project context through files such as AGENTS.md and other supported context formats. That lets the workspace explain its own rules instead of making you repeat them every time you open a new conversation.
Keep those files tight.
Project context is for the information Hermes should consistently have when working there.
It is not where I would paste the entire knowledge base.
Big reference documents, source files, datasets, notes, and other material can stay as normal files or knowledge sources that Hermes reads when the task needs them.
That keeps always-loaded context smaller and the project easier to maintain.
The rule:
Keep instructions close to the work. Keep references available to the work. Do not force every reference into the prompt.
Hermes also has named Projects and multi-folder workspace support when stronger project organization, Desktop grouping, Kanban, or worktree conventions become useful.
What this looks like when the layers work together
Take a recurring research brief.
The primary profile owns the job.
Project context defines the subject, source rules, output format, and where the brief should be saved.
Memory carries a few durable preferences, such as how concise the brief should be.
A Skill stores the repeatable research and verification procedure.
The enabled tools provide web research and file access.
Once the workflow works reliably from a fresh session, cron runs it every morning.
If three independent research branches would overload the main context, delegation handles those branches and returns the findings.
A provider fallback can keep the model route from depending on one provider.
A full Hermes backup protects the accumulated setup.
Later, the self-audit checks whether the Skill is still useful, whether the cron job is healthy, whether unused tools are adding weight, and whether any part of the workflow should be simplified.
That is the point of the layers.
They are not fourteen separate features.
They are different jobs inside one operating system.
Stage 5: Make stable work repeatable
9. Automation: do not schedule a workflow that still needs babysitting
Hermes scheduled jobs run in fresh agent sessions.
That means tomorrow’s cron job does not get to depend on hidden context sitting in the conversation you had today.
That is useful pressure.
It forces the workflow to become durable.
Before scheduling anything, run it manually until the instructions, project context, Skill, inputs, output location, and failure conditions make sense from a fresh session.
Then choose the lightest path.
If the job needs research, judgment, writing, or tool use, an agent cron job can make sense.
If the job is purely mechanical, Hermes supports no-agent cron jobs that run a script and deliver its output without waking an LLM.
If an outside system can already tell Hermes when something changed, use webhooks or event-driven activation instead of polling forever.
My automation rule:
Automate the stable part, not the confusion.
One good recurring workflow is worth more than twenty scheduled jobs you no longer remember creating.
10. Multi-Agent Workflows: use more agents when independence actually helps
Do not ask, “How many agents should I have?”
Ask, “Which parts of this work benefit from independent context or parallel reasoning?”
That can produce useful patterns:
Supervisor and worker: one agent owns the outcome and delegates bounded work.
Researcher and writer: research happens separately so source collection does not overwhelm the writing context.
Maker and reviewer: one agent creates, another looks at the result with fresh eyes.
Parallel specialists: multiple agents investigate genuinely independent parts at the same time.
Those are workflow patterns, not special Hermes modes.
And sometimes the answer is not another agent.
Mechanical processing is often better handled with code or normal tools than by spawning another reasoning loop.
Human judgment belongs in the design too.
If an action is public, expensive, destructive, sensitive, or genuinely preference-dependent, keep a human approval point instead of burying the decision somewhere inside a worker chain.
More agents can increase capability.
They can also increase coordination cost.
Add them when the independent work is worth the extra system.
Stage 6: Make the system cheaper and easier to operate
11. Cost & Token Optimization: measure before you start deleting things
Optimize from measurement, not instinct.
hermes prompt-size shows the fixed prompt budget of a fresh session before the conversation starts.
That baseline can include things such as:
the Skills index
memory and profile material
project context
enabled tool schemas
Then /usage shows what the current session has consumed.
And /compress can reduce older conversational history when a long session grows too large.
Those views tell you more than “Hermes feels expensive.”
Then look for architectural waste.
Is the main model doing side jobs that could use a faster auxiliary model?
Are unused toolsets adding schema weight?
Did you install far more Skills than you use?
Did you auto-load procedures that should stay task-specific?
Is an LLM performing a deterministic check that should be a no-agent script?
Is one giant conversation carrying work that should have moved into a project, Skill, fresh session, or delegation?
The cheapest token is often the one the workflow never needed to spend.
Measure first. Optimize second.
Stage 7: Make it survive problems
12. Reliability & Recovery: know how to get the system back
This is the part I would refuse to leave until “later.”
A serious Hermes setup accumulates things you care about: configuration, credentials, memory, Skills, sessions, profiles, schedules, integrations, and operating history.
You want a recovery plan before you need one.
Hermes gives you several recovery layers, and they solve different problems.
Provider fallbacks help when the primary inference route fails under qualifying conditions.
Sessions and logs help inspect what actually happened.
hermes doctor helps diagnose setup and dependency problems.
hermes backup creates a full Hermes-home backup that includes the broader setup, including credentials.
hermes import restores that full backup.
A profile export is narrower. It is useful for moving or sharing one profile and strips credentials rather than behaving like a full machine backup.
Checkpoints and /rollback are another separate layer. They are for restoring supported project or file changes, not replacing a full Hermes backup.
Those are different recovery jobs.
I would also keep at least one current full backup somewhere outside the machine or storage failure I am trying to protect against.
A backup living only on the same dying drive is not much of a recovery plan.
13. Security & Maintenance: keep the moving parts understandable
You do not need a security engineering project, but you should know what has access to what.
Secrets belong in supported secret or authentication stores, not scattered through prompts and project instructions.
Approval behavior should be intentional.
The execution backend should be understood.
Third-party Skills, plugins, and MCP servers should be installed because they have a job, then maintained like third-party software.
Useful maintenance surfaces include:
hermes update
hermes config check
hermes config migrate
hermes security audit
Skill update and audit commands
Plugin and MCP inspection tools
The security audit is useful, but treat it for what it is: a bounded supply-chain scan of supported dependency surfaces, not a certificate that the whole setup is secure.
Approvals and file-write protections work the same way.
They reduce risk.
They do not turn host-local execution into a complete sandbox.
If you cannot remember why a plugin is installed, which MCP server owns a tool, where a credential came from, or what a recurring job is doing, the system is already asking for maintenance.
Stage 8: Let usage improve the setup
14. The final layer: make Hermes audit itself
I would finish by making the system help inspect itself, not by adding another feature.
Hermes exposes enough read-oriented information to do a meaningful audit of its own environment.
A useful audit can look at:
current profile and configuration
primary and auxiliary model routing
fallback setup
prompt-size baseline
memory and project-context placement
installed and auto-loaded Skills
enabled toolsets
plugins and MCP servers
cron jobs and failures
logs and doctor findings
backup and recovery state
update and security status
The goal is not to let the agent silently rewrite the whole system.
The goal is to make Hermes show you what real usage has revealed.
I would give it an instruction like this:
Audit this Hermes setup without changing anything. Inspect the current profile, model routing, prompt-size baseline, memory and project context, installed and auto-loaded Skills, enabled tools, plugins, MCP servers, cron jobs, recent failures, logs, backup posture, approval settings, and update/security state. Tell me what looks unused, duplicated, stale, unnecessarily expensive, missing, or in the wrong layer. Separate facts you can verify from recommendations. Rank the changes by practical impact, then wait for approval before modifying anything.
Build the setup.
Use it for real work.
Then let the evidence tell you what deserves to change.
What I would actually build first
The full map matters, but I still would not configure all of it at once.
First hour
Focus on:
one working Hermes install
one primary profile
one known workspace
one primary model
basic SOUL, memory, and project-context decisions
only the tools needed for the first real job
a hermes doctor check with material issues resolved
Then stop configuring and use Hermes.
After a week of real work
Add what real usage has earned:
cleaner project context
custom or external Skills for repeated procedures
one useful integration
the first stable automation
prompt and usage measurement
a real full backup
When the setup earns more complexity
Then consider:
auxiliary model routing
fallback chains
external memory
persistent Skill auto-load
more plugins and MCP
specialist profiles
deeper multi-agent coordination
isolated or remote execution
event-driven automation
stronger checkpoint and recovery routines
Ongoing
Maintain the system:
updates
backups
audits
cleanup
improvements based on actual use
That is the rebuild I would trust.
Not the setup with the most models.
Not the one with the most agents.
Not the one with the biggest Skill folder.
A strong Hermes setup is the one where every layer has a job, useful work survives the chat, recovery is possible, and you can tell exactly why the next piece deserves to be added.