背景

你以为AI效果不好是模型问题？错了。

最近，OpenAI和Anthropic的工程师们发现了一个让人惊讶的事实：花大价钱升级AI模型，效果可能只提升5%~15%；但如果你升级的是"Harness"——也就是AI的工作框架——收益可能高达30%~300%。

这意味着什么？

真正决定AI任务成功率的，不是模型本身，而是你怎么"驾驭"它。

什么是Harness Engineering？

Harness Engineering，直译是"马具工程"，在AI领域指的是：

为每个任务构建专属的工作框架，而不是让AI直接执行指令。

用户任务 → 生成专属Harness → Planner规划 → Researcher调研 → Coder执行 → Reviewer审查 → Tester测试 → 高质量结果

为什么Harness突然火了？

1. 模型升级的边际效益递减

GPT-4到GPT-4o，模型能力提升显著，但在很多实际任务中，用户感知到的提升并没有想象中那么大。

原因很简单：模型再聪明，如果没有好的工作框架，它也不知道该先做什么、后做什么，更不知道如何避免错误。

2. Harness的收益是数量级的

Anthropic的实验数据显示：

差距有多大？6倍到20倍。

3. Dynamic Workflow成为主流

Anthropic提出的Dynamic Workflow概念正在被广泛接受：

• 不是固定写死一套流程
• 而是根据任务动态生成：Planner、Researcher、Coder、Reviewer、Tester
• 每个Agent都有明确的职责和输出标准

目前最流行的Harness结构

project/
│
├── AGENTS.md                    # Agent配置和指令
│
├── docs/
│   ├── requirements.md          # 需求文档
│   ├── architecture.md          # 架构设计
│   ├── coding-standard.md       # 编码规范
│   └── roadmap.md               # 路线图
│
├── tasks/
│   ├── backlog.md               # 待办事项
│   ├── active.md                # 进行中
│   └── completed.md             # 已完成
│
├── memory/
│   ├── decisions.md             # 决策记录
│   ├── lessons.md               # 经验教训
│   └── progress.md              # 进度状态
│
├── outputs/                     # 输出目录
│
└── scripts/                     # 脚本工具

五层架构解析

第一层：任务入口（task.md）

用户需求的最小单元，例如："开发一个CRM系统"。

第二层：自动生成项目地图

AI先生成完整的项目结构，包括：

• AGENTS.md：定义Agent的角色和职责
• architecture.md：技术架构设计
• roadmap.md：实施路线图
• tasks/：任务分解目录

第三层：动态创建Agent

根据任务类型自动生成：

第四层：任务自动拆解

以CRM系统为例，自动拆分为：

• 001 用户系统
• 002 权限系统
• 003 客户管理
• 004 订单管理
• 005 报表系统

形成tasks/目录，每个任务独立追踪。

第五层：状态持久化

最新Harness理念：状态存在文件，不要存在上下文。

memory/progress.md    # 进度状态
memory/decisions.md   # 决策记录
memory/lessons.md     # 经验教训

每次启动时读取状态，恢复工作，继续执行。不依赖长上下文窗口。

一个完整的Harness工作流示例

假设你给Claude一个需求："帮我开发一个在线商城系统"

Step 1: 生成Harness

Claude首先创建项目结构：

ecommerce-project/
├── AGENTS.md
├── architecture.md
├── roadmap.md
├── tasks/
│   ├── 001-user-system.md
│   ├── 002-product-system.md
│   ├── 003-order-system.md
│   ├── 004-payment-system.md
│   └── 005-admin-system.md
├── memory/
│   ├── decisions.md
│   ├── lessons.md
│   └── progress.md
└── outputs/

Step 2: Planner规划

Planner Agent分析需求，确定：

• 技术栈：React + Node.js + PostgreSQL
• 架构模式：前后端分离 + REST API
• 开发顺序：用户系统 → 商品系统 → 订单系统 → 支付系统 → 后台管理

Step 3: Researcher调研

Researcher Agent调研：

• 用户认证最佳实践（JWT vs Session）
• 支付接口对比（Stripe vs PayPal）
• 数据库设计范式

Step 4: Coder实现

Coder Agent按照任务顺序，逐个实现功能模块。

Step 5: Reviewer审查

Reviewer Agent检查代码质量：

• 代码规范
• 安全漏洞
• 性能问题

Step 6: Tester测试

Tester Agent生成测试用例：

• 单元测试
• 集成测试
• 端到端测试

最终结果：你得到的不只是一堆代码，而是一个完整的、经过审查的、有文档的项目。

如何开始使用Harness Engineering？

如果你也想尝试Harness Engineering，这里有一个简单的入门Prompt：

You are a Harness Engineer.

Before solving the task:

1. Generate a complete harness structure.
2. Create AGENTS.md.
3. Create architecture.md.
4. Create roadmap.md.
5. Create task breakdown.
6. Create memory files.
7. Create output directory.
8. Define specialized agents.
9. Only after the harness is generated, start execution.

Output the full project tree first.

适用场景

Harness Engineering特别适合以下场景：

• 复杂软件开发项目
• 需要多步骤推理的研究任务
• 需要质量保证的内容生成
• 需要状态持久化的长期项目
• 团队协作的AI辅助工作流

不适用场景

• 简单问答
• 单轮对话
• 快速原型验证（直接用模型可能更快）

未来趋势：Harness将成为AI应用的标准配置

随着AI模型能力越来越强，如何"驾驭"模型将成为核心竞争力。

最后

回到开头那个公式：

Agent = Model + Harness

模型是引擎，Harness是方向盘和底盘。

引擎再强，没有好的方向盘和底盘，车也跑不直。