Harness Engineer工程开发范式实战教程（非常详细），从入门到精通，收藏这一篇就够了！

Python编程杰哥

184人浏览 · 2026-03-26 14:25:28

Python编程杰哥 · 2026-03-26 14:25:28 发布

一、Harness Engineering 核心哲学

1.1 什么是 Harness Engineering

Harness Engineering 是 OpenAI 提出的 AI 原生开发方法论，核心思想是：

“设计环境，构建反馈回路，让 Agent 自主运转”

与传统软件开发不同，Harness Engineering 强调：

地图式导航 而非详细说明书
知识嵌入仓库 而非外部文档
机械验证 而非人工检查
迭代自愈 而非等待评审

1.2 四项核心实践

实践	传统方式	Harness 方式
信息组织	详细的手册和文档	AGENTS.md 地图 + 嵌入式知识
规范传递	口头传授、文档阅读	lint 规则、自动化检查
验证闭环	人工 review、手动测试	自动化测试、Agent 可观测
错误修复	等待人类介入	1-3轮自动迭代收敛

1.3 核心洞察

模型能力是地基，Harness 是上层建筑。

投入产出比递减：
- AGENTS.md + 验证闭环 → 80分（巨大提升）
- 80分到95分 → 工程量可能是前面的10倍

二、AI Coding 阶段论

2.1 Steve Yegge 的八阶段模型

阶段	描述	典型工具
阶段1	零 AI 或接近零 AI	偶尔代码补全
阶段2	IDE 内 Agent，需授权	Copilot Chat、边栏 Agent
阶段3	IDE 内 Agent，YOLO 模式	关闭权限确认
阶段4	IDE 内，Agent 全屏	Agent 占满屏幕，代码区变 Diff
阶段5	CLI，单 Agent	Claude Code、Codex CLI
阶段6	CLI，多 Agent 并行	3-5个实例同时工作
阶段7	10+ Agent，手动管理	触及手动管理极限
阶段8	构建自己的编排器	自动化 Agent 工作流编排

2.2 范式跃迁的关键节点

IDE→CLI****的跃迁：

CLI 是一等公民：本地、远程、CI 流水线环境一致
端到端闭环：读-改-跑-修是主路径，无需配置
长时自治：可跑几十分钟甚至几小时，失败自动重试
人机分工清晰：人是"指挥官"，Agent 负责全部执行

单 Agent → 多 Agent 的跃迁：

从 subagent 模式（主-从）到 mailbox 模式（peer-to-peer）
Agent 之间直接协商、分工、同步进度
无需中心调度器

三、Harness 工程工作流

3.1 六步开发流程

┌─────────────────────────────────────────────────────────────┐
│  1. 需求分析 (PRD)                                           │
│     └─ 业务背景 → AI生成初版PRD → 多轮细化                   │
├─────────────────────────────────────────────────────────────┤
│  2. 技术选型 (Tech Doc)                                      │
│     └─ 市场调研 → 技术选型 → 编写技术文档                    │
├─────────────────────────────────────────────────────────────┤
│  3. 任务拆分 (Task Doc)                                      │
│     └─ PRD+Tech Doc → AI拆分任务 → 创建Task清单              │
├─────────────────────────────────────────────────────────────┤
│  4. 编码实现 (Code)                                          │
│     └─ TDD → 验证闭环 → 自测功能                             │
├─────────────────────────────────────────────────────────────┤
│  5. 代码审查 (Review)                                        │
│     └─ 人工审查 + AI辅助审查 → Code Health检查               │
├─────────────────────────────────────────────────────────────┤
│  6. 交付维护 (Deploy)                                        │
│     └─ CI/CD → 监控 → 自动修复                               │
└─────────────────────────────────────────────────────────────┘

3.2 文档先行原则

核心文档体系：

文档	作用	维护者
PRD	产品需求文档，明确功能、用户、业务流程	PM/需求方
Tech Doc	技术设计文档，架构、选型、接口定义	技术负责人
Task Doc	任务清单，可验证、可执行的小任务	AI/开发者
Spec	详细规格，含验证方案	开发者
Design	技术设计，模块划分、数据流	开发者
AGENTS.md	项目地图，结构、命令、规范	团队
CLAUDE.md	上下文注入，项目背景、约束	团队

文档喂养策略：

每次开启新会话前，将三个核心文档（PRD + Tech Doc + Task Doc）喂给 AI
让 AI 了解项目整体情况，避免上下文污染

3.3 任务拆分原则

SMART 原则：

Specific：任务明确，不模糊
Measurable：可验证，有完成标准
Achievable：1-2小时内可完成
Relevant：与目标相关
Time-bound：有时限

示例 Task Doc 结构：

## 第一阶段：项目基础搭建

### 1. 三端项目初始化
**博客前台**
- [✔] Vue3 + Vite 项目搭建
- [ ] 路由配置
- [ ] Axios 封装

**管理后台**
- [ ] Vue3 + Element Plus 项目搭建
- [ ] 路由与权限配置

### 2. 数据库设计
- [ ] 用户表设计
- [ ] 文章表设计

四、核心开发范式

4.1 Spec-Driven Development（规范驱动开发）

Kiro 模式：

Requirement → Design → Tasks
     ↑           ↓        ↓
   确认        确认    执行

整个流程串行且不可跳过
必须确认上一阶段产出，才能推进到下一步
每个阶段可审查、修改、追加

两种变体：

Requirement-First：先写需求，再设计，最后任务
Design-First：已有明确技术方案时，先设计再反推需求

4.2 Claude Code 的自由模式

Anthropic 推荐工作流：

收集上下文 → 采取行动 → 验证工作 → 循环

复杂问题处理：

要求 Agent 阅读相关文件
明确告知先不要编写任何代码
要求制定一份计划
确认计划后再执行

关键警示：

“如果没有调研和规划步骤，Claude 的输出往往会直接跳到编写代码这一步。”

4.3 验证闭环设计

三层验证体系：

层级	验证内容	触发时机
L1: 静态检查	lint、format、type check	每次代码变更
L2: 单元测试	功能正确性、覆盖率	提交前
L3: 集成验证	启动应用、接口测试、E2E	PR前/部署前

Agent 可观测性：

将验证脚本串进 Agent 工作流
lint → spotless → build 自动触发
通过 start.sh 启动应用，用 curl/websocat 跑接口验证
使用 Agent Browser 操作浏览器定位问题

4.4 迭代自愈机制

改完代码 → 自动跑验证 → 失败 → AI分析修复 → 再验证
                ↓
            1-3轮收敛 → 反复失败 → 升级给人类

垃圾回收机制：

后台 Agent 定期扫描代码库
发现偏离团队规范的模式自动开 PR 修复
持续偿还小额技术债，而非等待堆积

五、多 Agent 协作模式

5.1 协作范式演进

模式	特点	适用场景
Subagent	主 Agent 派任务给子 Agent，收集结果	树形任务分解
Experts	专家 Agent 团队，各负责不同领域	复杂技术问题
Mailbox (Peer-to-Peer)	Agent 间直接通信，无中心调度	高度协作场景
Supervisor	Supervisor 管理 Specialized Agent 团队	系统化工程

5.2 Mailbox 机制（Claude Code）

┌─────────────┐      mailbox      ┌─────────────┐
│   Agent A   │ ←───────────────→ │   Agent B   │
│  (Frontend) │      点对点通信    │   (Backend) │
└─────────────┘                   └─────────────┘
       ↑                               ↑
       └────────── 直接协商 ──────────┘

特点：

Agent 之间直接协商、分工、同步进度
无需经过中心调度器
每个 Agent 是平等的 peer

5.3 Helmsman 模式（Supervisor）

┌─────────────────────────────────────────────┐
│              Supervisor Agent               │
│         (规划、协调、质量控制)               │
└──────────┬────────────────┬─────────────────┘
           ↓                ↓
┌──────────────────┐  ┌──────────────────┐
│   Coding Team    │  │   Testing Team   │
│  (代码实现 Agent) │  │ (测试生成 Agent)  │
└──────────────────┘  └──────────────────┘

工作流程：

Planning：用户查询通过人机对话 refine 成可执行计划
Coding：Supervisor 管理的 Specialized Agent 团队协作构建代码
Evaluation：代码在闭环模拟中自主测试和 refine

六、文档体系规范

6.1 AGENTS.md 地图规范

核心原则：Map not Manual

# AGENTS.md - Project Map

## 项目结构

src/├── components/ # UI 组件├── services/ # 业务逻辑├── utils/ # 工具函数└── tests/ # 测试文件


## 常用命令
- `npm run dev` - 启动开发服务器
- `npm run test` - 运行测试
- `npm run lint` - 代码检查

## 编码规范
- 见 `.cursor/rules`
- 使用 TypeScript 严格模式
- 组件使用函数式 + Hooks

## 架构文档
- [详细设计](./docs/architecture.md)
- [API 文档](./docs/api.md)

6.2 CLAUDE.md 上下文规范

作用： 为 Claude Code 注入项目级上下文

# CLAUDE.md

## 项目背景
这是一个现代化的个人博客系统，包含 AI 辅助写作功能。

## 技术栈
- 前端：Vue 3 + Vite + TypeScript
- 后端：Spring Boot + Kotlin
- 数据库：MySQL + Redis

## 开发约束
- 必须使用 Composition API
- 所有 API 调用需封装在 services 层
- 表单必须使用 validation 库

## 常见陷阱
- 不要直接使用 axios，使用封装后的 httpClient
- 图片上传必须使用压缩

6.3 Rules 规范（.cursor/rules）

# .cursor/rules
rules:
  - name: "TypeScript 严格模式"
    pattern: "*.ts"
    enforce: "strictNullChecks: true"

  - name: "组件命名"
    pattern: "*.vue"
    enforce: "PascalCase，多词组件名"

  - name: "禁止直接调用 API"
    pattern: "*.ts, *.vue"
    forbid: "axios.get|axios.post"
    suggest: "使用 httpClient"

七、质量保障体系

7.1 Code Health 指标

AI Readiness：

Code Health >= 9.5（理想 10.0）
低质量代码会降低 AI 表现

三层防护：

层级	工具	作用
生成时	`code_health_review`	每段代码生成时检查
提交前	`pre_commit_safeguard`	对未提交文件检查
PR前	`analyze_change_set`	分支 vs base 全量检查

7.2 覆盖率作为行为护栏

传统陷阱：

覆盖率变成数字游戏
过度 mock，测试 inflated metrics

Agentic 时代：

设置高阈值（如 99%）
覆盖率回归信号立即可见
防止 Agent 删除测试来通过检查

7.3 端到端自动化

构建可分发产品 → 创建/修改 Git 仓库 → 注入代码异味
         ↓                                    ↓
    调用产品验证 ←────────────────────── 检测问题

关键：

单元测试是基础，但只验证局部行为
E2E 测试验证真实场景下的产品行为
AI 速度下，这种自动化成为 non-negotiable

八、Agentic Workflow 模式

8.1 Prompt Chaining（提示链）

输入 → LLM Call 1 → 检查点 → LLM Call 2 → 检查点 → 输出
            ↓                      ↓
       中间产物验证          中间产物验证

适用场景：

任务可分解为固定子任务
用延迟换准确性
每步 LLM 调用都是简单任务

示例：

生成营销文案
翻译成其他语言
检查合规性

8.2 Routing（路由）

输入 → 分类器 LLM → 路由到专用 Agent → 输出
            ↓
      意图识别

适用场景：

多种类型的任务需要不同处理
每个任务有专门的优化 Agent

8.3 Parallelization（并行化）

┌→ LLM 1 → 结果 1 ─┐
输入 ────┼→ LLM 2 → 结果 2 ─┼→ 聚合器 → 输出
         └→ LLM 3 → 结果 3 ─┘

适用场景：

任务可分段并行处理
需要投票机制提高准确性
处理大量相似任务

8.4 Orchestrator-Workers（编排器-工作者）

输入 → Orchestrator LLM → 任务分解
                              ↓
                    ┌────────┼────────┐
                    ↓        ↓        ↓
                  Worker 1 Worker 2 Worker 3
                    └────────┼────────┘
                              ↓
                        聚合结果 → 输出

适用场景：

复杂任务，子任务无法预先确定
需要动态规划执行路径

8.5 Evaluator-Optimizer（评估-优化）

输入 → LLM 生成 → 评估器评分 → 分数合格? → 输出
                      ↓否
                  反馈给 LLM 优化

适用场景：

需要多轮优化才能达到质量标准
有明确的评估标准

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

在这里插入图片描述

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～