Anthropic 针对长时运行智能体的有效 Harness 系统

Anthropic 开发了一种专门的智能体 harness，以解决 AI 智能体在跨多个离散会话工作时出现的“记忆丢失”和进度不一致的问题。通过将工作流拆分为初始化智能体 (initializer agent) 和编码智能体 (coding agent)，开发者可以让像 Opus 4.5 这样的模型完成超出单个上下文窗口限制的复杂、生产级项目。

长时运行智能体的挑战

标准的智能体 harness 往往在处理复杂的、多会话任务时失败，因为每个新会话在开始时都没有先前操作的记忆。Anthropic 在使用 Claude Agent SDK 处理长程任务时，识别出了两种主要的失败模式：

1. 过度雄心 (One-shotting)： 智能体试图一次性实现太多功能，耗尽了上下文窗口，导致项目处于半实现、缺乏文档的状态。
2. 过早完成： 后续的智能体实例可能会看到已有的进度，并在所有需求满足之前错误地宣布整个项目已完成。

虽然上下文压缩 (context compaction) 有所帮助，但它通常不足以提供清晰、结构化的指令，使后续智能体能够在无需猜测或在恢复过程中浪费 token 的情况下恢复工作。

双智能体解决方案

为了弥合会话之间的差距，Anthropic 采用了两部分提示词策略。尽管底层的系统提示词和工具保持不变，但初始的用户提示词不同，从而创建了两个截然不同的角色：

1. 初始化智能体 (The Initializer Agent)

初始化智能体仅用于第一个会话。其主要目标是建立一个引导所有后续智能体的基础。关键输出包括：

• 功能列表 (Feature List)： 一个全面的 JSON 文件，将用户的高层级提示词扩展为详细的需求（例如，为 claude.ai 克隆版创建超过 200 个功能）。每个功能最初被标记为 "passes": false。
• 环境搭建 (Environment Setup)： 一个 init.sh 脚本，用于自动启动开发服务器并进行基础的端到端测试。
• 追踪基础设施 (Tracking Infrastructure)： 一个用于记录进度的 claude-progress.txt 文件，以及用于建立代码库状态的初始 git commit。

2. 编码智能体 (The Coding Agent)

后续会话使用编码智能体，其任务是实现增量式进度。为了防止上述失败模式，编码智能体遵循严格的操作循环：

• 定位 (Orientation)： 每个会话开始时，都会运行 pwd，读取 claude-progress.txt，查看 git log，并阅读 feature_list.json 文件。
• 增量实现 (Incremental Implementation)： 智能体一次只处理一个功能，以防止上下文耗尽。
• 验证 (Verification)： 智能体必须使用浏览器自动化工具（例如 Puppeteer MCP server）来像人类用户一样进行端到端的特征验证，而不是仅仅依赖单元测试或代码检查。
• 干净的交接 (Clean Handoff)： 在结束会话之前，智能体必须使用描述性的消息将进度提交到 git，并更新进度文件，确保环境处于适合下一个智能体的“merge-ready”状态。

失败模式与缓解措施总结

| 问题 | 初始化智能体操作 | 编码智能体操作 | | :--- | :--- | :--- | | | 项目过早宣告胜利 | 创建结构化的 JSON 功能列表 | 读取功能列表；一次只处理一个功能 | | 存在 Bug/缺乏文档的状态 | 建立 git 仓库和进度文件 | 读取日志/进度；开始时运行基础测试；结束时提交/更新 | | 功能过早完成 | 创建功能列表 | 在标记为 "passing" 之前通过端到端测试进行自我验证 | | 搭建摩擦 | 编写 init.sh 脚本 | 运行 init.sh 以启动服务器并验证状态 |

技术局限性与未来方向

尽管有所改进，Anthropic 指出当前浏览器自动化的特定局限性。例如，Claude 无法通过 Puppeteer MCP 看到浏览器原生的 alert 对话框，这可能导致依赖这些对话框的功能出现 Bug。

未来的研究将探索多智能体架构——利用专门用于测试、QA 和代码清理的智能体——是否比单一的通用编码智能体表现更好。此外， Anthropic 旨在将这些 harness 模式推广到 Web 开发之外的领域，如金融建模和科学研究。