Anthropic — 时间 Scalability（长程运行）
核心问题
当任务大到无法在单个上下文窗口中完成时，会发生什么？
两类失败模式
- 试图一次做太多事情 — agent 在不完成任何功能的情况下开始实现一个又一个功能，耗尽上下文窗口
- 断定工作已经完成 — 看到已有进展，便宣布胜利并停止工作
根源：agent 对项目状态没有持久的、结构化的理解，这种理解无法跨越上下文窗口边界。
双 Agent 架构
来源：Addy Osmani — Long-running Agents
初始化 Agent（首次会话）
产出三个关键输出：
init.sh— 可靠启动开发环境的脚本- 功能列表文件（
feature-list.json）— 结构化 spec，每个功能标记passes: false claude-progress.txt+ 初始 git commit
为什么用 JSON 而非 Markdown？模型不太可能不恰当地修改 JSON 文件。JSON 的严密结构能抵御随意的编辑。
编码 Agent（后续每次会话）
- 一次只处理一个功能
- 保持环境状态干净
- 会话结束前更新进度文件和 git 历史
启动序列（每次会话开始）
pwd确认工作目录- 读取进度文件和 git 日志
- 读取功能列表，选择优先级最高的未完成功能
- 运行
init.sh - 运行基础端到端测试验证应用状态
Test Ratchet（防退化机制）
Anthropic harness 中的关键 prompt 约束：
"it is unacceptable to remove or edit tests because this could lead to missing or buggy functionality"
这是为了防止 agent 最常见的失败模式之一：删除失败的测试来"让它们通过"。InfoQ 的 writeup 将这一架构扩展为 planner + generator + evaluator 三角色。
三角色架构（Anthropic 最新）
Planner + Generator + Evaluator
- Planner：把一句话需求扩展成完整 spec，只做产品层面设计
- Generator：按 spec 实现功能
- Evaluator：用 Playwright 操作真实运行的应用验证产出，与 Generator 之间没有共享内部状态
Evaluator 的独立性是它能纠偏的前提。
Project Vend：长时间运行的公开实验
Anthropic 的 Project Vend 让 Claude 实例实际运营一家自动售货机业务一个月，管理库存、定价、与供应商沟通。
- 第一阶段：以 informative 的方式失败
- 第二阶段：运行得好得多
- 目的不是盈利，而是观察 agent 在跨越周而非轮次维持身份时会出现什么 coherence 问题
这与生产环境中所有长时间运行 agent 团队现在遇到的问题相同。
Scientific Computing 简化栈
Anthropic 的 long-running Claude post 将上述架构简化为科研场景的最小实现：
| 组件 | 文件/工具 | 作用 |
|---|---|---|
| 活计划 | CLAUDE.md |
agent 随学习编辑的 living plan |
| 实验笔记 | CHANGELOG.md |
可移植的 lab notes |
| 执行层 | tmux + SLURM + git | 执行与协调 |
| 防提前停止 | Ralph loop | for 循环在 agent 声称完成时踢它回去 |
旗舰案例：Claude Opus 4.6 用几天时间构建的 Boltzmann solver，达到与参考 CLASS 实现 sub-percent 一致的水平——压缩了原本需要数月到数年的研究者时间。
Context Reset & Compaction
长时间任务中，summarization-as-compaction 对 very long jobs 不够。Anthropic 明确需要 full context resets：harness 撕毁 session，从结构化 handoff 文件重建。这本质上是"如何给新工程师做 onboarding"的自动化版本。
Harness 组件的生命周期
每个 harness 组件都是对当前模型能力边界的一个假设。随着模型迭代，假设会过期：
- Sonnet 4.5 → Opus 4.5 → Opus 4.6：context reset 先被淘汰，sprint 分解随后被淘汰，evaluator 仍然有价值
正确做法：逐一移除旧组件、测试质量是否真的下降，而不是继续叠加新组件。
关联
- harness-engineering/overview — Harness Engineering 总览
- harness-engineering/three-scaling-dimensions — 三个 Scaling 维度
- harness-engineering/self-verification-loops — Evaluator 是自我验证的核心
- 上下文管理 — 上下文管理