Long-Running Agent Harness
What it is
长时运行 Agent Harness 是让 AI Agent 连续运行数小时甚至数天而不跑偏的工程架构。核心挑战不是模型能力，而是上下文管理、规划能力和自我判断的系统性保障。
来自 Anthropic 应用 AI 团队（Ash Prabaker & Andrew Wilson）的 AI Engineer Summit 2025 分享。
Why it matters
当 Agent 从"完成几分钟小任务"扩展到"构建完整应用、调试复杂系统、持续自我推进"时，单会话的上下文窗口和简单循环已不够用。需要专门的 harness 架构来保障：
- 状态不丢失（检查点、压缩、恢复）
- 计划不漂移（planner 角色分离）
- 完成标准客观（evaluator 对抗验证）
Three Core Problems
| 难题 | 表现 | 解决方向 |
|---|---|---|
| 上下文管理 | 跑久了忘记前面在做什么 | 检查点、压缩、新 context window |
| 规划能力 | 多步骤任务中计划漂移 | 将 planner 拆分为独立角色 |
| 自我判断 | 不知道什么时候算"完成" | 用 evaluator 替代自我评估 |
Evolution of Claude Code (Andrew's Timeline)
| 阶段 | 关键能力 |
|---|---|
| 早期 2024 | 模型只能跑 20 分钟 |
| Artifacts / Computer Use / MCP / Skills | 产物预览、电脑操作、工具协议、技能复用 |
| 检查点 / Agent teams / 服务端压缩 | 状态保存、多 Agent 协作、百万上下文 |
| Opus 4 / Sonnet 4 | 上下文管理和任务完成能力提升 |
| Ralph loop | "确定性地差"的循环设计 |
| Claude Code 2.0 | 检查点、压缩、更强上下文意识 |
| Haiku / Opus 4.5 | 子 Agent 变便宜，规划与执行可以拆分 |
| Opus 4.6 / Sonnet 4.6 | 更 agentic 的模型与 Agent teams |
核心原则："能以可预测的方式失败，比以不可预测的方式成功更好。"
First-Gen Long-Running Harness
从模糊 prompt 到持久化产物：
- 输入：一句模糊的 feature 描述
- 输出：feature list、progress 记录、git repo
- 每轮循环：新上下文 → 冒烟测试 → 实现 → 验证 → 提交
New Harness Architecture: Role Separation (Ash)
Core Insight
"前沿并不会真的缩小，它只是会移动。"
模型变强后，harness 不会消失，而是会演化。
Generator + Evaluator Pattern (GAN-inspired)
| 角色 | 职责 |
|---|---|
| Generator（生成器） | 负责构建 |
| Evaluator（评估器） | 负责批评 |
为什么不要让 Agent 自己审查自己：
- 模型自我评估时过于宽容
- 有"迎合倾向"（sycophancy）
- 容易过早宣布完成
如何设计"严格的批评者"：
- 把品味变成可评分标准
- 用 Playwright 打开真实页面、点击、截图、测试
- 把具体批评交回给生成器
Frontend Quality Dimensions
- 设计（Design）
- 原创性（Originality）
- 工艺感（Craftsmanship）
- 功能性（Functionality）
Three-Layer Architecture
Planner（规划者）→ Generator（生成器）→ Evaluator（评估器）
Contract（契约）—— Key Innovation
- Generator 和 Evaluator 先协商"什么叫完成"
- 形成具体的、可验证的标准
- 这是 Ralph loop 缺少的关键创新
Case Study: Retro Forge (Retro Game Maker)
Without Harness
- 看起来能用，但实际玩不了
- 路由顺序错误、删除逻辑 bug、生产环境 bug
With Harness
- 项目对话框、Sprite 编辑器、AI 关卡助手
- Evaluator 真正玩游戏：方向键、碰撞、HUD、物理循环都被测试
27 Contract Standards
"标准模糊，批评就会模糊。generator 只会耸耸肩，然后随便改点东西。"
- 标准具体 → 批评可执行 → generator 知道怎么修复
- 标准模糊 → 批评模糊 → generator 耸耸肩随便改
Debugging Craft: Read Traces
Ash 多次强调：
- 没有神秘秘诀
- 一行一行看模型为什么这么判断
- 哪里和人类预期不一致
- 把这些发现写回 prompt、CLAUDE.md 或 skill
"只有这样，你才真正知道 scaffold 里哪些部分该删，哪些部分该留。"
Leave Breadcrumbs for Future Agents
如果 Agent 生成的应用未来还要继续维护：
- JSON 状态文件
- 时间戳日志
- bug 记录、修复记录
- 文件结构说明
"你等于给另一个模型留下了一串面包屑，让它之后能接着往下看。"
Key Quotes
- "能以可预测的方式失败，比以不可预测的方式成功更好。"
- "前沿并不会真的缩小，它只是会移动。"
- "把一个独立的批评者调得更严格，其实是很可行的；但把一个构建者调成有自我批评能力，就没那么容易。"
- "标准模糊，批评就会模糊。"
- "如果你对东西应该长什么样有明确看法，那就逼自己把它写下来。"
- "只有这样，你才真正知道 scaffold 里哪些部分该删，哪些部分该留。"
- "你等于给另一个模型留下了一串面包屑，让它之后能接着往下看。"
Evidence across sources
| Source | Key Claim | Relevance |
|---|---|---|
| 诗梳风 EP577 | Anthropic 内部长时运行 harness 的三层架构（planner-generator-evaluator）+ contract 机制 | 官方团队一手实践，生产级案例验证 |
| 诗梳风 EP577 | Retro Forge 案例：27 条 contract 标准 + evaluator 真玩游戏 | 具体展示对抗验证如何解决"看起来能用实际玩不了"问题 |
| Voxyz_ai 动态工作流分析 | 6 大模式 + 10 用例 + 3 大故障模式 | 与长时运行 harness 形成互补：前者关注编排模式，后者关注角色分离 |
| Thariq 动态工作流 | classify-act / fan-out-synthesize / adversarial-verify 等模式 | 可与 planner-generator-evaluator 组合使用 |
Related
- Ralph Harness Framework
- Multi-Agent Coordination
- Self-Verification Loops
- Agent Harness Worker Model
- Dynamic Workflows
- Managed Agents Architecture
Open Questions
- Contract 标准如何自动演化？人工维护 27 条标准是否可持续？
- Evaluator 的"品味"如何跨项目迁移？是否需要 few-shot 示例库？
- Planner-Generator-Evaluator 三层架构的 token 成本如何优化？
- "面包屑"记录的标准格式是什么？是否需要跨 harness 兼容？