Harness Engineering 为什么成了 2026 年最热门的技术词

2026 年开始，AI 工程圈出现了一个有意思的现象。

年初大家还在聊怎么写更好的 Prompt，年中这个词就突然变得很少有人提了。取而代之的是一个新词 Harness。这个词不是被某个小团队发明出来再扩散的，是被 OpenAI 和 Anthropic 这两家头部公司几乎同时推到了台前：

2 月 11 日：OpenAI 发布博客《Harness engineering: leveraging Codex in an agent-first world》
4 月 17 日：Augment Code 发布《Harness Engineering for AI Coding Agents》
4 月 20 日：Anthropic 三周内连发三篇工程论文，主题是 effective harnesses、harness design、managed agents
5 月 16 日：Medium 上 Mario Tort 整理《AI Agent Best Practices: Production-Ready Harness Engineering (2026 Guide)》

四个月里，AI 头部厂商和独立工程师围绕同一概念密集发声。这在以前是很少见的，通常一个新概念要扩散到这个密度，需要一两年。

这个词突然爆火背后是一个判断：Prompt Engineering 时代结束了，Harness Engineering 时代开始了。

我之前写过一篇《AI Agent 真正的分水岭：不是模型，而是可验证的 Harness》，偏技术细节。今天想从行业动作的角度，聊聊 为什么是 2026 年、为什么是 Harness 这个词、为什么 OpenAI 和 Anthropic 几乎同时押注它。

一、从行业动作里看到的趋势

如果只看"厂商在写新论文"，你会觉得这就是正常的科研节奏。

但如果把 2025 年底到 2026 年中的几件大事放在一起看，会发现这条线指的方向是一致的。

时间	事件	含义
2025 Q4	Claude Code 工作流被多篇博客复盘	大家开始意识到"光会写 Prompt 不够"
2026 年 1 月	Claude Code 1 周年，被认为"解决了 AI 编程问题"	但紧接着开始出现反弹——“贵、不稳定、需要工程化”
2026 年 2 月	OpenAI 发布 Harness Engineering 论文	第一次把"围绕 Agent 的工程"这个概念正式命名
2026 年 3-4 月	Anthropic 集中发表三篇相关论文	等于从对手角度确认了这个方向的价值
2026 年 4 月	AHE 框架（Agentic Harness Engineering）发布	把 Harness 变成可量化、可自动优化的对象
2026 年 5 月	社区开始把 Harness 写入"必备技能"	招聘 JD 里开始出现"Harness Engineering experience"

这条线的发展速度，比"Prompt Engineering"被广泛接受要快得多。后者用了大约 2 年（2022 年底到 2024 年），前者只用了 4 个月。

为什么这么快？因为 Prompt Engineering 的痛点已经被所有人共同感受到了。

二、为什么 Prompt Engineering 不够用了

2023 年和 2024 年，大家追捧 Prompt Engineering 的核心原因是：模型本身还不够强，需要靠精巧的提示来"挤"出更好的输出。

那时候一个好的 Prompt 工程师，确实能比一般用户多出 30%-50% 的可用性。这是真实存在的红利。

但到 2025 年底，模型本身的能力快速跃迁：

Claude Opus 4.5/4.6 在 SWE-Bench 上超过 60%
GPT-5 系列在多步推理上接近人类水平
开源模型（Qwen 3.5、Llama 4、Gemma 4）在垂直任务上已经能商用

模型能力上来之后，Prompt 的边际收益快速衰减。

举个具体例子：以前你得花 30 分钟设计一个 chain-of-thought Prompt，才能让模型正确拆解一个 5 步任务。现在你直接说"把这件事拆成 5 步做"，模型就能做对。

Prompt 的精雕细琢，变成了不必要的成本。

但这并不意味着"什么都不用做"。相反，问题转移了：

Prompt 不重要了，但 怎么让 Agent 跑完一个长任务不出错 变得重要
单次对话不重要了，但 怎么管理 Agent 的状态、记忆、工具调用 变得重要
文字指令不重要了，但 怎么让 Agent 在出错时自我恢复、在遇到歧义时主动问 变得重要

这些都不是 Prompt 能解决的问题。它们需要的是一套工程基础设施，也就是 Harness。

三、Harness 到底是什么

为了避免这个词变得过于抽象，先给一个具体定义。

按 OpenAI 在 2 月那篇博客里的说法：

A harness is the scaffold—the orchestration, context management, tool wiring, permission boundaries, and recovery loops—that sits between the model and the real world.

Prompt 时代 vs Harness 时代

翻译成中文：Harness 是 Agent 脚手架，包含编排、上下文管理、工具接入、权限边界、错误恢复这一整套让模型能稳定工作的工程层。

如果用软件工程的类比：

Prompt 像是函数调用。你给它输入，它给你输出
Harness 像是整个运行时。它管理内存、调度、IO、异常、资源

也就是说，Prompt 是 API 层，Harness 是操作系统层。

一个完整的 Harness 通常包含这几层组件（这是我综合多份资料整理的，不是某个单一来源的定义）：

Harness 七层组件架构

上下文工程（Context Engineering）：决定什么时候读什么文件、保留哪些历史、用什么格式
工具注册表（Tool Registry）：Agent 能调用哪些工具、怎么调用、参数怎么校验
权限系统（Permission System）：哪些操作需要用户确认，哪些可以自动跑
状态机（State Machine）：任务在"等待/执行/失败/完成"之间的转换逻辑
错误恢复（Recovery Loop）：工具调用失败、模型输出异常时怎么办
可观测性（Observability）：每一步做了什么、花了多少 token、为什么这么决定
子代理编排（Sub-agent Orchestration）：什么时候分拆任务、怎么合并结果

把这几层组合起来，就是一个 Harness。Claude Code、Codex 这些产品，本质上都是 Harness 的具体实现。

四、为什么是 2026 年

到这里其实还有个问题没回答：为什么 OpenAI 和 Anthropic 几乎同时押注 Harness 这个词？

我的判断是，三股力量在 2026 年初汇合了。

第一股：模型能力的同质化

GPT-5.5、Claude Opus 4.6、Gemini 3 Pro 在 SWE-Bench 这类硬指标上的差距，已经从 2023 年的 30%+ 缩小到 2026 年的 5% 以内。

当模型本身不再是差异点时，差异点就转移到了 Harness 上。

这就是为什么 OpenAI 和 Anthropic 都在大力宣传自己的 Harness 设计。他们卖的不只是模型，是"模型 + Harness 整体体验"。

第二股：企业级部署的爆发

2025 年开始，Agent 进入企业生产环境。但企业部署 Agent 很快发现：

一次 token 失控能烧掉 $5000
一个有歧义的指令能导致 Agent 删错文件
一次工具调用失败能让 Agent 死循环

这些问题都出在 Harness 上，不在模型上。企业级 Agent 部署的需求，把 Harness Engineering 从"可选优化"逼成了"必备技能"。

第三股：Agentic Harness Engineering 的可量化结果

AHE 框架（4 月发布）把 Harness 推到了一个新的高度。它能自动进化。

简单说，AHE 把 Harness 的各个组件（系统提示、工具描述、子代理配置、记忆）拆开，用可观测性追踪每个组件对最终效果的影响，然后用一个优化 Agent 自动改写"最弱的那一环"。

结果：在 Terminal-Bench 2 基准上，pass@1 从 69.7% 提升到 77.0%，超过手写的 Codex (71.9%)、自进化的 ACE 和 Training-Free GRPO。

更值得注意的是，训练好的 Harness 不绑死模型。它可以迁移到 SWE-bench-verified 和其他 4 个 base model，依然有提升。这说明 Harness 学到的是"通用工程经验"，不是针对某个 benchmark 的过拟合。

AHE 的存在让 Harness 变成了一个 可以被量化、被优化、被比较 的对象。这才是这个词被行业快速接受的关键。

五、开发者需要做什么

如果你在 2026 年还在用 2024 年的方式做 Agent 开发，可能会开始感觉到瓶颈。

这里给出三个具体的转向建议，先做第一个就够：

1. 重新审视你的项目结构

好的 Harness 有一个共同点：项目本身是可被 Agent 理解的。

具体做法：

README 要写"项目是什么、怎么跑、主要约束是什么"
CLAUDE.md / AGENTS.md 写"Agent 在这个项目里应该遵守的规则"
关键目录有明确的"职责说明"
测试、构建、部署的脚本要可被独立调用

Anthropic 自己在 Claude Code 项目里就是这么做的。一行 CLAUDE.md 比 1000 字的 system prompt 更有效，因为 Harness 会在正确的时机读它，而不是把所有内容塞进 context。

2. 关注"失败模式"而不是"成功模式"

Prompt Engineering 时代，大家花大量时间想"什么样的 prompt 能让模型成功"。

Harness Engineering 时代，更值得花时间的是"模型在哪些情况下会失败、失败后 Harness 怎么恢复"。

比如：

工具调用返回 500 怎么办？重试几次？降级到哪个工具？
模型输出格式不对怎么办？直接报错还是尝试解析？
长任务跑到一半超出 context 怎么办？压缩历史还是分拆子任务？

这些"如果…怎么办"的设计，比"怎么让 prompt 更精准"重要得多。

3. 把 Harness 看作可观测的对象

如果你的 Harness 没有日志、没有 metrics、没有 trace，那就不是一个 Harness，是一个黑盒。

最低限度，你至少要能回答这些问题：

这次任务一共消耗了多少 token？分别在哪一步？
Agent 调用了哪些工具？每个工具的调用次数和成功率？
Agent 在哪一步卡住过？最后怎么解决的？
如果用户报告"这次结果不对"，你能从日志里复现 Agent 的决策路径吗？

AHE 之所以能把 Harness 优化到 77%，核心就是它把每个组件的贡献都量化了。你不需要做 AHE，但你至少要能看到自己 Harness 的运行情况。

六、写在最后

回到开头那个判断。Prompt Engineering 时代是不是真的结束了，Harness Engineering 时代是不是真的开始了？

更准确的说法是：Prompt 仍然是 Harness 的一部分，但 Harness 的复杂度已经超过了 Prompt 本身。

就像前端工程师今天还是会写 HTML/CSS，但工作的主要内容已经变成了框架、状态管理、性能优化、构建工具。HTML/CSS 是地基，但不是全部。

Harness 也是一样。它不是 Prompt 的"替代品"，而是 AI 工程化的新一层。

2026 年不是 Harness 一夜爆火的年份，而是 Harness 从"少数先知在尝试"变成"行业共识在形成"的年份。OpenAI 和 Anthropic 同时押注这个词，只是这个共识的注脚。

如果你在 2026 年刚开始用 Claude Code 或 Codex，建议把时间花在理解你用的工具的 Harness 设计、读完它的官方文档、研究它的失败模式，而不是反复调优 prompt。

这些，比写一个 200 字的 system prompt 重要得多。