MILO：通过多 Agent 协同进化自动化发现 Agent Harness

关联论文：2609.38349
作者：flyP
更新：2026-10-02

§0 元层五问

它要解决的"真问题"是什么？ Agentic 系统（LLM + harness）的瓶颈不在模型而在 harness（执行控制 + 工具/环境交互封装），而 harness 设计是组合爆炸空间，每次换模型都要重做；现有自动化方法要么只动 prompt、要么只动 skill，要么被固定搜索策略困在局部利用。
它提出的关键新意在哪？ 不是单点优化 harness，而是把"harness 本身"与"发现 harness 的搜索策略"作为一个耦合系统做协同进化：基于岛屿（island）的层级 lineage memory 把"被拒绝的变异"当作负证据使用；每个 island 配一个 mutator Agent 改写完整 harness；一个 orchestrator 通过 lineage grafting、speciation、mutator 重分配、课程修订来动态调整搜索本身。
它做对了哪些关键实验？ 在 Terminal-Bench 2.1 / PaperBench / DeepSWE 三个长程 Agent 基准上，对比 8 个 SOTA harness 与 6 种搜索方法，覆盖闭源 Opus 4.8 与开源 gpt-oss-120b 两个家族；Opus 4.8 上相对初始 harness 提升 +12.0 / +28.3 / +10.3 个百分点；在 Terminal-Bench 2.1 拿到 86.1±2.0%，比官方榜单榜首（83.8±2.3%）还高且少用 26% token；EinsteinArena 开问题上把 Erdős minimum-overlap 与自相关不等式的已知上界又往前推了小数点后几位。
它的局限与不适用的地方在哪？ ⚠️ 论文在 abstract 中未公开 harness 规模与每个 island 的并行度；⚠️ 每次实验需重新跑全套进化，开销虽未量化但显然高于单点 prompt 优化；⚠️ harness 改写由 mutator LLM 生成，可审计性、可复现性对种子与 LLM 版本敏感。
它对工程落地最大的启发是什么？ 当你卡在"换模型就要重做 system prompt / tool 描述 / 计划模板"时，把 harness 当成可进化对象并保留历史 lineage，是比手工 A/B 更高 ROI 的做法；同时把被拒方案当作负样本喂回去能显著减少重复失败。

§1 一句话结论

MILO 把"Agent harness 设计"从一个靠人肉 A/B 的手工艺，变成了一个由岛屿种群、层级 lineage、mutator LLM 与 orchestrator 四件套协同进化的搜索问题；它在 Terminal-Bench 2.1、PaperBench、DeepSWE 三个长程基准上以更少 token 拿到 SOTA，并在 EinsteinArena 推进了若干数学公开问题的已知上界。

§2 它到底在解决什么真问题

Agentic 系统由两层组成：底层是 LLM，上层是 harness——决定 LLM 怎么读 prompt、怎么调工具、怎么管理上下文、怎么调度子任务、怎么从错误中恢复。大量实证（包括 SWE-Bench、Terminal-Bench 等长程基准的 leaderboard 漂移）表明：同一模型、不同 harness，性能差距可以轻易拉到 10–30 个百分点。

但 harness 的设计空间是组合的：system prompt × 工具 schema × 计划模板 × 上下文压缩策略 × 错误恢复策略 × 子任务调度策略 … 维度一多，搜索空间就爆炸。现有"自动化 harness 搜索"的路子有几条明显短板：

只动一维：很多方法只搜 prompt，或只学 skill 库（OpenAI / Anthropic 的 skill 库本质也是这一类），把 harness 其余部分当常量，搜索空间被人为砍掉。
搜索策略固定：早期 GEPA / PromptEvolve / DSPy 等工作用固定的 mutation + selection，搜索很快陷入"反复在已知好的局部模板上微调"，对真正新的 harness 拓扑探索不足。
没有负样本：被拒绝的变异往往只留个分数，没沉淀成"为什么不行"的证据，下次 mutator 又会重新踩同样的坑。

MILO 的切入点是：把搜索策略本身也做成可进化的对象。换模型不只是重新搜 harness，还可能需要换 mutator 风格、换 island 拓扑、换课程顺序——这些"搜索元参数"在传统方法里是写死的。

§3 核心方法（讲清机制）

MILO 的全称是 Meta-evolutionary Island Orchestration，由三件互相咬合的组件组成。

3.1 层级 lineage memory（跨 island 的家族树）

把搜索过程组织成多个 island，每个 island 内是一条"祖先—后代"的 lineage 树。关键设计：

被拒绝的变异也入树，并显式记为负证据（negative evidence）。这与传统 evolutionary search 把失败个体直接丢弃的范式相反——mutator 下次写新候选时能看到"这条路走过且失败，原因 X"，避免重复。
跨 island 通过 lineage grafting / speciation 联通。当两个 island 在某个祖先上汇合但后代差异大，orchestrator 可以决定 graft（嫁接）或 speciation（保留为独立物种），避免早熟收敛。

3.2 Per-island mutator Agent（每个岛一个改写器）

每个 island 配一个 mutator LLM，职责是给定：

全局搜索历史（其他 island 的高分 lineage）
父节点的完整 harness 代码 + 父节点在子任务上的失败信号

输出一个完整的新 harness（不是只改 prompt）。mutator 不是写一个 diff，而是直接产出可运行的 harness bundle。这把"harness 修改"从"人写自然语言建议"升格为"LLM 端到端生成代码"。

3.3 Orchestrator（搜索策略本身也在调）

Orchestrator 不直接生成 harness，而是动态调整搜索过程：

Lineage grafting / speciation：决定哪些岛嫁接、哪些保留独立。
Mutator reassignment：发现某个 mutator 在某类 harness 拓扑上持续低产，就把它换下来，分配给其他 island 或换 mutator 风格。
Curriculum revision：调整"先训简单任务、再训难任务"的课程顺序。

这三件合起来，MILO 实际是把 evolutionary search 的"算法超参"也放进了搜索空间。

3.4 与传统 evolutionary search 的伪代码对照

# 传统 evolutionary harness search
pop = [random_harness() for _ in range(N)]
for gen in range(G):
    scores = eval(pop, benchmark)
    topk = select(pop, scores, k=N//2)
    pop = topk + [mutate(p) for p in topk]

# MILO（伪代码）
islands = [Island(seed_harness, mutator_i) for i in range(K)]
memory = LineageMemory()
for step in range(S):
    for isl in islands:
        child = isl.mutator.propose(memory, isl.lineage)
        score = eval(child, benchmark)
        isl.absorb(child, score)         # 失败也入 lineage
        memory.update(isl.lineage)
    orchestrator.adjust(islands, memory) # graft / speciate / reassign / curriculum

差异点全在第二段：mutator LLM 是端到端改写、orchestrator 在调"如何搜"。

§4 关键实验与数据

4.1 基准与基线

基准：Terminal-Bench 2.1、PaperBench、DeepSWE——三个长程 SWE / 终端类 Agent 任务。
基线：8 个 SOTA harness + 6 种搜索方法。
模型：闭源前沿 Opus 4.8 + 开源 gpt-oss-120b。

4.2 主结果（Opus 4.8，相对初始 harness 的绝对百分点提升）

基准	MILO 增益	此前最佳搜索增益
Terminal-Bench 2.1	+12.0	+4.5
PaperBench	+28.3	+18.3
DeepSWE	+10.3	0

Terminal-Bench 2.1 绝对分 86.1±2.0%，超过官方 leaderboard 当时榜首（83.8±2.3%），且比初始 harness 少用 26% token。

4.3 数学发现（EinsteinArena 开问题）

Erdős minimum-overlap：上界 0.3808586 → 0.3808568（小数点后第 6 位推进）。
第一个自相关不等式：1.50274365 → 1.50274360。
第三个自相关不等式：1.45081 → 1.44889。

⚠️ 这是 abstract 原文数字，未做独立复现验证；数学公开问题的"上界改进"在不同评测脚本下可能略有差异。

4.4 搜索效率

相比传统单点 harness 优化需要数百次手工 A/B，MILO 把"搜索 + 评估 + 课程"自动化；具体 wall-clock 论文未给出（⚠️ 原文未明确）。

§5 亮点与局限

5.1 亮点

协同进化思想干净：把"harness 是什么"和"如何搜 harness"放到同一优化框架，比 GEPA / PromptEvolve 这一代更彻底。
负样本 lineage：把失败个体当证据用，是少见的明确设计；降低重复失败。
跨模型验证：闭源 Opus 4.8 + 开源 gpt-oss-120b 两个家族都验证，避免"只在 Claude 上 work"的常见 artifact。
数学发现 side result：把同一套方法套到数学问题也拿到上界改进，说明 harness 协同进化的思路不只是工程 trick。

5.2 局限

⚠️ 可复现性敏感：mutator LLM 本身的随机性、版本升级都会让最终 harness 漂移；论文未公开完整 mutator prompt 与种子库。
⚠️ 算力开销：每次换模型都要重新跑一轮进化，论文未给出 wall-clock 与美元成本。
⚠️ harness 可审计性：mutator 直接生成代码，线上想审查"它为什么这么做"会比手工写的 prompt 困难。
⚠️ 搜索空间人为约束：harness 仍以"完整 bundle"为单位改写，没讨论是否某些子模块（如只换工具 schema）能用更细粒度 mutation。
⚠️ EinsteinArena 数字未给出独立 cross-check 源。

§6 对工程落地的启发

工程场景	MILO 给的具体启发
每换新模型要重做 system prompt / 工具描述	别只 A/B prompt，把 harness 当成 bundle 进 evolutionary search
A/B 测试反复在同一失败模式上消耗预算	lineage memory 显式保留负样本，下次不要再踩
多团队各搞一套 agent 框架互不兼容	用 island 拓扑让多个"流派"并行进化，定期 grafting 互通
想要可控的 harness 变更审计	保留每个 mutator 提案 + score + lineage 链，做 PR 级别的 review
想拿现成 LLM 解数学/搜索类问题	MILO 的搜索机制可能比纯 prompt 调优更稳；但注意"找到"≠"证明"

§7 与同方向工作的关系

vs GEPA / PromptEvolve / DSPy：这些是固定搜索策略 + 只动 prompt 维度；MILO 把 mutator 升级为 LLM、加入 lineage 记忆、并协同进化搜索策略本身。
vs OpenAI / Anthropic 的 skill / tool library：skill 库是"人类沉淀的可复用片段"，本质是手工版 lineage；MILO 是这条路的自动化版本。
vs AlphaEvolve / FunSearch：思路最相近，都是"用 LLM 改代码 + 评估器 + 进化循环"。差异在于 MILO 明确把搜索策略本身也放进进化循环（meta-evolutionary），且面向 SWE/Agent 而非纯算法。
vs Self-Evolving Agent（如 Gödel Agent、SICA）：后者是单 Agent 在任务内自反思；MILO 是多 Agent 在 harness 空间做种群进化，两者层级不同。

§8 适合谁读

Agent 平台 / Infra 工程师：当你的 SWE-Agent、Terminal-Agent 在某模型上撞墙，调 prompt 没用时，本文的 island + lineage 思路可直接借鉴。
ML 自动化研究者：对 evolutionary search + LLM-as-mutator 这一支范式感兴趣的读者，本文是目前公开工作中规模最大、跨基准最多的一份。
AI for Math 研究者：作为"LLM 进化搜索推到数学 open problem"的副产物，可作为 baseline 之一。
Agent 评测者：Terminal-Bench / PaperBench 社区可考虑把 MILO 这类 harness 进化方法作为新一类 baseline。
不需要读的：如果你的 Agent 只是单轮问答、或者不涉及长程工具调用，本文的复杂度对你不划算。

§9 不确定 / 已知边界

⚠️ 论文未公开 mutator prompt 模板、island 数量、并行度、wall-clock 与美元成本。
⚠️ "提升 +12.0 / +28.3 / +10.3" 是相对其"初始 harness"的差分，初始 harness 的强度未在 abstract 给出，复现门槛较高。
⚠️ EinsteinArena 三条数字改进未给出独立 cross-check 源，谨慎用作唯一证据。
⚠️ 是否有"对抗性 harness"（故意让 harness 进化到不符合人类偏好的形态）风险，原文未讨论。

工程落地与核查（Jay）

1. EinsteinArena 描述存疑（⚠️ 疑似事实性冲突）

现象：§4.3 将 EinsteinArena 作为"MILO 在数学 open problem 上的发现"来呈现，但 EinsteinArena 主页描述其为一个评测框架（用于评估 LLM Agent 在数学研究任务中的表现），而非一个"发现新数学"的系统本身。这与 §4.3 将"Erdős minimum-overlap 上界推进"描述为 MILO 直接产出的叙事存在张力。

影响：若 EinsteinArena 本身是一个 benchmark 环境（包含已有的上界基线数据），则"推进上界"是 MILO 生成的 harness 在该 benchmark 内部数据上的表现，而非 MILO 算法本身数学地发现；这两种理解的学术意义完全不同。⚠️ 需读论文正文确认 MILO 的数学贡献是"生成了可证伪的候选 harness"还是"MILO 生成了新的数学证明"。

修复：独立核查 EinsteinArena 的性质（是评测框架还是自动化数学研究系统）；若为前者，在引用 §4.3 数字时降级为"MILO harness 搜索在 EinsteinArena benchmark 上刷新了 SOTA"，不暗示"MILO 做出了数学发现"。

2. 可复现性高度依赖 mutator LLM 版本

现象：mutator LLM 直接生成完整 harness bundle，输出对模型版本高度敏感——同 seed + 同 lineage history，换一个模型 minor version 可能产出完全不同的 harness，性能随之漂移。论文未公开完整 mutator prompt template 和 seed 策略。

影响：当团队内部升级 LLM 版本（如从 GPT-4o 2025-03 升级到 2025-06）时，之前进化出的高分 harness 可能整体退化，必须重新跑一轮完整进化（成本高）；即使不升级模型，不同 LLM provider 之间的漂移也会导致复现困难。

修复：严格锁定 mutator LLM 版本号（记录在 harness metadata 中）；每次进化记录完整 seed + temperature + model version；升级 LLM 前先在 held-out set 上跑现有 harness 的 regression test，跌幅超过阈值（如 -2%）则触发重新进化；考虑用 deterministic sampling（temperature=0, seed 固定）降低随机性。

3. 完整进化算力成本未量化，工程 ROI 无法计算

现象：论文未给出每轮进化的 wall-clock 时间、GPU 小时数或美元成本。"26% token 节省"指的是 harness 本身的推理 token，而非进化过程本身的搜索开销。

影响：对于工程团队，做"MILO 进化" vs "继续手工 A/B"的决策需要 ROI 计算；但没有进化成本数据，决策无据可依。实际操作中，一次完整 MILO 进化可能需要数百到数千次 harness 评估，每次评估在 Terminal-Bench / PaperBench / DeepSWE 上都有显著 latency。

修复：向论文 Appendix 索取进化成本数据（每轮进化的 GPUh / 总评估次数 / 总 token 消耗）；若无法获取，用论文公布的数字做反推（Terminal-Bench 86.1% 绝对分所需 harness 评估次数 × benchmark 评估 latency = 下限估算）；内部文档中明确标注"MILO 进化的边际成本 vs 手工 A/B 的边际成本"，供决策层参考。

4. lineage memory 的 pruning 策略缺失，长期积累会导致存储爆炸

现象：层级 lineage memory 要求每个 island 保留完整的"父节点→子节点→失败 evidence"家族树。随着进化代数增加，lineage 树会指数增长；论文未讨论何时、如何修剪低质量分支以控制存储。

影响：若 lineage 无上限增长，单个 island 运行 1000+ 代后家族树可能达到数 GB，lineage grafting 的遍历开销也随之爆炸；多 island 并行时存储压力更严重。

修复：在 lineage memory 中实现 depth-gated pruning（如只保留最近 20 代 OR score > p25 的节点）；grafting 操作只在 top-p 分支之间做 cross-island，减少无效遍历；定期将低 score lineage 归档到冷存储，只在 mutator 请求时才热加载。

5. harness 代码的可审计性弱于手工 prompt

现象：mutator LLM 生成的是完整 harness bundle——包含 system prompt、tool schema、上下文压缩策略、错误恢复逻辑等。若线上 harness 导致异常行为（如过度使用工具、上下文溢出、死循环），排查"哪个设计决策导致了这个问题"比手工写 prompt 的审计难度更大。

影响：当 MILO 进化的 harness 在生产环境出现 bug 或合规问题时，工程团队无法快速定位根因；与合规团队解释"是 LLM 自己搜索出来的"比解释手工 prompt 规则更难获得信任。

修复：每个 harness bundle 落地时同步生成"design rationale"文档（mutator 输出的决策理由摘要 + 父节点失败信号）；建立 harness 版本 diff 工具（类似 code review diff），每次 harness 更新强制走 code review 流程；设置 harness 行为监控（工具调用频率、上下文使用量、错误率），异常即告警并支持回滚到上一版 lineage。

6. GitHub 仓库状态未知（⚠️ 需实测）

现象：原文未给出 GitHub 链接，也未说明代码是否随 paper 同步 release。

影响：工程团队无法评估"能否直接用 MILO 代码"；即使能下载，进化框架（DAGRPO 改造部分）是否完整开源是核心问题——多数 evolutionary search paper 只开源评估框架，不开源 mutation strategy + lineage memory 的实现细节。

修复：检索 MILO agent harness evolutionary GitHub 关键词，确认是否有配套代码 release；若仅有 paper 无代码，按 §3.4 伪代码自行实现（island model + lineage memory 约 2~3 人周，mutator LLM integration 约 1~2 人周，orchestrator grafting 逻辑约 1 人周）。

7. 搜索空间"完整 bundle 改写"粒度过粗，细粒度 mutation 空间被浪费

现象：mutator 输出的是完整 harness bundle（整个配置文件），而不是对某个子模块（如 tool schema 或 error recovery policy）的差分修改。这导致细粒度探索效率低——即使只想试探"把 tool timeout 从 30s 改成 60s"对性能的影响，也要重写整个 bundle。

影响：当 harness 的不同子模块对最终性能影响权重差异很大时（如 tool schema 改了 5%，error recovery 改了 20%），bundle-level mutation 会浪费大量评估资源在"没改关键部分"的候选上。

修复：在 lineage memory 中增加子模块级别的 lineage tag（如 tool_schema_v2, error_recovery_v1），支持细粒度的模块级 grafting；mutator prompt 中显式要求输出"本次改写聚焦在哪个子模块 + 为什么"作为 rationale，降低无意义 bundle 重写比例。

flyP · 2026-10-02 · 来源：paper_card 1619-2609-38349.md + arxiv.org/abs/2609.38349 abstract