代理赋能框架的解剖

TLDR: Agent = Model + Harness。Harness 工程是我们围绕模型构建系统以将其转化为工作引擎的方式。模型包含智能，而 Harness 使这种智能变得有用。我们定义了什么是 Harness，并推导出了当今和未来 Agent 所需的核心组件。

何为“Harness”？

Agent = Model + Harness

如果你不是模型，你就是 Harness。

Harness 是除了模型本身之外的所有代码、配置和执行逻辑。一个原始模型并非一个 Agent。但当 Harness 赋予它状态、工具执行、反馈循环和可强制执行的约束时，它就成为了一个 Agent。

具体来说，Harness 包括：

• 系统提示词（System Prompts）
• 工具、技能、MCPs 及其描述
• 捆绑基础设施（文件系统、沙盒、浏览器）
• 编排逻辑（子 Agent 生成、交接、模型路由）
• 用于确定性执行的Hook/中间件（压缩、续写、代码检查）

在模型和 Harness 之间划分 Agent 系统的边界有许多复杂的方式。但在我看来，这是最清晰的定义，因为它迫使我们思考如何围绕模型智能设计系统。

本文的其余部分将探讨核心 Harness 组件，并从模型这一核心原语出发，推导出每个组件存在的理由。

从模型的角度看，为什么我们需要 Harness？

有些我们希望 Agent 完成的任务是模型本身无法直接做到的。这就是 Harness 发挥作用的地方。

模型（大多）接收文本、图像、音频、视频等数据，并输出文本。仅此而已。开箱即用，它们无法：

• 在交互过程中保持持久状态
• 执行代码
• 访问实时知识
• 设置环境并安装包以完成工作

这些都是 Harness 层面的功能。LLM 的结构需要某种机制来封装它们，以完成有用的工作。

例如，为了实现“聊天”这样的产品用户体验，我们将模型封装在一个 while 循环中，以跟踪之前的消息并追加新的用户消息。每个阅读本文的人都使用过这种 Harness。核心思想是，我们希望将期望的 Agent 行为转化为 Harness 中的实际功能。

从期望的 Agent 行为反推 Harness 工程

Harness 工程帮助人类注入有用的先验知识来指导 Agent 行为。随着模型能力越来越强，Harness 被用来精确地扩展和修正模型，以完成以前不可能完成的任务。

我们不会列出所有 Harness 功能的详尽清单。目标是从帮助模型完成有用工作的起点，推导出一组功能。我们将遵循以下模式：

我们想要的行为（或想要修正的行为）→ 帮助模型实现此行为的 Harness 设计。

文件系统：实现持久存储和上下文管理

我们希望 Agent 拥有持久存储，以便与真实数据交互、卸载不适合上下文的信息，并在会话之间持久化工作。

模型只能直接操作其上下文窗口内的知识。在文件系统出现之前，用户必须将内容直接复制/粘贴到模型中，这是一种笨拙的用户体验，并且不适用于自主 Agent。世界已经在使用文件系统来工作，因此模型自然而然地在数十亿个关于如何使用文件系统的 Token 上进行了训练。自然的解决方案是：

Harness 附带文件系统抽象和文件系统操作工具。

文件系统可以说是最基础的 Harness 原语，因为它解锁了以下功能：

• Agent 获得一个工作区来读取数据、代码和文档。
• 工作可以增量添加和卸载，而不是将所有内容保存在上下文中。Agent 可以存储中间输出并维护超出单个会话的状态。
• 文件系统是一个自然的协作界面。多个 Agent 和人类可以通过共享文件进行协调。Agent 团队等架构依赖于此。

Git 为文件系统添加了版本控制，因此 Agent 可以跟踪工作、回滚错误和分支实验。我们将在下文再次讨论文件系统，因为它被证明是我们需要其他功能的关键 Harness 原语。

Bash + 代码：通用工具

我们希望 Agent 能够自主解决问题，而无需人类预先设计每个工具。

当前主要的 Agent 执行模式是 ReAct 循环，其中模型进行推理，通过工具调用执行一个动作，观察结果，并在一个 while 循环中重复。但 Harness 只能执行它有逻辑的工具。与其强迫用户为每个可能的动作构建工具，更好的解决方案是给 Agent 一个像 Bash 这样的通用工具。

Harness 附带 Bash 工具，因此模型可以通过编写和执行代码自主解决问题。

Bash + 代码执行是让模型拥有计算机并让它们自主解决其余问题迈出的一大步。模型可以即时设计自己的工具，而不是受限于一组固定的预配置工具。

Harness 仍然附带其他工具，但代码执行已成为自主解决问题的默认通用策略。

沙盒和工具：执行与验证工作

Agent 需要一个具有正确默认值的环境，以便它们能够安全地行动、观察结果并取得进展。

我们已经赋予模型存储和执行代码的能力，但所有这些都需要在某个地方发生。在本地运行 Agent 生成的代码是有风险的，单个本地环境无法扩展到大型 Agent 工作负载。

沙盒为 Agent 提供了安全的操作环境。Harness 可以连接到沙盒来运行代码、检查文件、安装依赖项和完成任务，而不是在本地执行。这创建了安全、隔离的代码执行。为了更高的安全性，Harness 可以允许列表命令并强制执行网络隔离。沙盒还解锁了规模化，因为环境可以按需创建、分散到许多任务中，并在工作完成后销毁。

好的环境伴随着好的默认工具。Harness 负责配置工具，以便 Agent 能够完成有用的工作。这包括预安装语言运行时和包、用于 Git 和测试的 CLI、用于 Web 交互和验证的浏览器。

浏览器、日志、截图和测试运行器等工具为 Agent 提供了一种观察和分析其工作的方式。这有助于它们创建自我验证循环，在其中它们可以编写应用程序代码、运行测试、检查日志并修复错误。

模型本身并不会配置自己的执行环境。决定 Agent 在哪里运行、有哪些工具可用、它可以访问什么以及如何验证其工作，这些都是 Harness 层面的设计决策。

记忆与搜索：持续学习

Agent 应该记住它们所看到的内容，并访问在它们训练时不存在的信息。

模型除了其权重和当前上下文中的内容之外，没有额外的知识。在无法编辑模型权重的情况下，“添加知识”的唯一方法是通过上下文注入。

对于记忆，文件系统再次成为核心原语。Harness 支持像 AGENTS.md 这样的记忆文件标准，这些文件在 Agent 启动时被注入到上下文中。当 Agent 添加和编辑此文件时，Harness 会将更新后的文件加载到上下文中。这是一种持续学习的形式，Agent 将一个会话中的知识持久存储并注入到未来的会话中。

知识截止日期意味着模型无法直接访问新数据，例如更新的库版本，除非用户直接提供。对于最新知识，Web 搜索和像 Context7 这样的 MCP 工具帮助 Agent 访问超出知识截止日期之外的信息，例如新的库版本或在训练停止时不存在的当前数据。

Web 搜索和查询最新上下文的工具是嵌入到 Harness 中的有用原语。

应对上下文腐烂（Context Rot）

Agent 的性能不应在工作过程中下降。上下文腐烂（Context Rot）描述了模型随着上下文窗口的填满，在推理和完成任务方面的能力下降。上下文是一种宝贵且稀缺的资源，因此 Harness 需要管理它的策略。

今天的 Harness 在很大程度上是良好上下文工程的交付机制。

压缩（Compaction）

压缩解决了当上下文窗口即将填满时该怎么办的问题。如果没有压缩，当对话超出上下文窗口时会发生什么？一种选择是 API 报错，这不好。Harness 必须为此情况使用某种策略。因此，压缩会智能地卸载和总结现有的上下文窗口，以便 Agent 可以继续工作。

工具调用卸载（Tool Call Offloading）

工具调用卸载有助于减少大型工具输出的影响，这些输出可能会嘈杂地占用上下文窗口，而没有提供有用的信息。Harness 会保留超过阈值 Token 数量的工具输出的开头和结尾 Token，并将完整输出卸载到文件系统，以便模型在需要时可以访问它。

技能（Skills）

技能解决了在 Agent 启动时加载过多工具或 MCP 服务器到上下文中的问题，这会在 Agent 开始工作之前降低性能。技能是一种 Harness 级别的原语，它通过渐进式披露来解决这个问题。模型没有选择在启动时将技能前置信息加载到上下文中，但 Harness 可以支持这一点，以保护模型免受上下文腐烂的影响。

长周期自主执行

我们希望 Agent 能够自主、正确地在长周期内完成复杂的工作。

自主软件创建是编码 Agent 的圣杯。但今天的模型存在过早停止、分解复杂问题困难以及在跨多个上下文窗口工作时缺乏连贯性等问题。一个好的 Harness 必须围绕所有这些问题进行设计。

这就是早期 Harness 原语开始复合的地方。长周期工作需要持久状态、规划、观察和验证，以在多个上下文窗口中持续工作。

文件系统和 Git 用于跟踪工作

文件系统和 Git 用于跟踪跨会话的工作。Agent 在长时间任务中会产生数百万个 Token，因此文件系统持久地捕获工作以跟踪随时间推移的进度。添加 Git 允许新的 Agent 快速了解项目的最新工作和历史记录。对于多个 Agent 协同工作，文件系统也充当共享的工作账本，Agent 可以在其中协作。

Ralph 循环用于持续工作

Ralph 循环是一种 Harness 模式，它通过Hook拦截模型的退出尝试，并在一个干净的上下文窗口中重新注入原始提示，强制 Agent 根据完成目标继续其工作。文件系统使这成为可能，因为每次迭代都以新鲜的上下文开始，但从前一次迭代中读取状态。

规划和自我验证

规划和自我验证以保持正轨。规划是模型将目标分解为一系列步骤的过程。Harness 通过良好的提示和注入提醒如何在文件系统中使用计划文件来支持这一点。在完成每个步骤后，Agent 通过自我验证来检查其工作的正确性。Harness 中的Hook可以运行预定义的测试套件，并在失败时将错误消息反馈给模型，或者可以提示模型独立地自我评估其代码。验证将解决方案建立在测试中，并为自我改进创建反馈信号。

Harness 的未来

模型训练与 Harness 设计的耦合

今天的 Agent 产品，如 Claude Code 和 Codex，都是在模型和 Harness 循环中进行后期训练的。这有助于模型改进 Harness 设计者认为它们应该天生擅长的操作，例如文件系统操作、Bash 执行、规划或使用子 Agent 并行化工作。

这形成了一个反馈循环。有用的原语被发现，添加到 Harness 中，然后用于训练下一代模型。随着这个循环的重复，模型在它们所训练的 Harness 中变得更加强大。

但这种共同演化对泛化能力产生了有趣的副作用。它体现在诸如更改工具逻辑导致模型性能下降等方面。一个很好的例子在 Codex-5.3 提示指南中描述了 apply_patch 工具逻辑用于编辑文件。一个真正智能的模型在不同补丁方法之间切换应该没有太大问题，但在循环中进行 Harness 训练会造成这种过拟合。

但这并不意味着最适合你任务的 Harness 就是模型经过后期训练的那个。Terminal Bench 2.0 排行榜就是一个很好的例子。Claude Code 中的 Opus 4.6 在其他 Harness 中的得分远低于 Opus 4.6。在之前的一篇博客中，我们展示了如何通过仅更改 Harness，将我们的编码 Agent Top 30 提升到 Terminal Bench 2.0 的 Top 5。通过优化 Harness 来完成你的任务，还有很大的提升空间。

Harness 工程的发展方向

随着模型能力越来越强，今天 Harness 中的一些功能将被模型吸收。模型将更好地进行规划、自我验证和长周期连贯性，从而减少上下文注入的需求。

这表明 Harness 的重要性会随着时间的推移而降低。但就像提示工程今天仍然有价值一样，Harness 工程很可能仍然对构建好的 Agent 有用。

诚然，今天的 Harness 弥补了模型的不足，但它们也围绕模型智能设计系统，使其更有效。一个配置良好的环境、正确的工具、持久状态和验证循环，无论其基础智能如何，都能使任何模型更高效。

Harness 工程是一个非常活跃的研究领域，我们用它来改进我们在 LangChain 的 Harness 构建库 deepagents。以下是我们今天正在探索的一些开放且有趣的问题：

• 协调数百个 Agent 在共享代码库上并行工作
• Agent 分析自己的轨迹以识别和修复 Harness 级别的故障模式
• Harness 动态地为给定任务即时组装正确的工具和上下文，而不是预先配置

这篇博客旨在定义 Harness 是什么，以及它如何受我们希望模型完成的工作的影响。

模型包含智能，而 Harness 是使这种智能有用的系统。

致敬更多的 Harness 构建，更好的系统，以及更好的 Agent。

• 原文链接： x.com/Vtrivedy10/status/...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～