Harness Engineering 入门（一）：为什么说"你不是模型，那你就是 Harness"
约 11 分钟3271 字3 次阅读
Harness Engineering 入门（一）：为什么说"你不是模型，那你就是 Harness"
引言
2026年的AI应用开发圈，有一个词正在以惊人的速度成为高频词——Harness Engineering。
这个词最早是 Mitchell Hashimoto 在博客里用的，他原话是："我不知道业界有没有公认的术语，我自己管这叫 harness engineering。" 结果几天后，OpenAI 发了百万字实验报告，Anthropic 放出了全新的多智能体架构设计，Martin Fowler 网站上也有了深度分析。
Harness Engineering 成了讨论 AI Agent 开发绕不开的概念。
一、一个反直觉的实验
先从一个真实的故事说起。
Can.ac 做了个实验：同一个模型，只换了文件编辑接口的调用方式，编码基准分数从 6.7% 直接跳到 68.3%。
模型没变，变的是外围的那套系统。
这意味着什么？意味着你花大价钱买的最新 Claude Opus 4.7，如果 Harness 写得烂，效果可能还不如别人用免费模型的糟糕 Harness。
模型不是瓶颈，基础设施才是。
二、核心定义：Agent = Model + Harness
Harness Engineering 的核心观点可以用一句话概括：
Agent = Model + Harness。你不是模型，那你就是 Harness。
听起来有点绝对？但仔细想想，它确实抓住了关键。
Harness 就是模型之外的一切——系统提示词、工具调用、文件系统、沙箱环境、编排逻辑、钩子中间件、反馈回路、约束机制。
模型本身只是能力的来源。只有通过 Harness 把状态、工具、反馈和约束串起来，它才真正变成一个 Agent。
一个精准的比喻
模型是 CPU，Harness 是操作系统。
CPU 再强，OS 拉胯也白搭。你买了最新款 M5 芯片，装了个崩溃不断的系统，体验还不如老芯片配稳定的 OS。
三、Harness vs Prompt Engineering vs Context Engineering
很多人分不清这三者的关系——它们不是并列关系，而是嵌套关系。
更重要的是，每一层解决的是完全不同的问题：
| 层级 | 解决的核心问题 | 关注点 | 典型工作 |
|---|---|---|---|
| Prompt Engineering | 表达——怎么写好指令 | 塑造局部概率空间 | 系统提示词设计、Few-shot 示例、思维链引导 |
| Context Engineering | 信息——给 Agent 看什么 | 确保正确信息在正确时机到达 | 上下文管理、RAG、记忆注入、Token 优化 |
| Harness Engineering | 执行——系统怎么防崩、怎么量化、怎么持续运转 | 长链路任务中的持续正确、偏差纠正、故障恢复 | 文件系统、沙箱、约束执行、熵管理、反馈回路 |
简单任务里，提示词最重要——你把话说清楚就行。
依赖外部知识的任务里，上下文很关键——你得把正确的信息喂进去。
但长链路、可执行、低容错的真实商业场景里，Harness 才是决定成败的东西。
四、模型做不到的事，就是 Harness 要补的
理解 Harness 最好的方式，不是直接看它包含什么，而是看模型做不到什么。
不管大模型看起来多能干，本质就是一个文本（或图像、音频）进、文本出的函数。
模型做不到的，就是 Harness 要补的：
| 模型做不到 | Harness 怎么补 | 核心组件 |
|---|---|---|
| 记住多轮对话历史 | 维护对话历史，每次请求时拼进上下文 | 记忆系统 |
| 执行代码、跑命令 | 提供 Bash + 代码执行环境 | 通用执行环境 |
| 获取实时信息（新库版本、API 变化） | Web Search、MCP 工具 | 外部知识获取 |
| 操作文件和环境 | 文件系统抽象 + Git 版本控制 | 文件系统 |
| 知道自己做对了没有 | 沙箱环境 + 测试工具 + 浏览器自动化 | 验证闭环 |
| 在长任务中保持连贯 | 上下文压缩、记忆文件、进度追踪 | 上下文管理 |
把这些"模型做不了但你希望 Agent 能做到"的事情一个个补上，就得到了 Harness 的核心组件。
五、为什么瓶颈不在模型，而在 Harness？
说实话，第一次看到这个结论的时候也觉得很反直觉——不是应该等更强的模型出来就好了吗？
但数据确实不支持这个想法。
LangChain 的实验：优化了 Agent 运行环境（文档组织方式、验证回路、追踪系统），在 Terminal Bench 2.0 上从全球第 30 名升到第 5 名，得分从 52.8% 提升到 66.5%。模型没换，Harness 换了。
OpenAI、Anthropic、Stripe 的实践也都指向同一个结论：基础设施才是瓶颈，而非智能水平。
一个值得注意的发现：Model-Harness 耦合问题
LangChain 指出了一个重要问题：当前的 Agent 产品（如 Claude Code、Codex）是模型和 Harness 一起训练的。这导致一种过拟合——换了工具逻辑后模型表现会变差。
在 Terminal Bench 2.0 排行榜上观察到，Opus 在 Claude Code 的 Harness 下的得分，远低于它在其他 Harness 中的得分。
结论就是："The best harness for your task is not necessarily the one a model was post-trained with"——为你的任务选择 Harness 时，不要被模型的默认 Harness 束缚。
六、为什么上下文喂越多，Agent 反而越蠢？
Dex Horthy 观察到一个现象：168K token 的上下文窗口，用到大约 40% 的时候，Agent 的输出质量就开始明显下降。
| 区间占比 | 表现 |
|---|---|
| 0 - ~40% | 推理聚焦、工具调用准确、代码质量高 |
| 超过 ~40% | 幻觉增多、兜圈子、格式混乱、低质量代码 |
Anthropic 在自己的实践中也碰到了类似的问题，他们叫"上下文焦虑"：Sonnet 4.5 在上下文快填满时会变得犹豫，倾向于提前收工——哪怕任务还没做完。
你的目标不是给 Agent 塞更多信息，而是让它在任何时候都运行在干净、相关的上下文里。
七、Harness 六层架构总览
一个成熟的 Harness 有清晰的层次结构：
| 层级 | 名称 | 解决什么问题 |
|---|---|---|
| L1 | 信息边界层 | Agent 该知道什么、不该知道什么 |
| L2 | 工具系统层 | Agent 怎么跟外部世界交互 |
| L3 | 执行编排层 | 多步骤任务怎么串起来 |
| L4 | 记忆与状态层 | 长任务中间结果怎么管 |
| L5 | 评估与观测层 | Agent 怎么知道自己做对了没有 |
| L6 | 约束校验与恢复层 | 出错了怎么办 |
可以类比成给一个新手员工搭建的完整工作环境：
- L1 是岗位说明书（告诉它该关注什么）
- L2 是办公工具（给 ta 用什么干活）
- L3 是标准操作流程（按什么步骤做事）
- L4 是项目管理系统和笔记本（怎么记住做过的事）
- L5 是质检流程（怎么检验做对了没有）
- L6 是红线规则和应急预案（什么事绝对不能做、出了事怎么补救）
⚠️ 不要试图一开始就搭齐六层。从 L1（信息边界）和 L6（约束与恢复）入手，这两层投入产出比最高。
八、工程师的四个段位
你处在哪个阶段？
| Level | 特征 | 工程师角色 |
|---|---|---|
| Level 0 | 无 Harness | 直接给 Agent prompt，无结构化约束 |
| Level 1 | 基础约束 | AGENTS.md + 基础 Linter + 手动测试 |
| Level 2 | 反馈回路 | CI/CD 集成 + 自动化测试 + 进度追踪 |
| Level 3 | 专业化 Agent | 多 Agent 分工 + 分层上下文 + 持久化记忆 |
| Level 4 | 自治循环 | 无人值守并行化 + 自动化熵管理 + 自修复 |
总结
一句话概括 Harness Engineering 做的事情：承认模型有边界，然后把边界之外的需求一个个工程化地补上。
有一句话特别认同：
模型决定了系统的上限，Harness 决定了系统的底线。
在简单任务中提示词最重要，在依赖外部知识的任务中上下文很关键，但在长链路、可执行、低容错的真实商业场景中，Harness 才是 AI 稳定落地的前提条件。
与其纠结选哪个模型，不如先把 Harness 搭好。
标签：#AI #Agent #HarnessEngineering #ContextEngineering #PromptEngineering