Claude Code 长时运行智能体的有效驾驭工程框架实践
长时运行智能体的核心挑战在于,它们必须以离散的会话形式工作,而每个新会话开始时都对之前发生的事情毫无记忆。开箱即用的情况下,即使是像 Opus 4.5 这样的前沿编码模型,在 Claude Agent SDK 上循环运行多个上下文窗口,如果只给出"构建一个 claude.ai 克隆版"这样的高级提示,也无法构建出生产级质量的 Web 应用。所谓"干净状态",我们指的是适合合并到主分支的代码状态:没
大家好,我是玄姐。
PS:
OpenClaw 之后,Harness Engineering 到底是什么?在企业如何落地?有哪些使用场景?具体的实践经验是什么?今晚开场直播详细讲解,欢迎点击预约,直播见。
随着 AI 智能体能力的不断提升,开发者正越来越多地要求它们承担复杂任务,这些任务可能需要工作数小时甚至数天。然而,如何让智能体在多个上下文窗口中保持持续进展,仍然是一个开放性问题。
长时运行智能体的核心挑战在于,它们必须以离散的会话形式工作,而每个新会话开始时都对之前发生的事情毫无记忆。想象一下,一个软件项目由轮班工作的工程师负责,每位新接班的工程师都对上一班次发生的事情毫无印象。由于上下文窗口有限,且大多数复杂项目无法在一个窗口内完成,智能体需要一种方式来弥合会话之间的鸿沟。
我们为 Claude Agent SDK 开发了一套双重解决方案,使其能在多上下文窗口中高效工作:初始化智能体负责在首次运行时搭建环境,编码智能体则负责在每个会话中取得渐进式进展,同时为下一个会话留下清晰的产物。你可以在配套的快速入门指南中找到代码示例。

一、长时运行智能体的问题
Claude Agent SDK 是一个强大的通用智能体驾驭工程(Harness Engineering)框架,擅长编码以及需要使用工具来收集上下文、规划和执行的其他任务。它具备上下文管理功能,如压缩(compaction),使智能体能够在不耗尽上下文窗口的情况下持续工作。理论上,基于这种设置,智能体应该可以无限期地持续进行有效工作。
然而,仅靠压缩是不够的。开箱即用的情况下,即使是像 Opus 4.5 这样的前沿编码模型,在 Claude Agent SDK 上循环运行多个上下文窗口,如果只给出"构建一个 claude.ai 克隆版"这样的高级提示,也无法构建出生产级质量的 Web 应用。
Claude 的失败呈现出两种模式。首先,智能体倾向于一次性做太多事情,试图一次性完成(one-shot)整个应用。这常常导致模型在实现过程中耗尽上下文,让下一个会话以一个完成一半且未记录的功能作为起点。随后,智能体不得不猜测发生了什么,并花费大量时间试图让基础应用重新工作。即使使用压缩也会发生这种情况,因为压缩并不总是能向下一个智能体传递完全清晰的指令。
第二种失败模式通常发生在项目后期。在已经构建了一些功能之后,后期的智能体实例会环顾四周,看到已有进展,就宣布工作已经完成。
这可以将问题分解为两部分:首先,我们需要建立一个初始环境,为给定提示所需的所有功能奠定基础,使智能体能逐步、逐功能地工作;其次,我们应该提示每个智能体在实现目标的同时取得渐进式进展,并在会话结束时将环境保持在干净状态。所谓"干净状态",我们指的是适合合并到主分支的代码状态:没有重大 Bug,代码有序且文档完善,总的来说,开发者可以轻松开始新功能,而无需先清理不相关的烂摊子。
在内部实验中,我们使用两部分解决方案解决了这些问题:
-
初始化智能体(Initializer agent):第一个智能体会使用专门的提示,要求模型设置初始环境:一个 init.sh 脚本、一个记录智能体工作内容的 claude-progress.txt 文件,以及一个初始 git 提交,显示添加了哪些文件。
-
编码智能体(Coding agent):每个后续会话都要求模型取得渐进式进展,然后留下结构化更新。
这里的关键洞察在于找到一种方法,让智能体在从全新上下文窗口启动时,能快速理解工作状态,这通过 claude-progress.txt 文件和 git 历史记录来实现。这些实践的灵感来自于了解高效的软件工程师每天都在做什么。
二、环境管理
在更新的 Claude 4 提示指南中,我们分享了一些多上下文窗口工作流的最佳实践,包括一种驾驭结构,即"对第一个上下文窗口使用不同的提示"。这种"不同的提示"要求初始化智能体用所有必要的上下文来设置环境,让未来的编码智能体能有效工作。在这里,我们深入探讨这种环境的关键组件。
2.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 格式,因为模型不恰当地更改或覆盖 JSON 文件的可能性比 Markdown 文件更小。
2.2 增量进展
有了这种初始环境脚手架,下一个编码智能体就被要求一次只处理一个功能。这种增量方法对于解决智能体一次性做太多事情的倾向至关重要。
一旦开始增量工作,模型在代码更改后必须将环境保持在干净状态,这仍然至关重要。在我们的实验中,我们发现引发这种行为的最佳方式是要求模型用描述性的提交信息将进展提交到 git,并在进度文件中写入进展摘要。这使模型能够使用 git 来回退糟糕的代码更改,并恢复代码库的工作状态。
这些方法也提高了效率,因为它们消除了智能体必须猜测发生了什么,并花费时间试图让基础应用重新工作的需要。
2.3 测试
我们观察到的最后一个重大失败模式是,Claude 倾向于在没有适当测试的情况下将功能标记为完成。在没有明确提示的情况下,Claude 倾向于进行代码更改,甚至使用单元测试或对开发服务器使用 curl 命令进行测试,但无法识别功能端到端无法工作的情况。
在构建 Web 应用的案例中,一旦明确提示使用浏览器自动化工具并像人类用户那样进行所有测试,Claude 在端到端验证功能方面表现良好。

为 Claude 提供这类测试工具极大地提升了性能,因为智能体能够识别并修复仅从代码中看不出的 Bug。
仍然存在一些问题,比如 Claude 视觉能力的限制以及浏览器自动化工具难以识别每一种 Bug。例如,Claude 无法通过 Puppeteer MCP 看到浏览器原生警告弹窗,依赖这些弹窗的功能因此往往存在更多缺陷。
2.4 快速上手
有了以上所有设置,每个编码智能体都会被提示运行一系列步骤来了解情况,其中一些相当基础但仍然有帮助:
-
运行 pwd 查看你正在工作的目录。你只能编辑此目录中的文件。
-
阅读 git 日志和进度文件,了解最近的工作内容。
-
阅读功能列表文件,选择优先级最高且尚未完成的功能开始工作。
这种方法在每个会话中为 Claude 节省了一些 token,因为它不必弄清楚如何测试代码。还有助于要求初始化智能体编写一个可以运行开发服务器的init.sh脚本,然后在实现新功能前进行一次基本的端到端测试。
在 claude.ai 克隆版的案例中,这意味着智能体始终启动本地开发服务器,并使用 Puppeteer MCP 开启新对话、发送消息并接收响应。这确保 Claude 能够快速识别应用是否被遗留在了损坏状态,并立即修复任何现有 Bug。如果智能体转而开始实现新功能,很可能会让问题变得更糟。
基于以上,典型的会话以以下助手消息开始:
[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 文件,了解接下来需要实现什么。<开始新功能的工作>
三、智能体故障模式与解决方案
|
问题 |
初始化智能体行为 |
编码智能体行为 |
|---|---|---|
|
Claude 过早宣布整个项目胜利 |
设置功能列表文件:根据输入规格,建立一个包含端到端功能描述列表的结构化 JSON 文件 |
在会话开始时阅读功能列表文件,选择单个功能开始工作 |
|
Claude 遗留有 Bug 或未记录进展的环境 |
写入初始 git 仓库和进度记录文件 |
会话开始时阅读进度记录文件和 git 提交日志,对开发服务器运行基础测试以发现未记录的 Bug;会话结束时写入 git 提交和进度更新 |
|
Claude 过早将功能标记为完成 |
设置功能列表文件 |
自我验证所有功能,只有在仔细测试后才将功能标记为"通过" |
|
Claude 必须花时间弄清楚如何运行应用 |
编写可运行开发服务器的 init.sh 脚本 |
会话开始时阅读 init.sh |
四、未来工作
这项研究展示了一套可能的解决方案,在长时运行智能体驾驭工程框架中使模型能在多上下文窗口中取得渐进式进展。然而,仍有一些开放性问题。
最值得注意的是,单个通用编码智能体在各种上下文中表现最佳,还是多智能体架构能获得更好的性能,这一点仍不清楚。像测试智能体、质量保证智能体或代码清理智能体这样的专门化智能体,似乎完全有可能在软件开发生命周期的子任务中表现更出色。
此外,此演示是针对全栈 Web 应用开发优化的。未来的方向是将这些发现推广到其他领域。这些经验的部分或全部可能适用于其他类型的长时智能体任务,比如科学研究或金融建模。
PS:
OpenClaw 之后,Harness Engineering 到底是什么?在企业如何落地?有哪些使用场景?具体的实践经验是什么?今晚开场直播详细讲解,欢迎点击预约,直播见。
好了,这就是我今天想分享的内容。如果你对构建企业级 AI 原生应用新架构设计和落地实践感兴趣,别忘了点赞、关注噢~
—1—
加我微信
扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈,欢迎你扫码加我个人微信来看👇

加星标★,不错过每一次更新!
⬇戳”阅读原文“,立即预约!
更多推荐




所有评论(0)