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.
原文：Harness Design for Long-Running Application Development 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 开始赶工、跳过步骤、或者质量下降时，不要试图”提醒”它——直接开一个新会话，把当前进度和剩余任务作为新的输入传进去。
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 直接跑 | 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 变成开销 ║ ← 任务在模型能力范围内
│ ║ 增加时间但无收益 ║
│ ╚═══════════════════╝
└──────────────────────▶ 模型能力
怎么判断该加还是该减复杂度？
问自己这三个问题：
1. 这个组件要解决的模型缺陷，现在还存在吗？
→ 不存在 → 移除
2. 移除后质量会下降吗？
→ 做对照实验验证
3. 当前任务的难度超出模型的舒适区了吗？
→ 超出 → 保留/增加 QA
→ 没超出 → 简化
五、实战启示：这些原则怎么用在日常
你不需要搭建完整的三 Agent 系统才能从这篇文章中获益。以下是可以直接应用的原则：
原则 1：大任务用 Context Reset 而非长对话
❌ 在一个会话里干所有事，越到后面越糊涂
✅ 拆成多个会话，每个会话开头显式传入上下文和目标
原则 2：生成和评估分开做
❌ "帮我写完这个组件，顺便检查一下有没有问题"
✅ 先让 Agent 写完 → 新开一轮/用子 Agent 专门审查
requesting-code-review skill 是同一个思路——让不同的 Agent 实例来评估，避免自我偏差。
原则 3：先定义”完成”再开始
❌ "帮我实现用户系统"
✅ "帮我实现用户系统，完成标准：
1. 注册/登录流程能跑通
2. 密码用 bcrypt 加密
3. 有基本的输入校验
暂不需要：OAuth、邮箱验证、权限角色"
原则 4：定期质疑你的工作流复杂度
每隔一段时间问自己：
- 我的
CLAUDE.md 里有没有因为模型已经改进而不再需要的规则？
- 我是不是在用旧模型的经验来限制新模型？
- 哪些”必须”的步骤其实可以去掉了？
“有趣的 Harness 组合空间不会随着模型改进而缩小——它会移动。AI 工程师的有趣工作，就是不断发现下一个新的组合。“
原则 5：用审美暗示词提升设计质量
当需要 AI 生成前端设计时，在 prompt 中加入风格锚点：
| 暗示词 | 引导方向 |
|---|
| ”museum quality” | 精致、沉浸式、艺术感 |
| ”editorial” | 排版驱动、杂志风 |
| ”brutalist” | 粗犷、反传统、强视觉冲击 |
| ”craft beer label” | 手工感、细节丰富 |
六、与相关文章的关系
这篇文章和 Agentic Engineering 的层级体系（见 Agentic Engineering 的 8 个层级）有直接对应：
| 层级 | 概念 | 本文对应内容 |
|---|
| 第 3 层 | 上下文工程 | Context Reset vs Compaction |
| 第 6 层 | Harness 工程 | 三 Agent 架构、Sprint 合约、Playwright 测试 |
| 第 7 层 | 后台 Agent | Generator-Evaluator 分离、条件式 QA |
工程纪律（Superpowers）→ 多 Agent 协作（Harness）→ 自主团队（第 8 层）
约束单个 Agent 突破单 Agent 天花板 Agent 间自主协调
