通俗解读 AI 领域的 Harness 概念——从 Eval Harness 到 Agent Harness，基于 Anthropic 2025-2026 工程博客系列的核心洞察
2026 年 AI 工程领域最热的词之一不是某个新模型，而是 Harness——一个决定 AI 产出质量上限的隐形系统。
Harness（直译"挽具"）在 AI 领域指的是：包裹在模型外面的那一整套运行环境、指令、工具和流程编排——它决定了同一个模型能发挥出 30% 还是 90% 的实力。
打个比方：模型是一匹马，harness 就是套在马身上的挽具和缰绳。没有挽具的马可以乱跑，但拉不了车；好的挽具让马的力量精准地转化成有用的牵引力。
过去几年，行业的焦点一直在"造更大的模型"上。但到了 2026 年，一个共识浮出水面：
同一个模型，在不同的 harness 下，产出的质量天差地别。
Anthropic 在 2026 年 3 月的工程博客中用一个实验说明了这一点：
| 方式 | 耗时 | 花费 | 结果 |
|---|---|---|---|
| 裸跑（无 harness） | 20 分钟 | $9 | 游戏做出来了，但核心功能是坏的 |
| 精心设计的 harness | 6 小时 | $200 | 功能完整、可实际游玩、内置 AI 辅助 |
两次用的是同一个模型（Opus 4.5），唯一的区别就是 harness。
一个典型的 AI agent harness 通常包含以下几层：
人类工程师面对一个大项目时，会先拆分成可管理的小任务。AI 也需要被"教会"这样做。
Anthropic 的做法是用一个 Planner Agent 将用户的一句话需求（如"做一个复古游戏编辑器"）扩展成包含十几个功能点、分成多个 sprint 的完整产品规格。
为什么这很重要？ 如果不拆解，AI 会试图一口气写完所有代码——然后在中途耗尽上下文窗口，留下一堆半成品。
这一层定义了 AI 工作时能用什么工具、怎么保存进度、怎么从上一次的工作中接续。具体包括：
progress.txt 让下一个 session 的 agent 快速了解当前状态init.sh 让 agent 不用猜怎么跑项目这是 2026 年 harness 工程最大的突破点。核心发现是：
AI 不擅长评价自己的工作。
当你让 AI 评估自己写的代码或做的设计时，它倾向于自信地说"干得不错"——哪怕质量很一般。这就像让学生给自己的考卷打分。
解决办法借鉴了 GAN（对抗生成网络）的思路：把"做事"和"评判"分给两个不同的 agent。
AI 模型有一个天然限制：上下文窗口是有限的。 当一个任务需要数小时甚至数天才能完成时，模型不可能在一个窗口里记住所有信息。
更糟糕的是，Anthropic 发现了一种叫 "Context Anxiety"（上下文焦虑） 的现象：当模型"感觉"自己快要用完上下文时，会提前草草收尾，而不是做完应该做的事。
Harness 需要管理这个问题——通过 context reset（清空重启 + 结构化交接）或 compaction（压缩历史记录），让 agent 能跨多个 session 持续工作。
一个反直觉的发现是：harness 不是越复杂越好。
Anthropic 的演进路径很有代表性：
Sonnet 4.5 时期
├── 需要 context reset（模型有严重的上下文焦虑）
├── 需要 sprint 分解（模型无法长时间连贯工作）
├── 需要三 agent 架构（Planner + Generator + Evaluator）
└── 需要文件交接协议（sprint contract）
↓ 模型升级 ↓
Opus 4.6 时期
├── 移除 context reset（模型自身能保持连贯）
├── 移除 sprint 分解（模型能连续工作 2+ 小时）
├── 保留 Planner（仍需要扩展需求规格）
└── Evaluator 变为按需（只在超出模型能力边界时有用）
这背后的原则是：harness 中的每个组件都是对"模型自己做不到什么"的假设。当模型进步了，假设就要重新验证。
用 Anthropic 经典文章 Building Effective Agents 的话说：找到最简单的可行方案，只在需要时增加复杂度。
在 AI 领域看到"harness"这个词时，它可能指两个不同的东西：
用于测试和打分模型表现的标准化工具。最知名的是 EleutherAI 的 lm-evaluation-harness，支持数百个 benchmark，是 LLM 社区最广泛使用的评估框架。
类比：考试系统——出题、收卷、批改、统计分数。
用于编排和控制 AI agent 执行复杂任务的运行环境。这正是 Anthropic 两篇博文讨论的重点。
类比：施工脚手架——工人（模型）的能力没变，但有了脚手架就能安全高效地盖高楼。
2026 年社区里说的"Harness Engineering"大多指第二种含义。
无论你是开发者还是设计师，harness 思维都可以应用到日常的 AI 协作中：
1. 别让 AI 一口气做完所有事。 把任务拆成明确的步骤，每步有清晰的验收标准。
2. 不要相信 AI 的自我评价。 如果你让 AI 写完代码后自己检查，它大概率会说"看起来不错"。让它实际运行、实际测试，或者用另一个 prompt 专门做 review。
3. 给 AI 留进度笔记。 长任务跨多个对话时，让 AI 在每次结束前总结当前状态和下一步计划，下一次对话开头先读这个总结。
4. 随模型升级简化流程。 你为 Sonnet 设计的复杂 prompt 流程，在 Opus 上可能是多余的。定期测试哪些步骤还真正有用。
5. 把"怎么工作"和"做什么工作"分开思考。 Harness 是"怎么工作"，prompt 是"做什么工作"。前者往往比后者更能决定最终质量。