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

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

📊 Level ⭐⭐⭐ | 20.1KB | entities/harness-engineering-theory-to-practice-helen.md

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

概述¶

张海云Helen（AI原生探索者）2026-06-02 Harness Engineering 系列第 4 篇。前 3 篇讲理论框架，本文专攻实战区——理论没覆盖的更深层工程难题：行为正确性自我指涉死结（Anthropic 独立评估官/变异测试/OpenAI 人类不可省）、上下文腐烂与 Anthropic 两段式架构、可驾驭性 4 个架构判决、Ashby 必要多样性定律（模型越强需要纪律越多）。Böckeler 5 月传感器实验首次公开数据 + Karpathy Sequoia AI Ascent 六行工作模式首次系统化对接 Harness。核心判断：Harness Engineering 是一门关于"控制的边界在哪里"的工程学科——知道什么不能控制和知道什么能控制同样重要。

核心命题¶

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

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

新角色定义清楚后紧接着的问题：你拿什么来"定义反馈循环"？拿什么来"定义护栏"？答案就是 Harness Engineering。

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

Böckeler 理论框架 30 秒回顾¶

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

三句话核心¶

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

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

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

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

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

行为正确性：Harness 最大的缺口¶

真实场景（Agent 工作 3 小时）¶

假设给 Agent 一个任务：给订单模块新增退款流程。

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

自我指涉的验证回路（结构性死结）¶

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

当 Agent 同时生成代码和测试时，生成者和验证者共享同一个"对世界的理解"。如果 Agent 对需求的理解本身就偏了，那它写的测试会"忠实地"验证那个偏了的理解——测试全绿，功能全错。

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

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

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

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

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

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

在行为正确性 Harness 成熟之前，人类审查不能省。当团队汇报"AI 代码测试通过率 100%"时，你要追问一句：这些测试是谁写的？

上下文腐烂：长任务的隐形杀手¶

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

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

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

Anthropic 两段式架构（cwc-long-running-agents）¶

最值得借鉴的做法。

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

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

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

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

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

Agent 没有跨会话记忆。如果你不设计显式的状态交接机制，它每次醒来都是失忆的。这不是 bug，是大语言模型的物理属性。Harness 必须为这个属性做工程设计。

可驾驭性：被忽略的架构判决¶

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

✅ 高可驾驭性¶

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

❌ 低可驾驭性¶

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

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

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

下次技术架构评审时，"这个技术栈对 AI Agent 的可驾驭性如何"应该成为一个标准问题。

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 给了你速度。但速度不等于控制。你开得越快，方向盘和刹车就越重要——不是越不重要。

结语：Harness Engineering 的真正边界¶

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

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

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

对管理者的三件事¶

1. 计算性传感器先行——linter、类型检查、结构测试，便宜、可靠、每次提交都跑。回报最高的第一步投资
2. 行为正确性的人类审查不能省——功能层面的人工审查是最后一道防线。测试全绿不等于功能正确
3. 长任务必须分段——强制分段，用文件系统做状态交接，每次新会话从干净上下文开始

回到 Karpathy¶

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

Harness Engineering 就是这句话在工程层面的具体实现。

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

更强大，是事实。更昂贵，是现实。更危险——这才是 Harness Engineering 存在的理由。

7 个一手信息来源¶

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 开源参考实现

与现有 harness-engineering 实体的差异化¶

关键判断：本文独有内容不应合并到现有 entity——行为正确性死结 + 上下文腐烂专题 + 可驾驭性专题 + Ashby 定律专题全部是本文独有角度。

深度分析¶

1. Harness Engineering：从理论到实践的桥梁¶

Helen 的这篇系统梳理将 harness engineering 从零散实践提升为理论框架——定义了 harness 的核心组件（工具注册、权限控制、上下文管理、错误处理）和实践模式。

2. Harness 作为"AI 的操作系统"¶

harness 不是简单的"工具包装器"，而是 AI agent 的"操作系统"——管理资源（工具、上下文、权限）、调度执行、处理错误、记录审计。与 Agentic Ai System Architecture Harness Skill Mcp 的五层架构对齐。

3. 理论框架的实践验证¶

理论框架需要实践验证——harness engineering 的每个概念都应有对应的实现案例。Helen 的梳理提供了从"12 组件"到"7 决策"的实践路径。

实践启示¶

1. 用理论框架评估现有 harness 实现¶

对照 harness engineering 的组件清单评估你的 agent 系统——哪些组件缺失？哪些实现不完整？

2. 从核心组件开始，渐进式完善¶

先实现工具注册和权限控制（核心），再添加上下文管理和错误处理（增强），最后做审计和可观测性（运营）。

3. 每个组件都有测试¶

harness 是 AI 的"操作系统"——每个组件都应有单元测试和集成测试，确保可靠性。

相关实体¶

• Harness Engineering
• Fudan Peking Ahe Agentic Harness Engineering
• Fudan Agentic Harness Engineering Ahe Gpt54 7Points
• Harness Engineering Alibaba Java Case Study
• Tencent Cdn Lego Harness

→ 原文存档