Anthropic双智能体框架：破解AI长时任务记忆难题的工程化方案

如何让没有长时记忆的AI，完成持续数小时的复杂任务？Anthropic设计出一套更为高效的长时智能体运行框架，使AI能像人类工程师一样，在跨越数小时的任务中渐进式推进工作，克服记忆缺陷带来的挑战。

假如你雇佣了一支24小时轮班的工程师团队，要求他们一起开发一款复杂应用。

但有一个奇怪规定：每位工程师一上班就完全忘记上一班做过什么，只能从零开始重新干。

无论他们技术多强，工作多努力，这个项目恐怕也做不成。

而这正是「长期运行智能体」在现实中遭遇的真实困境：

「上下文窗口一关，AI就失忆」。

模型没有真正的长期记忆，所有判断都依赖当下能看到的文本片段，上下文窗口一满或被关掉，就像白板被擦掉一样，所有历史信息瞬间归零。

这种「记忆缺陷」，让智能体做不了长工程，一旦任务需要持续数小时、跨越多轮对话窗口时，这样的问题就会暴露出来。

由于上下文窗口有限，而大多数复杂项目无法在单一窗口完成，因此智能体必须找到一种能够跨越多轮编码会话的有效机制。

近日，Anthropic通过「偷师」人类工程师的日常工作习惯，形成了一套适用于长期运行智能体的有效框架，并在Claude Agent SDK中实现了双智能体架构，显著提升了任务执行的连贯性和可靠性。

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

双智能体架构，模仿人类优秀工程师的日常习惯

Claude Agent SDK是一个强大而通用的智能体框架，它不仅擅长编码，还能查资料、调工具、规划步骤、执行任务，几乎涵盖了软件开发的各个环节。

它拥有上下文管理能力，比如上下文压缩（compaction），能让智能体在不耗尽上下文窗口的前提下继续干活，但仅靠上下文压缩还不够，因为遗忘的根本问题并未解决。

在开箱即用的情况下，即使Opus 4.5这样顶级的编码模型，如果只给它一个「去做一个claude.ai的克隆网页」这样的模糊大指令。然后让它在SDK里跨多个上下文窗口反复执行，它依然很难完成一个真正能上线的Web应用，总是陷入重复劳动或错误判断。

在这个过程中，Claude经常会出现两类常见的失败模式：

第一种，它经常一次试图做太多事，缺乏分解任务的意识。

比如，一次性把整个应用写完。结果常常中途耗尽上下文，留下未完成、无文档的半成品功能，进入下一次会话时，就不得不猜测之前发生了什么，导致大量重复工作。

第二种，错误判断「项目已完成」，缺乏验收标准。

这通常出现在项目后期。当一些功能已经实现时，后来启动的智能体往往会扫瞄现有成果，然后直接宣布项目已经完成，而实际上很多功能并未真正实现或存在隐藏缺陷。

为了解决这个问题，研究人员将问题拆成两部分：

第一步，需要在初始环境中搭建好提示词要求的全部功能基础，让智能体能按步骤、按功能推进，而不是盲目行动。

第二步，每次会话中的智能体必须每次推进一小步，同时将环境保持在「干净状态」，确保代码随时可合并、可测试。

即能随时安全合并到主分支：没有明显bug、代码整洁、有清晰文档，开发者随时可以继续加新功能，而不需要重新理解项目状态。

按照这种思路，Anthropic为Claude Agent SDK设计了一个双组件方案：

• 初始化智能体（Initializer Agent）

第一次会话用一个专门提示词，让模型设置初始环境：生成init.sh脚本、claude-progress.txt工作日志文件，以及一个初始Git提交，为后续智能体打下基础。

• 编码智能体（Coding Agent）

在后续会话中接手工作，每次只推进一小步，并为下一轮工作留下清晰信息，通过阅读进度文件和Git历史快速恢复上下文。

这种模式的关键突破点在于找到一种方式，让每次会话在没有历史上下文的情况下也能快速理解当前项目状态，而claude-progress.txt文件与Git历史正好能做到这点，它们充当了“外部记忆”的角色。

这一灵感来自优秀软件工程师的日常工作习惯：他们总是通过文档、注释和版本控制来保持项目的连续性，而不是依赖大脑的记忆。

环境管理「三板斧」

如何让「接班」的智能体快速上手？

初始化智能体要搭建好所有未来编码会话需要的环境上下文，包括功能清单（Feature List）、渐进式推进（Incremental Progress）、测试（Testing）这三板斧。

功能列表

为避免智能体一次性写完整个应用或过早宣布项目完成，研究人员让初始化智能体将用户的初始提示，扩展成一个完整的功能需求文件，并采用不易误删的JSON格式。

例如，在claude.ai克隆示例中，它写出了超过200个功能，如「用户可以打开新对话、输入消息、按下Enter，并看到AI回复」。

这些功能一开始都标记为「failing」，让后续智能体清楚还有哪些功能没完成，从而聚焦于增量开发。

研究人员要求编码智能体只能修改passes字段的状态，并明确强调：「不允许删除或修改测试，否则可能导致功能缺失或出现bug。」

反复试验，研究人员最终选用JSON格式，这是因为比起Markdown文件，AI更不容易误删或覆盖JSON内容，保证了功能列表的稳定性。

渐进式推进

在初始环境搭建好之后，编码智能体会被要求一次只做一个功能的小步骤改动，就像敏捷开发中的迭代。

这种渐进式推进，对于解决智能体一次做太多事的问题非常关键，避免了上下文溢出和混乱。

同时，每次修改后保持环境的「干净」也很重要。

实验发现，最有效的方法是要求模型把改动通过描述性的信息提交到Git，并在progress文件中总结进展，这样下一轮智能体就能迅速了解当前状态。

这样，模型就能方便地回滚错误改动，恢复稳定代码状态，而不会因为一次错误导致整个项目崩溃。

这些方式能够大幅提升效率，因为智能体不再需要花大量时间猜测之前发生了什么，而是直接读取进度记录。

测试

此外，研究人员还观察到一个大问题：

Claude经常在没有充分测试的情况下，把功能标记为完成，导致上线后出现各种隐蔽问题。

这是因为，如果不提供明确指令和工具，Claude的「测试行为」大多会停留在「代码层面」，而不是「完整用户流程层面」，缺乏端到端的验证。

比如，它会改代码、跑单元测试、甚至用curl测一下开发服务器，但这些操作只能证明「代码大致能跑」，并不能保证整个用户操作流程从头到尾是顺畅可用的，比如界面交互、浏览器兼容性等。

如果我们明确要求它使用浏览器自动化工具，并像真实用户一样进行端到端测试，它在Web应用场景中通常表现得很好，很多原本容易漏掉的bug都能被发现出来，例如按钮点击无响应、页面跳转错误等。

Claude通过Puppeteer MCP服务器在测试claude.ai克隆版时截取的屏幕截图

因为很多问题只有在「真实运行、真实点击」时才会暴露，而不是从代码文本上就能看出来。

当然仍有一些限制，比如模型本身的视觉能力有限，浏览器自动化工具无法识别所有场景，比如弹窗、alert等。

比如，通过Puppeteer MCP，Claude现在看不到浏览器自带的alert弹窗，这限制了某些交互功能的测试覆盖。

对于那些「点一下按钮就弹个原生alert，再根据用户点击决定后续行为」的功能，Claude在自动化测试时就很难完整覆盖，也更容易出问题，未来需要更完善的测试工具。

快速上手

通过上述机制，每次编码智能体启动时都会先执行一套简单但实用的步骤：

运行 pwd 看看自己工作在什么目录，只能编辑这个目录里的文件，确保操作范围可控。

阅读 git 日志和进度文件，了解最近做了什么，快速融入项目。

阅读功能列表，并选择最高优先级且未完成的功能，避免重复劳动。

这种方式每次都能为Claude节省不少Token，因为它不必重新思考如何测试代码，而是直接利用已有的测试脚本。

研究人员还让初始化智能体编写一个init.sh脚本，用于启动开发服务器，并在实现新功能前跑一次基本的端到端测试，作为验收基准。

在claude.ai克隆项目中，智能体会先启动本地开发服务器，然后用Puppeteer MCP打开新对话、发送消息、接收回复。

这样Claude能立即判断项目是否处于异常状态，并马上修复bug，而不是在错误的基础上继续开发。

如果它直接开始做新功能，只会让情况更糟。

因此，一个典型的会话通常会从类似这样的助手消息开始：

目前的双组件架构已显著提升了全栈 Web应用开发的稳定性，但仍然有许多开放问题需要进一步探索。

其中最关键的一点是：

不清楚是否一个通用编码智能体就足够强，还是应该采用多智能体架构，比如引入专门的测试智能体、质检智能体或代码清理智能体来分担不同职责。

这一框架主要针对Web应用进行了优化，但很可能其中一些经验同样适用于科研、金融建模等需要长时间运行的智能体任务，未来有望扩展到更多领域。

参考资料

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