HarnessDev: 大语言模型能否创造并演化自己的智能体 Harness?

TL;DR HarnessDev 首次将评估对象从 agent 的任务输出转向其自建的执行基础设施（harness），让 LLM 从最小种子创建并演化 harness，在多个基准上衡量能力与效率，揭示了自建 harness 的现状与跨模型迁移的局限。

问题

问题背景

当前 AI agent 研究正从单次任务求解转向长期自主运行，模型外部执行基础设施（agent harness）对最终表现的影响日益凸显。同一套模型权重，更换 harness 即可显著改变任务成功率。

现有方法局限

主流 agent 评测（如 SWE-bench、WebArena）聚焦于给定 harness 下的下游任务得分，将 harness 视为固定组件而非可开发对象。这导致两个盲区：

• 无法衡量模型自主构建执行系统的能力——实际部署中往往缺少成熟 harness，模型需从零搭建或适配异构环境；
• 忽略 harness 本身的迭代价值——即便初始 harness 性能不足，是否能在执行反馈中持续演化，现有评测体系并不考察。 同时，已有自动化 agent 设计工作（如 ADAS、AFlow）多针对特定任务优化提示词或工作流，未把完整可运行的 harness 作为评估单元，缺乏对效率指标（如执行 token 成本）的系统约束。

为什么这个问题难且重要

构建 harness 需要模型同时具备代码生成、工具编排、环境理解与反馈整合能力，其搜索空间远大于单任务输出。而且 harness 与执行模型存在耦合：同一个 harness 在不同 runtime model 下表现可能剧烈波动，导致优化结果难以泛化。业界对可复现、可迁移、低成本的 agent 基础设施需求迫切，因为生产环境中 harness 的维护成本往往超过模型本身，而目前缺少统一的开发与评测范式。

行业类比

类似于自动驾驶的仿真与车辆控制系统：感知模型决定了上限，但车辆控制代码（harness）的优劣直接决定实际行驶表现，且不同车型（runtime model）需要不同的调校策略。

核心洞察

• 评估单元从任务输出转移到可运行基础设施本身，揭示模型在 harness 设计上的能力短板。传统 agent 基准固定 harness 测下游指标，无法分离任务解决能力与执行环境构建能力；HarnessDev 通过 Creation 阶段从最小种子构建完整执行系统，并隔离 held-out 基准评估，直接度量 harness 质量，结果发现自建 harness 在代码、搜索与研究域仍显著落后人类参考，说明基础设施设计是独立于模型权重的关键能力维度，直接影响实际部署的可行性。
• Evolution 阶段用下游执行反馈迭代改进 harness，但收益不稳定且跨模型迁移差，暴露当前 LLM 自改进执行环境的脆弱性。与自动智能体设计 (ADAS) 等工作相比，HarnessDev 强调从模型自创的 harness 出发，并在 held-out 任务上验证，发现改进可能过拟合开发集，在固定 runtime model 下跨模型迁移有限，提示 harness 优化需谨慎评估泛化性，不能仅依赖开发集反馈。

方法

HarnessDev 将评估单元从任务输出转移到可运行的 agent harness 本身。方法遵循“输入 → 构建 → 评估”流程。

输入 包括一个最小种子 harness H_seed（仅含基础接口骨架）和少量开发案例，不提供完整任务分布。

关键模块 分为两个阶段：

1. Harness Creation：创建者 LLM 从 H_seed 出发，在少量案例上理解需求，自主扩展出完整的执行系统——覆盖工具调用、上下文管理、输出解析、错误处理等。此阶段模拟从零搭建基础设施。
2. Harness Evolution：以自建 harness 为起点，引入下游执行反馈（如任务失败原因、执行 token 开销），迭代修改 harness 代码，目标是提升基准性能。反馈回路允许模型像软件工程师一样对 harness 做版本修订。

输出 是每个构建的 harness 在 held-out 基准上的评分，包含两个核心指标：capability（任务成功率）和 efficiency（执行 token 成本）。评估同时检查 constraint compliance，并将 creator LLM 与 runtime model 分离，以测量 harness 跨模型迁移性。

跟同类方法的差异点：传统 agent 基准固定 harness 并评估模型在任务上的表现，HarnessDev 反转视角，评估模型构建和演化 harness 的能力，从而暴露执行基础设施本身对性能与效率的影响。

实验

实验设计

HarnessDev 基准包含 Creation 和 Evolution 两个阶段。Creation 从最小 seed harness 和少量 case 开始，构建完整执行系统；Evolution 从自建的 harness 开始，利用下游执行反馈迭代改进。评估在 capability（held-out benchmarks 任务成功率）和 efficiency（execution-token cost）两个维度。实验覆盖六个 creator LLMs、四个领域、五个下游基准，共 2207 个独特下游实例，并且隐藏评估任务与开发任务隔离。

关键发现

生成的 harness 在代码和搜索/研究领域显著落后于成熟的人工工程参考系统；而在写作和机器学习实验领域匹配或超过选定的参考系统，但执行成本变异很大。Evolution 带来一些性能增益，但不稳定，且仅部分转移到 held-out tasks。固定 runtime model 的实验表明，增益强烈依赖于执行 harness 的模型，表明跨模型迁移有限。

与基线对比

与人类工程参考系统对比，生成 harness 整体落后于成熟参考，但某些领域可媲美或超越。同时，演化过程不稳定，说明当前 LLM 自主发展基础设施的能力有限，且其收益受限于执行模型，提示设计通用 harness 仍需人工干预。

行业影响

落地场景

HarnessDev 的核心价值在于将 agent harness 本身作为可评估、可迭代的开发产物。对于依赖 LLM agent 执行复杂任务的产品（如自动化客服、代码助手、研究分析工具、电商运营自动化），该 benchmark 可直接用于评估和筛选基础模型搭建执行框架的能力。典型场景：

• 电商智能运营：让 agent 自动构建商品信息抓取、价格监控、竞品分析等执行流水线，无需人工编写外部工具调用逻辑。
• 内容平台自动生成管线：从素材采集到多模态内容生成的 agent harness 自动搭建，降低对固定工程模板的依赖。
• 企业级 RPA 与工作流自动化：利用 LLM 自行生成和演化与内部 API、数据库交互的执行器，减少定制开发。

商业价值

主要落在 降本与效率提升：传统 agent 部署需要工程师针对每个垂直场景设计 harness，HarnessDev 指向了一种 模型自举 的可能，可将基础设施开发成本从人天级压缩到 token 级。同时，执行成本（execution-token cost）作为评估维度，直接对应 API 调用费用，能帮助团队筛选高性价比的 harness 生成方案。不过当前结果显示生成 harness 在代码、搜索等领域的性能仍落后于人工参考实现，且跨模型迁移弱，意味着短期商业落地更可能用于 辅助生成初版 harness 或作为自动化测试的补充，而非完全替代人工。但长期看，随着模型能力提升，自演进 harness 有望成为 MLOps 中的标准组件，显著缩短 agent 产品迭代周期。

与现有产品/工作流的集成

HarnessDev 可嵌入现有的 agent 开发与评估流水线：

• 在 CI/CD 中增加 harness 质量关卡，对每次模型升级或提示词变更自动运行 HarnessDev 评测，避免回归。
• 与 LangChain、AutoGen、Semantic Kernel 等框架结合，将生成的 harness 导出为可复用的工具集或插件，通过统一接口（如 OpenAPI schema）接入现有编排系统。
• 利用 execution-token cost 指标与现有的成本监控平台（如 AWS Cost Explorer、Datadog）对接，实现 harness 效率的实时追踪。

具体用例：一家全球电商平台在部署智能客服 agent 时，先用 HarnessDev 让候选 LLM 基于少量示例自动生成与订单系统、物流 API 交互的 harness，再通过 held-out 任务集评估成功率和 token 成本，选择最优组合上线；后续每次模型迭代都可复用该流程，快速验证新模型对执行链路的适配性。

局限

• **评估维度单一**：论文主要用下游任务成功率和 `execution-token cost` 衡量 harness 质量，但忽略可维护性、可读性、安全性、调试难度等工程属性。Harness 作为生产基础设施，这些属性直接影响迭代效率与事故风险。作者在讨论中也承认这些方面未覆盖，导致评估结果难以直接指导实际部署选型。
• **实验设计依赖性强**：Creation 阶段从固定 `seed harness` 骨架和少量示例出发，不同 seed 设计可能导致生成结果差异巨大；论文未做 seed 敏感性分析。Evolution 仅使用下游执行反馈（错误信号），没有融入人工反馈或结构化 search 策略，导致性能提升不稳定、迁移性差。此外，隐藏评估任务与开发任务同域，无法验证跨域泛化能力。
• **对比基线不足**：仅与少量 human-engineered reference harnesses 比较，未系统对比现有 automated agent design / prompt optimization 系统（如 DSPy、ADAS 等）。另外，六个 creator LLMs 覆盖面有限，且 `execution-token cost` 不能完全反映真实 wall-clock 时间和资源成本。这些限制使得结论的外部效度受到制约。