一个会自己长大的"终端助手"

——Hermes Agent 架构与实践

第一章：为什么一个"聊天程序"需要这么复杂的内脏？

“一切从实践中来，一切到实践中去。”
——认识论

实践场景

你在网上看到了 Hermes Agent——一个"AI Agent 框架"。安装很简单：复制一行命令到终端，回车，等它装完。然后你输入hermes，一个聊天界面出现了。

你开始跟它聊天。它回答得不错。但当你深入看它的能力时，你发现它不只是聊天的——它有记忆系统、技能系统、二十多种工具集、可以在多个消息平台上运行、后台自动管理自己的技能生命周期……一个"聊天的程序"，为什么要塞这么多东西？

引出矛盾

从表面看，Hermes 的使用跟 ChatGPT 在浏览器里没什么两样：你输入文字，它回复文字。

但它的架构完全是另一回事。ChatGPT 是一个网页用 HTTP 调一个大模型——简单、在线、别人管。Hermes 是你本地安装的一个程序，它自己在本地跑代码、操作文件、管理记忆、自动生成技能、通过消息网关跑到微信和 Telegram 上去接客——复杂、离线、你自己管。

一个用户第一次看到这些功能的第一反应是：我只是想要一个能帮我干活的工具，搞这么复杂干什么？

这就是核心矛盾：最简单的交互界面（聊天框）下面，藏着最复杂的 Agent 架构。如果你只把它当聊天工具用，这些复杂是浪费。但如果你需要它帮你做真正的事——写代码、管系统、跑任务——这些复杂就是力量。

理论/经验：三层分化

Hermes 的核心能力可以拆成三层：

第一层（你看到的部分） ┌────────────────────┐ │ CLI / TUI / 聊天框 │ ← 你跟它说话的地方 └────────┬───────────┘ ↓ 调用 第二层（你感受到的部分） ┌────────────────────┐ │ 工具执行 / 代码运行 │ ← 它能帮你干活 └────────┬───────────┘ ↓ 驱动 第三层（你不太看到的部分） ┌────────────────────┐ │ 技能 / 记忆 / 网关 │ ← 它变强、记住、跨平台的基础 └────────────────────┘

第一层是门面。第二层是它的"手"。第三层才是它的架构核心——决定了它能自学、能记住你、能同时在多个地方工作。

如果你只需要一个聊天机器人，一三层都可以不要，ChatGPT 就够。但如果你需要的是一个在你机器上、听你指挥、会越用越好用的 Agent，那第三层就是必须修的"内脏"。

回到实践

所以当你第一次输入hermes时，你打开的不是"又一个聊天程序"——你打开的是一个有四层复杂度的 Agent 的最外层界面。你觉得它只是个聊天框，但那个聊天框背后，技能系统在准备知识、记忆系统在加载上下文、工具系统在等待调用、网关在后台待命。

正如最简单的仪表盘背后是最复杂的发动机——Hermes 的聊天框就是它最复杂的架构的最薄的外皮。

第二章：一个 Agent 怎么做到"越用越好用"？

“内因是变化的根据，外因是变化的条件。”
——《矛盾论》

实践场景

你用 Hermes 完成了一个复杂的任务：比如从一堆日志文件中提取错误信息，按严重程度分类，生成一份报告。

Hermes 走了很多步：读文件、写过滤脚本、跑统计、格式化输出。整个过程花了它几分钟。

一周后，你又碰到了类似的任务——换了一个项目，但本质还是"找日志中的错误信息"。这一次，Hermes 明显快了很多。它直接跳过了一些试探性的步骤，上来就写了跟上次类似的脚本。

你心想：我没教过它第二次啊。它怎么好像"学会了"？

引出矛盾

大多数 AI Agent 有一个根本性的局限：它们是静态的。你今天教会它怎么分析日志，它知道了。但明天你再问同样的问题，它不会因为做过一次就做得更好。每一次对话都是"失忆的"——它知道怎么做，但它"不记得"它做过。

理想中的 Agent 应该是：做过一次的事，下次直接复用。就像你学会了骑自行车，两年没骑，再跨上去还是会的。

但 LLM 本身没有"经验积累"的能力——每次对话都是全新的上下文。昨天做过再好，今天也不记得。

这就是核心矛盾：使用频率越高应该越好用，但 LLM 天生做不到这件事。

理论/经验：Curator 技能生命周期管理

Hermes 解决这个矛盾的方法是一个名为Curator的后台子系统。

它的工作方式类似一个"数字工匠"——它观察 Hermes 是怎么干活的，把重复出现的模式固化下来：

你让 Hermes 做一个复杂的分析任务 ↓ Agent Loop 跑完所有步骤 ↓ Curator 认为这个流程值得固化 ↓ 自动生成 SKILL.md 文件 → 保存在 skills/ 目录 ↓ 下次遇到同类需求 → Hermes 直接调用这个技能 ↓ 不需要重新从头推理——已有的经验直接复用

Curator 的核心职责：

关键数据：

回到实践

Hermes 不会因为"你教过它"才变得好用。它会因为在实际使用中重复出现了某些模式，自己把这些模式固化为技能。你不需要刻意"训练"它——你正常用，它就在学。

这就是"内因是变化的根据"——Hermes 不是靠别人给它装插件来变强，是靠自己做过的事积累成经验来自我进化。你用了一年的 Hermes，理论上比刚装的时候多出了几十个累积技能——而这些技能，都是你自己干活的过程中"长"出来的。

第三章：关掉终端，它还记得你吗？

“实践是检验真理的唯一标准。”
——马克思主义

实践场景

你用 Hermes 聊了一整个下午。你跟它说了你的项目背景、你的技术栈、你的编码习惯、你讨厌什么风格、你偏好什么工具。它都记住了，回答越来越贴切。

晚上，你关了终端。

第二天早上，你打开终端又输入hermes。你发现——它还记得你。

你没重新自我介绍，但它知道你是谁、你喜欢什么、你的项目是什么。你直接从昨天断掉的地方继续聊。

引出矛盾

大语言模型本身是没有记忆的。

每次你跟它对话，它看到的上下文都是临时组装的——当前系统提示、之前的对话历史、当前用户输入。一旦对话结束、上下文被清除，模型就没有任何办法"记住"上回的东西。

LLM 就像一个只有短期失忆症的天才——每次见面都像第一次见面。

然而，作为你每天使用的助手，它必须记得：

• 你是谁、有什么特质
• 你的工作习惯和偏好
• 以前聊过的重要话题

这就是矛盾：模型天生无记忆，但 Agent 必须有记忆。

理论/经验：两层记忆架构

Hermes 从两个层面解决记忆问题：

记忆系统 ├── 内置记忆（总是加载） │ ├── MEMORY.md（Agent 的笔记——2200 字符上限） │ └── USER.md（用户档案——1375 字符上限） │ └── 外部记忆（按需检索，可选的 RAG 提供者） ├── Hindsight（知识图谱 + 多策略检索） ├── Honcho（结构化记忆 + 语义检索） ├── Mem0（向量嵌入 + 相似度搜索） └── Supermemory（持续学习）

内置记忆的工作方式：

每次对话开始时，MEMORY.md和USER.md被读入内存，全部注入到系统提示词中。Agent 一开始就知道了：

# MEMORY.md 用户是技术背景，使用 Python 和 JavaScript 为主。 偏好简洁的工具链，不喜欢配置繁重的框架。 正在研究 AI Agent 架构。 # USER.md 姓名：偏好直呼其名 时区：UTC+8 技术栈：Python / Node.js / Docker

这两份文件加起来大约 3575 字符的容量。不是很大，但足够放核心信息。

外部记忆的工作方式：

内置记忆不够用时，可以配置外部 RAG 提供者。这些系统会把大量信息存入向量数据库，只在需要时才检索相关片段。代价是多一次检索调用，换来几乎无限的容量。

回到实践

你关掉终端、再打开，Hermes 叫出你的名字——不是因为它"真的记得你"（从技术上讲，每次启动都是全新的上下文），而是因为每次会话开始时，MEMORY.md和USER.md被注入了系统提示词。

它"看起来记得你"。而当 MEMORY.md 写满 2200 字符时，你要么删旧的腾空间，要么加一个外部 RAG 提供者来扩展容量。这就是内置记忆的物理边界。

每一次"它在终端里记住了你"这个体验，背后都是这两份文本文件被读了一次。

第四章：一个不会干活的 AI 怎么成了你的"工具手"？

“不同质的矛盾，只有用不同质的方法才能解决。”
——《矛盾论》

实践场景

你对 Hermes 说：“看看系统里 CPU 占用最高的进程是什么，告诉我。”

Hermes 说：“好的。” 过了一会儿，它回复你：“目前 CPU 占用最高的是 Chrome，占 32%，其次是 VS Code 占 18%。按这个速度，建议你关掉 Chrome 里不用的标签页。”

它回答得干脆利落。但想象一下这个过程：大模型会写文字，但它不会读/proc/stat，也不会执行ps aux。它怎么"知道"CPU 占用情况的？

引出矛盾

大模型的能力到文字就为止了。它读不了文件、执行不了命令、发不了网络请求。如果用户说"查 CPU 占用"，LLM 只能告诉你"我是一个 AI，无法访问你的系统信息"——因为物理上真的访问不了。

但用户需要的不是一个会说"对不起我做不到"的助手。用户需要的是一个能做事的助手。

这就是核心矛盾：**LLM 只能"说话"，Agent 需要"做事"。"

理论/经验：工具集系统

Hermes 通过工具集（Toolsets）来给 LLM 装上"手"。每个工具集是一组相关功能：

Hermes 的 LLM 在系统提示中不仅收到"你是一个助手"的人格设定，还收到一份工具清单——每个工具的名字、参数说明、返回格式。当 LLM 需要执行操作时，它不会自己去跑，而是输出一个"工具调用指令"：

LLM 推理： 用户想知道 CPU 占用 → 我应该用 terminal 工具执行 ps 命令 → 输出 tool_call: terminal(command="ps aux --sort=-%cpu | head -5") Hermes 的 Agent Loop 拦截到这个调用： → 执行 ps 命令 → 拿到结果 → 把结果喂回 LLM LLM 看到结果： → "Chrome 32%, VS Code 18%..." → 输出自然语言回复

LLM 不需要学会执行命令——它只需要学会什么时候该用哪个工具。执行的事，交给工具集。

回到实践

Hermes 没有"自己动手"的能力。它把"动手"外包给了工具集。当它用 terminal 工具查 CPU、用 file 工具读文件、用 web 工具搜索网页时，你以为它"什么都能做"——实际上它只是什么工具都接得好。

这就是聊天机器人和 Agent 的分界线：

聊天机器人回答你的问题。Agent 帮你把事情办了。区别就是有没有工具集。

第五章：一个终端程序怎么跟二十多个平台打交道？

“矛盾存在于一切事物发展的过程中。”
——《矛盾论》

实践场景

你习惯在终端里用 Hermes。但你今天在外面，只有手机。你想通过 Telegram 继续跟它聊——你发了条消息给它的 bot，它回复了，跟终端里是同一个记忆、同一个人格。

你觉得这很自然，“只是一个消息应用嘛”。但你不知道的是：你刚刚从一个跟自己本机进程聊天的场景，无缝切换到了从一个远程聊天应用里跟同一个 Agent 聊天的场景——而 Hermes 处理这一切只用了一个配置开关。

引出矛盾

Telegram 有它的 Bot API（用 webhook 推送更新）。Discord 有自己的 Gateway + Intents 系统。WhatsApp 走 Baileys 桥或 Business API。Signal 是自己的加密协议。每个平台的认证方式、消息格式、推送机制都完全不同。

如果每个平台都要写一套独立的接入逻辑，那维护成本是不可持续的——二十个平台就是二十份半独立的代码。

但用户的期望是：一个 Agent，所有平台都能用，行为一致。

这就是矛盾：渠道之间的巨大差异和用户对统一体验的期望之间的矛盾。

理论/经验：Gateway + 平台适配器模式

Hermes 的解法是：一个人（Gateway）管理所有平台，每个平台配一个翻译员（适配器）。

Telegram 消息 → Telegram 适配器 → ↓ Discord 消息 → Discord 适配器 → ↓ WhatsApp 消息 → WhatsApp 适配器 → ↓ Gateway 统一调度 Signal 消息 → Signal 适配器 → ↓ ……20+ 平台 → 各自的适配器 → ↓ ↓ Agent Core（唯一的大脑）

每个适配器（Adapter）只做三件事：

1. 监听— 按平台规则收消息
2. 翻译— 把平台特有格式转成 Hermes 统一格式
3. 发送— 把回复转回平台格式发出去

适配器通用接口：

收消息（平台特有格式）——→ 适配器 ——→ 统一消息格式 → Agent Core ↓ 统一回复格式 ←—— 适配器 ←——发回复（平台特有格式）

关键设计原则：添加一个新平台 = 写一个新的适配器文件。核心代码一行不动。

回到实践

你在终端里跟 Hermes 聊天、在 Telegram 上跟它聊天、WebChat 上跟它聊天——你觉得这是"三个不同的 Hermes"。但实际上，终端里的 Agent Core 和 Telegram 里的 Agent Core 是同一个进程跑着的同一段代码。

不同的只是入口的适配器。终端用的是"标准输入输出适配器"，Telegram 用的是"Bot API 适配器"。进了适配器之后，消息格式已经统一了——Agent Core 根本不知道消息是从哪里来的。

这就是"矛盾存在于一切事物发展的过程中"——渠道差异这个矛盾解决了，统一体验就有了。

第六章：你的数据在谁手里？

“有比较才能鉴别。”
——教员

实践场景

你第一次使用 Hermes——你将它从 PyPI 安装，运行后它在本机创建了一个文件夹：~/.hermes/。你所有的对话、记忆、配置、技能，全都躺在里面。

你没被要求注册账号。没有给邮箱。没有同意服务条款（除了 MIT 许可证）。没有任何数据上传到远端。

引出矛盾

今天几乎所有的 AI 产品都是网页/App + 云端服务。你的对话被发送到提供商的服务器上，经过模型处理后返回给你。服务商知道你跟它聊了什么，可能用它训练模型，也可能在数据安全条款里给出限制条件——但你没法真正确认。

另一方面，自托管意味着你要自己处理所有事情：服务器维护、升级、备份、故障排查。

这是一对经典的矛盾：极致的便利（SaaS） vs 真正的控制权（自托管）。

理论/经验：自托管的架构设计原则

Hermes 的架构以"本地运行"为根本前提，所有设计都围绕这个前提展开：

回到实践

当你运行hermes时，没有流量离开你的局域网——除非你配置了需要联网的模型提供商或搜索工具。

你不需要签署任何协议。你不需要信任任何第三方来保管你的对话历史。你需要管理的最大成本是：自己的磁盘空间、自己的 API 费用、自己的升级计划。

对比下来，SaaS 产品像租房：省心，但墙不属于你。Hermes 像自建房：装修靠自己，但墙是你的。

小结

“一切从实践中来，一切到实践中去。”

Hermes 的架构其实就回答了一件事：一个完全属于你自己的 AI Agent，需要哪些零件才能活起来？

答案分成三块：

• 技能系统让它越用越好用— Curator 自动管理技能的出生、活跃和归档
• 记忆系统让它"认识你"— 内置文件每会话加载，外部 RAG 按需召回
• 工具系统让它"能干活"— 20+ 工具集把大模型从"说话者"变成"行动者"
• 网关让它无处不在— 一个核心，二十多个平台

这些零件不是工程师拍脑袋想出来的奢侈品。它们是被人"逼"出来的必需品——你要它记住你，于是有了记忆；你要它帮你干活，于是有了工具；你要它能在各种地方找到它，于是有了网关。

每一个想拥有一台属于自己的 AI Agent 的人，最终都会被这同一个实践驱动着，搭出类似的骨架。Hermes 只是把这个骨架打包好、让你不用从头搭而已。

所以它叫 Agent 框架，而不叫"AI 聊天助手"——因为它从一开始就准备让你拿去自己折腾。