SDD 之外是 Harness 吗？

文章SDD 之外是 Harness 吗？分享给大家，欢迎收藏极客资料网，专注分享技术知识

最近反复听到看到Harness这个词，看到大家对Harness疯狂讨论、起中文名！所以写个我理解下的科普文，说一下AI时代是怎么一步一步演进到此的，下一阶段我们要面对的是什么。

从提示词工程到 Harness Engineering，AI 编程这条线一直在做同一件事：人离代码越来越远，但对产出的控制力越来越强。提示词工程操控的是一句话，Harness 操控的是一整套执行环境。但只要这套环境还需要人来搭建，它就还不是终点。

2026 年 2 月，OpenAI 的工程师 Ryan Lopopolo 发了一篇博文，标题是 Harness Engineering: Leveraging Codex in an Agent-First World。内容很直白：他们用 3 个工程师，5 个月时间，让 Codex 生成了大约 100 万行代码，产品已经有内部日活和外部测试用户，零行手写代码。平均每个工程师每天合并 3.5 个 PR，而且随着团队从 3 人扩展到 7 人，吞吐量还在上升。

这篇文章在社区里引发了大量讨论。但大多数人把注意力放在了「100 万行」这个数字上，忽略了更重要的信息：这 3 个工程师到底在干什么？

他们不写代码。他们设计环境、指定意图、构建反馈循环。用 OpenAI 自己的话说：Humans steer. Agents execute.

这就是 Harness Engineering。OpenAI 内部有一个判断：模型变更对输出质量的影响是 10% 到 15%，而 Harness 的设计决定了 Agent 可靠性的 80%。大多数被归咎于「模型不行」的问题，其实是 Harness 没搭好。

1. 提示词工程：让 AI 听懂你说的话

大家发现不同的提示词、不同的角色设定对输出影响巨大，于是开始研究怎么写更好的 prompt。核心发现是：AI 的能力一直都在，关键看你怎么激发。但很快碰到天花板，提示词再怎么优化，也只能控制一次输入输出。任务复杂了，一段 prompt 撑不住。

2. 上下文工程：控制信息流

输入输出越来越长，怎么管理上下文窗口、怎么提供有效信息、怎么裁剪和分段，变成了一个独立的课题。yage之前讨论过这个话题：决定产出质量的不是模型智能，而是你注入的 context 密度。上下文工程到今天也没有过时，它是一切后续工作的地基。

3. Vibe Coding：让 AI 自己动手

AI 可以自己写代码、自己操作文件了。Claude Code、Codex CLI、Cursor 这些工具让「AI 写代码」从概念变成了日常。但问题随之而来：AI 写的代码质量不稳定，调试困难，跑偏了不容易发现。Vibe Coding 解决了「能不能写」的问题，没解决「写得对不对」的问题。

4. SDD：用规格体系约束产出

SDD（Spec-Driven Development，规格驱动开发）的思路是把结构化的文档体系放在开发的中心。这个体系不只包含需求规格说明书，还往下延伸到架构设计、接口定义、开发计划。

每一层文档都在约束下一层的细化程度：需求规格定义业务目标和验收标准，设计文档在此基础上定义架构和技术选型，开发计划把设计拆解为可执行的任务。不是一上来就把所有细节写死，而是逐层展开、逐层收敛。AI 写的每一行代码都要可追溯到这条文档链上，不符合规格的代码就是错的。它解决的是 Vibe Coding 留下的可靠性缺口。

但 SDD 的约束发生在编码之前，通过文档链传递。规格体系写得再完善，AI 真正开始写代码之后跑偏了、上下文污染了、工具调用失败了，你未必知道。SDD 定义了"什么算对"，但缺一套运行时机制来持续校验"是否真的做对了"。这个缺口需要另一种东西来填。

光说概念容易虚。看看 OpenAI 的 Harness 实际做了什么。

上下文管理：给地图，不给百科全书

OpenAI 最早试了「一个大 AGENTS.md」的方案，失败了。一个巨型指令文件会挤占任务和代码的空间，太多指导等于没有指导，而且腐朽得很快。他们后来把 AGENTS.md 缩到大约 100 行，当作目录而不是百科全书。真正的知识放在结构化的 docs/ 目录里：设计文档、执行计划、产品规格、架构文档、质量评分。

和我们日常用的 [[如何用AI重塑工作|Skill 系统]]是同一个思路：AGENTS.md 是 L1 cache，告诉 Agent 有哪些能力方向；docs/ 目录是 L2，按需加载具体文档；具体的规格文件和参考手册是 L3，只在相关任务中被读取。每一层只暴露当前决策所必需的信息。

更关键的是，他们用 linter 和 CI 机械地校验知识库的时效性、交叉链接和结构正确性，定期跑一个「doc-gardening」Agent 扫描过时文档并自动开 PR 修复。知识不会烂在仓库里。

可观测性：让 Agent 能自己测试

OpenAI 做了一件很有意思的事：让应用按 git worktree 隔离启动，Codex 每次改代码都能开一个独立实例来验证。他们把 Chrome DevTools Protocol 接入了 Agent 运行时，Agent 能拿到 DOM 快照、截图、导航事件，自己复现 bug、验证修复。所以像「确保服务启动在 800ms 以内」这种约束，从一句空话变成了可执行的检查项。

他们经常看到 Codex 单次运行连续工作 6 个小时以上，很多时候工程师在睡觉。

架构约束：边界比实现更重要

OpenAI 把应用分成固定的层级（Types → Config → Repo → Service → Runtime → UI），跨层依赖方向严格限定。这些约束用自定义 linter 机械执行，linter 的错误消息直接注入修复指令到 Agent 上下文。他们强制要求在边界解析数据（parse, don't validate），但不指定用什么库。

另外他们不要求 Agent 使用通用的 p-limit 并发控制包，而是让 Agent 自己实现了一个。因为这个自实现版本和他们的监控体系完全集成，行为可控。对于 Agent 来说，「无聊」的技术反而更好用，因为可组合、API 稳定、训练数据里见过得多。

熵管理：垃圾回收式的技术债治理

Agent 会复制仓库里已有的模式，包括不好的模式。OpenAI 早期每周五花 20% 时间清理「AI slop」，后来改成把「黄金原则」编码到仓库里：优先使用共享工具包而不是手写辅助函数；不允许 YOLO 式的数据探测，必须在边界校验。定期跑后台任务扫描偏差、开重构 PR，大多数 PR 审查不到一分钟就能 automerge。

他们的原话：技术债像高息贷款，持续小额偿还几乎总是比让它复利增长然后一次性处理要好。

最直接的证据来自 LangChain。他们在 Terminal Bench 2.0 上没换模型，只优化了 Harness：强调自验证循环的系统提示、增强工具和上下文注入、中间件钩子检测死循环。结果从 52.8% 跳到 66.5%，排名从 Top 30 到 Top 5。同一个模型，同样的任务，只靠 Harness 的差异就能拉开这么大的差距。

其他团队也观察到了类似现象。Anthropic 发现让同一个 LLM 写代码又检查代码，它会自欺欺人，写完做表面审查就宣布"没问题"，不跑测试。他们叫这 Poor Self-Evaluation Bias，解决方案是强制角色隔离。Vercel 则发现给 Agent 配 15 个工具成功率只有 80%，砍到 2 个反而 100%。工具多了不是赋能，是干扰。

SDD 和 Harness 解决的是同一个大问题（AI 编程的可靠性），但切入角度正交。

SDD 通过文档链传递约束，发生在编码之前。它定义"做什么"和"按什么标准做"，从需求规格到架构设计到开发计划，逐层收敛。Harness 通过运行时系统传递约束，发生在编码过程中。它校验 Agent 每一步的实际产出是否偏离了规格。

用施工打比方：SDD 是施工图纸和工艺规范，Harness 是脚手架、质检流程和现场监控系统。没有图纸和规范，施工队不知道该建什么；没有脚手架和质检，图纸画得再好工人也会出事。两者确实可以独立存在：写了一套完整的规格体系但没有 Harness 保护，跑偏了不知道；反过来也一样，有精密的施工管理系统但没人知道该建什么。但独立存在不意味着各自为政。真正高效的工作流是两者叠加：SDD 的文档链为 Harness 的验证层提供校验标准，Harness 在每一步执行中拿规格去对照 Agent 的实际产出。

如果硬要放一条演进线上：Vibe Coding 让 AI 能写代码，SDD 让 AI 按规格写代码，Harness 让 AI 持续可靠地按规格写代码。每一层解决前一层遗留的可靠性问题，但它们不是简单的替代关系，更像是互补。

AI 编程的终局，我觉得是 AI 变成编译器。

编译器的核心特征是确定性：给定相同的输入，输出一定相同。现在的 LLM 从根上就不是确定性的，它是概率预测。同一个需求跑两次，出来的代码不一样，质量也不一样。这是当前 AI 编程最大的问题，也是 SDD 和 Harness 存在的根本理由。

它们做的事情，本质上就是缩小模型的不确定性窗口。

SDD 从输入端收窄：规格文档写得越精确，模型的输出空间就越小，模糊的可能性被收窄到可预测的范围。

Harness 从过程端收窄：即使输入精确，模型在多步执行中也会累积偏差。验证循环纠正漂移，角色隔离防止自欺欺人，工具裁剪减少选择错误。

反馈循环从输出端收窄：自动化测试、linter、人工审查校验最终产出，错误的信号被喂回规格和 Harness，让下一轮执行更收敛。

三层合在一起，用工程手段模拟编译器的确定性。模型本身不够确定，就用外部约束把它逼到接近确定。OpenAI 的 80% 因子说的就是这个意思：在当前模型能力下，外部约束对最终可靠性的贡献远大于模型本身。

顺着这个逻辑推到极端：模型完全确定性了，SDD 和 Harness 是不是就没用了？大概率不是。编译器是确定性的，但我们仍然需要架构设计、代码规范和 CI 流水线。大型系统的复杂性不会因为模型变确定就消失。模型不确定性只是当前最紧迫的那个变量。

在那之前，外部工程能做的，就是不断缩小这个不确定性窗口。

文章来源:https://www.cnblogs.com/zer0Black/p/19834447
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若内容造成侵权/违法违规/事实不符，请联系邮箱：jacktools123@163.com进行投诉反馈，一经查实，立即删除！