---
title: "Harness Engineering 从理论到实战：行为正确性死结 + 上下文腐烂 + 可驾驭性 + Ashby 定律"
source_url: https://mp.weixin.qq.com/s/g7pxETjCn3xVcYwI2NFyog
ingested: 2026-06-02
sha256: feb8bde6859c1efad21fa67dfcce76b421075043b79ce369805fd3250a92508c
author: "张海云Helen"
feed: "AI原生探索者"
published: 2026-06-02
tags: [harness-engineering, beckeler, context-rot, harnessability, ashby-law, behavioral-correctness, two-phase-architecture, long-running-agent, karpathy, agentic-engineering, software-3-0]
---

# Harness Engineering 从理论到实战：行为正确性死结 + 上下文腐烂 + 可驾驭性 + Ashby 定律

> 来源：AI原生探索者 / 2026-06-02 / 张海云Helen
> 系列第 4 篇（前 3 篇：Harness Engineering AI 工程化时代已到来 / Martin Fowler 长文 / Thoughtworks 技术雷达 Vol 34）
> 上一篇：DeepSeek 亲自下场对标 Claude Code Harness

## 1. Karpathy + Böckeler：理论与新角色

**Karpathy 在 Sequoia AI Ascent** 上的核心判断：**vibe coding 已过时，agentic engineering 才是 Software 3.0 时代的专业范式**。

**六行工作模式**：
1. 定义上下文
2. 定义工具
3. 定义反馈循环
4. 定义护栏
5. 让 Agent 工作
6. 保持人类理解

**新角色定义清楚后紧接着的问题**：你拿什么来"定义反馈循环"？拿什么来"定义护栏"？

> **答案就是 Harness Engineering**。如果说 Karpathy 定义了新角色，那 **Böckeler 的 Harness 框架定义的是这个新角色的核心技能**。

## 2. 30 秒回顾：Böckeler 理论框架

**Birgitta Böckeler**（Thoughtworks 全球 AI 辅助软件交付负责人，Harness Engineering 最重要的体系化推动者）4-5 月构建了**目前最完整的 Harness 理论框架**：
- Martin Fowler 站上长文（2026-04-02）
- YouTube 56 分钟实操视频（2026-04-24）
- 5 月传感器实验（公开完整数据）

### 核心三句话

**第一句：两根缰绳**。
- **引导（Guides）**——事前给 Agent 方向
- **传感器（Sensors）**——事后检测并纠偏

两者必须配合——只有引导没有传感器，规则 Agent 可以忽略；只有传感器没有引导，Agent 反复犯同一个错。

**第二句：两种执行方式**。
- **计算性控制**（linter、类型检查、结构测试）——CPU、确定性、毫秒级、几乎免费
- **推理性控制**（AI 代码审查、LLM 语义分析）——GPU、概率性、更慢更贵

**Böckeler 5 月实验结论**：**计算性传感器可靠地抓住了绝大多数结构性问题，推理性传感器反而不稳定**。那些存在了几十年的老工具，在 AI 时代成了最可靠的缰绳。

**第三句：三层调节目标，难度递增**：

| 层级 | 目标 | 状态 |
|------|------|------|
| 🟢 | **可维护性**（代码结构、复杂度、重复） | 计算性传感器能可靠搞定，**最成熟** |
| 🟡 | **架构适应性**（性能、安全、可观测性） | 部分可行，**靠适应度函数** |
| 🔴 | **行为正确性**（功能到底对不对） | **最大缺口，几乎无法自动化** |

> **前两篇文章和技术雷达，把前两层讲得很充分了。但第三层——行为正确性——只是被点了一句"还不够好"就带过了。这恰恰是最深、最难、最容易让团队栽跟头的地方。**

## 3. 真实场景：Agent 工作三小时后发生了什么

假设你的团队有一个跑了五年的后端系统——十几万行代码，多个微服务，文档不完整。现在给编码 Agent 一个任务：**给订单模块新增一个退款流程**。

### 时间线

**▸ 前 30 分钟** — 一切看起来很完美。Agent 理解了需求，读了现有代码，生成了新的退款服务。代码风格一致，linter 全过，测试全绿。

**▸ 第 60 分钟** — **微妙的问题开始出现**。退款逻辑需要调用支付网关，Agent 写了一个新的网关客户端。**但系统里其实已经有一个了——埋在另一个微服务里，命名风格完全不同**。Agent 没找到它，自己造了一个轮子。**linter 不会报错**。

**▸ 第 90 分钟** — **Agent 开始"忘事"**。上下文窗口快满了。Agent 在第 20 分钟决定用整数（"分"）存储金额，到第 90 分钟开始用浮点数。**测试也过了——因为测试也是 Agent 写的，它按当前代码的逻辑写测试，自然通过**。

**▸ 第 150 分钟** — Agent **自信宣布"任务完成"**。测试覆盖率 94%，linter 零警告。但工程师审查后发现：
- 一个**重复造的网关客户端**
- **浮点精度隐患**
- 两处 **API 设计不一致**
- 三个**"对的测试验证错的逻辑"**的用例

> **🔴 这就是 Böckeler 框架里那个红色的行为正确性——Harness 最大的缺口**

## 4. 为什么行为正确性几乎无法 Harness

> **不是"工具还不够好"的问题——它是一个结构性的死结**。

### 自我指涉的验证回路

当你让 Agent 同时生成代码和测试时，**生成者（Agent）和验证者（Agent 写的测试）共享同一个"对世界的理解"**。

如果 Agent 对需求的理解本身就偏了，那它写的测试会**"忠实地"验证那个偏了的理解**——**测试全绿，功能全错**。

> **这就像让一个翻译自己校对自己的译文——他不会发现错误，因为错误来自他对原文的误解，而这个误解在翻译和校对中是一致的。**

Böckeler 文章原话："**这还不够好**。" 但她也承认，**目前没有完美的解**。

### 头部公司不完美但有效的做法

**Anthropic 的"独立评估官"**：
- 用**完全独立的 Agent**——在**全新的上下文**中、**没有任何写入权限**——来评审代码
- 关键细节：**"默认失败契约"**——每条验收标准默认为"未通过"，评估 Agent 必须拿出证据才能标记为通过
- 这**打破了自我指涉**——评估者和生成者不共享上下文，降低了"同一个误解被复制两次"的概率
- **注意，是降低，不是消除**

**Böckeler 的变异测试（Mutation Testing）**：
- 故意在代码中植入微小的改动（"变异体"），然后看测试能不能抓住这些改动
- **如果你的测试套件连一个故意引入的错误都检测不到，那它对真正的 bug 也一定检测不到**
- 是目前**最接近"客观验证测试质量"**的方法，但成本也最高

**OpenAI 的"人类不可省"**：
- 百万行代码实验中的做法**最简单也最诚实**
- linter 做硬门控（不通过不能合并），但**功能正确性依然靠人审查**
- **没有试图用 AI 解决 AI 的行为正确性问题**

> **在行为正确性的 Harness 成熟之前，人类审查不能省。当团队汇报"AI 代码测试通过率 100%"时，你要追问一句：这些测试是谁写的？** ^[raw/articles/3eDUjMNeM5AK4jUsgiFYng.md:1-50]

## 5. 上下文腐烂：长任务的隐形杀手

> **Agent 在第 90 分钟开始"忘事"——这不是偶发的 bug，是一个结构性问题，叫上下文腐烂（Context Rot）**。

**模型在对话开始时很强**——推理清晰、遵循指令、风格一致。但**随着上下文窗口被填满，性能开始退化**：
- 忘记早先的设计决策
- 重复自己说过的话
- 违反一开始遵守得很好的规则

> **这种退化是渐进的、静默的。不像语法错误那样立刻报红，它是一点一点偏移的——每一步看起来都合理，但累积起来就偏离了最初的设计。你的传感器抓不住它，因为每个局部都是对的，只有全局是错的。**

### Anthropic 长时运行 Agent 两段式架构

**最值得借鉴的做法**。参考实现：Anthropic cwc-long-running-agents 开源项目。

**初始化 Agent**（只运行一次）：
- 建立环境、阅读需求
- 生成一份**结构化的功能列表和进度追踪文件**（类似 claude-progress.txt）
- 然后它退出

**编码 Agent**（被反复唤醒）：
- 每次会话**只聚焦一个功能**
- 从进度文件读取当前状态
- 完成这个功能、运行测试、提交代码
- **更新进度文件**
- 然后退出
- **下一次会话从干净的上下文开始**

> **这个设计非常精妙。它的本质是：用文件系统来替代上下文窗口做记忆。**

**进度文件、git 提交记录、测试结果——这些东西不会"腐烂"，不会随着对话变长而被遗忘。每次新会话从这些硬状态重新加载，Agent 永远在一个"新鲜"的上下文里工作。**

> **"这就是你一直该写但没写的交接文档、sprint 日志、技术债务记录。以前没人逼你严谨地做这件事。现在 AI 逼你了。"**

> **Agent 没有跨会话记忆。如果你不设计显式的状态交接机制，它每次醒来都是失忆的。这不是 bug，是大语言模型的物理属性。Harness 必须为这个属性做工程设计。** ^[raw/articles/3eDUjMNeM5AK4jUsgiFYng.md:1-50]

## 6. 可驾驭性：一个被忽略的架构判决

**Böckeler 在框架中提出了一个概念叫可驾驭性（Harnessability）——不是每个代码库都能被有效 Harness**。

### ✅ 高可驾驭性

- **强类型语言**（TypeScript、Rust、Go）——**天然自带一层传感器（类型系统）**
- **清晰的模块边界**——天然支持架构约束
- **成熟框架**（Spring、Rails）——抽象掉底层细节，**缩小 Agent 犯错空间**

### ❌ 低可驾驭性

- **大单体应用**——依赖像意大利面，约束规则无从下手
- **自研框架**——Agent 没有社区知识可依赖
- **无 type hints 的 Python**——失去一整层自动验证能力

> **矛盾就在这里：技术债累积最严重的遗留系统——最需要 AI 帮忙的地方——恰恰是最难建 Harness 的地方。Harness 最被需要的地方，可驾驭性最低。**

> **你三年前的技术选型决策，正在决定你今天能在多大程度上利用 AI 编码。**

> **选了 TypeScript 还是 JavaScript、选了微服务还是大单体、有没有坚持写测试和维护模块边界——这些当时看起来"无所谓"的决策，现在变成了你能不能给 Agent 套上缰绳的前提条件。**

> **下次技术架构评审时，"这个技术栈对 AI Agent 的可驾驭性如何"应该成为一个标准问题。** ^[raw/articles/3eDUjMNeM5AK4jUsgiFYng.md:1-50]

## 7. Ashby 定律：为什么模型越强，需要的纪律反而越多

> **Böckeler 在框架中引用了控制论的 Ashby 必要多样性定律（Law of Requisite Variety）**：

> **一个控制系统的复杂度，必须匹配它所控制对象的复杂度。如果控制系统比被控对象简单，它就控制不住。**

翻译到 Harness Engineering 里就是一句**反直觉**的话：

> **Agent 越强大、越自主，你的 Harness 就必须越复杂。模型越强，需要的工程纪律不是越少，而是越多。**

**为什么**？
- 更强的模型意味着**更大的行动空间**
- 一个只能写 10 行代码的工具，出错的方式有限
- 一个能连续工作三小时、跨多个文件重构整个模块的 Agent，**出错的方式是指数级的**
- 它的"多样性"——它能做的事情的范围——远超简单工具
- 你的 Harness 的"多样性"——你能检测和纠正的问题的范围——**必须跟上**

> **这解释了一个很多团队困惑的现象：为什么从 GPT-3.5 升级到 GPT-4 再到 Claude Opus，代码质量确实提高了，但出的问题也更诡异了？**

> **因为弱模型犯的是语法级别的蠢错，linter 就能抓住；强模型犯的是语义级别的巧错——逻辑自洽但方向偏了，代码优雅但理解偏了——你所有的传感器都检测不到。**

### Thoughtworks 技术雷达的精准表述

> **"没有纪律的速度只会把成本复利化——当智能体系统让快速行动变得前所未有地容易时，这个原则比以往任何时候都值得坚守。"**

> **AI 给了你速度。但速度不等于控制。你开得越快，方向盘和刹车就越重要——不是越不重要。** ^[raw/articles/3eDUjMNeM5AK4jUsgiFYng.md:1-50]

## 8. 结语：Harness Engineering 的真正边界

把前三篇加上这一篇放在一起看，一条线索浮现了。

- **第一篇**讲的是"每当 Agent 犯一个错，就建一个机制让它永不再犯"——**很直觉，很朴素**
- **但实践告诉我们**，事情没有那么简单：
  - 有些错**你的传感器根本检测不到**（行为正确性死结）
  - 有些错**不是一瞬间犯的，而是在三小时的渐进退化中慢慢偏移出来的**（上下文腐烂）
  - 有些代码库**从根子上就不适合被 Harness**（可驾驭性问题）
  - 模型越强，问题不是越少而是**越诡异**（Ashby 定律）

> **Harness Engineering 不是一个加法题——不是你加的控制越多就越安全。它是一门关于"控制的边界在哪里"的工程学科。知道什么能控制，和知道什么不能控制，同样重要。**

### 对管理者的三件事

1. **计算性传感器先行**。linter、类型检查、结构测试——便宜、可靠、每次提交都跑。这是**回报最高的第一步投资**。

2. **行为正确性的人类审查不能省**。不管 Harness 多完善，在 AI 自验证死结被真正解开之前，**功能层面的人工审查是最后一道防线**。**测试全绿不等于功能正确**。

3. **长任务必须分段**。不要让 Agent 在一个越来越长的对话里连续工作几个小时。**强制分段，用文件系统做状态交接，每次新会话从干净上下文开始**。

### 回到 Karpathy

> **"你可以外包你的思考，但你不能外包你的理解。"**

> **Harness Engineering 就是这句话在工程层面的具体实现。你把编码外包给了 Agent，但你不能外包对代码质量的判断、对系统边界的理解、对"什么时候 Agent 已经跑偏了"的感知。**

> **"更强大、更昂贵、更危险"** — Böckeler · QCon London 演讲标题

> **更强大，是事实。更昂贵，是现实。更危险——这才是 Harness Engineering 存在的理由。** ^[raw/articles/3eDUjMNeM5AK4jUsgiFYng.md:1-50]

## 9. 信息来源

1. Birgitta Böckeler "Harness engineering for coding agent users"（martinfowler.com, 2026-04-02）
2. Böckeler "Maintainability sensors for coding agents"（2026-05-20/27）
3. Thoughtworks YouTube "Harness engineering beyond skills"（2026-04-24）
4. Thoughtworks Technology Podcast "What is harness engineering?"（2026-05-14）
5. Böckeler QCon London 主旨演讲
6. Thoughtworks 技术雷达 Vol 34
7. OpenAI "Harness engineering"（2026-02-11）
8. Anthropic cwc-long-running-agents 开源参考实现

---

- 原文：AI原生探索者 / 张海云Helen / 2026-06-02
- 系列：Harness Engineering 深度拆解（第 4 篇）
- 上一篇：DeepSeek 亲自下场对标 Claude Code Harness