GEPA 的 optimize_anything 看起来像一个可以优化 prompt、代码、Agent 架构、Skill 和配置的通用工具。更重要的变化发生在接口层：评估器负责定义什么是好结果，工件和搜索引擎都可以替换。只要评估器准确表达真实目标，这种分层就能释放杠杆；评估器存在盲区时，自动搜索会把盲区变成优化目标。
本文拆解 evaluator contract、Actionable Side Information、三种搜索模式、公开基准和生产验证方法。核心判断很简单：优化器负责找候选，评估器决定系统会朝哪个方向进化。
先区分 API 和搜索引擎
GEPA 是 Genetic-Pareto 的缩写，指一种反思式优化方法。optimize_anything 是接收工件、评估器、目标、数据集和预算的前端。2026 年 7 月 22 日的更新进一步把前端改成可插拔、可组合结构，可以切换 GEPA、AutoResearch、Meta-Harness 或组合流水线。
系统可以拆成四层：
- 工件负责变化，包括 prompt、程序、配置、策略、Skill 或 Agent 定义。
- 评估器负责证据，包括分数、诊断、硬约束、成本和失败信息。
- 搜索引擎负责探索，包括选择、变异、合并和保留候选。
- 测试闸门负责发布，判断最终候选是否脱离搜索环境后仍然成立。
评估器之所以像编程接口，是因为它应在工件表示和搜索引擎变化后继续表达同一个任务。如果更换引擎时成功定义也跟着变化，任务语义已经和优化器耦合。
最小 evaluator contract
官方 API 把评估器压缩成一个函数。它接收 candidate，在数据集模式下还接收 example，然后返回一个分数，或返回分数加 Side Information。当前文档常把后者称为 Actionable Side Information，简称 ASI。
def evaluate(candidate: str, example: dict):
result = run_in_sandbox(candidate, example)
score = compute_score(result)
return score, {
"correct": result.correct,
"runtime_ms": result.runtime_ms,
"cost_usd": result.cost_usd,
"stderr": result.stderr,
}
分数决定候选是否改进，诊断信息解释为什么。编译错误、断言失败、性能 trace、逐样例结果、渲染图片和结构化子目标都可以进入反馈。
把 ASI 类比成文本优化的梯度，有助于理解它为什么比单一分数高效。它并不是数学意义上的梯度，方向是否可靠完全取决于评估器。
反思式搜索如何运行
GEPA 引擎大致执行以下循环：
- 在全部样例和目标上评估初始工件。
- 记录在特定样例或指标上表现最好的候选。
- 选择一个 parent 和一小批样例。
- 把工件、分数与诊断 trace 交给 proposer。
- 让模型反思失败原因并提出定向变异。
- 对有希望的变异做完整评估，更新候选池。
- 预算耗尽后，返回验证结果最好的候选。
官方将选择机制称为 Pareto-aware。更准确地说，它按样例或 objective 记录 best-in-class，并根据候选在多少 key 上领先来提高其采样机会。这能保留不同专长的候选，但不等于维护教科书意义上的完整非支配解集合。一个各方面都排第二、却从未在任何指标领先的候选，可能落在默认 frontier 之外。
因此，这套机制保留的是互补优势证据，而不是穷尽所有多目标方案。
三种模式解决三类问题
API 根据 dataset 和 valset 决定搜索模式。
单任务搜索
系统只解决一个困难问题，candidate 本身就是答案或求解器。圆堆积和黑盒优化属于这一类。评估器直接对每个工件打分。
它适合环境固定、泛化要求较低的一次性问题。
多任务搜索
数据集包含一组相关问题，不同任务之间共享知识。CUDA kernel 适合这种模式，因为不同算子共享语言、编译器、硬件和优化技巧。
任务相关性是前提。论文把彼此独立的圆堆积尺寸放进多任务搜索后，结果反而下降：单任务得分为 2.6360，更宽的多任务版本降到 2.6313 和 2.5973。
多任务并行本身不创造迁移，依赖结构相似才会创造。
泛化模式
训练样例驱动搜索，独立 valset 选择一个准备应用到未见输入的全局工件。prompt、策略和通用 Agent 优化通常属于这一类。
验证集被反复用于选择，也可能被过拟合。需要额外保留搜索引擎看不到的封存测试集，只在优化完成后运行。当前 API 已提供结构上隔离的 test_set 路径。
公开基准实际证明了什么
optimize_anything 论文报告了多个领域的结果：
- Gemini Flash 的 ARC-AGI Agent 从 32.5% 提升到 89.5%。
- 云路由算法在作者模拟器中相对 Dijkstra 降低 40.2% 成本。
- 在 NVIDIA V100 和 31 个 KernelBench 算子上，87% 的生成 kernel 持平或超过 PyTorch，48% 达到至少 1.1 倍。
- GPT-4.1-mini 的 system prompt 在 AIME 2025 上从 46.67% 提升到 60.00%。
- Coding Agent Skill 在特定任务集上把 Claude Haiku 4.5 从 79.3% 提升到 98.3%，完成时间下降 47%。
这些数字来自作者实验，依赖具体模型、任务、硬件、评估器和预算。它们证明同一个反思式接口可以跨多种文本化优化问题工作，无法直接外推成生产系统的普遍增益。
成本也构成实际边界。论文配置从约 1 美元到 144.70 美元不等，评估执行往往占主要成本。Proposer 能力也会影响结果，较强模型在 AIME 和圆堆积实验中明显优于小模型。
评估器既是规格，也是攻击面
优化器无法恢复评估器从未测量的要求，只能找到在现有 contract 下得分高的候选。
假设一个 Agent 评估器只奖励任务完成和低延迟，却遗漏了以下条件：
- 是否调用了未授权工具；
- 是否泄露隐藏指令；
- 遇到分布变化后是否继续工作；
- 是否消耗了十倍 token；
- 是否依赖脆弱捷径通过测试。
只要这些遗漏能提高可见分数，搜索压力就会偏向它们。ASI 通过详细反馈提高了优化效率，也可能帮助 proposer 更快摸清代理指标的形状。
论文没有声称解决 reward hacking。相对可信的案例都把重要约束写进评估器。圆堆积会校验几何合法性，代码任务会编译、检查正确性、设置 timeout，并在 Sandbox 中执行。这些控制属于任务定义，并不是通用优化器自动提供的保障。
生产评估器需要四层 contract
第一层：准入条件
无效 candidate 应在质量评分前被拒绝：
- schema 与语法；
- 允许的 import、工具和网络目的地；
- 时间、内存和资源限制；
- Secret 与数据边界；
- 不可违反的安全约束。
违反硬约束的候选不应获得一个仍可竞争的低分，而应直接退出搜索空间。
第二层：任务质量
用能够区分候选的样例测量真实结果。代码任务应测正确性，而不是代码风格。Agent 任务应测完成、证据、恢复和副作用，而不是只让 judge 给出整体印象。
单一平均分容易掩盖灾难维度。关键目标应保留结构化子分数。
第三层：运行成本与方差
记录延迟、token、金钱、内存、重试和失败频率。对非确定性评估重复运行。平均分高但尾部风险大的候选，可能弱于略低但稳定的方案。
缓存只适用于确定性结果，或把环境、模型版本和配置等全部影响因素纳入缓存键。
第四层：泛化与发布
训练、验证和封存测试应相互分离。加入分布变化与对抗样例，对最终候选使用多个随机种子重复运行，然后在受限 canary 中与基线比较真实指标。
搜索引擎永远不应看到最终发布闸门。
一条安全的自动优化流水线
可以把优化过程放进以下边界：
- 冻结 baseline、数据集、评估器版本、模型版本和预算。
- 优化前先让 seed 通过所有硬约束。
- 在限制网络、文件系统、时间和成本的 Sandbox 中搜索。
- 返回能解释失败、又不泄露封存答案的结构化 ASI。
- 记录逐目标结果，不只保留聚合分数。
- 用验证集选择，只在结束后运行封存测试。
- 对最终比较执行多随机种子和分布变化测试。
- 审查 baseline 与优化工件之间的 diff。
- 通过可回滚 canary 上线，并监测真实结果。
这样，optimize_anything 成为可信系统中的候选生成组件。引擎负责搜索，发布流程负责判断证据是否充分。
这种分工类似数学 Agent 的双环验证协议：一个环负责探索，另一个独立边界负责判断候选是否合规、证据是否足以发布。
哪些任务不适合自动文本优化
当真实目标无法测量、变化速度高于评估周期，或后果无法用安全离线测试表达时，这种模式不合适。评估候选会暴露生产数据、运行不受控代码或制造不可逆副作用时，也应先重新设计边界。
有些目标必须保留人的判断。人工评审可以进入 evaluator，但小样本 panel 和 LLM judge 都会引入方差与偏差。论文的视觉示例使用 5 名人工评审做 sanity check，这属于有价值的小样本证据，不能当成大规模稳定结论。
通用文本优化有一条明确边界：工件能够表示成文本或可由文本控制的结构，质量能够在可接受成本内测量。边界之外的目标仍然需要其他方法。
常见问题
GEPA 只能优化 prompt 吗？
不能这样理解。GEPA 可以优化 prompt、代码、配置、Agent 架构和其他文本工件，前提是评估器能够安全执行或检查每个候选。
evaluator 应返回什么？
最低要求是一个越高越好的分数。更实用的评估器还应返回正确性、错误、运行时间、成本、逐样例结果或渲染输出等结构化诊断。
ASI 是什么？
ASI 是反思阶段提供给 proposer 的诊断反馈，通常比只有分数的变异更节省样本。它不是数学梯度，诊断偏离真实目标时也会把搜索带偏。
如何防止过拟合？
分离训练、验证和封存测试，限制反复暴露，增加对抗与分布变化样例，重复评估，并让最终发布闸门对优化器不可见。
GEPA 能防止 reward hacking 吗？
不能。硬约束应独立于分数执行，candidate 应在 Sandbox 中运行，发布测试需要隐藏，优化后的工件还要审查是否利用了捷径。
优化成本是多少？
成本取决于 proposer 模型、候选数量、评估执行、数据规模和重试。论文报告的任务配置约为 1 至 144.70 美元，这属于实验成本，不能直接视为生产 TCO。
参考资料
- optimize_anything 论文
- 官方 optimize_anything 发布说明
- 官方 omni 与可插拔引擎更新
- GEPA GitHub 仓库
- 官方 Evaluator API
- 官方候选选择说明
- 论文复现实验仓库
评估器是把意图转成可执行证据的地方。把它设计成版本化、可对抗测试的接口，搜索引擎就只是可替换的候选来源。保留模糊目标时，更强的优化器只会更快证明目标有多模糊。