自动 harness 在线上部署越跑越烂？这篇论文把"进化"和"适应"两个损失彻底拆开了

核心摘要

这篇论文盯上了一个让做 Agent 系统的人都熟悉的尴尬：你拿 A-Evolve、GEPA、Meta-Harness 这类自动 harness 框架，在固定 benchmark 上把 prompt、技能、工具调到极致，bench 分数好看得不行；可一旦丢到真实业务的开放任务流里——任务源源不断进来、类型五花八门、分布还在漂——系统就开始抽风：技能从 12 个膨胀到 34 个、prompt 从 2KB 涨到 68KB，准确率早早冲到顶后一路掉头。作者把这种现象正式定义为部署制度（deployment regime）下的开放任务流问题，并给出了一个干净的损失分解：总遗憾 = 进化损失 \(L_{\text{evo}}\) + 适应损失 \(L_{\text{adapt}}\)。前者是进化器本身的天花板（再怎么进化都摸不到），后者是"你必须在看到任务前提交 harness"这件事本身带来的——只能靠 solve-time 路由去缩小。配套提出的 Adaptive Auto-Harness (AAH) 用三件武器对应三种损失：有状态多智能体 evolver、harness 树（git 分支做路由）、人类在环钩子。在 PolyBench 上做到 80.9% 准确率（A-Evolve 才 18.4%），CTF-Dojo 涨到 50.2%，FutureX 47.3%。这篇的真正价值不在"我又涨了多少分"，而在它第一次把"线上 Agent 系统部署"这件事说清楚了——而且用一个极其干净的理论分解告诉你：哪些问题该靠"更强的进化"，哪些问题再怎么进化也没用、必须靠"延迟决策"。

arXiv: 2606.01770 | 标题: Adaptive Auto-Harness: Sustained Self-Improvement for Agentic System Deployment on Open-Ended Task Streams | v2: 2026-06-03

一个让人不舒服的现象：A-Evolve 跑着跑着自己崩了

我先讲个画面。你在 Polymarket 上跑一个预测市场的 Agent，用 A-Evolve 这种"看反馈→改 prompt→加技能→再跑"的标准自动 harness 流程，每周扫一批新市场。第一周表现挺好，第二周还行，第三周开始你发现：

  • 技能库从 12 个变成了 34 个，里头一堆早期任务上有用、现在压根用不到的逻辑分支；
  • 系统 prompt 从 2KB 滚到 68KB，agent 看到的 context 里塞满了"早期任务的特殊 case 处理"；
  • 准确率没有继续涨，反而往下掉。

图1：A-Evolve 在 Polymarket 上的 over-evolution 现象——技能从 12 涨到 34、prompt 从 2KB 涨到 68KB，但准确率早期到顶后一路下滑

图1：A-Evolve 在 Polymarket 上跑出来的"过进化"曲线。x 轴是处理过的任务数，左纵轴是 prompt 长度和技能数（两条都是单调上升），右纵轴是 cumulative win rate。技能/prompt 一直在涨，准确率却越跑越拉胯——这就是开放任务流给单 harness evolver 的当头一棒。

说实话这个现象我之前在调一个客服 Agent 的时候碰到过。你以为模型在"持续学习"，其实它是在对早期 batch 的尾部 case 过拟合——后来的新任务一来，evolver 还在拼命修补旧分布的边缘案例，prompt 越来越长、推理路径越来越绕，新任务该掉的还是掉。

这不是工程实现 bug，而是范式 bug。固定 benchmark 上"一次评测、一次进化"的范式，从一开始就没有给"任务流"留位置。

三个让单 harness 必死的部署维度

作者把"线上"和"benchmark"的差距形式化为三个维度，命名为 D1/D2/D3：

维度 名称 具体表现 单 harness evolver 为什么死
D1 无界流 (unbounded streams) 任务一直来，没有"评测结束"的时间点 evolver 拿不到稳定的"全集"做规划，只能贪心改
D2 任务异质性 (task heterogeneity) 同一个流里混着政治预测、体育、金融、加密多种任务 一个 harness 必须同时讨好所有类型，最后哪个都不擅长
D3 分布非平稳 (distribution drift) 早期是政治选举，后期是体育赛事、币圈事件 早期优化的 prompt/技能在后期过期，但 evolver 不知道该删

图2：三个部署维度的可视化——无界流让 evolver 没有终点、异质让单一 harness 顾此失彼、漂移让旧优化作废

图2：开放任务流的三个维度。这张图我建议任何在做 Agent 线上系统的人都贴墙上——它给出了一个非常干净的"为什么 benchmark 高分上不了线上"的解释。

读到这里我有个直觉判断：D1 和 D3 其实可以用更聪明的 evolver 部分缓解（比如显式做老化、做 context decay），但 D2 异质性是单 harness 范式的根本死点——它意味着"最优 harness"本身就不该是一个，而是一个集合。这也是后面 harness tree 思路的源头。

全文最值钱的一段：把损失拆成"进化损失"和"适应损失"

如果让我只挑这篇论文最值钱的一个贡献，我会选这个分解。它太干净了，干净到我觉得这应该写进所有 Agent 系统设计的入门教材。

定义一个 oracle harness \(\varphi^*(x_t)\)：在看到任务 \(x_t\) 后才提交的、最优的 harness。把你的真实 harness \(\varphi\) 跟它的 gap 做拆解：

\[ \mathbb{E}_{x_t}\big[\text{Regret}(\varphi, x_t)\big] = L_{\text{evo}}(\Phi) + L_{\text{adapt}}(\varphi) \]

其中：

  • 进化损失 \(L_{\text{evo}}(\Phi)\)：进化器类别 \(\Phi\) 的能力上限。哪怕你把进化跑到无穷次，这部分也消不掉。它代表的是"evolver 本身能做的事的边界"——比如 evolver 没法访问外部 API、没法装新工具、没法自己写底层 infra，那这些事就永远做不了。
  • 适应损失 \(L_{\text{adapt}}(\varphi)\)：源于"你必须在看到任务之前提交一个固定 harness"这件事本身。哪怕给你一个完美 evolver、让它跑无穷次，只要你要交一份"通用 harness"对所有任务，这部分损失就在。

这个拆解之所以值钱，是因为它把"该往哪个方向投精力"说明白了：

  • 你的瓶颈如果是 \(L_{\text{evo}}\)，再怎么 solve-time 路由都没用——你要做的是给 evolver 更强的能力（多 agent、更大上下文、更多工具）；
  • 你的瓶颈如果是 \(L_{\text{adapt}}\)，再怎么砸算力进化也没用——你要做的是把"提交时机"往后挪，看到任务再决定用哪个 harness（也就是路由）。

我之前在做某个对话系统的时候，团队曾经为了"系统 prompt 该不该针对每类客户单独写"吵过半天。当时如果有这个分解，结论会非常清楚：那是典型的 \(L_{\text{adapt}}\)，再怎么改通用 prompt 都白搭。

AAH 的三件武器

有了损失分解，方案就顺理成章了。AAH 用三件互补的东西打这两个损失：

损失 武器 干什么
\(L_{\text{evo}}\) 多 agent evolver + 跨周期持久状态 把 evolver 的能力天花板抬高
\(L_{\text{adapt}}\) harness 树 (git 分支) + solve-time 路由 把"选择 harness"延迟到见到任务之后
残余的 \(L_{\text{evo}}\) 人类在环钩子 当 evolver 撞上"模型/系统能力之外"的硬墙时，让人补一刀

图3：Adaptive Auto-Harness 系统总览——多 agent evolver 四阶段流水线 + harness tree（git 分支）+ solve-time 路由 + 人类钩子

图3：系统全景。左边是多 agent evolver（Analyze→Research→Build→Verify 四阶段），中间是 harness tree（main + crypto/binary 等专用分支，以 git 仓库存储），右边是 solve-time 的路由 agent。注意人类钩子是在 Analyze 和 Research 阶段插入的——后面会看到这个位置选得很关键。

武器一：多 agent evolver（针对 \(L_{\text{evo}}\)）

单 agent evolver 的问题不是"思考能力不够"，而是单 context 窗口被反馈/轨迹/旧 prompt 挤爆了。AAH 把进化拆成四个阶段，每个阶段是独立 agent、独立上下文预算：

  1. Analyze：读 batch 轨迹，更新 task board（按"高优先级失败"排序）；
  2. Research：3 个并行研究者各自探索假设、记录测试结果；
  3. Build：把验证过的改进真的写进 harness；
  4. Verify：跑 test suite 确认改进没退化。

跨周期之间，整个 workspace（task board、research log、architecture doc、test suite）作为 git 仓库持久化保留。这意味着第 N 周期的 agent 能看到第 1 周期的失败分析、第 5 周期的研究记录——评估只在任务真正解决后才暴露 ground truth，避免信息泄露。

武器二：harness tree + solve-time 路由（针对 \(L_{\text{adapt}}\)）

这是我个人最喜欢的设计。harness 不是一棵单链，而是一棵 git 分支树：

main (通用 harness)
├── branch/crypto-classical    (加密任务专用)
├── branch/binary-reversing    (二进制逆向专用)
├── branch/finance-tech        (金融&科技预测专用)
└── ...

每条分支有自己的 workspace meta，记录这条分支适合什么类型的任务、上次跑出来什么结果。任务来了之后：

  1. Router agent 读所有分支的 meta + 当前任务上下文；
  2. 选一条最匹配的分支；
  3. Solver checkout 该分支、执行任务。

这个设计的妙处在于：它用 git 这套已经存在的、健壮的版本机制做"多 harness 共存 + 选择"，而不是发明新的存储/检索系统。工程上几乎没有成本。

武器三：人类在环钩子

两个钩子点：

  • Task board 引导：人类审完 task board，可以加条目、调优先级、塞领域知识；
  • Research 阶段协助：当 research agent 撞上需要人类的硬墙（auth wall、付费 API、闭源数据），实时弹给人。

注意这里的设计哲学：人类不是来"教 agent 怎么思考"的，是来"补能力之外的洞"的。这跟很多"human-in-the-loop"的产品设计完全不同——后者经常变成"让人帮 agent 做决策"，最后人累死、agent 也没真的学到。

实验：到底涨了多少？

三个 stream，三个不同领域：

Benchmark 任务数 时间跨度 领域
PolyBench 5,075 2026.02.06–22 预测市场（Polymarket）
CTF-Dojo 261 2011–2024 安全竞赛（CTF challenges）
FutureX 503 2026.01–04 事件预测

主结果（节选关键行）：

方法 PolyBench Acc / Profit CTF-Dojo Pass@1 FutureX Pass@1
无进化 Sonnet baseline 22.2% / +1.7% 37.2% 31.0%
A-Evolve 18.4% / +7.2% 45.2% 47.5%
Meta-Harness 50.8% / +320% 41.0% 29.4%
AAH 多 agent 变体 79.8% / +351% 47.9% 49.5%
AAH 完整系统 80.9% / +330% 50.2% 47.3%

PolyBench 上，A-Evolve 居然比"什么都不进化的 Sonnet baseline"还低 4 个点（18.4% vs 22.2%）——这正是开篇那张过进化曲线的直接证据：乱进化反而是负收益。AAH 把同样的"进化范式"做对，从 18.4% 拉到 80.9%，差不多是 4.4 倍。

CTF-Dojo 是另一个有意思的切片。这个 benchmark 的瓶颈是"payload handling 基础设施"——也就是 evolver 能不能给自己装一套处理二进制 payload 的工具。在最大挑战文件这个维度上，单 agent 变体从 81.8% 跌到 30.4%（任务难度上升），多 agent 变体从 90.9% 跌到 39.1%——多 agent 在难任务上稳定保住 9 个点的优势。这正是 \(L_{\text{evo}}\) 被压缩的直接表现：单 agent 撞墙的地方，多 agent 还能再爬一段。

FutureX 上完整系统反而比纯多 agent 变体低 2 个点（47.3% vs 49.5%），这点作者也没遮掩。我的理解是：FutureX 的事件预测任务高度依赖"网络检索访问"，加 router 反倒把一些本来就该走 main 的任务路由错了。这其实暴露了 router 的一个潜在风险——当任务异质性不强时，多分支 + router 可能反而引入额外的 routing 噪声。

消融：哪件武器贡献了多少

多 agent evolver 的消融（图6）

图6：多 agent evolver 消融——把"完整 AAH evolver"分别砍掉时间揭示反馈、跨周期内存、单 agent 化，看哪一项掉得最多

图6：在 PolyBench/CTF-Dojo/FutureX 三个 benchmark 上分别砍掉一项做消融。最右一列是把多 agent 砍成单 agent，CWR 从 44.3 掉到 20.3（PolyBench），跌幅最猛。

关键数字：

  • 完整 → 单 agent：PolyBench CWR 20.3 → 44.3（涨 118%）；CTF-Dojo +5pp；FutureX +6pp
  • 去掉时间揭示反馈：主要伤 PolyBench（这里结果延迟解决，泄露 label 等于直接作弊）
  • 去掉跨周期 memory：三个 benchmark 全面下滑——memory 是最重要的一块

跨周期 memory 这个结论我比较意外。我原本以为多 agent 拆分本身才是关键，但消融告诉我：拆分给 agent 一个干净的上下文是必要条件，但真正让 evolver 越跑越强的是它能记住自己之前试过什么、什么 work、什么不 work。这件事其实很 obvious——我们做 RL 训练的时候不也强调 replay buffer 吗——但在 prompt-based evolver 里居然要做消融才能确认它的重要性，挺值得反思的。

Solve-time 路由的消融（图7）

这个消融才是真正能验证"\(L_{\text{adapt}}\) 是否存在"的关键实验。设四个条件：

  • Oracle：每个任务用最佳分支（事后选）
  • Adapt：AAH 的真实路由（事前选）
  • Naive：永远走 main 分支（无路由）
  • Worst：每个任务用最差分支（下界）

图7：路由消融——Oracle 和 Naive 的差距就是 \(L_{\text{adapt}}\) 的实证测量值

图7：Oracle/Adapt/Naive/Worst 四个条件在三个 benchmark 上的对比。Oracle - Naive 的 gap 直接告诉你"延迟决策"能拿到多少分。

实测的 \(L_{\text{adapt}}\)（Oracle − Naive）：

  • CTF-Dojo：55.0% − 17.5% = +37.5pp（巨大！这个 benchmark 异质性极强）
  • PolyBench (CWR)：+12.0% − 3.2% = +8.8pp
  • FutureX：46.6% − 39.7% = +6.9pp（最小）

CTF-Dojo 上 37.5 个点的 gap 很能说明问题：当任务异质性强、且不同任务真的需要根本不同的工具/方法时，单一 harness 即使被无限优化也吃不到这部分潜在收益。这就是适应损失存在的实证。

而 AAH 的 Adapt 条件能从 17.5% 拉到 35.0%（CTF-Dojo），相当于吃掉了 17.5pp / 37.5pp ≈ 47% 的适应损失。剩下的 53% 是 router 自身的判断错误造成的——这给后续工作留了明确的优化方向：把 router 做强。

人类在环（图9）

图9：人类钩子的切片提升——按任务子类别看人类引导带来的增量

图9：100 个 FutureX 任务上的切片分析。绿色条是有人类钩子的版本相对纯自动版本的提升。最左两类提升 0–5pp，金融&科技切片直接 +20pp。

按任务切片的提升：

  • 宽泛多市场问题：0pp
  • 宽泛搜索依赖问题：+5pp
  • 直接命中的金融&科技切片：+20pp
  • 相邻西方专业问题：+15pp

结论很硬：人类引导只在"agent 缺外部信号"的地方有用——比如 agent 没法访问的付费金融 API、新的网络源。在 agent 本身能搜到的宽泛问题上，人类的"通用建议"约等于零贡献。

这条结论我觉得对工程实践的启示比方法论本身更直接：你团队里那个一直追着 agent 提"建议"的产品经理，大概率是在做无效功。真正有效的人类干预是补能力的洞，不是补思考的洞。

我的判断

这篇值不值得读

值得，而且建议精读。但不是为了它的方法（方法本身在工程上其实并不算特别新——多 agent、git 分支、人类钩子，这些零件你都见过），而是为了它对问题的形式化。

具体来说：

  • \(L_{\text{evo}} + L_{\text{adapt}}\) 的损失分解会成为接下来一段时间内 Agent 系统设计的标准语言。它给出了一个非常干净的"该怎么投精力"的判据：先想清楚你的瓶颈在哪一项，再决定是堆 evolver 还是堆 router。
  • 三个部署维度（无界、异质、漂移）的命名虽然朴素，但值得收藏。下次有人说"我们 Agent 上线效果掉了"，你可以直接拿这三维去对号入座。
  • "人类只补能力洞"的实证对产品设计的指导意义比方法本身大。

几个我觉得它没说透的地方

第一，router 的训练/演化论文几乎没讲。它假设 router agent 能读 workspace meta 后做对决策——但 router 自己也是一个 LLM agent，它会犯错，它的错误在 FutureX 上让完整系统反而比纯多 agent 差。这个问题作者直接当成"future work"打发了，我觉得这是这套系统未来最大的优化空间。

第二，\(L_{\text{evo}}\) 和 \(L_{\text{adapt}}\) 的可分性其实是一个挺强的假设。论文做拆解时基本默认了"evolver 类别 \(\Phi\) 不影响 oracle harness 的存在性"，但实际上你的 evolver 能做的事会改变 harness 树的形态、进而改变 router 的最优策略——两者并不真的独立。这个数学细节作者没展开。

第三，benchmark 里 CTF-Dojo 这种工程类强、异质性强的任务最 favor AAH 的设计。FutureX 那种本身就高度搜索依赖、异质性弱的任务，AAH 完整系统反而不如纯多 agent 变体。我会担心：如果你的真实业务场景更像 FutureX 而不是 CTF-Dojo，AAH 完整套件可能并不是最优选择，单纯升级 evolver 就够了。

工程启发

如果你正在或将要部署一个长期运行的 Agent 系统，这篇至少可以指导你做三件事：

  1. 不要只看 benchmark 分数。在你的真实任务流上跑 4–6 周，看技能/prompt 是不是膨胀、看准确率有没有先涨后跌的曲线。出现就是 \(L_{\text{evo}}\) 已经被打满 + 进化器还在过拟合早期 batch 的尾部。
  2. 如果你的任务异质性强，先做 routing，再做 evolver 升级。CTF-Dojo 上 router 给了 17.5pp 的真实增益，这比你再把 evolver 升级一轮更划算。
  3. 人类资源用在"补能力洞"上。把"哪些任务需要人类提供 API/数据"列出来，做成 hook；不要把人类时间花在"建议 prompt 怎么改"上。

一句话收尾

这篇论文最厉害的不是它做了什么——而是它把"自动 harness 系统线上部署"这件事第一次说清楚了：你的 Agent 在线上掉点，不一定是模型不行、也不一定是 evolver 不行，可能是你根本不该追求"一个 harness 打天下"。 \(L_{\text{evo}}\) 和 \(L_{\text{adapt}}\) 的拆解会让接下来一年里的 Agent 系统论文都好读很多。

觉得有启发的话，欢迎点赞、在看、转发。跟进最新 AI 前沿，关注我

参考链接：

  • arXiv: https://arxiv.org/abs/2606.01770