效果上不去？蚂蚁把「调AI」这件事，也交给了AI

每个做 AI 系统的人都经历过这个阶段：效果上不去，又不知道往哪使劲——读轨迹、改 prompt、调配置，靠人一轮轮试，一试就是好几天。

能不能让「优化 AI 系统」这件事本身，也交给 AI？

为此，蚂蚁灵矽大模型应用平台团队开源 AntOmniEvo，一个自动优化 AI 系统的框架。

• AntOmniEvo 框架代码：https://github.com/ant-research/AntOmniEvo
• 核心算法 Mara Chain 论文：https://arxiv.org/abs/2609.35855

你只需要提供四样东西——系统里「可修改部分」（prompt、规则、脚本、配置，组织成一目录真实文件，是待优化系统的映射，就是下图左边的 artifact）、评估数据、打分标准、系统定义（系统怎么跑）；剩下的全部由框架驱动 AI 自动完成——改 prompt、改规则、改配置、改脚本，在「改文件 → 打分」的循环里 7×24 不停，直到把分数改上去。

这张图就是价值的全貌：左边你出四样东西，中间它 7×24 自己跑，右边交付可直接部署的最优 artifact 和每处改动的病历。核心价值一句话：把「调系统」这件最依赖老师傅经验的活，变成一件定义好目标、就能自动跑完的事——你是甲方，它是 7×24 干活的算法工程师。

四条核心价值：

• 省力：设好预算、启动，然后就不用管了。你下班它加班，你要做的只是最后收货。
• 交付物直接能上线：优化的产物就是一目录真实文件（prompt、规则文档、脚本、配置），系统运行时 load 的就是它们——改文件 = 改系统行为，替换回去 = 上线。每处改动可 diff、可 review、可回滚。
• 过程全白盒：每个候选版本、每次运行轨迹、每条评分都完整落盘，还自带一个「龙虾健身房」可视化器（下文有图）——谁进步、谁退步、哪一版修好了哪道难题，全程可围观。
• 一个框架通吃：Agent 的 skill、agent harness、检索管线的配置和节点脚本，三种形态，同一套优化循环，我们的目标是 optimize anything。

它怎么做到的

分两层说：系统怎么组织，算法怎么改进。

系统层：tunable artifacts——优化 = 改文件。系统里「可以改的部分」（prompt、规则、脚本、配置）映射成一个真实的文件目录，这就是 tunable artifacts；系统运行时 load 的就是这些文件，所以改文件 = 改系统行为，优化这个系统 = 让 coding agent 在「改文件 → 跑评估 → 看分数」的循环里进化这个目录。

随目录一起给出的还有一份声明（目录树长什么样、每个文件管什么、哪些允许改）——它既是框架和 AI 的改动边界，也会 render 成 prompt、按需注入干活的 agent：

接入也按这个边界设计：框架把「通用机器」和「任务相关插件」严格分开，一共 7 个可插拔组件、分三类——目标侧：System（你的系统怎么跑）、Evaluator（输出怎么打分）、DataInst（评估数据怎么加载）；优化器侧：Optimizer（进化主循环）、Proposer（动手改文件的 coding agent）、EvolutionAlgorithm（选谁变异、淘汰谁）；持久化：CandidateStore（所有状态落盘，想上云就换它）。

接入你的系统通常只需实现 System 和 Evaluator 两个接口，其余都有默认实现，特殊场景再按需替换，换任务不用动主循环。

算法层：两个关键设计，一个管「修」、一个管「选」，配合出效率。先看一轮迭代的完整流程：

Mara Chain：失败不丢弃。常见做法是改一版、不达标就扔、下一代重新想——预算大量浪费在重复踩坑上：同一个错误被反复诊断、反复尝试，rollout 越加越多，分数却纹丝不动，我们把这堵墙叫作顽固失败壁垒（persistent failure barrier）。

AntOmniEvo 反过来，没及格的候选带着诊断记录留下来，给定一个试错的预算，一代接一代接着修，同一个坑不踩第二次。

训练 AI 系统，也许应该更有耐心，给一些试错的空间。为什么失败的候选值得留？我们的观察是，一个没及格的候选，失败通常逃不出三种情况：

1. 修好了一半：改动是有效的，只是没修完——下一代可以在部分修正的基础上接着修，不用从零开始；
2. 方向对，但实现有 bug：改的方向是对的，实现里的 bug 拖累了分数——下一代只需修掉实现，不用推翻方向；
3. 证明了「此路不通」：尝试失败了，但它替后代排除了一条路线——下一代据此换一条路走，不再重蹈覆辙。

能复用的前提是证据没丢，所以 Mara Chain 的核心在每一代的上下文构建与继承：动手改之前，AI 先拿到链上前面所有代攒下的四类资产——逐题分数历史（每一代在哪些题上拿了多少分）、历代诊断报告（之前判定哪错了、该改哪个文件、怎么改）、逐代改动记录（每处改动改了哪个文件、为什么，能和分数变化逐代对上账）、原始运行轨迹（分数只说明「有没有变化」，轨迹才说明「为什么」）。

下一代因此不是从头猜，而是站在所有失败尝试的肩膀上：在部分修正上接着修、修掉方向正确的实现 bug，或者在「此路不通」被证实后果断换路——失败的积累形成合力，直到把卡住分数的墙打破。

当然，这不是无限制地保留失败，而是给一个有限的修正窗口：新候选没超过它的起点时，沿同一条链继续精修——每一步都继承前面所有代的证据，最多修到预设的链深；精修结束后取链中最佳的一版，只有它真的超过起点，才进验证集定分，否则整条链放弃。

差一步就让它补上，连续几步都补不上就停止投入，也就是试错也是有限度的。

把 Mara Chain 的细节展开就是下图：

论文里有个直观的案例（sanitize-git-repo）：这个任务需要连续修正多个相互依赖的问题，没有任何一个候选能一步到位。

没有 Mara Chain 时，系统反复提出「修好一半」的候选——补规则、调整搜索方式、提醒不要截断结果——但因为短期没涨分，这些候选很快被丢弃，下一轮换个方向重新来，相似的诊断不断重现，任务始终过不去。

有了 Mara Chain，失败候选在同一条链上被接着修：从文字规则推进到可执行脚本，再根据脚本暴露的问题继续修补，直到任务通过。

一句话：不是「永远不要淘汰」，而是不要过早淘汰——把选择放在更充分的证据之后。

pareto-filtered top-N selection：偏科生不死。只按总分排名，会系统性地杀掉「总分平平、但某道难题全场最强」的候选——这道题的最优解随之从种群中消失，后代都没得学；框架的进化淘汰模块先按逐题 Pareto 过滤把这类候选留住，再按总分做 Top-N 截断，防止种群爆炸。

两点设计缺一不可：消融实验里，关掉任一机制，爬到同一分数分别要多花约 1.5 倍和 2.3 倍的 rollout，终态也都够不到 0.87；TerminalBench 上同样明显——关掉 Mara Chain，通过率从 71.9% 掉到 57.3%，差 14.6 个百分点，越难的任务它的增益越大。

效率是配合出来的，不是某一个机制的功劳。

工程能力：一次建设，处处复用

自动优化是重计算任务——几十小时、成百上千次 rollout，光有算法跑不起来，还得有一套工程基建托底。

这些能力与具体业务无关，在框架里只做一遍、所有接入方直接继承；框架每升级一次，已接入的场景免费获益，而不是每个业务各自重造轮子：

• 五维预算控制：迭代数、rollout 数、系统运行数、token、墙钟时间，任一撞到上限就软停止——不再开新任务、在跑的跑完，成本不会烧穿。
• 成本监控：每次系统运行、每次 AI 干活的 token 用量都逐条记账落盘，累计花了多少实时可查——「烧到哪了、还能烧多少」始终有数。
• 进度监控：每轮迭代的分数、候选增减、预算消耗都写入统计——爬到哪了、涨没涨、预算还剩多少，随时可查。
• 断点续跑：所有候选、运行、改动记录全部落盘，机器挂了重启接着跑，几十小时的长任务不怕中断。
• 多 slot 并发：多个候选同时各自走进化循环、共享候选池，缩短进化时间。
• 全程可审计：每处改动强制落 changelog——改了哪个文件、为什么、修的是哪条失败证据，诊断报告先过一道自检质量门；连动手改文件的 AI 自己的轨迹也照样落盘——被优化的系统是白盒，干活的 AI 也是白盒。
• 验证集硬隔离：验证集对干活的 AI 是禁区（运行时硬拦截，看不到任何验证集轨迹），训练集决定「改动值不值得留」、验证集决定「候选排第几」——杜绝偷看考题，分数才可信。
• 可视化界面：能看的东西很多——家谱树上谁是谁的后代、每代涨了多少分；每个候选的祖先链、每次运行的原始记录都能点开下钻；哪道题只有哪个候选能做对，覆盖网格上一目了然……整个进化过程被渲染成一间可围观的「龙虾健身房」——这正是下一节的主角。

围观它干活：龙虾健身房

有趣的是框架自带可视化器，把整个优化过程渲染成一间「龙虾健身房」（Lobster Gym）：每个候选版本是一只在练级的龙虾，分数是段位，强者进黄金大厅，弱的在地下室继续练。

一次真实运行：家谱树从根的 0.5550 一路爬到第 9 代的 0.9050，每一步谁是谁的后代、涨了多少，全在树上；统计页一页看完 623 轮迭代、34 个候选入选、590 个被淘汰、总耗时 2 天 3 小时——全程无人值守；任意候选点开，祖先链、分数、每次运行的原始记录都能下钻审计。

效果：三个基准，三种形态，全部第一

三个基准各对应一种系统形态（skill / harness / 检索管线），同一套框架、同一个循环，每一列最好成绩都在 AntOmniEvo 手里。

设置一句话交代：每个基准都配上同赛道的专门方法做基线——skill 对 GEPA / ACE / SkillOpt-Lite，harness 对 AHE / Meta-Harness；被优化系统的模型全程冻结（默认 GLM-5，跨模型见本节末尾），均为同一模型、同一评测环境下的对比。

AppWorld（skill 形态，585 个任务 = 168 Normal + 417 Challenge）：四项测试指标（TGC = 任务完成率、SGC = 场景完成率）全部第一——89.9 / 83.9 / 76.7 / 59.0，比未优化基线最高 +48.2pp（Normal SGC），比最强前作相对提升最高 +20.5%。

更本质的口径是样本效率：爬到验证集 0.8，AntOmniEvo 只用 3,280 次 rollout，约为最强前作 GEPA（9,514 次）的 1/3；墙钟时间口径下是同样的差距——11.9 小时 vs 35.8 小时。

ACE 和 SkillOpt-Lite 全程从未到达 0.8（终态分别封顶 0.770 / 0.665）。终态也更高：AntOmniEvo 最终爬到 0.870，GEPA 停在 0.805。

TerminalBench 2.1（harness 形态，89 个任务，同模型 GLM-5、同 100 小时优化预算）：AntOmniEvo 通过率 71.9%，比未优化基线（51.7%）高 20.2 个百分点。作为对比，两个专门的 harness 优化器都没有超过未优化基线：AHE 51.7%，与基线持平；Meta-Harness 49.4%。

MuSiQue（检索管线形态）：这次被优化的不是 agent，而是一条检索管线的配置、节点脚本和 prompt——现有优化器没有可直接对比的检索管线实现，基线是人工手写的默认管线。

test 集 nDCG@10 从 0.301 到 0.405（+0.104）、Recall@10 从 0.329 到 0.460（+0.131）；验证集口径下提升同样成立（+0.134 / +0.210），且测试集和调优用的验证集不相交——提升是真泛化，不是背题。

这一格的意义超出数字本身：这套方法不限于 agent 系统。

换底座模型也成立：GLM-5 / DeepSeek-V4-Pro / Qwen3.5-397B 三个模型族各自优化、各自与未优化基线配对比较，四项指标平均分别 +40.3 / +32.7 / +23.4pp——被改进的是系统本身，不绑定某个特定模型。

不过，目前的优化效果尚未覆盖所有任务。在已开展的 Text2SQL 测试中，我们尚未观察到性能提升，相关原因和改进方向仍在探索。

更多结果——消融实验、算法 mara chain 案例研究、实验协议与超参，在论文中有更详尽的展开。

最后

三句话总结 AntOmniEvo：

1. 全面：能优化的形态全——Agent 的 skill、agent harness、检索管线的配置和节点脚本，凡是系统里「能改的部分」都能映射成一目录文件、交给同一套循环优化，目标是 optimize anything；
2. 高效：三个基准、三种形态全部第一，而且更省——爬到同一分数，rollout 和耗时都约为最强前作的 1/3；
3. 易用：按约定实现指定的模块，框架里的算法（Mara Chain、Pareto 淘汰）和工程基建（预算、监控、续跑、审计、可视化）就能全部复用——你定义「什么叫好」，它 7×24 自己跑，交付一目录能直接上线的文件，每处改动可 diff、可 review、可回滚。

它值夜班，你只管收货。

如果你的 AI 系统也有「效果上不去、不知道往哪使劲」的时刻，欢迎来试——代码和论文链接在文中。欢迎关注我们的工作，也欢迎在评论区聊你的场景。

团队介绍

我们是蚂蚁集团灵矽大模型应用平台团队，内部建设并持续打磨面向复杂业务场景的 Agent 研发平台，提供从 Agent 构建、调试、评测、优化到上线运营的全链路能力，目前支撑蚂蚁多个业务线的大规模 Agent 应用落地。

AntOmniEvo 正是我们在这一过程中沉淀出的 Agent 自进化技术框架，将内部反复验证的 Agent 自主迭代进化能力抽象、剥离业务后开源，希望与外部开发者共同推进 Agent 自进化方向的探索。