过去，LLM Agent   的研究更多关注模型能力本身，例如推理、规划、工具使用、记忆和多 Agent 协作；如今，随着模型能力提升，任务执行的可靠性越来越依赖 harness 工程。

近日，来自卡内基梅隆大学、耶鲁大学、杜兰大学、阿拉巴马大学伯明翰分校、亚马逊的研究团队及其合作者，发表了一篇 Harness 工程综述，对 Harness 工程进行了系统梳理。研究团队提到，在不改模型权重的情况下，仅调整 harness 层本身，也可能显著改变 Agent 在 coding 和 terminal benchmark 上的表现。

论文链接：https://picrew.github.io/LLM-Harness/main.pdf

项目主页：https://picrew.github.io/LLM-Harness/

围绕这一判断，研究团队将 2022 到 2026 年的工程重心变化概括为三个阶段：从提示工程，到上下文工程，再到   harness 工程，并提出了 ETCLOVG 七层分类体系。与已有框架相比，这一体系将 " 可观测性 " 和 " 治理 " 作为独立的架构层看待。

此外，他们对 170 多个公开条目进行了系统映射，总结了目前 Agent 基础设施生态中的分布特征、覆盖空白和新出现的设计方向。同时，他们也总结了 OpenAI、Anthropic 和 LangChain 在生产部署中的工程经验，以帮助读者更具体地理解 Harness 工程。

图｜2022 年至 2026 年代表性 Agent-harness 系统时间线。

如何理解 Harness 工程？

研究团队对 Harness 工程作了更明确的范围界定：它并非泛指与大语言模型相关的所有外围系统，而是指模型外层的工程化运行框架。它通过执行环境、工具接口、上下文控制、任务编排、可观测性、评估反馈和治理机制，将模型调用组织成可执行、可控制、可追踪的任务流程。

围绕这一定义，研究团队将 2022 到 2026 年的 harness 演进概括为三个阶段：

2022-2024 年：提示工程（prompt engineering）阶段，重点是优化单次模型调用的输入。

2025 年：上下文工程（context engineering）阶段，重点不再只是如何写提示词，而是每一步该向模型提供什么上下文，因此重心也转向了上下文管理。

2026 年：harness 工程阶段，随着 Agent 开始处理长链条、多步任务，可靠性越来越取决于模型外层的基础设施，即状态管理、工具协调、反馈注入、约束施加和进展验证。

图｜提示工程、上下文工程与 harness 工程的简要对比。

在此基础上，研究团队提出了   ETCLOVG 七层分类，包括执行环境与沙箱（Execution Environment & Sandbox）、工具接口与协议（Tool Interface & Protocol）、上下文管理（Context Management）、生命周期与编排（Lifecycle and Orchestration）、可观测性（Observability）、验证（Verification）和治理（Governance）。其中，前四层构成了 harness 的结构核心，后三层则对应围绕这一核心的控制平面。

具体来看，ETCLOVG 七层分别对应：

执行环境：决定 Agent 代码在哪里运行、受到什么约束。

工具接口与协议：定义外部能力如何被描述、发现和调用。

上下文管理：决定模型在短期、会话级和持久化层面能看到什么。

生命周期与编排：负责组织这些状态的读写控制流，覆盖从单 Agent 循环、多 Agent 协作到从 issue 到 pull request 的工作流。

可观测性：负责捕获轨迹、成本、失败和可靠性信号。

验证：负责把任务和轨迹转化为评估、失败归因和回归反馈。

治理：这一层主要通过权限、身份、策略、安全加固、审计和人工监督来约束系统行为。

图｜基于 LLM 的 Agent 系统中 harness engineering 分类体系示意图

Harness 工程的开源生态

这篇综述的实证部分对公开可见的 harness 生态进行系统映射。研究团队核验的技术目录共包含 171 个公开条目，其中 146 个来自 GitHub，142 个 GitHub 项目被纳入分层统计。

按主层归类看，生命周期与编排类项目最多，其次是验证、执行环境与沙箱。相比之下，可观测性与治理相关项目较少；上下文与记忆相关能力往往内嵌在大型框架中，很少作为独立的 harness 组件发布。基于这份映射，研究团队指出，较完整的 harness 系统正呈现跨层集成趋势，即在同一套系统中同时结合沙箱、工具协议、编排、追踪、评估和权限控制。

图｜技术生态精选目录

Harness 工程的落地经验

除了对开源生态的系统映射，研究团队还梳理了   OpenAI、Anthropic 和 LangChain   在生产部署中的一些共通经验。具体如下：

OpenAI 将 harness engineering 明确表述为围绕   Codex agents   设计环境、约束、文档和反馈回路的工程工作；

Anthropic 强调，Agent 应采用简单、可检查的架构；工具接口应为 Agent 而设计，而不是直接沿用给人用的 API；上下文应随着任务推进逐步提供，而不是一开始就全部交给模型；对于长时间运行的工作，还需要可恢复的执行基础设施和清晰的交接产物。

LangChain 的实践则更强调深度 Agent 的评测方法：需要根据具体任务编写测试逻辑，结合单步、完整回合和多轮评测，并为每次评测提供可重置、可复现的环境。

研究团队进一步结合 LangChain 与 Anthropic 的实践指出，评测与可观测性不应彼此割裂，而应被视为同一反馈回路的一部分。

不足和未来方向

尽管该综述对公开可见的 harness 生态进行了较为全面的梳理，研究团队也指出了目前研究的不足与未来方向。具体如下：

研究团队指出，这篇综述所依据的是公开可见的样本，不是对全部生产系统的完整盘点。闭源系统因缺少公开信息，在样本中明显不足；相比之下，代码 Agent 相关基础设施更容易留下仓库、benchmark、sandbox 和工作流等公开痕迹，因此也更容易被纳入这份映射，这也意味着非代码类 Agent 生态在当前样本中呈现得还不够充分。研究团队同时强调，分类依据是公开证据是否充分，而不是系统内部是否真实具备相应能力。

此外，研究团队也提出了几个后续值得关注的方向：如何提升执行环境的安全性、可扩展性和可迁移性；如何让长时间运行的 Agent 在多轮执行中保持可靠状态；系统发生故障后，如何基于执行轨迹更准确地定位原因；以及如何在 Agent、工具和人之间建立更标准化的交接机制。

目前，ETCLOVG 主要还是一套用于描述和整理现象的框架。研究团队指出，随着模型能力持续变化，哪些 harness 机制仍然必要，哪些需要重新评估、简化，甚至移除，也是后续必须面对的问题。未来，更重要的是让 ETCLOVG 框架不只停留在描述和整理现象，进一步发展成能够指导 harness 设计决策的框架。

更多技术细节，详见原论文。

作者：夏千斯

如需转载或投稿，请直接在本文章评论区内留言