文章

【Anthropic】长期运行 Agent 的有效容器架构

  1. 问题:跨越多个上下文窗口的连贯性困境
  2. 两阶段容器架构
    1. 初始化 Agent(Initializer)
    2. 编码 Agent(Coding Agent)
  3. 关键的环保部件
    1. 特性列表(Feature List)
    2. 进度日志
    3. 测试验证
  4. 失败模式及其对症
  5. 会话结构的实践模式
  6. 核心思想

原文:Effective Harnesses for Long-Running Agents

问题:跨越多个上下文窗口的连贯性困境

长期运行的自主 Agent 面临一个根本性限制:每个新会话都以无历史记忆开始。就像「轮班制工程师,每位新来的工程师都不知道前一班发生了什么」,这种完全重启的方式造成了协调挑战。标准的上下文管理技术(如压缩)无法完全解决这个问题,因为问题不在于信息量,而在于结构化的持续状态管理。

两阶段容器架构

初始化 Agent(Initializer)

第一个会话由专门的初始化 Agent 执行,职责是建立项目基础设施:

  • 生成 init.sh 环境配置脚本,确保后续会话能快速恢复开发环境
  • 创建 claude-progress.txt 进度日志文件,作为 Agent 间的通信方式
  • 执行初始 git commit 记录已添加的文件,为代码变更建立基线

这一步的关键是不重复工作——初始化只做一次,后续 Agent 基于这个基础继续。

编码 Agent(Coding Agent)

后续会话的 Agent 专注于增量推进,按照这套固定流程:

  1. 读取当前目录结构和文件列表
  2. 回顾 git 日志,理解已完成的工作
  3. 检查进度日志,找到下一个待完成的特性
  4. 运行基础功能测试,验证环境可用
  5. 实现单个特性,保持代码变更原子性
  6. 提交 git commit,更新进度日志

单一特性聚焦是关键——避免试图一次性解决多个问题,也避免过早宣布完成。

关键的环保部件

特性列表(Feature List)

维护一个包含 200+ 条详细特性描述的 JSON 文件,所有特性初始状态都标记为失败。这个看似悖论的设计其实很妙:

  • 为后续 Agent 提供明确的工作清单
  • 防止 Agent 早期假设功能已完成或产品可用
  • 提供结构化的决策参考,明确「下一步做什么」

进度日志

claude-progress.txt 是 Agent 间的交接文档,记录:

  • 已完成的特性及其 commit hash
  • 当前会话实现了哪些特性
  • 下一个待处理的特性编号

这样每个新 Agent 不需要重新扫描代码库,直接读文件就能快速定位断点。

测试验证

单元测试是必需但不充分的。浏览器自动化工具(如 Puppeteer MCP) 对端到端验证至关重要。Agent 需要真实执行功能流,观察是否产生预期的用户界面行为,而不是仅靠代码审查或单元测试覆盖率。

失败模式及其对症

Anthropic 的文章识别了四类常见问题:

  1. 过早胜利宣言:Agent 在功能实际完成前就标记为完成
    • 解决:特性列表初始全部失败,强制实装验证
  2. 环境污染:依赖版本不一致、临时文件堆积、配置漂移
    • 解决:init.sh 脚本确保可重复的环境初始化
  3. 验证不足:只依赖单元测试,忽略集成层问题
    • 解决:集成端到端测试,自动化浏览器验证
  4. 进度信息混乱:没有清晰的检查点,新 Agent 必须从头审视所有代码
    • 解决:强制结构化进度日志,git commit 作为事件记录

会话结构的实践模式

每个编码 Agent 会话始于:

1
2
3
4
5
6
7
8
1. ls -la && file structure review
2. git log --oneline -10
3. cat claude-progress.txt
4. select next feature from feature list
5. run e2e tests
6. implement feature X
7. git commit -m "Implement feature X"
8. update claude-progress.txt

这个模式的好处:

  • 无歧义:每个 Agent 都知道自己在哪、该做什么
  • 可恢复:任何会话中断都能精确续接
  • 审计友好:git 日志和进度文件清晰记录了全程决策
  • 测试驱动:边界清晰的 E2E 测试防止功能漂移

核心思想

这篇文章解决的本质问题是:长期自主工作需要的不是更聪明的 Agent,而是更清晰的「交接单」

传统的容器(harness)概念通常指人为设计一套测试、约束和验证机制;这里的创新在于把它用在多轮 Agent 之间——容器不是约束 Agent,而是保证 Agent 之间的协调和连贯

三个关键洞察:

  1. 初始化和编码分离:避免初始化逻辑混入每个会话,减少重复工作和决策空间
  2. 结构化进度追踪胜于上下文压缩:即使 context 很短,只要有清晰的进度点和特性列表,Agent 也能高效续接
  3. E2E 测试是硬约束,不是软建议:Agent 容易过度乐观,浏览器自动化测试是对抗这种偏差的有效工具

这个模式提示了一个更广泛的原则:无论多么强大的 LLM,面对长期任务时都需要良好的「工作簿」设计。好的容器不是限制 Agent 的能力,而是帮助它们在长时间跨度内保持理性和连贯。

本文由作者按照 CC BY 4.0 进行授权