harness engineering

rag系列文章目录

---

文章目录

• rag系列文章目录
• 前言
• 一、简介
• 二、关键思想
• 三、核心组成
• 总结

---

前言

现在大家都在使用claude code进行ai coding，当大家觉得ai coding做的不太好的时候，首先想到的是模型能力不行，这合理吗？其实现在模型能力并没有那么重要了，或者说一般大模型都是能够满足coding的需求的，此时需要考虑的就是harness engineering。

这里还有一个问题，就是在ai时代，ai输出了大量的代码，人无法逐行理解，如何保证代码的准确性，这也是需要harness engineering。

---

一、简介

harness本质：

不是写代码，而是设计一个"环境 + 约束 + 反馈系统"，让 AI 稳定地产生正确代码

换句话说：

传统工程：人 → 写代码
Harness 工程：人 → 设计系统 → AI 写代码

它的核心职责：

精确 specification（避免歧义）
设计执行环境（repo / tools / context）
构建验证机制（tests / CI / lint）
控制 agent 行为（边界 +流程）
审核输出而不是实现细节

二、关键思想

• 不要让 AI 做设计决策

  架构，数据模型，API 约束，依赖选择，必须由人进行定义。

  否则：模糊输入 → AI 自行设计 → 不可控系统

• 模糊 = 随机行为

  ai的行为规律：

  描述越模糊 → 偏差越大

  描述越精确 → 可预测性越强

• Harness ≠ Prompt

  不要只靠 prompt 控制 AI，把控制逻辑外移到系统层，对应实现可以是：CI / 测试、hooks、tool 限制、repo 结构。

• 把 AI 放进"轨道"而不是"对话"

  不要对话驱动，而要系统驱动

三、核心组成

1. Specification（规格层）
   定义：要做什么，不允许做什么，成功标准
2. Context（上下文层）
   长上下文会丢失信息，需要结构化管理
3. Tools（工具层）
   设计原则：小而明确（单职责），有边界，可验证
4. Constraints（约束层）
   强制规则：文件访问限制，命令白名单，权限控制
   不是告诉 AI "不要做"，而是"做不了"
5. Feedback（反馈层）
   核心：tests，lint，CI，自动检查
   让系统告诉 AI 对不对，而不是人去看代码

一般的ai开发流程：

1. 明确定义任务（spec）
2. 限定作用范围（scope）
3. 提供必要上下文
4. AI 实现
5. 自动验证（tests / CI）
6. 人只做结果审查

---

总结

Agent 能力 = 模型能力 × Harness 质量。如果 agent 表现不稳定，不要调 prompt，不要换模型，先重构 harness。

参考文档1，2，3