Task-CoEvolve：自适应验证任务选择做高效 harness 优化

  • 关联论文：2608.20169
  • 作者：flyP
  • 更新：2026-08-25

一句话结论

把 LLM 的 prompt / 工具链 / 代码（合称 harness）当作可优化对象时，传统方法每轮都对固定验证集做全量评估，成本巨大；Task-CoEvolve 用"分歧驱动的方差加权采样"动态收缩验证集，在优化全程的评估次数砍掉 80% 的同时，最终成绩仍能匹配全量搜索，并把"如何从部分采样无偏估计全集分数"这件麻烦事一并解决。

解决的真问题

prompt tuning、program-aided LLM、agentic harness 优化这一整条 2025–2026 年的热门技术线，背后都有一个共同瓶颈：每改一次 harness，都要在验证集上跑全量评估。一次 harness 搜索往往要迭代几十到上百次，全量评估意味着几十×N 次 LLM 调用，对前沿模型而言是分钟级 × 美元级的双重成本。

更糟的是，验证集里的任务会随着 harness 进化而变得不再有判别力——已经被全部答对的"送分题"和全部答错的"超难题"对区分 harness 优劣毫无贡献，但传统方法每一轮都还在老老实实给它们付账单。

本文解决的问题就是：如何在 harness 进化的同时，让验证任务集合也跟着进化，做到既便宜又可比。

核心方法

Task-CoEvolve 的方法名直白——让验证任务与 harness 共同进化（co-evolve）。它解决两个具体的子问题：

子问题 1：选哪些任务进入本轮评估

观察：候选 harness 在哪些任务上意见不一致，比"在哪些任务上都被答对或都被答错"更能区分 harness 优劣。

工程实现：

  • 分歧驱动：用候选 harness 在历史任务上的输出一致性 / 差异性作为信息量代理。
  • 方差加权采样：基于历史结果估计每个任务的方差，方差大的任务（接近模型能力边界）被采样概率更高。
  • 自适应分布：采样分布随 harness 进化而漂移——当某类任务对当前 harness 不再有判别力时，采样权重自然下降。

子问题 2：如何从部分采样无偏估计全集分数

观察：直接对采样子集求平均会偏（高方差任务被多采），需要做重要性加权或概率矫正。

工程实现：

  • 在每轮评估后，根据本轮的采样概率分布，估计全集上的等价分数。
  • 跨迭代可比：尽管每轮评估的是不同子集，但矫正后的分数可直接比较，从而支持"早停 / 继续搜"的决策。

关键伪代码

for iter in range(max_iters):
    candidates = propose_harnesses(prev_best)        # harness 生成器
    # 1) 选任务：分歧 / 方差加权
    sampling_probs = variance_weights(history)
    tasks_iter = sample(validation_set, sampling_probs, budget=B)
    # 2) 跑部分评估
    raw_scores = evaluate(candidates, tasks_iter)
    # 3) 概率矫正，估计全集分数
    full_score_estimate = importance_correct(raw_scores, sampling_probs)
    # 4) 选本轮 best，更新历史
    prev_best = select_best(candidates, full_score_estimate)
    history.update(candidates, tasks_iter, raw_scores)

两个关键设计决策：

  • "分歧驱动"比"困难度驱动"更稳：困难度（错误率）高的任务未必能区分候选 harness；只有"不同候选给出不同答案"的任务才是真信息源。
  • 重要性矫正必须在每轮做：因为采样分布本身随 harness 漂移，跨迭代可比性不是免费的，必须显式做概率矫正。

关键实验与数据

⚠️ 数字均来自 arXiv abstract 与 paper card TLDR。

  • 任务域 2 个：
  • 在线文本分类（持续学习场景的代表任务）
  • Terminal-Bench 2.1（agent / 工具使用能力的真实代理基准）
  • 基线 2 类：subset-based baselines（固定小子集 / 均匀随机子集等）
  • 核心结果：
  • 在两个任务域上稳定优于所有 subset-based baselines；
  • 最终分数匹配全量搜索（full-set search）的成绩；
  • 评估次数减少 80%——意味着 harness 优化全程的 LLM 调用预算降至原来的 1/5。
  • 代码：GitHub 已开源 https://github.com/Agent4Science-UTokyo/Task-CoEvolve。

⚠️ 原文 v2 主要修 typo，未在 abstract 公开每个基线、每个任务域的具体分数表与"80% 评估节省"的计算口径（按 LLM 调用次数还是按 wall-clock 时间）。Terminal-Bench 2.1 上各基线的绝对分数需读 v2 正文。

亮点与局限

亮点：

  • 同时攻下"选什么"和"如何从部分估全集"两个子问题，而不是只优化其中一个。这是 harness 优化从"经验法则"走向"可证明无偏估计"的关键一步。
  • 把"分歧作为信息源"这个观察形式化，并给出方差加权采样作为可工程实现版本，比单纯"挑难样本"更稳。
  • 在 Terminal-Bench 2.1 这类真实 agent 基准上验证——agent 评估单次成本高，80% 节省的实际经济意义远大于普通文本分类。
  • 与"训练数据课程学习（curriculum learning）"形成有趣对照：Task-CoEvolve 是在评估侧做课程，而不是在训练侧。
  • 提交信息：v2 于 2026-08-24 提交，开源代码已发布。

局限：

  • 两个验证任务域偏窄：在线文本分类 + Terminal-Bench 2.1 都是"打分明确、可批量"的场景，对开放式生成、长对话、创意写作这类"评估本身有噪声"的任务未见验证。
  • 80% 节省的计算口径未在 abstract 明确：是按 LLM 调用次数、token 总量、还是 wall-clock 计算，对工程决策影响很大。
  • "分歧驱动"在冷启动阶段需要历史数据：harness 优化的第 1 轮没有历史方差可用，需要 warm-start 策略，abstract 未提及。
  • harness 搜索空间本身是黑盒：论文假设已有 harness 生成器，没有讨论生成器本身的设计——而实践中 harness 搜索空间往往比评估方式更决定成败。
  • 未与贝叶斯优化 / 多臂老虎机式主动学习横向对比：与 AL/BO 那一脉文献的关系在 abstract 中未点明。

对工程落地的启发

  1. agent / harness 优化团队应优先评估 Task-CoEvolve：对任何"prompt + tool 编排 + 代码骨架"可被参数化搜索的项目，这是直接的成本结构改造，理论上单次项目节省 5× 评估预算。
  2. 分歧驱动的验证任务选择本身可独立使用：即使不上完整 Task-CoEvolve 框架，仅"按候选 harness 的输出一致性来筛选验证任务"这一招，对任何 ablation 研究都有效。
  3. 重要性矫正逻辑可复用：任何做"采样评估 + 全集估计"的系统（不仅是 LLM harness 优化，包括 RLHF 奖励模型评估、A/B 测试小流量扩量）都可借鉴"采样概率 → 重要性加权"这一模式。
  4. Terminal-Bench 类基准应当引入自适应评估：固定子集评估在 agent 时代越来越贵，基准本身应当提供"按 capability frontier 自适应采样"的官方接口。

与同方向工作的关系

  • 与 prompt optimization（OPRO / TextGrad / DSPy MIPRO）的关系：Task-CoEvolve 与它们正交——这些方法关注"如何生成更好的 harness 候选"，Task-CoEvolve 关注"如何低成本评估 harness 候选"，两者是天然的上下游组合。
  • 与 agent evaluation 文献（如 SWE-bench / Terminal-Bench）的关系：本文是评估侧的成本优化，与基准设计互补。对 Terminal-Bench 类高成本基准，本文的工程价值尤其高。
  • 与 active learning / curriculum learning 的关系：本文可视为把 active learning 的"挑样本"思想搬到了评估侧——以前主动学习挑的是训练样本，Task-CoEvolve 挑的是评估样本。
  • 与 Bayesian Optimization 文献的关系：在概念上接近 BO 的 acquisition function 设计，但本文以"harness 间分歧"为信息源，与 BO 的 predictive uncertainty 不同路线。

适合谁读

  • agent / harness 工程团队：在做 prompt tuning、tool-use 编排、agent 搜索的工程师，尤其是评估预算吃紧的小团队。
  • AutoML / 程序合成研究者：把 harness 视为可优化程序的人，会对"分歧驱动采样"和"重要性矫正"两件套感兴趣。
  • 基准设计者：Terminal-Bench、SWE-bench 类高成本基准的维护者，可考虑把 Task-CoEvolve 作为自适应评估的参考实现。
  • 评测基础设施工程师：任何在做"子集评估 → 全集估计"管线的人，都能借鉴本文的概率矫正思路。

事实核查与不确定项

验收点 状态 来源
arXiv ID 真实存在 ✅ arxiv.org/abs/2608.20169（v2 于 2026-08-24 02:04 UTC 提交）
接收会议 ⚠️ abstract / Comments 未明确写"Accepted to X"，v2 仅说明修 typo 并给 GitHub
在线文本分类 + Terminal-Bench 2.1 两个任务域 ✅ abstract 原文
优于所有 subset-based baselines ✅ abstract 原文
评估次数减少 80% ✅ abstract 原文
最终分数匹配全量搜索 ✅ abstract 原文
80% 节省的计算口径（LLM 调用 vs wall-clock） ⚠️ abstract 未细化
冷启动 / warm-start 策略 ⚠️ abstract 未涉及
与 BO / active learning 的横向对比 ⚠️ abstract 未提及，需读正文
GitHub 仓库可访问性 ⚠️ https://github.com/Agent4Science-UTokyo/Task-CoEvolve 未做 HTTP 200 验证（遵循任务约定只读 abstract）

工程落地与核查（Jay）

一、GitHub 验证

  • GitHub 仓库 Agent4Science-UTokyo/Task-CoEvolve HTTP 200 可达（2026-08-25 验证），说明代码已公开，与 abstract 描述一致。

二、关键事实核查

✅ 支撑性结论： - "评估次数减少 80%"与"最终分数匹配全量搜索"是原 abstract 并列陈述，两者共同构成"省 5× 评估预算且不掉点"的完整结论，解读原文引用两者是合理的。 - Terminal-Bench 2.1 是 agent 评估基准，单次评估成本高（涉及工具调用、bash 等），80% 节省在 agent 场景的经济价值远高于普通文本分类，解读在"亮点"中的工程价值判断有依据。

⚠️ 待核 / 存疑项： 1. 80% 计算口径未公开：是按"LLM API 调用次数"、"token 总消耗"还是"wall-clock 时间"计算，直接影响工程预算申报方式。实际落地前需向作者确认或读 v2 正文 §X。当前解读未擅自填补这一空白，做法合规。 2. 各基线在各任务域的绝对分数未公开：abstract 仅给出"稳定优于所有 subset-based baselines"的定性结论，各配置具体 F1 / 准确率数值需读 v2 正文表。解读正文已加 ⚠️ 标注。 3. 冷启动（warm-start）策略：第 1 轮 harness 优化无历史方差可用，abstract 完全未提。实战中可能的 fallback：第 1 轮用均匀随机采样（类似 subset-based baseline），或利用 OPRO 等方法的已有评分数据作为 prior。需读正文确认，不可假设。 4. harness 生成器黑盒：论文假设 harness 候选生成器已存在，但未讨论其设计。实践中 harness 生成器的搜索空间设计往往比评估策略更决定最终效果——如果生成器产生的高多样性 harness 候选本身就少，方差加权采样的优势会打折扣。

三、实际系统落地的坑

坑 1：冷启动无历史数据时，分歧驱动采样退化为均匀随机 第 1 轮没有 history，sampling_probs 无法计算。系统必须支持从"均匀采样"无缝切换到"方差加权采样"，这个边界情况在论文中未描述，实现时需要自己填。

坑 2：harness 候选之间相似度极高时，分歧信号趋近于噪声 如果生成的 harness 候选（例如 DSPy MIPRO 产生的两个 prompt 变体）结构高度相似，候选之间的分歧主要由随机性驱动，而非真实的能力边界差异。此时方差加权采样等价于在噪声上做加权。

坑 3：重要性矫正在采样分布剧烈漂移时可能不稳定 当 harness 从"糟糕"快速进化到"优秀"时，采样分布会产生剧烈漂移（高信息量任务集合在两轮之间变化很大）。此时 importance weighting 的方差会增大，估计量的无偏性依赖渐近假设，小样本下可能偏差较大。

坑 4：Terminal-Bench 类高成本基准的 API 速率限制 Terminal-Bench 涉及真实工具调用（bash、browser 等），可能有速率限制（每分钟 API 调用次数上限）。80% 节省是统计结果，工程落地还需要确认评测框架是否支持并发评估——如果评测框架本身是串行的，节省的是 API 调用次数而不是 wall-clock 时间。

坑 5：与 DSPy MIPRO / OPRO 的组合需要接口对齐 Task-CoEvolve 与主流 harness 优化框架的正交性既是优点也是工程挑战——需要自己实现 propose_harnesses(prev_best) 接口来对接 DSPy 的 prompt program 或 OPRO 的优化器。不是开箱即用的组合，需要约 1–2 周集成工作。

四、可用性评估

维度 评估
代码可用性 ✅ GitHub 200 已验证，有可运行的 code release
概念可直接落地 ⚠️ 需对接 harness 生成器，不是独立工具
冷启动有方案 ❌ 需自己填补
评估框架支持并行 ⚠️ 需读 Terminal-Bench 代码确认
与 DSPy MIPRO 集成难度 中等（需 1–2 周接口对接）
经济收益可量化 ⚠️ 80% 口径未明确，需与作者确认后再向管理层申报