随着 AI Agent 能力的增强，开发者开始要求它们承担跨越数小时乃至数天的复杂任务。然而，让 Agent 在多个上下文窗口之间持续稳定地前进，仍然是一个未完全解决的问题。
Anthropic 团队在 2025 年底至 2026 年初发布了三篇重要研究，系统性地探索了这一问题的解决方案。本文档将这三篇研究的核心洞察融合为一套可操作的完整方案。
三篇研究概览
| 编号 | 文章标题 | 核心贡献 |
|---|---|---|
| A | Effective Harnesses for Long-Running Agents（2025.11） | 双 Agent 架构（初始化 + 编码），增量进展与环境管理 |
| B | Long-Running Claude for Scientific Computing（2025.12） | 科学计算场景，RALPH 循环，持久记忆与基准验证 |
| C | Harness Design for Long-Running App Development（2026.03） | 三 Agent 架构（规划 + 生成 + 评估），GAN 灵感的迭代式质量提升 |
核心问题
Agent 必须在离散的会话中工作，而每个新会话开始时都没有之前的记忆。想象一个轮班制的软件项目，每个新上班的工程师对前一班发生的事情毫无记忆。这就是长时间运行 Agent 的核心挑战。
Anthropic 的研究归纳出四种典型失败模式：
- 一次性完成倾向（One-shotting）：Agent 试图一次做太多事情，在实现中途耗尽上下文，留下半完成的功能。
- 过早宣布完成（Premature completion）：Agent 看到已有进展就宣布任务结束。
- 测试不充分（Insufficient testing）：Agent 在没有端到端验证的情况下将功能标记为完成。
- 上下文焦虑（Context anxiety）：Agent 接近上下文窗口限制时开始草率收尾，即使任务远未完成。
总体架构设计
综合三篇研究，最完整的方案是一个三 Agent 架构（文章 C 的最终形态），并融入文章 A 的环境管理和文章 B 的持久记忆机制。三个 Agent 分别是：
| Agent | 角色 | 职责 |
|---|---|---|
| Planner | 规划者 | 将简短的用户 prompt 扩展为完整的产品规格和功能列表，初始化项目环境 |
| Generator | 生成者/编码者 | 每次只做一个功能，增量推进项目，保持环境干净可交付 |
| Evaluator | 评估者/QA | 独立审查工作成果，用浏览器自动化做端到端测试，反馈具体问题 |
架构的核心原则：“找到最简单的可行方案，只在必要时增加复杂度”（Find the simplest solution possible, and only increase complexity when needed）。每个组件都编码了一个关于”模型自己做不到什么”的假设。随着模型升级，应定期重新审视这些假设，移除不再必要的脚手架。
Planner Agent：规划与初始化
Planner 是整个流水线的起点。它接收用户的简短 prompt（通常 1-4 句话），输出一套完整的项目基础设施。
Planner 的产出物
A. 产品规格文档
Planner 将简短的 prompt 扩展为完整的产品规格。例如，“构建一个 2D 复古游戏制作器”被扩展为 16 个功能模块、横跨 10 个开发冲刺的完整规格。关键原则：专注产品上下文和高层技术设计，不要指定颗粒化的技术实现细节——如果规划者在前期指定了错误的细节，错误会级联到下游实现。
B. 功能列表文件（feature_list.json）
这是文章 A 的核心发现。将所有功能分解为结构化的 JSON 条目，每个功能初始标记为 "passes": false。使用 JSON 而非 Markdown，因为模型不太可能不当地修改 JSON 文件。在 claude.ai 克隆案例中，这产生了超过 200 个功能条目。示例结构：
{
"category": "functional",
"description": "新建聊天按钮创建新对话",
"steps": ["导航到主界面", "点击新建聊天按钮", "验证新对话已创建"],
"passes": false
}
C. 初始化脚本与环境
- init.sh：启动开发服务器的脚本，节省后续 Agent 每次自己探测的 token 开销。
- claude-progress.txt：进度日志文件，记录每个 Agent 会话的工作内容。
- CHANGELOG.md（来自文章 B）：记录进度、失败路径和精度节点，避免重复试错。
- CLAUDE.md（来自文章 B）：设定目标和设计原则，允许 Agent 动态更新。
- 初始 Git 提交：建立版本控制基线。
关键设计决策
范围雄心与实现克制的平衡：Planner 应被提示”对范围要雄心勃勃”，但只关注交付物而非实现路径，让下游 Agent 自行决定技术方案。文章 C 特别指出，可以要求 Planner 主动寻找将 AI 功能织入产品的机会。
Generator Agent：增量编码与状态管理
核心原则：每次只做一个功能
这是三篇文章共同强调的最重要原则。不要让 Agent 一次性实现整个应用。每个会话的 Agent 被要求：从功能列表中选择一个未完成的高优先级功能，完整实现并测试，然后留下干净的环境状态。
会话启动流程
Agent 启动时应执行固定的”获取方向感”流程：
pwd— 确认工作目录- 读取
claude-progress.txt和git log --oneline -20— 了解最近工作 - 读取
feature_list.json— 选择下一个要做的功能 - 运行
init.sh启动开发服务器 - 基线测试 — 用浏览器自动化工具验证现有功能正常，确认不是在坏的状态上开始工作
会话结束流程
Agent 完成后必须留下”干净状态”，即适合合并到主分支的代码：没有重大 bug、代码整洁有文档、开发者可以直接开始新功能。
- Git 提交：用描述性的 commit message 提交进度。这也允许模型用 git revert 回滚坏的代码变更。
- 更新进度文件：在
claude-progress.txt中写入本次会话的工作摘要。 - 更新功能状态：只允许修改
passes字段。使用强硬指令：“移除或编辑测试是不可接受的”。
上下文窗口管理策略
三篇文章提出了两种不同的上下文管理策略，适用于不同场景：
| 策略 | Compaction（上下文压缩） | Context Reset（上下文重置） |
|---|---|---|
| 原理 | 总结早期对话，同一 Agent 继续工作 | 完全清空上下文，启动新 Agent + 结构化交接 |
| 优势 | 保持连续性，编排简单 | 提供干净的”白板”，彻底解决 context anxiety |
| 劣势 | 无法解决 context anxiety | 增加编排复杂度和 token 开销 |
| 适用场景 | 能力强的模型（如 Opus 4.6） | 较弱模型或任务特别复杂时 |
文章 C 的关键发现：在 Opus 4.5 上，context anxiety 严重到必须使用 context reset；而 Opus 4.6 大幅消除了这一行为，可以仅依赖 compaction。这体现了一个核心原则：随模型升级重新审视脚手架的必要性。
RALPH 循环（来自文章 B）
对于需要长时间连续运行的场景，文章 B 提出了 RALPH 循环（Ralph Wiggum 方法）：一种编排模式，通过钩子或脚本反复确认任务状态，克服 Agent 提前终止的倾向。实现方式是在 HPC 集群的 tmux 后台驻留运行，通过 Git 频繁提交实现进度追踪与故障恢复。
Evaluator Agent：独立评估与质量把控
为什么需要独立的评估者
文章 C 的核心发现：当要求 Agent 评估自己的工作时，它们倾向于自信地赞扬自己的工作——即使对人类观察者而言质量明显平庸。调整一个独立的评估者让它持怀疑态度，比让生成者自我批评要容易得多。
评估标准设计
文章 C 为前端设计场景制定了四个评分维度，这个框架可以扩展到其他领域：
| 维度 | 权重 | 含义 |
|---|---|---|
| 设计质量 | 高 | 设计是否作为一个连贯的整体而非零散部件的拼凑？颜色、排版、图片等细节是否共同创造了独特的氛围和身份认同？ |
| 原创性 | 高 | 是否有自定义的设计决策？还是模板布局、库默认值和 AI 生成的典型模式（如紫色渐变+白卡片）？ |
| 工艺 | 标准 | 技术执行质量：排版层级、间距一致性、色彩和谐、对比度。大多数合理实现默认就能做好。 |
| 功能性 | 标准 | 与美学无关的可用性。用户能否理解界面功能、找到主要操作、完成任务？ |
评估工作流
Evaluator 的最佳实践：
- 使用浏览器自动化（Playwright / Puppeteer MCP）：Evaluator 应实际导航、点击、截图，像真实用户一样测试，而不是仅评分静态截图。
- Sprint Contract（冲刺合同）：在每个功能开发前，Generator 和 Evaluator 协商”完成标准”，商定要测试的具体行为。
- 硬阈值机制：每个评分维度设定硬性阈值，任一维度低于阈值则冲刺失败，并提供具体反馈。
- Few-shot 校准：用带详细评分的示例校准 Evaluator 的判断标准，减少评分漂移。
- 过度宽容的调教：文章 C 指出，默认的 Claude 是很差的 QA——它会发现问题但又说服自己这不是大问题。需要多轮读日志、找到判断偏差、更新 prompt 的循环。
评估者的动态价值
文章 C 的重要洞察：Evaluator 不是一个”要或不要”的固定决策。它的价值取决于任务是否处于当前模型能力的边界。当模型升级后，之前需要 Evaluator 才能做好的任务可能已经在模型能力范围内，Evaluator 变成了不必要的开销。但对于仍在边界的任务，Evaluator 继续提供真实的提升。
持久记忆与状态传递
这是三篇文章的另一个共同主题：如何让新 Agent 快速接手工作。综合各文章的方法，完整的状态传递体系包含：
| 状态载体 | 内容 | 来源 |
|---|---|---|
| feature_list.json | 所有功能及其完成状态 | 文章 A：核心设计 |
| claude-progress.txt | 每次会话的工作摘要 | 文章 A：会话间交接 |
| CHANGELOG.md | 进度、失败路径、精度节点 | 文章 B：科学计算场景 |
| CLAUDE.md | 目标、设计原则、全局规则 | 文章 B：科学计算场景 |
| Git 历史 | 代码变更的完整时间线 | 三篇共同强调 |
| 文件通信 | Agent 间通过读写文件交换信息 | 文章 C：多 Agent 协作 |
文件通信的重要性：文章 C 的多 Agent 架构中，Generator 和 Evaluator 之间的通信完全通过文件完成——一个 Agent 写文件，另一个读取并在同一文件或新文件中响应。这种模式简单耐用，避免了复杂的 Agent 间通信协议。
测试与验证体系
多层测试策略
综合三篇文章的测试方法，完整的测试体系应包含以下层次：
A. 基线测试（每次会话开始时） 启动开发服务器，运行基本的端到端流程（如新建聊天、发消息、收到回复），确保不是在坏的状态上工作。
B. 功能验证（每个功能完成后） 使用**浏览器自动化工具（Playwright / Puppeteer MCP）**做端到端测试，像人类用户一样操作。文章 A 指出，提供这类测试工具”大幅提升了性能，Agent 能够识别和修复仅从代码中看不出的 bug”。
C. 基准验证（来自文章 B） 对于科学计算等有明确正确答案的场景，依赖现有参考代码作为”测试预言机”，构建并持续运行单元测试以量化进展。
已知限制
文章 A 和 C 都诚实地指出了当前测试的局限性：
- Claude 无法通过 Puppeteer MCP 看到浏览器原生的 alert 弹窗，依赖这类弹窗的功能更容易出 bug。
- Claude 无法实际”听见”音频，这让音乐应用的 QA 反馈循环在”音乐品味”方面不够有效。 -深层嵌套的功能和边缘用例，Evaluator 不一定会充分探索。
实施路线图
阶段一：最小可行方案（双 Agent）
如果任务相对简单或模型能力足够强，从文章 A 的双 Agent 架构开始：
- Initializer Agent：生成 feature_list.json、init.sh、进度文件、初始 Git 提交。
- Coding Agent：每次会话做一个功能，包含自验、提交、更新进度。
成本参考：Solo 单 Agent ≈ $9 / 20分钟，双 Agent 效果已显著优于基线。
阶段二：完整方案（三 Agent）
当任务复杂度增加或质量要求提高时，升级为文章 C 的三 Agent 架构：
- Planner：扩展 prompt 为完整规格。
- Generator：增量实现功能，每轮结束后交给 Evaluator。
- Evaluator：独立评估，用浏览器自动化测试，不达标则打回并提供反馈。
成本参考：复古游戏制作器 ≈ $200 / 6小时；DAW 音乐工作站 ≈ $125 / 4小时。
阶段三：持续简化
文章 C 的核心经验：每当新模型发布时，应重新审视整个 harness，移除不再必要的组件。例如，从 Opus 4.5 升级到 Opus 4.6 后：
- Sprint 结构被移除（模型已经可以原生处理连贯的长时间工作）
- Context reset 被移除（context anxiety 已大幅消除）
- Evaluator 从每 Sprint 审查变为整体结束时单次审查
关键设计规则总结
以下是从三篇文章中提炼的最重要的设计规则：
规则 1：增量而非一次性
每次只做一个功能，完整实现并验证后再进入下一个。这是所有文章最一致的经验。
规则 2：结构化状态优于自由文本
用 JSON 而非 Markdown 跟踪功能状态，用 Git 而非口头描述跟踪代码变更。结构化数据更难被模型意外修改。
规则 3：分离生成和评估
不要让同一个 Agent 既做开发又做 QA。独立的 Evaluator 更容易被调教为严格、怀疑的态度。
规则 4：像真实用户一样测试
单元测试和 curl 命令不够。必须用浏览器自动化工具像人类用户一样交互、截图、验证。
规则 5：先确认基线再开新功能
每次会话开始时，先运行基线测试确认现有功能正常。如果在坏的状态上开始新功能，问题只会更严重。
规则 6：强制保护功能列表
使用强硬指令（“移除或编辑测试是不可接受的”）防止 Agent 通过删除测试来”通过”检查。
规则 7：记录失败而不仅记录成功
来自文章 B 的关键洞察：CHANGELOG 应该记录失败路径，避免后续 Agent 重复相同的试错。
规则 8：随模型升级简化脚手架
每个组件都编码了一个”模型自己做不到什么”的假设。新模型发布时，应逐个移除组件并审查影响，保持 harness 的精简。文章 C 的金句：“有趣的 harness 组合空间不会随模型提升而缩小，而是移动。”
适用场景与局限性
最佳适用场景
- 全栈 Web 应用开发：三篇文章的主要验证场景，效果最为成熟。
- 科学计算与数值求解器：文章 B 的核心场景，适合”范围明确、成功标准可量化”的任务。
- 遗留代码现代化：如旧版 Fortran 代码的迁移，有明确的参考基准可对比。
- 复杂前端设计迭代：文章 C 的 GAN 灵感迭代循环特别适合。
当前局限性
- 主观质量判断（如音乐品味、视觉美感）仍有边界。
- 浏览器自动化工具无法覆盖所有 UI 场景（如原生弹窗）。
- 成本较高（完整 harness 单次运行 $125-$200），适合有明确 ROI 的项目。
- 深层功能和边缘用例的测试覆盖仍有提升空间。
参考文献
- Justin Young. “Effective Harnesses for Long-Running Agents.” Anthropic Engineering Blog, November 2025.
- Siddharth Mishra-Sharma. “Long-Running Claude for Scientific Computing.” Anthropic Research, December 2025.
- Prithvi Rajasekaran. “Harness Design for Long-Running Application Development.” Anthropic Engineering Blog, March 2026.