OpenAI团队最近发布了一篇关于”Harness Engineering”的文章，描述了他们如何通过”完全不手动编写代码”的方式，使用AI代理构建和维护一个超过100万行代码的大型应用。这种新的工程范式正在重新定义我们如何构建和维护软件系统。本文深入探讨Harness Engineering的核心概念、实践方法及其对未来软件开发的影响。
AI 生成内容声明： 本文的内容由生成式 AI 研究、编写和审查。由于大型语言模型可能存在”幻觉”，信息可能包含一些不准确之处。建议读者自行判断技术信息的准确性和相关性。
- 什么是Harness Engineering？
- Harness的三大核心组件
- 从服务模板到Harness模板
- 运行时约束与AI自主性的平衡
- 技术栈的收敛趋势
- 新旧应用的维护策略差异
- 构建你自己的Harness
- 未来展望与挑战
什么是Harness Engineering？
Harness Engineering（缰绳工程）是一种新的软件工程范式，其核心思想是通过构建专门的工具和约束系统（即”缰绳”）来引导和控制AI代理的代码生成和维护行为。OpenAI团队在五个月的时间里，完全依赖AI代理构建并维护了一个超过100万行代码的真实产品，期间没有编写一行手动代码。
这个术语可能受到了Mitchell Hashimoto最近博文的启发，但”harness”（缰绳）这个词很好地描述了我们需要用来约束AI代理的工具和实践。与传统的软件开发不同，Harness Engineering更侧重于构建能够持续指导、监督和校正AI代理的系统，而不是直接编写业务逻辑代码。
Harness的三大核心组件
根据OpenAI团队的经验，一个完整的Harness系统包含三个主要组成部分：
1. 上下文工程（Context Engineering）
- 持续增强的知识库：在代码库中维护一个不断丰富的知识库
- 动态上下文访问：AI代理能够访问观测数据、浏览器导航等动态信息
- 设计作为上下文：代码设计本身成为上下文的重要组成部分
2. 架构约束（Architectural Constraints）
- 确定性监控：除了LLM代理监控外，还包括定制的确定性检查器
- 结构化测试：强制执行架构规则的结构化测试框架
- 边界强制执行：定义并严格执行模块边界和数据结构稳定性
3. “垃圾回收”机制（”Garbage Collection”）
- 周期性代理运行：定期运行的AI代理，专门查找不一致性
- 熵对抗：主动对抗代码库的熵增和衰减
- 文档一致性检查：确保文档与代码实现保持一致
从服务模板到Harness模板
大多数组织只有两三个主要技术栈，而不是每个应用都是独特的”雪花”。文章提出了一个有趣的设想：未来团队可能会从一组针对常见应用拓扑的Harness模板中选择合适的起点。
这让人联想到今天的服务模板，它们帮助团队在”黄金路径”上实例化新服务。Harness——包含自定义检查器、结构化测试、基础上下文知识文档和额外上下文提供者——是否会成为新的服务模板？
潜在的挑战包括：
- 团队如何共享和贡献Harness改进
- 如何避免Harness的分叉和同步问题
- 如何平衡标准化与定制化需求
运行时约束与AI自主性的平衡
很多早期的AI编码炒作假设LLM会给我们提供目标运行时的无限灵活性——用任何语言、任何模式生成代码，无需约束。但对于可维护、可信任的大规模AI生成代码，某些方面必须做出妥协。
OpenAI描述的Harness表明，增加信任和可靠性需要约束解决方案空间：
- 特定的架构模式
- 强制执行的边界
- 标准化的结构
这意味着为了提示、规则和充满技术细节的Harness而放弃一些”生成任何东西”的灵活性。
技术栈的收敛趋势
随着编码越来越像”引导代码生成”而非”键入代码”，AI可能会推动我们使用更少的技术栈。框架和SDK的可用性仍然重要——我们反复看到对人类好的东西对AI也好。但在这个细节层次上，开发者的口味将变得不那么重要。
界面中的小低效和特立独行将不那么烦人，因为我们不直接处理它们。我们可能会选择有良好Harness可用的技术栈，并优先考虑”AI友好性”。
这可能不仅适用于技术栈，也适用于代码库结构和拓扑。我们可能默认采用更容易用AI维护的结构，因为它们更容易被”缰绳”控制。
新旧应用的维护策略差异
假设我们开发了良好的Harness技术，将AI自主性提高到9分，并增加了对结果的信心。哪些技术可以应用于现有应用，哪些只能用于从零开始、考虑到Harness而构建的应用？
对于旧代码库，我们需要考虑改造Harness是否值得付出努力。AI可以帮助我们更快地完成这项工作，但这些应用程序通常如此非标准化且充满熵，可能不值得这样做。这让人想到在从未有过静态代码分析工具的代码库上运行一个，然后被警报淹没。
构建你自己的Harness
OpenAI团队花了五个月时间构建他们的Harness，这表明这不是你可以快速投入并获得快速结果的事情。但值得反思的是，你今天有什么样的”缰绳”？
可以考虑的起点：
- 你有一个预提交钩子吗？里面有什么？
- 你对自定义检查器有什么想法？
- 你想对你的代码库施加什么架构约束？
- 你尝试过像ArchUnit这样的结构化测试框架吗？
逐步构建Harness的方法：
- 从基本的代码质量检查开始
- 添加架构约束和边界检查
- 构建上下文知识库
- 实现周期性的一致性检查
- 迭代优化和扩展
未来展望与挑战
OpenAI团队表示：”我们现在最困难的挑战集中在设计环境、反馈循环和控制系统。”这让人想起Chad Fowler最近关于”重新定位严谨性”的帖子。听到关于严谨性可能去向的具体想法和经验，比仅仅希望”更好的模型”会神奇地解决可维护性问题要令人耳目一新。
关键挑战：
- 功能验证缺失：当前Harness方法主要关注内部质量，缺乏功能和行为的验证
- 技术债务管理：如何有效管理AI生成代码的技术债务
- 团队协作模式：在AI代理主导的开发中，人类开发者如何协作
- 技能转型需求：开发者需要从编码转向”缰绳设计”和”提示工程”
Harness Engineering的未来影响
Harness Engineering可能标志着软件开发的根本转变：
- 从编码到引导：开发者角色从编写代码转变为设计和维护引导系统
- 从个体到系统：重点从个人编码技能转向系统设计和约束工程
- 从灵活到约束：为了可维护性和可预测性而接受一定的约束
实践建议
- 从小处开始：不要试图一次性构建完整的Harness系统
- 关注可观测性：确保你能监控和理解AI代理的行为
- 保持迭代思维：当AI代理遇到困难时，将其视为改进Harness的信号
- 平衡约束与灵活性：找到适合你项目的约束程度
参考链接：
注： 本文基于Martin Fowler对OpenAI Harness Engineering文章的解读和分析，结合软件工程最佳实践进行扩展和深化。
