第一部分 项目定位1.1 框架定位可以随使用自我成长的 AI AgentHermes 的定位用一句话就能说清“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 部署技能的突变示例原始版本 V0docker build .docker push $IMAGEssh deploy.sh突变后版本 V1LLM 自动改写docker build -t $TAG .docker images | grep $TAGdocker push $TAGssh 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详细版条件步骤常见问题 FAQ82%350中高D精炼版B 的内容但措辞大幅压缩78%180中E全覆盖版C 的内容大量边界 case85%450高F平衡版条件步骤关键边界措辞精炼84%280中高现在逐个判断谁被支配、谁留在前沿上。第一步找被支配的变体。先看 B75%220中和 D78%180中D 的准确率更高78% 75%Token 消耗更低180 220鲁棒性相同。D 在所有指标上都不劣于 B且有两项严格更优——D 支配 BB 被淘汰。再看 C82%350中高和 F84%280中高F 的准确率更高84% 82%Token 消耗更低280 350鲁棒性相同。同理F 支配 CC 被淘汰。B 和 C 被淘汰的原因很典型它们各自都有一个全面碾压自己的兄弟版本——B 被更精炼的 D 碾压C 被更平衡的 F 碾压。这种中间态变体在进化中最容易被淘汰因为它们既没有极端优势又不够均衡。第二步确认前沿上的变体。剩下的 A、D、E、F 四个变体需要验证它们之间互不支配A65%150低准确率和鲁棒性都是最低的但 Token 消耗只有 150是所有变体中最低的。任何其他变体的 Token 都比 A 高所以没有变体能够在所有指标上都不劣于 A——A 在效率维度上有不可替代的极端优势。A 留在前沿上。D78%180中准确率中等偏上Token 消耗第二低鲁棒性中等。和 F 比F 准确率更高、鲁棒性更高但 Token 也更高280 180所以 F 不支配 D和 A 比A Token 更低。D 在中等准确率下的极致效率这个位置上没有对手。D 留在前沿上。F84%280中高综合表现最好的变体——准确率第二高Token 消耗中等鲁棒性第二高。和 E 比E 准确率更高85% 84%、鲁棒性更高高 中高但 Token 也高得多450 280所以 E 不支配 F和 D 比D Token 更低。F 是综合最优的代表。F 留在前沿上。E85%450高准确率最高、鲁棒性最高但 Token 消耗也是最高的450。和 F 比F Token 低很多所以 F 不支配 E。E 在高风险场景下的极致可靠性这个位置上不可替代——比如涉及大额退款、容易引发投诉的场景多花点 Token 换取最高的准确率和鲁棒性是值得的。E 留在前沿上。最终结果状态变体存在的理由淘汰B被 D 全面碾压准确率更低、Token 更高、鲁棒性相同淘汰C被 F 全面碾压准确率更低、Token 更高、鲁棒性相同前沿AToken 最低适合批量处理简单咨询的成本敏感场景前沿D中等准确率下的极致效率适合日常大多数退款请求前沿F综合最优适合标准场景下的默认选择前沿E准确率和鲁棒性最高适合大额退款等高风险场景这个例子清晰地展示了帕累托优化的核心思想进化不是线性地越改越好而是在多个目标之间探索不同的平衡点。被淘汰的是那些两头不靠的中间态留下来的是每个极端方向上的最优解。GEPA 不替你决定哪个方向最重要而是把所有方向上的最优解都保留下来让你根据具体场景做选择。这对自进化 Agent 意味着什么帕累托多目标优化的引入让 Hermes 的自进化超越了改对了就行的简单层面。普通的自进化比如 OpenClaw 的 Self-Improving-Agent只看一个目标——“下次能不能做对”改进是单向的、线性的。而 GEPA 承认一个现实技能的好坏不是一维的在不同场景下好的定义不同。通过维护帕累托前沿Hermes 理论上可以为不同类型的任务自动选择最合适的技能版本——高风险任务用鲁棒性优先的版本批量任务用效率优先的版本关键任务用准确性优先的版本。这不是简单的技能越改越好而是技能库越进化越能适应多样化的需求。第三部分 演示 Demo对自进化能力的模拟实现demo演示了下“进化”。初始是测试集和故意写的不完善的skill期望看到agent通过运行测试集自己进化skill提升skill的精准率。先测基线 → 分块答题 → 规则判错 → 把带原因的失败样本喂给持标准答案的 Reviewer → 它输出最小结构化补丁 → SkillManager 写回文件并存版本 → probe 复测量化提升。 Hermes‑Agent（自进化agent）浅析
第一部分 项目定位1.1 框架定位可以随使用自我成长的 AI AgentHermes 的定位用一句话就能说清“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 部署技能的突变示例原始版本 V0docker build .docker push $IMAGEssh deploy.sh突变后版本 V1LLM 自动改写docker build -t $TAG .docker images | grep $TAGdocker push $TAGssh 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详细版条件步骤常见问题 FAQ82%350中高D精炼版B 的内容但措辞大幅压缩78%180中E全覆盖版C 的内容大量边界 case85%450高F平衡版条件步骤关键边界措辞精炼84%280中高现在逐个判断谁被支配、谁留在前沿上。第一步找被支配的变体。先看 B75%220中和 D78%180中D 的准确率更高78% 75%Token 消耗更低180 220鲁棒性相同。D 在所有指标上都不劣于 B且有两项严格更优——D 支配 BB 被淘汰。再看 C82%350中高和 F84%280中高F 的准确率更高84% 82%Token 消耗更低280 350鲁棒性相同。同理F 支配 CC 被淘汰。B 和 C 被淘汰的原因很典型它们各自都有一个全面碾压自己的兄弟版本——B 被更精炼的 D 碾压C 被更平衡的 F 碾压。这种中间态变体在进化中最容易被淘汰因为它们既没有极端优势又不够均衡。第二步确认前沿上的变体。剩下的 A、D、E、F 四个变体需要验证它们之间互不支配A65%150低准确率和鲁棒性都是最低的但 Token 消耗只有 150是所有变体中最低的。任何其他变体的 Token 都比 A 高所以没有变体能够在所有指标上都不劣于 A——A 在效率维度上有不可替代的极端优势。A 留在前沿上。D78%180中准确率中等偏上Token 消耗第二低鲁棒性中等。和 F 比F 准确率更高、鲁棒性更高但 Token 也更高280 180所以 F 不支配 D和 A 比A Token 更低。D 在中等准确率下的极致效率这个位置上没有对手。D 留在前沿上。F84%280中高综合表现最好的变体——准确率第二高Token 消耗中等鲁棒性第二高。和 E 比E 准确率更高85% 84%、鲁棒性更高高 中高但 Token 也高得多450 280所以 E 不支配 F和 D 比D Token 更低。F 是综合最优的代表。F 留在前沿上。E85%450高准确率最高、鲁棒性最高但 Token 消耗也是最高的450。和 F 比F Token 低很多所以 F 不支配 E。E 在高风险场景下的极致可靠性这个位置上不可替代——比如涉及大额退款、容易引发投诉的场景多花点 Token 换取最高的准确率和鲁棒性是值得的。E 留在前沿上。最终结果状态变体存在的理由淘汰B被 D 全面碾压准确率更低、Token 更高、鲁棒性相同淘汰C被 F 全面碾压准确率更低、Token 更高、鲁棒性相同前沿AToken 最低适合批量处理简单咨询的成本敏感场景前沿D中等准确率下的极致效率适合日常大多数退款请求前沿F综合最优适合标准场景下的默认选择前沿E准确率和鲁棒性最高适合大额退款等高风险场景这个例子清晰地展示了帕累托优化的核心思想进化不是线性地越改越好而是在多个目标之间探索不同的平衡点。被淘汰的是那些两头不靠的中间态留下来的是每个极端方向上的最优解。GEPA 不替你决定哪个方向最重要而是把所有方向上的最优解都保留下来让你根据具体场景做选择。这对自进化 Agent 意味着什么帕累托多目标优化的引入让 Hermes 的自进化超越了改对了就行的简单层面。普通的自进化比如 OpenClaw 的 Self-Improving-Agent只看一个目标——“下次能不能做对”改进是单向的、线性的。而 GEPA 承认一个现实技能的好坏不是一维的在不同场景下好的定义不同。通过维护帕累托前沿Hermes 理论上可以为不同类型的任务自动选择最合适的技能版本——高风险任务用鲁棒性优先的版本批量任务用效率优先的版本关键任务用准确性优先的版本。这不是简单的技能越改越好而是技能库越进化越能适应多样化的需求。第三部分 演示 Demo对自进化能力的模拟实现demo演示了下“进化”。初始是测试集和故意写的不完善的skill期望看到agent通过运行测试集自己进化skill提升skill的精准率。先测基线 → 分块答题 → 规则判错 → 把带原因的失败样本喂给持标准答案的 Reviewer → 它输出最小结构化补丁 → SkillManager 写回文件并存版本 → probe 复测量化提升。