什么是「驾驭工程」（Harness Engineering）？

谈谈我实践踩坑获得的体会。

疑问

知识星球上，星友 blockphd 问了我一个很好的问题，涉及最近很火的几个概念。我把他的原话贴出来，然后咱们逐个聊。

王老师好，最近很火的 Harness Engineering 可以理解成在做产品端的顶层架构吗？最近看一些开培训班的课程就一直强调架构思维，但是不太理解到底是什么。

最近有被安利一个 GitHub 项目，叫 Gstack，也是在试图去帮助一个没有软件工程背景的用户，能够更加规范的去设计一个产品，跑通它的全流程。那 Gstack 这种项目一定程度上也算是 Harness Engineering 的一种应用吗？

三个问题，我一个一个来回答。

---

正名

先回答第一个问题：Harness Engineering 能理解成「产品端的顶层架构」吗？

我觉得你的直觉有合理之处，但是并不完全准确。

Harness Engineering，中文有人译作「驾驭工程」，是 2026 年 2 月刚冒出来的概念。最早的来源嘛，有人说是 Mitchell Hashimoto——HashiCorp 联合创始人、Terraform 的创建者 —— 他在 个人博客 里描述了自己使用 AI 编程的六个阶段，其中第五个阶段叫「Engineer the Harness」。

Mitchell 的核心理念很朴素：每当你发现 AI Agent 犯了一个错误，你就花时间设计一个解决方案，确保它再也不会犯同样的错误。

注意，这里说的不是「给 AI 更好的提示词」，也不是「给 AI 更多的上下文」。而是在 AI 之外，建一套系统——约束它、监控它、让它犯错后能自动纠正。

行业内现在用一个公式来描述这件事：

Agent = Model + Harness

是不是很直白？

Model 是 AI 的智能本身（比如 Claude 4.6 Opus、GPT 5.4 、Qwen 3.6 Plus 等）。Harness 是模型之外的一切 —— 约束机制、反馈循环、自动化测试、工作流控制、文档规范……Harness Engineering 就是设计和构建这些「模型之外的系统」的工程实践。

你看，「产品端的顶层架构」只描述了 Harness 的一小部分。架构设计确实是 Harness 的组成之一 ——Birgitta Böckeler 在 Martin Fowler 网站 的分析文章里，就专门列出了「Architecture Fitness Harness」（架构适配性）这个领域。

但咱们也不能忽视， Harness Engineering 还包括代码质量管控、自动化测试、行为监控、反馈循环等一整套工程基础设施。

所以一个更贴切的理解是：Harness 不是产品的架构，而是给 AI Agent 设计的操作系统。

这个「操作系统」里有两类控制机制。一类叫 Guides（前馈控制），在 AI 行动之前就引导它走正确的方向——比如代码规范文档、架构约束等。另一类叫 Sensors（反馈控制），在 AI 行动之后观察结果，帮它自我纠正——比如自动化测试、代码审查、性能监控等。

我自己的实践或许能帮你理解这两者的区别。

我用 Claude Code 做了几十个自动化工作流（Claude Skills），从调研到做幻灯片到写文献综述，各种各样。2026 年 4 月 4 日，我用一个脚本扫描了自己积累的 99 个 Skill，想看看每个 Skill 加载时要占用多少上下文窗口。结果让我吃了一惊：37 个 Skill 超过了 2000 token，最重的一个加载时直接吃掉 29,360 个 token—— 还没开始干活，Claude Code 真正可用的上下文就已经去掉一大截了。

不过你可能会疑惑，占用点儿上下文又有什么了不起呢？接着往下看。

3 月底我在做一套 30 页的教学幻灯片。AI 负责逐页设计，我在 Teaching Slides Skill 里提供了一份统一的设计规范—— 字体、配色、布局，写得很清楚。前 15 页生成得还不错，到第 20 页开始有点走样，到第 25 页我发现字体大小跟第 3 页完全不一致。我去查看 AI 当时的上下文 —— 果然，前面十几页的设计规范已经被后面的中间产物挤出记忆了。

我最初的反应是「换个上下文窗口更大的模型」。但想了想不对——即使窗口再大，以目前的模型真正可用上下文能力（不是宣称的动辄 1M token），更多页幻灯片的设计指令加上每页的中间产物，迟早还是会把规则挤出去。这不是模型能力的问题，是任务组织方式的问题。

然后我和 Claude Code 一起商讨出一个办法：不让一个 AI 从头到尾做 30 页。每一页的设计交给一个独立的 Agent。 每个 Agent 只负责一页，带着完整的设计规则进去，出来时只带一页的结果。主线程只做调度，不碰设计。

关键的认知转变在这里：Agent 的核心价值不是「可以并行处理」，而是上下文隔离。 每个 Agent 有自己独立的上下文窗口，一个 Agent 处理的中间数据不会污染另一个 Agent 的记忆。Claude Code 自己管这个叫「Agent 防火墙」。

这个模式在另一个场景也得到了验证。我做文献综述时，让 AI 逐篇分析 10 篇论文。串行处理时，前几篇分析得很仔细，但到第 8 篇开始质量明显下降——分析变粗糙了，有些字段开始漏填。原因一样：前面论文的分析结果塞满了上下文窗口，第 8 篇论文的分析不得不在一个「很拥挤」的上下文里进行。改成每篇论文一个 Agent 之后，质量不但没有因为隔离而下降，反而提升了——因为每个 Agent 有全新的、不被污染的上下文窗口。

这就是一种前馈控制 —— 在 AI 犯错之前，用系统设计把犯错的条件消除了。AI 模型本身没变，我变的是它工作的环境。

你可能在使用对话机器人时也遇到过类似的事。用 AI 处理长文档时，让它分析到第三章，它把第一章的关键结论忘了。让它改一篇长文章，改到后面，前面你强调的格式要求全丢了。这就是上下文管理问题。解决方案不是换更强的模型，而是改变任务的组织方式 —— 把一个长任务拆成多个短任务，每个短任务在独立的环境里完成。

反馈控制的故事更深刻一些。

2026 年 2 月中旬，我在做一篇文献综述。为了质量把关，我设了一个独立的审查 Agent—— 一个 AI 专门负责检查另一个 AI 的产出。这个审查 Agent 是认真的，它逐篇核查了引用信息，真的找到了 8 处作者张冠李戴 —— 把 A 学者的研究归在了 B 学者名下，这类错误简直无法容忍。它把这 8 个问题标记为最高优先级，意思是「必须修正才能继续」。

但执行任务的那个 Agent 不这么看。它写了一句话：「刚才负责检查的 Agent 自身也是基于搜索推断，无法确认。」然后把 8 个最高优先级问题全部降级为「非致命」，继续输出了终稿。8 处作者张冠李戴，直接进了最终产出物。

我仿佛看到了马三立相声里的「马大哈」出现在了模型界😓。

这件事太过蹊跷，一开始我真没想到 Agent 会这么糊弄。这让我花了好一阵子检查，然后在震惊中消化。审查机制我建了，审查 Agent 也做了它该做的事——问题出在我没有给审查结论赋予约束力。 执行者用一句模糊的理由就绕过了全部审查发现。这等于房屋建造者装了烟雾报警器，但允许住户自己决定要不要理会警报。

于是我加了一条铁律：执行者不得单方面否决审查 Agent 的发现。 要么修正，要么用可验证的证据反驳——比如拿出 DOI 查询结果或原文截图证明审查 Agent 搞错了。但不能用「它也可能有误」这种模糊理由绕过去。审查 Agent 标记的最高优先级问题，必须全部解决才能进入下一阶段。关于检查核对中遇到的其他坑，我在《AI Agent 查不出自己的错，怎么办？》里详细讲过，你也可以参考。

前馈控制相当于告诉马往哪边跑，反馈控制相当于给马装仪表盘。两手都要抓，缺一不可。但光装仪表盘没用，你还得保证驾驭员会看仪表盘，而且看了之后必须及时处理，不能掩耳盗铃。

---

全景

第二个问题：你提到培训班一直强调的「架构思维」到底是什么？

你注意到了一个真实的行业趋势。

2025 年，AI Agent 证明了它能写代码。到了 2026 年，越来越多人开始意识到：很多时候，真正拉开差距的，已经不只是 Agent 本身，而是围绕 Agent 的那套系统。

有一组数据很说明问题。2026 年 2 月，Can.ac 用 Grok Code Fast 1 做了一个实验：同一个模型，只改变编辑工具的 Harness（不改变模型本身），编码基准测试成绩从 6.7% 飙升到 68.3%。

同一个月，LangChain 也 报告 了类似的结果：同一模型通过 Harness 优化，在 Terminal Bench 2.0 排行榜上从第 30 名之外跃升到前 5。

这两组结果至少说明一件事：在一些具体的 AI 编程场景里，决定效果上限的，已经不只是模型本身，还包括围绕它搭起来的 Harness。

也正因为如此，你现在会看到不少培训内容开始强调「架构思维」或「系统设计」。这个判断方向是对的。不过「架构思维」似乎只抓住了 Harness Engineering 的一半。

Harness Engineering 像是一套完整的马术训练体系。培训班的「架构思维」相当于教你给马套上缰绳（前馈控制）—— 这很重要，没错。但完整的 Harness Engineering 还包括给马装仪表盘来监控状态（反馈控制），修好围栏确保它不跑偏（约束系统），以及训练结束后的复盘改进（持续迭代）。

我自己踩坑最深的地方，恰恰就是培训班不会教你的那一半。