视频 · 前往原文观看

一年前我们首次推出云端智能体时，它们看起来还像是本地智能体的简单延伸。自那以后，云端智能体的能力已大幅扩展。

云端智能体现在运行于专属的虚拟机上，拥有自己的环境、依赖项和网络访问权限。它们可以并行工作、无人值守运行，并能承担比运行在你笔记本电脑上的本地智能体更长期的任务。

这些能力带来了环境搭建、可靠性和编排方面的挑战，而这些挑战在智能体运行于你本地电脑时并不那么突出。

在这篇文章中，我们想分享在构建云端智能体过程中学到的最重要的经验教训，以及为什么这项工作越来越不像把本地智能体移植到服务器上，而更像是在其周围构建一个操作系统层。

开发环境即产品

在过去一年里，我们认识到，影响云端智能体输出质量的单一最大因素，是确保它拥有一个完整的开发环境，就像开发者所拥有的那样。

在本地你不需要过多考虑这个问题，因为本地智能体会自动继承你笔记本电脑上正在使用的开发环境。而在云端，你必须从头重建所有这一切，并且很难判断你是否做得完美无缺。

通常不会出现崩溃或错误信息，唯一的迹象往往是输出质量的微妙下降。你可能一开始注意不到，或者即使注意到了，也可能将其归咎于模型本身。

但我们一次又一次地将问题追溯到了同一个根源：云端智能体没有执行或验证其工作所需的环境。一年前这还没那么重要，因为模型无论如何都无法充分利用其环境。但随着模型变得越来越智能，环境搭建已成为决定它们能否充分发挥潜力的关键因素。

如今，要达到“完整环境”需要重建数量惊人的基础设施：

• 用于构建智能体环境的更好用户工具
• 在消息之间高效休眠和恢复智能体虚拟机的方法
• 用于快速且持久地检查点保存、恢复和分叉虚拟机镜像的流水线
• 紧密的约束与客户端集成，使智能体与人类都能解读环境并与之交互。

随着云端智能体承担更多工作，它们需要受控的网络访问权限来创建 PR、拉取依赖项以及进行研究。久而久之，我们最终构建了本质上相当于面向智能体的企业级 IT 系统，其中包含机密信息脱敏、网络策略和凭证管理。

长时间运行的智能体需要持久化执行。

云端智能体带来的可靠性挑战与本地智能体不同。云端智能体并非在本地笔记本电脑上争夺资源，而是在各自独立的虚拟机中运行。这使得开发者更容易并行运行多个智能体，并委派通常需要数小时而非数分钟的长时间运行任务。

但是，在虚拟机中运行会面临推理服务商中断、Pod 需要替换以及 EC2 节点宕机等中断风险。

我们最初采用工作窃取架构构建云端智能体，工作节点可以拾取智能体并循环运行直至完成。这种架构将本地运行的模式移植到了服务器上，但设置非常脆弱——我们早期的云端智能体测试版通常只能达到一个九的可靠性。

随着云端智能体的成熟，我们发现自己在重建 Temporal 已经解决的许多持久化执行原语（例如重试机制、跨机器调度工作、跨节点故障的持久性），因此我们转而迁移到了 Temporal。

我们目前在 Temporal 上的智能体循环能够承受推理可靠性波动、Pod 休眠与恢复，以及持续数天甚至数周的任务运行。仅此一次迁移就将我们的可靠性提升到了两个九以上。如今，Temporal 每天处理超过 5000 万次操作，涉及超过 700 万个独特的工作流。在内部，超过 40% 的 PR 来自云端智能体，并且这一比例还在增长。

随着时间的推移，我们学会了如何更好地构建 Temporal 工作流。我们已从“永久运行”的智能体工作流转向多个较短的、在完成单个任务后即退出的工作流，这使得版本升级更加容易。我们还拆分了活动，以便更好地处理超时和重试，因为异步工具调用、子智能体以及推理服务商的中断已经改变了我们的底层假设。

将智能体和机器与会话状态解耦

云端智能体不再只是单台机器上运行的一个循环。相反，一个智能体可能在一台机器上运行，在多个机器上生成异步子智能体，或者在本地启动然后将任务委托给云端。子智能体甚至可能比其父智能体存活更久，或者在完全不同类型的 Pod 上运行。

为了实现这一点，我们发现将智能体循环、机器状态和会话状态保持为解耦的组件非常有价值。由于智能体循环存在于 Temporal 中而非虚拟机本身，我们可以独立管理 Pod 的生命周期，并在不同类型的 Pod 上运行智能体——包括只读虚拟机或预热虚拟机等优化方案。

在会话方面，我们将存储和流式传输层与核心智能体工作流分离开来。我们构建了一种高效的仅追加存储机制，将会话更新流式传输到 Web 和桌面客户端。这一层负责处理重试，因此如果智能体循环中的某一步在流式传输部分输出后失败并随后被重试，客户端可以检测到这一点，回退其流，并显示新数据而非旧数据。

懂得如何适时放手

构建云端智能体框架意味着要不断评估有多少行为是确定性的，又有多少行为交由智能体处理。

早期，我们不太信任智能体，因此框架会在每个任务后复核其工作，强制提交并推送。随着模型变得越来越智能，我们开始将逻辑从框架中移出，放入智能体控制的工具中。一年前，多仓库设置需要硬编码的框架行为。现在，我们可以向智能体提供仓库布局，公开用于分支和拉取请求的工具，并让它自行决定如何完成工作。

CI 自动修复也经历了同样的过程。早期版本的云端智能体框架中包含用于抓取任务失败日志并将其写入虚拟机的逻辑。现在，我们只需让智能体访问 GitHub CLI，并自动将大量输出写入它可以搜索的文件中。发送给智能体的通知变得简单得多，我们预计这一趋势将持续下去。

框架本身并未消失，而是其包含的内容正在发生变化。计算机使用就是一个当下的好例子。我们的云端智能体框架为计算机使用配备了一个专门的子智能体类型，拥有自己的模型路由、自定义提示词和屏幕录制功能。VNC 和 Chrome 属于环境的一部分，由父智能体和子智能体共享。这使得父智能体可以直接使用它们，例如，通过运行 Playwright 脚本。我们使用这种脚手架结构，是因为模型尚未完全准备好独立处理计算机使用任务，但智能体仍然控制着何时调用它。

云端智能体在框架中需要的提示词类型也与本地智能体不同。我们鼓励它们更加自主，因为阻塞的成本要高得多。在本地，你知道智能体何时停止并等待许可，但在云端，它可能会在你回去检查之前，在那里闲置数小时。

自愈型智能体环境

展望未来，我们专注于超越在“手把手指导智能体”和“完全放手”之间的二元选择。一个更好的模式是赋予智能体理解其周围系统的工具。

我们希望云端智能体能够报告密钥缺失、网络访问被阻止，或环境以其他方式阻碍其进展的情况，然后能够以自愈的方式采取行动。在最近的一篇研究博客中，我们讨论了一种实现这一目标的途径，我们称之为“自动安装”。

仅仅在过去几个月里，云端智能体就取得了巨大的进步，我们预计变化的速度只会从这里开始加快。Cursor 云端智能体让团队能够利用这一广阔的应用领域，而无需在底层构建或维护基础设施。