随着 AI Agent 在代码生成领域的狂飙突进，"Harness Engineering" 成为了当下工程界最火热的词汇。无论是大厂还是开源社区，都在努力构建各种沙箱、CI 管道和反馈环，试图让 AI 在长时间运行中完成端到端的交付。
受到这些前沿探索的启发，我的脑海中一直盘旋着一个问题：目前的 Harness 概念，绝大多数精力都集中在"代码生成之后"的反馈与修复上。那么，我们为什么不能在代码生成"之前"，就对其进行 Harness（约束）呢？
SDD 与单次 Prompt 的工程瓶颈
听到"生成前约束"，很多开发者的第一反应可能是 SDD (Spec-Driven Development，规范驱动开发)。
但站在架构师的视角审视目前的 SDD 框架，我们会发现一个致命的局限：它们产生的架构，往往过度聚焦于眼前的单一任务。受限于大模型的实现机制，这些 AI 生成的架构往往缺乏适当的"灵活性"与"扩展性"设计，导致在未来的功能迭代中迅速遭遇瓶颈。这也直接导致了一个现象：目前的 SDD 框架普遍将 Spec 视作"单次任务的过程性文件"。虽然有些框架会存储这些文件以便后续引用，但其本质依然是一次性的消耗品，而非系统的核心骨架。
在另一个极端，通过精心设计一份极度详尽的 Prompt 或 Spec，开发者确实能有效防止模型在生成中迷失方向，甚至可以结合 Claude Code 等工具，迅速生成一套完整的专属程序。
这种"巨型指令文件"的思路看似直觉合理，但 OpenAI 的 Harness Engineering 团队已经用实践证明了它的局限。他们在构建百万行级代码库的过程中，最初尝试了"一个大型 AGENTS.md"的方案，结果以可预见的方式失败了：上下文是稀缺资源，一个巨大的指令文件会挤占任务本身、代码和相关文档的空间；当所有规则都被标记为"重要"时，等于没有任何规则是重要的；而且这种单体文件会迅速腐化，Agent 无法分辨哪些规则仍然有效。最终，他们不得不将其重构为一个精简的"目录"，指向更深层的、结构化的设计文档。
这个教训揭示了一个根本性问题：如果我们的目标是探索一套真正通用的 Harness 架构框架，用来承载中型甚至大型的软件项目，无论是粗放的单次 Prompt，还是将所有约束堆砌在一个文件中的做法，都显得捉襟见肘。当代码量急剧膨胀，微小的改动极易引发 AI 的"架构漂移（Architectural Drift）"——为了修复一个边缘 Bug，AI 可能会不知不觉地重构掉核心模块。
传统智慧的回归：逐步细化与活着的设计文档
破局的关键，或许并不在最新的 AI 论文里，而在于 50 多年前就已经确立的软件工程传统智慧中："逐步细化（Stepwise Refinement）"与"模块化（Modularization）"。
在前面的文章中，我之所以首先探讨 C4 Model，正是因为多层架构视角是大型系统管控的基石。在这个体系下，我们可以将功能或 Bug 的影响范围，进行严密的逐层确认。
这就是 Harness Architecture 的核心思想：为项目维护一份"活着的设计文档（Living Design Document）"，并将其作为每次代码生成的绝对上下文。
通过逐步细化和模块化的契约设计，我们可以实现两个极具工程价值的目标：
- 控制爆炸半径，提升精度： 每次功能迭代，都在架构层自上而下分解。处于执行层的 AI，甚至不需要知道本次迭代的"宏观全貌"，它只需要关注分配给它的"子模块接口变化"。上下文越小，大模型的输出精度就越高，幻觉越少。
- 极速降低 Token 消耗： 摒弃将几万行代码作为上下文一股脑塞给大模型的暴力做法，取而代之的是精准投喂局部架构契约。
SDLC 中的生态位：Design, Architecture 与 Engineering
在整个软件生命周期（SDLC）中，Harness Architecture 并不是孤立的，它与目前热议的 Harness Design 和 Harness Engineering 是完美的拼图关系：
- Harness Design (需求与交互设计)： 处于系统前端，处理模糊的业务需求，通过多模型的交叉验证与评审来产出交互设计。由于天然带有不确定性，这里无法直接上工程约束。
- Harness Architecture (架构约束)： 当需求趋于稳定，传统的架构思想开始接管。它指导 AI 进行模块划分、契约定义和逻辑流转，将发散的需求转化为确定的设计前置。
- Harness Engineering (执行与兜底)： 负责在微观层面处理代码的编译、测试反馈与持续集成。
如果把大语言模型比作一匹日行千里的野马，Harness Engineering 就像是防止它跑偏坠崖的"缰绳和护栏"，而 Harness Architecture 则是给马戴上的"眼罩"。它屏蔽掉无关的全局干扰，让 AI 只能在人类架构师规划好的、绝对安全的契约轨道上向前狂奔。
结语
目前，Harness Architecture 在我心中还只是一个雏形。与其说它是一种从零构建的新概念，不如说是我将多年架构设计工作中接触到的经典理念（如 C4 模型、契约式设计），与当下大模型的特质进行的一次重新整合。
但我坚信这个方向的未来。在接下来的系列文章中，我将逐步展开探讨：如何在实际的架构操作层面落实这种物理级的约束体系。
我也非常期待能与更多对 AI 原生软件工程感兴趣的同行、架构师们交流，一起把这个粗糙的雏形打磨成通往下一代研发范式的利器。
本文首发于公众号【架构余绪】，转载请注明出处。
如果你对软件架构设计以及AI驱动下的架构设计感兴趣，欢迎来我的公众号交流，那里有更完整的系列文章。
