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

注本文为小报童精选文章。已订阅小报童或加入知识星球「玉树芝兰」用户请勿重复付费疑问知识星球上星友 blockphd 问了我一个很好的问题涉及最近很火的几个概念。我把他的原话贴出来然后咱们逐个聊。王老师好最近很火的 Harness Engineering 可以理解成在做产品端的顶层架构吗最近看一些开培训班的课程就一直强调架构思维但是不太理解到底是什么。最近有被安利一个 GitHub 项目叫 Gstack也是在试图去帮助一个没有软件工程背景的用户能够更加规范的去设计一个产品跑通它的全流程。那 Gstack 这种项目一定程度上也算是 Harness Engineering 的一种应用吗三个问题我一个一个来回答。正名先回答第一个问题Harness Engineering 能理解成「产品端的顶层架构」吗我觉得你的直觉有合理之处但是并不完全准确。Harness Engineering中文有人译作「驾驭工程」是 2026 年 2 月刚冒出来的概念。最早的来源嘛有人说是 Mitchell Hashimoto——HashiCorp 联合创始人、Terraform 的创建者 —— 他在 个人博客[1]里描述了自己使用 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 网站[2]的分析文章里就专门列出了「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 做了一个实验[3]同一个模型只改变编辑工具的 Harness不改变模型本身编码基准测试成绩从 6.7% 飙升到 68.3%。同一个月LangChain 也 报告[4]了类似的结果同一模型通过 Harness 优化在 Terminal Bench 2.0 排行榜上从第 30 名之外跃升到前 5。这两组结果至少说明一件事在一些具体的 AI 编程场景里决定效果上限的已经不只是模型本身还包括围绕它搭起来的 Harness。也正因为如此你现在会看到不少培训内容开始强调「架构思维」或「系统设计」。这个判断方向是对的。不过「架构思维」似乎只抓住了 Harness Engineering 的一半。Harness Engineering 像是一套完整的马术训练体系。培训班的「架构思维」相当于教你给马套上缰绳前馈控制—— 这很重要没错。但完整的 Harness Engineering 还包括给马装仪表盘来监控状态反馈控制修好围栏确保它不跑偏约束系统以及训练结束后的复盘改进持续迭代。我自己踩坑最深的地方恰恰就是培训班不会教你的那一半。