当 AI Agent 完成一个需要数小时甚至数天的复杂项目时，它会面临一个致命问题——每次新会话开始时，它对之前的工作一无所知。

Anthropic 团队从人类工程师的工作方式中汲取灵感，设计了一套长时运行 Agent 框架。核心发现出人意料地朴素：解决 Agent "失忆"问题的最佳灵感，来自于观察优秀的人类工程师每天是怎么交接工作的。

问题：Agent 跑着跑着就"翻车"了

Claude Agent SDK 拥有上下文压缩（Compaction）能力——当上下文窗口快满时，自动压缩之前的内容继续工作。理论上允许 Agent 无限期工作。但现实中，即使用最强的 Opus 4.5 模型，仅凭一句高级指令（比如"构建一个 claude.ai 的克隆"），Agent 也无法构建出合格的生产级 Web 应用。

两个经典翻车模式：

模式一：贪多嚼不烂

Agent 倾向于试图在一个上下文窗口内一步到位完成整个应用。结果上下文在实现过程中耗尽，留下半成品：功能写了一半、没有文档、代码状态混乱。下一个 Agent 接手时不得不花大量时间"考古"——猜测上一个 Agent 做了什么。

模式二：过早"交卷"

当部分功能已构建完成后，后续 Agent 发现"看起来 App 已经能跑了"，于是直接宣布任务完成——哪怕还有一堆功能没做。

解法：像人类工程师一样"交接班"

Anthropic 设计了一个分两步走的框架：

第一步：初始化 Agent——搭好脚手架

第一个 Agent 会话使用专门的提示词，不急着写代码，而是先做三件事：

• 写一个 init.sh 脚本：记录如何启动开发服务器、运行测试等操作
• 创建 claude-progress.txt 文件：作为"工作日志"，记录每个 Agent 做了什么
• 做一个初始的 git 提交：让后续 Agent 能通过 git 历史了解项目的演进过程

这本质上就是资深工程师在团队开工前做的事：搭好基础设施、建立工作规范、确保每个人都能快速上手。

第二步：编码 Agent——增量推进 + 干净交接

每个后续的 Agent 会话被要求做到两点：

• 增量进展：只做一件事，做完做好
• 干净交接：提交 git、更新进度文件，确保环境处于"可合并到主分支"的状态

所谓"干净状态"非常具体：没有重大 Bug、代码整洁有文档、下一个接手的人（Agent）可以立刻开始新功能开发，不需要先收拾烂摊子。

三大环境管理策略

策略一：结构化功能清单

初始化 Agent 基于用户的原始需求，生成一个详尽的功能清单。在 claude.ai 克隆的案例中，这个清单包含超过 200 个功能点：

{
    "category": "functional",
    "description": "点击新建聊天按钮可以创建一个新对话",
    "steps": ["导航到主界面", "点击'新建聊天'按钮", "验证新对话被创建"],
    "passes": false
}

每个功能初始状态都是 "passes": false。编码 Agent 只被允许将 passes 从 false 改为 true，且提示词中有强硬措辞："删除或编辑测试是不可接受的"。

一个有趣的细节：Anthropic 选择 JSON 而不是 Markdown 来存储这个文件。原因是模型在面对 Markdown 时更容易随意修改内容，而 JSON 的结构化格式天然对此有抑制作用。

策略二：严格的增量开发

这是整个框架中最关键的一条规则：每个 Agent 一次只开发一个功能。完成后提交 git 并更新进度文件。这带来两个好处：

• git 历史使得 Agent 可以回退糟糕的代码改动
• 消除了"考古"开销——新 Agent 不再需要猜测之前发生了什么

策略三：像用户一样测试

Agent 在没有明确提示的情况下，会用单元测试或 curl 命令来测试，但这些测试往往无法覆盖真实的端到端场景。

解法是给 Agent 配备浏览器自动化工具（如 Puppeteer MCP），并明确提示它："像人类用户一样进行所有测试"。Agent 通过 Puppeteer 截取屏幕截图来验证功能，能发现很多仅看代码发现不了的 Bug。

标准化的会话启动流程

每个编码 Agent 的会话启动被标准化为清晰的流程：

1. 定位：运行 pwd 确认工作目录
2. 阅读历史：读取 git 日志和进度文件，了解最近完成的工作
3. 选择任务：阅读功能列表，选择最高优先级的未完成功能
4. 健康检查：启动开发服务器，运行基本端到端测试，确认应用没有处于损坏状态
5. 开始开发

这个流程中有一个容易被忽略但至关重要的细节：先做健康检查，再开新功能。如果上一个 Agent 碰巧留下了 Bug，那么在 Bug 未修复的情况下开发新功能，只会让问题更加恶化。

四大失败模式速查

苏米注：长时运行 Agent 的问题，本质上是一个"工程师交接班"的问题。解决方案不需要复杂的技术突破——进度文件、git 历史、结构化的功能清单，这些都是人类软件团队每天在用的工具和流程。

展望

这项工作中仍有一些开放性问题：

• 单 Agent vs 多 Agent：是让一个通用编码 Agent 包揽一切更好，还是用专门的 Agent（测试 Agent、代码审查 Agent、代码清理 Agent）分工协作更好？
• 领域泛化：这套方案目前针对全栈 Web 应用开发。但它背后的原则——增量进展、结构化交接、端到端验证——很可能可以迁移到科学研究、金融建模等其他领域。

对于正在构建 Agent 系统的开发者来说，最重要的启示或许是：不要试图让 Agent 变得更聪明来解决长时运行的问题，而是给它一套好的工作规范。就像管理一个工程团队一样，流程和规范往往比个人能力更重要。

原文：anthropic.com/engineering/effective-harnesses-for-long-running-agents

代码示例：github.com/anthropics/claude-quickstarts