Agent 系统的性能越来越依赖 Harness，但这些逻辑通常藏在代码里、框架默认设置里，或者特定运行时的各种约定里。结果就是很难把一个 Harness 移植到另一个系统、拿来比较，或者系统性地研究改进
作者提出把 Harness 的高层控制逻辑从代码中抽出来，用自然语言写成一个可编辑、可移植的文档，叫Natural-Language Agent Harnesses (NLAH)。然后设计一个共享的运行时Intelligent Harness Runtime (IHR)，让 LLM 直接读懂这个自然语言描述，并按照里面的规则去执行任务
方法
本文认为 Harness 是管理任务族的多个模型或智能体的一个模式层，其指定：控制（如何分解和安排工作）；契约（必须生产哪些工件、满足哪些条件、何时停止运行）；说明（每个步骤和分支坚持的内容）
(1) NLAH
与 OpenAI 的报告一样，NLAH 是有明确结构的自然语言文档，通常放在类似 harness-skill/SKILL.md 的文件里。具体而言，其包含以下部分：
Contracts：定义输入输出格式、验证规则、停止条件、重试次数。比如 "必须输出有效的 Python 代码文件 solution.py，否则重新生成"
Roles：给不同子代理分配职责和 prompt，比如 Planner 负责出计划，Solver 负责写代码，Verifier 负责跑测试，Debugger 负责修复
Stage Structure：描述工作流拓扑，比如 "先 PLAN → 再 EXECUTE → 然后 VERIFY → 失败就进入 REPAIR，最多重试 3 次"
Adapters/Scripts：命名一些确定性的钩子，比如跑测试的脚本、解析输出的工具
State Semantics：说明状态怎么持久化（推荐用文件），比如通过路径重新打开 artifact
Failure Taxonomy：给常见失败起名字并定义处理方式，比如 "test_failure" 就跳到 REPAIR 阶段，"tool_error" 就重试一次
(2) IHR
具体而言，IHR是个共享运行时，里面有个 "in-loop LLM" 负责不停解读 NLAH、当前状态和一个叫Runtime Charter（运行时宪章）的共享规则
它把任务拆成父子代理：父代理轻量级，只管调度；子代理干实际活
状态用文件持久化，放在固定路径下，便于重启和审计
每次行动前都会检查 contracts，失败就按 taxonomy 处理
关键是把运行时通用规则 和 具体任务 harness分开，避免污染
实验
可以看到 Harness 显著改变了行为（工具调用、LLM 调用、运行时间），但 Performance 变化不大；此外，不是所有模块都有用，有些模块（如 verifier）因为 overhead，在小样本上反而没明显提升甚至略降
总结
这篇工作更像是一次显式化 Harness 的初步探索，利用自然语言形态的 Harness 可以增加可解释性和可迁移能力，让 Harness 成功抽象出来。但在小样本实验下，NLAH 虽然显著影响了智能体的运行逻辑，成功率并无显著提升。由于预算有限，作者说后续会在大规模实验来继续探究
