146 lines
6.5 KiB
Markdown
146 lines
6.5 KiB
Markdown
---
|
||
title: "长运行应用的 Harness 设计"
|
||
source: "Harness design for long-running application development"
|
||
raw_sources:
|
||
- path: raw/Harness design for long-running application development.md
|
||
hash: "sha256:initial"
|
||
tags:
|
||
- "实践指南"
|
||
- "Harness工程"
|
||
- "多智能体"
|
||
last_updated: 2026-04-11
|
||
---
|
||
|
||
# 长运行应用的 Harness 设计
|
||
|
||
本文基于 Anthropic 团队的实践经验，探讨如何设计有效的 Harness 来支持长运行、自主的应用开发任务。
|
||
|
||
## 核心问题
|
||
|
||
在长运行 Agent 任务中，简单的实现通常会遇到两个持续存在的问题：
|
||
|
||
### 1. 上下文窗口填充导致的连贯性丧失
|
||
|
||
随着任务进行，模型往往会在冗长任务上失去连贯性。一些模型还表现出"**上下文焦虑**"——当它们接近认为的上下文限制时，会过早地结束工作。
|
||
|
||
**解决方案对比**：
|
||
- **压缩 (Compaction)**：总结对话的早期部分，使同一个 Agent 可以在缩短的历史上继续。保留了连续性，但没有给 Agent 一个干净的状态。
|
||
- **上下文重置 (Context Reset)**：完全清除上下文窗口并启动一个新的 Agent，结合结构化移交来携带前一个 Agent 的状态和下一步。提供了干净的状态，但增加了编排复杂性、令牌开销和延迟。
|
||
|
||
### 2. 自我评估问题
|
||
|
||
当被要求评估自己产生的工作时，Agent 往往会自信地赞扬工作——即使在人类观察者看来质量明显一般。对于像设计这样的主观任务，这个问题尤其明显。
|
||
|
||
**解决方案**：将执行工作的 Agent 与评判工作的 Agent 分离。调整独立的评估器使其持怀疑态度，比让生成器批评自己的工作要容易得多。
|
||
|
||
## 前端设计：使主观质量可评分
|
||
|
||
受生成对抗网络 (GANs) 的启发，设计了一个带有**生成器**和**评估器** Agent 的多 Agent 结构。
|
||
|
||
### 四个评分标准
|
||
|
||
1. **设计质量**：设计感觉像是一个连贯的整体而不是部分的集合吗？
|
||
2. **原创性**：有自定义决策的证据吗，还是模板布局、库默认值和 AI 生成的模式？
|
||
3. **工艺**：技术执行：排版层次结构、间距一致性、色彩和谐、对比度。
|
||
4. **功能性**：独立于美学的可用性。
|
||
|
||
### 评估器校准
|
||
|
||
使用带有详细分数分解的少样本示例来校准评估器，确保评估器的判断与人类偏好一致，并减少迭代之间的分数漂移。
|
||
|
||
### 迭代循环
|
||
|
||
1. 生成器 Agent 首先根据用户提示创建 HTML/CSS/JS 前端
|
||
2. 评估器使用 Playwright MCP 与实时页面交互
|
||
3. 评估器对每个标准进行评分并编写详细的批评
|
||
4. 反馈流回生成器作为下一次迭代的输入
|
||
5. 每次生成运行 5 到 15 次迭代
|
||
|
||
## 扩展到全栈编码
|
||
|
||
将这种 GAN 启发的模式应用于全栈开发，生成器-评估器循环自然地映射到软件开发生命周期。
|
||
|
||
### 三 Agent 架构
|
||
|
||
**Planner (规划器)**：
|
||
- 将简单的 1-4 句提示扩展为完整的产品规范
|
||
- 被提示要对范围保持雄心勃勃
|
||
- 专注于产品上下文和高级技术设计，而不是详细的技术实现
|
||
- 寻找机会将 AI 功能编织到产品规范中
|
||
|
||
**Generator (生成器)**：
|
||
- 一次从规范中提取一个功能
|
||
- 每个冲刺使用 React、Vite、FastAPI 和 SQLite 堆栈实现应用
|
||
- 被指示在每个冲刺结束时自我评估其工作，然后移交给 QA
|
||
- 有 git 用于版本控制
|
||
|
||
**Evaluator (评估器)**：
|
||
- 使用 Playwright MCP 像用户一样点击运行中的应用
|
||
- 测试 UI 功能、API 端点和数据库状态
|
||
- 根据发现的 bug 和一组标准对每个冲刺进行评分
|
||
- 每个标准都有硬阈值，如果任何一个低于它，冲刺就失败
|
||
|
||
### 冲刺契约
|
||
|
||
在每个冲刺之前，生成器和评估器协商一个**冲刺契约**：在编写任何代码之前，就该工作块的"完成"是什么样子达成一致。
|
||
|
||
## 结果对比
|
||
|
||
### 复古游戏制作器示例
|
||
|
||
| Harness | 时长 | 成本 | 结果 |
|
||
|---------|------|------|------|
|
||
| 单独 Agent | 20 分钟 | $9 | 界面看起来符合预期，但实际游戏坏了，实体不响应输入 |
|
||
| 完整 Harness | 6 小时 | $200 | 16 个功能规范，分布在十个冲刺中，包含精灵动画系统、行为模板、音效和音乐、AI 辅助的精灵生成器和关卡设计器，以及可分享链接的游戏导出 |
|
||
|
||
### 关键发现
|
||
|
||
- 单独运行的输出最初看起来令人印象深刻，但深入研究后问题开始出现
|
||
- Harness 运行的应用立即显示出比单独运行更多的打磨和流畅性
|
||
- 评估器使实现与规范保持一致，契约是细粒度的，评估器的发现足够具体，可以采取行动
|
||
|
||
## 简化 Harness
|
||
|
||
随着模型的改进，值得重新检查 Harness，剥离不再对性能有负载作用的部分，并添加新部分以实现以前不可能的更大能力。
|
||
|
||
### Opus 4.6 的改进
|
||
|
||
- 更仔细地规划
|
||
- 更长时间地维持 Agent 任务
|
||
- 可以在更大的代码库中更可靠地操作
|
||
- 具有更好的代码审查和调试技能来发现自己的错误
|
||
- 长上下文检索方面有了实质性改进
|
||
|
||
### 移除冲刺结构
|
||
|
||
保持规划器和评估器，因为每个都继续增加明显的价值。将评估器移动到运行结束时的单次通过，而不是每个冲刺评分。
|
||
|
||
### DAW 示例结果
|
||
|
||
使用更新的 Harness 生成数字音频工作站 (DAW)：
|
||
|
||
| Agent & Phase | 时长 | 成本 |
|
||
|---------------|------|------|
|
||
| Planner | 4.7 分钟 | $0.46 |
|
||
| Build (Round 1) | 2 小时 7 分钟 | $71.08 |
|
||
| QA (Round 1) | 8.8 分钟 | $3.24 |
|
||
| Build (Round 2) | 1 小时 2 分钟 | $36.89 |
|
||
| QA (Round 2) | 6.8 分钟 | $3.09 |
|
||
| Build (Round 3) | 10.9 分钟 | $5.88 |
|
||
| QA (Round 3) | 9.6 分钟 | $4.06 |
|
||
| **总计 V2 Harness** | **3 小时 50 分钟** | **$124.70** |
|
||
|
||
## 经验教训
|
||
|
||
1. **实验**：与你正在构建的模型一起实验，阅读其在现实问题上的轨迹，并调整其性能以实现你想要的结果
|
||
2. **分解**：在处理更复杂的任务时，有时可以通过分解任务并将专门的 Agent 应用于问题的每个方面来获得提升
|
||
3. **重新检查**：当新模型落地时，通常很好的做法是重新检查 Harness，剥离不再对性能有负载作用的部分，并添加新部分以实现以前不可能的更大能力
|
||
|
||
> 随着模型的改进，有趣的 Harness 组合空间不会缩小。相反，它会移动，而 AI 工程师的有趣工作是继续找到下一个新颖的组合。
|
||
|
||
## 相关研究
|
||
|
||
- [[Harness-Engineering|Harness 工程]]
|
||
- [[Externalization-in-LLM-Agents|LLM Agent 中的外部化]]
|
||
- [[Skill-Systems|技能系统]]
|