1. 为什么“自我进化”是 AI Agent 落地的分水岭过去一年我经手过不少 AI Agent 项目从简单的客服问答到复杂的多步骤任务编排踩过的坑基本能写一本小册子。但真正让我意识到“Agent 和普通 LLM 调用是两码事”的是第一次遇到同一个任务反复失败、Agent 却毫无长进的场景。你给它一个复杂指令它跑一遍错了再跑一遍还是错第三遍依然在同一个地方翻车——这跟一个实习生连续三天犯同一个错误没什么区别。Hermes Agent 里的 GEPA 自我进化引擎解决的正是这个问题。GEPA 是Generalized Evolutionary Prompt Adaptation的缩写直译过来就是“广义进化式提示自适应”。说人话就是让 Agent 在运行过程中根据自己执行任务的成功与失败自动调整内部的提示策略、工具调用顺序和推理路径而不是每次都从同一个起点重新开始。这个能力为什么关键因为绝大多数 AI Agent 的“智能”其实是一次性的——模型权重固定提示词固定工具列表固定。你部署上线那一刻是什么水平后面基本就是什么水平除非你手动去改提示词、换模型、加工具。但真实业务场景是动态的用户需求在变数据格式在变外部 API 在变一个不会自我迭代的 Agent 很快就会从“能用”退化到“不能用”。GEPA 的核心价值在于把“调优”这件事从人工离线操作变成了Agent 自身的在线能力。它不需要你重新训练模型也不需要你手动写几十版提示词做 A/B 测试而是让 Agent 在每一次任务执行后自动评估结果、提取失败模式、生成改进策略并在后续任务中验证这些策略是否有效。有效就保留无效就淘汰——本质上是一套运行在提示词和工具调用层面的“自然选择”机制。适合谁来深入了解这块内容三类人最应该关注一是正在做 AI Agent 应用开发、被“效果不稳定”折磨的工程师二是负责企业级 Agent 平台架构、需要考虑长期可维护性的技术负责人三是对 Agent 自我改进机制好奇、想从 0 到 1 搭建练手项目的开发者。哪怕你目前只用过 DeepSeek 这类模型的 API 做简单问答理解 GEPA 的思路对你设计更复杂的 Agent 系统也会有直接帮助。2. GEPA 引擎的整体设计与核心思路拆解2.1 从 DSPy 到 GEPA一条清晰的演进脉络要理解 GEPA 的设计得先知道它站在谁的肩膀上。DSPy 是斯坦福 NLP 组推出的一个框架核心思想是把 LLM 的提示词从“手写字符串”变成“可编程的模块”然后通过编译器自动优化这些模块的参数和提示。DSPy 解决的是“离线优化”问题——你在开发阶段准备好训练数据跑一遍编译得到一个优化后的提示词集合然后部署上线。但 DSPy 有个明显的局限它的优化是静态的、离线的。上线之后如果任务分布发生变化优化过的提示词可能就不再适用了而 DSPy 本身没有在线自适应能力。GEPA 在 Hermes Agent 里的定位就是在 DSPy 的模块化基础上加了一层运行时进化机制。具体来说GEPA 把 Agent 的每一次任务执行看作一次“个体表现”把 Agent 内部的提示策略、工具选择偏好、推理链长度等看作“基因”。任务成功后表现好的“基因组合”会被保留并扩散到后续任务中任务失败后GEPA 会分析失败原因尝试对“基因”进行变异——比如换一种提示模板、调整工具调用顺序、增加或减少推理步骤——然后在后续任务中测试变异效果。这个思路跟生物进化非常像变异、选择、保留。区别在于 GEPA 的进化发生在提示词和调用策略层面而不是模型权重层面所以它不需要 GPU 训练完全可以在 CPU 上跑响应速度也快得多。2.2 为什么选择“提示层进化”而不是“模型微调”这里有一个关键的设计取舍需要解释清楚。让 Agent 自我迭代理论上至少有三种路径一是微调模型权重二是训练一个奖励模型做强化学习三是在提示词和工具调用层面做进化。GEPA 选了第三条路原因很实际。微调模型权重的成本太高。一次完整的微调需要准备标注数据、租用 GPU、跑几个小时甚至几天而且微调后的模型很难回滚——如果新版本在某些任务上变差了你没法只回退那部分能力。对于需要快速迭代的 Agent 场景来说这个周期完全不可接受。强化学习路径的问题在于样本效率。训练一个稳定的奖励模型需要大量交互数据而且奖励信号的设计本身就很困难——什么算“好”的 Agent 行为是任务完成率高还是步骤少还是用户满意度高这些目标之间经常冲突设计不当会导致 Agent 学会“刷分”而不是真正解决问题。提示层进化的优势在于低成本、可解释、可回滚。GEPA 的每一次“变异”本质上就是生成一个新的提示模板或调整一组工具调用参数这些都以结构化数据的形式存储在 Agent 的配置里。如果某个变异导致效果变差直接删掉那条配置就行不影响其他能力。而且因为所有变化都在提示词层面你可以直接看到 Agent 为什么做了某个选择调试起来比黑盒模型容易得多。注意提示层进化并不意味着模型本身不重要。GEPA 的效果高度依赖底层模型的指令遵循能力和推理能力。如果底层模型连基本的多步推理都做不好GEPA 的进化空间会非常有限。所以选一个靠谱的基座模型仍然是前提。2.3 GEPA 在 Hermes Agent 架构中的位置Hermes Agent 的整体架构可以粗略分为四层最底层是模型接入层负责对接各种 LLM API往上是工具层管理 Agent 可以调用的外部工具再往上是 GEPA 进化层负责策略的生成、评估和选择最上面是任务编排层负责接收用户请求、拆解任务、调度工具和模型。GEPA 进化层不直接跟用户交互也不直接调用工具它更像是一个“幕后教练”。每次任务执行完毕后任务编排层会把执行轨迹——包括每一步的输入输出、工具调用结果、最终任务状态——传给 GEPA 层。GEPA 层分析这些轨迹判断哪些策略有效、哪些无效然后生成新的策略候选存入策略库。下一次任务执行时任务编排层会从策略库里选取当前最优的策略组合来指导 Agent 的行为。这个设计的巧妙之处在于解耦。任务编排层不需要知道策略是怎么来的GEPA 层也不需要关心具体任务是什么。两者通过策略库这个接口交互各自可以独立演进。你甚至可以替换掉 GEPA 层换成别的进化机制只要接口不变上层任务编排不受影响。3. 核心细节解析与实操要点3.1 策略表示GEPA 的“基因”长什么样GEPA 的进化对象是“策略”那策略具体是什么在 Hermes Agent 的实现里一个策略单元包含以下几个字段提示模板用于指导模型完成特定子任务的提示词模板支持变量插值。工具偏好在多个可用工具功能重叠时优先选择哪个工具的权重。推理深度控制模型在给出最终答案前进行多少步内部推理。重试策略当某个步骤失败时是重试、换工具还是跳过。上下文裁剪规则当对话历史过长时保留哪些部分、丢弃哪些部分。这些字段组合在一起就形成了一个策略的“基因型”。GEPA 的进化操作就是对这些字段进行变异和组合。比如一个策略在“数据查询”子任务上表现不好GEPA 可能会尝试把提示模板从“请查询以下数据”改成“请先确认数据表结构再执行查询”同时把推理深度从 2 调到 3看看效果是否改善。这里有个实操要点策略的粒度不能太粗也不能太细。如果策略太粗比如一个策略管所有任务那变异空间太大GEPA 很难找到有效方向如果策略太细比如每个 API 调用都单独一个策略那策略数量会爆炸管理成本极高。Hermes Agent 的常见做法是按“子任务类型”来划分策略粒度比如“信息检索”“数据转换”“结果汇总”各有一套策略这样既保证了针对性又不至于太碎。3.2 评估信号怎么判断一个策略是好是坏GEPA 的进化依赖评估信号也就是“适应度函数”。没有好的评估信号进化就会变成随机游走。Hermes Agent 里常用的评估信号有三类第一类是任务完成度这是最直接的信号。任务成功完成得 1 分部分完成得 0.5 分完全失败得 0 分。但光看完成度不够因为有些任务虽然完成了但步骤冗余、耗时过长。第二类是效率指标包括总步骤数、总 token 消耗、总耗时。同样的任务用 3 步完成和用 10 步完成质量是不一样的。GEPA 会把效率指标作为惩罚项纳入适应度计算。第三类是中间步骤质量这个比较难量化但在复杂任务里很重要。比如一个多步推理任务最终答案对了但中间某一步的推理是错的只是碰巧结论对了。这种“侥幸成功”如果被当成好策略保留下来后续任务很容易翻车。Hermes Agent 的做法是对关键中间步骤做抽样检查用另一个模型实例或者规则引擎来判断中间结果是否合理。提示评估信号的设计直接决定 GEPA 的进化方向。如果你只奖励任务完成度Agent 可能会学会“不管三七二十一先把任务标记为完成”如果你只奖励效率Agent 可能会学会“跳过必要步骤”。多信号加权是必须的权重需要根据业务场景调整。3.3 变异操作GEPA 怎么生成新策略GEPA 的变异操作主要有四种我按使用频率从高到低排列第一种是提示模板改写。这是最常用也最安全的变异方式。GEPA 会把当前策略的提示模板和失败案例一起发给一个“变异模型”让变异模型生成几个改进版本。比如原模板是“请总结以下文本”失败原因是总结太笼统变异模型可能会生成“请提取以下文本中的三个关键论点每个论点用一句话概括”。这种变异成本低、可解释性强是 GEPA 的主力操作。第二种是工具偏好调整。当 Agent 在多个工具之间选择时GEPA 会调整工具选择的权重。比如发现某个任务用工具 A 的成功率明显高于工具 B就会提高 A 的权重。这个操作需要积累一定数量的执行样本才能生效冷启动阶段效果不明显。第三种是推理深度调整。有些任务失败是因为模型推理太浅有些则是因为推理太深导致“想太多”反而出错。GEPA 会根据失败模式动态调整推理深度参数。这个操作的风险在于推理深度和任务类型强相关一个策略上的调整不一定能泛化到其他任务。第四种是策略组合。当两个策略分别在各自任务上表现良好时GEPA 会尝试把它们组合成一个新策略看看组合后的效果是否超过单独使用。这个操作的搜索空间最大但也最容易产生意外结果通常只在策略库比较丰富时才启用。3.4 策略选择怎么决定用哪个策略策略库里有了一堆候选策略下一个问题是每次任务执行时用哪个Hermes Agent 用的是多臂老虎机的思路具体来说是 Thompson Sampling 的一个变体。简单解释一下每个策略都有一个“成功率分布”初始时所有策略的分布都很宽表示不确定。每次任务执行前GEPA 从每个策略的分布中采样一个值选采样值最高的策略来执行。任务完成后根据结果更新该策略的分布——成功则分布向高成功率方向移动失败则向低成功率方向移动。随着执行次数增加好策略的分布会越来越窄且集中在高成功率区域被选中的概率自然越来越大。这个机制的好处是自动平衡探索和利用。初期所有策略都有机会被尝试避免过早锁定在局部最优后期好策略逐渐胜出保证整体效率。实操中需要注意的是策略库不能无限增长需要定期淘汰长期表现差的策略否则采样开销会越来越大。4. 实操过程与核心环节实现4.1 环境准备与 Hermes Agent 安装要点在动手之前先把环境理清楚。Hermes Agent 的部署方式比较灵活可以单机跑也可以多容器部署。如果你只是想体验 GEPA 的进化效果单机模式足够了。多容器部署适合需要隔离工具环境或者做压力测试的场景。安装过程中最容易卡住的地方是依赖下载。常见报错包括failed to download repository和请求的名称有效这类网络相关的问题。这类问题的根源通常是包管理器的源配置或者 DNS 解析。我的处理顺序是先确认基础网络连通性再检查包管理器源是否可达最后看 DNS 配置。如果是企业内网环境可能需要配置内部镜像源。另一个常见坑是 Python 版本兼容性。Hermes Agent 对 Python 版本有要求太老的版本会导致部分依赖装不上太新的版本又可能有兼容性问题。我实测下来3.10 到 3.11 之间的版本最稳。建议用虚拟环境隔离避免污染系统 Python。安装完成后先跑一个最小验证让 Agent 执行一个简单的两步任务比如“查询当前时间然后计算距离今天结束还有多少小时”。这个任务足够简单能快速验证模型接入、工具调用、任务编排三条链路是否通畅。如果这个都跑不通先别急着上 GEPA把基础链路调通再说。4.2 配置 GEPA 进化引擎的关键参数GEPA 的配置主要集中在进化策略和评估信号两块。下面这张表是我在实际项目中总结的常用参数和推荐值参数名作用推荐值说明evolution_interval每多少次任务执行后触发一次进化10-20太小会导致策略频繁变动太大则进化太慢mutation_rate每次进化生成新策略的比例0.2-0.3太高会引入太多噪声太低则探索不足selection_temperature策略选择的随机性0.5-1.0值越大越倾向于探索新策略max_strategy_pool策略库最大容量50-100超过后淘汰最差策略min_samples_per_strategy策略被评估前的最少执行次数5避免因样本太少而误判策略好坏fitness_weights完成度/效率/中间质量的权重0.6/0.2/0.2根据业务场景调整这些参数没有绝对的最优值需要根据你的任务类型和执行频率来调。比如任务执行频率很高每分钟几十次evolution_interval可以设小一点让进化更快如果任务执行频率低每天几次设太大可能几天才进化一次设太小又样本不足。4.3 一个完整的 GEPA 进化循环实操记录下面我用一个实际项目里的场景来演示 GEPA 的完整进化循环。任务场景是“从用户邮件中提取关键信息并生成回复草稿”涉及信息抽取、意图判断、回复生成三个子任务。第一轮执行Agent 用初始策略执行了 20 个任务成功率 65%。失败案例集中在“意图判断”子任务上很多邮件同时包含多个意图Agent 只识别了其中一个。第一次进化触发GEPA 分析了失败案例发现“意图判断”的提示模板过于简单只要求“判断邮件意图”没有要求列出所有可能的意图。变异模型生成了三个新模板其中一个要求“列出邮件中所有可能的意图并按置信度排序”。第二轮执行新策略被选中执行了 15 个任务意图判断的准确率从 65% 提升到 82%。但出现了新问题回复生成步骤的耗时增加了因为 Agent 在生成回复前会先列出所有意图导致上下文变长。第二次进化触发GEPA 检测到效率指标下降对“回复生成”子任务的上下文裁剪规则做了变异增加了“只保留置信度最高的两个意图”的规则。第三轮执行整体成功率提升到 88%平均耗时回到正常水平。这个策略组合被保留下来成为后续任务的默认策略。这个循环里最关键的是评估信号的准确性。如果第一轮只看了成功率没有分析失败模式GEPA 就不知道该往哪个方向变异。如果第二轮只看成功率提升忽略了耗时增加最终策略会变得又慢又重。多信号评估是 GEPA 有效运转的前提。4.4 策略库的持久化与管理GEPA 进化出来的策略需要持久化存储否则重启一次就全丢了。Hermes Agent 默认把策略库存成 JSON 文件每个策略一条记录包含策略内容、历史表现、创建时间、最后使用时间等字段。策略库的管理有几个实操要点。第一定期备份。策略库是 Agent 的核心资产丢了就得重新进化成本很高。第二版本控制。每次进化产生的策略变更都应该记录方便回溯和回滚。第三冷热分离。长期不用的策略可以归档到冷存储减少主库的查询开销。还有一个容易被忽略的点策略库的跨环境迁移。如果你在开发环境进化出了一套好策略想迁移到生产环境直接复制 JSON 文件通常不够因为策略里可能引用了开发环境特有的工具配置或模型参数。迁移前需要做一次配置映射把环境相关的字段替换掉。5. 常见问题与排查技巧实录5.1 GEPA 进化效果不明显怎么办这是被问得最多的问题。GEPA 跑了一段时间策略也进化了但整体效果提升很小。排查思路按以下顺序来先看评估信号是否区分度不够。如果所有策略的适应度得分都差不多GEPA 就没有选择压力进化会变成随机漂移。解决办法是细化评估指标比如把“任务完成度”拆成“信息抽取准确率”“意图判断准确率”“回复可用率”三个独立指标让不同策略在不同维度上拉开差距。再看变异操作是否有效。如果变异生成的策略跟原策略差别很小进化就只是在原地打转。可以检查变异模型的提示词确保它被要求生成“有实质性差异”的候选策略。另外变异模型的选型也很重要用一个能力太弱的模型做变异生成的策略质量会很差。最后看策略选择机制是否合理。如果 Thompson Sampling 的参数设置不当比如selection_temperature太低Agent 会过早锁定在某个策略上不再探索新策略。适当提高探索温度给新策略更多机会。5.2 策略库膨胀导致性能下降策略库不是越大越好。当策略数量超过一定规模后每次任务执行前的策略采样开销会显著增加而且策略之间的干扰也会变多。我遇到过策略库涨到 200 多条后单次任务耗时增加了 40% 的情况。处理办法是定期淘汰。淘汰规则可以综合策略的近期表现、使用频率和创建时间。比如“最近 50 次执行中成功率低于 40% 且超过 7 天未被使用”的策略直接删除。淘汰时注意保留那些虽然近期表现一般但曾经表现优秀的策略因为它们可能只是暂时不适应新的任务分布。另一个办法是策略聚类。把功能相似的策略归为一组组内只保留表现最好的几个减少冗余。这个操作可以在策略库达到一定规模后定期执行。5.3 进化后的策略在新任务上表现不稳定这种情况通常是因为过拟合。GEPA 在旧任务上进化出的策略可能过度适应了旧任务的特征换到新任务上就不行了。这跟机器学习里的过拟合是一个道理。缓解办法有几个。一是保留一定比例的随机策略不让 Agent 完全依赖进化出来的策略保持对新任务的适应能力。二是在评估信号里加入多样性惩罚如果一个策略只在特定类型的任务上表现好在其他任务上表现差适应度会被拉低。三是定期用新任务数据重新评估策略库把不适应新数据的策略降权或淘汰。5.4 常见问题速查表问题现象可能原因排查方向解决建议进化后效果无提升评估信号区分度不足检查各策略适应度分布细化评估指标增加维度策略库增长过快淘汰机制缺失查看策略创建和淘汰记录设置容量上限和淘汰规则新任务表现差策略过拟合旧任务对比新旧任务的特征分布保留随机策略加多样性惩罚进化循环卡住变异操作无效检查变异模型输出质量换更强的变异模型调整变异提示任务耗时增加策略过于复杂分析策略的步骤数和 token 消耗在适应度中加入效率惩罚策略选择震荡探索温度过高观察策略选择的历史分布降低 selection_temperature5.5 几个我踩过的坑和对应技巧第一个坑是过早优化。项目刚开始跑任务样本还不到 50 个就急着开 GEPA 进化。结果进化出来的策略严重过拟合那几十个样本换一批任务就崩了。后来我给自己定了个规矩至少积累 200 个以上的任务执行样本再启动 GEPA。样本太少的时候先把基础提示词调好别指望进化引擎能变魔术。第二个坑是评估信号里混入了噪声。有段时间我发现 GEPA 进化出来的策略时好时坏排查了很久才发现是任务完成度的判定逻辑有问题——有些任务实际上失败了但因为异常处理没做好被标记成了成功。评估信号被污染后GEPA 的进化方向完全跑偏。评估逻辑的可靠性比进化算法本身更重要这是血的教训。第三个技巧是给变异操作加约束。早期我让变异模型自由发挥结果生成了一堆天马行空的策略大部分根本跑不通。后来我在变异提示里加了硬约束新策略必须兼容现有的工具接口提示模板的变量数量不能超过原模板的两倍推理深度调整幅度不超过正负 2。加了约束之后变异策略的可用率从不到 30% 提升到了 70% 以上。第四个技巧是人工审核关键策略。GEPA 是全自动的但全自动不代表可以完全放手。对于影响面大的策略变更比如涉及核心业务逻辑的提示模板改写我会让 GEPA 先在小流量上验证确认效果后再全量。这个“人工在环”的机制虽然增加了一点操作成本但避免了好几次潜在的生产事故。6. 从 GEPA 延伸出去的几个思考GEPA 这套机制跑通之后我陆续在几个不同场景里做了迁移实验有一些额外的发现值得分享。第一个发现是GEPA 对工具设计的反馈价值。当 GEPA 反复在某个工具上进化失败时往往说明这个工具本身的设计有问题——可能是接口太复杂可能是返回结果格式不统一也可能是功能重叠导致 Agent 难以选择。这时候与其继续调策略不如回头改工具。我在一个项目里就是通过 GEPA 的失败模式分析发现某个数据查询工具的参数设计过于繁琐简化之后 Agent 的成功率直接提升了 20 个百分点。第二个发现是GEPA 和人工提示词工程不是替代关系。有人觉得有了 GEPA 就不需要手写提示词了这个想法不对。GEPA 的进化是在现有提示词基础上的微调如果初始提示词质量太差进化空间会很有限。我的做法是先用人工把提示词写到 70 分水平再让 GEPA 去攻剩下的 30 分。人工负责框架和方向GEPA 负责细节和自适应。第三个发现是GEPA 的进化结果可以反哺模型选型。通过观察 GEPA 在不同基座模型上的进化效率和最终效果可以判断哪个模型更适合当前任务。有些模型指令遵循能力强但推理能力弱GEPA 在需要多步推理的任务上进化会很吃力有些模型推理强但输出格式不稳定GEPA 在需要结构化输出的任务上会频繁变异。这些观察结果比单纯的 benchmark 分数更有参考价值。第四个发现是GEPA 的长期运行需要关注策略的“代际退化”。进化不是单调向好的有时候会出现“后代不如祖先”的情况。原因可能是变异累积了太多微小改动导致策略偏离了最初的有效方向。我的处理办法是定期做一次“回交”——把当前最优策略和早期的一个高表现策略做组合引入一些“古老基因”防止策略在局部最优附近过度特化。这些经验不一定适用于所有场景但如果你正在搭建自己的 AI Agent 系统并且打算引入自我进化机制希望这些踩坑记录能帮你少走一些弯路。GEPA 不是银弹它更像是一个放大器——你的基础架构越扎实、评估信号越准确、工具设计越合理GEPA 能带来的提升就越大。反过来如果基础没打好GEPA 只会把问题放大得更明显。 AI Agent自我进化引擎GEPA：提示层进化机制与工程实践
1. 为什么“自我进化”是 AI Agent 落地的分水岭过去一年我经手过不少 AI Agent 项目从简单的客服问答到复杂的多步骤任务编排踩过的坑基本能写一本小册子。但真正让我意识到“Agent 和普通 LLM 调用是两码事”的是第一次遇到同一个任务反复失败、Agent 却毫无长进的场景。你给它一个复杂指令它跑一遍错了再跑一遍还是错第三遍依然在同一个地方翻车——这跟一个实习生连续三天犯同一个错误没什么区别。Hermes Agent 里的 GEPA 自我进化引擎解决的正是这个问题。GEPA 是Generalized Evolutionary Prompt Adaptation的缩写直译过来就是“广义进化式提示自适应”。说人话就是让 Agent 在运行过程中根据自己执行任务的成功与失败自动调整内部的提示策略、工具调用顺序和推理路径而不是每次都从同一个起点重新开始。这个能力为什么关键因为绝大多数 AI Agent 的“智能”其实是一次性的——模型权重固定提示词固定工具列表固定。你部署上线那一刻是什么水平后面基本就是什么水平除非你手动去改提示词、换模型、加工具。但真实业务场景是动态的用户需求在变数据格式在变外部 API 在变一个不会自我迭代的 Agent 很快就会从“能用”退化到“不能用”。GEPA 的核心价值在于把“调优”这件事从人工离线操作变成了Agent 自身的在线能力。它不需要你重新训练模型也不需要你手动写几十版提示词做 A/B 测试而是让 Agent 在每一次任务执行后自动评估结果、提取失败模式、生成改进策略并在后续任务中验证这些策略是否有效。有效就保留无效就淘汰——本质上是一套运行在提示词和工具调用层面的“自然选择”机制。适合谁来深入了解这块内容三类人最应该关注一是正在做 AI Agent 应用开发、被“效果不稳定”折磨的工程师二是负责企业级 Agent 平台架构、需要考虑长期可维护性的技术负责人三是对 Agent 自我改进机制好奇、想从 0 到 1 搭建练手项目的开发者。哪怕你目前只用过 DeepSeek 这类模型的 API 做简单问答理解 GEPA 的思路对你设计更复杂的 Agent 系统也会有直接帮助。2. GEPA 引擎的整体设计与核心思路拆解2.1 从 DSPy 到 GEPA一条清晰的演进脉络要理解 GEPA 的设计得先知道它站在谁的肩膀上。DSPy 是斯坦福 NLP 组推出的一个框架核心思想是把 LLM 的提示词从“手写字符串”变成“可编程的模块”然后通过编译器自动优化这些模块的参数和提示。DSPy 解决的是“离线优化”问题——你在开发阶段准备好训练数据跑一遍编译得到一个优化后的提示词集合然后部署上线。但 DSPy 有个明显的局限它的优化是静态的、离线的。上线之后如果任务分布发生变化优化过的提示词可能就不再适用了而 DSPy 本身没有在线自适应能力。GEPA 在 Hermes Agent 里的定位就是在 DSPy 的模块化基础上加了一层运行时进化机制。具体来说GEPA 把 Agent 的每一次任务执行看作一次“个体表现”把 Agent 内部的提示策略、工具选择偏好、推理链长度等看作“基因”。任务成功后表现好的“基因组合”会被保留并扩散到后续任务中任务失败后GEPA 会分析失败原因尝试对“基因”进行变异——比如换一种提示模板、调整工具调用顺序、增加或减少推理步骤——然后在后续任务中测试变异效果。这个思路跟生物进化非常像变异、选择、保留。区别在于 GEPA 的进化发生在提示词和调用策略层面而不是模型权重层面所以它不需要 GPU 训练完全可以在 CPU 上跑响应速度也快得多。2.2 为什么选择“提示层进化”而不是“模型微调”这里有一个关键的设计取舍需要解释清楚。让 Agent 自我迭代理论上至少有三种路径一是微调模型权重二是训练一个奖励模型做强化学习三是在提示词和工具调用层面做进化。GEPA 选了第三条路原因很实际。微调模型权重的成本太高。一次完整的微调需要准备标注数据、租用 GPU、跑几个小时甚至几天而且微调后的模型很难回滚——如果新版本在某些任务上变差了你没法只回退那部分能力。对于需要快速迭代的 Agent 场景来说这个周期完全不可接受。强化学习路径的问题在于样本效率。训练一个稳定的奖励模型需要大量交互数据而且奖励信号的设计本身就很困难——什么算“好”的 Agent 行为是任务完成率高还是步骤少还是用户满意度高这些目标之间经常冲突设计不当会导致 Agent 学会“刷分”而不是真正解决问题。提示层进化的优势在于低成本、可解释、可回滚。GEPA 的每一次“变异”本质上就是生成一个新的提示模板或调整一组工具调用参数这些都以结构化数据的形式存储在 Agent 的配置里。如果某个变异导致效果变差直接删掉那条配置就行不影响其他能力。而且因为所有变化都在提示词层面你可以直接看到 Agent 为什么做了某个选择调试起来比黑盒模型容易得多。注意提示层进化并不意味着模型本身不重要。GEPA 的效果高度依赖底层模型的指令遵循能力和推理能力。如果底层模型连基本的多步推理都做不好GEPA 的进化空间会非常有限。所以选一个靠谱的基座模型仍然是前提。2.3 GEPA 在 Hermes Agent 架构中的位置Hermes Agent 的整体架构可以粗略分为四层最底层是模型接入层负责对接各种 LLM API往上是工具层管理 Agent 可以调用的外部工具再往上是 GEPA 进化层负责策略的生成、评估和选择最上面是任务编排层负责接收用户请求、拆解任务、调度工具和模型。GEPA 进化层不直接跟用户交互也不直接调用工具它更像是一个“幕后教练”。每次任务执行完毕后任务编排层会把执行轨迹——包括每一步的输入输出、工具调用结果、最终任务状态——传给 GEPA 层。GEPA 层分析这些轨迹判断哪些策略有效、哪些无效然后生成新的策略候选存入策略库。下一次任务执行时任务编排层会从策略库里选取当前最优的策略组合来指导 Agent 的行为。这个设计的巧妙之处在于解耦。任务编排层不需要知道策略是怎么来的GEPA 层也不需要关心具体任务是什么。两者通过策略库这个接口交互各自可以独立演进。你甚至可以替换掉 GEPA 层换成别的进化机制只要接口不变上层任务编排不受影响。3. 核心细节解析与实操要点3.1 策略表示GEPA 的“基因”长什么样GEPA 的进化对象是“策略”那策略具体是什么在 Hermes Agent 的实现里一个策略单元包含以下几个字段提示模板用于指导模型完成特定子任务的提示词模板支持变量插值。工具偏好在多个可用工具功能重叠时优先选择哪个工具的权重。推理深度控制模型在给出最终答案前进行多少步内部推理。重试策略当某个步骤失败时是重试、换工具还是跳过。上下文裁剪规则当对话历史过长时保留哪些部分、丢弃哪些部分。这些字段组合在一起就形成了一个策略的“基因型”。GEPA 的进化操作就是对这些字段进行变异和组合。比如一个策略在“数据查询”子任务上表现不好GEPA 可能会尝试把提示模板从“请查询以下数据”改成“请先确认数据表结构再执行查询”同时把推理深度从 2 调到 3看看效果是否改善。这里有个实操要点策略的粒度不能太粗也不能太细。如果策略太粗比如一个策略管所有任务那变异空间太大GEPA 很难找到有效方向如果策略太细比如每个 API 调用都单独一个策略那策略数量会爆炸管理成本极高。Hermes Agent 的常见做法是按“子任务类型”来划分策略粒度比如“信息检索”“数据转换”“结果汇总”各有一套策略这样既保证了针对性又不至于太碎。3.2 评估信号怎么判断一个策略是好是坏GEPA 的进化依赖评估信号也就是“适应度函数”。没有好的评估信号进化就会变成随机游走。Hermes Agent 里常用的评估信号有三类第一类是任务完成度这是最直接的信号。任务成功完成得 1 分部分完成得 0.5 分完全失败得 0 分。但光看完成度不够因为有些任务虽然完成了但步骤冗余、耗时过长。第二类是效率指标包括总步骤数、总 token 消耗、总耗时。同样的任务用 3 步完成和用 10 步完成质量是不一样的。GEPA 会把效率指标作为惩罚项纳入适应度计算。第三类是中间步骤质量这个比较难量化但在复杂任务里很重要。比如一个多步推理任务最终答案对了但中间某一步的推理是错的只是碰巧结论对了。这种“侥幸成功”如果被当成好策略保留下来后续任务很容易翻车。Hermes Agent 的做法是对关键中间步骤做抽样检查用另一个模型实例或者规则引擎来判断中间结果是否合理。提示评估信号的设计直接决定 GEPA 的进化方向。如果你只奖励任务完成度Agent 可能会学会“不管三七二十一先把任务标记为完成”如果你只奖励效率Agent 可能会学会“跳过必要步骤”。多信号加权是必须的权重需要根据业务场景调整。3.3 变异操作GEPA 怎么生成新策略GEPA 的变异操作主要有四种我按使用频率从高到低排列第一种是提示模板改写。这是最常用也最安全的变异方式。GEPA 会把当前策略的提示模板和失败案例一起发给一个“变异模型”让变异模型生成几个改进版本。比如原模板是“请总结以下文本”失败原因是总结太笼统变异模型可能会生成“请提取以下文本中的三个关键论点每个论点用一句话概括”。这种变异成本低、可解释性强是 GEPA 的主力操作。第二种是工具偏好调整。当 Agent 在多个工具之间选择时GEPA 会调整工具选择的权重。比如发现某个任务用工具 A 的成功率明显高于工具 B就会提高 A 的权重。这个操作需要积累一定数量的执行样本才能生效冷启动阶段效果不明显。第三种是推理深度调整。有些任务失败是因为模型推理太浅有些则是因为推理太深导致“想太多”反而出错。GEPA 会根据失败模式动态调整推理深度参数。这个操作的风险在于推理深度和任务类型强相关一个策略上的调整不一定能泛化到其他任务。第四种是策略组合。当两个策略分别在各自任务上表现良好时GEPA 会尝试把它们组合成一个新策略看看组合后的效果是否超过单独使用。这个操作的搜索空间最大但也最容易产生意外结果通常只在策略库比较丰富时才启用。3.4 策略选择怎么决定用哪个策略策略库里有了一堆候选策略下一个问题是每次任务执行时用哪个Hermes Agent 用的是多臂老虎机的思路具体来说是 Thompson Sampling 的一个变体。简单解释一下每个策略都有一个“成功率分布”初始时所有策略的分布都很宽表示不确定。每次任务执行前GEPA 从每个策略的分布中采样一个值选采样值最高的策略来执行。任务完成后根据结果更新该策略的分布——成功则分布向高成功率方向移动失败则向低成功率方向移动。随着执行次数增加好策略的分布会越来越窄且集中在高成功率区域被选中的概率自然越来越大。这个机制的好处是自动平衡探索和利用。初期所有策略都有机会被尝试避免过早锁定在局部最优后期好策略逐渐胜出保证整体效率。实操中需要注意的是策略库不能无限增长需要定期淘汰长期表现差的策略否则采样开销会越来越大。4. 实操过程与核心环节实现4.1 环境准备与 Hermes Agent 安装要点在动手之前先把环境理清楚。Hermes Agent 的部署方式比较灵活可以单机跑也可以多容器部署。如果你只是想体验 GEPA 的进化效果单机模式足够了。多容器部署适合需要隔离工具环境或者做压力测试的场景。安装过程中最容易卡住的地方是依赖下载。常见报错包括failed to download repository和请求的名称有效这类网络相关的问题。这类问题的根源通常是包管理器的源配置或者 DNS 解析。我的处理顺序是先确认基础网络连通性再检查包管理器源是否可达最后看 DNS 配置。如果是企业内网环境可能需要配置内部镜像源。另一个常见坑是 Python 版本兼容性。Hermes Agent 对 Python 版本有要求太老的版本会导致部分依赖装不上太新的版本又可能有兼容性问题。我实测下来3.10 到 3.11 之间的版本最稳。建议用虚拟环境隔离避免污染系统 Python。安装完成后先跑一个最小验证让 Agent 执行一个简单的两步任务比如“查询当前时间然后计算距离今天结束还有多少小时”。这个任务足够简单能快速验证模型接入、工具调用、任务编排三条链路是否通畅。如果这个都跑不通先别急着上 GEPA把基础链路调通再说。4.2 配置 GEPA 进化引擎的关键参数GEPA 的配置主要集中在进化策略和评估信号两块。下面这张表是我在实际项目中总结的常用参数和推荐值参数名作用推荐值说明evolution_interval每多少次任务执行后触发一次进化10-20太小会导致策略频繁变动太大则进化太慢mutation_rate每次进化生成新策略的比例0.2-0.3太高会引入太多噪声太低则探索不足selection_temperature策略选择的随机性0.5-1.0值越大越倾向于探索新策略max_strategy_pool策略库最大容量50-100超过后淘汰最差策略min_samples_per_strategy策略被评估前的最少执行次数5避免因样本太少而误判策略好坏fitness_weights完成度/效率/中间质量的权重0.6/0.2/0.2根据业务场景调整这些参数没有绝对的最优值需要根据你的任务类型和执行频率来调。比如任务执行频率很高每分钟几十次evolution_interval可以设小一点让进化更快如果任务执行频率低每天几次设太大可能几天才进化一次设太小又样本不足。4.3 一个完整的 GEPA 进化循环实操记录下面我用一个实际项目里的场景来演示 GEPA 的完整进化循环。任务场景是“从用户邮件中提取关键信息并生成回复草稿”涉及信息抽取、意图判断、回复生成三个子任务。第一轮执行Agent 用初始策略执行了 20 个任务成功率 65%。失败案例集中在“意图判断”子任务上很多邮件同时包含多个意图Agent 只识别了其中一个。第一次进化触发GEPA 分析了失败案例发现“意图判断”的提示模板过于简单只要求“判断邮件意图”没有要求列出所有可能的意图。变异模型生成了三个新模板其中一个要求“列出邮件中所有可能的意图并按置信度排序”。第二轮执行新策略被选中执行了 15 个任务意图判断的准确率从 65% 提升到 82%。但出现了新问题回复生成步骤的耗时增加了因为 Agent 在生成回复前会先列出所有意图导致上下文变长。第二次进化触发GEPA 检测到效率指标下降对“回复生成”子任务的上下文裁剪规则做了变异增加了“只保留置信度最高的两个意图”的规则。第三轮执行整体成功率提升到 88%平均耗时回到正常水平。这个策略组合被保留下来成为后续任务的默认策略。这个循环里最关键的是评估信号的准确性。如果第一轮只看了成功率没有分析失败模式GEPA 就不知道该往哪个方向变异。如果第二轮只看成功率提升忽略了耗时增加最终策略会变得又慢又重。多信号评估是 GEPA 有效运转的前提。4.4 策略库的持久化与管理GEPA 进化出来的策略需要持久化存储否则重启一次就全丢了。Hermes Agent 默认把策略库存成 JSON 文件每个策略一条记录包含策略内容、历史表现、创建时间、最后使用时间等字段。策略库的管理有几个实操要点。第一定期备份。策略库是 Agent 的核心资产丢了就得重新进化成本很高。第二版本控制。每次进化产生的策略变更都应该记录方便回溯和回滚。第三冷热分离。长期不用的策略可以归档到冷存储减少主库的查询开销。还有一个容易被忽略的点策略库的跨环境迁移。如果你在开发环境进化出了一套好策略想迁移到生产环境直接复制 JSON 文件通常不够因为策略里可能引用了开发环境特有的工具配置或模型参数。迁移前需要做一次配置映射把环境相关的字段替换掉。5. 常见问题与排查技巧实录5.1 GEPA 进化效果不明显怎么办这是被问得最多的问题。GEPA 跑了一段时间策略也进化了但整体效果提升很小。排查思路按以下顺序来先看评估信号是否区分度不够。如果所有策略的适应度得分都差不多GEPA 就没有选择压力进化会变成随机漂移。解决办法是细化评估指标比如把“任务完成度”拆成“信息抽取准确率”“意图判断准确率”“回复可用率”三个独立指标让不同策略在不同维度上拉开差距。再看变异操作是否有效。如果变异生成的策略跟原策略差别很小进化就只是在原地打转。可以检查变异模型的提示词确保它被要求生成“有实质性差异”的候选策略。另外变异模型的选型也很重要用一个能力太弱的模型做变异生成的策略质量会很差。最后看策略选择机制是否合理。如果 Thompson Sampling 的参数设置不当比如selection_temperature太低Agent 会过早锁定在某个策略上不再探索新策略。适当提高探索温度给新策略更多机会。5.2 策略库膨胀导致性能下降策略库不是越大越好。当策略数量超过一定规模后每次任务执行前的策略采样开销会显著增加而且策略之间的干扰也会变多。我遇到过策略库涨到 200 多条后单次任务耗时增加了 40% 的情况。处理办法是定期淘汰。淘汰规则可以综合策略的近期表现、使用频率和创建时间。比如“最近 50 次执行中成功率低于 40% 且超过 7 天未被使用”的策略直接删除。淘汰时注意保留那些虽然近期表现一般但曾经表现优秀的策略因为它们可能只是暂时不适应新的任务分布。另一个办法是策略聚类。把功能相似的策略归为一组组内只保留表现最好的几个减少冗余。这个操作可以在策略库达到一定规模后定期执行。5.3 进化后的策略在新任务上表现不稳定这种情况通常是因为过拟合。GEPA 在旧任务上进化出的策略可能过度适应了旧任务的特征换到新任务上就不行了。这跟机器学习里的过拟合是一个道理。缓解办法有几个。一是保留一定比例的随机策略不让 Agent 完全依赖进化出来的策略保持对新任务的适应能力。二是在评估信号里加入多样性惩罚如果一个策略只在特定类型的任务上表现好在其他任务上表现差适应度会被拉低。三是定期用新任务数据重新评估策略库把不适应新数据的策略降权或淘汰。5.4 常见问题速查表问题现象可能原因排查方向解决建议进化后效果无提升评估信号区分度不足检查各策略适应度分布细化评估指标增加维度策略库增长过快淘汰机制缺失查看策略创建和淘汰记录设置容量上限和淘汰规则新任务表现差策略过拟合旧任务对比新旧任务的特征分布保留随机策略加多样性惩罚进化循环卡住变异操作无效检查变异模型输出质量换更强的变异模型调整变异提示任务耗时增加策略过于复杂分析策略的步骤数和 token 消耗在适应度中加入效率惩罚策略选择震荡探索温度过高观察策略选择的历史分布降低 selection_temperature5.5 几个我踩过的坑和对应技巧第一个坑是过早优化。项目刚开始跑任务样本还不到 50 个就急着开 GEPA 进化。结果进化出来的策略严重过拟合那几十个样本换一批任务就崩了。后来我给自己定了个规矩至少积累 200 个以上的任务执行样本再启动 GEPA。样本太少的时候先把基础提示词调好别指望进化引擎能变魔术。第二个坑是评估信号里混入了噪声。有段时间我发现 GEPA 进化出来的策略时好时坏排查了很久才发现是任务完成度的判定逻辑有问题——有些任务实际上失败了但因为异常处理没做好被标记成了成功。评估信号被污染后GEPA 的进化方向完全跑偏。评估逻辑的可靠性比进化算法本身更重要这是血的教训。第三个技巧是给变异操作加约束。早期我让变异模型自由发挥结果生成了一堆天马行空的策略大部分根本跑不通。后来我在变异提示里加了硬约束新策略必须兼容现有的工具接口提示模板的变量数量不能超过原模板的两倍推理深度调整幅度不超过正负 2。加了约束之后变异策略的可用率从不到 30% 提升到了 70% 以上。第四个技巧是人工审核关键策略。GEPA 是全自动的但全自动不代表可以完全放手。对于影响面大的策略变更比如涉及核心业务逻辑的提示模板改写我会让 GEPA 先在小流量上验证确认效果后再全量。这个“人工在环”的机制虽然增加了一点操作成本但避免了好几次潜在的生产事故。6. 从 GEPA 延伸出去的几个思考GEPA 这套机制跑通之后我陆续在几个不同场景里做了迁移实验有一些额外的发现值得分享。第一个发现是GEPA 对工具设计的反馈价值。当 GEPA 反复在某个工具上进化失败时往往说明这个工具本身的设计有问题——可能是接口太复杂可能是返回结果格式不统一也可能是功能重叠导致 Agent 难以选择。这时候与其继续调策略不如回头改工具。我在一个项目里就是通过 GEPA 的失败模式分析发现某个数据查询工具的参数设计过于繁琐简化之后 Agent 的成功率直接提升了 20 个百分点。第二个发现是GEPA 和人工提示词工程不是替代关系。有人觉得有了 GEPA 就不需要手写提示词了这个想法不对。GEPA 的进化是在现有提示词基础上的微调如果初始提示词质量太差进化空间会很有限。我的做法是先用人工把提示词写到 70 分水平再让 GEPA 去攻剩下的 30 分。人工负责框架和方向GEPA 负责细节和自适应。第三个发现是GEPA 的进化结果可以反哺模型选型。通过观察 GEPA 在不同基座模型上的进化效率和最终效果可以判断哪个模型更适合当前任务。有些模型指令遵循能力强但推理能力弱GEPA 在需要多步推理的任务上进化会很吃力有些模型推理强但输出格式不稳定GEPA 在需要结构化输出的任务上会频繁变异。这些观察结果比单纯的 benchmark 分数更有参考价值。第四个发现是GEPA 的长期运行需要关注策略的“代际退化”。进化不是单调向好的有时候会出现“后代不如祖先”的情况。原因可能是变异累积了太多微小改动导致策略偏离了最初的有效方向。我的处理办法是定期做一次“回交”——把当前最优策略和早期的一个高表现策略做组合引入一些“古老基因”防止策略在局部最优附近过度特化。这些经验不一定适用于所有场景但如果你正在搭建自己的 AI Agent 系统并且打算引入自我进化机制希望这些踩坑记录能帮你少走一些弯路。GEPA 不是银弹它更像是一个放大器——你的基础架构越扎实、评估信号越准确、工具设计越合理GEPA 能带来的提升就越大。反过来如果基础没打好GEPA 只会把问题放大得更明显。