内容
TLDR： 智能体 = 模型 + harness。Harness 工程是我们围绕模型构建系统、将其转化为工作引擎的方法。模型承载智能，harness 让智能变得可用。本文定义了 harness 的概念，并推导出当今及未来智能体所需的核心组件。
能否有人定义一下"Harness"？
Agent = Model + Harness
如果你不是模型，你就是 harness。
Harness 是指除模型本身之外的所有代码、配置和执行逻辑。原始模型不是智能体，但当 harness 赋予它状态、工具执行、反馈循环和可强制执行约束等能力时，它就成为了智能体。
具体而言，harness 包括：
-
系统提示词（System Prompts）
-
工具、技能、MCP 及其描述
-
捆绑基础设施（文件系统、沙盒、浏览器）
-
编排逻辑（子智能体生成、交接、模型路由）
-
确定性执行的钩子/中间件（压缩、续接、代码检查）
在模型与 harness 之间划分智能体系统的边界有多种混乱的方式。但在我看来，这是最清晰的定义，因为它迫使我们思考围绕模型智能设计系统。
本文其余部分将介绍核心 harness 组件，并从模型的核心原语出发，倒推为何需要每个组件。
智能体 Harness 通过上下文注入、控制、行动、观察和持久化包裹模型
为何需要 Harness……从模型的视角
我们希望智能体完成某些任务，但模型开箱即用无法做到。这就是 harness 的用武之地。
模型（主要）接收文本、图像、音频、视频等数据，输出文本。仅此而已。开箱即用，它们无法：
-
在交互间维持持久状态
-
执行代码
-
访问实时知识
-
搭建环境并安装包以完成工作
这些都是 harness 级别的功能。大语言模型的结构需要某种机制将其包裹起来才能完成有用的工作。
例如，要实现"聊天"这样的产品体验，我们用 while 循环包裹模型以追踪历史消息并追加新用户消息。阅读本文的每个人都已使用过这种 harness。核心思想是将期望的智能体行为转化为 harness 中的实际功能。
从期望的智能体行为倒推 Harness 工程
Harness 工程帮助人类注入有用的先验知识以引导智能体行为。随着模型能力增强，harness 被用于精准扩展和修正模型，以完成此前不可能的任务。
我们不会穷尽列举所有 harness 功能。目标是从帮助模型完成有用工作的起点出发，推导出一组功能。我们遵循如下模式：
我们想要的（或想要修复的）行为 → 帮助模型实现该行为的 Harness 设计。
每个 harness 功能都源于模型自身无法提供的行为
文件系统用于持久存储与上下文管理
我们希望智能体拥有持久存储，以对接真实数据、卸载放不进上下文的信息，并在会话间持久化工作成果。
模型只能直接操作其上下文窗口内的知识。在文件系统出现之前，用户必须直接复制粘贴内容给模型，这种用户体验笨拙，且对自主智能体无效。世界本就使用文件系统完成工作，因此模型自然在数十亿 token 上训练了如何使用它们。自然解决方案成为：
Harness 配备文件系统抽象和文件操作工具。
文件系统堪称最基础的 harness 原语，因为它解锁了：
-
智能体获得工作空间以读取数据、代码和文档。
-
工作可以增量添加和卸载，而非全部保存在上下文中。智能体可以存储中间输出，并维持超越单次会话的状态。
-
文件系统是自然的协作界面。多个智能体和人类可通过共享文件协调。智能体团队（Agent Teams）等架构依赖于此。
Git 为文件系统添加版本控制，使智能体能够追踪工作、回滚错误、分支实验。下文我们将再次讨论文件系统，因为它竟是其他所需功能的关键 harness 原语。
我们希望智能体自主解决问题，无需人类预先设计每个工具。
当今主要的智能体执行模式是 ReAct 循环，模型推理、通过工具调用采取行动、观察结果，并在 while 循环中重复。但 harness 只能执行其有逻辑的工具。与其强迫用户为每个可能的操作构建工具，更好的解决方案是给智能体一个通用工具如 bash。
Harness 配备 bash 工具，使模型能通过编写和执行代码自主解决问题。
Bash + 代码执行是向赋予模型一台计算机并让其自主解决其余问题迈出的一大步。模型可以通过代码即时设计自己的工具，而非受限于固定预设的工具集。
Harness 仍配备其他工具，但代码执行已成为自主问题解决的默认通用策略。
智能体需要具备合适默认配置的环境，以便安全行动、观察结果并取得进展。
我们已赋予模型存储和执行代码的能力，但这一切都需要在某个地方发生。本地运行智能体生成的代码有风险，且单一本地环境无法扩展至大规模智能体工作负载。
沙盒为智能体提供安全的运行环境。 Harness 可以连接沙盒而非本地执行，以运行代码、检查文件、安装依赖、完成任务。这实现了代码的安全隔离执行。为增强安全性，harness 可以允许列表命令并强制执行网络隔离。沙盒还解锁了扩展性，因为环境可以按需创建、分散到众多任务，并在工作完成后销毁。
好环境配备好默认工具。 Harness 负责配置工具，使智能体能完成有用工作。这包括预装语言运行时和包、git 和测试的 CLI、浏览器用于网页交互和验证。
浏览器、日志、截图、测试运行器等工具为智能体提供了观察和分析工作的方式。这帮助它们创建自验证循环，可以编写应用代码、运行测试、检查日志、修复错误。
模型不会开箱即用地配置自己的执行环境。决定智能体在哪里运行、有哪些工具可用、能访问什么、如何验证工作，都是 harness 级别的设计决策。
记忆与搜索用于持续学习
智能体应记住所见，并访问训练时不存在的信息。
模型除了权重和当前上下文外没有额外知识。在不访问修改模型权重的情况下，"添加知识"的唯一方式是上下文注入。
对于记忆，文件系统再次成为核心原语。Harness 支持 AGENTS.md 等记忆文件标准，在智能体启动时注入上下文。随着智能体添加和编辑此文件，harness 将更新后的文件加载到上下文中。这是一种持续学习形式，智能体将知识从一会话持久存储，并注入未来会话。
知识截止意味着模型无法直接访问新数据，如更新的库版本，除非用户直接提供。为获取最新知识，网页搜索和 Context7 等 MCP 工具帮助智能体访问知识截止之外的信息，如训练停止后出现的新库版本或当前数据。
网页搜索和查询最新上下文的工具是融入 harness 的有用原语。
对抗上下文衰减
智能体性能不应随工作进程而下降。
上下文衰减描述模型如何随着上下文窗口填满而在推理和完成任务方面变差。上下文是宝贵且稀缺的资源，因此 harness 需要管理策略。
当今的 harness 很大程度上是良好上下文工程的交付机制。
压缩解决上下文窗口即将填满时的问题。不压缩会怎样？对话超出上下文窗口时，一种选择是 API 报错，这不好。Harness 必须对此情况采用某种策略。因此压缩智能地卸载和总结现有上下文窗口，使智能体能够继续工作。
工具调用卸载帮助减少大型工具输出的影响，这些输出会嘈杂地 clutter 上下文窗口而不提供有用信息。Harness 保留超过阈值 token 数的工具输出的首尾 token，将完整输出卸载到文件系统，以便模型需要时访问。
技能解决智能体启动时加载过多工具或 MCP 服务器到上下文导致性能下降的问题，这在智能体开始工作前就损害性能。技能是 harness 级别的原语，通过渐进式披露解决此问题。模型并未选择让技能前言在启动时加载到上下文，但 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 工具逻辑。真正智能的模型在补丁方法间切换应无困难，但与 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 修补了模型的不足，但它们也围绕模型智能工程化系统以使其更有效。配置良好的环境、合适的工具、持久状态和验证循环，无论基础智能如何，都能让任何模型更高效。
Harness 工程是我们用于改进 LangChain 的 harness 构建库 deepagents 的活跃研究领域。以下是我们当今探索的一些开放且有趣的问题：
-
编排数百个智能体在共享代码库上并行工作
-
分析自身轨迹以识别和修复 harness 级别故障模式的智能体
-
为给定任务即时动态组装合适工具和上下文的 harness，而非预配置
本文是一次定义 harness 是什么、以及它如何由我们希望模型完成的工作所塑造的练习。
模型承载智能，harness 是让该智能变得有用的系统。
致更多 harness 构建、更好的系统、更好的智能体。