模型之外的工程
Harness Engineering 可以直译成“挽具工程”，但这个中文并不直观。更贴近实际的理解是：为一个有能力、也会犯错的执行者，搭建一套可控的工作环境。
Harness 包含什么
它不只是提示词。一个完整的 Harness 往往还包括：
- 任务需要的上下文
- 可调用工具的边界
- 过程中的状态记录
- 失败后的重试与恢复
- 交付前的检查方法
模型像发动机，Harness 决定动力能不能安全地传到车轮上。
为什么它会越来越重要
模型变强会降低“生成一个看起来合理答案”的成本，却不会自动降低真实世界里的协调成本。文件可能过期，接口可能失败，权限可能不足，需求也可能彼此冲突。
好的 Harness 不假设这些问题不会发生，而是让它们发生时能够被看见、被定位、被修复。
最小可用原则
并不是控制越多越好。每增加一层规则，都应该回答两个问题：
- 它防止了哪一种真实失败？
- 它是否让正常工作变得更慢？
只有经得住这两个问题的约束，才值得长期保留。