Tldr
智能体 = 模型 + Harness。Harness 工程是围绕模型构建系统、将其变成工作引擎的方法。模型提供智能，Harness 让这种智能发挥作用。本文定义了 Harness 的概念，并推导出当下及未来智能体所需的核心组件。
到底什么是「Harness」？
智能体 = 模型 + Harness
如果你不是模型，那你就是 Harness。
Harness（执行框架）是模型之外的一切——所有代码、配置和执行逻辑。一个裸模型不是智能体，但当 Harness 赋予它状态管理、工具执行、反馈循环和可执行的约束时，它就成了智能体。
具体来说，Harness 包含以下内容：
- 系统提示词
- 工具、技能（Skills）、MCP 及其描述
- 配套基础设施（文件系统、沙箱、浏览器）
- 编排逻辑（子智能体生成、任务交接、模型路由）
- 用于确定性执行的钩子/中间件（上下文压缩、延续、代码检查）
在模型和 Harness 之间划分智能体系统的边界，有很多杂乱的做法。但在我看来，这是最干净的定义，因为它迫使我们从围绕模型智能设计系统的角度去思考。
本文接下来将逐一解析 Harness 的核心组件，从模型这一基本原语出发，反推每个组件存在的理由。
从模型的视角看，为什么我们需要 Harness
我们希望智能体做到的很多事，模型开箱即用并不具备。这就是 Harness 登场的地方。
模型（大多数情况下）接收文本、图像、音频、视频等数据，然后输出文本。就这些。它们开箱即用无法做到以下几点：
- 跨交互维持持久状态
- 执行代码
- 获取实时知识
- 搭建环境和安装依赖包来完成工作
这些全是 Harness 层面的功能。LLM 的结构决定了需要某种包装机制来让它们做有用的事。
举个例子，要实现「聊天」这种产品体验，我们把模型放在一个 while 循环里，追踪之前的消息并追加新的用户消息。读到这里的每个人其实都已经用过这种 Harness 了。核心思想就是：把期望的智能体行为转化为 Harness 中的实际功能。
从期望的智能体行为反推 Harness 工程
Harness 工程帮助人类注入有用的先验知识来引导智能体行为。随着模型越来越强大，Harness 被用于精准地扩展和纠正模型，以完成此前不可能的任务。
我们不会穷举每一个 Harness 功能。目标是以「帮助模型做有用的事」为起点，推导出一组核心功能。我们将遵循以下模式：
我们期望的行为（或需要修复的行为） → 帮助模型实现它的 Harness 设计。
文件系统：持久存储与上下文管理
我们希望智能体拥有持久存储，以便与真实数据交互、卸载上下文中放不下的信息，并跨会话保留工作成果。
模型只能直接操作上下文窗口内的知识。有文件系统之前，用户只能把内容复制粘贴给模型——体验很笨拙，而且对自主智能体完全行不通。现实世界早已在用文件系统来工作，模型自然也在数十亿 token 的训练数据中学会了使用文件系统。于是，自然而然的解决方案就是：
Harness 内置文件系统抽象和文件操作工具。
文件系统可以说是最基础的 Harness 原语，因为它解锁了以下能力：
- 智能体获得了一个工作空间，可以读取数据、代码和文档。
- 工作成果可以增量写入和卸载，而不必把一切都塞在上下文里。智能体可以存储中间输出，维持跨会话的持久状态。
- 文件系统是天然的协作界面。 多个智能体和人类可以通过共享文件来协调工作。Agent Teams 等架构正是依赖于此。
Git 为文件系统增加了版本控制，智能体因此可以追踪工作、回滚错误、分支试验。我们稍后还会再谈文件系统，因为它是其他所需功能的关键 Harness 原语。
Bash + 代码：通用工具
我们希望智能体能自主解决问题，而不需要人类为每种可能的操作预先设计工具。
当前智能体的主流执行模式是 ReAct 循环——模型推理、通过工具调用执行操作、观察结果，然后在循环中反复迭代。但 Harness 只能执行它预置了逻辑的工具。与其强制用户为每种可能的操作构建工具，不如给智能体一个通用工具——比如 bash。
Harness 内置 bash 工具，让模型可以通过编写和执行代码来自主解决问题。
Bash + 代码执行是朝着把计算机交给模型迈出的一大步——让模型自行搞定剩下的事。模型可以通过代码即时设计自己的工具，而不受限于一组固定的预配置工具。
Harness 仍然会搭载其他工具，但代码执行已经成为自主解决问题的默认通用策略。
沙箱与工具：执行与验证
智能体需要一个具备合理默认配置的环境，以便安全地执行操作、观察结果并推进工作。
我们已经给模型提供了存储和代码执行能力，但这一切需要一个运行场所。在本地运行智能体生成的代码有风险，而且单一本地环境也无法扩展到大规模智能体工作负载。
沙箱为智能体提供安全的运行环境。 Harness 可以连接沙箱来运行代码、检查文件、安装依赖、完成任务，而不是在本地执行。这实现了代码的安全隔离执行。为了更高的安全性，Harness 可以使用命令白名单并强制网络隔离。沙箱还解锁了可扩展性——环境可以按需创建、分散到多个任务上，工作完成后即可销毁。
好的环境配备好的默认工具。 Harness 负责配置工具链，让智能体能做有用的事。这包括预装语言运行时和包、git 和测试的命令行工具、用于 Web 交互和验证的浏览器。
浏览器、日志、截图和测试运行器等工具为智能体提供了观察和分析自身工作的手段，帮助它们构建自验证循环——编写应用代码、运行测试、检查日志、修复错误。
模型不会自己搭建执行环境。决定智能体在哪运行、有哪些可用工具、能访问什么资源、如何验证工作——这些都是 Harness 层面的设计决策。
记忆与搜索：持续学习
智能体应该记住它见过的内容，并能获取训练时不存在的信息。
模型除了权重和当前上下文，没有额外的知识。既然我们无法直接修改权重，「增加知识」的唯一方式就是上下文注入。
在记忆方面，文件系统再次成为核心原语。Harness 支持诸如 AGENTS.md 之类的记忆文件标准，这些文件在智能体启动时被注入上下文。当智能体添加和编辑这个文件时，Harness 会将更新后的文件加载到上下文中。这是一种持续学习——智能体将一次会话中的知识持久化存储，并注入到未来的会话中。
知识截止日期意味着模型无法直接获取更新的数据——比如新版本的库——除非用户直接提供。为获取最新知识，Web 搜索和 Context7 等 MCP 工具帮助智能体访问知识截止日期之后的信息，如新的库版本或训练停止后产生的数据。
Web 搜索和实时上下文查询工具是值得内置到 Harness 中的有用原语。
对抗上下文腐化
智能体的性能不应在工作过程中衰减。
上下文腐化（Context Rot）描述的是：随着上下文窗口逐渐被填满，模型的推理和任务完成能力会下降。上下文是宝贵且稀缺的资源，因此 Harness 需要策略来管理它。
如今的 Harness 在很大程度上就是优质上下文工程的交付机制。
上下文压缩（Compaction） 解决的是上下文窗口即将填满时怎么办的问题。没有压缩机制，当对话超出上下文窗口会怎样？一种结果是 API 报错——这可不行。Harness 必须有应对策略。上下文压缩会智能地卸载和摘要现有上下文，让智能体得以继续工作。
工具调用卸载（Tool Call Offloading） 有助于减少大量工具输出对上下文的冲击——这些输出往往像噪声一样塞满上下文窗口，却不提供有用的信息。Harness 保留超过阈值的工具输出的头部和尾部 token，将完整输出卸载到文件系统，以便模型按需访问。
技能（Skills） 解决的是另一个问题：智能体启动时加载太多工具或 MCP 服务器到上下文中，导致还没开始工作性能就已下降。Skills 是一种 Harness 层面的原语，通过渐进式披露（Progressive Disclosure） 来解决这个问题。模型并没有选择在启动时加载 Skills 的前置描述，但 Harness 可以支持这种机制来保护模型免受上下文腐化。
长周期自主执行
我们希望智能体能在长时间跨度内自主、正确地完成复杂工作。
自主软件创作是编程智能体的圣杯。但当前的模型面临过早停止、复杂问题分解困难、以及工作跨越多个上下文窗口时的不连贯等问题。好的 Harness 必须围绕这些问题进行设计。
这正是前面提到的 Harness 原语开始产生叠加效应的地方。长周期工作需要持久状态、规划、观察和验证，才能跨越多个上下文窗口持续推进。
文件系统和 git 用于跨会话追踪工作。 智能体在长任务中会生成数百万 token，文件系统将工作成果持久化存储以追踪进度。加入 git 后，新的智能体可以迅速了解项目的最新状态和历史。对于多智能体协作，文件系统还充当共享的工作台账。
Ralph 循环用于延续工作。 Ralph 循环是一种 Harness 模式——通过钩子拦截模型的退出尝试，在干净的上下文窗口中重新注入原始提示词，迫使智能体继续朝完成目标推进。文件系统使这成为可能，因为每次迭代都以全新的上下文开始，但会从上一次迭代中读取状态。
规划和自验证用于保持方向。 规划是指模型将目标分解为一系列步骤。Harness 通过良好的提示词和注入提醒来支持这一点，引导模型使用文件系统中的计划文件。每完成一步，智能体都会通过自验证来检查工作的正确性。Harness 中的钩子可以运行预定义的测试套件，失败时将错误信息回传给模型；或者提示模型独立地自我评估代码。验证将解决方案锚定在测试上，并为自我改进提供反馈信号。
Harness 的未来
模型训练与 Harness 设计的耦合
如今的智能体产品——如 Claude Code 和 Codex——在后训练阶段将模型与 Harness 放在同一个循环中训练。这让模型在 Harness 设计者认为应该原生掌握的能力上不断进步：文件系统操作、bash 执行、规划、以及用子智能体并行化工作。
这形成了一个反馈循环。有用的原语被发现、加入 Harness，然后在训练下一代模型时被使用。随着这个循环不断重复，模型在其训练所用的 Harness 中变得越来越强。
但这种协同进化对泛化能力产生了有趣的副作用——比如更改工具逻辑会导致模型性能下降。Codex-5.3 提示词指南中的 apply_patch 文件编辑工具就是一个好例子。一个真正智能的模型在不同的 patch 方法之间切换应该不费吹灰之力，但与 Harness 联合训练产生了这种过拟合。
但这并不意味着模型后训练所用的 Harness 就是你任务的最佳选择。 Terminal Bench 2.0 排行榜就是个很好的例子。Claude Code 中的 Opus 4.6 得分远低于其他 Harness 中的 Opus 4.6。在之前的博客中，我们展示了仅通过更换 Harness 就将编程智能体从 Terminal Bench 2.0 的 Top 30 提升到 Top 5。针对你的任务优化 Harness，还有很大的提升空间。
Harness 工程的未来方向
随着模型越来越强大，如今 Harness 中的一些功能将会被模型吸收。模型会在规划、自验证和长周期连贯性方面原生表现更好，从而减少对上下文注入的依赖。
这似乎暗示 Harness 会随着时间推移变得不那么重要。但正如提示词工程至今仍然有价值一样，Harness 工程很可能将持续地对构建优秀智能体发挥作用。
确实，当下的 Harness 在一定程度上是弥补模型的不足。但它们也在围绕模型智能构建系统，使其更加高效。一个配置良好的环境、合适的工具、持久状态和验证循环，能让任何模型都更高效——无论其基础智能水平如何。
Harness 工程是一个非常活跃的研究领域，我们在 LangChain 利用它来改进 Harness 构建库 deepagents。以下是我们正在探索的几个开放且有趣的问题：
- 协调数百个智能体在共享代码库上并行工作
- 智能体分析自身的执行轨迹，识别并修复 Harness 层面的失败模式
- Harness 根据给定任务动态按需组装合适的工具和上下文，而非预先配置
这篇博客是一次定义 Harness 的尝试——它是什么，以及它如何被我们期望模型完成的工作所塑造。
核心观点
模型蕴含智能，Harness 是让这种智能发挥作用的系统。
愿我们构建更多 Harness，打造更好的系统，创造更强的智能体。