什么是 Harness Engineering？打造可靠的 AI Agent Harness（2026）
Agent = Model + Harness。一份实用指南：什么是 harness、它的七个组成部分、它与 prompt engineering 和 context engineering 的关系、主流 harness 的横向对比，以及如何评估一个 harness。
每个 AI agent 都是模型加上 harness（脚手架系统）的组合——而到 2026 年，决定一个 agent 是否真正能用的，往往是 harness，而不是模型本身。Harness 是包裹在模型周围的一切——控制循环、工具、记忆、沙箱和上下文管理——正是这些东西把原始的智能转化为有用的工作，可以用一个公式来概括：Agent = Model + Harness（智能体 = 模型 + 脚手架）。 Harness engineering（脚手架工程） 是把这套外围系统构建好的学科。本指南将对其进行定义，说明它与 prompt engineering、context engineering 之间的关系，剖析 harness 的构成，比较当下人们实际使用的各种 harness，并解释如何评估一个 harness。
为什么 Harness Engineering 现在如此重要
Harness engineering 之所以重要，是因为模型已经不再是瓶颈——模型周围的系统才是。随着前沿模型在原始能力上趋于收敛，一个能真正交付工作的 agent 和一个会卡壳的 agent 之间的差异，几乎完全体现在 harness 上：它如何管理状态、如何从错误中恢复、如何调用工具，以及如何在长时间运行中保持专注。
从业者们不断得出同样的结论。那些精简掉过度设计的 agent 技术栈的工程师们经常发现，"问题从来不是模型本身，而是围绕它的系统和基础设施。"这就是为什么同一个模型在一个产品中表现出色，在另一个产品中却毫无用处：智能完全相同，但 harness 大相径庭。
推动这一术语兴起的还有一个更深层的趋势：模型和 harness 正越来越多地被一起训练。 各大实验室现在会针对特定的 harness 功能对模型进行后训练——比如某个特定的文件编辑工具、某个特定的规划循环——使二者协同演进。这种耦合让 harness 设计成为一门第一流的工程学科，而不再只是胶水代码，这也是"harness engineering"从小众术语变成 2026 年一个被正式命名的实践的原因。
什么是 Agent Harness？
Agent harness 是 AI agent 中除模型本身之外的一切。一个有用的说法是：如果你不是模型，你就是 harness。 模型是一个把文本转化为文本的函数；它本身无法保持持久状态、运行代码、获取实时信息，或搭建自己的运行环境。这一切都由 harness 提供。
具体来说，harness 让模型能够：
- 在现实世界中采取行动（运行命令、编辑文件、调用 API）
- 记住单次回复之外的事情
- 在某一步失败时进行恢复
- 在多个步骤中持续朝着一个目标推进
没有 harness，你得到的是一个聊天机器人。有了 harness，你得到的才是一个 agent。
Prompt Engineering、Context Engineering 与 Harness Engineering 的对比
这三个术语构成了一个嵌套的层级结构，每一层都包裹着前一层：prompt engineering 优化单条指令，context engineering 管理模型所看到的一切，而 harness engineering 构建模型运行所依托的整个系统。它们不是相互竞争的理念——而是同心的层级。
Prompt engineering、context engineering 和 harness engineering 是同心的层级，而不是相互竞争的方法。
| 层级 | 范围 | 它回答的问题 |
|---|---|---|
| Prompt engineering | 单条指令 | 我该如何表述这个请求？ |
| Context engineering | 上下文窗口中的一切 | 此刻模型应该看到什么信息？ |
| Harness engineering | 模型周围的整个系统 | Agent 需要哪些工具、循环、记忆和环境才能可靠地运作？ |
Prompt engineering 存在于 context engineering 之内，而 context engineering 又存在于 harness engineering 之内。如果你正在构建一个自主 agent，那么这三者你都在做——但决定它能否在真实的、多步骤任务中存活下来的，是 harness 这一层。
Agent Harness 的构成
绝大多数生产级 harness 都由相同的七个组件构成。你可以通过审视任何一个 agent——无论是 Claude Code、一个自建的 LangChain 系统，还是一个托管平台——如何处理这七个组件，来理解它。
包裹模型、使其成为可运作 agent 的七个组件。
- 控制循环（Control loop） —— 驱动 agent 前进并决定何时完成的规划-执行循环（通常是 ReAct 风格的循环：推理、行动、观察、重复）。
- 工具（Tools） —— agent 能够采取的行动。Bash 和文件系统是杠杆效应最大的通用工具；专用工具和 MCP 服务器则可以扩展其能力范围。
- 记忆（Memory） —— 上下文窗口之外的持久存储：文件、记忆存储，或是 agent 读写的一份简单的
AGENTS.md/CLAUDE.md。 - 上下文管理（Context management） —— 压缩、摘要，以及渐进式披露，用来让上下文窗口保持聚焦并对抗上下文腐化（context rot）。（这正是 harness engineering 包含 context engineering 的地方。）
- 沙箱（Sandbox） —— agent 行动运行的隔离环境，这样一个失误或隐藏在其读取内容中的恶意指令就不会损害宿主机器。
- 权限（Permissions） —— agent 无需请示就能做什么，以及哪些地方必须由人类审批。
- 可观测性（Observability） —— 日志、追踪，以及查看 agent 做了什么、为什么这么做的能力，从而让你能够调试并改进 harness。
一个精心设计的 harness，未必是组件最多的那个——而是这些组件彼此协调、相互增益的那个。
真实的 Agent Harness 对比
理解 harness engineering 最快的方式，是看看已上线的产品在 harness 上做出了怎样不同的选择。下表比较了几款流行的 agent harness 在用户最关心的决策点上的差异。
| Harness | 主要界面 | 配置方式 | 执行环境 | 最适合谁 |
|---|---|---|---|---|
| Claude Code | 终端 / CLI（另有 IDE、网页版） | 本地安装 + 配置 | 你自己的机器或沙箱 | 熟悉终端的开发者 |
| OpenAI Codex | CLI + 云端 | 安装 / 云账户 | 沙箱化云端或本地 | OpenAI 生态中的开发者 |
| OpenClaw | 开源 agent 运行时 | 自托管 / 本地配置 | 你自己的基础设施 | 想要完全掌控的技术型用户 |
| Happycapy | 浏览器中的可视化 GUI | 无需配置——直接在浏览器中运行 | 托管的云端沙箱 | 所有人——无论是否具备技术背景 |
这里的规律是：更多的掌控权通常意味着更多的配置工作和 harness 责任，而托管型 harness 则用一部分掌控权换取零配置的可靠性。哪个"最好"，完全取决于使用者是谁，以及他们愿意承担多少 harness 层面的工作。
如何评估一个 Harness
评估一个 harness，要看它能以多可靠、多低成本的方式把一个目标转化为已完成的工作，且只需最少的人工照看。目前主流的指南大多描述了 harness 的组成部分，却很少说明该如何评判一个 harness——以下这些指标正好填补了这一空白：
- 任务成功率（Task success rate） —— 端到端正确完成的任务占比。这是核心指标；应在一套固定的任务集上运行测试。
- 介入率（Intervention rate，自主性） —— 每个任务中人类需要介入的频率。更好的 harness 达到同样的结果所需的中断次数更少。
- 恢复率（Recovery rate） —— 当某一步失败时，harness 有多大概率能自行检测并纠正，而不是卡住或使错误累积扩大。
- 安全隔离（Safety containment） —— agent 的行动能否损害沙箱之外的任何东西？如果一个 harness 会破坏宿主机，无论任务分数多高，它都算失败。
- 可观测性（Observability） —— 你能否看清发生了什么、为什么会这样？如果你无法追溯一次失败的原因，你就无法改进这个 harness。
- 每任务的成本与延迟（Cost and latency per task） —— 实际的上限约束。激进的验证和探索能提升质量，但会消耗更多的 token 和时间；这一指标让这种权衡保持诚实。
可以把它想象成 agent 的持续集成（CI）：一套具有代表性的任务基准，在每次 harness 变更后都要重新跑一遍，这样一次提升了某个指标的调整就不会悄悄破坏另一个指标（一个悄悄拉低成功率的更快循环，是一次退化，而不是一次进步）。
自建还是购买：应该自己动手构建 Harness 吗？
当你的工作流特殊到没有现成的 harness 能满足时，就该自己构建；而当你想要可靠的 agent 工作成果、又不想自己拥有全部七个组件时，就该购买（或采用）一个托管型 harness。自建能给你完全的掌控权，对于新颖的、深度集成的系统来说是正确的选择——但你也就要自己拥有控制循环、沙箱、可观测性和安全性，并随着模型的演进持续维护它们。
对大多数团队和个人来说，目标并不是去工程化一个 harness——而是借助一个 harness 把工作完成。这正是选择托管型 harness 的理由。
Happycapy 是一个你可以直接在浏览器中使用的托管 agent harness：它在一个云端沙箱中运行 Claude Code 及 150 多个模型，配置好工具与文件系统，管理上下文与记忆，并通过一个可视化桌面把工作呈现出来，让你可以随时观察 agent 的运行、并在需要时介入。用 harness 的术语来说，全部七个组件都已经为你工程化并维护好了——你只需描述任务，剩下的交给 harness。这是那些想要 agent 成果、但不想成为 harness 工程师的人的"购买"路径。
安全性：为 Harness 加上沙箱
一个 harness 中最重要的安全决策是沙箱，因为一个能运行命令的 agent 也能运行有害的命令——无论是它自己的失误，还是隐藏在它读取的网页或文件中的提示注入（prompt-injection）攻击所致。Harness 在一个光谱上分布，从软沙箱化（soft sandboxing）（agent 在带有防护机制的可信机器上运行）到硬沙箱化（hard sandboxing）（agent 在一个完全隔离、无法访问宿主机或敏感数据的环境中运行）。
应把 agent 检索到的任何内容——网页、文档、工具输出——都当作不可信输入来对待，并在一个隔离的沙箱中执行，而不是直接在你自己的机器上运行。这正是基于浏览器、云端沙箱化的 harness 在日常使用中如此有吸引力的原因：隔离是默认设置，而不是需要用户自行配置的东西。
开始你的 Harness Engineering 之旅
无论你选择自建还是购买，遵循的原则都是一样的：
- 从你想要的行为出发。 从"agent 应该可靠地做什么"倒推出能够实现它的 harness 功能。
- 给它一个真实的循环和真实的工具。 在你需要更复杂的东西之前，Bash 加文件系统就能覆盖极其广泛的任务。
- 把状态放在模型之外。 使用文件和记忆，让进度在上下文窗口之外也能保留下来。
- 隔离执行环境。 优先做沙箱化；这是防范代价高昂的失误最廉价的保险。
- 衡量它。 在一套固定的任务集上追踪成功率、介入率和恢复率。
如果想了解更广泛的 harness 模式、工具与评测目录，社区维护的 awesome-harness-engineering 列表是一份有用的地图。而如果你根本不想维护一个 harness，在 Happycapy 上，上述七个组件都已经预先连接好——这样你就可以直接从浏览器标签页里让 agent 开始工作，而不必自己拥有控制循环、沙箱和可观测性。
常见问题
问：AI 中的 harness engineering 是什么？
Harness engineering 是设计围绕 AI 模型的一切——控制循环、工具、记忆、沙箱、上下文管理、权限和可观测性——把一个原始模型变成一个可靠 agent 的实践。它可以用公式 Agent = Model + Harness 来概括。
问：模型和 harness 有什么区别？
模型是智能本身——一个把文本转化为文本的函数。Harness 是其余的一切：让模型能够采取行动、记住事情、从错误中恢复、并在多个步骤中持续工作的代码和基础设施。正如那句话所说，"如果你不是模型，你就是 harness。"
问：Harness engineering 与 context engineering 有什么不同？
它们是嵌套的层级。Context engineering 管理模型在其上下文窗口中所看到的内容；harness engineering 构建模型运行所依托的整个系统——其中就包括作为其组成部分之一的上下文管理。Harness engineering 是最外层，同时包裹着 context engineering 和 prompt engineering。
问：我需要自己构建 agent harness 吗？
通常不需要。对于特殊的、深度集成的工作流来说，自建是有道理的，但这意味着你要自己拥有控制循环、沙箱、安全性和可观测性。对大多数人来说，托管型 harness——比如一个基于浏览器的沙箱化平台——会更适合，因为它已经替你把这些组件工程化好了。
问：如何衡量一个 harness 是否够好？
追踪任务成功率、介入率（人类需要介入的频率）、恢复率（自我纠正的频率）、安全隔离、可观测性，以及每任务的成本/延迟——并在一套固定的任务集上运行测试，这样你就能在每次变更前后进行比较。
