Anthropic 长周期 Agent Harness 设计Anthropic 长周期 Agent Harness 设计Anthropic 长周期 Agent Harness 设计

❝

文章来源

• ▸Harness design for long-running application development (2026-03-24, Prithvi Rajasekaran)
• ▸Effective harnesses for long-running agents (2025-11-26, Justin Young)

这两篇文章是同一研究线的两个里程碑：

演进主线：从解决"Agent 能不能持续干活"（第一篇），到解决"Agent 能不能干好活"（第二篇）。第二篇在第一篇的基础设施上增加了评估闭环，形成了从"能用"到"好用"的跨越。

当 Agent 被要求在数小时甚至数天的时间里构建完整 Web 应用时，存在四个典型失败模式：

只在第一轮运行，职责是搭脚手架：

关键设计决策：用 JSON 而非 Markdown 编写功能清单，因为实验发现模型更不容易误改 JSON 文件的结构。

每轮 session 运行一个实例，遵循固定流程：

每轮 Agent 的启动协议（减少 token 浪费的关键）：

1. ▸pwd 确认工作目录
2. ▸读 claude-progress.txt 和 git log 了解进度
3. ▸读 feature_list.json 选择下一个功能
4. ▸运行 init.sh 启动服务
5. ▸用浏览器自动化工具验证基础功能

1. ▸增量开发是必要的：让 Agent 一次只做一件事，避免上下文耗尽
2. ▸交接质量决定连续性：结构化文件 + git 历史 = 新 Agent 的"记忆"
3. ▸测试工具改变行为：给 Agent 浏览器自动化能力（Puppeteer MCP）后，它能发现仅看代码无法识别的 bug
4. ▸格式选择很重要：JSON 比 Markdown 更稳定，模型不太会误改结构

• ▸Vision 和浏览器自动化仍有盲区（如无法通过 Puppeteer 看到浏览器原生 alert modal）
• ▸单一通用 Agent vs 多专业 Agent 的优劣尚不明确
• ▸仅针对全栈 Web 开发验证，其他领域待探索

第二篇从两个具体失败模式出发：

Agent 在上下文窗口填充时会过早收工，或在 compaction 后仍然残留焦虑感。

解决方案对比：

关键发现：Opus 4.6 大幅缓解了 context anxiety，可以在第二篇的后半部分完全去掉 context reset。

Agent 对自己产出的代码会过度自信——即使质量明显平庸也会给出好评。这在主观任务（如设计）中尤其严重，因为缺乏二元判定标准（如测试通过/失败）。

解决方案：Generator 和 Evaluator 分离——但这本身不够，还需要调教 Evaluator 保持怀疑态度。

灵感来自生成对抗网络（GAN），核心思想是Generator 和 Evaluator 对抗迭代。

四维评分标准（按权重排序）：

关键洞察：加权标准本身就驱动了模型行为改变——即使没有 Evaluator 反馈，第一轮产出就比 baseline 明显更好。

典型案例：荷兰艺术博物馆网站在第 10 轮时，Agent 彻底推翻原有设计，用 CSS perspective 构建了一个 3D 画廊空间（带棋盘格地板、墙面挂画、门口导航），这是单轮生成从未见过的创意跃迁。

Sprint Contract 机制：

这是第二篇最重要的创新之一。Generator 提出"我要做什么 + 如何验证"，Evaluator 审查"这是否是正确的东西"。双方迭代直到达成一致，然后 Generator 按合同实现。

┌─────────────────────────────────────────────────┐
│              Sprint Contract（示例片段）            │
├─────────────────────────────────────────────────┤
│ 功能: Level Editor - 矩形填充工具                  │
│ 验收标准:                                        │
│ 1. Rectangle fill tool allows click-drag to fill │
│    a rectangular area with selected tile         │
│ 2. User can select and delete placed entity      │
│    spawn points                                  │
│ 3. 27 条具体标准覆盖整个 Level Editor              │
└─────────────────────────────────────────────────┘

Evaluator 发现的具体 bug 示例：

使用 Opus 4.6 升级后的简化架构：

关键变化：Opus 4.6 的 Builder 可以连续运行 2+ 小时不需要 sprint 分解，大幅减少了上下文重置的开销。

第二篇的下半部分记录了一个重要的工程实践：系统地精简 harness。

核心方法论：

1. ▸每次移除一个组件，观察对最终结果的影响
2. ▸每个 harness 组件都编码了一个关于"模型不能做什么"的假设
3. ▸这些假设可能不正确，也可能因模型升级而过时
4. ▸新模型发布后，必须重新审视 harness，去掉不再必需的组件

Evaluator 的经济学：

❝

Evaluator 不是固定的"有"或"无"。当任务超出当前模型 solo 可靠完成的边界时，它才值得花费成本。

第一层：执行连续性失败
  ├── 一次做太多 → context 耗尽
  ├── 过早宣布完成 → 缺少全局 checklist
  └── 环境不干净 → 缺少交接协议

第二层：质量产出失败
  ├── 自我评估偏差 → Generator/Evaluator 必须分离
  ├── 主观任务无标准 → 评分标准必须可操作化
  └── 测试不够深 → 必须用真实用户工具（Playwright/Puppeteer）

这个 22x 的成本差异揭示了一个现实：质量提升的本质是用 token 换迭代。每一轮 Evaluator 反馈都是一次额外的 token 消耗，但正是这些迭代把"能跑的代码"变成"好用的产品"。

• ▸ 分解任务：一次只做一件事，避免 context 耗尽
• ▸ 结构化交接：用 JSON/Markdown 文件 + git 记录进度
• ▸ 分离评估：Generator 和 Evaluator 必须是不同 Agent 实例
• ▸ 真实测试：用 Playwright/Puppeteer 等工具端到端验证
• ▸ 可回退：每个里程碑都要有干净的 git commit
• ▸ 定期精简：模型升级后重新评估 harness 组件的必要性

任务复杂度 ───────────────────────────────────────────►

简单任务          中等任务              复杂全栈应用
  │                 │                      │
  ▼                 ▼                      ▼
单 Agent         单 Agent              Planner + Generator
+ Compaction     + 交接文件            + Evaluator（条件性）
                                     连续运行，不需 sprint

❝

每个 harness 组件都编码了一个关于模型不能做什么的假设。这些假设值得被压力测试——因为它们可能不正确，也可能很快过时。

这条原则是两篇文章最核心的方法论提炼。它要求 Agent 工程师：

1. ▸用真实问题的 trace 来调优性能
2. ▸新模型发布后立即重新评估 harness
3. ▸去掉不再 load-bearing 的组件
4. ▸找到下一个 novel combination