# Harness Engineering 工程化落地指南

## 核心结论

**Harness Engineering 的本质：如何让 AI 在你的项目里，持续、稳定、规范、顺畅地做出你真正想要的结果。**

六个核心概念解决六个不同问题，最终靠四块拼图一起转动。

---

## 核心概念速览

| 概念 | 问题 | 角色 |
|------|------|------|
| **Rule** | 什么事绝对不能乱来 | 基础规矩、红线、底线 |
| **Skill** | 这件事具体应该怎么做 | 标准操作手册 |
| **Sub Agent** | 复杂任务由谁分工 | 不同阶段专业角色 |
| **Workflow** | 按什么顺序接力 | 前进、暂停、打回、重跑规则 |
| **Scripts** | 谁来判断做没做好 | 统一门禁和事后验证 |
| **MCP** | 怎么接外部工程系统 | 外接能力接口 |

---

## Rule 的局限

**Rule 是软约束，不是硬门禁。**

AI 会出现三种典型情况：
1. 忘了某条 Rule
2. 认为 Rule 和当前需求"无关"
3. 知道 Rule 但偷懒没做

**Rule 不能单独解决问题。**

---

## 多 Agent 的演化路径

多 Agent 不是设计出来的，是被问题逼出来的：

遇到问题 → 拆分新 Agent → 继续遇到问题 → 继续拆分

三层补稳机制：
1. 流程定义文件
2. 角色契约（输入输出）
3. 流程校验脚本

---

## Scripts 是最后的兜底

**当 Rule 管不住、Agent 有随机性时，需要 Scripts 来兜底。**

三类问题：
- **A 类**：静态规范问题（代码风格、命名）
- **B 类**：基础交付门槛（编译、测试）
- **C 类**：工程一致性（构建产物、版本号）

总验证脚本把"是否完成"从 Agent 责任变成系统责任。

---

## 项目记忆机制

AI 不能只依赖当前对话，需要"整个项目的记性"：

- **dev-map**：技术债务、决策记录、历史上下文
- **任务看板**：进度、阻塞点、下一步

---

## 四块拼图全貌

| 拼图 | 作用 |
|------|------|
| Rule + Skill | 约束与规范 |
| Sub Agent + Workflow | 执行与协作 |
| Scripts | 验证与判断 |
| Memory/Context | 记忆与上下文 |

---

## 标签

#主题/AI-Agent #场景/技术博客

## 相关链接

- [[index]]
- [[agent-architecture]]
- [[tool-use]]