聊聊驾驭工程Harness Engineering

文章主旨：在AI深度改造研发流程的背景下，harness engineering（驾驭工程）成为将大模型不确定产出转化为确定性价值的核心工程框架，它是未来大规模AI应用的关键。

关键要点：

1. AI工程实践已演进为三个阶段：prompt engineering、context engineering、harness engineering，后者包含前两者成果。
2. harness engineering的核心目标是让AI能持续稳定地完成复杂任务，通过过程管控和纠偏实现从“回答问题”到“好好工作”的进化。
3. harness engineering的组成结构包括：上下文系统、工具调用系统、流程编排、监测与评估、控制五个层次。
4. harness engineering与DevOps有本质区别：前者处理概率系统、会随模型进化而快速演变、以“AI自修复”导向、需以AI自动化测试替代人工代码评审。
5. 当前harness engineering尚未成为科学，存在案例宣传倾向、概念模糊等问题，但它本质仍是工程，需要深厚技术功底和架构能力。

内容结构：

1. AI工程化的三个阶段

• prompt engineering：解决沟通问题，通过语言概率驾驭模型，但复杂场景受限。
• context engineering：在合适时机喂给大模型所需信息（历史经验、系统规则等），延伸至agent长链路任务，RAG为核心实践。
• harness engineering：当信息充足但模型仍不能稳定工作时，需要一整套工程框架进行过程管控和纠偏，让AI“好好工作”。

2. harness的组成结构

• 第一层：上下文系统，包括短期指南、长期记忆、企业知识库等，并连接业务系统API。
• 第二层：工具调用系统，在合适时机调用合适工具，设有审计与权限。
• 第三层：流程编排，拆解复杂任务、处理异常分支，Skills为复用实例。
• 第四层：监测与评估，记录状态、日志，可回溯复现，自动化测试通过才视为完成。
• 第五层：控制，包括人工接管、恢复、权限、成本、安全边界，含Guardrail机制。

3. Agent运行态（OpenAI）

• Agent运行是DO WHILE循环：初始化→加载上下文→循环中若返回纯文本则退出，否则执行工具调用、agent调用或人工介入等操作并继续。
• 监测记录持久化，支持恢复上下文；设置最大尝试次数避免过度循环；输出标准化处理；多agents并行时需拆分并定义分工边界。

4. harness engineering和DevOps的不同

• 传统工程生成确定系统，AI工程生成概率系统，需大量细节创新试验。
• 传统工程趋于稳定，AI工程随模型进化需瘦身和拆解重构。
• 问题修复导向不同：传统找具体BUG，harness看“为何AI不能自己解决”。
• 传统门禁（如代码评审）不适用，需以AI自动化测试应对。

5. harness engineering还不是科学

• 领先案例有宣传目的，缺乏现实企业多样性；概念易被滥填。
• 作者倾向于定义为“让AI在业务研发中发挥最大效能的工程总和”，需具备透明可控、可恢复、可解释、可整合特征。

6. 结语：坚持工程底色

• 与“人人AI编程”“一人公司”等观念不同，harness面向工程高手，需要继承传统工程功底，成为企业核心资产。
• 开发与测试工程师拥抱编程基本功不会错，企业仍需要懂技术架构的实践派掌控核心资产。

文章总结：本文系统阐述了harness engineering的演进逻辑、分层结构、运营机制及与传统DevOps的本质差异，强调其为让AI产生确定价值的工程总和方法，核心资产仍属于懂工程实践的专家。

废掉一个人最隐蔽的方式：假学习

了解更多

敏捷测试转型

查看原文：聊聊驾驭工程Harness Engineering

文章来源：

敏捷测试转型

扫码关注公众号