一个被质疑 "炒概念" 的新词，到底是不是噱头？
2026 年，AI 工程圈又冒出一个新名词 ——Harness Engineering（驾驭工程）。它出现得密集而迅猛，很快就遍布技术博客、开源项目和一线团队的复盘文章。
热度自然也带来了质疑。反对的声音主要分两派：
- 一派说它「新瓶装旧酒」，用的全是被讲烂的老技术；
- 另一派更狠：所有 Harness 迟早会被更强的模型吃干抹净，今天费尽心思搭的约束系统，明天可能就被模型自己吸收了。
要判断这些说法成不成立，得先把概念本身拆开看清楚。
一、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 承接真实业务、长链路、低容错任务时，决定表现上限的，往往是模型之外整套系统：约束、反馈、记忆、观测与故障恢复。
它未必是技术终点，但一定是当下非常值得投入的方向。 毕竟，一匹好马，也需要一副好马具；一个强大的模型，同样需要一个稳定运行的世界。
最后说一句，技术成长不只是写代码，职业规划和自我包装同样重要。我整理了一份简历、面试和职业规划的学习资料，适合想在职场上走得更远的朋友看看。
资料展示
下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。
如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。
