📝

/images/Hermes-创始人亲自写的自进化工具不是训练模型而是在训练-Agent-配方/2a5b59342766。png Hermes 创始人亲自写的自进化工具：不是训练模型，而是在训练 Agent 配方最近看到一个挺有意思的新仓库： hermes-agent-self-evolution https://github

原文链接：https://mp.weixin.qq.com/s/ZKja7yPjNHwz7rnKPyXKEw

Hermes 创始人亲自写的自进化工具：不是训练模型，而是在训练 Agent 配方

最近看到一个挺有意思的新仓库：

hermes-agent-self-evolution (https://github.com/NousResearch/hermes-agent-self-evolution)

作者是 Hermes 创始人 @Teknium。

这个项目的目标写得很直接：

优化 Hermes。

它不是在搞一个“万能超级 Agent”，也不是训练大模型权重，而是想让 Hermes 这种技能驱动型 Agent，能通过工程化流程持续改进自己的能力配置。

更直白一点说：

它是在训练 Agent 的“使用说明书”和“技能配方”。

目前最实用、最先落地的部分，是优化 Hermes 的 SKILL.md 技能文件。

后面它还计划继续扩展到：

tool descriptions 工具描述优化
system prompt 系统提示词优化
代码实现优化
持续自动进化流水线

但不要一上来把它想得太大。

现阶段最实际的玩法就是：

拿一个 Hermes skill，让它自动生成评测集、自动尝试优化、自动对比前后效果。

一、它解决的是什么问题？

很多人做 Agent，最后都会遇到一个问题：

Agent 能不能不是靠作者手动改 prompt，而是靠反馈自己变强？

以前我们优化 skill 或 prompt，通常是这样：

用着不顺 → 拍脑袋改几句 → 再试试 → 感觉好像变好了。

问题是，这种方式太玄学。

没有基线，没有评测集，没有 holdout，没有约束，也没有可复现的改进流程。

hermes-agent-self-evolution 想做的，就是把这件事工程化。

它的核心闭环是：

目标

→ 数据集

→ 变异

→ 评测

→ 约束

→ PR

这比单纯“让模型帮我改 prompt”靠谱得多。

它最值钱的地方，不是会改 prompt。

而是它把 prompt / skill 优化这件事，做成了一个有数据、有验证、有约束的流程。

二、当前真正落地的是什么？

README 里讲的愿景比较大，但目前真正成熟的主线主要是：

Phase 1：优化 SKILL.md

也就是优化 Hermes 的技能文件。

比如你有一个 skill：

github-code-review
arxiv
repo-analysis
issue-triage
文档总结类 skill

它会读取当前的 SKILL.md，然后围绕这个 skill 构建测试任务，再跑优化器，最后判断新版本是不是比旧版本更好。

计划中的功能还包括：

tool description 优化
system prompt 优化
代码实现优化
持续自动进化流水线

但这些还不能当成已经完全成熟的能力。

所以现在最现实的定位是：

Hermes 的技能自动炼丹器。

不是训练模型权重，而是训练：

技能文本
提示结构
执行步骤
输出约束
行为表现

三、它的工作流像什么？

整个流程很像“自动调参”。

只不过调的不是模型参数，而是 skill 文本。

大概流程是：

读取当前 skill
构建评测集
跑优化器
对候选版本打分
过约束检查
输出改进版本，准备 PR

具体展开看：

1）读取当前 skill

比如你指定：

–skill github-code-review

它会去 Hermes 仓库里定位对应的 SKILL.md，把技能内容读进来。

也就是说，它不是凭空写一个 skill，而是基于你现有的 skill 进行优化。

2）构建评测集

它支持三种数据来源：

synthetic

sessiondb

golden

synthetic

模型自动根据 skill 生成测试题和评分标准。

适合第一次试流程。

优点：

最简单
开箱即用
不需要历史数据

缺点：

不一定贴近真实使用场景

sessiondb

从真实历史会话里挖任务。

它支持导入：

Claude Code 历史
GitHub Copilot 历史
Hermes 历史

这个点很关键。

因为真实任务比模型自动造题更接近实际使用。

仓库里的 external_importers.py 就是负责做这件事的。

它还会处理：

敏感信息过滤
API key / token / password 清洗
判断历史消息和 skill 是否相关
格式标准化

这说明它不是纯 demo，而是真的在考虑历史数据能不能安全进入评测流程。

golden

人工维护的高质量题库。

如果你要长期认真优化某个核心 skill，最好还是做 golden dataset。

优点是最可控，最适合长期复现。

缺点是需要自己整理数据。

3）跑优化器

核心用的是：

DSPy + GEPA

如果 GEPA 不可用，会回退到：

MIPROv2

它会把 skill 文本当成可优化对象，不断生成候选版本，然后在评测集上比较表现。

4）打分对比

它不是只看训练集。

它会切分：

train

val

holdout

最后会对比：

baseline 分数

evolved 分数

提升幅度

也就是说，它至少有基本的基线意识和保留集意识。

这比“让模型随便改一版，然后感觉好像更好”强很多。

5）过约束

README 里写了 guardrails。

每个进化版本必须过一些门槛，比如：

测试通过
skill 大小限制
tool description 长度限制
不能语义漂移
不能破坏缓存兼容
最终走 PR，人审

这个设计很重要。

因为 prompt 优化最怕的问题是：

短期分数上去了，长期行为变歪了。

比如一个 code review skill，为了在测试集上拿高分，可能会变得越来越啰嗦、越来越保守、越来越偏题。

所以约束层是必要的。

四、关键文件怎么看？

这个仓库目前不算大，整体还比较早期。

但结构已经比较清晰。

几个关键文件：

evolution/skills/evolve_skill.py

evolution/core/dataset_builder.py

evolution/core/external_importers.py

evolution/core/constraints.py

evolution/core/fitness.py

evolution/skills/skill_module.py

其中：

evolve_skill.py

主流程入口。

负责：

定位 skill
读取 SKILL.md
构建数据集
检查约束
跑优化器
对比 baseline 和 evolved
输出结果

dataset_builder.py

负责构建评测集。

synthetic 模式下，它会让模型根据 skill 文本生成：

task_input
expected_behavior
difficulty
category

然后切成：

train
val
holdout

所以 synthetic 本质上是：

先读 skill，再自动生成一套测试题。

external_importers.py

负责从真实历史记录里抽数据。

支持：

Claude Code：~/.claude/history.jsonl
Copilot：~/.copilot/session-state/…
Hermes：~/.hermes/sessions/…

它还会做敏感信息过滤。

这是这个项目比较有实战价值的一块。

因为真实会话数据如果能安全、稳定地转成评测集，那 Agent 的优化就不再只是玩具流程。

constraints.py

负责约束检查。

防止 evolved skill 变得太长、偏题、破坏兼容性。

fitness.py

负责评分逻辑。

也就是判断某个 skill 版本在任务上的表现到底好不好。

五、怎么安装？

README 给的最小安装流程是：

git clone https://github.com/NousResearch/hermes-agent-self-evolution.git

cd hermes-agent-self-evolution

pip install -e “.[dev]”

项目要求：

Python >= 3.10

主要依赖包括：

dspy

openai

pyyaml

click

rich

还需要告诉它 Hermes 主仓在哪里：

export HERMES_AGENT_REPO=~/.hermes/hermes-agent

注意，这个项目是外挂式的。

它会读取你的 Hermes 仓库内容，然后对 Hermes 的 skill 做进化。

六、第一次应该怎么玩？

如果只是想 10 分钟体验，建议不要一开始搞太复杂。

先跑 synthetic。

例如：

python -m evolution.skills.evolve_skill \

–skill github-code-review \

–iterations 5 \

–eval-source synthetic

这一步的目的不是一步到位炼出神级 skill。

而是先确认最小闭环能不能跑通：

环境能跑

skill 能找到

数据集能生成

优化器能执行

前后分数能对比

结果能输出

如果这套链路跑通，再考虑更实战的 sessiondb。

七、三种路线怎么选？

路线 1：最省事，跑 synthetic

适合：

第一次试
没有历史数据
想快速验证流程

命令：

python -m evolution.skills.evolve_skill \

–skill github-code-review \

–iterations 5 \

–eval-source synthetic

优点是简单。

缺点是 synthetic 数据不一定代表真实提升。

路线 2：更接近实战，跑 sessiondb

适合：

已经长期使用 Hermes / Claude / Copilot
有真实历史任务
想让优化更贴近实际使用

命令：

python -m evolution.skills.evolve_skill \

–skill github-code-review \

–iterations 5 \

–eval-source sessiondb

优点是更真实。

缺点是数据质量影响很大。

如果历史会话很乱，或者里面混了很多低质量任务，优化结果也会被带歪。

路线 3：长期认真做，维护 golden dataset

适合：

高频 skill
核心业务 skill
想持续稳定复现优化效果

示例：

python -m evolution.skills.evolve_skill \

–skill arxiv \

–eval-source golden \

–dataset datasets/skills/arxiv/

这是最严肃的路线。

缺点是要人工维护题库。

但如果你真的想让某个核心 skill 持续变强，golden dataset 是迟早要做的。

八、哪些 skill 适合先优化？

我建议优先挑这种：

输出结构固定

任务边界清晰

好坏容易判断

使用频率高

有真实任务积累

比如：

code review
repo analysis
issue triage
文档总结
学术检索
PR 审核
安全检查
数据清洗流程

这些任务比较容易打分，也更适合自动评测。

九、哪些不适合一开始就试？

不建议一上来优化太开放的 skill。

比如：

泛创作型
纯风格型
高开放式聊天
成功标准很主观的任务
边界非常宽的综合助理 skill

原因很简单：

不好评测。

如果连“什么叫好”都定义不清楚，优化器很容易优化到奇怪方向。

比如写作类 skill，模型可能为了拿高分变得更长、更套路、更像模板。

这不一定是真的更好。

十、它的优点是什么？

1）方向很对

很多 Agent 项目都在喊“自我进化”。

但大部分停留在概念。

这个项目至少把流程拆成了可执行步骤：

数据集

优化器

评测

约束

这是工程化的方向。

2）从 skill 开始，很务实

直接优化 system prompt 或代码实现，风险很大。

先优化 SKILL.md，风险更低，收益也更直观。

因为 Hermes 本来就是技能驱动型 Agent。

skill 写得好不好，直接影响 Agent 的执行质量。

3）真实会话导入很有价值

sessiondb 是很关键的一步。

Agent 真正的进化，不应该只靠模型自己造题。

而应该来自真实任务反馈。

如果后续这块做得更成熟，它会很有想象力。

4）有 guardrails，不是乱改

它不是自动乱改主仓。

而是生成改进版本，经过约束，再准备 PR。

这符合真实工程团队的使用方式。

十一、它的局限也很明显

1）项目还早期

当前真正落地的主线还是 skill evolution。

不要把 README 里的长期计划都当成已经实现。

2）评测质量决定上限

无论是 synthetic、sessiondb 还是 golden，数据集质量都会直接决定优化结果。

垃圾数据喂进去，只会炼出更会迎合垃圾题目的 skill。

3）LLM-as-judge 有噪音

评分本身也可能有主观性。

尤其是写作、总结、开放问题这类任务，打分不一定稳定。

4）有 API 成本

README 给的量级是单次大概几美元到十美元级别。

迭代次数越高，成本越高。

这不是本地免费训练。

5）更像研究型工具，不是大众即插即用

普通用户直接上手门槛不低。

它更适合已经在用 Hermes、并且愿意维护 skill / dataset / PR 流程的人。

十二、我怎么看这个项目？

我觉得这个项目抓住了一个很核心的问题：

Agent 怎么从“作者手写提示词”，走向“系统化反馈驱动的持续改进”。

这件事如果做通，对 Hermes 这种技能驱动型 Agent 非常重要。

因为 Agent 的能力不只来自底层模型。

还来自：

工具设计
skill 设计
system prompt
任务拆解方式
历史经验沉淀
评测体系

而 hermes-agent-self-evolution 做的事情，就是尝试把这些“Agent 配方”放进一个可优化流程里。

它不是训练模型。

它是在训练 Agent 的工作方式。

这可能比很多人想象得更重要。

最后总结

如果你期待它是一个现成超级 Agent，那它不是。

如果你关心的是：

Agent 能不能像产品一样，靠反馈持续变强？

那这个仓库值得研究。

当前最现实的使用方式就是：

选一个 skill

→ 自动生成评测

→ 自动优化

→ 看前后分数

→ 过约束

→ 走 PR

一句话概括：

这是 Hermes 的技能自动炼丹器。

不是训练模型权重，而是在训练 Agent 配方。

Hermes 创始人写了个挺有意思的自进化工具。

它不是训练模型，而是优化 Agent 的 skill、提示结构和工作流。

最关键的不是“会改 prompt”，而是它把流程做成了：

目标 → 数据集 → 变异 → 评测 → 约束 → PR

这比拍脑袋改 prompt 靠谱很多。

💬 本文评论区已开启，但暂无读者留言。

本文转载自微信公众号，如有侵权请联系删除。