HarnessDev：LLM 构建自身的底层架构

字节跳动 (ByteDance) 与多家高校联合推出了 HarnessDev，这是一个允许大语言模型 (LLM) 编写其专属“智能体操作系统”（称为 Agent Harnesses）的框架。研究团队为 LLM 提供了一个精简的入门套件，并让其自行完善其余部分，展示了 AI 如何在无需人类逐行编写代码的情况下，构建出能够运行自身工具调用循环、验证步骤和错误处理的控制层。

为什么自建 Harness 至关重要

AI 智能体 (AI agents) 已从单一提示词助手演变为能够调用 API、查询数据库并整合结果的多步执行者。在此之前，开发者需要手动编写编排代码 (orchestration code)，以告知模型何时调用搜索工具、如何存储中间状态以及如何验证最终答案。HarnessDev 颠覆了这一模式：通过一个 seed harness 提供必要的脚手架——包括循环、工具选择和状态跟踪的基本功能——然后由 LLM 将其扩展为一个功能完备的运行时 (runtime)。

在论文的基准测试中，该模型生成了 18 个不同的 Harness，在原始种子代码的基础上增加了超过 17,000 行代码。每个 Harness 都能管理任务的全生命周期：执行循环、选择合适的工具、维持上下文、跟踪状态、验证结果以及从错误中恢复。

研究揭示的隐藏成本

数据看起来很惊人，但作者警告称，单纯的代码实现并不等同于实际应用。

  • 未使用的组件 – 生成的代码中有相当大的一部分在实际任务执行期间从未运行。LLM 编写了一些智能体从未调用的函数，导致代码库膨胀却未能提供实际价值。
  • 模型锁定 – Harness 往往会针对创建它的特定 LLM 进行微调。当将同一个 Harness 交给不同的模型时，性能会明显下降，这表明自动生成的控制逻辑中嵌入了特定模型的特性。
  • 验证漏洞 – 一个测试 Harness 报告的成功率为 99%（100 次运行中有 99 次成功），但其正确率仅为 48%。如果没有强大的验证机制，智能体可能会自信地给出错误答案。
  • Token 开销 – Token 使用量（计算成本的代理指标）波动巨大。为了达到相同的效果，一个 Harness 所需的 Token 量竟然是另一个的 七倍，这引发了人们对生产环境下可扩展性的担忧。

这些发现强调了即使代码是由 LLM 生成的，也需要进行严谨的设计。

开发者应注意的事项

  1. 将 Harness 设计视为架构设计 – 不要指望模型能“直接搞定”。在让 LLM 填充内容之前，应先为循环控制、工具选择、状态处理和验证定义清晰的模块。
  2. 构建强大的验证机制 – 插入显式检查，将智能体的结论与标准答案 (ground truth) 或第二个模型进行对比。研究中提到的“99% 自报成功率但仅有 48% 准确率”的情况表明，验证绝不能是事后才考虑的事情。
  3. 关注 Token 预算 – 更复杂的 Harness 可能会导致 Token 数量激增。应尽早对不同的 Harness 变体进行性能分析 (profile)，以避免隐藏的成本爆炸。
  4. 进行跨模型测试 – 使用多个 LLM 后端运行同一个 Harness。如果性能大幅下降，你可能需要更具模型无关性 (model-agnostic) 的设计，或者为每个模型准备独立的 Harness。

核心结论： HarnessDev 证明了 LLM 能够起草类似于操作系统的控制代码。