> ## Documentation Index
> Fetch the complete documentation index at: https://adonis-til.mintlify.app/llms.txt
> Use this file to discover all available pages before exploring further.

# 长时间 AI 编程任务的 Harness 设计：从单 Agent 到多 Agent 协作

> 解读 Anthropic Labs 关于多 Agent Harness 设计的实战经验，涵盖上下文退化、自我评估偏差、Generator-Evaluator 循环、三 Agent 架构，以及随模型进步简化架构的核心原则

> 原文：[Harness Design for Long-Running Application Development](https://www.anthropic.com/engineering/harness-design-long-running-apps) by Prithvi Rajasekaran (Anthropic Labs)

***

## 一句话总结

让 AI 跑 20 分钟和跑 6 小时是完全不同的工程问题。这篇文章讲的就是：**当任务足够复杂、运行足够长时，如何设计多 Agent 协作架构（Harness）来保证产出质量。**

***

## 一、两个核心失败模式

在开始讲解决方案之前，先搞清楚"到底哪里会出问题"。长时间运行的 Agent 有两个几乎必然会遇到的坑：

### 1.1 上下文退化：Agent 越跑越糊涂

你可能遇到过这种情况：Agent 前期表现不错，但随着对话越来越长，它开始丢细节、重复之前的错误、甚至忘了自己说过的话。

更隐蔽的问题是 **"上下文焦虑"（Context Anxiety）**：当模型感知到上下文窗口快满了，它会开始草草收尾——不是因为做完了，而是因为"慌了"。

**原则：Context Reset > Compaction**

| 策略                | 做法               | 效果              |
| ----------------- | ---------------- | --------------- |
| Compaction（压缩）    | 把之前的对话摘要后继续      | 保持连续性，但无法消除焦虑行为 |
| Context Reset（重启） | 清空上下文，启动全新 Agent | 干净的起点，焦虑行为消失    |

直觉上你会觉得摘要更好——保留了之前的信息嘛。但实际上，压缩虽然保留了连续性，却无法给模型提供"从头来过"的清爽感。**重启一个新 Agent，把必要的上下文显式传递过去，效果更好。**

> **实践要点：** 当你发现 Agent 开始赶工、跳过步骤、或者质量下降时，不要试图"提醒"它——直接开一个新会话，把当前进度和剩余任务作为新的输入传进去。

### 1.2 自我评估偏差：Agent 永远觉得自己做得不错

这是更难察觉的问题。让 Agent 写完代码后评价自己的产出，它会 **"自信地夸赞自己的作品——即使在人类看来质量明显平庸"**。

这在有明确对错的任务中问题不大（测试通不通过一目了然），但在 **主观性任务** 中会严重失真：

* 前端设计好不好看？
* 交互体验流不流畅？
* 代码架构优不优雅？

这些都没有二进制的"对/错"判断，Agent 很容易自我感觉良好。

**原则：评估与生成必须分离**

> 让写代码的 Agent 评价自己写的代码，就像让学生批改自己的考卷。调优评估者的批判性，比让生成者学会自我批评要容易得多。

***

## 二、Generator-Evaluator 循环：让 AI 设计不再"AI 味"

为了解决自我评估偏差，作者引入了一个受 GAN（生成对抗网络）启发的模式：**Generator 和 Evaluator 分离，循环对抗迭代**。

### 工作流程

```
Generator 生成设计 → Evaluator 用 Playwright 打开页面实际体验
  → 按四个维度打分 → 反馈给 Generator → Generator 改进
  → 重复 5-15 轮
```

### 四个评估维度

| 维度                       | 评估什么                  | 关键问题               |
| ------------------------ | --------------------- | ------------------ |
| **Design Quality（设计质量）** | 颜色、字体、布局、图像是否有统一的审美风格 | "看起来像不像一个整体？"      |
| **Originality（原创性）**     | 是否有自主的设计决策，而非模板默认值    | "有没有 AI 味 / 套模板感？" |
| **Craft（工艺）**            | 层次、间距、色彩和谐、对比度等技术执行   | "细节处理到不到位？"        |
| **Functionality（功能性）**   | 脱离审美后的可用性             | "好不好用？"            |

### 关键发现

**Prompt 措辞会独立于评估反馈，塑造输出的审美方向。** 作者发现，在 prompt 中使用 "museum quality" 这样的措辞，会引导模型向特定美学方向收敛。在一个案例中，一个荷兰博物馆网站经过 10 轮迭代后，从普通页面演化成了 3D CSS 透视空间配合自由导航——这种创意跳跃在单次生成中几乎不可能出现。

> **实践要点：** 当你希望 AI 生成的设计更有"性格"时，不要只描述功能需求，加入一些**审美方向的暗示词**（如 "editorial"、"museum quality"、"brutalist"），它们会像锚点一样引导整体风格。

***

## 三、三 Agent 架构：Planner → Generator → Evaluator

把上面的思路扩展到完整的全栈应用开发，作者设计了三个角色分工明确的 Agent：

```
┌──────────┐    ┌──────────┐    ┌──────────┐
│ Planner  │───▶│Generator │───▶│Evaluator │
│ 规划师    │    │ 生成器    │    │ 评估者    │
└──────────┘    └──────────┘    └──────────┘
 1-4 句需求       系统实现        像用户一样测试
 → 完整产品规格    → 自检后交付    → 打分 + 反馈
```

### 各角色详解

**Planner（规划师）**

* 输入：1-4 句简短需求描述
* 输出：完整的产品规格
* 关键：**鼓励野心但避免过度指定实现细节**——告诉它"做什么"和"为什么"，而不是"怎么做"
* 会主动寻找集成 AI 功能的机会

**Generator（生成器）**

* 按规格系统实现功能
* 使用典型全栈技术栈（React + Vite + FastAPI + SQLite/PostgreSQL）
* 完成后先做一轮自检再交付

**Evaluator（评估者）**

* 用 Playwright 像真实用户一样操作应用——点击界面、调用 API、检查数据库状态
* 按具体标准打分，设有硬性阈值
* **最重要的一点：先谈判 Sprint 合约，定义"完成"再开始编码**

### Sprint 合约：先定义"完成"再动手

这是整个架构中最值得借鉴的设计。在 Generator 开始写代码之前，Evaluator 会先和它协商一个 **Sprint 合约**：

```
Sprint 合约示例：
✅ 用户能注册和登录
✅ 能创建新项目并保存到数据库
✅ 项目列表页支持分页
❌ 暂不考虑权限管理
❌ 暂不需要文件上传
```

**为什么这很重要？** 因为没有明确的完成标准，Agent 会陷入两个极端：要么草草了事宣布完成（自我评估偏差），要么无限迭代改来改去。Sprint 合约让"完成"变成了可验证的清单。

### 效果对比

以"制作一个复古游戏编辑器"为例：

| 方式              | 耗时    | 成本    | 结果                          |
| --------------- | ----- | ----- | --------------------------- |
| 单 Agent 直接跑     | 20 分钟 | \$9   | 游戏机制有 bug，信息架构混乱            |
| 三 Agent Harness | 6 小时  | \$200 | 功能完整的编辑器、可玩关卡、集成 AI 生成精灵和关卡 |

差距不只是"好一点"——是从"勉强能看"到"真正可用"的质变。

***

## 四、随模型进步简化架构

这是文章中最有洞察力的部分。作者提出了一个核心原则：

> **每一个 Harness 组件都编码了一个关于模型局限性的假设。当模型改进后，这些假设需要被重新检验。**

### 实例：Opus 4.6 带来的简化

在开发过程中，Claude 升级到了 Opus 4.6。作者发现可以逐步移除之前必要的组件：

| 移除的组件     | 原因                                      |
| --------- | --------------------------------------- |
| Sprint 拆分 | Opus 4.6 的规划和持续执行能力提升，不再需要把任务拆成小 Sprint |
| 无条件 QA    | 评估者的价值取决于任务难度与模型能力的关系                   |

### 条件式 QA：什么时候评估是价值，什么时候是开销

```
任务难度 vs 模型能力：

任务难度 ▲
         │  ╔═══════════════════╗
         │  ║  QA 有真实价值     ║  ← 任务超出模型舒适区
         │  ║  能抓到真实缺陷    ║
         │  ╠═══════════════════╣
         │  ║  QA 变成开销       ║  ← 任务在模型能力范围内
         │  ║  增加时间但无收益   ║
         │  ╚═══════════════════╝
         └──────────────────────▶ 模型能力
```

用一个实例说明：作者用简化后的系统生成一个 **数字音频工作站（DAW）**，耗时 3 小时 50 分钟，花费 \$124.70，经历了 3 轮构建 + QA 循环。Evaluator 在每轮中都精准地发现了 Generator 偷偷 stub 掉的核心功能——证明对于这种复杂度的任务，QA 仍然有真实价值。

### 怎么判断该加还是该减复杂度？

```
问自己这三个问题：

1. 这个组件要解决的模型缺陷，现在还存在吗？
   → 不存在 → 移除

2. 移除后质量会下降吗？
   → 做对照实验验证

3. 当前任务的难度超出模型的舒适区了吗？
   → 超出 → 保留/增加 QA
   → 没超出 → 简化
```

***

## 五、实战启示：这些原则怎么用在日常

你不需要搭建完整的三 Agent 系统才能从这篇文章中获益。以下是可以直接应用的原则：

### 原则 1：大任务用 Context Reset 而非长对话

```
❌ 在一个会话里干所有事，越到后面越糊涂
✅ 拆成多个会话，每个会话开头显式传入上下文和目标
```

在 Claude Code 中，这意味着：当你发现对话变长且质量下降时，开一个新会话，用清晰的 prompt 重述当前进度和剩余工作。

### 原则 2：生成和评估分开做

```
❌ "帮我写完这个组件，顺便检查一下有没有问题"
✅ 先让 Agent 写完 → 新开一轮/用子 Agent 专门审查
```

这和 Superpowers 中的 `requesting-code-review` skill 是同一个思路——让不同的 Agent 实例来评估，避免自我偏差。

### 原则 3：先定义"完成"再开始

```
❌ "帮我实现用户系统"
✅ "帮我实现用户系统，完成标准：
    1. 注册/登录流程能跑通
    2. 密码用 bcrypt 加密
    3. 有基本的输入校验
    暂不需要：OAuth、邮箱验证、权限角色"
```

明确的边界帮助 Agent 知道什么该做、什么不该做，避免无限发散或草草收尾。

### 原则 4：定期质疑你的工作流复杂度

每隔一段时间问自己：

* 我的 `CLAUDE.md` 里有没有因为模型已经改进而不再需要的规则？
* 我是不是在用旧模型的经验来限制新模型？
* 哪些"必须"的步骤其实可以去掉了？

> **"有趣的 Harness 组合空间不会随着模型改进而缩小——它会移动。AI 工程师的有趣工作，就是不断发现下一个新的组合。"**

### 原则 5：用审美暗示词提升设计质量

当需要 AI 生成前端设计时，在 prompt 中加入风格锚点：

| 暗示词                | 引导方向         |
| ------------------ | ------------ |
| "museum quality"   | 精致、沉浸式、艺术感   |
| "editorial"        | 排版驱动、杂志风     |
| "brutalist"        | 粗犷、反传统、强视觉冲击 |
| "craft beer label" | 手工感、细节丰富     |

这些词不是指令，而是**审美锚点**——它们会在迭代过程中持续影响设计方向。

***

## 六、与相关文章的关系

这篇文章和 Agentic Engineering 的层级体系（见 [Agentic Engineering 的 8 个层级](/posts/ai/levels-of-agentic-engineering)）有直接对应：

| 层级    | 概念         | 本文对应内容                             |
| ----- | ---------- | ---------------------------------- |
| 第 3 层 | 上下文工程      | Context Reset vs Compaction        |
| 第 6 层 | Harness 工程 | 三 Agent 架构、Sprint 合约、Playwright 测试 |
| 第 7 层 | 后台 Agent   | Generator-Evaluator 分离、条件式 QA      |

如果说 [Superpowers 实战指南](/posts/ai/superpowers-workflow-guide) 讲的是"用 Skill 约束单个 Agent 的行为纪律"，那这篇讲的就是更上一层——**用多 Agent 协作来突破单 Agent 的能力天花板**。

三者形成递进：

```
工程纪律（Superpowers）→ 多 Agent 协作（Harness）→ 自主团队（第 8 层）
    约束单个 Agent            突破单 Agent 天花板         Agent 间自主协调
```