Anthropic：长效AI代理的高效管理方案：解决多轮会话中的持续推进难题

随着AI代理能力的不断提升，开发者正越来越多地借助它们处理那些需要数小时甚至数天才能完成的复杂任务。然而，如何让AI代理在多个上下文窗口中保持稳定的推进节奏，仍是一个亟待解决的问题。长效AI代理的核心挑战在于，它们必须在离散的会话中工作，而每一次新会话启动时，都无法继承上一次的工作记忆。这就好比一个软件项目由工程师轮班开发，但每位接替的工程师都对前一班的工作内容毫无了解。

由于上下文窗口存在长度限制，且大多数复杂项目无法在单个窗口内完成，AI代理亟需一种方法来衔接不同的编码会话。为此，我们为Claude Agent SDK（ Claude代理开发工具包）设计了一套双重解决方案，使其能在多个上下文窗口中高效工作：一是初始化代理，负责在首次运行时搭建基础环境；二是编码代理，负责在每一次会话中实现增量推进，并为下一次会话留下清晰的工作成果。相关代码示例可参考配套的快速入门文档（链接）。

长效AI代理面临的核心问题

Claude Agent SDK是一款功能强大的通用代理管理工具，不仅擅长编码任务，还能处理那些需要模型调用工具来收集上下文、制定计划并执行的各类任务。它具备上下文压缩等管理能力，可确保代理在处理任务时不会耗尽上下文窗口资源。从理论上讲，基于这样的配置，AI代理应该能够无限期地持续开展有效工作。

但实际情况是，仅靠上下文压缩远远不够。即便使用像Opus 4.5这样的前沿编码模型，在Claude Agent SDK上以多轮上下文窗口循环运行，若仅给出“开发一个claude. ai的克隆版本”这类高层级指令，也无法构建出达到生产级质量的Web应用。Claude在这类任务中的失效主要表现为两种模式。

第一种模式是代理往往试图一次性完成过多工作——本质上是想“一步到位”地构建整个应用。这常常导致模型在实现过程中耗尽上下文资源，使得下一次会话不得不从某个未完成且缺乏文档说明的功能开始。此时，代理只能猜测上一次的工作进展，花费大量时间修复基础功能，才能重新推进项目。即便启用了上下文压缩功能，这种问题依然存在，因为压缩机制并非总能向下一次会话的代理传递清晰完整的指令。

第二种失效模式通常出现在项目后期。当部分功能已经开发完成后，后续启动的代理实例会查看现有成果，并错误地宣布任务已完成。

这一问题可拆解为两个核心要点。首先，我们需要搭建一个初始环境，为用户指令所需的所有功能奠定基础，引导代理按步骤、分功能地推进开发。其次，需要引导每一次会话的代理实现增量式进展，同时在会话结束时将环境维持在“清洁状态”。这里的“清洁状态”指的是代码达到可合并至主分支的标准：无重大漏洞、结构规整且文档完善，确保后续开发者能够直接着手新功能开发，无需先清理无关的遗留问题。

在内部实验中，我们通过两部分解决方案解决了这些问题：

1. 初始化代理：首次会话启动的代理将执行专门指令，搭建初始环境，包括创建init. sh脚本（初始化脚本）、claude-progress. txt文件（用于记录代理工作进展），以及完成首次Git提交以明确新增文件清单。

2. 编码代理：后续所有会话中的代理均需实现增量开发，并留下结构化的更新记录¹。

这一方案的核心思路在于，让代理在启动新的上下文窗口时能够快速掌握工作状态——而这一目标主要通过claude-progress. txt文件与Git提交历史的结合来实现。这些实践方法的灵感，源自高效软件工程师的日常工作模式。

环境管理：为长效工作奠基

在更新后的《Claude 4提示词指南》（链接）中，我们分享了多上下文窗口工作流的最佳实践，其中就包括为“首次上下文窗口配置专属提示词”的管理结构。这种“专属提示词”会要求初始化代理搭建包含所有必要信息的环境，为后续编码代理的高效工作提供支撑。下文将深入解析这类环境中的核心组件。

1. 功能清单：明确目标边界

为解决代理“一步到位开发”或“提前宣布完成”的问题，我们指令初始化代理基于用户的初始需求，编写一份详尽的功能需求文件。以claude. ai克隆项目为例，这份清单包含了200多项功能，例如“用户可新建对话、输入查询内容、按下回车并查看AI回复”。所有功能初始状态均标记为“未通过”（failing），以便后续编码代理清晰掌握完整的功能范围。

{
  "category": "functional",
  "description": "New chat button creates a fresh conversation",
  "steps": [
    "Navigate to main interface",
    "Click the 'New Chat' button",
    "Verify a new conversation is created",
    "Check that chat area shows welcome state",
    "Verify conversation appears in sidebar"
  ],
  "passes": false
}

我们明确指令编码代理仅可通过修改“passes”字段来更新这份文件，并加入了严格约束：“禁止删除或修改测试内容，否则可能导致功能缺失或程序漏洞”。经过多次实验，我们最终选择JSON格式存储这份清单——相比Markdown格式，模型对JSON文件进行不当修改或覆盖的概率更低。

2. 增量推进：确保稳步迭代

在搭建好上述初始环境后，我们指令后续编码代理每次仅专注于开发一项功能。这种增量开发模式，是解决代理“贪多求快”问题的关键。

即便采用增量开发，模型在完成代码修改后，仍需将环境维持在清洁状态。实验表明，实现这一目标的最佳方式是：要求模型通过Git提交记录进展（提交信息需具备描述性），并在进展文件中总结本次工作内容。这样一来，模型可借助Git回滚有问题的代码，恢复代码库的可用状态。同时，这种方式还能提升效率——代理无需再猜测上一次的工作内容，也不必花费时间修复基础功能。

3. 测试验证：避免功能虚标

我们观察到的另一大失效模式是：Claude往往会在未完成充分测试的情况下，就将功能标记为“已完成”。若未明确指令，Claude可能会修改代码，甚至通过单元测试或对开发服务器执行curl命令进行简单测试，但无法识别功能是否真正实现端到端可用。

在Web应用开发场景中，只要明确指令Claude使用浏览器自动化工具，并以普通用户的操作方式完成全流程测试，它就能很好地实现端到端功能验证。

上图为Claude通过Puppeteer MCP服务器测试claude. ai克隆版本时截取的画面。为Claude配备这类测试工具后，其性能显著提升——代理能够识别并修复那些仅从代码层面难以发现的漏洞。当然，目前仍存在一些局限，例如Claude的视觉识别能力以及浏览器自动化工具的功能限制，导致部分漏洞难以检测。举例来说，Claude无法通过Puppeteer MCP识别浏览器原生的提示弹窗（alert modals），因此依赖这类弹窗的功能往往更容易出现漏洞。

快速上手：代理的标准化启动流程

配置好上述所有组件后，我们为每一次会话的编码代理设定了一套标准化的启动流程，帮助其快速进入工作状态。这些步骤看似基础，却能有效提升效率：

1. 执行 pwd 命令，确认当前工作目录（仅可编辑该目录下的文件）。

2. 读取Git日志与进展文件，了解近期工作内容。

3. 读取功能清单文件，选择优先级最高的未完成功能作为本次开发目标。

这套流程能为Claude的每一次会话节省token资源——无需再花费精力探索代码的测试方法。同时，我们还指令初始化代理编写init. sh脚本（用于启动开发服务器），并要求编码代理在开发新功能前，先通过该脚本完成基础的端到端测试。

以claude. ai克隆项目为例，这意味着代理每次启动后，都会先启动本地开发服务器，再通过Puppeteer MCP工具新建对话、发送消息并接收回复。这一过程能帮助Claude快速检测应用是否处于故障状态，若存在问题则立即修复——如果代理跳过这一步直接开发新功能，很可能会导致问题进一步恶化。

基于上述配置，一次典型的代理会话会以如下助理消息开启：

[Assistant] 我将先熟悉项目现状，明确当前进展。
[Tool Use] <bash - pwd>
[Tool Use] <read - claude-progress.txt>
[Tool Use] <read - feature_list.json>
[Assistant] 我需要查看Git日志，了解近期工作内容。
[Tool Use] <bash - git log --oneline -20>
[Assistant] 现在我将检查是否存在init.sh脚本，用于重启服务器。
<启动开发服务器>
[Assistant] 很好！接下来我将访问应用，验证核心功能是否正常工作。
<测试基础功能>
[Assistant] 验证结果显示，核心功能运行正常——包括聊天功能、主题切换、会话加载及错误处理均无问题。现在我将全面查看tests.json文件，明确下一步的开发任务。
<开始开发新功能>

AI代理失效模式与解决方案对照表

问题类型	初始化代理的应对措施	编码代理的应对措施
过早宣布整个项目完成	基于输入需求，创建结构化JSON格式的功能清单文件，包含所有端到端功能描述	会话启动时读取功能清单，每次仅选择一项功能进行开发
留下存在漏洞或缺乏文档的环境	创建初始Git仓库及进展记录文件	会话启动时读取进展文件与Git提交日志，通过开发服务器执行基础测试以检测隐藏漏洞；会话结束时提交Git记录并更新进展文件
过早标记功能为“已完成”	创建功能清单文件，明确功能验证标准	对所有功能进行自主验证，仅在充分测试后将功能状态改为“通过”（passing）
花费大量时间探索应用启动方法	编写可启动开发服务器的init. sh脚本	会话启动时先读取init. sh脚本，掌握启动方法
（上表总结了长效AI代理的四大常见失效模式及对应解决方案）

未来展望

本研究提出了一套长效AI代理管理方案，可帮助模型在多个上下文窗口中实现增量推进。但目前仍存在一些开放性问题，其中最核心的是：在多轮上下文会话中，单一通用编码代理的表现是否最优？还是说，采用多代理架构能实现更好的效果？

从逻辑上看，为软件开发全流程中的子任务配置专用代理（如测试代理、质量保障代理、代码优化代理等），可能会取得更优的效果。此外，本方案目前针对全栈Web应用开发进行了优化，未来的研究方向将是把这些成果推广到更多领域——例如，这些经验很可能适用于科学研究、金融建模等需要长效AI代理支持的任务场景。

更多 AI 前沿技术与设计灵感，欢迎关注「设计小站」公众号（ID：sjxz00），一起探索科技与设计的融合创新。

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