Agent Harness 的构造解析
翻译自 langchain blog
2026 年 3 月 10 日
原文：www.langchain.com/blog/the-an...
核心要点
拆解复杂目标： 规划工具让 Agent 能够拆解任务、跟踪进度，并随着学习不断调整。
并行委派工作： 为相互独立的子任务创建 Subagent（子 Agent），每个子 Agent 都拥有隔离的上下文。
简要总结： Agent = Model + Harness。Harness Engineering（Harness 工程）是围绕模型构建系统，将模型转变为工作引擎的方法。模型承载智能，而 Harness 让这种智能真正变得有用。本文将定义什么是 Harness，并从这一基础出发，推导出当今以及未来 Agent 所需要的核心组件。
能否先定义一下什么是"Harness"？
Agent = Model + Harness
If you're not the model, you're the harness.
如果你不是模型本身，那么你就是 Harness。
Harness 是除模型本身之外的所有代码、配置以及执行逻辑。一个原始模型本身并不是 Agent；但当 Harness 为它提供状态、工具执行、反馈循环以及可强制执行的约束等能力之后，它就成为了 Agent。
具体来说，一个 Harness 包括：
- 系统提示词（System Prompts）
- 工具（Tools）、Skills、MCP，以及它们的描述信息
- 配套基础设施（文件系统、Sandbox、浏览器）
- 编排逻辑（创建 Subagent、任务交接、模型路由）
- 用于实现确定性执行的 Hooks / Middleware（例如上下文压缩、任务续接、Lint 检查）
在 Agent 系统中，模型和 Harness 之间的边界可以有很多种复杂而混乱的划分方式。但在我看来，上述定义是最清晰的，因为它迫使我们思考一个核心问题：围绕模型的智能来设计系统。
本文接下来将逐一介绍 Harness 的核心组件，并从模型这一核心原语出发，反向推导出：为什么每一个组件都是必要的。
为什么需要 Harness？------从模型的视角来看
有些我们希望 Agent 完成的事情，模型本身无法开箱即用地完成。这正是 Harness 发挥作用的地方。
模型（主要）接收文本、图像、音频、视频等数据，然后输出文本。仅此而已。开箱即用的模型无法：
- 在多次交互之间维护持久状态
- 执行代码
- 获取实时知识
- 配置环境并安装完成任务所需的软件包
这些全部都是 Harness 层面的功能。LLM 的结构决定了它需要某种外围机制进行封装，才能真正完成有用的工作。
例如，为了实现"聊天"这样的产品体验，我们会将模型放进一个 while 循环中，用它来跟踪之前的消息，并不断追加新的用户消息。所有读到这里的人其实都已经使用过这种 Harness。
核心思想是：我们希望将某种期望的 Agent 行为，转化为 Harness 中真正可执行的功能。
从期望的 Agent 行为反向推导 Harness Engineering
Harness Engineering 帮助人类向系统中注入有用的先验，从而引导 Agent 的行为。随着模型能力越来越强，Harness 也开始被用于更加精细地扩展和纠正模型，使其能够完成过去无法完成的任务。
我们不会列举 Harness 的所有功能。本文的目标，是从"帮助模型完成有用工作"这一出发点，推导出一组核心功能。我们会遵循这样的模式：
我们希望实现（或修正）的行为 → 帮助模型实现这一行为的 Harness 设计。
用于持久化存储和上下文管理的文件系统
我们希望 Agent 拥有持久化存储能力，以便与真实数据交互，将无法放入上下文的信息卸载出去，并让工作成果跨 Session 持久保存。
模型只能直接操作其上下文窗口中的知识。在文件系统出现于 Agent Harness 之前，用户必须把内容直接复制粘贴给模型。这种用户体验非常笨拙，而且无法很好地支持自主 Agent。
现实世界本来就已经广泛使用文件系统来完成工作，因此模型也自然地在数十亿 Token 的相关数据上接受了训练，学习如何使用文件系统。
于是，一个自然的解决方案出现了：
Harness 自带文件系统抽象以及用于文件系统操作（fs-ops）的工具。
文件系统可以说是最基础的 Harness 原语，因为它解锁了大量能力：
- Agent 获得一个工作空间，可以读取数据、代码和文档。
- 工作可以逐步添加和卸载，而不需要把所有内容一直保存在上下文中。Agent 可以存储中间输出，并维护超越单个 Session 生命周期的状态。
- 文件系统是一个天然的协作界面。 多个 Agent 和人类可以通过共享文件进行协调。诸如 Agent Teams 这样的架构就依赖这一点。
Git 为文件系统增加了版本控制能力，使 Agent 可以跟踪工作、回滚错误以及创建实验分支。下面我们还会再次讨论文件系统，因为事实证明，它也是其他许多所需 Harness 功能的关键基础原语。
Bash + Code：通用工具
We want agents to autonomously solve problems without humans needing to pre-design every tool.
我们希望 Agent 能够自主解决问题，而不需要人类事先为每一种可能的操作设计一个工具。
如今 Agent 的主要执行模式是 ReAct loop（ReAct 循环） ：模型进行推理，通过工具调用采取行动，观察结果，然后在 while 循环中不断重复这一过程。
但 Harness 只能执行那些已经拥有对应执行逻辑的工具。与其强迫用户为每一种可能的操作都构建一个工具，不如给 Agent 一个像 Bash 这样的通用工具。
Harness 提供 Bash 工具，使模型能够通过编写和执行代码来自主解决问题。
Bash + 代码执行是朝着 "给模型一台计算机" 迈出的重要一步，并让模型能够自主解决剩下的问题。
模型可以通过代码即时设计自己的工具，而不再被限制在一组预先配置好的固定工具之中。
Harness 仍然会提供其他工具，但代码执行已经成为自主解决问题时默认的通用策略。
Sandbox 与用于执行和验证工作的工具
Agents need an environment with the right defaults so they can safely act, observe results, and make progress.
Agent 需要一个具有合理默认配置的环境，以便安全地采取行动、观察结果并持续推进工作。
我们已经为模型提供了存储能力和代码执行能力，但这些操作总得发生在某个地方。
直接在本地运行 Agent 生成的代码存在风险，而单一的本地环境也无法扩展到大规模的 Agent 工作负载。
Sandbox 为 Agent 提供安全的运行环境。
Harness 不必在本地执行代码，而是可以连接到 Sandbox，在其中运行代码、检查文件、安装依赖并完成任务。这为代码执行提供了安全、隔离的环境。
为了进一步提高安全性，Harness 可以对允许执行的命令进行 Allowlist（允许列表）控制，并实施网络隔离。
Sandbox 同时也带来了扩展能力，因为环境可以按需创建，可以针对大量任务同时展开，并在工作完成后销毁。
优秀的运行环境应该配备良好的默认工具。
Harness 负责配置各种工具，让 Agent 能够真正完成有用的工作。这包括预先安装语言运行时和软件包、用于 Git 和测试的 CLI，以及用于网页交互和验证的浏览器。
浏览器、日志、截图和测试运行器等工具，为 Agent 提供了观察和分析自己工作的方式。
这帮助 Agent 建立自我验证循环（self-verification loop） ：它们可以编写应用代码、运行测试、检查日志，然后修复错误。
模型本身并不会开箱即用地配置自己的执行环境。
决定 Agent 在哪里运行、有哪些工具可用、可以访问什么资源，以及如何验证自己的工作，这些全部都是 Harness 层面的设计决策。
用于持续学习的 Memory 与 Search
Agent 应该记住自己曾经见过的内容，并能够访问那些在模型训练时尚不存在的信息。
除了模型权重以及当前上下文中的内容之外，模型没有其他额外知识。
如果无法修改模型权重，那么唯一能够"增加知识"的方式就是通过上下文注入（context injection） 。
对于 Memory 来说，文件系统再次成为核心原语。
Harness 支持诸如 AGENTS.md 这样的 Memory 文件规范，并在 Agent 启动时将其注入上下文。
随着 Agent 添加和编辑这个文件，Harness 会将更新后的文件重新加载到上下文中。
这是一种 continual learning（持续学习） 的形式：Agent 将某个 Session 中获得的知识持久保存下来，并在未来的 Session 中重新注入这些知识。
知识截止时间意味着，如果没有用户直接提供信息，模型无法直接获取诸如最新软件库版本之类的新数据。
为了获得最新知识，Web Search 以及像 Context7 这样的 MCP 工具可以帮助 Agent 获取超出知识截止时间的信息，例如最新的软件库版本，或者模型训练结束时尚不存在的当前数据。
Web Search 以及用于查询最新上下文的工具，是值得内置到 Harness 中的实用基础原语。
对抗 Context Rot（上下文腐化）
Agent 的性能不应该随着工作持续进行而逐渐下降。
Context Rot（上下文腐化） 描述的是这样一种现象：随着上下文窗口不断被填满，模型在推理和完成任务方面的表现会越来越差。
上下文是一种宝贵且稀缺的资源，因此 Harness 需要采用策略对其进行管理。
如今的 Harness 在很大程度上就是优秀 Context Engineering（上下文工程）的交付机制。
Compaction（压缩） 解决的是上下文窗口即将被填满时该怎么办的问题。
如果没有 Compaction，当对话超过上下文窗口之后会发生什么？一种可能是 API 直接报错，而这显然不是一个好的结果。Harness 必须针对这种情况采取某种策略。因此，Compaction 会智能地将现有上下文卸载并进行摘要，使 Agent 能够继续工作。
Tool call offloading（工具调用结果卸载） 有助于降低大型工具输出对上下文窗口的影响。
大型工具输出可能会充斥上下文窗口，造成大量噪声，却并没有提供相应的有用信息。Harness 可以保留超过某个 Token 阈值的工具输出的头部和尾部 Token，并将完整输出卸载到文件系统中，以便模型在需要时访问。
Skills 解决的是这样一个问题：Agent 启动时，如果有太多工具或 MCP Server 被加载进上下文，Agent 甚至还没开始工作，性能就已经开始下降。
Skills 是一种 Harness 层面的原语，通过 progressive disclosure（渐进式披露） 来解决这一问题。 模型并没有主动选择在启动时将 Skill 的 front-matter 加载到上下文中，但 Harness 可以支持这种机制，以保护模型免受 Context Rot 的影响。
长时间跨度的自主执行
我们希望 Agent 能够在很长的时间跨度内，自主且正确地完成复杂工作。
自主创建软件是 Coding Agent 所追求的圣杯。
但今天的模型仍然存在提前停止、复杂问题拆解困难，以及当工作跨越多个上下文窗口时出现不连贯等问题。
一个优秀的 Harness 必须围绕这些问题进行设计。
这正是前面介绍的 Harness 原语开始产生组合效应的地方。
长时间跨度的工作需要持久状态、规划、观察和验证能力，从而能够跨越多个上下文窗口持续工作。
使用文件系统和 Git 跨 Session 跟踪工作。 Agent 在一个长期任务中可能产生数百万 Token，因此文件系统可以持久记录这些工作，从而长期跟踪进展。加入 Git 后，新 Agent 可以快速了解项目当前的最新状态以及历史记录。对于多个 Agent 协同工作的场景，文件系统还可以充当共享的工作账本，让 Agent 之间能够进行协作。
使用 Ralph Loop 持续工作。 Ralph Loop 是一种 Harness 模式：它通过 Hook 拦截模型试图退出的行为，然后在一个干净的上下文窗口中重新注入原始 Prompt，迫使 Agent 围绕完成目标继续工作。文件系统使这一机制成为可能，因为每一次迭代都会从一个全新的上下文开始，但同时又可以读取上一轮迭代留下的状态。
通过 Planning 和 Self-Verification 保持方向正确。 Planning（规划）就是模型将一个目标拆解成一系列步骤。Harness 可以通过良好的 Prompt，以及向模型注入如何使用文件系统中的计划文件的提醒，来支持这一过程。在完成每一个步骤之后，Agent 可以通过 self-verification（自我验证） 来检查工作的正确性。
Harness 中的 Hook 可以运行预先定义好的测试套件，并在测试失败时将错误信息反馈给模型，使其重新进入循环；或者，也可以通过 Prompt 让模型独立地对自己的代码进行自我评估。
Verification（验证）可以让解决方案建立在测试之上，并为自我改进提供反馈信号。
Harness 的未来
模型训练与 Harness 设计的耦合
如今的 Agent 产品，例如 Claude Code 和 Codex，会在模型与 Harness 共同参与的环境中进行 Post-training（后训练）。
这帮助模型提升那些 Harness 设计者认为模型应该原生擅长的行为，例如文件系统操作、Bash 执行、规划，以及通过 Subagent 并行处理工作。
这形成了一个反馈循环。
人们发现有用的原语，将它们加入 Harness，然后在训练下一代模型时使用这些原语。
随着这一循环不断重复，模型会在其接受训练的 Harness 中变得越来越强大。
但这种共同进化也会对模型的泛化能力产生一些有趣的副作用。
其中一种表现就是：改变工具逻辑可能导致模型性能下降。
一个很好的例子是 Codex-5.3 prompting guide 中描述的 apply_patch 文件编辑工具逻辑。
一个真正智能的模型应该不会难以在不同的 Patch 方法之间切换，但由于 Harness 被纳入训练循环，这会产生过拟合。
但这并不意味着，针对你的任务而言，最好的 Harness 就一定是模型进行 Post-training 时所使用的那个 Harness。
Terminal Bench 2.0 Leaderboard 就是一个很好的例子。
在 Claude Code 中使用 Opus 4.6 的得分，远低于在其他 Harness 中使用 Opus 4.6 的得分。
在之前的一篇博客中，我们展示了如何仅仅通过修改 Harness，就让我们的 Coding Agent 在 Terminal Bench 2.0 上从 Top 30 提升到 Top 5。
Harness 针对具体任务进行优化，仍然有巨大的性能提升空间。
Harness Engineering 将走向何方
随着模型能力越来越强，如今存在于 Harness 中的一部分能力将逐渐被模型本身吸收。
例如，模型将原生地变得更擅长规划、自我验证以及长时间跨度的一致性，因此不再需要那么多的上下文注入。
这似乎意味着 Harness 随着时间推移应该会变得越来越不重要。
但正如 Prompt Engineering（提示工程）在今天仍然具有价值一样，Harness Engineering 很可能也会持续成为构建优秀 Agent 的重要手段。
诚然，如今的 Harness 确实在弥补模型的不足，但与此同时，它们也在围绕模型智能设计系统，使模型变得更加有效。
一个配置良好的环境、合适的工具、持久化状态以及验证循环，无论模型本身的基础智能水平如何，都可以让模型工作得更加高效。
Harness Engineering 是一个非常活跃的研究领域。我们也利用相关研究来改进 LangChain 的 Harness 构建库 deepagents。
目前我们正在探索的一些开放且有趣的问题包括：
- 编排数百个 Agent，让它们在共享代码库上并行工作
- 让 Agent 分析自己的 Trace，从而识别并修复 Harness 层面的故障模式
- 让 Harness 针对具体任务，在恰当的时间动态组装正确的工具和上下文，而不是提前进行固定配置
这篇文章实际上是一次思考练习：尝试定义什么是 Harness，以及我们希望模型完成的工作又是如何塑造 Harness 的。
The model contains the intelligence and the harness is the system that makes that intelligence useful.
模型承载智能，而 Harness 则是让这种智能真正发挥作用的系统。
To more harness building, better systems, and better agents.致力于构建更多更好的 Harness、更好的系统，以及更好的 Agent。
Deploy Deep Agents in 1-click with LangSmith Deployment. Speak with an expert from our team.