从Prompt到Harness：AI工程化的范式升级与实践

1. 从Prompt Engineering到Harness Engineering的范式跃迁

去年这个时候，我还在团队内部培训中反复强调Prompt Engineering的重要性，手把手教新人如何构造有效的上下文提示。没想到短短几个月后，整个AI工程领域已经悄然完成了范式升级。Harness Engineering的兴起不是简单的概念替换，而是标志着AI应用开发进入了工业化阶段。

这个转变让我想起2010年前后云计算的发展轨迹。最初大家讨论的是"如何把服务器搬到云上"，后来迅速演变为"如何设计云原生架构"。Prompt Engineering相当于前者，关注单点技巧；Harness Engineering则是后者，构建完整的工程体系。

2. Harness Engineering的核心架构解析

2.1 概念本质与三大支柱

Harness的本意是马具，这个比喻非常精准。好的马具既要让马匹充分发挥速度优势，又要确保行驶方向可控。对应到AI工程中，完整的harness体系包含三个关键组件：

1. 意图传导系统 - 将人类目标转化为机器可执行的指令链
2. 约束执行机制 - 通过架构规范、流程控制等手段限定解决方案空间
3. 质量反馈回路 - 建立客观的评估体系对抗AI的自我认知偏差

2.2 OpenAI的工业化实践

OpenAI团队在五个月内用Codex Agent生成100万行代码的实验，展示了harness工程在规模化生产中的威力。他们的系统设计有几个精妙之处：

上下文动态加载机制

python复制class ContextManager:
    def __init__(self):
        self.architecture_docs = load_architecture()
        self.design_specs = load_specs()
        
    def get_context(self, task_type):
        if task_type == "coding":
            return self._assemble_coding_context()
        elif task_type == "debug":
            return self._assemble_debug_context()
        
    def _assemble_coding_context(self):
        return f"""
        [系统架构]
        {self.architecture_docs}
        
        [设计规范]
        {self.design_specs}
        
        [编码约束]
        1. 严格遵循依赖流向规则
        2. 每100行代码必须包含单元测试
        3. 接口文档与实现必须同步更新
        """

架构约束的自动化验证
他们开发了专门的linter工具，在CI/CD流水线中强制检查：

• 层间依赖关系（Types → Config → Repo → Service...）
• 接口契约一致性
• 测试覆盖率阈值

2.3 Anthropic的多智能体对抗设计

Anthropic工程师提出的GAN式架构解决了AI开发的独特挑战：

评估器Agent的工作流程

1. 启动Playwright加载生成的前端页面
2. 执行自动化遍历脚本
3. 基于预定义的评分矩阵生成报告：

   markdown复制| 维度       | 权重 | 得分 | 评语                     |
   |------------|------|------|--------------------------|
   | 设计质量   | 30%  | 85   | 配色方案不够专业        |
   | 功能性     | 40%  | 92   | 所有交互流程测试通过    |
   | 性能指标   | 20%  | 78   | 首屏加载时间超过2秒     |
   | 可访问性   | 10%  | 60   | 缺少ARIA标签            |
   

4. 将评估结果反馈给生成器Agent进行迭代

3. 开源实现方案深度对比

3.1 Superpowers的强制流程控制

这个项目的核心价值在于将软件工程最佳实践编码到工作流中。其执行引擎包含以下阶段：

1. 需求确认阶段

   • 强制进行5W1H分析（What/Why/Who/Where/When/How）
   • 生成用户旅程地图
   • 输出风险评估矩阵

2. 实现阶段

   • 任务分解为原子操作（每个耗时<5分钟）
   • 采用TDD红-绿-重构循环
   • 每完成3个任务执行一次架构一致性检查

3. 交付阶段

   • 自动化生成变更说明
   • 执行安全扫描（SAST+DAST）
   • 更新知识图谱

3.2 gstack的虚拟团队模式

Garry Tan设计的角色系统实际上构建了一个数字化的敏捷团队。关键角色包括：

3.3 Compound Engineering的知识复利

这个插件最创新的部分是它的知识沉淀机制。每次迭代后执行的Compound阶段会：

1. 提取本次开发中的设计决策
2. 自动生成模式库（Pattern Library）
3. 更新领域特定语言（DSL）词典
4. 优化后续任务的上下文组装策略

其知识图谱采用增量式构建：

mermaid复制graph LR
    A[本次任务] --> B{成功模式?}
    B -->|是| C[加入模式库]
    B -->|否| D[记录反模式]
    C --> E[更新DSL解释器]
    D --> F[创建规避规则]

4. 工程实践中的关键挑战

4.1 上下文管理的艺术

在指导多个AI Agent协作时，上下文管理面临特殊难题：

典型问题场景

• 多个Agent对同一概念的理解偏差
• 长对话中的信息衰减
• 跨任务的知识传递断层

解决方案

1. 建立统一的术语表（Glossary）
2. 实现上下文快照（Snapshot）机制
3. 设计上下文校验和（Checksum）算法

4.2 评估体系的构建

有效的评估需要超越简单的正确性检查，我们开发了多维评分卡：

4.3 调试复杂工作流

当多个Agent协作出现问题时，传统的调试方法失效。我们采用的策略：

1. 分布式追踪：为每个决策点打标

   python复制def agent_decision(point):
       with tracer.start_span(f"decision_{point}") as span:
           span.set_tag("input", context)
           span.log_kv({"options": candidates})
           result = llm.generate(context)
           span.set_tag("output", result)
           return result
   

2. 因果图分析：可视化决策链

3. 反事实测试：修改中间状态观察影响

5. 实施路线图与工具链选择

5.1 渐进式 adoption 路径

对于希望尝试harness工程的团队，建议分阶段推进：

阶段1：基础建设

• 搭建文档知识库（建议用Notion或Wiki.js）
• 制定架构约束规范
• 部署基础监控（Prometheus+Grafana）

阶段2：单点突破

• 选择非关键路径试点（如内部工具开发）
• 配置基础harness（Superpowers基础版）
• 建立人工复核流程

阶段3：规模扩展

• 引入多Agent协作（gstack核心角色）
• 实现自动化质量门禁
• 构建知识复利系统

5.2 工具链配置建议

经过半年实践，我们的技术栈稳定在：

6. 未来演进方向

从当前实践来看，harness工程将向三个方向发展：

1. 领域专用化：针对前端、数据工程等垂直领域优化约束集
2. 自适应调节：根据项目阶段动态调整约束严格度
3. 人机协作界面：开发更直观的intent表达工具

最近在尝试将物理系统的控制理论应用到harness设计中，用PID控制器动态调节：

• 上下文丰富度（P）
• 约束严格度（I）
• 反馈灵敏度（D）

这个方向的探索刚刚开始，但初步结果显示可以提升约15%的迭代效率。