1. 从「用完即忘」到「越用越强」Hermes-Agent 自进化 agent 到底解决了什么如果你写过 Agent大概率经历过这种循环给模型一套工具描述、一段 System Prompt跑起来效果还行但换个场景就崩崩了之后你手动改 Prompt改完再跑再崩再改。整个过程里Agent 本身没有任何变化变的是你。Hermes-Agent 想做的事情就是把这个「人改 Agent」的过程变成「Agent 改自己」。Hermes-Agent 是一个自进化 agent 框架核心口号是「The Agent That Grows With You」。它和市面上大多数静态 Agent 框架的区别在于每完成一次任务它会把操作流程沉淀成 SKILL.md 技能文件运行中发现更好的做法会通过 patch 机制局部修改技能离线时还能用 GEPA 遗传算法对技能做多目标优化。换句话说它的技能库不是人工写死的而是随着使用不断生长出来的。这套机制适合谁我认为有三类开发者值得关注。第一类是正在做垂直领域 Agent 的人比如电商客服、运维自动化、数据分析助手这些场景的共同点是任务模式会反复出现经验沉淀的收益很高。第二类是对 Agent 上下文成本敏感的人Hermes 的 Skill 六层渐进加载机制大多数场景只消耗名称加描述级别的 50 到 100 token确认需要某个技能时才加载完整内容。第三类是想理解自进化 Agent 设计思路的人Hermes 把个体运行时学习和种群离线进化两套模型并行运作这个设计本身就值得拆解。我试过把 Hermes 的技能进化流程跑一遍最直观的感受是它把「经验固化」这件事做成了工程闭环而不是停留在概念层面。下面我会从 SKILL.md 的结构讲起然后拆 GEPA 的帕累托优化取舍最后给出一套可复制的配置片段和一轮进化验证动作并说明怎么通过 TaoToken 统一 Key 和 API 通道接入模型完成对比实验。2. SKILL.md 技能定义与 GEPA 进化策略自进化 agent 的机制拆解2.1 SKILL.md 是什么把操作经验写成可加载的文件SKILL.md 是 Hermes-Agent 里技能的基本单位。你可以把它理解成一份「操作手册」里面写的是某个任务该怎么一步步做。和传统 Prompt 的区别在于它不是塞在 System Prompt 里一次性加载而是存在技能库中按需加载。一个典型的 SKILL.md 结构大概长这样--- name: digital_goods_refund description: 处理数字商品退款请求适用于已支付但未发货的订单 version: 3 tags: [refund, ecommerce, digital-goods] --- ## 适用场景 用户已支付数字商品订单但商品未发货或用户要求取消。 ## 操作步骤 1. 调用 order_query 工具传入 order_id确认订单状态为 paid 2. 检查商品类型是否为数字商品digitaltrue 3. 若未发货调用 refund_create传入 order_id 和 reason 4. 退款成功后调用 notify_user 发送确认消息 ## 注意事项 - 若订单状态为 shipped转人工处理 - 单笔退款金额超过 500 元时需要二次确认 - 退款失败时记录 error_code不要重试超过 2 次这个文件的关键在于它是纯文本LLM 天生擅长改写文本。所以无论是运行时 patch还是离线 GEPA 突变操作对象都是这份 Markdown不需要设计复杂的变异算子。2.2 个体学习Nudge 后台复盘怎么触发个体学习的核心是 Nudge 机制。Agent 每调用一次工具计数器加 1达到阈值默认 10 次后标记「需要复盘」。这里有个关键设计复盘判定在响应交付之后才激活。也就是说Agent 先把用户的回答返回确认主任务完成再在后台启动复盘流程不抢占主 Agent 的注意力。复盘不是主 Agent 自己做的而是派生一个独立的后台回顾 Agent。这个后台 Agent 接收父 Agent 的对话快照拥有 skill_manage 工具权限可以审查对话并决定创建或修改哪些技能。但它有严格的约束_skill_nudge_interval 0 # 后台 Agent 自己不会再触发 Nudge _memory_nudge_interval 0 # 记忆 Nudge 也禁用 max_iterations 20 # 轻量执行不允许跑太久这套隔离设计的本质是自进化是一个单向输出过程。主 Agent 产生经验后台 Agent 消化经验并写入技能库但后台 Agent 不能再产生新的复盘任务否则系统会陷入递归失控。回顾 Agent 审查完对话后会输出两种操作之一。create 是新建技能当发现一类反复出现的操作模式且现有技能库没有覆盖时创建一个全新的 SKILL.md。patch 是局部修改传入 old_text 和 new_text系统执行字符串替换后重新安全扫描再写入文件。patch 机制里有个工程细节值得注意原子写入。内部流程是先写入临时文件调用 os.fsync 刷盘再用 os.replace 原子替换原文件。这样保证任何时刻读者要么看到完整的旧版本要么看到完整的新版本不会看到写了一半的损坏文件。2.3 GEPA 离线进化把 SKILL.md 当作基因GEPA 的核心思想可以用一句话概括把 SKILL.md 文件当作生物的基因用遗传算法的方式让它一代代进化。这个比喻不是修辞而是整套机制的设计基础。基因对应 SKILL.md 文本每条技能是一个个体技能中的每句自然语言指令是可被突变的基因片段。染色体对应技能文件整体进化目标是让它更好地指导 Agent。种群对应多版本变体集合同时维护 N 个候选版本互相竞争。突变是 LLM 改写指令步骤随机改写技能中的某段文字产生新变体。交叉是混合两变体段落取 A 的前半部分加 B 的后半部分产生组合变体。自然选择是帕累托排序淘汰劣质变体优质变体进入下一代。这个映射的关键洞察是SKILL.md 是纯文本而 LLM 天生擅长改写文本。不需要设计复杂的变异算子让 LLM 自己去突变和交叉就行了。举个突变的具体例子。原始版本 V0 的 docker 部署技能docker build . docker push $IMAGE ssh deploy.sh突变后版本 V1docker build -t $TAG . docker images | grep $TAG docker push $TAG ssh deploy.sh; wait_healthy 60突变后新增了两步验证镜像是否构建成功以及部署后等待健康检查。这不是人工指定的改进而是 LLM 根据 docker 部署的上下文自动推断出来的。LLM 的预训练知识本身就是变异的灵感来源它能产生人类设计者可能没想到的改进方向。交叉操作模拟生物的有性繁殖取两个优质变体把它们的段落混合产生一个新变体。比如变体 A 的前半部分步骤写得好变体 B 的后半部分注意事项写得好交叉后可能得到一个前半用 A、后半用 B 的组合体。突变是单点探索交叉是组合探索。单靠突变每次只能在一个方向上小步改进有了交叉两个独立发现的好改进可以组合到同一个个体中加速进化。2.4 帕累托优化为什么没有单一的「最优技能」GEPA 评估一个技能变体时同时看三个指标准确性任务成功率越高越好、效率Token 消耗量越低越好、鲁棒性不同输入下的一致性越高越好。问题在于这三个目标通常不能同时达到最优。想提升准确率往往要在技能里写更多细节、更多示例这会增加 Token 消耗想降低 Token就要精简技能内容可能损失鲁棒性想提升鲁棒性就要覆盖更多边界情况又会增加 Token。帕累托优化用一个简单的规则来判断两个变体之间的优劣关系叫做帕累托支配如果变体 A 在所有指标上都不劣于变体 B并且至少有一个指标严格更优那么 A 支配 B被支配的变体可以被淘汰。把所有变体按支配关系筛选一遍剩下的那些不被任何其他变体支配的解就构成了帕累托前沿。用一个具体例子理解。假设 GEPA 对一个电商客服退款技能进行进化产生了 6 个变体变体技能特点准确率Token 消耗鲁棒性A极简版只写告知用户退款入口65%150低B基础版写清退款条件和操作步骤75%220中C详细版条件步骤常见问题 FAQ82%350中高D精炼版B 的内容但措辞大幅压缩78%180中E全覆盖版C 的内容大量边界 case85%450高F平衡版条件步骤关键边界措辞精炼84%280中高先看 B 和 DD 的准确率更高78% 大于 75%Token 消耗更低180 小于 220鲁棒性相同。D 在所有指标上都不劣于 B且有两项严格更优D 支配 BB 被淘汰。再看 C 和 FF 的准确率更高84% 大于 82%Token 消耗更低280 小于 350鲁棒性相同F 支配 CC 被淘汰。剩下的 A、D、E、F 四个变体互不支配。A 的 Token 消耗只有 150是所有变体中最低的任何其他变体的 Token 都比 A 高所以没有变体能在所有指标上都不劣于 A。D 在中等准确率下的极致效率这个位置上没有对手。F 是综合最优的代表。E 在准确率和鲁棒性上最高适合大额退款等高风险场景。最终结果是B 和 C 被淘汰A、D、F、E 留在帕累托前沿上。这个例子清晰地展示了帕累托优化的核心思想进化不是线性地越改越好而是在多个目标之间探索不同的平衡点。被淘汰的是那些两头不靠的中间态留下来的是每个极端方向上的最优解。3. 可复制配置用 TaoToken 统一 Key 接入 Hermes-Agent 做对比实验3.1 为什么需要统一 API 通道做 GEPA 对比实验时一个绕不开的问题是你需要同时调用多个模型来评估不同技能变体的表现。如果每个模型都要单独配置 Key、单独处理 base_url、单独管理限流实验还没开始配置工作就已经把人耗光了。TaoToken 在这里的作用是提供一个统一的 API 通道你只需要一个 Key就能在多个模型之间切换做对比实验时不用反复改配置。TaoToken 的 API 地址是https://taotoken.net/api官网是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content。下面给出 Hermes-Agent 的配置片段。3.2 Hermes-Agent 的 settings 配置Hermes-Agent 的模型配置通常放在~/.hermes/settings.json或项目根目录的hermes.config.json中。以下是一个可复制的配置片段{ model: { provider: openai-compatible, base_url: https://taotoken.net/api, api_key: sk-your-taotoken-key, model_id: claude-sonnet-4-20250514, max_tokens: 8192, temperature: 0.3 }, skill: { nudge_interval: 10, max_iterations: 20, skill_dir: ./skills, auto_patch: true }, gepa: { enabled: true, population_size: 6, mutation_rate: 0.4, crossover_rate: 0.3, objectives: [accuracy, token_efficiency, robustness], pareto_front_size: 4 } }如果你用的是 TOML 格式等价配置如下[model] provider openai-compatible base_url https://taotoken.net/api api_key sk-your-taotoken-key model_id claude-sonnet-4-20250514 max_tokens 8192 temperature 0.3 [skill] nudge_interval 10 max_iterations 20 skill_dir ./skills auto_patch true [gepa] enabled true population_size 6 mutation_rate 0.4 crossover_rate 0.3 objectives [accuracy, token_efficiency, robustness] pareto_front_size 4这里有三件套需要确认Base URL 填https://taotoken.net/apiKey 填你在 TaoToken 控制台创建的 API KeyModel ID 填你要用的模型标识。如果你用的是 Claude Code 或 Cline 这类工具配置逻辑是一样的把 Base URL 和 Key 填进去即可。3.3 环境变量方式如果你不想改配置文件也可以用环境变量export HERMES_MODEL_PROVIDERopenai-compatible export HERMES_BASE_URLhttps://taotoken.net/api export HERMES_API_KEYsk-your-taotoken-key export HERMES_MODEL_IDclaude-sonnet-4-20250514 export HERMES_SKILL_DIR./skills export HERMES_GEPA_ENABLEDtrue配置完成后你可以用一条简单的 curl 命令验证通道是否通curl -X POST https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-your-taotoken-key \ -d { model: claude-sonnet-4-20250514, messages: [{role: user, content: 回复 OK}], max_tokens: 10 }如果返回里能看到choices字段和正常的 content说明通道没问题。这一步很重要因为后面 GEPA 进化一轮可能要上百次 LLM 调用通道不稳定会直接导致实验失败。4. 验证请求与成功结果跑一轮技能进化看提升4.1 准备测试集和初始技能验证自进化能力最直接的方式是准备一个测试集和一个故意写得不完善的技能然后看 Agent 能不能通过运行测试集自己进化技能提升精准率。先建一个测试集文件test_cases.json[ { input: 订单 ORD-001 已支付但未发货用户要求退款, expected_action: refund_create, expected_params: {order_id: ORD-001, reason: user_request} }, { input: 订单 ORD-002 已发货用户要求退款, expected_action: transfer_to_human, expected_params: {} }, { input: 订单 ORD-003 已支付金额 800 元用户要求退款, expected_action: refund_create_with_confirm, expected_params: {order_id: ORD-003, amount: 800} } ]然后写一个故意不完善的初始技能skills/refund_v0.md--- name: refund description: 处理退款 --- ## 步骤 1. 调用 refund_create 2. 通知用户这个技能的问题很明显没有区分已发货和未发货没有处理大额退款的二次确认没有错误处理。4.2 运行进化脚本Hermes-Agent 的进化脚本通常叫evolve_skill.py运行方式如下python evolve_skill.py \ --skill ./skills/refund_v0.md \ --test-cases ./test_cases.json \ --generations 3 \ --population 6 \ --output ./skills/refund_evolved.md脚本的执行流程是先测基线用初始技能跑一遍测试集记录准确率然后分块答题把测试用例按类型分组接着规则判错对比 expected_action 和实际 action把带原因的失败样本喂给持标准答案的 ReviewerReviewer 输出最小结构化补丁SkillManager 写回文件并存版本最后 probe 复测量化提升。4.3 成功结果长什么样跑完一轮后你会看到类似这样的输出[Baseline] accuracy0.33, tokens180, robustness0.40 [Generation 1] accuracy0.67, tokens240, robustness0.60 [Generation 2] accuracy0.89, tokens280, robustness0.80 [Generation 3] accuracy1.00, tokens310, robustness0.90 [Pareto Front] 4 variants retained - variant_A: accuracy1.00, tokens310, robustness0.90 - variant_B: accuracy0.89, tokens220, robustness0.70 - variant_C: accuracy0.78, tokens180, robustness0.60 - variant_D: accuracy0.67, tokens150, robustness0.50进化后的技能文件refund_evolved.md大概会变成这样--- name: refund description: 处理退款请求区分已发货和未发货支持大额二次确认 version: 3 --- ## 适用场景 用户要求对已支付订单进行退款。 ## 步骤 1. 调用 order_query 确认订单状态 2. 若状态为 shipped调用 transfer_to_human 转人工 3. 若状态为 paid 且金额小于 500调用 refund_create 4. 若状态为 paid 且金额大于等于 500调用 refund_create_with_confirm 5. 退款成功后调用 notify_user 通知用户 ## 注意事项 - 退款失败时记录 error_code重试不超过 2 次 - 大额退款必须二次确认对比初始版本进化后的技能增加了状态判断、大额确认、错误处理准确率从 33% 提升到 100%。这就是一轮完整的进化验证。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth5.1 401 Unauthorized这是最常见的错误通常有三个原因。第一API Key 填错了检查sk-开头的那串字符有没有复制完整。第二Key 前面多了空格或者换行用echo $HERMES_API_KEY | xxd看一下有没有隐藏字符。第三Base URL 写成了https://taotoken.net/api/带了尾部斜杠有些客户端会拼成//v1/chat/completions导致鉴权失败。正确的写法是https://taotoken.net/api不带尾部斜杠。5.2 local proxy failed这个报错通常出现在你本地配了代理但代理没启动或者端口不对。排查步骤先确认环境变量HTTP_PROXY和HTTPS_PROXY有没有设置如果设置了但代理没跑直接 unset 掉。然后检查NO_PROXY里有没有把taotoken.net加进去。如果你用的是公司网络可能需要找运维确认出口策略。5.3 reading choices 相关报错这个错误一般长这样KeyError: choices或者reading choices of undefined。原因是 API 返回的结构和你代码里解析的结构不一致。常见情况是你请求的模型 ID 写错了服务端返回了一个错误对象而不是正常的 completion 响应。排查方法先用 curl 单独请求一次看返回的 JSON 顶层有没有choices字段。如果没有看error字段里的 message通常是模型 ID 不存在或者参数不合法。5.4 OAuth 相关报错如果你用的是 Claude Code 或者 Codex 这类工具可能会遇到 OAuth 报错。这类工具默认走 OAuth 流程但如果你要接自定义 API 通道需要切换到 API Key 模式。以 Codex 为例检查~/.codex/auth.json{ OPENAI_API_KEY: sk-your-taotoken-key, OPENAI_BASE_URL: https://taotoken.net/api }如果 auth.json 里还有tokens字段说明它还在走 OAuth需要把 tokens 删掉只保留 API Key 和 Base URL。Claude Code 的话检查~/.claude/settings.json里的env字段确保ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY都指向 TaoToken。5.5 GEPA 进化不收敛如果跑了很多代准确率还是上不去先检查测试集是不是太小。GEPA 需要足够的样本才能区分变体优劣测试集少于 10 条时评估结果波动会很大。其次检查 mutation_rate 和 crossover_rate如果都设成 0.1 以下种群多样性不足容易早熟收敛。建议 mutation_rate 设 0.3 到 0.5crossover_rate 设 0.2 到 0.4。最后检查 objectives 的权重如果三个目标权重一样帕累托前沿可能会保留太多变体导致选择困难。6. 把自进化 agent 接进你的工作流Hermes-Agent 的自进化机制本质上是在回答一个问题怎么让 Agent 从「每次从零开始」变成「越用越强」。它的答案是把经验固化成 SKILL.md用 Nudge 机制在运行时持续改进用 GEPA 在离线时做种群进化用帕累托优化在多个目标之间保留多样化的最优解。如果你想动手试我建议从最小闭环开始先写一个不完善的 SKILL.md准备 10 条测试用例跑一轮 evolve_skill.py看准确率有没有提升。通道方面用 TaoToken 统一 Key 和 Base URL省去多模型切换的配置麻烦。模型对话可以在https://taotoken.net/api对应的控制台里调试API Key 在https://taotoken.net/api-keys创建接入文档在https://taotoken.net/doc。如果你打算长期跑编码类 Agent 或者做多轮进化实验Coding Plan 会比按量计费更划算具体在https://taotoken.net/coding-plan看。最后说一个我踩过的坑GEPA 进化一轮可能要上百次 LLM 调用如果你的测试集有 50 条种群大小 6跑 5 代那就是 1500 次调用。跑之前先算一下预算别跑到一半发现额度不够了。建议先用小测试集跑通流程确认进化逻辑没问题再放大规模。