Anthropic — 时间 Scalability（长程运行）
核心问题
当任务大到无法在单个上下文窗口中完成时，会发生什么？
两类失败模式
- 试图一次做太多事情 — agent 在不完成任何功能的情况下开始实现一个又一个功能，耗尽上下文窗口
- 断定工作已经完成 — 看到已有进展，便宣布胜利并停止工作
根源：agent 对项目状态没有持久的、结构化的理解，这种理解无法跨越上下文窗口边界。
双 Agent 架构
初始化 Agent（首次会话）
产出三个关键输出：
init.sh— 可靠启动开发环境的脚本- 功能列表文件（JSON 格式）— 超过 200 个具体的端到端功能描述，每个初始标记为
passes: false claude-progress.txt+ 初始 git commit
为什么用 JSON 而非 Markdown？模型不太可能不恰当地修改 JSON 文件。JSON 的严密结构能抵御随意的编辑。
编码 Agent（后续每次会话）
- 一次只处理一个功能
- 保持环境状态干净
- 会话结束前更新进度文件和 git 历史
启动序列（每次会话开始）
pwd确认工作目录- 读取进度文件和 git 日志
- 读取功能列表，选择优先级最高的未完成功能
- 运行
init.sh - 运行基础端到端测试验证应用状态
三角色架构（Anthropic 最新）
Planner + Generator + Evaluator
- Planner：把一句话需求扩展成完整 spec，只做产品层面设计
- Generator：按 spec 实现功能
- Evaluator：用 Playwright 操作真实运行的应用验证产出，与 Generator 之间没有共享内部状态
Evaluator 的独立性是它能纠偏的前提。
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 是自我验证的核心
- 上下文管理 — 上下文管理