我要投稿

什么是 Harness？——智能体时代的软件工程新范式

发布日期：2026-03-31 05:42:07 浏览次数： 1523

作者：Agent笔记

微信搜一搜，关注“Agent笔记”

在 AI 智能体（Agent）迅速发展的今天，一个名为 Harness 的工程技术概念正在改变我们构建软件的方式。Anthropic 和 OpenAI 的工程团队分别通过实践揭示了一个共同的洞见：当 AI 成为主要的代码生产者时，人类的角色从"写代码"转变为"设计环境"。

从"写代码"到"造 harness"

传统软件开发中，工程师的核心工作是编写代码。但在智能体优先的世界里，这个等式发生了根本性逆转。

OpenAI 的团队进行了一项激进实验：在五个月内构建了一个拥有约 100 万行代码的产品，其中没有一行代码是人工编写的。三位工程师通过 Codex 智能体完成了 1,500 个 Pull Request，平均每位工程师每天处理 3.5 个 PR。这并非为了炫技——产品已经拥有数百名真实用户，包括每天都在使用的高级内测用户。

Anthropic 的实验同样令人印象深刻：他们使用 Claude 构建了一个完整的 2D 复古游戏制作器和数字音频工作站（DAW），这些应用包含关卡编辑器、精灵编辑器、AI 辅助功能等复杂模块，且能在浏览器中流畅运行。

这些成果背后的秘密，就是 Harness Engineering，也被翻译为驭缰工程。

Harness 究竟是什么？

简单来说，Harness 是一套围绕 AI 智能体设计的工程系统，它包含工具、约束、反馈回路和编排机制，让智能体能够可靠地执行复杂任务。

就像赛车需要安全带（harness）来保护驾驶员一样，AI 智能体也需要一个"harness"来确保它们在长时间、复杂的任务中不偏离轨道。

核心组件

根据 Anthropic 和 OpenAI 的实践，一个有效的 Harness 通常包含以下要素：

1. 多智能体架构

不同于单一的"万能智能体"，Harness 采用分工明确的智能体团队：

规划者（Planner）：将模糊的用户需求转化为详细的产品规格说明
生成者（Generator）：负责实际编写代码、设计界面
评估者（Evaluator）：像严格的 QA 工程师一样测试和评判产出

Anthropic 的设计团队发现，将"生成"与"评判"分离是关键。当让同一个智能体既当运动员又当裁判时，它往往会对自己的作品过度宽容。而独立的评估者可以被调优得更挑剔，从而为生成者提供真正有价值的反馈。

2. 上下文管理

智能体在长任务中容易"迷失方向"。Harness 通过以下方式解决：

上下文重置（Context Reset）：在适当时机清空对话历史，让智能体"重新开始"，避免上下文焦虑
结构化交接（Structured Handoff）：通过文件、artifact 等形式在智能体间传递状态
渐进式披露：不给智能体一本 1000 页的说明书，而是一张地图，让它按需探索

OpenAI 的经验是：给智能体一张地图，而不是一本 1000 页的说明书。情境是稀缺资源，过多的指导反而无效。

3. 严格的架构约束

智能体在具有严格边界和可预测结构的环境中最为高效。因此 Harness 会强制执行：

分层架构：如 Types → Config → Repo → Service → Runtime → UI 的依赖方向
代码规范：通过自定义 linter 强制执行命名约定、文件大小限制等
边界验证：在数据边界处解析数据形状，但不规定具体实现方式

这些约束对人类可能显得"迂腐"，但对智能体来说是加速器——一旦编码，就能立即应用于所有地方。

4. 反馈回路

Harness 建立了多层次的反馈机制：

即时代码审查：智能体可以审查自己的更改，也可以请求其他智能体审查
自动化测试：CI 配置、测试用例由智能体生成和维护
运行时验证：通过 Playwright、Chrome DevTools 协议等工具让智能体能"看到"应用的实际运行效果

OpenAI 甚至让 Codex 能够启动应用的独立实例，复现 bug、录制视频验证修复，然后自动合并 PR。

为什么需要 Harness？

解决智能体的固有局限

上下文焦虑：随着对话窗口填满，模型倾向于过早结束工作
自我评估偏差：智能体倾向于自信地赞扬自己的作品，即使质量平庸
能力边界：复杂任务超出单次调用的可靠处理范围

放大人类的价值

Harness 让工程师的工作重点转向：

系统设计：定义架构、约束和抽象层
意图明确：将用户需求转化为清晰的验收标准
工具构建：为智能体创造更好的"工作环境"

正如 OpenAI 总结的：人类掌舵，智能体执行。

Harness 的实际效果

Anthropic 的对比实验

模式	时长	成本	结果
单智能体	20 分钟	$9	核心功能损坏，布局浪费空间
Harness	6 小时	$200	功能完整的游戏制作器，包含 AI 辅助功能、导出分享等高级特性

虽然 Harness 模式成本高出 20 倍，但产出的质量差距"立竿见影"。

OpenAI 的规模效应

3 位工程师 + Codex = 1500 个 PR，100 万行代码
随着团队扩大到 7 人，吞吐量不降反增
单次 Codex 运行可持续工作超过 6 小时（通常发生在人类睡眠时间）

Harness 设计的核心原则

1. 最小可行复杂性

Anthropic 强调：找到最简单的解决方案，只在必要时增加复杂性。随着模型能力提升（如从 Claude Sonnet 4.5 升级到 Opus 4.6），原本必需的组件（如 sprint 分解）可以被移除。

2. 可执行的文档

文档不应是静态的百科全书，而应是可以被验证、被智能体直接使用的"活文档"。OpenAI 将 AGENTS.md 视为内容目录，指向结构化的知识库。

3. 持续清理

OpenAI 团队建立了"黄金原则"和定期清理流程，通过后台 Codex 任务扫描偏差、发起重构 PR，类似于垃圾回收机制。技术债务要像高息贷款一样持续小额偿还，而不是累积成大问题。

4. 模型适配

Harness 不是一成不变的。当新模型发布时，需要重新审查：移除不再必要的组件，添加新的能力扩展。Harness 的设计空间不会随着模型改进而缩小，而是转移。

面向未来的工程范式

Harness 工程代表了一种范式转移：

传统软件工程	Harness 工程
人类编写代码	智能体编写代码
代码审查保证质量	多智能体反馈回路保证质量
文档供人阅读	文档供智能体执行
约束被视为束缚	约束成为加速器
工程师 = 编码者	工程师 = 系统设计师