Command Palette
Search for a command to run...
何为 Harness:智能体 Harness 的必要与充分条件
何为 Harness:智能体 Harness 的必要与充分条件
Sanderson Oliveira de Macedo
摘要
随着生成式人工智能在软件工程中的广泛应用,“智能体 harness”这一术语已广为流传。它指代包裹语言模型并将其转变为能够对代码仓库执行操作的编码智能体的那一层。该术语的使用较为松散且存在多义性:有时指代整个产品(如 Claude Code、Codex CLI),有时指代针对任务运行智能体的评估脚手架(如 SWE-bench harness),有时又与智能体框架、SDK、IDE 插件或编排器混为一谈。目前缺少一个可作为工具使用的参考定义,即能够一致地包含和排除具体案例的定义。我们通过一项概念分析来构建这一定义,该分析结合了具有持久标识符的著作与一手灰色文献资料,如官方文档、术语表和工程报告。我们重构了该术语的谱系:从马具到经典的测试 harness,再到机器学习评估 harness,最终到智能体 harness。随后,我们提出了一个构成性定义,阐明了一个系统成为智能体 harness 的必要且充分条件,将其操作化为一个包含与排除测试,并划定了该概念与智能体框架、智能体 SDK、IDE 插件、评估 harness 及编排器的边界。我们将此定义应用于六个真实的 harness(Claude Code、Codex CLI、Aider、Cline、OpenHands 和 SWE-agent)以及精心设计的边缘案例;该测试能够一致地进行包含与排除。最后,我们以设计张力轴为框架,提出了一个研究议程。本文的贡献在于提供了一个可操作的智能体 harness 定义及共享词汇,能够指导工程实践和对智能体系统的科学比较。
一句话总结
戈亚斯联邦研究所的研究人员通过对agent harness进行概念分析,推导出充分必要条件,并将其操作化为包含与排除测试,通过验证六个实际编码agent系统(Claude Code、Codex CLI、Aider、Cline、OpenHands和SWE-agent)来建立共享词汇,以指导工程实践和比较评估。
核心贡献
- 从马具、测试harness到评估harness,重构了术语“agent harness”的谱系,确立了独特的agentic意义源于在运行时执行而不仅是执行后进行控制的机制。
- 基于四个充分必要条件提出构成性定义:agent循环、工具接口、上下文管理和控制机制;将其操作化为包含与排除测试,以区分agent harness与相邻概念,如agent框架、SDK和编排器。
- 将该定义应用于六个实际系统(Claude Code、Codex CLI、Aider、Cline、OpenHands、SWE-agent)以及有意选取的边缘案例,展示了分类一致性,并沿四个设计张力轴推导出研究议程。
引言
大语言模型已从文本生成器演变为能够推理、调用工具并在代码库上执行操作的agent,这催生了对周围基础设施的需求,以将模型与任务绑定并控制其执行。在实践中,这类基础设施通常被称为harness,但该术语的使用并不一致,可指代评估套件、编排层甚至整个产品,使得系统比较、设计优点归因或构建可信agent变得困难。作者通过构建一个精确的、可操作的agent harness定义来填补这一空白:一个满足四个构成性条件(agent循环、工具接口、上下文管理和控制机制)的系统,并将该定义转化为可复现的包含/排除测试,以区分harness与相邻概念,如agent框架、SDK和评估harness。
方法
作者将agent harness定义为运行时工程层,它包装一个或多个语言模型,将其转换为能够在外部环境中完成任务的agent。该定义基于四个必要条件而非具体示例建立。当且仅当一个系统在运行时实例化这四个要素,在任务执行期间发挥作用,而非仅在事后进行评估时,该系统才符合agent harness的条件。
如下图所示:
agent harness的解剖结构将模型置于中心,作为引擎。周围是使引擎可驾驶所需的组件。四个核心要素是绝对必要的。首先,agent循环将推理、行动和观察交织在一起。没有此循环,系统仅作为生成器而非agent运行。其次,工具接口允许模型感知并改变外部环境,例如编辑文件或运行命令。第三,上下文管理根据任务内容主动决定哪些信息进入和离开模型的上下文窗口,防止信息稀释。第四,控制机制提供限制、验证和确定性操作,以确保执行可信且受控,独立于模型的合作。
除了这些核心要求之外,架构还包括增强鲁棒性的可选限定符。这些包括跨步骤存活的记忆、确认任务完成的验证器、针对瞬态故障的带最终模型切换的重试逻辑、用于审计的可观测性、用于安全限制的护栏,以及用于敏感操作的确定性处理器。这些限定符是核心要素的专门化,而非新的基本要求。
虽然核心定义统一了概念,但具体实现因设计选择与现实张力而产生分歧。作者沿四个设计轴组织这些分歧,以描绘研究空间。
如下图所示:
第一个轴对比自主性与控制,平衡agent的独立决策与安全监督。第二个轴跨越广泛上下文与精选上下文,权衡主动选择相关信息的成本与在长上下文中稀释有用数据的风险。第三个轴区分通用harness与专用harness,探讨有效的控制机制是可跨领域复用还是必须定制。第四个轴从开放权限到受控环境,比较在用户权限下运行的agent与在受限沙箱中运行的agent。这些轴表明,尽管agent harness的概念是单一的,但其设计空间广阔,并由这些基本权衡所塑造。
实验
评估将包含与排除测试应用于六个实际harness,确认所有系统都满足核心要素,同时正确排除了内联自动补全和固定流水线等缺乏自适应循环或控制的系统。对这些harness的设计轴分析表明,控制是最具区分度的维度,也是一个重要的开放研究前沿,同时揭示出harness本身而非底层模型可能成为关键的工程因素。该研究强调了评估方法需要将harness的贡献与模型性能分离开来。
术语harness已从离线测试和评估脚本演变为一个运行时层,它主动控制、限制、验证和纠正agent执行。这种从观察到执行期间干预的转变,使受控环境与控制成为最具区分度的设计方面,并开启了一个方法论缺口:当前的评估衡量的是模型-harness组合的整体性能,而没有分离出harness自身的贡献。agent工程意义上的harness在运行时运行,不同于之前两种仅从外部观察的意义。将模型与harness分离,使得模型切换可以成为一种控制机制,减少应用对单一大型模型的依赖。
一个agent harness的定义是满足四个运行时条件:推理-行动-观察循环、与环境的工具接口、主动上下文管理,以及至少一个独立于模型的控制机制。不满足任何条件都会将系统归入一个独特的相邻类别,例如固定流水线、孤立模型、朴素包装或不可信演示。控制条件尤为具有区分性,该定义允许将harness的贡献与模型的贡献分离开来。如果没有推理、行动和观察的运行时循环,系统就是一个单次生成器或固定流水线,而非agent。如果没有独立控制机制,该系统就是一个信任模型输出的演示,缺乏保证。
agent harness是唯一满足全部四个标准的概念:运行时的闭环、对外部环境的作用、上下文与验证,以及控制。每个相邻概念至少缺少运行时循环和控制,同时在是否提供工具、作用于环境或适应观察方面存在差异。这一区别揭示了harness是一个独特的层,它组装并运行一个受控agent,而框架、SDK、插件、评估harness和编排器在agent生态系统中各自扮演不同角色。harness通过了全部四项测试(T1–T4),而所有五个相邻概念至少未通过T1和T4。agent框架组合agent,但自身不执行循环或控制;它们依赖内嵌的harness。IDE插件缺少循环且不作用于代码仓库,不形成闭环且不提供控制。评估harness和编排器提供工具(T2),但缺少自适应、观察驱动的循环(T1和T3)。agent SDK提供构建块,但不组装运行时循环,是原材料而非成品。
所有六个实际系统均针对agent harness的四个核心要素(T1–T4)进行了评估,且每个系统都满足,确认它们都是agent harness。控制(T4)的形式是最多样化的要素,其机制包括运行时护栏、人工批准、沙箱执行和版本控制可审计性等。这种多样性使控制成为主要的设计区分因素,也是文献中明显开放的领域。六个系统均满足T1(agent循环)、T2(文件和shell工具)、T3(上下文管理)和T4(控制),确认它们是agent harness。控制要素(T4)显示出最大的多样性,包括运行时护栏、权限模式、版本控制可审计性、人工批准、沙箱和结构化动作接口等独特机制。控制(T4)是最具区分度的设计特征,也是正式文献中最不巩固的领域。
该分析将agent harness定义为一个运行时层,必须满足四个条件:推理-行动-观察循环、工具接口、主动上下文管理,以及至少一个独立的控制机制,缺少任何条件都会将系统归入独特的相邻类别(例如,固定流水线、朴素包装)。通过根据这些标准评估六个实际编码agent系统,该工作确认所有系统均为harness,其中控制维度展现出最大的多样性——涵盖护栏、沙箱、人工批准和审计跟踪——并成为最具区分度的设计特征。这种模型与harness的分离还使模型切换成为一种控制机制,减少应用对单一大型模型的依赖。