当前位置：首页 > news >正文

原创丨一个会“记住你“的 AI 智能体是怎么造出来的：拆解Hermes Agent

news 2026/6/1 10:33:31

作者：金一鸣 本文约5800字，建议阅读11分钟 本文介绍成长型智能体架构、运行机制、应用场景与现存局限。

引言：为什么大多数 AI 助手都"记不住你"

一个常见的体验是：上周你已经向某个 AI 助手解释过自己写代码的偏好、项目背景、表达风格，本周开启新对话，它又像第一次见到你。你昨天告诉它"我习惯用驼峰命名"，今天它依然在用下划线。再具体一些——把同一份长文档翻译两次，得到两份风格不一致的译文；让 AI 助手帮忙整理客户资料，每次都要从头解释"我是做什么的、客户是谁"。

这不是模型本身不够强，而是当前 AI 助手的使用方式默认是无状态的——每一次对话都是独立的，结束即遗忘。这种"金鱼式记忆"是绝大多数主流 AI 助手的共同特征。

过去两年，大语言模型（Large Language Model，以下简称 LLM）的能力开发经历了几个明显的阶段。最初，模型被当作一次性问答工具使用；随后，开发者通过外挂工具、链式思考（Chain-of-Thought）和检索增强生成（RAG）扩展其能力边界；近一年内，"Agent"（智能体）这一形态逐步成为主流——模型不再被动应答，而是主动调用工具、规划步骤、完成多轮任务。

然而，"无状态"的局限并未随之消失。Agent 能调更多工具、跑更长流程，但每次会话结束，它学到的内容、踩过的坑、用户的偏好仍会随之归零。同一个用户、同一个任务，Agent 可能需要被反复"教导"。

由 Nous Research 在 2026 年 2 月开源的 Hermes Agent，是针对这一痛点的一种系统性回答。其官方标语为 "the agent that grows with you"——与你共同成长的 Agent。截至 2026 年 5 月，该项目在 GitHub 上已获得约 142k Stars、22k Forks。它没有发明新的模型，也没有提出新的算法，而是把"记忆""技能""工具""调度"这些零件组合起来，让 Agent 在每一次使用中留下痕迹、长出能力。

接下来这篇文章，会拆解它是怎么做到的——架构是什么样、核心机制怎么工作、对普通人意味着什么，以及它仍然解决不了的问题。

整体架构：一个"运行时"，而非一个"模型封装"

理解 Hermes Agent 的第一个关键，是区分它与传统 LLM 应用的不同定位。它不是 ChatGPT 那样的端到端产品，也不是 LangChain 那样的开发库，而是一个自治式 Agent 运行时（Agent Runtime）。

查阅其 GitHub 仓库的代码目录，可以观察到 Hermes Agent 的工程结构呈现出清晰的模块划分：agent/（核心推理循环）、gateway/（消息网关）、skills/（技能库）、tools/（工具集合）、cron/（定时调度）、acp_adapter/（Agent Communication Protocol 适配层）、environments/（强化学习环境）。会话、工具、记忆、调度、通信协议在此被作为并列的顶层模块组织，而非附属于某个核心组件之下。

整体架构可以划分为五层，如下图所示：

各层职能如下表所示：

值得注意的是，全部数据默认存储于本地 SQLite 数据库，不经过第三方云服务。这一选择服务于自托管定位，使数据与日志都保留在部署者本地，与主流 SaaS 形态的 AI 助手存在明显差异。

核心机制一：自我进化的学习闭环

Hermes Agent 最具辨识度的特性是其学习闭环（Learning Loop）。该闭环并非单一算法，而是由五个相互衔接的子机制构成。官方 README 将其概括为五点：Agent 策展的记忆与定期提示、复杂任务后自主创建技能、技能在使用中自我改进、基于 FTS5 与 LLM 摘要的跨会话召回、Honcho 辩证用户建模。下面分别展开。

1. 分层记忆架构

学习闭环的基础是记忆。Hermes Agent 的记忆系统不是单一存储，而是分层设计：

这一设计的实际收益是对 Prompt Cache 友好：常驻的两个 Markdown 文件保持稳定，便于 LLM Provider 命中缓存；而频繁变化、体量较大的会话历史和技能则通过工具按需检索，避免占用主上下文。在长期使用中，这能直接降低 Token 消耗。

2. 从任务到技能：经验的固化

当 Agent 完成一个复杂任务后，会自动触发一次"技能提炼"流程。社区文档中明确指出，触发阈值为涉及五次以上工具调用的任务。该流程会回看本次任务的完整轨迹，提取其中可复用的步骤序列、参数模板与判断逻辑，将其固化为一个新的 Skill 文件。Hermes Agent 兼容 agentskills.io 开放标准，意味着技能可以在不同 Agent 之间迁移与共享。

这一机制的设计哲学，与传统 Agent 框架（如 OpenClaw 类项目）形成了对比：

可以看到，这是一种典型的设计权衡（Trade-off）：以冷启动质量换取长期个性化与维护成本。

3. 技能的自改进

技能一旦生成并不固化。在后续被调用的过程中，Hermes Agent 会持续监测其执行结果——成功率、耗时、报错频率等指标。当某项指标偏离预期时，Agent 会触发对该技能的反思与改写。

这种"使用即训练"的机制，可以理解为把传统机器学习中"在线学习（Online Learning）"的思想，迁移到了符号化的技能脚本层面。它不依赖梯度回传，而是依赖 LLM 的自我反思能力（Self-Reflection）完成迭代。技能本身以 Markdown 形式存在，可读、可审、可手动修改、可版本控制——这与"调整模型权重"的不透明过程形成了对照。

4. 跨会话记忆与召回

会话档案模块是闭环的另一关键支柱。Hermes Agent 采用 SQLite 的 FTS5 扩展（Full-Text Search version 5）建立全文索引。召回时，并非简单做向量检索，而是采用 FTS5 关键词检索 + LLM 二次摘要的混合方案。该方案相比纯向量检索的优势在于：精确召回结构化事实（如人名、时间、API Key 命名），并通过 LLM 对召回片段做语义压缩，控制注入主推理上下文的 Token 体量。

5. 用户建模

在记忆之上，Hermes Agent 集成了来自 Plastic Labs 的 Honcho 框架，采用辩证法（Dialectical）方式持续推断用户的风格、技术偏好、错误容忍度等画像维度。该画像作为可选模块，启用后会作为系统提示的一部分注入每次推理，使 Agent 输出风格逐步向用户对齐。

整体闭环可表示如下：

核心机制二：统一消息网关与多平台抽象

Hermes Agent 的另一个值得关注的设计是其统一消息网关（Unified Gateway）。

具体而言，它将 Telegram、Discord、Slack、WhatsApp、Signal、Email、CLI 等异构通道抽象为同一种内部消息格式，再交由推理层处理。带来的直接收益是：同一个 Agent 实例可以在多个平台上同时服务，且共享同一份记忆与技能库。

国内用户更关心的微信、飞书、钉钉、企业微信等平台，目前不在官方原生适配清单中。但社区已通过桥接方案补齐——例如开源项目 HermesClaw 通过微信网页协议接入个人微信号；飞书与钉钉则可通过其官方机器人 API 编写自定义 Adapter 接入。这意味着 Hermes Agent 的"统一消息抽象"对国内生态同样适用，只是初期需要一些配置工作。

实现层面，网关采用插件化适配器（Adapter）模式，每个平台对应一个独立适配器，负责协议翻译、媒体格式转换与速率控制。新增平台支持的边际成本很低。

核心机制三：模型无关的路由层

LLM 生态变化极快，新模型几乎每月都在更新。任何绑定单一模型的 Agent 框架都将面临持续的迁移成本。Hermes Agent 在设计上采用了模型无关（Model-Agnostic）的路由抽象，目前已兼容 Nous Portal、OpenRouter（聚合 200+ 模型）、NVIDIA NIM（Nemotron 系列）、智谱 GLM、Kimi/Moonshot、MiniMax等以及任何用户自托管的端点。

切换方式较为简单，命令行执行 Hermes model 即可在交互界面中选择，无需修改代码。这一抽象除了支持手动切换，也允许根据任务类型动态选择模型——例如代码生成路由至擅长编码的模型，文案改写路由至擅长长文本的模型，工具调用决策路由至响应速度更快的小模型。这种异构模型协同的策略，可以在控制成本的同时兼顾输出质量。

子 Agent 与上下文压缩

复杂任务往往需要多步骤、多工具的协同。如果所有中间结果都堆积在主 Agent 的上下文窗口中，会迅速触及 Token 上限并显著推高成本。Hermes Agent 引入了子 Agent（Sub-Agent）并行化机制：主 Agent 通过 RPC 调用方式派发子任务，子 Agent 在独立上下文中完成工具调用与初步推理，仅将最终结论回传。

这一机制的效果是将多步骤流程压缩为"对主上下文几乎无成本的一次调用"。从工程视角看，思路与操作系统的进程隔离类似——上下文相当于地址空间，子 Agent 相当于子进程。

下表对比了有无子 Agent 机制的差异：

沙箱执行：七种终端后端

Agent 一旦具备调用终端、修改文件、执行代码的能力，安全边界就成为不可回避的问题。Hermes Agent 在这个问题上提供了七种可选的执行后端：

其中 Modal 与 Daytona 这两个 Serverless 后端值得关注：Agent 的环境可以在空闲时休眠，按需唤醒，闲置阶段几乎不产生持续费用。这降低了让 Agent 长期运行的门槛。

之所以提供如此多种后端，背后的考虑是不同用户的安全偏好与运行环境差异极大：开发者本机偏好 local 直连，企业部署需要 Docker 隔离，云服务管理依赖 SSH，科研机构使用 Singularity，间歇任务适合 Serverless。统一的 Agent 行为，对接不同的执行隔离层级——这是 Hermes Agent 在"自治程度"与"安全可控"之间留出的调节空间。

与普通人有什么关系：四个具体场景

技术原理之外，普通人最关心的问题是：这一切对自己意味着什么？以下是几个具体的应用场景。

场景一：自由职业者的"个人秘书"

一名自由撰稿人通常会在多个平台间切换——客户在微信沟通需求、稿件在飞书或腾讯文档中撰写、参考资料散落在浏览器收藏夹、发票在邮箱中等待整理。传统 AI 助手对此场景几乎无能为力——它每次都需要被告知"我是谁、我在做什么、上次聊到哪里"。

部署一个 Hermes Agent 后，情况发生改变：

Agent 通过消息网关常驻在飞书或企业微信；
用户在不同时间从不同设备发送指令，Agent 凭借跨会话记忆延续上下文；
完成第一次"整理客户需求并生成稿件大纲"任务后，Agent 自动提炼一份对应技能；下次只需说"按上次那个流程整理"，技能即被复用；
通过定时任务，Agent 每周一早上 9 点自动汇总上周的客户沟通要点，发送到指定渠道。

场景二：研究者的实验记录助手

科研工作者在重复性实验中常常面临"上次配置了什么参数、为什么这个步骤要这样做"的记忆负担。Hermes Agent 的技能系统可以扮演结构化实验记录的角色：

第一次跑通一个数据预处理流水线后，Agent 自动生成一份技能文档，记录每一步的参数、依赖项、常见报错与验证方法；
后续若同事或自己半年后需要复现，仅需调用同一技能；
技能在使用过程中如发现陷阱（如 GPU 显存不足时的回退策略），会自动迭代更新。

这与 Jupyter Notebook 笔记不同——它不仅是被动的记录，而是可执行、可调用、可演化的程序性知识。

场景三：小型团队的运维助手

一支三五人的创业团队通常没有专职运维。Hermes Agent 配合 SSH 后端，可以承担日常运维角色：

每晚定时执行数据库备份，结果推送到团队的飞书群或钉钉群；
监控服务器告警，自动诊断常见问题（如磁盘满、进程崩溃）并尝试修复；
团队成员在飞书或企业微信中用自然语言下达指令，例如"看一下昨晚的日志有没有异常"——Agent 调用对应技能，远程登录、检索、汇总、回复。

这类场景中，Hermes Agent 的"技能积累"特性较为有用——团队的运维经验会被自动沉淀为技能库，新成员加入时可直接复用。

场景四：个人知识管理与生活助理

对完全非技术背景的用户，Hermes Agent 仍可作为长期的"数字伴侣"：

通过微信（社区桥接）或飞书与之对话，记录每日想法、待办事项、阅读笔记；
Agent 学习用户的语言风格与关注主题，逐步形成个性化画像；
当用户提出"帮我把上周读到的那篇关于睡眠的研究找一下"，Agent 能够通过 FTS5 检索结合 LLM 摘要，准确召回相关对话片段；
通过定时任务，每月自动生成一份"个人月报"，汇总当月的关注主题、待办完成情况与重要事件。

需要补充的是，上述数据均存储在用户自己的服务器上，不流向第三方云厂商。这对隐私敏感的使用者而言是一项实际差异。

局限性与挑战

任何技术方案都有适用边界。客观看 Hermes Agent，至少存在以下几方面的挑战。

第一，自生成技能的质量不可控。由于技能由 Agent 在使用中自动提炼，质量高度依赖早期任务样本的代表性。若早期任务存在偏差，提炼出的技能可能将错误模式固化。该问题虽然可以通过自改进机制部分缓解，但在缺乏外部评估信号的情况下，存在"自我强化错误"的风险。

第二，可观测性不足。一次 Hermes Agent 的运行可能涉及多轮推理、若干工具调用、子 Agent 派发与记忆读写。当结果偏差或成本异常时，定位问题根源较为困难。阿里云等厂商已为其提供了可观测性插件，从侧面反映了原生方案在该领域的不足。

第三，安全与权限边界。自治程度越高的 Agent，权限滥用的潜在风险越大。当 Agent 拥有持久记忆、可调用任意工具、可派发子任务时，一次提示注入（Prompt Injection）攻击就可能造成持久性影响——例如恶意指令被固化为技能。Hermes Agent 通过命令审批机制、DM 配对、容器隔离等多层防御缓解此问题，但风险并未完全消除。

第四，成本不可预测。学习闭环中的技能提炼、记忆摘要、用户建模本身需要额外的 LLM 调用。对于轻度使用场景，这部分"元开销"可能高于实际任务开销。Modal 与 Daytona 这类 Serverless 后端缓解了闲置成本，但活跃使用阶段的 Token 消耗仍需关注。