# Harness Design

> GAN 风格的多 Agent Harness 工作流编排器。在用户明确要求或同意进入 Harness 模式时， 创建 Generator + Evaluator subagent 对， 通过交互式对话为用户的具体任务生成定制化评估标准，然后全自动迭代直到质量达标。 适用于任何需要"生成-评估"循环的场景：前端页面设计、文档写作、代码生成、方案设计等。 当用户提到 harness、生成评估循环、多 agent 协作设计、质量迭代、Generator+Evaluator、 对抗式生成、前端设计质量评审 时使用。即使用户只说"帮我设计一个页面"或"帮我写个方案"， 如果任务复杂度足以受益于迭代评估，也应建议使用此 skill，并先与用户确认是否进入 Harness 模式。

- Skill: `josephcooperhc/harness-design-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add josephcooperhc/harness-design-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/josephcooperhc/harness-design-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: JosephCooperHC (https://skillmd.com/u/josephcooperhc)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/josephcooperhc/harness-design-2

---


# Harness Design：生成-评估迭代工作流

受 Anthropic 工程博客 "Harness design for long-running application development" 启发，
本 skill 将 GAN 风格的 Generator + Evaluator 对抗架构落地为可操作的工作流。

核心理念：**生成与评估分离，通过迭代反馈循环持续提升输出质量**。

## 运行原则

优先用第一性原理判断是否真的需要 Harness，而不是机械地起多 agent：

1. 如果任务简单、成功标准单一、一次生成就能验证，直接完成任务，不进入本流程。
2. 如果任务复杂但用户尚未明确要求 subagent，先完成 Phase 1 和 Phase 2，再征求一次确认是否切换到 Harness 模式。
3. 只有当用户明确要求 harness / 多 agent / subagent / Generator+Evaluator / 并行评审，或已经同意切换到 Harness 模式时，才进入完整的 subagent 迭代。
4. 如果上层指令、权限或环境限制不允许创建 subagent，则降级为"手动 Harness"：
   - 先产出评估标准和 Evaluator 提示词。
   - 再由主线程显式分角色串行执行 Generator / Evaluator。
   - 不要把串行角色扮演描述成真实多 agent 运行。

## 工作流总览

```
Phase 1: 理解任务 → Phase 2: 定义评估标准 → Phase 3: 自动迭代
```

```
                    ┌─────────────┐
                    │   Planner   │ ← 你（用户）+ 本 skill
                    │  定义标准    │
                    └──────┬──────┘
                           │ 评估标准 + 任务描述
                    ┌──────▼──────┐
               ┌───►│  Generator  │
               │    │  生成产出    │
               │    └──────┬──────┘
               │           │ 产出物
               │    ┌──────▼──────┐
               │    │  Evaluator  │
               │    │  独立评分    │
               │    └──────┬──────┘
               │           │
               │     达标？─┤
               │     否 ↙   └─► 是 → 交付
               └────┘
```

---

## Phase 1：理解任务（2 分钟）

目标：搞清楚要生成什么、给谁用、什么算好。

### 需要收集的信息

通过对话快速确认以下 4 点：

1. **任务类型**：前端页面 / 文档 / 代码 / 方案 / 其他
2. **产出物**：具体要交付什么（一个页面？一份文档？一段代码？）
3. **目标用户**：谁会使用/阅读这个产出物
4. **质量期望**：用户心中"好"的标准是什么（哪怕模糊的也行）

如果用户说不清楚质量标准，没关系——Phase 2 会引导他们定义。

### 确定 Generator 的领域 skill

根据任务类型，先看当前会话里**实际可用**的 skill，再决定是否给 Generator 或 Evaluator 加载。不要引用不存在的 skill 名称。

| 任务类型 | 优先 skill | 使用规则 |
|---------|------------|----------|
| 前端页面设计（Figma 落地） | `figma-implement-design` | 仅当用户提供 Figma URL/node 或要求 1:1 对齐设计稿 |
| 前端页面设计（一般实现） | 无专门 skill | 直接按项目技术栈和现有前端规范实现 |
| 技术文档 / 方案设计 | `tech-doc-writer` | 适合 design doc、技术方案、使用指南 |
| 浏览器交互评测 | `playwright` | 主要给 Evaluator 用于访问页面、截图、核对状态 |
| 文档 / PDF 交付 | `doc` / `pdf` | 仅在产出格式或视觉校验需要时加载 |
| 代码实现 | 选择当前确实存在的语言/框架 skill，否则无 skill | 不要臆造 skill 名 |
| 其他 | 与用户讨论确定 | 先追求可执行，再追求花哨编排 |

如果某个预想中的领域 skill 当前不存在，直接不用，不要为了"完整性"硬塞一个虚构依赖。

**确认后进入 Phase 2。**

---

## Phase 2：定义评估标准（5 分钟）

这是本 skill 的核心价值——帮用户把模糊的"好不好"变成可打分的具体维度。

### Step 2.1：选择评估维度

根据任务类型，向用户推荐 3-5 个评估维度。每个维度需要：
- **维度名称**
- **权重**（百分比，所有维度加起来 = 100%）
- **评分标准**（1-10 分，至少定义 9-10、7-8、5-6、1-4 四档）
- **具体检查项**（2-4 个可操作的检查点）

#### 维度推荐模板

以下是按任务类型预设的维度模板，作为对话起点（不是死板模板，根据用户反馈调整）：

**前端页面设计：**
- D1 任务效率（30%）— 用户能否快速完成核心任务
- D2 信息层级（25%）— 信息优先级是否通过视觉正确传达
- D3 视觉一致性（20%）— 颜色/字体/间距是否协调统一
- D4 交互反馈（15%）— 操作是否有及时明确的反馈
- D5 边界状态（10%）— 空状态/加载态/错误态是否妥善处理

**技术文档：**
- D1 准确性（35%）— 技术细节是否正确、无歧义
- D2 完整性（25%）— 关键信息是否都覆盖到
- D3 可读性（20%）— 结构是否清晰、是否易于快速定位
- D4 可操作性（20%）— 读者能否按文档实际执行

**代码生成：**
- D1 功能正确性（35%）— 是否满足需求、通过测试
- D2 代码质量（25%）— 可读性、命名、结构
- D3 健壮性（20%）— 错误处理、边界情况
- D4 性能（20%）— 是否有明显性能问题

### Step 2.2：与用户确认并调整

将推荐的维度以表格形式展示给用户，问：
- "这些维度覆盖了你关心的方面吗？"
- "权重分配合理吗？哪个维度对你更重要？"
- "有没有需要增加或去掉的维度？"

根据用户反馈调整，直到用户确认。

### Step 2.3：设定通过阈值

与用户确认：
- **通过分数**：加权总分 ≥ X 分为通过（建议默认 7.5）
- **单项最低分**：任何单项 < Y 分则不通过（建议默认 5.0）
- **最大迭代轮数**：防止无限循环（建议默认 3 轮）

**确认后进入 Phase 3。**

---

## Phase 3：自动迭代

### Step 3.1：生成 Evaluator 提示词

基于 Phase 2 确认的评估标准，自动生成一段完整的 Evaluator 提示词。
提示词结构必须包含以下部分：

```
# [任务类型] Evaluator

你是一个独立的[任务类型]评估器。你的职责是按标准打分并给出改进意见，不要修改产出物本身。
你与 Generator 是对抗关系：严格按标准评分，不要因为"已经不错了"就放水。

## 评估流程
1. [根据任务类型定义检查方式——如前端需要实际访问页面，文档需要通读全文]
2. 按以下 N 个维度逐项评分（1-10 分）
3. 给出总评和具体改进清单
4. 判定：通过 / 需迭代

## 评分维度
[Phase 2 确认的所有维度，每个包含：分档标准 + 检查项]

## 评估输出格式
[标准化的评估报告模板，包含：评分表、判定结果、具体问题清单]

## 规则
- 只负责评估，不要自己改产出物
- 每个问题必须给出具体的、可执行的改进建议
- 如果同一问题连续 2 轮未改进，升级为 P0
- 评分要稳定：相同质量在不同轮次应得到相近分数
```

将生成的 Evaluator 提示词展示给用户确认。

### Step 3.2：启动 Generator

创建 Generator subagent，提供：
- 用户的原始任务描述
- 要使用的领域 skill（Phase 1 确定的）
- 输出路径
- 与主 agent 相同的模型和 `reasoning_effort`；除非子任务非常小、低风险、非关键路径，否则不要静默降级
- 明确要求它只负责生成，不要自评

### Step 3.3：启动 Evaluator

Generator 完成后，创建 Evaluator subagent，提供：
- Step 3.1 生成的 Evaluator 提示词
- Generator 的产出物路径
- 评估标准和通过阈值
- 与主 agent 相同的模型和 `reasoning_effort`
- 可实际访问的评测入口：页面 URL、启动命令、文件路径、仓库路径或截图产物

### Step 3.4：迭代循环

```
WHILE 轮数 < 最大迭代轮数:
  1. Evaluator 评分
  2. IF 总分 ≥ 通过阈值 AND 所有单项 ≥ 最低分:
       → 通过，输出最终结果
       → BREAK
  3. ELSE:
       → 提取 Evaluator 的改进建议
       → 创建新的 Generator subagent（上下文重置！）
       → 将改进建议 + 原始任务描述作为输入
       → 回到 Step 1
```

**关键：每轮 Generator 都用新的 subagent（上下文重置）**，只传入：
- 原始任务描述
- Evaluator 的改进建议
- 上一轮产出物的路径（供参考，不是让它在上面改）

这样 Generator 在干净的上下文中工作，避免"上下文焦虑"导致的保守改动。

每轮都保存最少三类产物，保证有证据链可追溯：
- Generator 产物
- Evaluator 报告
- 提炼后的改进清单

### Step 3.5：输出最终报告

迭代结束后，向用户汇报：

```
## Harness 迭代报告

**任务**：[任务描述]
**迭代轮数**：N
**最终评分**：X.X/10

### 评分明细
| 维度 | 权重 | 第1轮 | 第2轮 | ... | 最终 |
|------|------|-------|-------|-----|------|

### 关键改进记录
- 第1→2轮：[主要改了什么]
- 第2→3轮：[主要改了什么]

### 产出物位置
[最终产出物的路径]
```

---

## 注意事项

### 上下文重置的重要性
每轮 Generator 必须是全新的 subagent。不要在同一个 agent 里说"请根据反馈修改"——
这会让模型在越来越长的上下文中变得保守。干净的上下文 + 明确的改进方向 = 更好的产出。

### 评估与生成必须分离
不要让 Generator 自己评估自己的产出。即使是同一个模型，作为 Evaluator 时
它只拿到评估标准和产出物，不知道生成过程中的"苦衷"，才能客观评分。

### 子 agent 模型选择
- Generator 和 Evaluator 默认跟随主 agent 的模型与 `reasoning_effort`
- 只有在用户明确允许，且任务很小、风险低、不在关键路径上时，才降级到更轻模型

### 需要真实可评测的对象
前端、文档、代码这三类任务都需要真实产物才能评估。进入 Phase 3 前，先确认至少具备以下之一：
- 可打开的页面 URL 或启动命令
- 可读取的文件路径
- 可运行的代码仓库或测试命令

如果这些都没有，就先补齐评测对象，再启动 Evaluator。

### 何时不需要 Harness
- 任务简单明确，一次就能做好 → 直接做，不需要本流程
- 用户明确说"不用这么复杂" → 尊重用户，可以只生成 Evaluator 提示词供手动使用
- 评估标准完全主观且用户无法量化 → 简化为用户手动审查，不做自动评分