Hermes‑Agent（自进化agent）浅析

第一部分项目定位

1.1 框架定位：可以随使用自我成长的 AI Agent

Hermes 的定位用一句话就能说清："The Agent That Grows With You"------一个会随着使用不断自我成长的 AI Agent 框架。

市面上绝大多数 Agent 框架是"静态"的：你给它一套工具、一套 Prompt，它每次启动都是同一个状态，做完任务就忘，下一次从零开始。Hermes 想打破这个模式------它的核心假设是，Agent 每完成一次任务，都应该比上一次更强一点。

这个假设落地为三个核心能力：

第一，经验固化为技能。 Agent 完成复杂任务后，能自动把操作流程提炼成 SKILL.md 文件，存入技能库。下次遇到同类任务，不需要重新摸索，直接加载已有技能即可。

第二，使用中持续改进。 已有的技能不是一成不变的。Agent 在运行过程中如果发现更好的做法，可以通过 patch 机制局部修改技能文件；离线状态下还能通过 GEPA 遗传算法对技能进行多目标优化，系统性地提升准确性和效率。

第三，多平台无缝运行。 同一个 Agent 核心可以同时服务 CLI、Telegram、Slack、钉钉、飞书等 18 个平台，平台差异只存在于入口适配层，核心逻辑完全复用。

1.2 要解决的传统 Agent 痛点

痛点一：用完即忘，经验不沉淀。

传统 Agent 的"记忆"仅限于当前会话的上下文窗口。会话一结束，它在这次任务中摸索出来的操作方法、踩过的坑、验证过的解决方案，全部消失。下次遇到同类任务，从零开始，重复同样的试错。Agent 用得越多，浪费的重复劳动越多，但它本身不会因此变强。

Hermes 的应对：三层持久记忆 + Skill 自创建机制，把一次性的操作经验固化为可复用的 SKILL.md 文件，跨会话积累。

痛点二：技能靠人工编写，覆盖范围有限。

传统 Agent 的能力边界由人工决定------人写了什么工具描述、什么 Prompt 规则、什么知识库文档，Agent 才能做什么。一旦遇到预设之外的场景，Agent 要么瞎猜，要么直接推脱。而且技能的维护成本极高：每新增一个场景就要人工写一份 Prompt，每改一个流程就要手动更新所有相关描述。

Hermes 的应对：Agent 可以自主 create 新技能、patch 已有技能，技能的产生和改进不再完全依赖人工。

痛点三：Prompt 越堆越长，上下文成本失控。

为了让 Agent"记住"更多东西，传统做法是把所有规则、示例、历史操作一股脑塞进 System Prompt。结果就是 Prompt 像滚雪球一样越来越长，Token 成本飙升，还随时可能超出模型的上下文窗口。更讽刺的是，90% 的 Prompt 内容在绝大多数任务中根本用不上，但每次调用都要为它们付费。

Hermes 的应对：Skill 六层渐进加载------大多数场景只消耗名称+描述级别的 50-100 token，确认需要某个技能时才加载完整内容，从机制上控制上下文成本。

痛点四：错误处理脆弱，一错就崩。

传统 Agent 在真实环境中运行时，会遇到各种意外：API 限流（429）、上下文超长（400）、服务器错误（5xx）、连接超时、工具调用失败......大多数框架的处理方式是直接抛错终止，或者陷入无限重试死循环。没有分级错误分类、没有智能退避策略、没有备用 Provider 故障转移、没有预算耗尽时的优雅退出机制。

Hermes 的应对：10 类错误场景分级处理 + Jittered Backoff 退避 + Provider 故障转移 + 预算宽限模式，韧性工程代码占了整个核心循环的 99%。

痛点五：平台绑定，迁移成本高。

传统 Agent 往往为某个特定平台深度定制------为 Telegram 写的机器人，换到 Slack 就要重写消息解析和事件处理；为 CLI 写的工具，接到 Web 端就要改交互逻辑。平台差异渗透到了核心逻辑里，换平台等于重写。

Hermes 的应对：统一 AIAgent 核心 + 18 平台适配器，平台差异只存在于入口层，核心逻辑完全复用。

痛点六：安全边界模糊，风险不可控。

传统 Agent 获得工具调用权限后，安全问题就变得尖锐：它可能执行 rm -rf 这样的破坏性命令、可能在输出中泄露 API Key、可能被恶意 Prompt 注入篡改行为、可能安装包含数据窃取代码的外部技能。大多数框架要么完全放开（信任模型不会做坏事），要么完全锁死（什么工具都不给用），没有中间地带。

Hermes 的应对：五层纵深防御------输入层检测注入、执行层拦截危险命令、技能层安全扫描、输出层密钥脱敏、授权层人机确认，核心哲学是"检测自动化，决策留给人类"。

这六个痛点不是孤立的，它们共同指向一个根本问题：传统 Agent 是一个"静态的工具执行器"，而不是一个"能成长的智能体"。 Hermes 的所有设计------从记忆到技能、从韧性到安全、从 Nudge 到 GEPA------都是在系统性地回答同一个问题：怎么让 Agent 从"每次从零开始"变成"越用越强"。

第二部分自进化引擎：框架最核心机制

2.1 两套进化模型：个体运行时学习 + 种群离线进化

Hermes 的自进化不是单一机制，而是两套互补的进化模型并行运作：一套在运行时实时学习，一套在离线时系统性优化。前者解决"这次任务的经验怎么立刻用上"，后者解决"积累了大量经验后怎么系统性地变得更好"。

维度	个体学习 --- 运行时自改进	种群进化 --- GEPA 离线优化
触发条件	每 10 次工具调用计数后，在响应交付后非同步触发	手动运行 evolve_skill.py，或定时批处理任务
执行方式	派生独立后台回顾 Agent，不占用主 Agent 注意力	DSPy GEPA 遗传算法，多目标帕累托排序
输出结果	skill_manage(create) 或 skill_manage(patch)	经验证的更优 SKILL.md，覆盖原有版本
作用范围	单次会话即时生效，下次会话自动加载新技能	跨会话系统性改良，同时优化准确性 + 效率 + 鲁棒性
优化目标	修复当前遇到的具体失败，查漏补缺	在多个候选变体中搜索全局更优解
实时性	实时，任务跑完几分钟内生效	离线，一次完整进化可能需要上百次 LLM 调用

两套机制不是互斥的，而是接力关系：个体学习在日常使用中不断产生和修补技能，相当于"快速迭代"；种群进化定期对已有技能进行遗传搜索和多目标优化，相当于"版本升级"。前者保证 Agent 不会在同一个地方反复摔倒，后者保证技能库不会停留在"够用但不最优"的状态。

2.2 个体学习：Nudge 后台复盘 Reviewer 机制

个体学习的核心是 Nudge 机制------Agent 在运行过程中，每隔一段时间自动触发一次后台自我复盘，把本次任务中的经验教训固化为技能。

触发：工具调用计数器驱动

Nudge 的触发不是定时的，也不是任务结束时触发，而是由工具调用计数器驱动。Agent 每调用一次工具，计数器加 1；达到阈值（默认 10 次）后，标记"需要复盘"。

这里有一个关键的设计决策：复盘判定在响应交付之后才激活。也就是说，Agent 先把用户的回答返回，确认主任务已经完成，再在后台启动复盘流程。这样做的目的是不抢占主 Agent 的注意力------用户不会因为 Agent 在"反思"而等待更久。

另一个细节是防冗余设计：如果 Agent 主动调用了 skill_manage 工具（自己创建或修改了技能），计数器会立刻归零。逻辑很直接------刚创建完技能，说明最近的经验已经处理过了，不需要立刻又触发一次复盘。

隔离：后台回顾 Agent 的约束条件

复盘不是由主 Agent 自己做的，而是派生一个独立的后台回顾 Agent。这个后台 Agent 接收父 Agent 的对话快照，拥有 skill_manage 工具权限，可以审查对话并决定创建或修改哪些技能。

但它有严格的约束，核心目的是防止无限递归：

_skill_nudge_interval = 0：后台 Agent 自己不会再触发 Nudge，避免"复盘的复盘"无限嵌套
_memory_nudge_interval = 0：同理，记忆 Nudge 也禁用
max_iterations = 20：轻量执行，不允许后台 Agent 跑太久
与父 Agent 共享 HERMES_HOME：这样它创建/修改的技能文件，父 Agent 下次就能加载到

这套隔离设计的本质是：自进化是一个"单向输出"的过程------主 Agent 产生经验，后台 Agent 消化经验并写入技能库，但后台 Agent 不能再产生新的复盘任务，否则整个系统会陷入递归失控。

操作：create 新建与 patch 局部修改

回顾 Agent 审查完对话后，会输出两种操作之一：

create（新建技能） ：当发现一类反复出现的操作模式，且现有技能库中没有覆盖时，创建一个全新的 SKILL.md 文件。比如 Agent 连续处理了几个数字商品退款问题，发现现有技能里没有相关内容，就会创建 digital_goods_refund.md。

patch（局部修改） ：当已有技能基本正确但有缺陷时，不重写整个文件，而是做精确的局部替换。Agent 传入 old_text（需要被替换的原文，逐字符精确匹配）和 new_text（改进后的内容），系统执行字符串替换后重新安全扫描，再写入文件。

patch 机制中有一个值得注意的工程细节：原子写入 。内部流程是先写入临时文件，调用 os.fsync 刷盘，再用 os.replace 原子替换原文件。这样做保证了任何时刻读者要么看到完整的旧版本，要么看到完整的新版本，永远不会看到"写了一半"的损坏文件。对于一个会自动修改自己技能文件的系统来说，这不是锦上添花，而是必需的安全保障。

2.3 GEPA 离线种群进化

2.3.1 将 Skill 视作基因：突变、交叉、种群

GEPA 的核心思想可以用一句话概括：把 SKILL.md 文件当作生物的基因，用遗传算法的方式让它一代代进化。 这个比喻不是修辞，而是整套机制的设计基础------每一个概念都能在生物进化中找到精确对应。

从生物进化到 GEPA 的概念映射

生物概念	GEPA 对应	具体含义
基因	SKILL.md 文本	每条技能 = 一个"个体"，技能中的每句自然语言指令 = 可被突变的基因片段
染色体	技能文件整体	一条 SKILL.md = 一条"染色体"，进化目标是让它更好地指导 Agent
种群	多版本变体集合	同时维护 N 个候选版本的技能，互相竞争
突变	LLM 改写指令步骤	随机改写技能中的某段文字，产生新变体
交叉	混合两变体段落	取 A 的前半部分 + B 的后半部分，产生组合变体
自然选择	帕累托排序淘汰	劣质变体被评估淘汰，优质变体进入下一代

这个映射的关键洞察是：SKILL.md 是纯文本，而 LLM 天生擅长改写文本。 不需要设计复杂的变异算子，让 LLM 自己去"突变"和"交叉"就行了------这比传统遗传算法中针对二进制或数值编码的变异操作要自然得多。

突变：LLM 自动改写技能指令

突变的操作很直接：拿一条现有的 SKILL.md，让 LLM 随机改写其中的某段步骤，产生一个变体。改写不是乱改，而是 LLM 根据上下文"推断"可能的改进方向。

PPT 中给了一个 docker 部署技能的突变示例：

原始版本 V0：

docker build .
docker push $IMAGE
ssh deploy.sh

突变后版本 V1（LLM 自动改写）：

docker build -t $TAG .
docker images | grep $TAG
docker push $TAG
ssh deploy.sh; wait_healthy 60

突变后新增了两步："验证镜像是否构建成功"和"部署后等待健康检查"。这不是人工指定的改进，而是 LLM 根据 docker 部署的上下文自动推断出来的------它"知道"构建后应该验证、部署后应该等待健康检查，于是把这些步骤加了进去。

这就是突变的力量：LLM 的预训练知识本身就是变异的"灵感来源"，它能产生人类设计者可能没想到的改进方向。

交叉：混合两个变体的段落

交叉操作模拟生物的有性繁殖：取两个优质变体，把它们的段落混合，产生一个新变体。比如变体 A 的前半部分步骤写得好，变体 B 的后半部分注意事项写得好，交叉后可能得到一个"前半用 A、后半用 B"的组合体，集两者之长。

交叉的意义在于：突变是单点探索，交叉是组合探索。 单靠突变，每次只能在一个方向上小步改进；有了交叉，两个独立发现的好改进可以组合到同一个个体中，加速进化。

种群：一代代筛选与迭代

有了突变和交叉产生变体，接下来就是种群的迭代过程。每一代的流程是：

产生变体：对上一代的优质个体执行突变和交叉，生成新候选
评估指标：用真实 LLM 执行每个变体对应的技能，在评估集上测出准确性、Token 消耗、鲁棒性
帕累托排序：按多目标指标排序，淘汰被支配的劣质变体
精英存续：帕累托前沿上的优质变体进入下一代

GEPA 的思路提出了一个问题------当技能库积累了足够多的经验后，我们能不能用算法系统性地搜索出比人工复盘更好的技能版本？ 这个问题的答案，可能决定了自进化 Agent 能走多远。

2.3.2 帕累托多目标优化原理

上一节讲了 GEPA 怎么通过突变和交叉产生大量技能变体。这一节要回答一个更关键的问题：产生了这么多变体，怎么判断谁好谁坏？

答案不是"选一个分数最高的"，因为 GEPA 同时优化三个目标，而这三个目标往往是互相矛盾的。这就需要帕累托多目标优化。

为什么没有单一的"最优"版本

GEPA 评估一个技能变体时，同时看三个指标：

准确性：任务成功率，越高越好
效率：Token 消耗量，越低越好
鲁棒性：不同输入下的一致性，越高越好

问题在于，这三个目标通常不能同时达到最优。想提升准确率，往往要在技能里写更多细节、更多示例，这会增加 Token 消耗；想降低 Token，就要精简技能内容，可能损失鲁棒性；想提升鲁棒性，就要覆盖更多边界情况，又会增加 Token。

这就像找工作：你想找薪资高、工作轻松、通勤近的工作，但这三个条件往往不可兼得。薪资高的可能加班多，工作轻松的可能薪资低，通勤近的可能前两者都不行。不存在一个"各方面都最好"的工作，只有"在某些方面更好、在其他方面可接受"的选择。

技能优化也是一样。不存在一个唯一的"最优技能"，只存在一组"各有所长"的候选技能。

帕累托支配：谁有资格淘汰谁

帕累托优化用一个简单的规则来判断两个变体之间的优劣关系，叫做帕累托支配：

如果变体 A 在所有指标上都不劣于变体 B，并且至少有一个指标严格更优，那么我们说"A 支配 B"。被支配的变体可以被淘汰。

这个规则的直觉是：如果 A 在准确性、效率、鲁棒性三个方面都不比 B 差，而且至少有一方面确实更好，那 B 就没有任何存在的理由了------选 A 在任何情况下都不会比选 B 差。反过来，如果 A 准确率更高但 Token 也更多，B 准确率更低但 Token 也更少，那两者互不支配，各有适用场景。

帕累托前沿：不被任何人支配的解的集合

把所有变体按支配关系筛选一遍，剩下的那些"不被任何其他变体支配"的解，就构成了帕累托前沿。前沿上的每个变体都有自己的长处，没有一个能被其他变体完全替代。

GEPA 的做法是：不要求找到唯一最优解，而是保留帕累托前沿上的所有优质变体，按任务侧重灵活选用。 如果任务对准确性要求极高（比如涉及金额的退款判定），就选前沿上准确率最高的那个变体；如果任务对成本敏感（比如批量处理大量简单咨询），就选 Token 消耗最低的那个变体；如果任务输入变化大（比如用户表述五花八门的开放问题），就选鲁棒性最高的变体。

用一个具体例子理解：退款技能的 6 个进化变体

假设 GEPA 对一个"电商客服退款技能"进行进化，产生了 6 个变体，每个变体在三个维度上的表现如下：

变体	技能特点	准确率	Token 消耗	鲁棒性
A	极简版：只写"告知用户退款入口"	65%	150	低
B	基础版：写清退款条件和操作步骤	75%	220	中
C	详细版：条件+步骤+常见问题 FAQ	82%	350	中高
D	精炼版：B 的内容但措辞大幅压缩	78%	180	中
E	全覆盖版：C 的内容+大量边界 case	85%	450	高
F	平衡版：条件+步骤+关键边界，措辞精炼	84%	280	中高

现在逐个判断谁被支配、谁留在前沿上。

第一步：找被支配的变体。

先看 B（75%，220，中）和 D（78%，180，中）：D 的准确率更高（78% > 75%），Token 消耗更低（180 < 220），鲁棒性相同。D 在所有指标上都不劣于 B，且有两项严格更优------D 支配 B，B 被淘汰。

再看 C（82%，350，中高）和 F（84%，280，中高）：F 的准确率更高（84% > 82%），Token 消耗更低（280 < 350），鲁棒性相同。同理，F 支配 C，C 被淘汰。

B 和 C 被淘汰的原因很典型：它们各自都有一个"全面碾压"自己的兄弟版本------B 被更精炼的 D 碾压，C 被更平衡的 F 碾压。这种"中间态"变体在进化中最容易被淘汰，因为它们既没有极端优势，又不够均衡。

第二步：确认前沿上的变体。

剩下的 A、D、E、F 四个变体，需要验证它们之间互不支配：

A（65%，150，低） ：准确率和鲁棒性都是最低的，但 Token 消耗只有 150，是所有变体中最低的。任何其他变体的 Token 都比 A 高，所以没有变体能够在"所有指标上都不劣于 A"------A 在效率维度上有不可替代的极端优势。A 留在前沿上。
D（78%，180，中） ：准确率中等偏上，Token 消耗第二低，鲁棒性中等。和 F 比，F 准确率更高、鲁棒性更高，但 Token 也更高（280 > 180），所以 F 不支配 D；和 A 比，A Token 更低。D 在"中等准确率下的极致效率"这个位置上没有对手。D 留在前沿上。
F（84%，280，中高） ：综合表现最好的变体------准确率第二高，Token 消耗中等，鲁棒性第二高。和 E 比，E 准确率更高（85% > 84%）、鲁棒性更高（高 > 中高），但 Token 也高得多（450 > 280），所以 E 不支配 F；和 D 比，D Token 更低。F 是"综合最优"的代表。F 留在前沿上。
E（85%，450，高） ：准确率最高、鲁棒性最高，但 Token 消耗也是最高的（450）。和 F 比，F Token 低很多，所以 F 不支配 E。E 在"高风险场景下的极致可靠性"这个位置上不可替代------比如涉及大额退款、容易引发投诉的场景，多花点 Token 换取最高的准确率和鲁棒性是值得的。E 留在前沿上。

最终结果：

状态	变体	存在的理由
淘汰	B	被 D 全面碾压（准确率更低、Token 更高、鲁棒性相同）
淘汰	C	被 F 全面碾压（准确率更低、Token 更高、鲁棒性相同）
前沿	A	Token 最低，适合批量处理简单咨询的成本敏感场景
前沿	D	中等准确率下的极致效率，适合日常大多数退款请求
前沿	F	综合最优，适合标准场景下的默认选择
前沿	E	准确率和鲁棒性最高，适合大额退款等高风险场景

这个例子清晰地展示了帕累托优化的核心思想：进化不是线性地"越改越好"，而是在多个目标之间探索不同的平衡点。 被淘汰的是那些"两头不靠"的中间态，留下来的是每个极端方向上的最优解。GEPA 不替你决定哪个方向最重要，而是把所有方向上的最优解都保留下来，让你根据具体场景做选择。

这对自进化 Agent 意味着什么

帕累托多目标优化的引入，让 Hermes 的自进化超越了"改对了就行"的简单层面。普通的自进化（比如 OpenClaw 的 Self-Improving-Agent）只看一个目标------"下次能不能做对"，改进是单向的、线性的。而 GEPA 承认一个现实：技能的好坏不是一维的，在不同场景下"好"的定义不同。

通过维护帕累托前沿，Hermes 理论上可以为不同类型的任务自动选择最合适的技能版本------高风险任务用鲁棒性优先的版本，批量任务用效率优先的版本，关键任务用准确性优先的版本。这不是简单的"技能越改越好"，而是"技能库越进化越能适应多样化的需求"。

第三部分演示 Demo：对自进化能力的模拟实现

demo演示了下"进化"。初始是测试集和故意写的不完善的skill，期望看到agent通过运行测试集，自己进化skill，提升skill的精准率。

复制代码

先测基线 → 分块答题 → 规则判错 → 把带原因的失败样本喂给持标准答案的 Reviewer → 它输出最小结构化补丁 → SkillManager 写回文件并存版本 → probe 复测量化提升。