企业官网建设流程全解析

AntOmniEvo 是一个自动进化框架，让 AI 代理 7×24 小时持续优化你的系统。它的候选池管理核心是micro-pareto 策略：用 Pareto 前沿支配关系淘汰被全面压制的候选，再用 top-N 截断控制种群规模，配合多维领先的加权采样选出最强候选做下一步进化。本文带你完整拆解这套"选谁进化、淘汰谁"的机制。

为什么纯 Pareto 前沿不够用 🤔

AntOmniEvo 的每个候选（candidate）在验证集上会留下一个多维分数列表score_list——每个维度对应一道题/一个 data_id 的得分。理论上，用经典 Pareto 支配（A 在每个维度都 ≥ B 则 A 支配 B）剪掉弱者是标准做法。

但官方设计文档 system-design.zh-CN.md 里点破了关键矛盾：

务实的 micro-pareto —— 承认概率评分下纯 Pareto 失效，top-N 兜底 + 多维领先加权保护多面手。

LLM 评估带有噪声，单维分数可能有 ±噪声级别的波动，两个"旗鼓相当"的候选可能互相不构成支配，纯 Pareto 会让种群越滚越大、无法收敛。所以 AntOmniEvo 在 Pareto 之上叠加了两层工程化补丁：选择端的多维领先加权和淘汰端的 top-N 截断。

整套实现集中在一个文件：pareto_frontier.py，不到 180 行，逻辑非常清爽。

选择策略：多维领先加权采样，谁是多面手谁上场

每次开新迭代槽位，调度器会调用select(num)从候选池挑出"父本"。规则在 select 方法 里：

1. 只看pending状态的候选——evolving的正在忙，unavailable的要么待验证要么已退役；
2. 计算每个候选的max_score_count：它在多少个维度上拿到了全种群的最高分（见 _get_max_score_count_dict）；
3. 以该计数为权重做加权随机采样（不放回）——0 权重候选永远不会被选中；
4. 没有任何候选有分数时，退化为均匀随机采样，保证冷启动也能推进。

直观理解：不追求单科状元，而是保护多面手。一个在 30% 题目上都拿到满分的候选，比只在个别题目领先的候选更有机会被选中继续进化。这个行为有专门的单测守护，见 test_pareto_selection.py——它验证了零权重候选绝不会被抽样到。

下面这张图展示了多维分数对比的实际效果：Insights 覆盖网格把每组候选在每道题上的得分排成矩阵，你可以直观看到"每个维度都有领先"的候选长什么样。

淘汰第一阶段：Pareto 弱支配剪枝

每个 slot 结束后都会调用一次eliminate()（而不是只在接受子代时才裁），实现见 eliminate 方法。Phase 1 做的事很纯粹：

• pending和evolving都参与支配比较，但只有pending会被真正 retire。这样正在进化的弱候选可以先跑完，下个 slot 再淘汰；而max_candidate_num上限也不会挡住强候选的入场；
• 排序技巧：候选先按(generation, created_at)降序排列，进化代数深的排前面。配合 Phase 1 里>=的判定，两个全维度打平时，更深代数的候选存活；
• 支配判定见 _is_dominated：A 每维+ 1e-8后 ≥ B 才算支配。这里有个防御细节——分数列表为空或长度不一致时直接返回False，否则"跳过验证"模式下空列表会让每个候选都"支配"其他所有候选，整个池子坍缩成只剩一个幸存者。

被支配的候选会打上dominated by {cid}的退役原因，写入日志可追溯。

淘汰第二阶段：top-N 截断兜底 🏆

Phase 1 之后，如果存活的前沿（frontier）数量超过max_candidate_num（默认 10），进入 Phase 2：

frontier.sort( key=lambda c: (summaries[c].avg_score, metas[c].generation, metas[c].created_at), reverse=True, )

按(平均分, 代数, 创建时间)降序排序，只保留前 N 个，其余打上top-N cutoff (avg_score=...)原因退役。这一步就是官方文档说的"top-N 兜底"：即使没有任何候选被 Pareto 支配，种群规模也有硬上限，分数越高、进化越深、越新的候选优先留下。

被选中的父本每次都会记录日志：selected={cid} (avg_score=..., max_score_dims=...)，配合每次eliminate的dominated by/top-N cutoff日志，你可以完整复盘"谁上场了、谁被刷了、为什么"。

真实进化运行中的效果：种群始终精瘦

这套 micro-pareto 策略在一个真实 AppWorld 进化运行中的表现，可以在 Stats 标签页 看到：623 次迭代、总共创建 34 个候选、拒绝了 590 个子代，而存活种群规模始终只有 3 个。

这正是策略设计目标的直接体现：进化不是无限扩张种群，而是让候选池保持"精瘦"——留下的每一个都是当前最强梯队，被淘汰的要么是全面被压制（Pareto 支配），要么是平均分不够进前 N（top-N 截断）。

从 Lineage Tree 能更清楚地看到这条血统链：每个节点标注平均分、相对 root 的提升和等级徽章，被 micro-pareto 留下的候选层层向上爬升，最终跑出比 baseline 高出 +35pp 的最优解。

动手看看：用可视化器验证 micro-pareto 效果 🧪

想亲眼确认这些行为，可以用项目自带的可视化器（独立子包，位于 visualizer/）：

uv pip install -e ".[visualizer]" cd visualizer && npm install antomnievo-visualizer-manage start --workspace /path/to/workspace/<run>

启动后在浏览器里：

• Evolution 标签页：看候选在 Lobster Gym 里的实时状态（pending / evolving）；
• Stats 标签页：看Population Size是否被稳定压在max_candidate_num以内；
• Insights 标签页：用覆盖网格核对"多维领先"到底领先在哪几道题。

另外，store.retire()写入的退役原因都在日志里，配合 iteration_records.jsonl 的逐 slot 记录，能精确还原每次eliminate的裁决过程。

小结：三个机制，一条清晰的取舍线 💡

micro-pareto 的精妙之处在于务实：它不假装分数是精确的，而是承认 LLM 评估的噪声，用"支配关系 + 规模上限 + 多维加权"三重保险，保证候选池始终留得住当前最强梯队。如果你想在自己的系统上复现这套策略，参考 docs/extensibility.zh-CN.md 即可按接口契约接入 EvolutionAlgorithm 抽象。