Harness Engineering崛起，规范驱动开发还有价值吗？

近期，一个名为「Harness Engineering」的概念在AI工程领域引起了广泛关注。HashiCorp联合创始人Mitchell Hashimoto和OpenAI工程团队先后发文，阐述了一套让AI Agent可靠工作的工程方法论。与此同时，规范驱动开发（SDD）作为一种通过结构化规范指导AI编程的实践，也正在被越来越多的团队采纳。这不禁引发了一个关键问题：当Harness体系不断完善时，投入精力构建规范体系是否仍然有意义？

Harness到底是什么

在回答这个问题之前，需要先厘清Harness的含义。Mitchell Hashimoto将Harness定义为：当发现Agent犯错误时，花时间工程化一个解决方案，确保Agent不再重犯同类错误。具体做法包括记录Agent的异常行为模式（如Ghostty项目的AGENTS.md），以及编写专用工具脚本让Agent能够自我验证。OpenAI则从团队系统的层面描述了更大规模的实践——5个月内用约100万行代码构建完整系统，全部由Agent生成代码，人类工程师的职责转向定义产品规格、设计约束和搭建反馈系统等支撑性工作。两个视角指向同一个核心：Harness是让Agent可靠工作的系统环境，而不仅仅是模型本身。

工程纪律的转移

OpenAI在其官方文章中指出：「构建软件仍然需要纪律，但纪律更多地体现在支撑结构上，而不是代码上。」这一论断揭示了一个重要趋势：工程纪律的重心正在从「如何写好代码」转移到「如何构建支撑Agent工作的系统体系」——包括结构化的文档、明确的约束规则、完善的反馈回路等。从代码驱动转向环境设计，是这场变革的本质特征。OpenAI还特别强调了一个关键发现：从Agent的视角来看，它在运行时无法访问的内容都等同于「不存在」——存储在文档、聊天记录或人类头脑中的知识无法被系统触及，只有仓库本地版本化的工件才是Agent所能看到的全部。

Spec在Harness中的三个核心角色

一旦理解了这个背景，Spec在Harness中的角色就变得清晰。首先，Spec是Agent推理的「地图」而非「百科全书」。OpenAI的实践原则是「给Agent一张地图」，通过渐进式披露机制，让Agent从高层概览出发，按需深入到具体节点，而不是一开始就被海量信息淹没。其次，Spec是约束生效的语义基础。虽然linter可以机械地强制执行格式层面的约束，但语义层面的约定——如跨服务的错误码处理、接口字段的业务含义、状态流转规则——必须显式写入Spec，Agent才能正确推理。第三，Spec是反馈回路的正确性判据。Harness的飞轮运转需要「发现错误」的前提，而这需要明确的正确性判据。Spec中的验收标准层（WHEN/THEN Scenario）正是提供了这个判据，让Agent的输出可以被自动对照验证。

为什么SDD反而更重要了

基于上述分析，答案变得清晰：SDD不仅没有失去意义，反而因为Harness的成熟而变得更为重要。Harness是放大器——它放大Agent的执行能力，也放大输入内容的影响。Spec写得好，Harness将其放大为可靠的、一致的、可验证的输出；Spec写得差，Harness则把Agent的猜测放大为高效率地产出错误。这类似于高速公路的护栏比自行车道更必要——不是因为车速更危险，而是因为速度更快、后果更严重。此外，SDD解决的是一个根本问题：将知识从「人脑+对话历史」转化为「仓库里版本化的结构化资产」，让设计决策和跨服务约定不会随人或会话流失。

如有侵权，请联系删除。