AI Agent 新范式:会记忆、会调度、会进化的 Hermes Agent 全解析

我有个朋友，是一名独立开发者，同时跑着三个项目。他从去年开始用 AI 助手辅助写代码，用了大半年，每天早上打开对话框的第一件事，还是粘贴一段固定的上下文说明：

"我的项目是 Rust + Axum，使用 SQLx 操作 PostgreSQL，代码风格用 Tab 缩进，120 字符换行，不要用 sudo 运行 Docker……"

他跟我说，这件事让他每天都有一种奇妙的挫败感——用了这么久，AI 对他的了解，还停留在"第一次见面"的水平。

这不是个例。这几乎是所有人使用 AI 助手的共同体验。

原因说穿了也简单：大多数 AI 工具是无状态的。你关掉对话窗口，它就忘了你。任务完成了，经验清零了。每一次交互都是从零开始，它不记得你，不了解你，更谈不上"越用越顺手"。

这背后有一个更深层的问题：我们一直在把 AI Agent 当作工具在用，但工具是不会成长的。

2026 年 2 月 25 日，Nous Research 发布了 Hermes Agent。这个项目在 GitHub 上突破了 15.6 万+ Star（5月中）。热度背后，是一批真实用户从其他 Agent 迁移过来之后发出的那种感叹——"这才是我想要的 Agent 该有的样子"。

这篇文章不是产品评测，我想做的是借助 Hermes Agent 的架构设计，聊清楚一件事：一个真正成熟的智能体系统，到底应该长什么样子？

一、我们真正需要的 Agent 是什么

在拆解 Hermes 之前，先退一步想清楚一个问题：现有的 Agent 到底差在哪里？

我把常见的问题归纳成三点，姑且叫它 Agent 的"三原罪"。

第一罪：无状态。每次对话从零开始，没有跨会话的记忆，关掉窗口就失忆。

第二罪：无积累。即便完成了复杂的任务，那段经验也不会变成它下次可以直接调用的"方法"。它只是执行，不会从执行中学习。

第三罪：无自主。它只能等你触发。你不来，它不动。没有能力主动去做那些不需要你每次都手动发起的重复性工作。

这三点加在一起，造成了一种根本性的体验缺失：你用的时间越长，感受到的进步越少。

那么，一个真正成熟的 Agent 应该满足什么条件？

我认为可以用三个维度来衡量一个 Agent 的架构成熟度：记忆的深度、调度的广度、进化的能力。

记忆的深度，决定了它是否真正了解你；调度的广度，决定了它能否主动帮你工作；进化的能力，决定了它会不会越用越懂你。

Hermes Agent 的整套架构，其实就是围绕这三件事展开的。

二、架构全景——六层设计，每一层都有它的道理

我们先看全貌，再往里走。

Hermes Agent 的架构分为六层，从上到下依次是：用户接入层、核心引擎层、消息平台层、工具层、基础设施层、LLM 提供商层。

光看这个分层，你可能觉得和其他框架差不多。但每一层背后的设计决策，才是真正值得拿出来说的地方。

用户接入层：无处不在，才是真正的入口

Hermes 支持七种接入方式：命令行 CLI、终端 TUI、IDE 插件、API 服务、消息网关、批量运行、定时任务。

这不是为了"功能丰富"而堆功能。背后是一个明确的设计主张：Agent 不应该被绑在某个入口，它应该活在你已经在用的地方。

你在终端工作，它陪你在终端；你习惯用 Telegram 发消息，它就住在你的 Telegram 里；你需要它在你睡觉的时候跑一个批量任务，它自己知道怎么做。

更关键的是，接入层与核心引擎完全解耦。无论你从哪个入口进来，走的都是同一条核心处理管道。这种设计才能让 Agent 真正做到"平台无关"——换个入口，不影响任何行为逻辑。

核心引擎层：编排才是灵魂

这是 Hermes 架构里最重要的一层，也是它和大多数其他 Agent 框架拉开差距的地方。

Hermes 的核心是 AIAgent Loop，而不是网关控制面。这是一个刻意的设计选择——学习循环是第一优先级的架构关切。

这一层里有五个子模块，每一个都值得单独说一说：

Prompt 组装器：不是让人手写 Prompt，而是系统自动将记忆、技能、工具描述、上下文，按照优先级动态拼装成每次调用的完整输入。Prompt 工程应该是系统行为，而不是人工艺术。

比例阈值压缩：当上下文超出模型的窗口限制时，自动按照信息密度和重要性进行压缩。这解决了长任务中的"上下文溢出"问题，让 Agent 能处理真正复杂的长流程任务。

工具注册与调度：工具不是硬编码进去的，而是通过注册机制动态加载。Agent 在运行时根据任务需要，自主决定调用哪个工具、按什么顺序调用。工具是一等公民，不是硬编码的函数。

会话存储（SQLite + FTS5）：所有对话历史存入本地 SQLite 数据库，并建立 FTS5 全文索引。这让 Agent 能够在几个月后的对话里，精确检索出你三个月前讨论过的某个细节。

模型适配层：对上层屏蔽具体的 LLM 实现，任何 OpenAI 兼容的接口都能接入。换模型只需一行命令，不改业务逻辑。

消息平台层：网关是循环的一部分

Hermes 支持 20 多个消息平台，包括 Telegram、Discord、Slack、WhatsApp、飞书、钉钉、微信、QQ 机器人等。

但比"支持多少平台"更重要的，是它处理消息的方式。

大多数 Agent 框架里，消息平台是外挂在核心逻辑外面的"接口层"。而在 Hermes 里，网关是同一个循环的一部分。一条消息可以触发技能创建，一个定时任务的输出也通过同一套网关路由回来，跨平台的会话连续性因此得以真正实现——不是拼凑出来的，是架构上原生支持的。

这个区别在实际使用中非常明显：你在 Telegram 发消息让它开始一个任务，它在服务器上执行，完成后再通过同一个 Telegram 把结果发回给你。整个过程是一个完整的闭环，而不是三个独立的系统碰巧连在一起。

工具层：40+ 工具，自动发现

工具层包含六大类：终端执行（支持 8 种后端）、文件操作、网络搜索、浏览器控制、子代理、MCP 集成，以及记忆工具。

这里值得关注的，不是工具的数量，而是工具注册与调度分离的设计思想。

工具不是在启动时就固定好的，而是通过注册中心动态管理的。Agent 在执行任务时，会根据当前任务的语义，自动发现并调用合适的工具。这让系统具备了真正的可扩展性——加一个新工具，不需要修改核心逻辑。

基础设施层：三个可插拔系统

可插拔记忆、技能系统、插件系统，构成了 Hermes 的基础设施底座。

"可插拔"这个词很关键。Hermes 内置了 8 个记忆后端，包括 Honcho、Mem0、Hindsight、Supermemory 等，可以根据场景选择不同的记忆方案。本地记忆不够用的时候，无缝接入云端语义记忆服务。

这里体现的是一个重要的架构原则：基础设施与业务逻辑分离，才能让系统在不同规模和场景下都能运转。

LLM 提供商层：模型无关性

对于国内用户，Hermes 原生支持 DeepSeek、通义千问（Qwen）、GLM 智谱、MiniMax、KIM 等国产模型，同时也支持 OpenRouter 上的 200+ 模型。

切换模型只需要一条命令：hermes model，不需要改任何代码，不被任何平台锁定。

这背后的架构原则是：模型适配层应该是抽象接口，而非具体依赖。你用什么模型，是部署配置的问题，不应该渗透到应用逻辑里。

三、记忆系统——Agent 如何真正"记得住"

记忆是区分一个"能用的工具"和一个"真正的助手"的核心能力。但记忆这件事，远比听起来复杂。

问一个关键的问题：什么样的信息，应该以什么样的方式被记住？

不同类型的信息，有完全不同的访问模式。你的编码偏好，每次会话都需要用到，应该常驻在上下文里；三个月前某次讨论的技术决策，偶尔需要检索；某个复杂任务的执行方法，需要能被复用和改进。把这三种信息都塞进同一个"记忆数据库"里，要么太贵（每次都全量注入），要么太慢（每次都要检索），要么太死（只记事实，不记方法）。

Hermes 的解法是三层记忆栈。

第一层：冻结式系统 Prompt 记忆（热记忆）

两个文件：MEMORY.md（约 800 Token）和 USER.md（约 500 Token）。

这两个文件的内容，会被注入到每一次会话的系统 Prompt 里，Agent 永远能直接访问，不需要检索。

MEMORY.md 存的是关于环境和项目的事实性知识，比如：

这台机器运行 Ubuntu 22.04，装了 Docker 和 Podman
项目用 Tab 缩进，120 字符换行，Google 风格注释
Docker 组不需要 sudo
数据库已在 2026 年 1 月从 MySQL 迁移到 PostgreSQL

USER.md 存的是用户的工作风格和偏好：习惯的工作时间、沟通方式、常用工具、决策倾向。

这一层的设计哲学：最高频使用的信息，应该零延迟可达。把它放进系统 Prompt，就是最直接的实现方式。

第二层：情节记忆——技能文件（温记忆）

技能（Skill）是 Hermes 里最有创意的设计，放到下一章单独讲。但从记忆的角度来说，技能文件扮演的是程序性记忆的角色——它记住的不是事实，而是方法。

"上次你帮我做竞品价格分析，是怎么做的？"——这个问题，事实性记忆回答不了，技能文件可以。

第三层：历史检索——SQLite + FTS5（冷记忆）

所有对话历史存入 SQLite，通过 FTS5 建立全文索引。这让 Agent 能够精确检索几个月前的对话内容。

检索不是直接返回原始文本，而是经过 LLM 摘要处理，提取出与当前任务相关的信息片段再注入上下文。

这三层加起来，构成了一个按照访问频率和信息密度分层的知识体系：常用的放热层，偶尔用的放冷层，方法论放中间。

架构方法论：记忆不是一个数据库，而是一个有温度分层的知识系统。设计记忆架构时，要先想清楚不同类型信息的访问模式，再决定存在哪一层。

四、自我进化循环——Agent 如何越用越强

这是 Hermes 整个架构里最值得深想的部分。

大多数 Agent 完成任务之后，那次任务的经验就消失了。下次遇到同样的问题，它还是从零开始思考。这不是记忆的问题，而是经验转化的问题——它没有能力把一次成功的执行过程，变成下次可以直接调用的方法。

Hermes 的解法叫做程序性记忆，载体是技能（Skill）文件。

学习循环的完整五步

第一步，完成一个复杂任务。比如你让它"调研竞品定价并生成对比表格"。

第二步，任务完成后，Agent 分析自己的执行步骤，识别出其中可以复用的模式——搜索策略、数据提取方式、表格结构、交叉验证方法。

第三步，将这个工作流写成一份 Markdown 技能文件，包含任务描述、触发条件、执行步骤、注意事项。

第四步，下次遇到类似任务，直接加载这个技能文件，在已有步骤的基础上执行，并根据结果进一步优化技能内容。

第五步，每完成 15 个任务，Agent 做一次整体复盘——分析哪些任务成功、哪些失败、成功的原因是什么、失败的模式是什么——然后更新相应的技能文件。

这个循环的关键创新，是它把**"做过"转化成了"会做"**。事实性记忆记住了"发生了什么"，程序性记忆记住了"怎么做到的"。

技能文件的价值：让成长可审计

一个典型的技能文件大概长这样：

# 竞品价格调研技能触发条件：需要分析竞品定价或市场价格对比时执行步骤：1. 明确竞品范围（直接竞品 vs 间接竞品）2. 搜索策略：优先官网，辅以第三方评测3. 数据标准化：统一货币、计费周期、功能维度4. 交叉验证：至少两个来源确认关键数据5. 输出格式：Markdown 表格 + 文字摘要注意事项：- 注明数据获取日期，价格信息时效性强- 免费套餐与付费套餐分开列

这个文件，你可以打开，可以阅读，可以手动编辑，可以导出给其他 Agent 使用。它是开放的、透明的、可迁移的。

这是一个听起来很低的技术门槛，但它是所有前代框架都没能跨过的门槛——那些框架的记忆是黑盒，你不知道它"学到"了什么，也没法验证它的学习是否正确。

技能库的自我维护

从 v0.12 版本开始，Hermes 引入了一个自主 Curator 机制：通过 Cron 定期对整个技能库进行评分和整合——合并功能重叠的技能，淘汰低效的技能，提炼出更通用的版本。

这意味着技能库不只是被动地积累，而是会主动优化自身。这是 Agent 走向真正自治的一个关键能力节点。

架构方法论：技能即代码，经验即资产。一个成熟的 Agent 系统，应该能把成功的执行过程沉淀为可复用、可审计、可迁移的程序性知识。

五、调度系统——从"被动响应"到"主动执行"

如果说记忆和进化解决的是"了解你"的问题，那么调度解决的是"主动帮你"的问题。

想象一个场景：每天早上 8 点，你的 Agent 自动汇总昨天的 GitHub 提交，检查 CI 是否全部通过，把需要你关注的问题整理好，在你打开 Telegram 的时候已经发给你了。你不需要启动它，不需要发指令，它自己就做了。

这就是调度系统的价值所在。

传统 Cron 的问题

传统的定时任务（Cron + Shell 脚本）有一个根本性的缺陷：它执行了，但不知道发生了什么。

Token 过期了，任务失败了，你三周后才发现 GitHub 仓库一直没有更新。系统不会告诉你，日志也许有，但谁会每天看日志？

更重要的是，传统 Cron 是孤立的——它不知道你的偏好，不了解你的项目，不能根据执行结果调整策略。它只是一个定时触发的 Shell 命令。

Hermes 的 Cron 是怎么工作的

Hermes 里的定时任务，是第一公民的 Agent 任务，不是碰巧调用 AI 的 Shell 脚本。

当调度时间到来，触发的是完整的 Agent Loop——带着完整的记忆和技能访问权限，用和交互式会话完全相同的处理管道来执行任务，只是触发方式从"收到消息"变成了"时钟信号"。

执行完成后，结果通过 Gateway 路由到你指定的平台——可以是 Telegram、Slack、Email，或者写入文件。

更关键的是，任务结束后，Agent 会更新 MEMORY.md，记录任务状态、执行结果、遇到的问题。如果任务失败——比如 GitHub Token 过期——它不会静默失败，而是在你下次打开对话的时候主动告诉你："昨晚的备份任务失败了，原因是认证 Token 已过期，需要更新。"

这就是调度与 Agent 核心共享上下文的价值：它知道上下文，才能做出超越简单执行的判断。

自然语言调度

Hermes 还做了一件很有意思的事：你不需要写 Cron 表达式。

你只需要说："每天晚上 12 点，把今天的代码变更推送到 GitHub。"

Hermes 自己解析这句话，创建对应的技能文件，设置好 Cron 任务，告诉你配置完成了。

这不只是用户体验的改善。它背后的意思是：自动化的门槛，不应该是你需要掌握 Cron 表达式和 YAML 配置，而是你能不能清楚地描述你想要什么。

架构方法论：调度层不应该是一个独立的子系统，而应该是 Agent 核心循环的自然延伸。调度任务能访问记忆，能触发技能，能通过网关回报结果——这才是完整的调度能力。

六、可以迁移的架构原则

讲到这里，我想把 Hermes 的具体实现抽象出来，整理成几条我认为对智能体架构设计有普适价值的原则。

这些原则不只适用于 Hermes，如果你在设计任何形式的 AI Agent 系统，这些思路都值得认真想一想。

原则一：接入无关性。好的 Agent 架构，核心逻辑不应该依赖任何特定的接入入口。接入层与引擎层的解耦，是实现跨平台、跨场景能力的前提。

原则二：记忆分层化。按照访问频率和信息密度，将记忆分为热（系统 Prompt 常驻）、温（技能文件按需加载）、冷（历史检索按需召回）三层。不同温度的信息，用不同的存储和访问机制。

原则三：经验程序化。 Agent 应该能将成功的工作流，自动转化为可复用、可审计的程序性记忆。技能文件是载体，学习循环是机制，关键是让"做过的事"变成"会做的事"。

原则四：调度一体化。定时任务不是外挂功能，应该是 Agent 核心循环的自然延伸。调度任务能访问记忆、能触发技能、能感知失败、能主动汇报，才具备真正的自治价值。

原则五：模型解耦化。 LLM 调用应该通过抽象层隔离，任何业务逻辑都不应该直接依赖具体的模型 API。模型切换应该是配置问题，不是代码问题。

原则六：技能开放化。技能的格式应该是开放的、跨平台的。一个在 Hermes 里积累的技能库，应该能迁移到其他支持同一标准的 Agent 上使用——这是真正有价值的"数字资产"。

七、现实一点——它解决了什么，还没解决什么

好的技术评估，不能只说优点。

Hermes 真正解决的问题：

学习循环（记忆 + 技能 + 用户建模）是真正有创意的设计，大多数竞争框架甚至没有尝试实现跨会话的持续改进。技能生态已经积累了 600+ 个社区技能，你不需要从零开始训练你的 Agent。六种终端后端（本地、Docker、SSH、Daytona、Singularity、Modal）给了部署上真正的灵活性。

Hermes 尚未解决的问题：

记忆文件的 Token 上限较小（MEMORY.md 约 800 Token），信息量大的场景会有瓶颈。技能快照有滞后问题——技能文件的更新不是实时的，在高频迭代的场景下，技能内容可能落后于实际行为。Cron 任务的 Prompt 开销在大量定时任务的场景下不容忽视。

安全层面，有几个尚未完全解决的问题需要认真对待：技能投毒攻击（恶意构造的技能文件可以影响 Agent 行为）、MCP 供应链风险（第三方 MCP 服务的可信度难以验证）、主机凭证暴露（Agent 有终端执行权限，配置不当存在凭证泄露风险）。

对于支付、合规等高敏感场景，目前不建议直接使用。

适合用的场景：

独立开发者、研究人员、重度使用 AI 助手的个人用户。特别是那些有稳定工作流、需要 Agent 长期积累上下文、希望 Agent 能主动帮你跑重复性任务的人。

暂时不适合的场景：

需要多人协作审批流程的团队工作流，需要强审计追踪的合规场景，以及对技能文件来源没有严格把控能力的团队。

总结：Agent 的终点，不是"用完即弃"

Stanford HAI 2026 年 AI 指数报告里有一句话，让我印象很深：Agent 的价值不再仅来自模型本身，而是来自记忆、工作流恢复、工具编排和可重复执行能力。

这句话换一种说法是：好的 Agent，不只是一个会回答问题的 LLM，而是一个有记忆、有积累、有自主性的系统。

Hermes Agent 的架构，是对这种判断的一次具体实践。它不是最完美的方案，但它提出了一套清晰的思路——记忆要分层，经验要程序化，调度要一体化，技能要开放。

我们正处在 Agent 从"会用的工具"进化为"真正的助手"的过渡期。在这个阶段，架构设计的选择，往往比模型能力本身更重要。

最后留一个问题给你思考：

如果你要为自己的工作场景设计一个 Agent，你会优先解决记忆、调度、进化三个维度中的哪一个？为什么？

欢迎在评论区聊聊你的想法。

本文参考资料：NousResearch/hermes-agent（GitHub）· Turing Post《Hermes vs OpenClaw》· Stanford HAI AI Index 2026 · Hermes Agent 官方文档