什么是Harness Engineering：Vibe Coding的下一波浪潮在2026

每隔几年，开发者与技术合作的方式就会发生一些变化——不仅仅是新工具，而是对工作本身的新思考方式。2025 年，这种变化以 vibe coding 的形式到来。2026 年，它正在深化为更具结构性的东西：harness engineering。

要理解 harness engineering 是什么以及它为何重要，你必须追溯其源头。因为 harness engineering 并非孤立出现。它是人类与 AI 协作构建软件的快速演进中的最新一步——这一进程从 vibe coding 经由 prompt engineering 和 context engineering 发展而来，最终抵达我们今天的位置。

这个序列中的每一步都代表一种范式转变，而非仅仅是技术升级。理解完整的发展轨迹是理解 harness engineering 究竟是什么、它为何存在，以及 2026 年希望在软件开发前沿工作的开发者需要什么的最佳方式。

AI 辅助开发的四种范式

1. Vibe Coding：意图优于语法

2025 年初，Andrej Karpathy coined the term vibe coding 来描述许多开发者已经在做的事情：你不再逐行编写代码，而是用自然语言描述你想要的东西，让 AI 生成代码、运行它，然后根据有效结果进行迭代。你不需要阅读每一行代码。你是在通过感受来解决问题。

这个名称半带玩笑，但实践是真实的，其影响是严肃的。初级开发者能够交付他们自己无法编写的功能。没有工程背景的创始人能够构建可工作的原型。非技术团队能够自动化以前需要开发者参与的工作流。“拥有一个想法”与“拥有一个可工作的程序”之间的障碍以真正新颖的方式崩塌了。

Vibe coding 的核心洞见看似简单：intent, not syntax, is the primary input. 开发者的工作从为编译器编写精确指令转变为向 AI 清晰传达目标。代码成为协作的输出，而非协作的媒介。

这对一代因需要技术流利度而被软件创造锁在门外的构建者来说是解放性的。但它也暴露了一系列新问题。当一切都由 AI 生成时，你如何知道它是正确的？当系统崩溃时，你如何调试你没有编写的东西？当任务复杂到单一自然语言描述不足以应对时，接下来是什么？

2. Prompt Engineering：请求中的严谨

Vibe coding 在简单、有界限的任务上效果良好。当任务变得复杂、输出需要一致、同一提示在不同日子返回截然不同的结果时，开发者遇到了直觉驱动交互的极限。出现的答案是 prompt engineering。

Prompt engineering 是更仔细地设计输入的学科。哪些词语重要？提示中的示例如何影响输出？框架如何改变模型的行为？你应该要求模型在回答前逐步推理，还是直接给出问题？给它一个角色扮演会发生什么？

这仍然是单次交换的思维——一次提示输入，一次输出——但它为原本即兴的东西带来了严谨。它将与 AI 的对话从抛硬币变成了可重复的事情。在一段时间内，“提示工程师”成为大规模部署 AI 的公司的合法职位头衔。

随着用例变得更加雄心勃勃，prompt engineering 的局限性变得清晰。它本质上是脆弱的。它在模型更新时失效。它无法扩展到跨越数十步的任务。它将每次交换视为孤立的，而真实工作是连续且有上下文的。优化提示与构建可靠系统不同，一旦你认真对待 AI 生成的工作，这种差异就极其重要。

3. Context Engineering：设计 AI 的世界

下一个范式转变来自认识到提示只是决定 AI 产出的一个部分。同样重要——有时更重要——的是提示周围的一切：它可以访问的文档、它可以调用的工具、它可以引用的对话历史、它在会话间携带的记忆。

Context engineering 是刻意设计整个信息环境的实践。不仅仅是你问什么，而是 AI 能看到、记住和采取行动的内容。

Shopify 首席执行官 Tobi Lutke 在一份广为流传的内部备忘录中很好地阐述了这一点：工作是给 AI “完成任务所需的正确上下文、工具和信息”。这意味着仔细思考检索——什么信息被拉入，以及何时拉入。这意味着跨会话管理记忆，以便 AI 不是每次都从头开始。这意味着构建工具定义，以便 AI 知道可用能力并能适当地从中选择。

Context engineering 将范式从优化单次交换转变为 designing an ongoing collaboration environment。开发者不再只是提示编写者，而更多是 AI 工作条件的架构师——塑造 AI 运行其中的信息景观，而不仅仅是它接收的词语。

这是一个有意义的升级。借助良好的 context engineering，AI 代理可以处理跨越多个步骤的任务、引用项目历史、调用外部工具，并产生在长时间会话中连贯的输出。但 context engineering 仍留下一个根本问题未解决：当真实用户依赖它时，你如何让这在生产规模上可靠地工作？

4. Harness Engineering：为生产而构建

Vibe coding 给了我们意图。Prompt engineering 精炼了请求。Context engineering 构建了环境。但这些都没有完全解决希望认真部署 AI 的团队面临的最难问题：how do you take an AI agent that works in a demo and make it work reliably in production?

这就是 harness engineering 解决的问题。

该术语在 2026 年获得 traction，由包括 Martin Fowler's blog 的作者和 OpenAI 的团队在内的实践者提出。“harness” 借自软件测试——测试 harness 是围绕组件的脚手架，使其可测试、可观察和可控制。Harness engineering 将同样的思维应用于 AI 代理。

Context engineering 关注 AI 知道什么，而 harness engineering 关注 how the AI behaves——使代理行为一致、可恢复和可信赖的结构、约束和基础设施，当 stakes 是真实的时候。

Harness 是围绕 LLM 使其达到生产级别的一切：

• Tool definitions and boundaries：代理能做什么和不能做什么。清晰的接口防止失控行为，并使代理的能力明确且可审计。

• State tracking：代理需要知道它在多步骤任务中的位置、它已经做了什么以及还剩下什么。没有这个，代理会在长工作流中迷失，并产生不连贯或矛盾的输出。

• Error recovery：当工具调用失败时会发生什么？当模型幻觉出一个不存在的函数时？当 API 返回意外输出时？Harness 定义系统如何优雅地失败而非灾难性地失败。

• Observability：你能看到代理做了什么、以什么顺序、用了什么输入和输出吗？没有可观察性，调试 AI 行为就是猜测。

• Architectural constraints：放弃一些通用性——模型“生成任何东西”的能力——以换取可预测性。具体模式。强制结构。约束解空间的护栏。

OpenAI 的一个团队记录了使用 Codex 代理维护超过一百万行代码的代码库的 harness 构建过程，以“完全不手动输入代码”作为刻意强制函数。五个月后，使其工作的不是模型的质量。而是 harness：约束、模式和脚手架，使代理行为在数千次操作中保持一致和可恢复。

正如 Martin Fowler 的文章所说：harness engineering 不是一门新学科——它是 DevOps 应用于一种新工作负载。你越早这样看待它，你就能越快构建出在生产中真正工作的代理。

贯穿主线：更多 AI 能动性，更好的人类结构

将这四种范式放在一起看，发展方向变得清晰。

每一步都涉及 giving AI more agency——从按需生成代码片段（vibe coding）到优化单次交换（prompt engineering）到在设计环境中管理复杂的多步骤工作（context engineering）再到在生产中自主运行并产生真实后果（harness engineering）。

而每一步都要求开发者构建 better structure 来使这种增加的能动性安全可靠。没有构建使 AI 代理可观察、可恢复和受约束的 harness，你就无法获得让 AI 代理发布生产代码的好处。结构是赢得信任的东西，而信任使能动性值得拥有。

这就是为什么 harness engineering 不是与 vibe coding 分离的学科——它是成熟的 vibe coding。它是范式从“这在演示中令人印象深刻”到“这就是我们实际构建软件的方式”的转变。

为什么这种进展重要

序列中的每种范式都解决了前一个范式产生的问题。Vibe coding 创造了 AI 生成代码的可能性，但引入了不可预测性。Prompt engineering 在单次交换层面减少了不可预测性，但无法扩展。Context engineering 将 AI 协作扩展到多步骤任务，但留下了生产可靠性未解决。Harness engineering 通过引入前几种范式所缺乏的结构纪律解决了生产可靠性。

这不是每种范式被取代的故事。这是每种范式被纳入下一个的故事。Prompt engineering 仍然发生在设计良好的上下文中。Context engineering 是 harness 管理的一部分。Vibe coding 的直觉——清晰描述意图、快速迭代、关注结果而非实现——在 harness 层面构建时同样有价值。层级累积，它们不会相互抵消。

Harness Engineering 在实践中的样子

工作 Harness 的组件

为 AI 代理构建 harness 涉及传统软件工程尚未以这种方式解决的多个维度的决策。

Tool design 是基础。你赋予 AI 代理的每项能力——读取文件、调用 API、写入数据库、发送消息——都需要清晰定义，带有明确的接口和明确的限制。代理的行为部分取决于它访问的工具以及这些工具如何被描述。模糊的工具定义产生模糊的行为；精确的工具定义产生精确的行为。

Memory architecture 决定代理在交互间拥有多少连续性。无状态代理在调用间忘记一切，仅限于适合单个上下文窗口的任务。设计良好的记忆系统允许代理携带相关信息前进、引用过去决策并逐步构建理解——就像熟练的人类协作者一样。

Failure modes 需要明确设计。当代理无法完成步骤时它会做什么？它重试、升级给人类、记录失败并继续，还是停止？答案取决于特定部署上下文中每个选项的后果。没有定义失败行为的 harness 是不完整的。

Observability infrastructure 是让你理解代理实际做了什么的东西。工具调用、输入和输出、决策点和时序信息的日志使调试问题、审计行为和随时间改进系统成为可能。像黑箱一样工作的代理是你无法自信部署的代理。

Context Engineering 作为 Harness 的一部分

构建 harness 时 context engineering 不会消失——它成为 harness 的组件之一。Context engineering 产生的检索系统、记忆结构和工具定义是管理其使用方式的 harness 的输入。

对于工程团队来说，这通常意味着构建或采用 knowledge infrastructure，以便代理能可靠查询。技术文档、过去项目决策、代码历史、团队讨论——这些需要以服务代理需求而非仅团队临时浏览习惯的方式组织、索引和检索。

支持 passive knowledge capture and intelligent retrieval 的工具在此框架中成为 harness 基础设施的一部分——不是可选的生产力工具，而是使代理行为准确和有根据的系统的核心组件。Engineering teams that have built searchable knowledge bases 从本地技术文档构建的团队已经在构建 harness 的一层，无论他们是否这样描述。

这对 2026 年开发者意味着什么

心智模型必须扩展

Harness engineering 的实际含义不是每个开发者都需要一夜之间成为 AI 基础设施工程师。而是与 AI 合作的心智模型需要从提示和上下文扩展到包括结构、约束和系统思维。

Vibe coding 仍然有价值。 清晰描述意图和快速迭代的能力不会消失——它成为更大栈中的一层。

Prompt engineering 仍然是一项技能。 但它不是可能性的上限，也不是复杂系统中 AI 输出质量的主要决定因素。

Context design 比大多数开发者意识到的更重要。 你给 AI 什么信息、以什么形式、在何时检索——这些决策比大多数单个提示选择更能塑造输出质量，并且会随时间累积。

如果你要部署代理，你需要一个 harness。 不是因为它在智力上有趣，而是因为没有它，在开发中工作的代理会在生产中崩溃。Harness 是将强大但不可预测的系统转化为可靠系统的关键。

开发者的角色在转变，而非缩小

这个故事有一个版本将 harness engineering 描述为使开发者变得不那么必要的东西——如果 AI 可以写代码，为什么需要工程师？实际情况不同。

Harness engineering 恰恰需要经验丰富的开发者在职业生涯中培养的技能：系统思维、故障模式分析、可观察性设计、接口定义、架构约束。这些不是 AI 自动生成的东西。它们需要判断力、上下文，以及只有从构建过出错的系统才能获得的对可能出错之处的深刻理解。

理解这个栈所有四层的开发者——能够 vibe code 原型、为复杂任务设计上下文、设计检索系统，并为生产部署构建 harness——正在 2026 年软件开发前沿工作。

知识基础设施层

贯穿所有四种范式并在 harness engineering 层面最明显的一个主题是 knowledge infrastructure 的重要性。

在 vibe coding 中，知识是隐式的：AI 利用你当下描述的内容和其训练数据中的内容。在 prompt engineering 中，你开始刻意在提示中包含相关示例和上下文。在 context engineering 中，你构建检索系统，以便 AI 可以按需访问文档、项目历史和团队知识。在 harness engineering 中，知识库成为脚手架的一部分——代理查询它、更新它，并依赖它在会话间保持连贯状态。

这种进展意味着在 2026 年认真部署 AI 的团队越来越发现他们的知识基础设施是一种竞争优势。不仅是为了人类生产力，也是为了 AI 代理的质量和可靠性。能够访问组织良好、最新且相关知识的代理比盲目飞行的代理表现更好——构建这一知识层是必须刻意完成的事情。

常见问题

Harness engineering 与 AI safety 相同吗？

不完全相同。AI safety 是一个更广泛的领域，涉及对齐、长期风险和社会影响。Harness engineering 具体是关于使 AI 代理在生产软件系统中可靠和可信赖——一个更有限的、实用的工程问题。它们在某些地方重叠（两者都关心可控性和可观察性），但 harness engineering 是一门工程学科，而不是研究议程。

我需要从头构建 harness 吗？

不一定。LangChain、LlamaIndex 和新兴代理基础设施工具等框架提供了覆盖 harness 部分需求的脚手架。但使用框架不能替代设计决策：暴露哪些工具、如何处理失败、记录什么、记忆如何结构化。框架是起点，而不是完整答案。

这与 MLOps 有何不同？

MLOps 关注机器学习模型的生命周期——训练、评估、部署、监控、再训练。Harness engineering 关注使用预训练模型作为组件的 AI 代理的运行时行为。它们是处理栈不同部分的相邻学科。在生产中部署 AI 代理的团队可能需要两者的实践。

项目何时需要 harness engineering？

粗略的启发式方法：如果 AI 代理采取具有真实世界后果的操作（写入数据库、发送消息、部署代码、进行购买），你需要 harness。如果代理在多个步骤上运行且早期错误会累积，你需要 harness。如果你需要能够解释或审计代理做了什么，你需要 harness。如果失败意味着用户影响或数据丢失，你需要 harness。

范式在继续前进

Vibe coding 还不到一岁，harness engineering 就开始作为概念结晶。人类与 AI 合作方式的变化速度并没有放缓，将 harness engineering 视为 AI 辅助开发工作方式的最终定论将是一个错误。

这一进展的每一步都一致遵循以下模式：AI 获得更多能力和自主性，人类开发者通过构建更好的结构来引导这种自主性 productively。结构并不约束 AI 使其不那么有用——它们约束它使其更有用，因为可预测和可恢复的行为是使强大系统值得实际部署的可信赖性的关键。

在这个环境中最有效的开发者是那些能够流畅跨越所有四种范式的人：在需要快速原型设计时使用 vibe coding 直觉，在一致性重要时应用 prompt engineering 严谨，为复杂多步骤工作流设计上下文环境，并在真正的生产可靠性面临考验时构建完整 harness。

下一波浪潮不会取代前一波。它是为前一波提供更好的运行场所。