拆解 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。听起来像遗传算法术语落到工程实现里其实是四步在训练集里抽一个 minibatch用当前候选 Prompt 跑完整链路。保存轨迹包括模块输入输出、推理过程、工具调用、工具返回和最终答案。评测器给出分数也给出文字反馈例如“定位到了风险但缺少触发路径”“评论给了结论却没有最小修复建议”。反思模型读取“旧 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 C061%67%61%S1: L1 C088%54%74%S1 的总分更高但它有个很烦的问题抓得更猛以后评论里混进了不少“可能有问题”的泛化提醒人工评审会觉得吵。S0 虽然漏缺陷但在低风险 MR 上更克制。两者互不支配都先留下。第二轮父代采样时S0 被抽中。新 minibatch 暴露的是评论生成模块的弱项评论只说“这里可能有空指针”但没解释触发路径也不给修法。反思模型这次不动 L只改 C得到 S2。候选缺陷召回评论可采纳率综合S0: L0 C061%67%61%S1: L1 C088%54%74%S2: L0 C170%91%82%S2 基本覆盖了 S0 的优势S0 可以退出。但 S1 还不能删因为它在高风险缺陷召回上明显更强。此时 Merge 有了意义把 S1 的定位规则和 S2 的评论写法拼起来。{L:定位 v1: 显式检查并发写、权限短路、nil 分支和资源释放路径,C:评论 v1: 先给触发条件再说明影响最后给最小修改建议}候选高风险缺陷召回评论可采纳率综合S1: L1 C088%54%74%S2: L0 C170%91%82%S3: L1 C187%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 等任务上做了实验。关键信息可以压成一张表对比项GEPAGRPO / RLMIPROv2平均效果相比基线约 10 分作为主要对照基线通常低于 GEPA 10%样本消耗通过文字反馈减少无效 rolloutrollout 最多可到 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 工程有启发的地方。它把“版本”从一个线性编号变成了带谱系的候选族群。落地边界不是所有任务都适合 GEPAGEPA 不是万能的。它需要任务能被执行、能被观察、能被评价。尤其是评测器如果只能吐出 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 EngineeringAgent 真正能交付靠的不是更强模型而是上下文、执行协议和验收闸门Agent 工具链工程化 Skill 负责编排判断CLI 稳定交付的执行边界