上周字节跳动 Seed 团队联合新加坡科技设计大学、佐治亚理工等机构发布了 HarnessDev，研究一个和 Agent 工程相关的问题：LLM 能不能自己创建 Agent Harness，并根据后续任务的运行反馈持续修改这套 Harness。
HarnessDev 将 Agent 的核心控制能力留给 creator 自行构建。每个 creator 都从同一套 Weak Seed Harness 出发：它具备基础运行能力和必要接口，模型需要在此基础上补齐 Agent Loop、工具策略、上下文管理、状态管理、结果验证等控制逻辑。
完成创建后，Harness 会被冻结，再由 executor 执行 Code、Data、Writing 和 Research 等领域的下游任务。论文将整个过程分为两个阶段：
Creation：从 Weak Seed 出发，构建一套完整的 Agent Harness。
Evolution：以 Creation 阶段生成的 Harness 为起点，根据下游任务的运行反馈持续调整，并评估新版本在后续任务中的表现。
Creation 阶段，HarnessDev 共测试了 6 个 creator 模型，覆盖 4 个任务领域、5 个 Benchmark 和 2,207 个下游任务实例。
图注：HarnessDev 的 Creation 与 Evolution。左侧是固定 Harness 的现有 Agent Benchmark；右侧分别展示 Creation 阶段从 Weak Seed 创建 H₀，以及 Evolution 阶段根据运行反馈继续迭代 H₀ → H₁ → Hₙ。
从 Weak Seed 补齐 Harness 控制层
Creation 阶段中，所有 creator 都从同一套 Weak Seed Harness 出发。
这套 Seed 先把基础运行框架搭好：它能够读取任务和模型配置，管理工作目录，并向上提供文件访问、搜索、进程调用和 LLM Gateway 等基础接口。任务执行过程中产生的日志和轨迹，也会由这套框架统一记录。
在这个基础上，creator 再补充真正驱动 Agent 完成任务的控制逻辑，比如如何推进任务、怎样调用工具、如何组织上下文、记录执行状态，以及什么时候需要验证结果、处理失败或结束任务。未经扩展的 Seed 在五个下游 Benchmark 上得分均为 0。所以，Creation 阶段考察的是模型能否基于一套最小运行框架，逐步搭出完整的 Agent 控制层。
论文进一步将 Harness 的控制能力归纳为六类：
Execution：执行循环、规划、调度和停止条件
Tools：工具选择、参数约束、输入输出和错误处理
Context：任务、代码、历史、日志和约束的上下文组织
State：当前目标、进度、尝试记录、失败信息和产物状态
Lifecycle：超时处理、恢复机制、前后置流程和任务收尾
Verification：测试、结果检查、完成判定和运行记录
这六类能力覆盖了 Agent Harness 从接收任务、推进执行到结果交付的主要环节。
以 Coding Agent 为例，Execution 负责控制任务如何推进以及何时结束；Tools 处理各类工具调用；Context 决定哪些任务信息和执行历史需要提供给模型；State 记录当前进度和任务状态；Lifecycle 负责执行过程中的异常、超时和恢复；Verification 则用来检查代码修改和最终结果是否符合任务要求。
论文并不要求这六类能力分别对应六个独立模块。重要的是这些能力要真正参与 Harness 的执行过程。后续实验因此还会继续检查，代码里实现的这些机制在真实任务中是否实际触发并发挥作用。
图注：Harness 的六类控制能力
从代码存在到运行时生效
从实验结果看，LLM 可以在 Weak Seed 的基础上补出一套完整度较高的 Harness。
图注：不同 creator 的 Code Harness 改动规模与任务表现
18 份 Code Harness 一共新增了 17,111 行代码，但改动规模和任务表现之间没有明显对应关系。Gemini 的代码改动最少，只新增了 1,006 行，却在 Terminal-Bench 2.1 上拿到了 68.8 的最高分。
作者随后进一步检查这些能力在真实任务中的运行情况。18 份 Code Harness 都实现了 Execution Loop；Tools、Lifecycle 和 Verification 也有较高的完成度，分别有 13/18、13/18 和 15/18 达到完整状态。
相比之下，State 和 Memory 的实际运行证据要少得多。
11 份 Harness 定义了 State 类，其中只有 1 份提供状态保存接口，1 份实现了周期性 checkpoint。作者继续检查 26,679 条真实任务轨迹，里面没有出现一次 checkpoint event。这说明一些 Harness 虽然写入了 State、Memory 和 checkpoint 相关逻辑，但这些机制在实际执行中并没有被触发。
作者随后把检查范围扩展到更多组件。Code Harness 中一共统计了 108 个组件实例，其中 72 个能在真实任务里观察到完整运行，18 个只有部分运行记录，另外 18 个始终没有出现在实际执行中，而这 18 个全部来自 State 和 Memory。Writing 和 Data Harness 里也出现了类似情况：有些机制虽然写进了代码，但真实任务并没有走到对应流程。
这说明评估一套 Harness 时，除了确认某项能力是否实现，还要继续检查它在真实任务中有没有被触发，以及触发之后是否发挥了预期作用。
这类检查可以借助任务轨迹来完成。比如 checkpoint 可以记录创建和恢复情况，重试机制可以记录每次触发的原因和结果，Verifier 也可以保留每次验证的判定。跑完一批任务后，开发者就能进一步确认这些机制实际触发了多少次，又分别影响了哪些任务。
图注：Harness 架构。图里的颜色表示机制证据密度，并不代表对应模块对最终成绩的因果贡献。
从完成判断到结果验收
Verification 的作用，是在模型给出完成判断之后，再检查任务结果是否真正满足要求。
HarnessDev 的 Evolution 阶段提供了一个案例。Opus 在检查任务结果时发现，100 次运行中有 99 次 Harness 自报成功，但真正通过评测的只有 48 次。它随后把问题定位到任务过早结束，并加入 Completion Check，对任务完成状态进行额外检查。
对于 Coding Agent，模型完成代码修改后，还需要继续确认测试是否通过、项目能否构建，以及目标问题是否得到解决。Data Harness 中也出现了类似情况：在 2,325 个执行任务里，有 441 个产生了退化提交，但这些异常结果都没有被 Harness 识别出来。
因此，模型给出的 completion 更适合作为进入 Verification 的信号，再由后续检查决定任务是通过、重试、重新规划还是结束。
Harness 中的 Verification 需要关注最终任务结果，而不只检查输出格式或代码语法。
Harness 与 Executor 的适配关系
Harness 创建完成后，论文进一步测试了它在不同 executor 之间的迁移表现。
Self-Eval 中，creator 使用自己创建的 Harness 执行任务；Unified-Eval 则统一换成 Gemini 3.1 Pro 作为 executor，再运行同一套 Harness。两组结果之间出现了明显差异。
例如，Opus 创建的 SWE-Pro Harness 在 Self-Eval 中得分为 69.3，换成 Gemini 执行后降到 33.0。作者检查后发现，这套 Harness 将 120 步上限写进了执行逻辑，而这一参数是围绕原 executor 的运行特点设置的，换模型后便不再适配。
Search 任务里的变化更大。Opus Harness 更换 Gemini 后，重复查询率从 10.1% 上升到 88.2%，说明原有的去重、复查和停止规则与 executor 的行为存在较强关联。
也有 Harness 在更换 executor 后表现提升。Qwen Harness 使用 Gemini 执行后，BrowseComp 提升 17.6 分，MLE-bench 提升 12.9 分，表明原 executor 本身也可能限制 Harness 的表现。
这组结果说明，多模型 Agent 的适配不只发生在 API 和 Tool Calling 层。Prompt、工具协议、执行预算、步骤上限、Context 策略和停止规则，都可能逐渐形成针对特定 executor 的配置。
因此，更换底层模型时，这些运行策略也需要重新验证和调整。
图注：同一 Harness 更换 Gemini executor 后的变化。实心点代表 Self-Eval，空心点代表固定 Gemini 执行后的成绩。
Harness 的持续演化与泛化
Creation 阶段完成 Harness 的初始构建后，Evolution 继续测试 LLM 能否根据运行反馈修改自己的 Harness，并让这些改动延续到后续任务中。
这一阶段聚焦 Code Harness。模型从 Creation 得到的 H₀ 出发，在可见反馈集上运行任务、分析结果并修改 Harness，再提交新的版本。与此同时，作者保留了 630 道 SWE-Pro held-out 任务，用来评估这些改动在新任务上的表现。
在 creator 自己作为 runtime 的 self-runtime 设置下，5 条演化轨迹在可见反馈集上的分数都有提升。Qwen 从 41.8 提升到 55.7，增加 13.9 分；DeepSeek 从 47.2 提升到 60.6，增加 13.4 分。
到了 held-out 集，两者的提升分别缩小到 1.43 分和 3.17 分。5 条 self-runtime 轨迹在 held-out 上的平均提升为 3.11 分。
固定使用 Gemini 作为 runtime 后，结果进一步分化。4 条演化轨迹中，Opus 的 held-out 分数提升 2.70 分，Qwen、DeepSeek 和 GPT-5.5 均出现回落，其中 GPT-5.5 下降 10.32 分。
作者还比较了 64 次相邻版本切换。反馈集和 held-out 集的变化方向一致率为 53.1%；9 个 creator 最终选出的版本中，只有 2 个同时也是 held-out 上表现最好的版本。
这组结果对应了 Agent 开发中一个常见的评测问题：随着开发者持续查看同一批任务的失败结果，并据此调整 Prompt、工具和执行流程，可见反馈集也会逐渐参与到 Harness 的优化过程中。反馈集上的涨分，因此未必能完整延续到新的任务。
对于持续迭代的 Agent Harness，可以将开发阶段使用的反馈集和最终选版使用的 held-out 集分开，用后者检查新版本的泛化表现。
图注：Evolution 中反馈集与 held-out 的版本轨迹
版本提升与评测波动
Agent Harness 的版本评测还会受到运行波动的影响。
HarnessDev 测得，同一个 commit 重复运行时，评测分数的波动约为 ±4.75 分。在 64 次官方版本切换中，有 27 次分数变化仍落在这一波动范围内。
因此，如果一个 Harness 从 62 分提升到 64 分，仅凭一次评测还不足以判断这次修改是否真正有效。实际开发中，可以先对同一版本进行多次评测，估算系统自身的波动范围，再判断后续版本的变化是否超过这一范围。
论文还比较了 creator 的开发行为。自测次数与下游成绩的相关性只有 0.13～0.26，而根据反馈进行修改的 revision calls 与成绩的相关性达到 0.57。相比反复运行测试，读取失败结果、定位原因、修改对应机制并重新验证，与最终表现的关系更明显。
这也提高了任务轨迹和结构化日志的重要性。开发者需要从一次失败任务中看到模型当时接收了哪些信息、执行了哪些操作、在哪一步偏离预期，以及任务最终为何结束或被判定为成功。
这些运行信息能够帮助开发者把问题定位到具体执行环节，减少只围绕 Prompt、参数和评测分数反复调整的情况。
Harness 的执行成本
Harness 也会影响 Agent 完成一次任务所需的执行成本。
不同的执行策略，会改变模型的调用轮数、上下文长度和工具调用次数，失败后的重试与恢复也会继续增加消耗。
论文在 MLE-bench 上观察到了较大的成本差异。GPT-5.5 Harness 使用 29.3M token，medal rate 为 19.1；DeepSeek V4 Harness 使用 208.4M token，成绩为 19.6。两者表现接近，token 用量相差约 7 倍。放到整个 MLE-bench 实验中，不同 Harness 的 token 开销跨度约为 19 倍。
因此，评估 Harness 时，可以把任务表现和执行成本放在一起观察。除了成功率，也可以记录单任务 token、模型调用次数、工具调用次数和运行时间等指标。
如果一个新版本只带来小幅性能提升，却需要明显更多的 token 和执行时间，就需要结合实际业务判断这次改动是否值得保留。
图注：Harness 的执行成本与任务表现。横轴是执行 token，用对数尺度展示；纵轴是对应 Benchmark 的下游成绩。
结语
HarnessDev 关注的核心问题，是 LLM 能否自行构建 Agent Harness，并根据运行反馈继续调整这套执行系统。从实验结果看，模型可以从 Weak Seed 出发补齐主要控制能力，也能结合下游任务结果继续修改已有 Harness。
但真正进入工程使用后，Harness 还需要接受更多运行层面的检验。比如代码里的机制是否真的被触发，模型声明完成后有没有可靠验证，更换 executor 后原有能力能否保持，以及版本提升能否延续到 held-out 任务。论文中，26,679 条任务轨迹没有记录到一次 checkpoint；Evolution 阶段中，可见反馈集与 held-out 集的版本变化方向一致率也只有 53.1%。
对开发者来说，评估 Harness 时，除了看代码结构和 Benchmark 分数，也需要关注真实运行路径、结果验证、executor 适配、版本泛化和执行成本。随着 Agent 开始承担 Coding、Research 和更长时间的任务，这些问题也会逐渐进入 Harness 的日常设计和维护过程。
参考资料：
论文： HarnessDev: Can LLMs Create and Evolve Their Own Agent Harness?
arXiv： 2609.01437
项目页： self-developing-agents.github.io/
