LLM 能自己创建和演化 Agent Harness 吗？

湖泊

LLM 能自己创建和演化 Agent Harness 吗？

来自 ByteDance Seed 等团队的研究者们，发布了一个把评测对象从 "任务答案" 转向 "Agent 执行基础设施" 的基准「HarnessDev」
论文：https://huggingface.co/papers/2609.01437

现有问题
同一模型换个 harness（执行循环、工具、上下文管理、恢复、验证），成绩可差十几个点，但现有基准都把 harness 当作固定配置，从未评测 "模型能否自己造 harness"。论文填补这一空白。

基准设计
· Creation：从一个只有被动工具、无任何策略、零分的弱种子出发，凭任务说明和 1–3 个样例构建完整 harness。
· Evolution：从自建 harness 出发，用 189 个反馈任务的结果迭代 10 轮，自选最终版；之后在 630 个从未展示的任务上测泛化。
· 创建者与执行者分离：Self-Eval（跑自己写的）vs Unified-Eval（统一用 Gemini 跑），前者测协同设计，后者测 harness 是否是可迁移资产。
· 同时报能力与执行 token 成本；评分只看真实 diff/环境状态，harness 自报成功不计分。
· 6 个创建者，4 领域 5 基准，2,207 个实例。

Creation 结果
· 六个创建者：Opus 4.8、GPT-5.5、Gemini 3.1 Pro、DeepSeek V4 Pro、Qwen 3.7 Max、Seed 2.0 Pro。开发环境统一用 Claude Code（GPT-5.5 用 Codex）。每个创建者-基准对独立创建 3 个 harness，报 avg@3。
· 领域差异极大：写作持平人类参考、ML 实验超过参考，代码落后（69.3 vs 80.0），搜索研究差距最大（52.6 vs 92.2）。
· 共适应严重：Opus 的 harness 换 Gemini 执行，SWE-Pro 从 69.3 跌至 33.0，原因是硬编码了 120 步上限；Qwen、DeepSeek 的 harness 换更强执行者反而提升。可运行不等于可迁移。
· 代码量不预测性能：Gemini 加行最少却拿 Terminal-Bench 最高分。
· 状态/记忆几乎全是死代码：26,679 条轨迹中零次 checkpoint；验证多停留在语法层。
· 成本与效果不相关：同等分数 token 消耗可差约 7–19 倍。
有效的开发模式是"读失败→定向改→再验证"（修订次数与分数相关 0.57），而非堆自测。

Evolution 结果
· 反馈集上都涨（+3 到 +14），held-out 上缩到 +1.4 到 +4.4；固定 Gemini 执行时仅 Opus 仍正向，其余倒退，GPT-5.5 达 −10。
· 64 次版本切换中仅 2 次有超出噪声的明确正向证据；同一 commit 重跑波动约 ±4.75 分。
· 反馈与泛化方向一致仅 53%，9 个自选最终版只有 2 个是 held-out 最优——反馈分数可用于局部搜索，不可用于最终选版。
· 诊断是最弱环节：轨迹查看接口全程只用 2 次。正例是 Opus 发现 99 次自报成功只有 48 次真过，加了完成检查门。