一个会自己长大的终端助手——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 的核心职责职责做了什么频率检测识别哪些经验值得固化为技能每次对话后生成自动写出 SKILL.md 文件触发式审计跟踪哪些技能正在被使用每 24 小时归档超过 21 天未使用的技能自动标记 stale42 天后归档持续恢复归档的技能可随时找回按需关键数据指标含义21 天闲置标记为 stale过期42 天闲置自动归档不删除永远可恢复永不主动删除Curator 最大动作是归档归档回到实践Hermes 不会因为你教过它才变得好用。它会因为在实际使用中重复出现了某些模式自己把这些模式固化为技能。你不需要刻意训练它——你正常用它就在学。这就是内因是变化的根据——Hermes 不是靠别人给它装插件来变强是靠自己做过的事积累成经验来自我进化。你用了一年的 Hermes理论上比刚装的时候多出了几十个累积技能——而这些技能都是你自己干活的过程中长出来的。第三章关掉终端它还记得你吗“实践是检验真理的唯一标准。”——马克思主义实践场景你用 Hermes 聊了一整个下午。你跟它说了你的项目背景、你的技术栈、你的编码习惯、你讨厌什么风格、你偏好什么工具。它都记住了回答越来越贴切。晚上你关了终端。第二天早上你打开终端又输入hermes。你发现——它还记得你。你没重新自我介绍但它知道你是谁、你喜欢什么、你的项目是什么。你直接从昨天断掉的地方继续聊。引出矛盾大语言模型本身是没有记忆的。每次你跟它对话它看到的上下文都是临时组装的——当前系统提示、之前的对话历史、当前用户输入。一旦对话结束、上下文被清除模型就没有任何办法记住上回的东西。LLM 就像一个只有短期失忆症的天才——每次见面都像第一次见面。然而作为你每天使用的助手它必须记得你是谁、有什么特质你的工作习惯和偏好以前聊过的重要话题这就是矛盾模型天生无记忆但 Agent 必须有记忆。理论/经验两层记忆架构Hermes 从两个层面解决记忆问题记忆系统 ├── 内置记忆总是加载 │ ├── MEMORY.mdAgent 的笔记——2200 字符上限 │ └── USER.md用户档案——1375 字符上限 │ └── 外部记忆按需检索可选的 RAG 提供者 ├── Hindsight知识图谱 多策略检索 ├── Honcho结构化记忆 语义检索 ├── Mem0向量嵌入 相似度搜索 └── Supermemory持续学习内置记忆的工作方式每次对话开始时MEMORY.md和USER.md被读入内存全部注入到系统提示词中。Agent 一开始就知道了# MEMORY.md 用户是技术背景使用 Python 和 JavaScript 为主。 偏好简洁的工具链不喜欢配置繁重的框架。 正在研究 AI Agent 架构。 # USER.md 姓名偏好直呼其名 时区UTC8 技术栈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 装上手。每个工具集是一组相关功能工具集能力给 LLM 提供什么terminalShell 命令可以执行ps aux、ls、grep等file文件操作可以读写搜索文件web网页搜索和抓取可以查网络信息code_executionPython 沙箱可以跑脚本、算数据vision图像分析可以看图片delegation子任务可以派活给其他 AgentHermes 的 LLM 在系统提示中不仅收到你是一个助手的人格设定还收到一份工具清单——每个工具的名字、参数说明、返回格式。当 LLM 需要执行操作时它不会自己去跑而是输出一个工具调用指令LLM 推理 用户想知道 CPU 占用 → 我应该用 terminal 工具执行 ps 命令 → 输出 tool_call: terminal(commandps 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只做三件事监听— 按平台规则收消息翻译— 把平台特有格式转成 Hermes 统一格式发送— 把回复转回平台格式发出去适配器通用接口收消息平台特有格式——→ 适配器 ——→ 统一消息格式 → Agent Core ↓ 统一回复格式 ←—— 适配器 ←——发回复平台特有格式关键设计原则添加一个新平台 写一个新的适配器文件。核心代码一行不动。平台适配器做什么Telegram监听 webhook 推送到 GatewayDiscord建立 Gateway 长连接监听事件CLI标准输入输出最简单的适配器桌面应用Electron 原生 IPC 通信回到实践你在终端里跟 Hermes 聊天、在 Telegram 上跟它聊天、WebChat 上跟它聊天——你觉得这是三个不同的 Hermes。但实际上终端里的 Agent Core 和 Telegram 里的 Agent Core 是同一个进程跑着的同一段代码。不同的只是入口的适配器。终端用的是标准输入输出适配器Telegram 用的是Bot API 适配器。进了适配器之后消息格式已经统一了——Agent Core 根本不知道消息是从哪里来的。这就是矛盾存在于一切事物发展的过程中——渠道差异这个矛盾解决了统一体验就有了。第六章你的数据在谁手里“有比较才能鉴别。”——教员实践场景你第一次使用 Hermes——你将它从 PyPI 安装运行后它在本机创建了一个文件夹~/.hermes/。你所有的对话、记忆、配置、技能全都躺在里面。你没被要求注册账号。没有给邮箱。没有同意服务条款除了 MIT 许可证。没有任何数据上传到远端。引出矛盾今天几乎所有的 AI 产品都是网页/App 云端服务。你的对话被发送到提供商的服务器上经过模型处理后返回给你。服务商知道你跟它聊了什么可能用它训练模型也可能在数据安全条款里给出限制条件——但你没法真正确认。另一方面自托管意味着你要自己处理所有事情服务器维护、升级、备份、故障排查。这是一对经典的矛盾极致的便利SaaS vs 真正的控制权自托管。对比维度SaaS AI 产品Hermes自托管数据存放提供商服务器你的机器~/.hermes/账号邮箱注册无账号费用月费或按量计费模型 API 费用你自己选提供商模型选择提供商锁定20 提供商任选可扩展性产品让你用什么就用什么技能、插件、自定义工具理论/经验自托管的架构设计原则Hermes 的架构以本地运行为根本前提所有设计都围绕这个前提展开特性为什么在自托管下更容易完整的文件系统访问读文件、写文件、跑脚本——没有沙箱限制本地技能文件skill/ 目录就是文件系统上的文件夹你直接操作文件SQLite 状态数据库不需要云端数据库一个 .db 文件管所有会话无需注册没有用户中心、没有后台管理页面——你即管理员灵活配置改 config.yaml 就生效没有管理员审核流程回到实践当你运行hermes时没有流量离开你的局域网——除非你配置了需要联网的模型提供商或搜索工具。你不需要签署任何协议。你不需要信任任何第三方来保管你的对话历史。你需要管理的最大成本是自己的磁盘空间、自己的 API 费用、自己的升级计划。对比下来SaaS 产品像租房省心但墙不属于你。Hermes 像自建房装修靠自己但墙是你的。小结“一切从实践中来一切到实践中去。”Hermes 的架构其实就回答了一件事一个完全属于你自己的 AI Agent需要哪些零件才能活起来答案分成三块技能系统让它越用越好用— Curator 自动管理技能的出生、活跃和归档记忆系统让它认识你— 内置文件每会话加载外部 RAG 按需召回工具系统让它能干活— 20 工具集把大模型从说话者变成行动者网关让它无处不在— 一个核心二十多个平台这些零件不是工程师拍脑袋想出来的奢侈品。它们是被人逼出来的必需品——你要它记住你于是有了记忆你要它帮你干活于是有了工具你要它能在各种地方找到它于是有了网关。每一个想拥有一台属于自己的 AI Agent 的人最终都会被这同一个实践驱动着搭出类似的骨架。Hermes 只是把这个骨架打包好、让你不用从头搭而已。所以它叫 Agent 框架而不叫AI 聊天助手——因为它从一开始就准备让你拿去自己折腾。