在大模型与 Agent 快速渗透开发流程的当下，一个新的工程范式正在浮出水面——Harness Engineering。
相比 prompt、context、agent 等更偏“能力侧”的概念，Harness Engineering 直指一个更底层的问题：
当代码不再由人一次性写完，而是由 Agent 持续生成时，系统如何保持稳定？
这不仅是工程问题，更接近一个经典但被忽视的领域——控制系统设计。
一个反直觉的现实正在被越来越多团队验证：
在短任务中，大模型表现优异；但在长周期、多步骤的工程任务中，问题迅速暴露：
关键不在于模型“聪不聪明”，而在于：
系统缺乏约束与反馈机制，导致行为不可控
传统软件工程是一个相对静态的过程：
而在 Agent 参与后，流程变为：
这一变化带来的核心影响是：
也就是说，软件不再是“构建完成后运行”，而是：
一个持续生成、持续变化的动态系统
早期实践中，开发者试图通过 prompt engineering 控制输出：
但在复杂任务中，这种方式很快失效，因为：
本质上，这是一个典型的开环系统（open-loop）。
随后，Agent + Loop 模式出现：
看似形成闭环，但实际效果往往是：
每轮输出引入微小误差，逐步放大
系统结构被多次局部修改破坏
Agent 只优化当前问题，忽略整体一致性
因此可以得出一个关键结论：
Loop 让系统“持续运行”，但不保证“稳定运行”。
在这一背景下，在其 Agent 实践（如 Codex 系统）中提出了 Harness Engineering 概念。
其核心不是工具，而是一个转变：
不再问模型为什么出错，而是问系统为什么允许它出错
Harness Engineering 可以理解为：
其核心组成包括三部分：
作用是：减少错误产生
作用是：限制系统状态空间
作用是：持续纠正偏差
如果用控制系统的视角来看：
这一结构对应经典的闭环控制系统，其理论基础可以追溯到 提出的控制论（cybernetics）。
甚至更早，在 的蒸汽机调速器中，就已经体现了类似思想：通过反馈调节系统状态，使其保持稳定。
这也解释了一个有趣的现象——这个名字本身就源于“舵手”，与控制论同源。
关键在于它改变了系统的三个核心属性：
明确输入边界，让 Agent 不再“猜测”
缩小可行动范围，避免结构失控
让错误无法持续存在
三者叠加后，系统具备了一个重要能力：
从“不断偏离”转为“持续收敛”
如果从系统论角度进一步抽象，可以发现：
因此，AI 时代的软件工程，本质是在做一件事：
控制熵的增长
具体手段包括：
目标不是“让系统更强”，而是：
让系统不失控
Harness Engineering 带来的最大变化，是工程关注点的转移：
过去关注：
现在关注：
换句话说：
工程对象从“代码”，变成了“持续运行的行为系统”。
在 AI 工程体系中，正在形成一个新的分工：
三者缺一不可。
如果没有 Harness，再强的模型也可能导致系统失控；而一旦控制机制建立，AI 才真正具备进入生产级工程体系的条件。
最终问题不再是：
而是：
我们能否设计出一个系统，让它在持续写代码的过程中，始终不偏离目标。
这，才是 AI 时代软件工程真正的分水岭。