Harness Engineering：AI Agent 时代的工程范式革命
2026-03-21
Harness Engineering（驾驭工程）是2026年2月爆发的软件开发新范式——工程师不再写代码，而是设计让 AI Agent 可靠工作的约束系统、反馈回路和运行环境。 这个概念由 HashiCorp 联合创始人 Mitchell Hashimoto 于2026年2月5日命名，仅三周内就从一个博客术语变成了行业热词。OpenAI 随后发表实验报告佐证：3名工程师用5个月、零行手写代码，生成了约100万行生产级代码，效率约为传统开发的10倍。这标志着软件工程从"人写代码、AI辅助"正式转向"AI写代码、人设计环境"的根本转变。 （这是一篇 AI 撰写的研究报告，仅分享给大家参考。） 一个马具隐喻催生的新范式 Harness 本意是马具——缰绳、鞍具、嚼子——一整套让强大但不可控的马匹按人的意图行进的装备。前 Google 首席决策科学家 Cassie Kozyrkov 的比喻最为精准："马就是 AI 模型——力量大、速度快，但自己不知道该去哪。握着缰绳的人才做真正的智力工作：选择目的地、判断地形、知道何时减速。" Mitchell Hashimoto 在2026年2月5日的博文《My AI Adoption Journey》中首次为这一实践命名。他描述了自己的六阶段 AI 采纳路径，第五阶段命名为"Engineer the Harness"，核心定义极其简洁："每当你发现 Agent 犯了一个错误，你就花时间设计一个解决方案，使 Agent 永远不再犯同样的错误。" 他坦承当时"行业内还没有一个广泛接受的术语"。 六天后，OpenAI 工程师 Ryan Lopopolo 发表了关键文章《Harness engineering: leveraging Codex in an agent-first world》，以震撼性的实验数据为这一概念注入了巨大势能。随后 Martin Fowler 网站上 Thoughtworks 杰出工程师 Birgitta Böckeler 的深度分析、LangChain 的基准测试验证、Ethan Mollick（沃顿商学院教授）将其纳入 AI 教学框架——多方推力之下，Harness Engineering 在短短数周内成为主流话语。值得注意的是，Böckeler 观察到 OpenAI 原文正文中实际只出现了一次"harness"一词，暗示这一标题可能是受 Hashimoto 博文启发后的"事后追加"。 "Harness"一词在 AI 语境中并非全新。EleutherAI 早在2020年就有 Language Model Evaluation Harness 项目；Anthropic 在2025年11月将 Claude Agent SDK 描述为"a powerful, general-purpose agent harness"。但将"Harness Engineering"上升为一个独立的工程学科，2026年2月才是真正的分水岭。 从 Prompt 到 Context 再到 Harness：三代范式的嵌套进化 理解 Harness Engineering 的位置，关键在于看清它与前两代范式的嵌套递进关系。Prompt Engineering 管"说什么"，Context Engineering 管"知道什么"，Harness Engineering 管"在什么环境里做事"。 三者并非替代关系，而是逐层包裹：Prompt Engineering ⊂ Context Engineering ⊂ Harness Engineering。 | 维度 | Prompt Engineering | Context Engineering | Harness Engineering | |------|-------------------|---------------------|---------------------| | 范围 | 单条指令 | 所有输入给模型的信息 | 包围 Agent 的完整运行环境 | | 设计对象 | 问题/命令本身 | 推理时可用的信息 | 约束、工具、反馈回路、生命周期系统 | | 隐喻 | "向右转"指令 | 地图、路标、可见地形 | 缰绳、围栏、马鞍和道路本身 | | 兴起时间 | 2023-2024 | 2025年中 | 2026年2月 | HumanLayer 联合创始人 Dex Horthy 给出的嵌套关系定义最为清晰："我们认为 Harness Engineering 是 Context Engineering 的子集。Context Engineering 是 Prompt Engineering 的超集。Harness Engineering 是 Context Engineering 中主要通过利用外部配置点来精心管理 Coding Agent 上下文窗口的那一部分。" Phil Schmid（Hugging Face）则用更通俗的类比："模型是 CPU，Harness 是操作系统——CPU 再强，OS 拉胯也白搭。" 与 Vibe Coding 的根本分野 2025年初 Andrej Karpathy 提出的 Vibe Coding——"氛围编程"——在认识论上与 Harness Engineering 构成鲜明对立。Cassie Kozyrkov 的比较最到位："Vibe Coding 在认识论上是被动的：你和键盘一起放弃了对代码的理解。Harness Engineering 在认识论上是主动的：它只是重新定向了你需要理解的东西。" 她强调两者不是二选一，而是一个连续谱——你需要根据后果的严重程度来调节严格程度。 Octopus Deploy 进一步对比：Vibe Coding 接受所有 AI 变更而不审查，遇到错误就扔给 AI 再试一次；Harness Engineering 则通过机械化手段强制执行架构约束，把文档维护为唯一事实来源，运行定期清理 Agent。两者的目标截然不同——前者追求"能跑就行"，后者追求"可靠地规模化运行"。 与传统软件工程的本质转变 根本转变在于：工程师停止写代码，开始设计 Agent 写代码的环境。OpenAI 报告中最关键的一句话是："我们工程团队的首要工作不再是写代码，而是让 Agent 能够做有用的工作。" 当某项任务失败时，"修复方法几乎从来不是'再努力试试'。人类工程师总是走进任务问：缺少什么能力？如何让它对 Agent 既可读又可执行？"
本文为付费内容，订阅后阅读全文。