智能体 Harness 剖析

关键要点

• 拆解复杂目标：规划工具让智能体可以把任务拆成一步步、追踪进度，并在推进过程中不断调整
• 并行委派工作：为相互独立的子任务创建子智能体（subagent），每个子智能体拥有自己隔离的上下文

一句话概括：Agent（智能体）= Model（模型）+ Harness。所谓 "Harness 工程"，说的是我们围绕模型搭建起的一整套系统，正是这套系统把模型变成了真正能干活的"工作引擎"。模型提供智能，Harness 让这份智能变得可用。这篇文章要做的，就是定义清楚 Harness 到底是什么，并推导出今天乃至未来的智能体都需要具备的核心组件。

到底什么是 "Harness"？

Agent = Model + Harness

如果你写的不是模型本身，那你写的就是 Harness。

Harness 指的是除模型之外的一切代码、配置和执行逻辑。一个"裸模型"算不上智能体；只有当外部系统为它提供了状态、工具执行能力、反馈闭环、以及可强制执行的约束条件之后，它才真正成为智能体。

具体来说，Harness 通常包括：

• 系统提示词（System Prompts）
• 工具、技能（Skills）、MCP，以及它们各自的描述文本
• 打包在一起的基础设施：文件系统、沙盒、浏览器
• 编排逻辑：子智能体创建、任务交接、模型路由
• 用于确定性执行的钩子/中间件：上下文压缩、任务续接、代码规范检查等

模型和 Harness 之间的边界其实有很多种划法，但作者认为这是最干净的一种定义方式，因为它逼着我们必须去思考如何围绕模型的智能来设计系统。

接下来的内容会沿着这样一条主线展开：从模型这个最核心的基本单元出发，反过来推导出 Harness 里每个组成部分存在的原因。

从模型的视角看，为什么需要 Harness

有些我们希望智能体能做到的事，模型开箱即用是做不到的，Harness 正是为此而生。

模型（大多数情况下）接收的是文本、图像、音频、视频这类数据，输出的几乎只有文本，仅此而已。开箱即用的模型做不到：

• 在多轮交互之间维持持久状态
• 执行代码
• 获取实时知识
• 搭建环境、安装依赖包来完成工作

这些统统是 Harness 层面才具备的能力。LLM 本身的结构决定了，它必须被某种外部机制"包裹"起来，才能真正产出有用的成果。举个例子，要实现"聊天"这样一种产品体验，做法是把模型放进一个 while 循环里，持续记录历史消息、不断把新的用户输入拼接进去——这正是每个人都已经用过的一种 Harness。核心思路很简单：把我们希望智能体表现出的行为，转化成 Harness 里真正能跑起来的功能。

从"期望的智能体行为"反推 Harness 工程

Harness 工程帮助人类把有用的先验（priors）注入智能体，引导它的行为方式。随着模型能力不断增强，Harness 也被用来对模型做更精细的"外科手术式"能力延伸和纠偏，让它们完成过去做不到的任务。

作者没有打算穷举 Harness 的每一项功能，而是想从"如何帮助模型完成有价值的工作"这个起点出发，推导出一套核心特性。整体遵循这样的模式：

我们想要（或想修复）的行为 → 为帮助模型实现这个行为而设计的 Harness

文件系统：持久化存储与上下文管理

我们希望智能体拥有持久化存储，能对接真实数据、把超出上下文容量的信息卸载出去、并让工作可以跨会话保留。

模型能直接操作的知识仅限于当前上下文窗口内的内容。在文件系统方案出现之前，用户只能把内容手动复制粘贴给模型，这种交互体验很笨拙，也完全无法支撑自主运行的智能体。由于现实世界早已在广泛使用文件系统来完成各种工作，模型训练时自然接触了海量与"如何使用文件系统"相关的 token，于是很自然地演化出了这样一套方案：

Harness 直接内置文件系统的抽象层，以及配套的文件操作（fs-ops）工具。

文件系统可能是所有 Harness 原语里最基础的一个，因为它解锁了：

• 智能体获得一个可以读取数据、代码、文档的工作空间
• 工作内容可以增量添加和卸载，不必把所有东西都塞进上下文；智能体能存储中间产出，维持超出单次会话生命周期的状态
• 文件系统是天然的协作界面：多个智能体、甚至智能体和人类之间，都可以通过共享文件来协调，"Agent Teams" 这类架构正是建立在这一点之上

Git 为文件系统加上了版本管理能力，让智能体可以追踪工作历史、在出错时回滚、也能分支出不同的实验路径。文章后面还会反复提到文件系统，因为事实证明，它是支撑其他很多能力的关键 Harness 原语。

Bash + 代码：通用问题解决工具

我们希望智能体能自主解决问题，不需要人类为每一种可能的操作都提前设计好工具。

当下主流的智能体执行范式是 ReAct 循环：模型进行推理、通过工具调用采取行动、观察结果，如此循环往复。但 Harness 只能执行它已经写好逻辑的工具。与其强迫用户为每一种可能的操作都单独构建工具，更好的做法是给智能体一个足够通用的工具，比如 bash。

Harness 内置 bash 工具，让模型可以通过编写和执行代码来自主解决问题。

Bash 加代码执行能力，某种意义上是朝着"直接给模型一台电脑、剩下的交给它自己想办法"迈出的关键一步。模型因此可以按需通过代码即时"发明"出自己的工具，而不必被局限在一套预先配置好的固定工具集里。

Harness 依然会配备其他各种专用工具，但代码执行已经成为智能体自主解决问题时默认采用的通用策略。

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

智能体需要一个默认配置就相对合理的环境，这样才能安全地采取行动、观察结果，并持续推进任务。

我们已经给了模型存储能力和代码执行能力，但这一切终究得"发生在某个地方"。在本地环境里直接运行智能体生成的代码风险不小，单一的本地环境也完全撑不住大规模的智能体工作负载。

沙盒为智能体提供安全的运行环境。 Harness 不再于本地执行代码，而是连接到沙盒去运行代码、检查文件、安装依赖、完成任务，从而实现安全、隔离的代码执行。想要更高的安全性，Harness 还可以对可执行命令做白名单限制、强制启用网络隔离。沙盒同时也带来了规模化的可能：环境可以按需创建，在大量任务之间并行展开，工作完成后随即销毁。

好的环境离不开好的默认工具配置。 配置这些工具正是 Harness 的职责所在，这样智能体才能真正做成有价值的事，包括预装好各种语言运行时和依赖包、用于 git 操作和测试的命令行工具，以及用于网页交互和结果验证的浏览器等。

有了浏览器、日志、截图、测试运行器这类工具，智能体就有了观察和分析自己工作成果的手段，这能帮它们建立起一种自我验证闭环——编写应用代码、运行测试、检查日志、修复错误。

模型自己并不会去配置执行环境。智能体究竟在哪里运行、能用到哪些工具、能访问什么资源、又该如何验证自己的工作成果，这些统统属于 Harness 层面需要做出的设计决策。

记忆与搜索：持续学习

我们希望智能体能记住自己曾经接触过的信息，也能获取那些训练完成之后才出现的新信息。

除了模型权重里固化下来的知识、以及当前上下文窗口里的内容，模型不具备任何额外的知识来源。既然没法直接编辑模型权重，"新增知识"这件事就只剩一条路可走——上下文注入（context injection）。

在"记忆"这件事上，文件系统再次扮演了核心角色。Harness 支持类似 AGENTS.md 这样的记忆文件规范，这类文件会在智能体启动时被注入进上下文；随着智能体不断往里面增补、修改内容，Harness 也会持续把更新后的文件重新加载进上下文——这本质上是一种持续学习：智能体把某一次会话里学到的知识持久化地存下来，并在未来的会话中重新注入这些知识。

知识截止日期意味着，如果用户不主动提供，模型没法直接得知诸如软件库最新版本这样的信息。为了获取最新知识，网页搜索，以及像 Context7 这样的 MCP 工具，可以帮助智能体访问知识截止日期之后才出现的信息，比如新发布的库版本，或者训练结束之后才存在的最新数据。

网页搜索，以及各种用来查询最新上下文信息的工具，都是很值得内置进 Harness 里的实用原语。

对抗"上下文腐化"

智能体的表现不应该随着工作的推进而逐渐变差。

Context Rot（上下文腐化）描述的是这样一种现象：随着上下文窗口被逐渐填满，模型在推理和完成任务这两方面的能力都会随之下滑。上下文是一种珍贵而稀缺的资源，Harness 必须有相应的策略来管理它。

今天的 Harness，很大程度上就是优质"上下文工程"（context engineering）的一种交付载体。

压缩（Compaction） 要解决的问题是：当上下文窗口快被填满时该怎么办。如果没有压缩机制，一旦对话内容超出上下文窗口容量会发生什么？一种可能是 API 直接报错，这显然不是什么好结果。所以 Harness 必须有某种策略来应对：智能地把现有上下文内容做卸载和总结，让智能体能够继续把工作进行下去。

工具调用输出卸载（Tool call offloading） 能帮助降低大体量工具输出对上下文窗口造成的干扰——这些输出往往占用大量空间，却没提供多少真正有用的信息。具体做法是，当工具输出超过某个 token 阈值时，Harness 只保留输出内容开头和结尾的部分 token，把完整输出卸载到文件系统里，模型需要时可以随时访问。

技能（Skills） 要解决的，是智能体启动时因为加载了太多工具或 MCP 服务器，导致性能在真正开始工作之前就已经打了折扣的问题。Skills 是 Harness 层面的一种原语，它通过渐进式披露（progressive disclosure）来解决这个问题——模型自己并没有"选择"要在启动时把 Skill 的元信息（front-matter）加载进上下文，但 Harness 可以支持这样的机制，从而在上下文腐化这件事上替模型多一层保护。

长周期自主执行

我们希望智能体能够长时间、自主而且正确地完成复杂工作。

自主完成软件开发是编码类智能体追求的"圣杯"，但今天的模型仍然存在过早停止、拆解复杂问题能力不足，以及工作一旦跨越多个上下文窗口就容易前后不连贯这些问题。一个好的 Harness 必须针对这些问题做出系统性设计。

正是在这个场景下，前面提到的那些 Harness 原语开始真正产生"复利效应"。要在跨越多个上下文窗口的情况下持续推进长周期工作，离不开持久状态、规划能力、观察手段和验证机制的共同配合。

文件系统 + git，用于跨会话追踪工作。 智能体在完成一项长任务的过程中往往会产生数以百万计的 token，文件系统能把这些工作成果持久化地记录下来，从而随时间推移追踪整体进度。加入 git 之后，新接手任务的智能体也能很快了解项目最新的进展和历史脉络。当多个智能体协同工作时，文件系统还能充当一种共享的工作台账。

用 Ralph Loop 延续工作。 Ralph Loop 是一种 Harness 模式：它通过一个钩子拦截模型试图"退出"的动作，然后在一个全新、干净的上下文窗口里重新注入最初的提示词，从而强迫智能体针对既定目标持续推进工作。文件系统正是让这一切成为可能的关键——因为虽然每一轮迭代都从全新的上下文开始，但它会读取上一轮迭代留下的状态。

用规划与自我验证保持在正轨上。 所谓"规划"，指的是模型把一个目标拆解成一连串具体步骤。Harness 通过精心设计的提示词、以及在文件系统里注入提醒（告诉模型该如何使用一份"计划文件"）来支持这种能力。每完成一个步骤之后，智能体如果能对自己的工作成果做一次正确性检查，往往会有明显收益——这就是自我验证。Harness 里的钩子可以运行一套预先定义好的测试用例，一旦测试失败就把报错信息反馈给模型，形成闭环；也可以直接提示模型让它对自己写的代码做独立的自我评估。验证机制能让最终方案有据可依，也为智能体的自我改进创造出了一种反馈信号。

Harness 的未来

模型训练与 Harness 设计的耦合

像 Claude Code、Codex 这样的智能体产品，今天在后训练（post-training）阶段就已经把模型和 Harness 一起纳入了训练循环。这样做有助于让模型在 Harness 设计者认为它"理应表现出色"的那些操作上变得更强，比如文件系统操作、bash 执行、任务规划，或是借助子智能体并行处理工作。

这就形成了一个反馈循环：人们发现某个有用的原语，把它加进 Harness，然后在训练下一代模型时用上它。这个循环每重复一轮，模型在它被训练所依托的那套 Harness 环境里就会变得更强大。

不过，这种"协同进化"也带来了一些颇为有趣的副作用，尤其体现在泛化能力上——比如说，单单改变工具的底层逻辑，就可能导致模型表现明显变差。一个很好的例子是 Codex-5.3 提示指南里关于 apply_patch 工具（用来编辑文件）的讨论。按理说，一个真正智能的模型应该能毫不费力地在不同的补丁处理方式之间自由切换，但正因为训练过程中 Harness 全程参与，反而造成了这样一种"过拟合"现象。

但这并不意味着，模型后训练时所用的那套 Harness，就一定是最适合你手头任务的 Harness。 Terminal Bench 2.0 排行榜就是一个很好的例子：同样是 Opus 4.6，跑在 Claude Code 里的得分，远低于跑在其他 Harness 里的得分。作者提到，此前他们仅仅通过改造 Harness 本身，就把自家编码智能体在 Terminal Bench 2.0 上的排名从 Top 30 提升到了 Top 5。这说明，针对具体任务去优化 Harness，还有相当大的潜力可以挖掘。

Harness 工程接下来会走向何方

随着模型能力越来越强，今天活在 Harness 里的一部分能力，未来大概率会被逐渐"吸收"进模型本身——模型会在规划、自我验证、长周期连贯性这些方面天生变得更强，从而不再那么依赖诸如上下文注入这样的手段。

照这个逻辑推演，似乎意味着 Harness 会变得越来越不重要。但正如提示词工程（prompt engineering）至今依然很有价值一样，作者认为 Harness 工程很可能也会在打造优秀智能体的过程中持续发挥作用。

确实，今天的 Harness 很大程度上是在为模型的种种不足打补丁，但与此同时，它们也在围绕模型的智能构建出一整套系统，让这份智能能够更有效地发挥出来。一个配置得当的运行环境、恰到好处的工具、能持久保存的状态、以及完整的验证闭环——不管模型本身的基础智能水平如何，这些都能让它运转得更高效。

Harness 工程是一个当下非常活跃的研究领域，LangChain 团队也正是依靠对这一领域的持续探索，来不断改进他们用于构建 Harness 的开源库 deepagents。文中提到几个他们正在探索、也颇具开放性的有趣问题：

• 如何编排数以百计的智能体，让它们在同一个代码库上并行协作
• 如何让智能体分析自己的执行轨迹（trace），从而识别并修复 Harness 层面存在的失败模式
• 如何让 Harness 能动态地、即时地为某个具体任务组装出合适的工具和上下文，而不是依赖预先配置好的固定方案

这篇文章本质上是一次思考练习：定义清楚 Harness 到底是什么，以及它是如何被我们想让模型完成的工作所塑造出来的。

模型承载智能，而 Harness 是让这份智能真正发挥作用的系统。