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

在 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？

解决智能体的固有局限

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

放大人类的价值

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

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

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

Harness 的实际效果

Anthropic 的对比实验

虽然 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 是智能体时代的软件工程基础设施。它不是简单的"提示词工程"或"工具调用"，而是一个完整的系统设计，涉及多智能体编排、上下文管理、架构约束和反馈回路。

正如 Anthropic 所言：随着模型能力提升，有趣的 Harness 组合空间不会缩小，而是会转移。AI 工程师的有趣工作，就是不断发现下一个新颖的组合方式。

在这个新范式中，构建软件仍然需要纪律——但纪律更多地体现在支撑结构上，而不是代码本身。保持代码库一致性的工具、抽象和反馈回路，变得比以往任何时候都更加重要。