拆解 GEPA 如何用轨迹反馈、Pareto 前沿和模块合并，让 Prompt 优化更稳、更可审计。
原文链接：AI 小老六

Agent 系统里的 Prompt 很少是一次写对的。更常见的情况是，线上 case 出错以后，人去翻日志、看工具调用、读模型输出，再手工改一版 Prompt 或 Skill，跑评测，分数涨了就先收下。

这个流程能跑，但很累，也不稳定。最麻烦的不是“改不动”，而是改了 A 以后 B 退化。比如分类更准了，回复变得生硬；检索召回上去了，推理链路开始乱跳。只拿一个总分做判断，很容易把某些长尾能力一起丢掉。

GEPA 解决的正是这类问题。它不是再造一个更复杂的手工调参流程，而是把“看轨迹、找错因、改 Prompt、保留互补版本”这套人工经验，放进一条可以自动运行的进化流水线里。

本文按工程视角拆 GEPA：它到底优化什么，为什么比只看分数的 Prompt 搜索更稳，以及在业务系统里落地时哪些地方最容易被低估。

图：轨迹反馈驱动 Prompt 候选不断进化

Prompt 优化的真实瓶颈：反馈太薄

很多 Prompt 优化方案最后都会卡在同一个地方：评测器只给一个分数。

61 分涨到 74 分，看起来是进步。但这 13 分来自哪里？哪些样本变好了，哪些样本变差了？如果一版 Prompt 更会抓并发 bug，却把一堆低风险 diff 写成高危告警，要不要保留？

人类调 Prompt 时其实不会只看分数。我们会看错例，会读执行轨迹，会从失败样本里总结规则。GEPA 的起点就是这个判断：LLM 已经能读代码、读日志、读用户反馈，那它也可以读自己的​运行轨迹​，并把错误原因写回 Prompt。

GEPA 的学习介质不是梯度，而是自然语言。

优化方式	反馈形式	学到的东西	常见问题
人工手调	人读 case 后总结	经验规则	成本高，难复制
标量搜索	单个分数	哪个版本分高	不知道为什么好
强化学习	reward / rollout	参数或策略偏好	调试成本高，样本消耗大
GEPA	轨迹 + 自然语言反馈	可读、可审计的 Prompt 规则	依赖评测器质量

这也是 GEPA 和很多 Prompt optimizer 的分界线。它不是让模型凭空“想一个更好的提示词”，而是要求模型先读完整轨迹，再根据具体失败原因改写。

Reflective Mutation：把一次失败变成可复用规则

GEPA 的变异算子叫 Reflective Prompt Mutation。听起来像遗传算法术语，落到工程实现里，其实是四步：

1. 在训练集里抽一个 minibatch，用当前候选 Prompt 跑完整链路。
2. 保存轨迹，包括模块输入输出、推理过程、工具调用、工具返回和最终答案。
3. 评测器给出分数，也给出文字反馈，例如“定位到了风险但缺少触发路径”“评论给了结论，却没有最小修复建议”。
4. 反思模型读取“旧 Prompt + 轨迹 + 反馈”，只改当前选中的模块 Prompt。
   

图：一次失败如何被反思模型改写成新候选 Prompt

这里有个实用细节：反思模型通常可以比目标模型更强。它不直接接管线上任务，而是把诊断能力“写进”目标模型可执行的 Prompt。这样做的成本比训练小得多，产物也更容易审计。

如果目标系统有多个模块，GEPA 不会每次把整套 Prompt 一起改掉。它会选择一个模块做局部变异，比如只改分类 Prompt，回复 Prompt 保持不动。这个限制很重要。一次只动一个变量，后面才知道收益和回归来自哪里。

Pareto 前沿：不要急着扔掉“偏科生”

最容易误解 GEPA 的地方，是它不总是保留总分最高的那一版。

在复合任务里，总分最高的候选未必支配所有样本。它可能在大多数样本上赢，但在少数关键样本上输得很明显。传统贪心策略会把旧版本删掉，后续就失去了从旧分支继续演化的机会。

图：Pareto 前沿保留互补候选，而不是只追最高均分

GEPA 用 Pareto 前沿维护候选池。判断标准很简单：只要某个候选在至少一条验证样本上是当前最好，它就有留下来的理由。

图：按验证样本优势维护候选池，并继续采样演化

这带来一个很实际的收益：优化器不会被平均分骗走。一个候选只擅长 5% 的长尾样本，也可能是后面合并出强版本的材料。

候选保留策略	会发生什么	风险
只留总分最高	主干很干净	容易丢掉长尾能力
保留所有历史版本	信息完整	候选池膨胀，搜索变慢
Pareto 前沿	留下互补版本	需要稳定验证集

我更愿意把 Pareto 前沿理解成“能力档案柜”。它不是收集所有旧版本，而是保留那些还有独特价值的版本。

System-Aware Merge：把分支上的好东西拼回来

有了多条分支以后，GEPA 还能做一件链式优化很难做的事：合并。

假设一个 Agent 有两个模块：

模块	职责
L	在代码 diff 里定位风险点，例如并发、空指针、权限绕过、资源泄露
C	把风险点写成评审评论，要求有触发条件、影响范围和修复建议

第一轮反思可能让 L 更会抓并发问题，但 C 写出的评论变得太像报警器，误伤了可读性。第二轮从旧版本出发，可能把 C 的语气和证据链调好了，但 L 仍然漏掉边界条件。GEPA 会在候选谱系里识别这种“同源、互补、互不支配”的关系，然后做模块级合并。

图：同源候选在模块边界清楚时可以横向合并

这不是简单复制粘贴。Merge 需要满足几个约束：

约束	含义
共同祖先	只合并同一任务谱系下的候选，避免把无关改动硬拼
模块边界清楚	候选必须能拆成模块级 Prompt 或规则
验证无回归	合并后要重新跑验证集，不能只看局部收益

这一步解释了 GEPA 为什么更适合多模块系统。单个 Prompt 当然也能优化，但在 Agent、RAG、工具链、workflow 这类系统里，模块之间经常“此消彼长”，Merge 的收益会更明显。

图：多模块 Agent 的分支经验在系统边界内合并

一个代码评审 Agent 例子：高分版本也可能偏科

换一个更贴近工程团队的例子。假设我们在做一个代码评审 Agent，它先从 diff 里找风险点，再生成行级评论。样本来自历史 MR，里面有人工标注的真实缺陷、误报和可接受评论。为了防止调参把测试集“看熟”，数据切成三份：

数据集	数量	用途
轨迹集	90	每轮抽 12 个 MR，让反思模型看到具体失败过程
裁判集	45	所有候选都完整评测，用来决定谁能留在前沿
封存集	30	优化期间完全不用，最后看真实泛化

初始版本 S0 只是能跑通链路：

{
  "L": "阅读 diff，找出可能的 bug",
  "C": "把发现的问题写成 code review 评论"
}

S0 在裁判集上的综合分是 61%。第一轮抽到的 12 个 MR 里，漏报集中在两类：一个是 goroutine 写共享 map 没加锁，另一个是鉴权判断被提前 return 绕过。反思模型这次只改 L 模块，补上“并发写”和“权限短路”两组检查规则，得到 S1。

候选	高风险缺陷召回	评论可采纳率	综合
S0: L0 + C0	61%	67%	61%
S1: L1 + C0	88%	54%	74%

S1 的总分更高，但它有个很烦的问题：抓得更猛以后，评论里混进了不少“可能有问题”的泛化提醒，人工评审会觉得吵。S0 虽然漏缺陷，但在低风险 MR 上更克制。两者互不支配，都先留下。

第二轮父代采样时，S0 被抽中。新 minibatch 暴露的是评论生成模块的弱项：评论只说“这里可能有空指针”，但没解释触发路径，也不给修法。反思模型这次不动 L，只改 C，得到 S2。

候选	缺陷召回	评论可采纳率	综合
S0: L0 + C0	61%	67%	61%
S1: L1 + C0	88%	54%	74%
S2: L0 + C1	70%	91%	82%

S2 基本覆盖了 S0 的优势，S0 可以退出。但 S1 还不能删，因为它在高风险缺陷召回上明显更强。此时 Merge 有了意义：把 S1 的定位规则和 S2 的评论写法拼起来。

{
  "L": "定位 v1: 显式检查并发写、权限短路、nil 分支和资源释放路径",
  "C": "评论 v1: 先给触发条件，再说明影响，最后给最小修改建议"
}

候选	高风险缺陷召回	评论可采纳率	综合
S1: L1 + C0	88%	54%	74%
S2: L0 + C1	70%	91%	82%
S3: L1 + C1	87%	89%	88%

后面再跑几轮，最终版本在封存集上拿到 86% 的综合分。初始 S0 是 59%。更重要的是，人工复核里“评论可直接粘到 MR”的比例从 41% 提到 76%。

这个例子里最值得记住的不是 86%，而是 S1 那一刻没有被平均分策略清掉。它当时的评论质量很差，但缺陷召回这条能力后来被 S3 吃到了。如果只保留 S2，系统会变得很会写评论，却继续漏掉真正危险的 diff。

GEPA 主循环：搜索的是可解释程序，不是玄学 Prompt

把上面的动作连起来，GEPA 的主循环大致如下：

图：从候选采样、轨迹反馈到前沿更新和最终验证

停止条件通常有三类：

停止条件	说明
预算耗尽	目标模型调用次数达到 max_metric_calls
前沿饱和	连续 K 轮没有新候选进入 Pareto 前沿，K 常用 patience 控制
满分达成	验证集指标达到目标上限

这套循环看起来像搜索，实际产物更接近一组可解释的文本程序。每次改动都有轨迹、有反馈、有验证分数，也能追溯是哪个模块发生了变化。

和 GRPO、MIPROv2 比，GEPA 赢在哪里

在 HotpotQA、IFBench、HoVer、PUPA 等任务上做了实验。关键信息可以压成一张表：

对比项	GEPA	GRPO / RL	MIPROv2
平均效果	相比基线约 +10 分	作为主要对照基线	通常低于 GEPA 10%+
样本消耗	通过文字反馈减少无效 rollout	rollout 最多可到 GEPA 的 35 倍	与传统 Prompt 搜索接近
AIME-2025	相比 MIPROv2 约 +12%	未作为同表核心项	基线
结果形态	自然语言 Prompt，可读可审计	策略或参数更新更重	Prompt 搜索结果

GEPA 的优势不只是分数。它的工程吸引力在这几个点：

维度	GEPA 的处理方式	对工程团队的价值
样本效率	从单条轨迹里提炼文字规则	少跑很多无意义试验
可解释性	知识沉淀在 Prompt 里	能审计，也能手工修
泛化方式	学的是规则，不只是分布偏好	对长尾样本更友好
部署成本	不需要权重训练	主要消耗 API 调用和评测预算
系统适配	支持多模块、谱系和 Merge	更适合 Agent / RAG / 工具链

GEPA 还可以作为推理时搜索策略用在代码优化等任务上。也就是说，即使没有训练阶段，只要系统能执行、能反馈、能比较，反思和 Pareto 前沿也能用来搜索更好的候选解。

从链式迭代到候选树：优化形态变了

传统 Prompt 调优大多是一条线：

图：传统 Prompt 调优通常只有一个当前版本

这条线的问题是，时间上只能有一个“当前版本”。一旦 V1 被 V2 覆盖，V1 的优势除非人工记下来，否则就没了。

GEPA 更像一棵可以横向焊接的候选树：

图：GEPA 将线性迭代扩展成可回访、可合并的候选树

这个结构带来几个链式迭代没有的能力：

能力	具体含义
回访分岔点	旧候选只要还有独占优势，就能继续作为父代
横向合并	两个分支分别学到的模块经验可以组合
并行探索	多个候选分支可以独立评测和反思

这也是我觉得 GEPA 对 Agent 工程有启发的地方。它把“版本”从一个线性编号，变成了带谱系的候选族群。

落地边界：不是所有任务都适合 GEPA

GEPA 不是万能的。它需要任务能被执行、能被观察、能被评价。尤其是评测器，如果只能吐出 0/1 分数，GEPA 的效果会打折。

适合使用	不太适合
Agent、RAG、工具链这类多模块系统	只有二值奖励、没有文字反馈的任务
评测器能解释为什么错	验证集太小或噪声太大
需要白盒、可审计的优化结果	目标模型上下文极短，装不下反思规则
没有 GPU 训练资源，只能调 API	反思模型预算很低
贵模型、长链路，对 rollout 成本敏感	需要权重级知识注入或风格内化

真要在业务里用，接入 GEPA 只是第一步。后面通常还有四层工作：

层级	要做的事	代码评审场景例子
L1 反馈函数	把错因写成自然语言，而不是只给分	“指出了并发风险，但没有说明哪个共享对象会被两个 goroutine 同时写”
L2 参数配置	调整 auto、use_merge、num_threads、track_stats 等开关	根据验证曲线决定是否开启 Merge 和并行评测
L3 自定义 Adapter	把业务链路里的工具调用、延迟、复诉率接进轨迹	GEPA 同时看到 diff 片段、静态扫描结果、人工采纳状态
L4 Instruction Proposer	约束反思模型如何产出 Prompt	限制长度，过滤合规风险，多模型投票后再写入

这一层层做下去，边际收益会递减，但工程可控性会变强。尤其是 L1，最容易被低估。评测器写得粗，GEPA 只是在粗反馈上自动绕圈。

我对 GEPA 的判断

GEPA 让“调 Prompt”这件事的重心往上游挪了一截。以前人的主要时间花在改提示词，现在更应该花在评测器、轨迹可观测性和反馈粒度上。

这也解释了 Claude Code 作者 Boris 那句 “I don't prompt Claude anymore. I write loops.” 真正重要的不是某条神奇 Prompt，而是让 Prompt 自己变好的循环。循环能走多远，取决于评判信号有多细。

GEPA 的边界也比 PE 更宽。只要一个对象能文本化、能执行、能打分，它就有机会被反思式进化。Prompt 可以，工具描述可以，Skill 可以，workflow、路由规则、harness 里的约束也可以。

所以我不太把 GEPA 看成“自动写 Prompt 的工具”。它更像一个系统优化框架：把运行轨迹变成反馈，把反馈变成文本规则，把文本规则放回系统，再用 Pareto 前沿保留那些一时看起来偏科、但可能在未来合并出更强版本的候选。

对 Agent 工程来说，这个方向比单纯追求更会写 Prompt 的人更有想象力。真正稀缺的能力，可能会变成如何设计评测、如何暴露轨迹、如何让系统的每次失败都能留下可复用的经验。

推荐阅读

Agent Workflow Runtime 架构拆解：把 Agent Loop 从提示词搬进代码，长任务才真正稳了

Google AX 控制面拆解：分布式 Agent 如何把断点恢复、审计策略和执行调度收进同一条链路

AI Native 竞争力：真正稀缺的不是会用 AI，而是把事往前推的人

Harness Engineering：Agent 真正能交付，靠的不是更强模型，而是上下文、执行协议和验收闸门

Agent 工具链工程化： Skill 负责编排判断，CLI 稳定交付的执行边界