Harness Engineering 实战：从单Agent到可验证AI工程系统的完整演进指南

在 AI 代码生成能力日益强大的今天，一个根本性问题始终困扰着工程团队：如何确保 AI 生成的代码真正"可用"而非"看起来能用"？本文将分享一种系统性的 AI 工程架构方法论——Harness Engineering，它通过六层叠加架构让 AI 从"随意发挥"走向"可预期、可审计、可持续"的工程化交付。

成熟度地图：你的团队现在站在哪一级？

这套方法论包含六个核心层次：SPEC 定义目标边界、Rule 设置工程底线、Skill 固化操作流程、Sub-Agent 拆分角色职责、Workflow 编排协作规则、Script 提供客观验证。六个层次并非相互替代，而是逐层叠加——就像建造高楼，地基之上还有结构、结构之上还有机电，每一层都有其不可替代的功能。

SPEC：真正的第一步不是写 Rule

在深入技术细节之前，先用成熟度模型定位你的现状。L0 是裸调模式——单次 Prompt，无约束，无复用；L1 引入基本 Rule，有工程底线但执行不稳定；L2 实现 Rule+Skill+自动化校验，AI 可作为可靠的初级伙伴；L3 通过 Multi-Agent+Workflow 编排处理复杂系统；L4 达到系统自治，可无人干预持续维护。实践中，大多数团队卡在 L1 向 L2 的跃迁阶段——写了 Rule，但 AI 仍会绕过约束。

Rule 与 Skill：约束与流程的分工

很多团队一听到 Harness 就急于写 Rule，但忽略了最关键的前提："到底要做什么？完成标准是什么？"没有清晰的 SPEC，后面的每一条约束都建立在沙滩上。真正的第一步是与 AI 反复迭代打磨一份完整的设计规范——包括核心需求（HARD 标记）、边界条件、非目标范围。这不仅是文档工作，更是一个协作式发现过程：有时连需求方自己一开始也不清楚想要什么，让 AI 扮演反方能有效暴露边界情况。

Multi-Agent：为什么结构化编排是必然选择

Rule 是团队的工程政策，告诉 AI "什么必须做"；Skill 是标准操作流程，告诉 AI "具体怎么做"。以测试为例，如果只说"跑测试"，AI 可能简单执行 pytest；但固化后的 Skill 应包含覆盖率门禁、并发执行、超时控制等完整参数。关键洞察：Rule 强制原则约束，但无法强制流程执行——这就是为什么需要将固定、可重复的流程从 Rule 中抽离，编码成 Skill。一个直观的类比：Skill 就是把 AI 的"自由发挥"变成"逐项打勾"。飞行员起飞前也要逐项检查清单，不靠"我觉得没问题"。

如有侵权，请联系删除。