可进化 Agent 系统：从 Hermes Agent 看经验闭环如何落到架构里

过去一年，Agent 系统的讨论已经从“能不能调用工具”转向了另一个更关键的问题：Agent 能不能越用越强？

很多系统表面上看也有“记忆”：把历史对话塞进向量库，或者在 prompt 里放一段用户偏好。但真正可进化的 Agent 不是“记住更多内容”，而是能把一次次任务执行中的经验，沉淀成下一次可以复用的能力。换句话说，它要形成一个闭环：

Nous Research 的 Hermes Agent 是个值得拆开看的样本——官方定位不是绑定 IDE 的 coding copilot，也不是单 API 的 chatbot wrapper，而是可以运行在服务器、云端沙箱或本地环境中的自治 Agent，强调“the agent that grows with you”：会记住项目、生成技能、跨会话延续能力。

一、为什么“经验闭环”比“长上下文”更重要

很多 Agent 系统的第一代做法是：上下文越长越好，历史越多越好，向量检索越强越好。但这会带来三个问题。

第一，历史不是经验。一段失败日志、一轮工具调用、一次用户纠正，本身只是原始轨迹。只有被提炼成“以后遇到类似问题应该怎么做”，才算经验。

第二，记忆不是能力。记住用户喜欢 TypeScript 只是偏好；记住“这个项目部署前必须先跑某个脚本，否则生产环境会失败”，才接近可执行经验。

第三，上下文不是架构。把所有东西塞进 prompt，只会让系统越来越臃肿。真正可持续的 Agent，需要区分哪些内容应该常驻、哪些按需检索、哪些沉淀为技能、哪些应该过期归档。

Hermes Agent 的价值在于，它没有把“进化”只停留在模型层，而是拆成了几个工程化子系统：Memory、Session Search、Skills、Curator、Tool Runtime、Context Compression、Gateway/Platform Layer。这些模块组合起来，才让“经验闭环”有了架构承载。

二、Hermes Agent 的核心架构：Agent Loop 不是孤立循环

从官方架构文档看，Hermes 的核心是 AIAgent，入口可以来自 CLI、Gateway、ACP、Batch Runner、API Server 或 Python Library；核心内部再拆成 Prompt Builder、Provider Resolution、Tool Dispatch、Compression & Caching、Tool Registry 等模块。底层则连接 SQLite + FTS5 的 Session Storage，以及 Terminal、Browser、Web、MCP、File、Vision 等工具后端。

Hermes 的 Agent Loop 不是简单的：

而更接近：

Agent 的智能不只在模型里，也在运行时里。

模型负责推理与生成，但“能不能复用经验”“能不能回忆过去”“能不能安全执行工具”“能不能压缩上下文”“能不能把成功路径沉淀成技能”，这些都需要运行时系统来承接。

三、经验闭环的第一层：短小但高价值的长期记忆

Hermes 的 Persistent Memory 不是无限记忆，而是有边界、有治理的记忆。官方文档说明，它默认由两个文件组成：MEMORY.md 用于 Agent 自己的笔记，比如环境事实、项目约定、工具踩坑；USER.md 用于用户画像，比如偏好、沟通风格和期望。两者存储在 ~/.hermes/memories/，并在会话开始时作为冻结快照注入系统 prompt。

1. 记忆是“精选摘要”，不是原始历史

Hermes 对记忆设置了字符限制：MEMORY.md 默认约 2,200 字符，USER.md 默认约 1,375 字符。容量限制迫使系统做选择：不是所有内容都值得永久进入 prompt。

这比“无限向量库”更接近真实工程实践。因为常驻记忆会影响每次推理，必须足够短、准、稳定。

2. 记忆分层：Agent 经验和用户偏好分开

MEMORY.md 更像 Agent 的工作笔记：项目路径、部署方式、工具坑点、已完成任务；USER.md 更像用户画像：沟通风格、技术水平、偏好。

这很关键。因为“用户是谁”和“系统怎么做事”是两类不同记忆。如果混在一起，后续注入 prompt 时很容易造成噪音。

3. 会话开始时冻结注入

Hermes 的记忆快照在会话开始时注入，之后即使本轮会话修改了记忆，也要到下次会话才会体现在系统 prompt 中。这是为了保持 prompt cache 和运行稳定性。

可进化 Agent 不是每一步都动态改系统提示词——在“进化”和“稳定”之间，这是必须做的工程取舍。

四、经验闭环的第二层：Session Search 保存原始轨迹，Memory 保存关键事实

Hermes 没有把所有历史都压缩进 Memory。它还提供了 Session Search：所有 CLI 和 messaging session 会存进 SQLite，并用 FTS5 做全文搜索，检索结果再由 LLM 总结。官方文档也明确区分了 memory 和 session search：Memory 适合关键事实常驻上下文，Session Search 适合按需找回过去讨论过的具体内容。

两者各有职责，不是互相替代：

如果把 Agent 经验系统类比成人类工作方式，Memory 像“脑子里随时记得的原则”，Session Search 像“可以翻的项目档案”。

一个成熟 Agent 不能只靠其中一个。只有 Memory，容易丢细节；只有 Session Search，每次都要检索，成本高且不稳定。两者组合，才形成了“常识层 + 档案层”。

五、经验闭环的第三层：Skills 把成功路径变成程序性记忆

Hermes 最值得关注的是 Skills System。官方文档把 Skills 定义为按需加载的知识文档，采用 progressive disclosure 模式：先只暴露技能列表和描述，只有任务需要时才加载完整内容，必要时再读取具体 reference 文件。

这解决了 Agent 系统里一个非常常见的矛盾：

经验越多，越想让 Agent 复用； 但经验全塞进上下文，系统又会变慢、变贵、变混乱。

Hermes 的方案是把经验封装成 Skill，而不是长期塞在 prompt 里。

一个 Skill 通常包含：

• SKILL.md：定义触发条件、操作步骤、已知坑点、验证方式
• references/：放背景资料和扩展说明
• templates/：放复用输出模板
• scripts/：放自动化脚本
• assets/：放图片、样例、附件等资源

官方文档中也给出了类似目录结构，强调 SKILL.md 是主说明，references、templates、scripts 等作为可选补充。

这就是“程序性记忆”：不是记住一句话，而是记住一套可复用做法。

六、Agent 自己创建 Skills：经验闭环真正发生的地方

Hermes 允许 Agent 通过 skill_manage 工具创建、更新和删除自己的技能。官方文档明确说：当 Agent 解决了一个非平凡工作流时，可以把方法保存为未来复用的 skill；触发场景包括完成复杂任务、经历错误和死路后找到正确路径、用户纠正了做法、发现了非平凡工作流等。

这正是经验闭环的关键点：

Skill 和普通 RAG 不是一回事。RAG 是“找到相关资料”；Skill 是“调用一套做事方法”。

RAG 更像搜索，Skill 更像 SOP。对于可进化 Agent 来说，SOP 化比单纯检索更重要。因为真正的经验通常不是某一段文字，而是：

1. 在什么条件下触发
2. 按什么顺序执行
3. 使用哪些工具
4. 遇到错误如何修复
5. 最后如何验收

这也是 Agent 从“会回答”走向“会做事”的关键。

七、Curator：经验不是越多越好，还需要治理

自动生成技能会带来一个新问题：如果 Agent 每次成功都写一个 Skill，时间久了就会产生大量重复、过时、狭窄的技能，反而污染技能目录。

Hermes 为此设计了 Curator。官方文档描述它是针对 Agent-created skills 的后台维护流程，会跟踪每个技能被查看、使用和 patch 的频率，并把长期不用的技能从 active 移到 stale，再到 archived；同时会周期性触发辅助模型 review，提出合并、修补或归档建议。

很多团队做 Agent 记忆时，只考虑“怎么写入”，不考虑“怎么淘汰”。但可进化系统一定会面对熵增：经验会过期，流程会变化，旧技能会和新技能冲突。

Hermes 的 Curator 至少提供了三个工程启发：

1. 给经验生命周期建模

技能不是永久有效的，它应该有状态：

这样系统才能区分“当前推荐使用的经验”和“历史上曾经有用的经验”。

2. 用使用数据驱动治理

Curator 会维护每个技能的 use_count、view_count、patch_count、last_used_at、last_patched_at 等指标。

这意味着经验治理不是凭感觉，而是基于使用痕迹。

3. 治理动作要可回滚

Curator 在真实执行前会做备份，支持 rollback 和 restore。

这是生产系统非常需要的设计。因为 Agent 自我改进不能变成不可逆自我破坏。

八、工具执行层：经验闭环必须建立在可观察、可控的行动系统上

Hermes 的工具系统覆盖 web search、browser automation、terminal execution、file editing、memory、delegation、messaging delivery、MCP、RL training 等多个类别。工具被组织为 toolsets，可以按平台启用或禁用。

Hermes 的经验闭环不是纯文本闭环，而是行动闭环：

在 Agent Loop 内部，Hermes 对工具调用也做了工程化处理：单个 tool call 直接执行，多个 tool call 可以通过 ThreadPoolExecutor 并发执行；危险命令会经过 approval 检查；工具结果会重新追加到对话历史中。([GitHub][7])

只有行动过程被结构化记录，经验才有原料可提炼。

如果工具调用只是黑盒执行，Agent 就很难知道自己到底做对了什么、错在哪里、下次应该如何复用。

九、上下文压缩与持久化：让长任务不断线

Agent 做复杂任务时，很容易超过模型上下文窗口。Hermes 的 Agent Loop 文档提到，当会话超过模型上下文窗口 50% 时会触发 preflight compression；Gateway 场景下超过 85% 会更激进地自动压缩。压缩时会先把 memory flush 到磁盘，中间轮次会被总结，最后 N 条消息会保留，工具调用和结果会成对保留，之后生成新的 session lineage。([GitHub][7])

经验闭环依赖长任务轨迹，而长任务轨迹天然会撑爆上下文，这是任何复杂 Agent 绕不过去的工程问题。

Hermes 的处理方式可以抽象成：

1. 保留最近细节，保证当前任务不断线
2. 压缩中间过程，降低上下文成本
3. 持久化关键状态，防止信息丢失
4. 维护会话谱系，保留任务演化轨迹
5. 成对保留工具调用和结果，确保经验可回放

尤其是“工具调用和结果成对保留”这个细节很重要。因为对 Agent 来说，单独保留工具调用或单独保留结果都不完整；只有 action-result pair 才能构成可学习的经验片段。

十、从 Hermes 抽象出的可进化 Agent 架构

把 Hermes 的做法抽象一层，可进化 Agent 系统在架构上大概是这样分的：

这个架构的核心不是“多一个记忆模块”，而是把经验拆成不同形态：

十一、对企业 Agent 架构的启发

企业场景和个人使用 Hermes 有一个根本差别：知识是团队的，流程是会变的，数据是有合规边界的。

这意味着经验闭环要解决的问题也不一样。个人用 Agent 最怕记忆遗忘；企业 Agent 最怕的是三件事同时出现：经验过期了没人发现、旧技能和新流程冲突、敏感数据悄悄进了系统 prompt。把 Hermes 的设计迁移过来，我更看重以下几点。

知识库和经验库是两类不同的东西

传统知识库擅长存文章、FAQ、规范；但真正决定 Agent 行为质量的，是这一类内容：

• 某个环境部署失败，最后发现是镜像 tag 和配置版本不一致
• 某类 SQL 结果为空，不是 query 错，而是业务筛选条件过窄
• 某个客户每次会议前必须先看合规口径，才能谈产品能力
• 某个系统发布前必须跑一组不写在文档里的检查脚本

这些信息存进向量库，检索时可能能找到；但如果封装成 Skill，Agent 遇到同类任务会主动触发，不需要碰运气。知识库是"有人查才有用"，经验库是"Agent 做事时自动接入"——两者的架构意图完全不同。

经验提炼需要原材料：结构化轨迹

Agent 的经验不是凭空产生的，它来自一次次任务执行的记录。问题是，很多企业 Agent 系统只存了聊天记录，却没有结构化地记下"做了什么、怎么做的、哪里出了问题"。等到想做经验提炼，发现根本没有可用原料。

有效的轨迹至少要包含：

没有这些，经验提炼要么靠人工整理，要么靠模型猜——两种都不可靠。

技能生成要有门槛，不能什么任务都写

技能库的熵增比你想象的快。如果 Agent 每次任务结束都生成一个 Skill，三个月后技能目录就会充满互相重叠、覆盖范围极窄的碎片，反而让 Agent 不知道该用哪个。

我倾向于只在以下几种情况触发技能生成：

• 任务涉及多步工具调用，且路径不直觉（不记下来下次大概率还会走弯路）
• 出错之后找到了稳定解法（失败代价已经付过了，值得固化）
• 用户明确纠正了 Agent 的做法（纠正本身就是经验）
• 流程涉及本项目特有的约定，外部文档不会覆盖

一条技能如果可以用通用常识推导出来，不值得单独写。真正值得沉淀的，是那些"不经历过就不知道"的东西。

技能治理不是可选项

企业内部流程比你想象的更容易变化。API 换版本了、合规口径更新了、部署方式调整了——这些变化不会自动通知技能库。旧技能如果不归档，就会悄悄成为误导 Agent 的噪音。

所以技能的元数据从一开始就要支持生命周期管理：

没有这些字段，治理就退化成"定期手动清理一遍"——很快就没人做了。

记忆的边界是安全边界

Hermes 文档里，Memory 写入时会做提示词注入和数据外泄模式扫描，原因很简单：Memory 内容会直接进入系统 prompt，是高权重上下文资产，出问题很难追踪和撤回。

企业场景要比个人场景更严格。一个可执行的原则：进入 Memory 的内容，都应该能通过"这条内容可以被所有调用这个 Agent 的人看到"这个审查。以下内容一律不应该写进去：密钥、令牌、客户敏感数据、个人隐私、未经确认的结论、过期合规口径。

十二、一个企业版"经验闭环 Agent"的落地方案

不要试图一步到位。经验闭环的每个阶段都依赖上一个阶段的产出：没有轨迹就没有原料，没有原料就没有可信的 Memory 和 Skill，没有足够的技能积累就谈不上治理。从最小可行版本开始，逐阶段解锁能力，是更稳的路。

阶段一：先把轨迹存起来，不急着自我改进

这一阶段的目标不是让 Agent 变聪明，而是建立经验原料的采集管道。五张表足够：

• messages：完整对话历史
• tool_calls：每次工具调用的名称、参数
• tool_results：工具返回结果与状态
• task_summary：任务级别的目标、计划、结论
• user_feedback：用户的纠正、评分、补充说明

这一步做完，你才真正拥有"可以被分析的经验"，而不只是"可以被翻阅的聊天记录"。

阶段二：区分常识层和档案层

轨迹有了，下一步是对信息分层存储，避免什么都往 prompt 里塞：

Memory 的关键不是"存多少"，是"存什么"。一条常驻在系统 prompt 里的事实，比一千条塞进向量库的记录影响更直接——也更难撤销。Session Search 可以存大量历史，但它靠检索触发，更适合回溯具体细节，而不是替代常识。

两者配合，才形成"随时可用的工作常识 + 按需调取的任务档案"这个结构。

阶段三：把高频路径固化成 Skill

当某类任务开始重复出现，就是引入 Skill 的时候。一个 Skill 不需要很复杂，基本结构够用：

SKILL.md
- 触发条件：什么情况下该用这个技能
- 输入要求：需要什么前置信息
- 执行步骤：具体操作顺序
- 工具清单：会用到哪些工具
- 常见错误：哪里容易出问题
- 验收方式：怎么判断做完了
- 示例：一个真实任务的执行记录

不要一开始追求全自动生成。早期让 Agent 提议、人工确认后入库，比直接让 Agent 自主写要安全得多。等你对技能质量有判断力了，再逐步放开自动化。

阶段四：用数据驱动技能治理

技能积累到几十条之后，就会开始出现老旧、重复、过时的情况。这时候需要的不是人工扫描，而是一套数据驱动的治理机制——这正是 Curator 的用武之地。

核心逻辑是：用使用频率和修补次数判断技能是否还活跃，低频技能自动降级为 stale，触发人工 review；确认过期则归档；核心技能用 pinned 标记保护。出了问题，rollback_snapshot 让你能安全回退。

做到这一步，Agent 的经验系统才真正形成了正向飞轮：新任务产生轨迹 → 轨迹提炼成技能 → 技能经过使用和修补变得稳定 → 稳定的技能让下次任务更快、更少出错 → 又产生更高质量的轨迹。

这一步决定系统是"越用越强"，还是"越积累越乱"。

十三、Hermes 给我们的真正启示

Hermes Agent 最有启发的地方，不是它支持多少平台、多少工具、多少模型，而是它把“经验闭环”拆成了可工程化的模块：

Agent 的长期能力不是一次推理产生的，而是在持续运行中被积累、压缩、提炼、调用和修正出来的。

所以，真正可进化的 Agent 系统，不能只问：

• 这个模型够不够强？
• 工具够不够多？
• 上下文够不够长？

而应该问：

• 它做过的事，能不能变成下次可复用的能力？
• 它犯过的错，能不能变成下次避免的规则？
• 用户纠正过它，能不能改变未来行为？
• 成功路径，能不能沉淀为可审计、可更新、可回滚的技能？

这才是从“会调用工具的 Agent”走向“可进化 Agent 系统”的分水岭。

参考资料

1. Hermes Agent — The Agent That Grows With You | Nous Research
2. Architecture | Hermes Agent
3. Persistent Memory | Hermes Agent
4. Skills System | Hermes Agent
5. Curator | Hermes Agent
6. Tools & Toolsets | Hermes Agent
7. hermes-agent/agent-loop.md at main · NousResearch/hermes-agent · GitHub