从Vibe Coding到Harness：大型代码仓库中的AI工程化实践
当AI模型的推理能力越来越强，一个核心问题浮出水面：模型足够强了，但工程没跟上。在真实业务场景中，让AI独立完成一个完整的产品需求——从PRD到代码落地、接口测试通过、代码审查通过、最后提交MR——你会发现整条链路上有太多事情不是“写代码”本身，而是协作、流程、信任与收口。这些都不是模型问题，而是工程问题。
为什么需要Harness
四Agent架构设计
Harness的本质不是让AI看起来更聪明，而是让AI在复杂工程里更可控、更可靠、更可维护。我们构建的Harness由六个核心层次组成：Rule（规则）、Skill（标准操作手册）、Sub Agent（专职角色）、Workflow（流程定义）、Scripts（门禁脚本）、MCP（外部系统接口）。其中最关键的认知是：能写成脚本的约束就别留在Rule里，能下沉成Skill的规范就别让Agent记住。
AI的瓶颈早就不是模型，是协作、流程、信任。Harness Engineering不是为了让AI看起来更聪明，是为了让AI在复杂工程里更可控、更可靠、更可维护。
“工程实践总结”积墨 AI 智能体开发平台
快速搭建具备商业价值的 AI 智能体，支持复杂工作流编排、50+ 主流模型接入与私有化部署。
13阶段工作流
我们的实践最终只保留了4个核心Agent：需求Agent负责把TAPD链接转化为结构化的需求理解文档和代码影响地图；方案Agent负责输出可执行的技术方案；开发Agent负责按设计落地代码并产出接口测试；代码审查Agent负责从方案一致性、验收标准覆盖、质量基线三个维度进行收口。
13个阶段的划分不是过度设计，而是每个阶段的存在都对应着一类历史教训。我们发现，集成测试前置到代码审查之前这一调整，让代码审查的平均打回次数从1.8次降到0.4次。原因很简单：让产生问题的人同时产生验证手段，而不是把验证成本推到最贵的环节。
如有侵权，请联系删除。