AI也能换岗了！Anthropic教智能体交接班，不怕长任务断片

【导读】如何让没有长时记忆的AI，完成持续数小时的复杂任务？Anthropic设计出一个更高效的长时智能体运行框架，让AI能够像人类工程师一样，在跨越数小时的任务中渐进式推进。

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

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

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

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

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

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

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

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

近日，Anthropic通过「偷师」人类工程师，形成了一套适用于长期运行智能体的有效框架。

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）

在后续会话中接手工作，每次只推进一小步，并为下一轮工作留下清晰信息。

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

这一灵感来自优秀软件工程师的日常工作习惯。

环境管理「三板斧」

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

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

功能列表

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

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

这些功能一开始都标记为「failing」，让后续智能体清楚还有哪些功能没完成。

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

反复试验，研究人员最终选用JSON格式，这是因为比起Markdown文件，AI更不容易误删或覆盖JSON内容。

渐进式推进

在初始环境搭建好之后，编码智能体会被要求一次只做一个功能的小步骤改动。

这种渐进式推进，对于解决智能体一次做太多事的问题非常关键。

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

实验发现，最有效的方法是要求模型把改动通过描述性的信息提交到Git，并在progress文件中总结进展。

这样，模型就能方便地回滚错误改动，恢复稳定代码状态。

这些方式能够大幅提升效率，因为智能体不再需要花大量时间猜测之前发生了什么。

测试

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

Claude经常在没有充分测试的情况下，把功能标记为完成。

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

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

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

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

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

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

比如，通过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

秒追ASI

⭐点赞、转发、在看一键三连⭐

点亮星标，锁定极速推送！