Agent Harness 的概念最早在 2023 年 Beren Millidge 的经典论文《Scaffolded LLMs as Natural Language Computers》中有了雏形，但直到 2026 年初才被 OpenAI、Anthropic 和 LangChain 同时正式命名和采用。
用最简洁的话来概括，Harness 就是大模型之外的全部工程化基础设施。一个原始的 LLM 就像是一颗强大的大脑，但没有眼睛（无法感知环境）、没有双手（无法执行操作）、没有记忆（无法保持状态）、没有检查机制（无法验证自己的工作）。Harness 就是给这颗大脑装上感官系统、执行机构、记忆系统和质量控制的完整操作系统。
把Harness类比为操作系统，不是为了赶时髦，而是因为两者在结构上确有相似之处。
操作系统管理的是计算机的硬件资源——CPU、内存、磁盘、网络。应用程序不需要知道这些硬件具体怎么工作，操作系统提供了统一的接口：你调用read()，不必关心数据是从SSD还是网络来的。
Harness管理的是Agent的智能资源——LLM调用、工具执行、记忆存取、上下文窗口。Agent的开发者不需要每次手动拼接消息、处理工具循环、管理token预算，Harness提供了统一的抽象：你定义一个工具，Harness负责把它正确地交给LLM、执行、并把结果放回对话中。
这种类比的深层含义是：正如操作系统让程序员从“操作硬件”中解放出来，专注于写应用逻辑；Harness让Agent开发者从“操作LLM”的琐碎细节中解放出来，专注于定义Agent的能力和行为。
再往深一层看，操作系统还做了一件关键的事：资源隔离与安全。一个进程崩溃不应该拖垮整个系统，一个程序不能随意读取其他程序的内存。同样，Harness必须保证：一个Agent的失败不会影响其他Agent的运行，一个工具调用不会越权执行危险操作。
回想你第一次写Agent的经历，代码大概长这样：
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "帮我查一下北京明天的天气"}],
tools=[{"type": "function", "function": {...}}]
)
# 然后手动处理工具调用、拼接消息、再调用API...
这段代码确实能“跑起来”，但如果你把它直接部署到生产环境，很快会遭遇一连串灵魂拷问：
一段能跑通的代码和一个能用的Agent系统之间的距离，就是Harness存在的意义。
Harness是包裹在Agent核心逻辑之外的一整套基础设施，它为Agent提供运行、评估、调试和治理所需的全部支撑能力。如果说LLM是Agent的大脑，那么Harness就是Agent的身体——它决定了这个大脑能接触到什么、能做什么、以及它的每一次“思考”是否被妥善记录。一个典型的Harness包含以下核心模块：
| 模块 | 回答的问题 |
|---|---|
| Runtime | Agent如何执行？状态如何管理？ |
| Tool System | Agent能做什么？边界在哪里？ |
| Memory | Agent记得什么？忘记什么？ |
| Evaluator | Agent做得好不好？如何度量？ |
| Observability | Agent“想”了什么？出了问题如何排查？ |
| Security | Agent的行为是否安全？谁来兜底？ |
没有Harness的Agent是“裸奔”的——它能对话，但你不知道它为什么这样回答，不知道它调用了什么，也不知道它下次会不会犯同样的错。
大模型火出圈之后，总共走过了三个工程层次：从 Prompt Engineering 到 Context Engineering，再到Harness Engineering。而 Harness 概念的正式化标志着 AI 工程领域经历了三个层次的演进：
第一层：Prompt Engineering（2022-2024）——关注如何与模型对话，即"怎么说"。这是最直接的交互优化层，通过精心设计提示词来引导模型产生更好的输出。
第二层：Context Engineering（2025）——关注模型能看到什么信息，即"看什么"。工程师开始系统地管理记忆、持久化和状态，为非技术用户则意味着给 AI 提供真正有用的背景信息。
第三层：Harness Engineering（2026）——关注围绕模型的完整系统，即"怎么控"。这是当前的最高层次，涵盖了从 Prompt Construction 到 Error Handling、从 Verification Loops 到 Subagent Orchestration 的全部基础设施设计。
每一层并没有取代前一层，而是在其上构建。Prompt 仍在 Harness 之内发挥作用，Context 管理仍是 Harness 的核心组件，但 Harness Engineering 将这些元素整合到了一个统一的系统框架中。
为了避免概念膨胀，有必要划清几条边界：
Harness不是Agent框架本身。 LangChain、AutoGen这类框架提供了构建Agent的组件和抽象，而Harness是更上层的概念——它关心的是Agent如何被运行、评估和治理。你可以用LangChain构建Agent，再用Harness来评估和部署它。当然，实践中两者常常融合在一起，LangGraph本身就内置了部分Harness能力。
Harness不是简单的Prompt封装。 把Prompt放进一个配置文件，加上几个变量替换，这距离Harness还差得很远。Harness的核心价值在于闭环：运行 → 记录 → 评估 → 改进 → 再运行。
Harness不是万能胶。 它不能解决Agent的根本性难题——比如LLM的幻觉、推理能力的上限。Harness能做的是：让这些问题可见、可度量、可控制，从而让你有机会系统性地改进，而不是每次靠运气。
2024年之前，Agent开发的主流方式是“写个demo，手动测几条，感觉不错就上线”。这种方式在Agent能力有限、应用场景简单时还能凑合。
但现在情况变了：
第一，Agent的能力边界在快速扩张，失败的成本也在同步上升。 当Agent只能查天气时，答错了没什么大不了。当Agent开始帮你回复客户邮件、操作数据库、执行交易时，一次错误的代价可能是灾难性的。Harness提供的评估和安全机制，是Agent走向高价值场景的前提。
第二，模型在快速迭代，Agent的表现是“漂移”的。你今天调好的Prompt，在模型升级后可能完全变样。没有Harness的评估体系，你根本不知道Agent是变好了还是变坏了，更不知道坏在哪。
第三，Agent的调试难度比传统软件高一个数量级。传统软件出了bug，你可以打断点、看堆栈。Agent“出错”时，往往不是抛异常，而是给出一个看似合理实则错误的回答。没有完整的执行轨迹记录，这种问题几乎无法定位。
第四，多Agent系统的复杂度在爆炸。当多个Agent相互协作时，消息传递、状态同步、冲突协调这些问题会让裸写的Agent代码迅速失控。Harness提供的编排和治理能力，是管理这种复杂度的唯一可行路径。
Harness是Agent从“玩具”走向“工具”的分水岭。它不直接提升Agent的智能水平，但它决定了Agent的智能能否被信任、度量和持续改进。
在接下来的章节中，我们将从零开始搭建一个最小可用的Harness，然后逐步为它添加工具管理、记忆系统、评估体系和可观测性能力。当你完成这本书时，你将不再是一个“会调API写Agent的人”，而是一个“能构建可靠Agent系统的工程师”。