jzy/my_wiki

Fork 0

Files

T

Junjian Wang 1c45805457 init commit

2026-04-07 21:01:17 +08:00

6.3 KiB

Raw Blame History

title, tags, source, confidence_score, last_updated

title

Harness 工程

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

核心定义

什么是 Harness？

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

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

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

Harness 工程的正式定义

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

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

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 智能体都健康。

参考来源

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

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

6.3 KiB Raw Blame History Unescape Escape