Agent 很强，但 Harness 才是那个决定成败的东西

一个安全研究员，只改了一个代码编辑格式，把 patch 换成他自己设计的 Hashline，然后测试分数从 6.7% 飙到 68.3%。

底层模型，一个参数都没动。

另一边，LangChain 花了几个月优化编程 Agent 的外部环境——文档结构、验证回路、追踪系统——基准测试从 52.8% 跳到 66.5%，排名从全球第 30 名前进到前 5。同样的模型。

这两件事，同一个结论：

2025 年 AI 证明了它能写代码。2026 年我们才意识到，Agent 本身从来不是难点——Harness 才是。

---

Harness 是什么？

Harness 的字面意思是"马具"——缰绳、马鞍、嚼子，一整套用来引导一匹力量惊人但不受控的动物走向正确方向的设备。

这个比喻是刻意的：

• 马 = AI 模型：力量强大，速度惊人，但它不知道该往哪走
• Harness = 马具：约束、护栏、反馈回路，把模型的力量变成真正的生产力
• 骑手 = 人类工程师：提供方向，但不亲自奔跑

没有 Harness 的 AI Agent，就像一匹在旷野里狂奔的纯血赛马——速度快得惊人，看起来很震撼，但对你要完成的任务毫无帮助。

所以什么是 Harness Engineering（驾驭工程）？

它是设计和实施这套系统的工程学科。具体做四件事：

• 约束（Constrain）：规定 Agent 能做什么、不能做什么
• 告知（Inform）：确保 Agent 在正确的时间拿到正确的信息
• 验证（Verify）：检查 Agent 是否正确完成了任务
• 纠正（Correct）：Agent 出错时自动修复，而不是等着人工收拾烂摊子

---

这个概念从哪来的

2026 年 2 月 5 日，HashiCorp 联合创始人 Mitchell Hashimoto 在他的博客文章里第一次喊出了"Harness Engineering"这个词。

他在 AI 辅助开发实践中发现了一个关键问题：

anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent will not make that mistake again in the future.

翻译成人话：每次 Agent 犯错，正确的回应不是换一个模型，而是重新设计它运行的环境。

六天后，OpenAI 发布了一份详细实验报告，标题直接用了这个词。再然后，Martin Fowler 在 Twitter 上给 Thoughtworks 工程师的深度分析站台。

一个月之内，Harness Engineering 从一篇博客变成了开发者社区的高频词。

---

一个故事说明白

说个具体的。

你用过 Claude Code 或者 Cursor 吗？刚装上的时候很惊艳，用了两天开始骂街——它会跑偏，会重复做一件事，会生成一堆你不需要的文件，会忘记你刚刚说的约束。

这个时候你的第一反应是什么？换一个模型？GPT-4 不行换 Opus，Opus 不行换 Sonnet？

Harness Engineering 的回答是：先别换模型。你那个模型本来就很强，问题出在它跑的那个"环境"上。

类比一下。你有一把特别锋利的刀，但每次切菜都切到手。你不会去换一把"更锋利"的刀——你会去装一个防滑手柄，加一个护指套，搞一套正确的切菜手法。

刀还是那把刀。但环境变了。

---

Harness 的三大支柱

这是最硬的部分。

OpenAI 的报告把 Harness Engineering 分成了三个核心类别，理解了这三个类别，就理解了这个领域在干什么。

第一根支柱：上下文工程（Context Engineering）

不是塞给 Agent 一堆文档就完事了。上下文工程的核心问题是：Agent 在正确的时间看到了正确的东西吗？

这里面分两类：

静态上下文，是你提前准备好的：

• 代码库的架构规范、API 契约、风格指南
• AGENTS.md 或者 CLAUDE.md——写清楚这个项目的规则
• Linter 验证过的交叉链接设计文档

动态上下文，是 Agent 运行过程中实时获取的：

• 可观测性数据：日志、指标、追踪链路
• Agent 启动时的目录结构映射
• CI/CD 流水线状态、测试结果

关键原则只有一条：从 Agent 的角度看，任何它上下文中访问不到的东西，就等于不存在。

Google Docs 里的架构决策、Slack 里的讨论、工程师脑子里的约定——对 Agent 来说全是盲区。代码库必须是唯一的真理来源。

这也解释了为什么很多人抱怨"Agent 不听话"——不是模型的问题，是你把规则写在了它看不到的地方。

第二根支柱：架构约束（Architectural Constraints）

这是 Harness Engineering 和传统 Prompt Engineering 差距最大的地方。

传统做法：告诉 Agent"写出好代码"，然后祈祷它听懂了。

Harness 做法：不告诉它什么叫好代码，直接强制规定好代码长什么样。

举个例子。OpenAI 的 Codex 团队要求 Agent “在边界处解析数据形状”，但不规定具体实现方式。这不是提示，是约束——通过结构化测试和 CI 校验强制执行的。

依赖分层也是一个典型：

Types → Config → Repo → Service → Runtime → UI

每一层只能从左侧的层导入。这不是建议，是用工具强制检查的。

约束执行的工具包括：

• 确定性 Linter：自动标记违规的自定义规则
• LLM 审计员：专门审查其他 Agent 代码是否合规的 Agent
• 结构化测试：类似 ArchUnit，但针对 AI 生成的代码
• Pre-commit 钩子：任何代码提交前必须通过检查

这里有一个反直觉的事实：限制解决方案空间，反而让 Agent 的产出质量更高。

当 Agent 可以生成"任何东西"时，它会浪费大量 token 去探索死路。当 Harness 划定了清晰的边界，Agent 能更快收敛到正确的解。

第三根支柱：熵管理（Entropy Management / 垃圾回收）

这是最容易被忽视的一根柱子。

随着时间推移，AI 生成的代码库会积累"熵"——文档与现实脱节、命名约定偏离、死代码堆积。相当于一间房子越住越乱，但没人收拾。

Harness Engineering 的做法是：设置定期运行的 Agent，专门负责清理。

• 文档一致性 Agent：验证文档是否与当前代码匹配
• 约束违规扫描器：抓取漏网之鱼
• 模式强化 Agent：修复偏离既定模式的代码
• 依赖审计员：追踪循环依赖和不必要的依赖

这些 Agent 按计划运行（每天或每周），或者由特定事件触发（代码提交、发布前）。保持代码库对人类和未来的 AI Agent 都处于健康状态。

---

Anthropic 补充的第四根柱子：Generator-Evaluator 架构

Anthropic 的工程团队在构建前端设计和全栈开发 Harness 时，发现了一个 OpenAI 那篇文章没提到的问题——

Agent 打分永远给自己打高分。

当你让一个 Agent 做一件事，然后问它"你做得怎么样"，它永远会回答"很好，不错，继续"。这不是因为它骄傲，而是因为它没有外部参照物来评判自己的产出。

Anthropic 的解决思路来自 GAN（生成对抗网络）的灵感：把做事的 Agent 和评判的 Agent 分开。

他们设计了一个三 Agent 架构：

• Planner Agent：把用户的一句话需求展开成完整的产品规格说明书
• Generator Agent：一个功能一个功能地写代码，每个 sprint 完成一个小目标
• Evaluator Agent：独立评估每次 sprint 的产出，不通过代码看结果，而是实际操控页面来验证

Evaluator 这个设计最有意思。它不是读代码然后打分，而是用 Playwright MCP 实际打开页面、点击按钮、测试功能、截图研究，然后打分。这解决了一个常见问题：Agent 写的代码可能通过所有静态检查，但一跑起来各种 bug。

Grading Criteria：把主观判断变成可打分的标准

Evaluator 之所以能有效评分，关键在于 Anthropic 设计了一套具体的评分维度——把"这个设计好不好"这种主观问题，转化成可衡量的标准：

维度	问题	说明
Design Quality	设计是否像是一个整体而非部件拼凑？	颜色、字体、布局是否形成统一风格
Originality	有没有定制化的决策，还是全是模板和默认值？	过度使用 AI 常见样式会扣分
Craft	技术实现水平：字体层级、间距一致性、色调和谐度	基础功是否扎实
Functionality	独立于美学之外的可用性	用户能否顺利完成操作

这套维度的关键是：Criteria 本身就是对 Agent 的引导。 把"原创性"写进评分标准，Agent 在生成时就会主动避免 AI 常见样式，因为知道这会扣分。

Context Anxiety：模型会在上下文快满时提前收尾

Anthropic 还提到了一个之前没人提到的现象：Context Anxiety。

当模型的上下文窗口快满的时候，有些模型（尤其是早期 Sonnet 版本）会开始"提前收尾"——它觉得自己快装不下了，于是开始草草结束任务，而不是等到任务真正完成。

解决方案是上下文重置：清空上下文窗口，用结构化的handoff 在会话之间传递状态。Anthropic 发现 Sonnet 4.5 这个倾向特别严重，必须靠上下文重置才能正常跑长任务。到了 Opus 4.5，这个问题基本消失，所以后续的 Harness 设计里去掉了这步。

这是一个重要的工程细节：Harness 设计要跟着模型版本走。同一个 Harness，在不同模型上可能表现差异很大。

---

一个数字改变一个认知

LangChain 的案例值得单独说一次。

他们在 Terminal Bench 2.0 基准测试上做了这件事：

变更项	影响
自验证循环	增加完成前检查清单
中间件	提交前捕获错误
上下文工程	启动时映射目录结构
循环检测	防止重复文件编辑
推理三明治	高推理用于规划/验证，中等推理用于执行

结果：得分从 52.8% 飙到 66.5%，排名从前 30 跃升到前 5。

底层模型，一个参数没改。

这是 Harness Engineering 最有力的实证。

---

为什么 Prompt Engineering 已经不够用了

你可能还记得"vibe coding"这个词——YC 发的指南强调"你主导决策，AI 负责执行"。

这套方法论在当时是对的，它刷新了很多人的认知。

但问题在于：无论 Prompt 多精妙，如果 Agent 运行的脚手架不稳，一切都是空中楼阁。

三层对比：

• Prompt Engineering 关注的是"说什么"
• Context Engineering 关注的是"给什么上下文"
• Harness Engineering 关注的是"在什么条件下运行"

脚手架不稳，再好的设计师也爬不到高处。

---

一个反直觉的判断

说到这，我想直接亮一个观点：

未来三到五年，模型能力的差异会越来越小，但 Harness 的差异会越来越大。

模型正在变得商品化。GPT-4、Claude 3.5、Gemini，每一个拿出来在基准测试上差距都在个位数百分点。对用户来说，体感差异远没有宣传的那么大。

但 Harness 呢？每个团队、每个产品、每个场景设计出来的 Harness 完全不同。这就是真正的竞争壁垒。

一个基于成熟 Harness 的 GPT-4，大概率比一个基于粗糙手工的 GPT-5 更能在生产环境中可靠地完成任务。

在 AI 时代，真正的护城河不是模型，而是模型运行的环境。

---

怎么看自己有没有 Harness 问题

几个信号：

1. Agent 经常跑偏：给了一个任务，它做出来的方向不对。不是它理解错了，是你没在正确位置写清楚规则。

2. 同一个错误重复犯：Agent 删了 A 文件，你纠正了，下次它删了 B 文件。问题不在模型，在缺乏反馈回路。

3. 文档和代码对不上：你改了代码，文档没更新，Agent 看到的是过时信息，然后基于过时信息做了决策。缺乏熵管理。

4. 每次发布都要人工兜底：Agent 生成的代码必须有人检查一遍才能发布。好的 Harness 应该让 Agent 的产出直接可用，不需要二次人工审核。

---

结尾留一个问题

文章最后，我想把这个问题抛给你：

你现在用 AI 的方式，是在"优化 Prompt"，还是在"设计环境"？

这两个方向产出的结果，差距会越来越大。

如果你每次用 AI 的方式都是"这个 Prompt 不够好，我再改改措辞"——你在第一层。

如果你开始思考"我有没有把规则放在它能看到的地方"、“我有没有给它装反馈回路”、“我有没有设置约束防止它跑偏”——你开始进入 Harness 的世界。

大部分人还在第一层。这是先上车的人的机会。

---

参考资料

1. Mitchell Hashimoto — “My AI Adoption Journey”
HashiCorp 联合创始人，2026 年 2 月 5 日第一次提出"Harness Engineering"这个词。原文核心观点：每次 Agent 犯错，正确的回应不是换模型，而是重新设计它运行的环境。

2. OpenAI — “Harness Engineering: leveraging Codex in an agent-first world”
OpenAI 官方报告，详细描述了如何通过 Harness 系统在零人工代码的情况下构建 100 万行生产级应用。5 个月开发，100 万+ 行代码，全部由 Codex Agent 生成，构建时间约为人工的 1/10。

3. Anthropic — “Harness design for long-running application development”
Anthropic 工程团队关于 Generator-Evaluator 双 Agent 架构的核心实践，包含 Planner-Generator-Evaluator 三层设计、Grading Criteria 方法论、以及 Context Anxiety 现象的首次系统性描述。

4. Can Boluk — “I Improved 15 LLMs at Coding in One Afternoon. Only the Harness Changed”
安全研究员仅通过改变代码编辑格式（patch → Hashline），让基准得分从 6.7% 跃升至 68.3%，证明 Harness 的改变有时比模型升级效果更显著。

5. LangChain Terminal Bench 2.0 Results
LangChain 通过优化 Agent 的外部环境（文档结构、验证回路、追踪系统），在底层模型未改动的情况下，得分从 52.8% 提升到 66.5%，排名从前 30 跃升至前 5。

6. Martin Fowler — Harness Engineering
知名软件架构师，在 Twitter 上为 Harness Engineering 概念和分析站台，将其定义为"约束 AI Agent 的工具和实践的系统"。