同一个AI模型，数据没换，提示词也没改，仅仅更换了模型外部包裹的那层运行环境，在编程基准测试中的成功率就从 42% 跃升到了 78%。
这个数据来自研究者 Nate B Jones 的一项实验。其中唯一的变量就是：模型外面的那层“壳”。
近期，Anthropic 也分享了一篇工程博客，用自己的实验提供了另一组对比数据：使用同一句提示词、同一个模型，运行20分钟花费9美元，产出的程序核心功能是坏的；而换一套运行架构，运行6小时花费200美元，最终得到一个可以实际游玩的游戏。
目前业内的一个共识是，当一项技术被 Anthropic 以官方博客的形式正式分享出来，往往意味着这项技术已成为必需且成熟的方案。
这层至关重要的“壳”，现在有了一个正式的名称：Harness。
围绕它展开的整套工程实践，被称为 Harness Engineering，这无疑是2026年AI工程圈最炙手可热的话题之一。
三代演进：从提示到环境
要理解 Harness Engineering 究竟在解决什么问题，我们需要先回顾它的前两代实践。
2022 到 2024 年，关键词是 Prompt Engineering。核心关注点是如何精心设计一条指令。Few-shot、Chain-of-Thought、角色扮演等技巧，本质上都在打磨单次的输入输出对。
到了 2025 年，Andrej Karpathy 和 Shopify CEO Tobi Lütke 推动了一个新概念：Context Engineering。人们意识到单条提示词已经不够用了，必须为模型动态构建整个上下文环境——包括相关文件、历史对话、工具定义、知识库检索结果——确保模型在做每一个决策时，都能看到所需的全量信息。
时间来到 2026 年 2 月，Harness Engineering 正式登场。
我们可以打一个比方：
- Prompt Engineering 是写好一封内容清晰的邮件。
- Context Engineering 是把所有相关的附件都准确无误地附上。
- Harness Engineering，则是搭建整个高效、稳定的工作环境——让 AI Agent 能够持续、可靠、高质量地完成复杂任务。它包含了上下文工程，但在更高的层面运作，涉及约束、反馈循环、架构规则、工具链以及整个生命周期管理。
这个词最早由 Mitchell Hashimoto——HashiCorp 联合创始人、Terraform 的缔造者——提出。他在今年 2 月的一篇博客中，将自己使用 AI 进行编程的进化历程拆解为六个阶段。其中第五个阶段就叫 Engineer the Harness。
他对这一阶段的定义非常精炼：
每当你发现 Agent 犯了一个错误，你就花时间去工程化一个解决方案，让它再也不会犯同样的错。
他在 Ghostty 项目中实践了这一理念。项目中的 AGENTS.md 文件，其每一行规则都对应着一个 Agent 曾经犯过的具体错误。他表示，这个文件几乎完全解决了所有记录在案的不良行为。
几天后，OpenAI 跟进了一篇重磅博文，随后 Martin Fowler 团队的 Birgitta Böckeler 也进行了深入分析。短短几周内，“Harness Engineering”一词迅速火遍了整个 AI 工程圈。
百万行代码的验证：工程师的新角色
OpenAI 的 Codex 团队进行了一项开创性实验，让整个行业重新思考“工程师”这个角色的未来定义。
他们从一个空的 Git 仓库开始，历时 5 个月，生成了大约 100 万行代码，提交了 1500 个 Pull Request，全部由 AI Agent 完成，人类没有手写一行代码。
团队最初只有 3 名工程师，后来扩展到 7 人。他们使用 GPT-5 驱动的 Codex CLI 从零构建了一个完整的生产级应用。平均每位工程师每天能合并 3.5 个 PR。如果采用传统手工编码方式，预计工期将是现在的 10 倍。
该项目的核心工程师 Ryan Lopopolo 留下了一句深刻总结：构建 Agent 不难，设计 Harness 才难。
在 5 个月的实战中，他们提炼出几条硬核规则：
- 仓库是 Agent 唯一的知识来源。 杜绝信息孤岛，一切决策基于代码库现状。
- 代码不仅要对人类可读，更要对 Agent 可读。 清晰的命名、结构和注释至关重要。
- 架构约束不靠 Prompt，靠 Linter。 用自动化工具而非自然语言来强制实施代码规范。
- 自主性得一步步给。 如同培训新人，权限和职责随能力提升逐步开放。
- 如果 PR 需要大改才能合并，问题不在 Agent，在 Harness。 这表明环境设计存在缺陷，未能引导 Agent 产出符合要求的代码。
OpenAI 团队这样总结自己的新角色：当前最大的挑战，在于设计环境、构建反馈循环和优化控制系统。工程师们不再专注于写代码，而是编写规则。
Cursor 团队在另一项长期编码实验中也发现了一个反直觉的结论：约束解空间，反而让 Agent 更有生产力。 当模型可以天马行空地生成任何东西时，它会浪费大量 Token 去探索死胡同。而当 Harness 定义了清晰的边界和路径时，Agent 反而能更快地收敛到正确答案。
不止 OpenAI：行业集体转向
如果只有 OpenAI 一家在实践，Harness Engineering 可能只是个例。但事实是，多家顶尖技术公司几乎同步走向了同一方向。
Stripe 的内部系统「Minions」，每周合并超过 1300 个 PR，全部由无人值守的 Agent 完成。
其架构中有一个值得注意的设计：Blueprint 编排系统。它将工作流明确拆分为确定性节点和Agentic 节点。
- 确定性节点——如运行 Linter、推送更改——按照固定路径执行，不调用大模型。
- Agentic 节点——如实现新功能、修复 CI 失败——则交由模型进行判断和决策。
Stripe 还设定了一条硬性规则：CI 最多只运行两轮。第一轮失败，Agent 会自动尝试修复并再跑一次。如果再次失败，任务将直接转交人类处理，不允许 Agent 在 CI 上进行无限重试。
此外，他们内部的工具平台集成了大约 500 个 MCP 工具，但提供给每个 Agent 的只是经过精心筛选的子集。因为他们发现：更多的工具并不等于更好的表现。
Stripe 工程团队的总结一针见血：成功取决于可靠的开发者环境、健壮的测试基础设施和高效的反馈循环，与选择哪个特定模型关系不大。
Cursor 的「自驱动代码库」研究走得更远——达到每小时约 1000 次 commit，一周内超过 1000 万次工具调用，启动后无需人工干预。
但他们所走过的弯路，恰恰证明了 Harness 设计的复杂性：
- 第一版采用单 Agent，无法处理复杂任务。
- 第二版引入多 Agent 但共享状态文件，导致锁竞争严重，Agent 之间“互相打架”。
- 第三版尝试结构化角色分工，又显得过于僵硬。
- 第四版的持续执行器则导致角色过载。
- 最终版本才确定为递归的 Planner-Worker 模型。
他们还观察到一个颇具黑色幽默的现象：一条模糊的初始指令，在数百个并发 Agent 的执行过程中会被不断放大。一个 Agent 犯的错，乘以几百倍的并发量，结果可想而知。
底层挑战：模型不会自我反省
上述案例都在解决同一个问题：如何让 Agent 持续、稳定地产出高质量代码。但有一个更底层的问题，直到 Anthropic 的这篇博客才被清晰地剖析出来：模型不会准确评价自己的工作。
Anthropic 的工程师发现，当你要求 Agent 评估它刚完成的工作时，它会表现出高度的自信并给出积极评价，即使这些工作在人类看来质量明显平庸。
这个问题在主观性任务上（例如前端设计、UI/UX 评判）尤为突出，因为缺乏像软件测试那样非对即错的二元标准。但即使在有客观标准的任务中，Agent 的自我判断也经常失灵。
这恰恰是 Harness 需要存在的根本原因之一：模型本身具备了强大的能力，但它对自己的能力边界缺乏准确的认知。
Anthropic 的解法借鉴了生成对抗网络（GAN）的思路：将生成和评估拆解为两个独立的 Agent。 一个 Generator 负责编写代码，一个 Evaluator 负责评审验收。这个 Evaluator 并非简单地看截图打分，而是使用 Playwright 等工具真实地去点击页面、调用 API、检查数据库状态，像一个真正的 QA 工程师一样进行操作后再给出反馈。
然而，Evaluator 也并非天生可靠。开箱即用的 Claude 本身是一个很差的 QA Agent。 早期的 Evaluator 会发现问题，但容易说服自己“这不是大问题”，然后予以批准。它也倾向于进行表面测试，而非深入探索边界情况。团队花了多轮迭代来校准 Evaluator 的判断标准，使其严苛程度符合人类工程师的期望。
关键在于，让一个独立的 Evaluator 变得严格，远比让 Generator 学会自我批评容易得多。 这就是职责分离的价值所在。
他们进行了一系列全栈开发测试，采用了一套包含 3 个 Agent 的架构：Planner 将一句话需求拆解为完整的产品规格；Generator 按照迭代计划逐个实现功能；Evaluator 则在每个迭代结束后进行真机验收。
Solo 模式（无独立Evaluator）下的输出看起来界面完整，但核心功能是坏的，从界面上难以直观发现。
Harness 模式下产出的版本，编辑器功能更完备，游戏可以实际游玩，物理引擎虽有些粗糙，但核心交互是通畅的。
并且，Evaluator 能够提供精确到代码行级别的 Bug 报告。
数据调研：Harness 带来的显著提升
通过对多家公司发布的数据进行调研，Harness 带来的价值提升显而易见：
- LangChain：同一模型（gpt-5.2-codex），仅更改 Harness，在 Terminal Bench 2.0 上的成绩从 52.8% 提升至 66.5%，排名从三十名开外直接跃升至前五。
- Nate B Jones：同一模型，不同的 Harness，成功率分别为 42% 和 78%。更换 Harness 带来的提升幅度，相当于迭代了一代模型。
- Anthropic：Solo 模式：20 分钟 / $9（功能不可用）。基础 Harness 模式：6 小时 /$200（功能可用）。优化后的 Harness：约 4 小时 / $125。
- Terminal Bench 2.0：Claude Opus 4.6 在默认的 Claude Code Harness 上排名第 33，更换另一个 Harness 后冲至第 5。同一模型，同一基准，排名相差 28 位。
- Pi Research：仅用一个下午的时间，仅通过修改 Harness，就提升了 15 个不同大语言模型的编程能力。其论文标题就是《Improving 15 LLMs at Coding in One Afternoon. Only the Harness Changed》。
众多数据都指向同一个结论：在当前阶段，优化模型外部的“壳”（Harness），其投资回报率可能比单纯等待下一代更强的基础模型要高得多。
反对声音：Bitter Lesson 的启示
当然，并非所有人都完全认同 Harness Engineering 的长期价值。
OpenAI 的 Noam Brown 在一次访谈中直言：Harness 就像一根拐杖，我们终将超越它。
他的理由是：在具备强推理能力的模型出现之前，开发者不得不在 GPT-4o 等模型之上搭建复杂的多智能体系统来模拟推理过程，例如路由器、编排器和多 Agent 协作框架。然而，当真正的推理模型问世后，这些复杂的工程“拐杖”在一夜之间变得不再必要，甚至在许多场景下反而降低了效率。
他的预测是，OpenAI 将走向一个“统一模型”的未来，用户不应该需要在模型之上再叠加一个路由层。他给开发者的建议颇为直接：
别花六个月搭建一个可能六个月后就被淘汰的东西。
METR 的一项研究数据也给 Harness 阵营带来了一些冷思考。
他们邀请了 scikit-learn、Sphinx 和 pytest 这三个知名开源项目的活跃维护者，审查了 296 个由 AI 生成并通过了自动化评分（SWE-bench Verified）的 PR。结果发现：维护者实际的合并率大约只有自动化评分通过率的一半。
自动评分器认为 Agent 能够独立完成耗时约 50 分钟的任务，但维护者实际愿意合并的 PR 所对应的任务范围平均只有 8 分钟左右——存在高达 7 倍的能力高估。
这一派观点常被称作“Bitter Lesson”阵营，其思想源自 Rich Sutton 那篇著名的随笔：不要在复杂的工程技巧上过度投入，因为长远来看，计算力的指数级增长终将碾平这些暂时性的障碍。
持续进化：Harness 的可能性空间在平移
Noam Brown 的观点是否正确？从 Anthropic 自己的实验来看，他的判断对了一半。
他们最早的 Harness 基于 Claude Opus 4.5 设计，需要将工作拆分为多个 Sprint（冲刺），每个 Sprint 完成一个功能，并且在 Sprint 之间进行上下文重置。这是因为 Opus 4.5 存在一种“上下文焦虑”，当它感知到上下文窗口即将耗尽时，会提前开始草率收尾，导致质量骤降。整套 Sprint 机制正是为了应对这个模型本身的缺陷。
随后，Opus 4.6 版本发布了。这个新版本在长期任务规划上更谨慎、更稳定，长上下文检索能力更强，自我 Debug 的能力也提升了。于是，Anthropic 直接砍掉了 Sprint 结构，让 Generator 连续运行两个多小时完成整个构建，期间没有崩溃。
在这里，Noam Brown 所说的“拐杖”（Sprint机制）确实被扔掉了。
但是，Evaluator 并没有被扔掉。
因为即使 Opus 4.6 变强了，它的能力边界也只是向外扩展了一些，边界本身并未消失。在边界内的任务，Generator 可以独立搞定，Evaluator 似乎是多余开销；但在边界附近的任务上，Evaluator 依然能捕获 Generator 自身无法察觉的问题——例如功能实现流于表面、因 API 路由定义顺序导致的隐蔽 Bug、交互逻辑的缺失等。
Anthropic 据此给出了一个关键判断：Harness 的可能性空间不会随着模型进步而缩小，它只是在发生平移。
模型变强了，旧的、用于弥补模型缺陷的约束可以被拆除。但同时，新的、更高阶的约束空间被打开了。以前你需要教 Agent 如何管理上下文焦虑，现在不需要了；但现在你可以尝试让它进行长达四小时的自主开发任务，这又需要设计新的任务分解、进度监控和验收反馈机制。
这种演进并非孤例。Manus 在 6 个月内重构了 5 次 Harness；LangChain 在一年内重新架构了 3 次研究型 Agent；Vercel 则砍掉了 80% 的 Agent 工具。这些都说明：Harness 不是一劳永逸的静态工程，而是一个需要持续演化的动态系统。
Anthropic 那篇博客的结尾写道：
有趣的 Harness 组合空间不会随着模型进步而缩小，它只是在移动。而 AI 工程师真正要做的，是持续找到下一个有效的组合。
写在最后
OpenAI 的 Codex 团队不再专注于写业务代码，而是编写架构规则、Linter 配置和 AGENTS.md 文件。Stripe 的工程师不再手动实现功能，而是设计 Blueprint 工作流编排和 CI 限速策略。Anthropic 的工程师不再直接编程，而是校准 Evaluator 的评分标准和验收逻辑。
编写代码，正在变成一件成本相对较低的事。 而设计那套能让 AI Agent 持续、稳定、高质量编写代码的 系统（Harness），才是当前真正具有挑战性和高价值的部分。
并且，这套系统本身也不是永恒的。每一代更强的基础模型发布，工程师都需要重新审视：哪些约束已经过时可以移除？哪些新的可能性可以被探索？哪些更高阶的挑战需要新的约束来应对？
真正的稀缺能力，或许不在模型内部，而在模型外部。而且，这项能力每隔几个月，就可能需要你重写一次。对于热衷于探索 AI 工程化前沿的开发者而言，不妨在 云栈社区 与其他同行交流更多关于 Harness 设计的实战经验与技术文档。
发表于 昨天 21:17
|
查看: 3|
回复: 0
