你有没有这样的经历：用 Cursor 或 Claude Code 写代码，Agent 唰唰写了一大段，然后......停了。测试没跑，边界没处理，你以为它干完了，结果还得自己收拾烂摊子。
这个时候，你的第一反应大概率是："模型还是不够聪明，等下一代吧。"
但 LangChain 和 HumanLayer 等团队在做了上百个 Agent 项目后，得出了一个完全不同的结论：
"It's not a model problem. It's a configuration problem."
那些"模型之外的东西"，现在有了一个统一的名字------Harness。
一、Harness 到底是什么？
LangChain 的 Vivek Trivedy 给了一个最干净的定义：
Agent = Model + Harness. If you're not the model, you're the harness.
翻译过来就是：Agent 不是一个单纯的模型，而是一个系统。这个系统由两部分组成：
- Model：模型权重、推理能力，是"大脑"
- Harness：模型之外的一切，是"身体 + 环境 + 工具"
Harness 具体包含哪些东西？打开你正在用的 Agent，背后其实藏着这些：
| 类别 | 具体内容 |
|---|---|
| 执行环境 | 沙盒（sandbox）、文件系统、网络权限、操作系统 |
| 工具与接口 | MCP 服务器、命令行、浏览器、API 调用 |
| 上下文管理 | 系统提示词、检索增强（RAG）、上下文压缩、按需加载 |
| 流程控制 | 中间件（middleware）、退出前自检、死循环检测、重试策略 |
| 持久化与反馈 | 执行轨迹记录、错误修复固化、数据集积累 |
一句话：凡是模型权重之外的东西，都属于 Harness。
二、Harness Engineering 的核心思想
Harness Engineering 不是简单的"改 prompt"，也不是等模型升级。它有一套自己的工程哲学。
My AI Adoption Journey 给了一个非常落地的定义：
"Harness engineering is the idea that anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."
翻译过来：当 Agent 犯了一个错，你花时间去设计一个解决方案，让这个 Agent 永远不再犯这个错。
注意，这不是"改 prompt 再试一次"，而是改变环境、增加流程、加上护栏，从架构层面把错误堵死。
举个例子，Agent 最常见的失败模式：写完代码就停，不跑测试。
用 Harness Engineering 的思路，你不会每次都给 prompt 加一句"记得跑测试"，而是会在 Agent 试图退出时强制拦截，注入一个 checklist，让它必须跑完测试才能退出。
这不是靠模型自觉，而是靠流程保证。
三、Prompt → Context → Harness：不是替代，是包含
你可能已经熟悉 Prompt Engineering ------写 few-shot、CoT、角色扮演。
2025 年，Andrej Karpathy 提出了 Context Engineering，强调不要只关注 prompt 本身，而要管理整个上下文窗口。
那 Harness Engineering 又是什么？它是再往外扩一层：
- Prompt Engineering：管你给模型的第一句话怎么写
- Context Engineering：管整个上下文窗口里有什么信息
- Harness Engineering ：不光管"给什么信息"，还管"跑在什么环境里"
社区对 Harness 和 Context 的关系有过争议。LangChain 认为 Harness ⊃ Context （超集关系），HumanLayer 则认为 Harness ⊂ Context。
我个人倾向于超集关系------因为沙盒、CI 门禁、版本控制这些显然不属于"上下文管理"，但它们都是 Harness 的核心组成部分。
不过，纠结定义意义不大。重要的是：当 Agent 出问题时，我们不仅要去查"给了什么信息"，还要去看"跑在什么环境里"。
四、案例：同一个模型，只改 Harness
LangChain 做过一个实验，很好地说明了 Harness 的实际影响。
基线 ：deepagents-cli + GPT-5.2-Codex，默认配置，在 Terminal Bench 2.0 上得分 52.8 ，排名 Top 30。
他们只调整了 Harness 上的三个"旋钮"（原话是 "knobs on a harness"）：
- 退出前强制自检
在 Agent 试图退出时拦截，强制注入 checklist，要求对照任务说明验证。解决"写完就停"的问题。 - 启动时注入环境信息
自动扫描目录结构、Python 环境，注入上下文，减少 Agent 在陌生环境中盲目探索。 - 死循环检测
通过 hook 追踪每个文件的编辑次数，超过阈值就注入"考虑换个方案"的提示。 - 推理强度"三明治"策略
规划和验证阶段用高推理（xhigh），执行阶段用中推理（high），避免因全程高推理导致超时。
结果：同一个模型，得分从 52.8 涨到 66.5，排名从 Top 30 冲到 Top 5。
模型一丁点没换，换的全是 Harness。
这个实验告诉我们：很多时候你觉得 Agent 不行，其实是你给它搭的"台子"没搭好。
五、哪些 Harness 设计是持久的？
我们得承认，The Bitter Lesson 一直在起作用：模型会越来越强，很多今天精心设计的 Harness 逻辑，明天可能就过时了。
比如，你现在为了弥补模型推理能力不足而写的复杂控制流，等模型自己会规划了，这些代码就变成了技术债。
那么，哪些 Harness 设计是持久的？
我认为是那些由物理约束决定的东西：
- 文件系统作为持久存储：模型再强，也需要读写文件
- 沙盒隔离：安全边界不会因为模型变聪明而消失
- 版本控制：协作和回滚是工程化的基本需求
另外，LangChain 还提了一个很有意思的观点：Harness 就是你的数据集。
你每跑一次 Agent 任务，都会产生执行轨迹------成功的路径、失败的模式、工具调用的序列。这些数据可以反馈回训练，让下一代模型更适配你的 Harness 环境。模型和 Harness，其实在共同进化（co-evolution）。
六、实践建议：如何开始做 Harness Engineering？
如果你已经在写 CLAUDE.md、配 MCP Server、用 Sub-agent、做上下文压缩------恭喜，你其实已经在做 Harness Engineering 了。
这里有几个可以立刻上手的切入点：
-
记录失败模式
每次 Agent 犯错，不要只改 prompt，而是问自己：能不能通过改环境或加流程，让它以后再也犯不了这个错？
-
加中间件
在 Agent 的关键节点（退出、工具调用、循环）插入检查逻辑。很多 Agent 框架（如 LangGraph、Vercel AI SDK）都支持中间件。
-
注入环境信息
在 Agent 启动时，主动把目录结构、可用工具、环境变量注入上下文，减少它的无效探索。
-
构建持久化反馈回路
把 Agent 的执行轨迹存下来，定期分析失败模式，把高频错误固化到 Harness 中。
七、总结
- Agent = 模型 + Harness。模型负责思考，Harness 负责提供环境、工具、约束。
- Harness Engineering 是通过改变环境与流程，让 Agent 不再犯同样错误的工程实践。
- 同一个模型，只改 Harness，性能可以从 Top 30 冲到 Top 5。
- 不是所有 Harness 设计都会持久，但那些由物理约束决定的（文件系统、沙盒、版本控制）会长期有效。
所以，下次当你觉得 Agent 不好用的时候，先别急着怪模型。
先看看它的 Harness------环境、工具、流程，有没有给够，有没有把坑填上。
如果你对 Agent 工程化感兴趣，欢迎在评论区交流，也欢迎分享你在项目中遇到的"Harness 调优"案例。
参考资料：
- LangChain -- The Anatomy of an Agent Harness (Vivek Trivedi, 2026.03)
- HumanLayer -- Skill Issue: Harness Engineering for Coding Agents (2026.03)
- LangChain -- Improving Deep Agents with harness engineering (2026.02)
- OpenAI -- Harness engineering: leveraging Codex in an agent-first world (2026.02)