长时运行智能体的难题#

Claude Agent SDK 是一个功能强大、用途广泛的智能体框架(agent harness),擅长编码,也擅长其他需要模型借助工具收集上下文、制定计划并加以执行的任务。它具备上下文压缩(compaction)等上下文管理能力,让智能体可以在不耗尽上下文窗口的情况下持续推进一项任务。理论上,有了这样的配置,智能体应该能够无限期地持续做有价值的工作。

然而,仅靠上下文压缩并不够。开箱即用时,即使像 Opus 4.5 这样的前沿编码模型,在 Claude Agent SDK 上跨多个上下文窗口循环运行,如果只给一个高层级的提示词——比如「做一个 claude.ai 的克隆版」——也无法构建出一个达到生产质量的 Web 应用。

Claude 的失败体现在两种模式上。第一种,智能体倾向于一次想做太多事情——本质上就是试图一次性完成(one-shot)整个应用。这常常导致模型在实现过程中耗尽上下文,留给下一个会话的是一堆实现了一半、毫无文档的功能。于是智能体不得不去猜测之前发生了什么,并花大量时间试图让基础应用重新跑起来。即使启用了上下文压缩也会发生这种情况,因为压缩并不总能向下一个智能体传递足够清晰的指令。

第二种失败模式往往出现在项目后期。在部分功能已经构建完成之后,后一个智能体实例会四处看看,发现已经有了进展,便宣布任务大功告成。

由此可以把问题拆解成两部分。第一,我们需要搭建一个初始环境,为某个提示词所要求的全部功能奠定基础,让智能体能够按步骤、按功能逐个推进。第二,我们应当提示每个智能体朝着目标取得渐进进展,同时在会话结束时把环境保持在干净状态。所谓「干净状态」,指的是适合合并到主分支的那类代码:没有重大缺陷,代码井然有序、文档完善,总体而言,开发者可以轻松开始一个新功能的开发,而不必先收拾一堆无关的烂摊子。

在内部实验中,我们用一套双部分的解决方案处理了这些问题:

1. 初始化智能体:第一个智能体会话使用专门的提示词,要求模型搭建初始环境:一个 init.sh 脚本、一个记录各智能体工作日志的 claude-progress.txt 文件,以及一个能体现新增了哪些文件的初始 git 提交。
2. 编码智能体:之后的每个会话都要求模型取得渐进进展,然后在结束时留下结构化的更新。¹

这里的关键洞见是找到一种方式,让智能体在拿到全新上下文窗口时能快速理解工作的当前状态——这通过 claude-progress.txt 文件配合 git 历史来实现。这些做法的灵感,来自对高效软件工程师日常工作的了解。

环境管理#

在更新版的 Claude 4 提示指南中,我们分享了一些多上下文窗口工作流的最佳实践,其中包括一种框架结构:对第一个上下文窗口使用「不同的提示词」。这个「不同的提示词」要求初始化智能体把环境搭建好,为后续编码智能体高效工作准备好一切必要上下文。下面,我们对这类环境的一些关键组成部分做更深入的剖析。

1
{
2
    "category": "functional",
3
    "description": "New chat button creates a fresh conversation",
4
    "steps": [
5
      "Navigate to main interface",
6
      "Click the 'New Chat' button",
7
      "Verify a new conversation is created",
8
      "Check that chat area shows welcome state",
9
      "Verify conversation appears in sidebar"
10
    ],
11
    "passes": false
12
  }

快速进入状态#

有了上述所有机制,每个编码智能体都会被提示按一系列步骤来摸清现状——有些步骤相当基础,但仍然管用:

• 运行 pwd 查看你所在的目录。你只能编辑此目录内的文件。
• 阅读 git 日志与进度文件,了解最近做了哪些工作。
• 阅读功能清单文件,挑一个尚未完成、优先级最高的功能来做。

这种做法在每个会话中都能为 Claude 省下一些 token,因为它不必再琢磨如何测试代码。此外,让初始化智能体写一个能启动开发服务器的 init.sh 脚本,并在实现新功能前先跑一遍基本的端到端测试,也很有帮助。

以 claude.ai 克隆版为例,这意味着智能体总是先启动本地开发服务器,再用 Puppeteer MCP 开一个新对话、发一条消息并收到回复。这能确保 Claude 快速发现应用是否处于损坏状态,并立刻修复已有的缺陷。如果智能体不这么做,而是直接开始实现新功能,很可能会让问题变得更糟。

有了这一切,一次典型会话的开场大致如下:

1
[Assistant] I'll start by getting my bearings and understanding the current state of the project.
2
[Tool Use] <bash - pwd>
3
[Tool Use] <read - claude-progress.txt>
4
[Tool Use] <read - feature_list.json>
5
[Assistant] Let me check the git log to see recent work.
6
[Tool Use] <bash - git log --oneline -20>
7
[Assistant] Now let me check if there's an init.sh script to restart the servers.
8
<Starts the development server>
9
[Assistant] Excellent! Now let me navigate to the application and verify that some fundamental features are still working.
10
<Tests basic functionality>
11
[Assistant] Based on my verification testing, I can see that the fundamental functionality is working well. The core chat features, theme switching, conversation loading, and error handling are all functioning correctly. Now let me review the tests.json file more comprehensively to understand what needs to be implemented next.
12
<Starts work on a new feature>

智能体的失败模式与解决方案

上表总结了长时运行智能体中的四种常见失败模式及其解决方案。

未来工作#

这项研究展示了长时运行智能体框架中的一套可行解决方案,使模型能够在多个上下文窗口间取得渐进进展。不过,仍然存在一些开放性问题。

最值得注意的是,目前尚不清楚究竟是单个通用型编码智能体在跨上下文时表现最佳,还是通过多智能体架构能取得更好的表现。合理的猜想是,像测试智能体、质量保障智能体或代码清理智能体这样的专职智能体,或许能在软件开发生命周期的各个子任务上做得更好。

此外,这个演示是针对全栈 Web 应用开发做了优化的。未来的一个方向是把这些发现推广到其他领域。这些经验中的一部分或全部,很可能也适用于科学研究和金融建模等场景所需要的那类长时运行智能体任务。