---
title: Harness 工程
tags: [核心概念, Harness, 架构]
source: [OpenAI, Anthropic, Martin Fowler, LangChain, NxCode]
confidence_score: 高
last_updated: 2026-04-07
---

# Harness 工程

**Harness 工程**（Harness Engineering）是设计和实现使 AI 智能体可靠工作的系统的新学科。如果说 2025 年是 AI 智能体验证它们能够编写代码的一年，那么 2026 年就是我们认识到**智能体不是难点——Harness 才是**的一年。

## 核心定义

### 什么是 Harness？

术语 "Harness" 来源于马具——缰绳、马鞍、马嚼子——用于引导强大但不可预测的动物朝正确方向前进的全套设备。这个比喻是有意为之的：

- **马**是 AI 模型——强大、快速，但自己不知道要去哪里
- **Harness**是基础设施——约束、护栏、反馈循环，用于高效地引导模型的能力
- **骑手**是人类工程师——提供方向，而不是亲自奔跑

没有 Harness，AI 智能体就像开放田野里的纯种马。快速、令人印象深刻，但对于完成任何事情来说完全无用。

### Harness 工程的正式定义

**Harness 工程**是设计和实现以下系统的学科：

1. **约束** AI 智能体可以做什么（架构边界、依赖规则）
2. **告知** 智能体应该做什么（上下文工程、文档）
3. **验证** 智能体正确执行了（测试、linting、CI 验证）
4. **纠正** 智能体出错时（反馈循环、自我修复机制）

Martin Fowler 将其描述为"我们可以用来控制 AI 智能体的工具和实践"——但它不仅仅是安全。一个好的 Harness 使智能体**更有能力**，而不仅仅是更受控制。

## 为什么 Harness 工程现在如此重要

### 模型是商品，Harness 是护城河

AI 行业正面临一个令人不安的事实：**底层模型的重要性不如围绕它的系统。**

LangChain 明确证明了这一点。他们的编码智能体在 Terminal Bench 2.0 上从 **52.8% 提升到 66.5%**——从 **Top 30 跃升至 Top 5**——对模型没有做任何改变。他们只改变了 Harness：

| 改变 | 他们做了什么 | 影响 |
|------|-------------|------|
| 自我验证循环 | 添加完成前检查清单中间件 | 在提交前捕获错误 |
| 上下文工程 | 启动时映射目录结构 | 智能体从一开始就理解代码库 |
| 循环检测 | 跟踪重复的文件编辑 | 防止"末日循环" |
| 推理三明治 | 规划/验证使用高推理，实现使用中等推理 | 在时间预算内获得更好的质量 |

**相同的模型。不同的 Harness。显著更好的结果。**

### OpenAI 的 100 万行代码证明点

OpenAI 的实验是迄今为止最令人信服的证据：

- **5 个月**的开发
- 最终产品中有 **100 万+ 行代码**
- **零行手动编写的代码**——每一行都是由 Codex 智能体生成的
- **用人类所需时间的约 1/10 构建**
- 产品有**内部日常用户和外部 Alpha 测试者**
- 它**交付、部署、出故障并得到修复**——全部由 Harness 内的智能体完成

工程师的工作？设计 Harness。指定意图。提供反馈。不是编写代码。

## 三大支柱

OpenAI 的框架将 Harness 工程组织为三个核心类别：

### 1. 上下文工程

上下文工程是关于确保智能体在正确的时间获得正确的信息。

**静态上下文：**
- 仓库本地文档（架构规范、API 契约、风格指南）
- 编码项目特定规则的 `AGENTS.md` 或 `CLAUDE.md` 文件
- 由 linter 验证的交叉链接设计文档

**动态上下文：**
- 智能体可访问的可观测性数据（日志、指标、追踪）
- 智能体启动时的目录结构映射
- CI/CD 流水线状态和测试结果

**关键规则：** 从智能体的角度来看，它无法在上下文中访问的任何内容都不存在。Google Docs、Slack 线程或人们头脑中的知识对系统是不可见的。**仓库必须是单一事实来源。**

### 2. 架构约束

这是 Harness 工程与传统 AI 提示最显著不同的地方。与其告诉智能体"编写好代码"，不如**机械地强制执行好代码的样子**。

**依赖分层：**
```
Types → Config → Repo → Service → Runtime → UI
```

每层只能从其左侧的层导入。这不是建议——它由结构测试和 CI 验证强制执行。

**约束强制执行工具：**
- **确定性 linters**——自动标记违规的自定义规则
- **基于 LLM 的审计员**——审查其他智能体代码的架构合规性
- **结构测试**——像 ArchUnit，但用于 AI 生成的代码
- **预提交钩子**——在提交任何代码前的自动检查

**为什么约束能改善输出：** 矛盾的是，约束解决方案空间使智能体**更有生产力**，而不是更少。当智能体可以生成任何东西时，它会浪费 token 探索死胡同。当 Harness 定义清晰的边界时，智能体会更快地收敛到正确的解决方案。

### 3. 熵管理（"垃圾回收"）

这是最被低估的组件。随着时间的推移，AI 生成的代码库会积累熵——文档与现实脱节、命名约定分歧、死代码堆积。

Harness 工程通过**定期清理智能体**来解决这个问题：
- **文档一致性智能体**——验证文档与当前代码匹配
- **约束违规扫描器**——找到逃过早期检查的代码
- **模式强制执行智能体**——识别并修复与既定模式的偏差
- **依赖审计员**——跟踪并解决循环或不必要的依赖

这些智能体按计划运行——每日、每周，或由特定事件触发——保持代码库对人类审查者和未来 AI 智能体都健康。

## 相关概念

- [[Context-Engineering|上下文工程]]
- [[Architectural-Constraints|架构约束]]
- [[Entropy Management|熵管理]]
- [[OpenAI Harness Engineering|OpenAI Harness 工程]]
- [[Anthropic-Harness-Design|Anthropic Harness 设计]]
- [[LangChain Harness Engineering|LangChain Harness 工程]]

## 参考来源

1. OpenAI - Harness Engineering：在智能体优先的世界中利用 Codex
2. Anthropic - Harness design for long-running application development
3. Martin Fowler - Harness engineering for coding agent users
4. LangChain - Improving Deep Agents with harness engineering
5. NxCode - Harness Engineering: The Complete Guide

---

*最后更新：2026-04-07*  
*本文档由 [[WikiLLM]] 编译自多个来源*