138 lines
6.3 KiB
Markdown
138 lines
6.3 KiB
Markdown
---
|
||
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]] 编译自多个来源*
|