一个被质疑 "炒概念" 的新词，到底是不是噱头？
2026 年，AI 工程圈又冒出一个新名词 ------Harness Engineering（驾驭工程）。它出现得密集而迅猛，很快就遍布技术博客、开源项目和一线团队的复盘文章。
热度自然也带来了质疑。反对的声音主要分两派：
- 一派说它「新瓶装旧酒」，用的全是被讲烂的老技术；
- 另一派更狠：所有 Harness 迟早会被更强的模型吃干抹净，今天费尽心思搭的约束系统，明天可能就被模型自己吸收了。
要判断这些说法成不成立，得先了解清楚什么是Harness Engineering 。
一、Harness 是什么：一匹好马，还需要一副好马具
Harness 本义是马具------ 套在马身上用来控制马的那套装备，缰绳、头套、挽具。这个比喻很妙：马的力量惊人，但若没有约束，就是脱缰的野马，会跑偏、会撞墙。大模型就是那匹马，能力强，但任其自由发挥，就会发散、会幻觉、会在长任务中途迷路。
于是行业形成了一个广泛引用的公式（由 LangChain 的 Vivek Trivedy 在《The Anatomy of an Agent Harness》中给出经典表述）：
Agent = Model + Harness
Harness 指模型之外的一切：系统提示词、工具调用、文件系统、沙箱环境、编排逻辑、记忆机制、反馈回路、权限约束。
说得直白点：只要你做的不是模型本身，那你搭的东西大概率就是 Harness。
这个定义并不严格，更像一种便于协作的共识：
模型只负责推理和生成，Harness 负责把状态、工具、反馈、执行环境和安全边界串起来，Agent 才能真正干活。
一个贴切的类比是计算机：
把模型看作 CPU，把 Harness 看作操作系统。CPU 再强，系统天天崩溃、驱动乱飞，体验也好不了。
这就解释了一个常见困惑：为什么换了更贵的模型，Agent 还是照样重复犯错、做到一半放弃、上下文一长就不稳定？
二、三代范式的递进：从 "怎么问" 到 "怎么搭系统"
Harness Engineering 有两位「前任」，三者不是并列关系，而是一层套一层、范围不断向外扩张。
第一代：Prompt Engineering（提示词工程）
解决「怎么把话说清楚」。
比如让模型 "帮我的猫起个名字"，它可能回你 "花花"" 小白 "；但你家是橘猫，于是你把提示词改成" 帮我的橘色小猫起名，两个字，体现它活泼的性格 "，它就能给出更合适的结果。
今天它已很少被单独提及 ------ 门槛不高，且模型变强后，不反复调提示词也能给出不错回答。
第二代：Context Engineering（上下文工程）
解决「该让模型看到什么」。
你接着问 "它平时吃什么好"，这个 "它" 指谁？模型靠的是接收到的全部信息 ，也就是上下文。上下文有容量上限，于是需要精心设计。
经典技术之一是上下文压缩：对话越堆越长，超过阈值就把早期对话总结成摘要。还有动态检索、渐进式披露等方法。
但人们很快发现，上下文工程的效果也有天花板。于是有了今天的主角。
第三代：Harness Engineering（驾驭工程）
研究如何围绕大模型搭建一套完整可靠的运行系统。除了模型本身不研究，别的都管 ------ 它站在系统层面设计环境，让模型踏实做事。
表格
| 范式 | 解决的问题 | 通俗说法 |
|---|---|---|
| Prompt Engineering | 怎么把指令说清楚 | 教 AI 怎么想 |
| Context Engineering | 该给 AI 看什么 | 教 AI 看什么 |
| Harness Engineering | 系统怎么持续执行、纠偏、恢复 | 规定 AI 在什么环境工作 |
时间线上，行业普遍认同这个节奏：
2022---2024 提示词工程，2024---2025 上下文工程，2026 起驾驭工程。
这不只是概念叠加，而是 AI 工程重心的转移 ------从「调模型」转向「搭系统」。
三、为什么瓶颈常常不在模型？
一个反直觉的结论：很多 Agent 场景里，卡住效果的不是模型智商，而是基础设施。
有个流传很广的对照实验：开发者 Can Bölük 在 2026 年 2 月测试了 16 个模型、3 种代码编辑格式，同一个模型，只是把编辑接口从标准格式换成一种基于行哈希的新格式，成功率就从 6.7% 跳到 68.3%------Grok Code Fast 1 提升近十倍。
模型一行没动，变的只是外面那套系统。作者一句话点破：
模型是护城河，Harness 才是那座桥。
类似地，LangChain 通过优化运行环境 ------ 重组文档、补上验证回路、接入追踪系统 ------ 把 Terminal Bench 2.0 的排名从全球第 30 提升到第 5，得分从 52.8% 涨到 66.5%。模型没换，换的是 Harness。
这背后还有一个易忽略的现象：上下文并非越多越好。
有人观察到「智能区 / 迟钝区」的分界 ------ 上下文窗口用到约 40% 时，输出质量就开始明显下滑：幻觉增多、开始兜圈子、代码质量下降。
这也是团队热衷「渐进式披露」和「分层管理」的原因：目标不是塞更多信息，而是让 Agent 尽量待在干净、相关的上下文里。
一句话总结：
Agent 的问题，很多时候不是「模型行不行」，而是「系统有没有把模型需要的东西准备好」。
四、一个成熟 Harness 的六层骨架
把 Harness 拆开看，一个成熟的系统通常有清晰分层。一个便于理解的全景框架是六层：
表格
| 层级 | 名称 | 解决什么问题 |
|---|---|---|
| L1 | 信息边界层 | Agent 该知道什么、不该知道什么 |
| L2 | 工具系统层 | Agent 怎么和外部世界交互 |
| L3 | 执行编排层 | 多步骤任务怎么串起来 |
| L4 | 记忆与状态层 | 长任务中间结果怎么管理 |
| L5 | 评估与观测层 | Agent 怎么知道自己做对了没有 |
| L6 | 约束、校验与恢复层 | 出错了怎么办 |
可以类比成给新员工搭工作环境：
- L1 是岗位说明
- L2 是办公工具
- L3 是标准流程
- L4 是项目管理和笔记本
- L5 是质检
- L6 是红线规则和应急预案
是整套闭环，而非功能堆砌。
💡 务实建议：不要一上来就想搭齐六层，优先落地 L1 和 L6。先让 Agent 知道自己该干什么，再设好出错后的拦截与恢复机制。这两层投入不高却最容易见效。
五、一线团队怎么落地：四个实战样本
概念之外，最有说服力的是真实案例。下面四家做法不同，但踩的坑高度相似。
OpenAI：3 个人 5 个月，100 万行代码，0 行手写
2025 年 8 月，OpenAI 启动了一项实验：从零写一个真实软件产品，全程不允许工程师手写一行代码。业务逻辑、测试、CI 配置、文档全由 AI 生成。
结果：团队从 3 人扩到 7 人，历时 5 个月，产出约 100 万行代码，手写 0 行，效率约为传统模式的 10 倍。
更值得看的是教训。实验初期进展不顺 ------ 不是模型不够聪明，而是 Harness 没搭好，Agent 经常走错方向、重复犯同一个错。
他们由此总结几条核心经验：
- 给地图，别塞手册。
最初把所有规范塞进超大的 AGENTS.md，反而抓不住重点，文件还迅速腐化。后来把它压缩到约 100 行，只当目录用，指向深层设计文档，按需加载 ------ 这就是渐进式披露。 - 架构约束必须机械执行。
依赖方向被固定为Types → Config → Repo → Service → Runtime → UI，靠自定义 Linter 和结构测试保证。违反时工具不只报错，还告诉 Agent 怎么改。
不能被机械执行，Agent 迟早偏离。
- 把可观测性交给 Agent。
接入浏览器调试协议，让 Agent 自己截屏、抓 DOM、模拟用户操作来验证 UI，于是 "把启动时间降到 800 毫秒内" 不再是模糊要求，而是可自测的目标。 - 熵不会自己消失。
生成越多，重复逻辑、架构违规也越多，团队改为用后台 Agent 定期扫描并自动提交清理 PR。 - 仓库即唯一事实来源。
散落在聊天记录、在线文档里的知识对 Agent 等于不存在，于是强制把约定搬进代码仓库。
这一切背后，是 OpenAI 反复强调的理念：
Human steer, agents execute. ------人类掌舵，Agent 执行。
软件工程并未消失，而是演变成新形态：工程师的核心职责，变成了为 Agent 搭建稳定可靠的系统与支撑框架。
Anthropic：从上下文焦虑到三智能体架构
Anthropic 的实践围绕两个核心问题：任务规划、质量评估。
任务规划
早期 Agent 接到需求就开干，急于求成，结果上下文满了直接撂挑子，接手者只能靠猜。
解法是引入负责初始化的 Agent ：拆解需求、写启动脚本、加进度文件，把模糊需求拆成清晰的功能列表 ，后续 Agent 逐个推进、做完标记一个。该角色被抽象为专门的 Planner（规划者）。
质量评估
人工评估太慢；让 Agent 自评又行不通，很容易自我美化。
于是选择第三条路：设立独立的评估 Agent，作为第三方没有动机护短，评价更客观，还能单独优化。
最终形成经典三角架构：
Planner（规划者）→ Generator（执行者）⇄ Evaluator（评估者）
- Planner：把一两句话产品描述扩展成完整规格；
- Generator：逐个开发功能；
- Evaluator：用 Playwright 实际点击运行中的应用，从产品设计、功能性、视觉设计、代码质量等维度打分。
小细节："设计质量" 和 "原创性" 权重被故意调高。因为模型极易做出「功能齐全但长相平庸」的东西，调高权重逼迫模型去往更难的方向探索。
Anthropic 还发现关键现象 ------上下文焦虑 ：上下文快满时模型变得犹豫，甚至提前草草收工。
他们的解决方案是 context resets（上下文重置）：清空上下文，但通过结构化交接文档保留关键状态，再启动一个干净的新 Agent 接着做。
两种配置成本与效果对照：
表格
| 方案 | 耗时 | 花费 | 效果 |
|---|---|---|---|
| Solo（单 Agent + 最少工具） | 20 分钟 | $9 | 跑不起来的半成品 |
| Full（三 Agent + 完整工具链） | 6 小时 | $200 | 完整可用的应用 |
Stripe 与 Mitchell Hashimoto：两种相反的路线
Stripe Minions：高度自动化、无人值守路线
开发者发一条消息，Agent 就从写代码、跑 CI 到提 PR 全部完成，每周有超过 1300 个完全由 AI 生成、无人类手写代码的 PR 被合并。
依赖一套成熟工程底座：预装源码的开发环境、编排状态机拆分确定性节点与 Agent 节点、集中式工具服务、覆盖 300 万 + 测试的反馈回路。
核心理念：
What's good for humans is good for agents.
过去为人类工程师投入的工具链，在 Agent 身上会直接产生回报。
Mitchell Hashimoto：人机深度参与路线
HashiCorp 联合创始人 Mitchell Hashimoto 选择相反思路：一次只跑一个 Agent，人类深度参与过程。
核心实践：
- Agent 在真实可读写文件、运行程序、发起请求的环境干活，不只局限聊天窗口；
- Agent 每犯一次错，就工程化一个方案，让它不再犯同类错误；
- 下班前给 Agent 布置调研、探索类任务；
- AGENTS.md 的每一行，都对应一个过去的失败案例，是持续迭代的防错系统。
六、它到底是噱头，还是终局？
回到开篇的质疑，先梳理这个名词的来龙去脉：
Harness 本身并不是新词：软件测试领域早有 test harness，AI 领域有开源 LM Evaluation Harness；Anthropic 在 2025‑11 就发布过《Effective Harnesses for Long‑Running Agents》。
真正的转折点：
- 2026‑02‑05 ：Mitchell Hashimoto 在博客提出「Harness Engineering」，核心理念：只要 Agent 犯错，就去改造系统，让它绝不再犯同样的错误。
- 2026‑02‑11：OpenAI 相关实验文章发布，引爆行业讨论。
- 2026‑02‑17：Martin Fowler 网站发布《Harness Engineering: First Thoughts》，做结构化拆解。
- 2026‑03‑24：Anthropic 公开 Planner / Generator / Evaluator 三智能体架构，被业界视作 Harness 教科书案例。
质疑一：全是老技术，属于新瓶装旧酒
这个批评有一定道理：Harness Engineering 用到的技术没有一项是全新的，Linter、代码检查、任务拆解、质量评估早已存在。
但它的价值不在于发明新技术，而在于提供一套新的系统思维框架，把零散的工具、方法收拢起来，变成可设计、可迭代、可落地的工程范式。
工程领域很多重要进步，不是来自发明新技术，而是把已有能力组织成一套可持续优化的体系。
质疑二：模型越来越强，Harness 终会被模型吃掉
现象客观存在：部分过去必须靠 Harness 解决的问题，随着模型升级会被缓解。比如部分场景下「上下文焦虑」会被新版本模型改善，部分强制约束可以放宽。
模型越强，所需 Harness 越少；但 Harness 只会变形，不会消失。
模型能力上限提升之后，人类会给 Agent 分配更复杂、更长链路的任务，又会诞生新一代系统约束需求。
综合判断：不是噱头，但大概率不是终局
✅ 不是噱头：OpenAI、Anthropic、Stripe 都靠这套思路拿到可验证的工程结果，显著提升 Agent 稳定性与生产力。
⚠️ 不是终局：随着模型持续进化，今天大量用于约束、纠错、兜底的系统逻辑，会逐步被模型自身能力吸收。
定位：Harness Engineering 是 AI Agent 发展过渡期的关键工程方法论。它未必是终极答案，却是当下最现实的答案。谁能把 Harness 搭得更稳，谁就能更早把大模型能力转化为真实生产力。
七、落地指南：从哪里开始
搭建 Harness 不必上来就做宏大完整系统，按优先级逐步推进。
P0｜马上就可以落地
- 创建并持续维护
AGENTS.md，Agent 启动自动加载；每一次 Agent 犯错，就更新文档，每一行对应真实失败案例（参考 Mitchell Hashimoto）。
❗坑点：不要把 AGENTS.md 写成超长超级系统提示词。OpenAI 实践：控制在约 100 行，作为索引目录，不堆砌全部规则，否则上下文膨胀，Agent 反而更容易跑偏。
- 构建自定义 Linter，配套修复指令；报错时直接告诉 Agent 应该怎么改，而不是只抛出错误。
- 将团队约定、业务知识沉淀进代码仓库；聊天记录、在线文档中的信息对 Agent 属于不可见信息。
P1｜P0 跑通之后再补充
- 分层上下文管理；建立进度文件、功能任务列表；
- 赋予 Agent 端到端自验证能力；
- 控制上下文窗口利用率，尽量不超过 40%，规避「迟钝区」。
P2｜资源充裕再考虑
- Agent 专业化分工，多智能体协作；
- 后台 Agent 做定期垃圾回收、架构巡检；
- 完整可观测性链路集成。
结语
Harness Engineering 最值得记住的，不是名词本身，而是一种思维姿态的转变：
从盯着模型本身，转向设计模型所处的运行环境。
过去两年，我们大量精力花在「怎么问得更好」、「该让模型看到什么」。
但当 Agent 承接真实业务、长链路、低容错任务时，决定表现上限的，往往是模型之外整套系统：约束、反馈、记忆、观测与故障恢复。
它未必是技术终点，但一定是当下非常值得投入的方向。
毕竟，一匹好马，也需要一副好马具；一个强大的模型，同样需要一个稳定运行的世界