Martin Fowler 近日在 Thoughtworks Engineering 博客发布了万字长文，系统阐述 Harness Engineering for Coding Agent Users——这是目前对"如何工程化一个编码 Agent"最体系化的框架描述。
核心公式：Agent = Model + Harness
Fowler 借用了 LangChain 的经典公式：
Agent = Model + Harness
Harness 在这里指的是"模型以外的所有东西"——系统提示词、代码检索机制、编排系统、规则、工具链。在编码 Agent 场景下，Harness 被分为两层：
- Builder Harness（底层）：Agent 构建者提供的内置能力
- User Harness（外层）：用户为自己的场景搭建的外部控制层
这篇文章的核心就是讲如何构建 User Harness。
两大控制手段：Guides 和 Sensors
Guides（前置引导）
在 Agent 行动之前提供引导，提升一次做对的概率。
Sensors（反馈感知）
在 Agent 行动之后观察结果，帮助其自我修正。特别是那些专门针对 LLM 消费优化过的传感器信息——例如自定义 linter 消息，包含 Agent 自我修正指令。
只有 Guide 没有 Sensor：Agent 编码规则但从不知道效果如何。
只有 Sensor 没有 Guide：Agent 重复犯同样的错误。
两者缺一不可。
计算式 vs 推理式：两种执行类型
这是文章的关键分类框架：
| 类型 | 运行方式 | 特点 |
|---|---|---|
| Computational（计算式） | CPU 执行，确定性，毫秒级 | 测试、linter、类型检查、结构分析 |
| Inferential（推理式） | GPU/NPU 执行，慢且贵，非确定性 | AI 代码审查、"LLM as judge"、语义分析 |
两者的分工原则：
- Computational Controls 便宜快速，每次代码变更都可以运行
- Inferential Controls 昂贵且结果不稳定，但在需要语义判断时能提供远超规则引擎的能力
工具对照表（原文核心精华）
| 控制方向 | 执行类型 | 示例实现 |
|---|---|---|
| 编码规范 | feedforward · inferential | AGENTS.md、Skills |
| 项目启动引导 | feedforward · 两者皆可 | Skill + bootstrap script |
| Code Mods | feedforward · computational | OpenRewrite 配方工具 |
| 结构测试 | feedback · computational | ArchUnit 模块边界检查 |
| 评审引导 | feedback · inferential | Skills |
掌舵循环：人类的作用
Fowler 提出的核心操作模式：人类负责迭代 Harness，不是盯着 Agent 干活。
掌舵循环的逻辑：
- 问题出现多次 → 人类改进 Guide 或 Sensor
- 让问题在未来变得更不可能发生，甚至提前阻止
- Agent 也可以帮助改进 Harness——生成结构性测试、写草稿规则、搭 custom linter、从代码库里考古生成 how-to 指南
AI 可以用来改善 Harness 本身，这是一个重要的递归视角。
调节三维度：Maintainability / Architecture / Behaviour
Harness 不是铁板一块，Fowler 建议按调节目标分成三类：
1. Maintainability Harness（可维护性）
这是目前最成熟的维度——大量现成工具可以直接用：
- Computational Sensors：检测重复代码、圈复杂度、测试覆盖率、架构漂移、代码风格违规
- Inferential Sensors：语义重复代码、冗余测试、over-engineering（但贵且概率性）
对于"正确性问题"——misdiagnosis、overengineering、指令理解错误——两类传感器都无法可靠捕获。这一块仍然需要人类介入。
2. Architecture Fitness Harness（架构适应性）
即 Fitness Functions 思想的延伸：
- Guide：性能需求（通过 Skills 前馈）、可观测性编码规范
- Sensor：性能测试反馈、debug 质量反思
3. Behaviour Harness（行为正确性）
这是最难的环节，也是目前方案最薄弱的：
目前大多数人的做法是"相信 AI 生成的测试套件"——但这还不够。
Fowler 同事在实践中看到不错效果的是 Approved Fixtures 模式：人类预先批准某些关键测试用例，Agent 在这个基础上扩展，而非从头生成全部测试。但这只在部分场景适用，不能全面解决问题。
与 Context Engineering 的关系
这是文章末尾的重要脚注：Harness Engineering 是 Context Engineering 在编码 Agent 场景的具体形态。
Context Engineering 提供的是"让 Guides 和 Sensors 对 Agent 可见"的机制；Harness Engineering 则是在这个机制上，针对编码场景搭建具体的控制层。
对 SOTA Sync 的意义
Fowler 这篇文章的价值在于：它把 Agent 工程化从"调 prompt"的玄学阶段，拉到了"系统控制论"的工程学阶段。
几个可以直接落地的东西：
- 拿到一个新代码库，先评估它的 Harnessability（强类型语言天然有 type checker 作为 sensor，模块边界清晰则可以上 ArchUnit）
- 建设 Agent 编程流程时，先问：feedforward 和 feedback 是否都存在？比例是否合理？
- 人类的时间应该花在掌舵（Steering）——迭代 Harness，而不是盯着 Agent 逐行review
这是 Agent 编程走向工程化的重要一步。