📚 系列导航：上一篇 Hermes Agent 是什么教程 已经讲清“是什么：开源自改进 AI Agent 入门”；本篇聚焦 Hermes Agent 架构；下一篇 Hermes Agent 开源模式说明 继续学习“与 Nous Research：开源模式和商业逻辑”。
先给结论：命令行、桌面 App、网页面板和聊天平台只是不同入口，后面共用同一个 Agent 核心。 换的是脸，不是脑子。理解这一点，后面的记忆、Skill 和跨平台行为才不会看乱。
ℹ️ 版本说明： 原稿基于 Hermes Agent v0.16.0（2026 年 6 月）源码整理。本文保留其版本化机制分析；命令、数量和界面请以 Hermes Agent 官方文档 与本地输出为准。
Hermes Agent 整体架构图
Hermes 的架构图画出来，中间是一个孤零零的圆，叫 AI Agent。外面围着一圈方块：CLI、Ink 做的 TUI、Electron 桌面 App、浏览器管理面板、还有二十多个 IM 平台适配器。所有方块都用线连回那个圆。
这张图的全部信息量就一句话：外面那一圈，没有一个是「另一个 Hermes」，全是同一个核心的不同外壳。
你在 Telegram 上跟它聊，和你在桌面 App 里跟它聊，和你在命令行里敲命令，调用的是同一个 AI Agent 实例的同一套逻辑。换张脸，脑子不换。
Hermes Agent 核心运行循环
AI Agent 这个类，是整个系统的中枢。它有个很扎眼的特征：构造函数吃大约 60 个参数。
凭证、路由、各种回调、会话上下文、预算、凭证池……全塞在一个构造函数里。任何一个写过代码的人看到都会皱眉—这在教科书里叫「上帝对象」，是典型的反面教材。维护者自己也不避讳，在源码的 AGENTS.md 里白纸黑字写着这是个 god object。
但它是故意这么设计的。后面会讲为什么宁可背这个骂名也不拆。
这个大脑对外只开两个口子。一个叫 chat(message) ，扔进去一句话，吐出来一句回复，简单粗暴。另一个叫 run_conversation() ，是完整接口，返回最终回复加上整轮对话的消息列表。日常你用到的所有功能，最终都收口到这两个方法上。
它内部跑的是一个同步循环，不是时髦的 async。带着中断检查、预算追踪，还有一次叫 grace call 的宽限调用。模型说要调工具，它就去调，把结果塞回消息列表，再问模型一次；模型说话说完了，循环结束。默认最多转 90 圈，而且这 90 圈的预算是主 Agent 和它派生的子 Agent 共用的。
Hermes Agent 与 Harness 五组件的对应关系
如果你读过 Harness Engineering 那本橙皮书，会记得一套缰绳框架：指令、约束、反馈、记忆、编排。当时讲的是「你应该怎么给 Agent 套缰绳」。
Hermes 有意思的地方在于，它把这五组件全做成了出厂自带的内建系统。不是你去配，是它本来就长在身上。一一对上号：
| Harness 组件 | Hermes 里是什么 | 一句话 |
|---|---|---|
| 指令层 | Skill 系统 | markdown 技能文件,注入时是 user message 不是 system prompt |
| 约束层 | 工具集开关+沙箱+6 种终端后端 | 该给的权限给,不该碰的关掉 |
| 反馈层 | 自改进学习循环+Curator | 用得越多越好用,还会自己剪掉过时的技能 |
| 记忆层 | SQLite+FTS5+可换的记忆 provider | 本地存、全文索引、跨会话找得回来 |
| 编排层 | 子 Agent 委派+定时任务+Kanban 看板 | 一个 Agent 能指挥一群 Agent 干活 |
这本书后面的章节，基本就是顺着这五行往下挖。每一行都有自己的源码、自己的设计取舍、自己的坑。这一节先把地图铺开，让你知道每块拼图大概在哪。
| 记住这条对应关系。它是整本书的骨架。读到后面任何一个系统觉得绕,回来看这张表,问自己「这是缰绳的哪一组件」,多半就理顺了。 |
|---|
Hermes Agent 使用统一核心的原因
到这里你应该有个疑问。一个吞 60 参数的 god object，明显「不优雅」。这帮人技术不差，为什么不把它拆成几个干净的微服务？
我一开始也这么想。芒格有句话，遇到反常的决策，先别急着说人家蠢，先问问这么干换来了什么。
换来的是一件特别值钱的事：任何平台上，行为完全一致。
因为所有的脸共享同一个大脑，你在桌面 App 里调好的偏好、教会它的习惯、它记住的事，到了命令行、到了 Telegram，全都在。不是「同步」过去的，是本来就是同一个东西，根本不存在两份状态要对齐。一旦拆成微服务，你立刻要面对分布式系统那一整套老问题：状态怎么同步、消息怎么一致、哪个服务是真相来源。
而真正把这个取舍钉死的，是两处不能动的硬约束。
推荐：
prompt cache 不可破。对话中途绝不能改过去的上下文、不能换工具集、不能重建 system prompt—改，缓存全废，每次请求都得重新烧 token。这条约束甚至决定了 Skill 为什么注入成 user message 而不是 system prompt。
不推荐：
几万个测试不能动。整个项目压着将近一万七千个测试。拆架构等于动地基，这么多测试跟着遭殃，工程成本高到不现实。
这两条约束摆在一起，答案就清楚了。这其实不是技术品味问题，而是工程现实主义。当一个上帝对象能换来「所有平台行为一致」，而拆掉它要付出「缓存崩了+几万测试重写」的代价，背着这口锅反而是聪明的选择。
这一版 v0.16.0 做过一次教科书级的重构，恰好印证了这种克制。他们把那个驱动单轮对话、将近 3900 行的巨型方法整体搬进独立模块，原地只留一个薄薄的转发器，还专门用间接解析的写法保证那几万个测试一个都不破。先让大象能被搬动，再谈拆解。不重新设计，不改状态形状，只挪位置。这就是 Hermes 的架构性格—保守、务实、对真实成本有敬畏。
一个大脑，很多张脸。这句话不只是个比喻，它是一个被两条硬约束逼出来的、想清楚了的工程决策。下一节我们换个角度，看看 Nous 到底图什么，要把这么一个东西做出来。
常见问题
Hermes Agent 为什么有多个入口？
不同入口服务不同使用场景，但后面连接的是同一个 Agent 核心。这样可以复用同一套记忆、Skill、工具和配置。
Hermes Agent 为什么没有拆成多个微服务？
原稿认为统一核心有利于保持跨平台行为一致，并避免状态同步和提示缓存失效。具体实现仍应结合当前源码版本判断。
这篇教程里的版本数字会变化吗？
会。原稿以 Hermes Agent v0.16.0 为分析基线，平台、工具、命令参数和默认配置可能继续变化；实际操作前请核对当前官方文档和本地命令帮助。