Anthropic 面向长时间运行代理的有效框架

随着 AI 代理被赋予跨越数小时或数天的复杂项目任务，Anthropic 引入了一个双管齐下的解决方案——一个初始化代理和一个编码代理——以确保代理在多个独立的上下文窗口中保持一致的进展。

该框架解决了核心挑战，即代理必须在没有先前工作记忆的会话中工作，而对于大规模软件开发，简单的上下文压缩无法克服这一限制。

长时间运行代理的挑战

简单的上下文压缩不足以让 AI 代理在多个上下文窗口中完成生产级质量的项目。Claude Agent SDK，即使使用像 Opus 4.5 这样的先进模型，在仅给出高层提示时，也会表现出两种主要的失败模式。

代理失败模式 1：过度规划

代理倾向于一次尝试完成过多工作，旨在一次性实现。这通常导致模型在实现过程中耗尽上下文，使得下一个会话从一个半实现且无文档记录的功能开始。随后的代理必须花费大量时间猜测先前的状态，并尝试恢复基本功能。

代理失败模式 2：过早完成

在项目的后期，一个代理实例可能会审查现有的进展，并过早地宣布整个工作完成，即使重要功能仍未完成。

这些失败需要一种结构化的方法：首先，为所有必需功能建立一个基础环境；其次，提示每个代理进行小而渐进的进展，同时在每个会话结束时保持一个干净、可合并的状态。

双管齐下的代理解决方案

Anthropic 通过实现一个专门的两部分框架结构来解决这些问题：

初始化代理

第一个代理会话使用专门的提示来设置初始环境。此设置包括创建一个 init.sh 脚本，生成一个 claude-progress.txt 文件来记录代理操作，并执行一次初始的 git 提交以记录添加的文件。这个基础确保代理被设置为逐步、按功能地工作。

编码代理

每个后续会话由编码代理处理，其任务是朝着目标取得渐进进展。至关重要的是，该代理必须在每个会话后保持环境处于干净状态。“干净状态”意味着代码有序、文档完善且没有重大错误，适合合并到主分支。

环境管理与工作流细节

为了强制结构并防止代理进行大规模、不受管理的更改，采用了特定的提示和工件管理技术。

定义功能需求

为了对抗一次性实现应用的倾向，初始化代理被提示编写一个全面的功能需求文件，该文件扩展了用户的初始提示。对于 claude.ai 克隆示例，这产生了超过 200 个功能，所有功能最初都标记为“失败”。编码代理随后被指示仅通过更改 passes 字段的状态来编辑此功能文件，使用 JSON 格式以最小化不当覆盖的风险。

确保渐进进展

一旦初始环境搭建完成，编码代理被指示一次只处理一个功能。为了保持干净状态，模型被提示使用描述性的提交消息将其进展提交到 git，并在进度文件中写入其进展摘要。使用 git 允许模型回滚错误的代码更改并恢复工作状态。

实施健壮的测试

观察到的一个主要失败模式是代理在没有进行适当的端到端测试的情况下将功能标记为完成。虽然模型可以执行单元测试，但它通常无法识别仅从代码中不明显的错误。当 Claude 被提供测试工具（如 Puppeteer MCP 服务器）时，性能显著提高，这允许代理像人类用户一样端到端地测试功能。这使代理能够识别并修复原本不可见的错误。

操作化代理会话

为了确保每个编码代理在稳定且知情的状态下开始，每个会话开始时都会运行一系列标准步骤：

目录检查： 运行 pwd 以确认工作目录。
状态审查： 阅读 git 日志和进度文件，以快速了解最近的工作。
任务选择： 阅读功能列表文件，并选择尚未完成的最优先功能。

这个启动例程节省了令牌，并确保代理在尝试实现新功能之前首先验证应用的状态——通过运行本地开发服务器并执行基本的端到端测试——从而防止现有错误的加剧。

未来研究方向

虽然这项研究为长时间运行的代理框架提供了一套健壮的解决方案，但仍存在几个开放性问题。目前尚不清楚一个通用的编码代理是否能在各种上下文中表现最佳，或者多代理架构是否能产生更好的性能。假设专门的代理，如专门的测试代理或代码清理代理，可以在软件开发生命周期中提高子任务的性能。此外，当前的演示是针对全栈 Web 应用开发优化的，未来的工作将集中于将这些经验推广到其他长时间运行的代理任务，如科学研究或金融建模。