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%