当大语言模型被部署为可执行任务的智能体时，最终表现并不只由模型权重决定。围绕模型运行的提示词、工具调用、代码执行和反馈循环等基础设施，同样会改变任务结果。HarnessDev关注的正是这层常被称为 agent harness 的外部执行系统：模型能否自己搭建一套可运行的工具链，并根据实际执行反馈持续改进它。
从任务答案转向执行基础设施
现有智能体评测通常固定一套 harness，再报告模型在下游任务上的成功率。这样的结果能够反映某种配置下的能力，却较难回答另一个问题：模型是否具备设计和改造执行框架的能力。HarnessDev因此把评测单位从单个任务输出转向可运行的基础设施，并分为 Creation 和 Evolution 两个阶段。
在 Creation 阶段，智能体从一个最小种子和少量案例出发，构建完整执行系统；在 Evolution 阶段，它从自己创建的 harness 出发，依据下游执行反馈反复修改，目标是提升基准表现。每个构建出的 harness 都要同时接受能力和效率评估，前者看保留测试集上的任务成功情况，后者看执行过程消耗的 token 成本。这个设计使“能不能完成任务”和“完成任务要付出多少推理开销”被放在同一评价框架中。
Creation 结果揭示的差距
论文报告的 Creation 实验覆盖六个创作者 LLM、四个领域和五个下游基准，共包含 2,207 个独特的下游实例；隐藏评测任务不会在开发阶段提供给模型。结果显示，生成的 harness 在代码以及搜索与研究任务上，仍明显落后于成熟的人类工程参考实现；在写作和机器学习实验领域，则达到或超过了选定参考实现。不同 harness 之间的执行成本差异很大，说明任务成功率之外，工程结构和调用策略也会显著影响实际使用代价。
我的判断
HarnessDev的价值在于把“模型会不会使用工具”推进到“模型能不能设计工具使用系统”，为智能体研究增加了更贴近部署现实的评测维度。它尤其适合分析模型、提示词、工具编排和反馈机制之间的组合效果。但现有材料主要给出了 Creation 阶段的总体发现，Evolution 阶段的具体结果并不完整，因此还不能据此判断模型能否稳定、持续地优化自己的 harness。与此同时，参考实现的选择、不同领域的任务差异和执行 token 成本的解释方式，也会影响结论的可迁移性。