---
title: "编码智能体用户的 Harness Engineering"
sourceTitle: "Harness engineering for coding agent users"
sourceUrl: "https://martinfowler.com/articles/harness-engineering.html"
sourceAuthor: "Birgitta Böckeler (Thoughtworks)"
sourcePublishedAt: "2026-04-02"
translationMethod: "baoyu-translate skill (refined mode)"
language: "zh-CN"
sourceFigureCount: 6
---

# 编码智能体用户的 Harness Engineering

*要让编码智能体（Coding Agent）以更少的监督工作，我们需要有办法增强对其结果的信心。作为软件工程师，我们对 AI 生成的代码天然存在信任屏障——LLM 是非确定性的，它们不了解我们的上下文，也并不真正理解代码，它们以 token 为单位思考。本文探索一种心智模型，将上下文工程（Context Engineering）和 Harness Engineering（驾驭工程）中正在涌现的概念整合在一起，以建立这种信任。*

Birgitta Böckeler 是 Thoughtworks 的杰出工程师和 AI 辅助交付专家，拥有超过 20 年的软件开发、架构和技术领导经验。

2026 年 4 月 2 日

---

本文更新了我早前一篇概述 Harness Engineering 初步印象的备忘录。Harness 这个词已经成为一种速记，意思是 AI 智能体中除模型之外的一切——智能体 = 模型 + Harness。这是一个非常宽泛的定义，因此有必要在常见的智能体类别中缩小其含义。我想在**使用编码智能体**这个限界上下文（bounded context）中定义它的含义。在编码智能体中，Harness 的一部分是内建的（例如通过系统提示词、选定的代码检索机制，甚至是一个复杂的编排系统）。但编码智能体也为我们——它们的用户——提供了许多功能，让我们能够专门为自己的用例和系统构建一个外层 Harness（outer harness）。

> 有人向我指出，在 harness 外面再套 harness 在概念上说不通："你试过把 harness（马具/牵引带）套在狗的里面吗？"我听到了，但如果限界上下文的方法确实有助于驾驭这个词的用法，我愿意容忍这个比喻上的牵强。

![图 1：三个同心圆，模型位于核心，编码智能体的内建 Harness（builder harness）在下一环，编码智能体的用户 Harness（user harness）作为最外层——每个限界上下文赋予"Harness"不同的含义](https://martinfowler.com/articles/harness-engineering/harness-bounded-contexts.png)

*[图 1：三个同心圆，模型位于核心，编码智能体的内建 Harness（builder harness）在下一环，编码智能体的用户 Harness（user harness）作为最外层——每个限界上下文赋予"Harness"不同的含义。]*

一个精心构建的外层 Harness 服务于两个目标：它提高智能体一次就做对的概率，并提供一个反馈环路，在问题到达人类眼前之前尽可能多地自我纠正。最终，它应当减少审查负担、提高系统质量，同时还能减少不必要的 token 消耗。

## 前馈与反馈

![图 2：编码智能体用户的 Harness Engineering。引导器（前馈）和传感器（反馈）的概览，包含计算性和推理性两种执行类型](https://martinfowler.com/articles/harness-engineering/harness-overview.png)

*[图 2：编码智能体用户的 Harness Engineering。引导器（前馈）和传感器（反馈）的概览，包含计算性和推理性两种执行类型。]*

要驾驭编码智能体，我们既要预见不想要的输出并尝试预防，又要部署传感器（Sensor）让智能体能够自我纠正。

**引导器（Guides，前馈控制）**——预判智能体的行为，在它行动之前加以引导。引导器提高智能体首次尝试就产出好结果的概率。

**传感器（Sensors，反馈控制）**——在智能体行动之后进行观测，帮助它自我纠正。当传感器产生的信号针对 LLM 消费做了优化时尤其强大，例如自定义 linter 消息中包含自我纠正的指令——一种积极的提示词注入（prompt injection）。

如果只有其中一种，你得到的要么是一个不断重复同样错误的智能体（只有反馈），要么是一个编码了规则却永远不知道规则是否生效的智能体（只有前馈）。

## 计算性 vs 推理性

引导器和传感器有两种执行类型：

**计算性（Computational）**——确定性且快速，由 CPU 运行。测试、linter、类型检查器、结构分析。毫秒到秒级完成，结果可靠。

**推理性（Inferential）**——语义分析、AI 代码审查、LLM-as-judge。通常由 GPU 或 NPU 运行。更慢且更昂贵，结果更具非确定性。

计算性引导器通过确定性工具提高好结果的概率。计算性传感器足够便宜和快速，可以在每次变更时与智能体一同运行。推理性控制当然更昂贵且非确定性，但允许我们既提供丰富的引导，又增加额外的语义判断。尽管推理性传感器具有非确定性，但当与一个强大的模型——更准确地说，一个适合当前任务的模型——一起使用时，尤其能增强我们的信任。

**示例：**

| 方向 | 计算性/推理性 | 示例 |
|------|--------------|------|
| 编码规范 | 前馈 | 推理性：AGENTS.md、Skills |
| 新项目引导指令 | 前馈 | 两者兼有：带有指令和引导脚本的 Skill |
| 代码变换 | 前馈 | 计算性：使用 OpenRewrite 配方的工具 |
| 结构测试 | 反馈 | 计算性：预提交/编码智能体钩子运行 ArchUnit 测试 |
| 审查指南 | 反馈 | 推理性：Skills |

## Harness Engineering 与上下文工程的关系

> 上下文工程为我们提供了将引导器和传感器提供给智能体的手段。为编码智能体构建用户 Harness 是上下文工程的一种具体形式。

## 持续调优

人类在其中的角色是通过迭代 Harness 来引导智能体。每当一个问题多次出现，就应该改进前馈和反馈控制，使该问题在未来不太可能发生，甚至完全阻止它。

我们当然也可以用 AI 来改进 Harness。智能体可以帮助编写结构测试、从模式中生成草稿规则、搭建自定义 linter 脚手架，或者从代码库考古中创建操作指南。

## 时机：质量左移

持续集成的团队一直面临一个挑战：根据成本、速度和关键性，在开发时间线上分配测试、检查和人工审查。原则是：越早发现问题，修复成本越低。

关键问题包括：
- 哪些在集成甚至提交创建之前运行（linter、快速测试套件、基础审查智能体）？
- 哪些在集成后的流水线中运行（变异测试、全面代码审查）？

**变更生命周期中的前馈与反馈：**

- **前馈示例：** LSP、architecture.md、/how-to-test skill、AGENTS.md、用于知识管理的 MCP 服务器
- **第一自我纠正环路反馈：** /code-review、eslint、semgrep、覆盖率、dep-cruiser
- **集成后流水线传感器 + 昂贵选项：** /architecture-review skill、/detailed-review skill、变异测试

![变更生命周期中的前馈与反馈示例：前馈引导初始生成，第一自我纠正环路与人工审查提供反馈，集成后流水线重跑所有传感器并追加更昂贵的传感器](https://martinfowler.com/articles/harness-engineering/harness-change-lifecycle-examples.png)

**持续漂移与健康传感器：**
- 持续监测的渐进漂移（死代码检测、测试覆盖率质量分析、依赖扫描）
- 运行时反馈（SLO 退化建议、响应质量采样、日志异常标记）

![变更集成后的持续反馈传感器示例：代码库中的持续漂移检测（如 /find-dead-code、/code-coverage-quality、dependabot），以及持续运行时反馈（如延迟、错误率或可用性 SLO 触发编码智能体建议，/response-quality-sampling、/log-anomalies AI 评审）](https://martinfowler.com/articles/harness-engineering/harness-continuous-feedback-examples.png)

## 调控类别

智能体 Harness 就像一个控制论调速器（cybernetic governor），将前馈和反馈结合起来，将代码库调控到期望的状态。以下三个类别有助于思考 Harness 的不同调控对象：

### 可维护性 Harness

本文中的绝大多数示例都是关于调控内部代码质量和可维护性的。这是目前最容易构建的 Harness 类型，因为我们有大量现有工具可用。

为了评估上述可维护性 Harness 理念能在多大程度上增强我对智能体的信任，我将之前编录的常见编码智能体失败模式与之做了映射。

计算性传感器可靠地捕捉结构性问题：重复代码、圈复杂度、缺失的测试覆盖率、架构漂移、风格违规。这些方法便宜、成熟且确定性。

LLM 可以部分解决需要语义判断的问题——语义重复代码、冗余测试、暴力修复、过度工程化的方案——但代价高昂且概率性强，不适合在每次提交时运行。

但两者都无法可靠捕捉一些影响更大的问题：问题误诊、过度工程化和不必要的功能、对指令的误解。它们有时能捕捉到，但不够可靠到足以减少监督。如果人类一开始就没有清晰地说明自己想要什么，正确性就超出了任何传感器的管辖范围。

### 架构适应度 Harness

这一类别包括定义和检查应用架构特性的引导器和传感器。基本上就是：适应度函数（Fitness Functions）。

示例：
- 传达性能需求的 Skills（前馈），结合反馈改进或退化的性能测试
- 可观测性编码规范的 Skills，结合要求智能体反思其可用日志质量的调试指令

### 行为 Harness

这是房间里的大象——我们如何引导和感知应用是否在功能上按我们需要的方式运行？

据我观察，目前大多数赋予编码智能体高自主性的人是这样做的：

**前馈：** 一份功能规格说明（详细程度不等，从简短的提示词到多文件描述）。

**反馈：** 检查 AI 生成的测试套件是否通过、是否有合理的高覆盖率，有些人甚至用变异测试监控其质量，然后结合手动测试。

这种方法对 AI 生成的测试寄予了过多信任，目前还不够好。我的一些同事在使用"预审批基准"模式（approved fixtures pattern）时看到了不错的结果，但这种模式在某些领域比其他领域更容易应用。他们在合适的地方选择性地使用它，它并不是测试质量问题的全面解答。

因此总体而言，我们在弄清楚有效的功能行为 Harness 方面还有很多工作要做，这些 Harness 需要能够充分增强我们的信心，以减少监督和手动测试。

![图 3：Harness 的简化概览，展示了三个调控类别（可维护性、架构适应度和行为）的引导器和传感器](https://martinfowler.com/articles/harness-engineering/harness-types.png)

*[图 3：Harness 的简化概览，展示了三个调控类别（可维护性、架构适应度和行为）的引导器和传感器。]*

## 可驾驭性

并非每个代码库都同样适合驾驭。使用强类型语言编写的代码库天然拥有类型检查作为传感器；清晰可定义的模块边界支持架构约束规则；像 Spring 这样的框架抽象掉了智能体甚至不需要操心的细节，从而隐式地提高了智能体的成功概率。没有这些特性，就无法构建这些控制。

## 环境可供性

我的同事 Ned Letcher 用"环境可供性"（ambient affordances）来描述使智能体环境更具可驾驭性的特性："环境本身的结构性属性，使其对在其中运作的智能体而言是可读的、可导航的和可处理的。"

这在全新项目与遗留系统中表现不同。全新项目团队可以从第一天起就内建可驾驭性——技术决策和架构选择决定了代码库的可治理程度。遗留系统团队，尤其是那些积累了大量技术债务的应用，面临更艰难的问题：Harness 最需要的地方，恰恰是最难构建的地方。

## Harness 模板

大多数企业都有几种覆盖 80% 需求的常见服务拓扑——通过 API 暴露数据的业务服务、事件处理服务、数据仪表盘。在许多成熟的工程组织中，这些拓扑已经被编纂为服务模板。这些模板未来可能演变为 Harness 模板：一组引导器和传感器的集合，将编码智能体约束到某种拓扑上，遵循该拓扑的结构、规范和技术栈。团队可能会开始部分根据已有哪些 Harness 来选择技术栈和架构。

![图 4：一组拓扑示例及其 Harness 模板细节](https://martinfowler.com/articles/harness-engineering/harness-templates.png)

*[图 4：一组拓扑示例及其 Harness 模板细节。]*

## Ashby 定律

Ashby 的必要多样性定律（Ashby's Law of Requisite Variety）为这些预定义拓扑提供了另一个有趣的论据。该定律指出，调控器必须至少拥有与其所治理系统一样多的多样性，并且只能调控它拥有模型的部分。基于 LLM 的编码智能体几乎可以产出任何东西，但确定采用一种拓扑就缩窄了这个空间，使全面的 Harness 更加可行。定义拓扑是一种多样性缩减的举措。

当然，我们会面临与服务模板类似的挑战。一旦团队实例化了模板，它们就开始与上游改进脱节。Harness 模板将面临同样的版本管理和贡献问题，由于非确定性的引导器和传感器更难测试，情况可能甚至更糟。

## 人类的角色

作为人类开发者，我们将自己的技能和经验作为一种隐式 Harness 带入每个代码库。我们内化了规范和良好实践，感受过复杂性带来的认知痛苦，也知道自己的名字在提交记录上。我们还携带着组织对齐——对团队目标的认知、哪些技术债务因业务原因而被容忍、以及在这个特定上下文中"好"是什么样的。我们以小步伐和人类的节奏推进，这就为经验的调动和运用留出了思考空间。

编码智能体没有这些：没有社会问责、没有对 300 行函数的审美厌恶、没有"我们这里不这样做"的直觉、也没有组织记忆。它不知道哪个规范是承重的、哪个只是习惯，也不知道技术上正确的方案是否符合团队正在努力达成的目标。

Harness 是一种将人类开发者的隐性经验显式化的尝试，但它只能做到一定程度。构建一套连贯的引导器、传感器和自我纠正环路系统是昂贵的，因此我们必须以明确的目标来确定优先级：好的 Harness 不一定要以完全消除人类输入为目标，而是要将人类的输入引导到最重要的地方。

## 一个起点——以及开放问题

我在这里展开的心智模型描述了实践中已经在发生的技术，并帮助框定我们仍需弄清楚的问题。它的目标是将对话提升到功能层面之上——从 Skills 和 MCP 服务器上升到我们如何战略性地设计一套控制系统，使我们对智能体的产出拥有真正的信心。

以下是当前话语中一些与 Harness 相关的案例：

- OpenAI 的一个团队记录了他们的 Harness 是什么样的：由自定义 linter 和结构测试实施的分层架构，以及周期性的"垃圾回收"来扫描漂移并让智能体建议修复。他们的结论是："我们最困难的挑战现在集中在设计环境、反馈环路和控制系统上。"

- Stripe 关于其 minions 的文章描述了诸如基于启发式运行相关 linter 的预推送钩子，他们强调"反馈左移"对他们有多重要，他们的 "blueprints" 展示了如何将反馈传感器整合到智能体工作流中。

- 变异测试和结构测试是过去未被充分利用的计算性反馈传感器的例子，但现在正在复兴。

- 开发者之间关于在编码智能体中整合 LSP 和代码智能的讨论越来越多，这些是计算性前馈引导器的例子。

- 我从 Thoughtworks 的团队那里听到一些案例，他们用计算性和推理性传感器相结合来应对架构漂移，例如用智能体和自定义 linter 的组合来提升 API 质量，或者用"清洁工军团"来提升代码质量。

仍有许多需要弄清楚的事情，不仅仅是前面提到的行为 Harness。我们如何在 Harness 增长时保持其连贯性，使引导器和传感器保持同步、互不矛盾？当指令和反馈信号指向不同方向时，我们能在多大程度上信任智能体做出合理的权衡？如果传感器从不触发，这是高质量的标志还是检测机制不足？我们需要一种类似于代码覆盖率和变异测试对测试所做的那样，来评估 Harness 覆盖率和质量的方法。前馈和反馈控制目前分散在交付步骤中，有很大的工具化潜力来帮助配置、同步，并将它们作为一个系统来推理。构建这个外层 Harness 正在从一次性配置转变为一种持续的工程实践。

## 致谢

衷心感谢 Doppler 团队引发的深入讨论和实验，这些为本文提供了素材——Kief Morris、Ned Letcher、Chris Ford、Ben O'Mahoney、Matteo Vaccari、Christoph Burgmer、Jörn Dinkla 和 Michael Feathers。感谢 Karrtik Iyer、Swapnil Phulse、Paul Sobocinski 和 Zhenjia Zhou 提供的宝贵反馈。

GenAI（Claude 和 Claude Code）被用于研究和语言润色。

我在二月初写了一份包含 Harness Engineering 初步想法的备忘录。本文取代了那份备忘录，是读者更好的参考资源。

---

*重要修订：*
- *2026 年 4 月 2 日：正式文章发布*
- *2026 年 2 月 17 日：初始备忘录发布*