一年前，我们刚推出云端智能体时，它们看起来不过是本地智能体的自然延伸。而从那以后，云端智能体能力已经有了很大拓展。

如今，云端智能体运行在各自专用的虚拟机上，拥有独立的环境、依赖项和网络访问能力。它们可以并行工作、无人值守地运行，还能承担比您笔记本电脑上的本地智能体更耗时的任务。

这些能力也带来了环境设置、可靠性和编排方面的挑战；而当智能体运行在您的笔记本电脑上时，这些问题通常并不会这么突出。

在这篇文章中，我们想分享我们在构建云端智能体时学到的几个最重要的经验，以及为什么这项工作如今越来越不像是把本地智能体移植到服务器上，反而更像是围绕它构建一层操作层。

#开发环境本身就是产品

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

在本地，这件事通常不需要您操太多心，因为本地智能体会直接继承您笔记本电脑上现成的开发环境。在云端，您则必须从零开始把这一切重新搭建起来，而更棘手的是，很多时候您很难判断自己是否真的把每个环节都做到位了。

很多时候，不会出现崩溃或错误信息，唯一的信号往往只是输出质量轻微下降。您可能一开始根本察觉不到；即使察觉到了，也可能会把它归因于模型本身。

但我们反复排查后发现，症结总是一样：云端智能体缺少执行或确认其工作所需的环境。一年前，这一点还没那么重要，因为那时模型还不太会利用周围的环境。但随着模型越来越强，环境设置已经成为决定它们能否发挥全部潜力的关键因素。

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

• 为构建智能体环境提供更好的用户工具
• 让智能体 VM 能够在消息之间高效休眠和恢复的方法
• 用于快速、可靠地为 VM 镜像创建检查点、恢复和派生的流水线
• 紧密的 harness 与客户端集成，让智能体和人类都能理解环境并与之交互

随着云端智能体承担越来越多的工作，它们还需要受控的网络访问，用来创建 PR、拉取依赖并开展研究。久而久之，我们实际上构建出了一套面向智能体的企业级 IT 系统，包含机密信息脱敏、网络策略和凭证管理。

#长时间运行智能体需要持久执行

与本地智能体相比，云端智能体面临着另一类可靠性挑战。云端智能体不是在你的笔记本电脑上争抢本地资源，而是在各自隔离的 VM 中运行。这让开发者更容易并行运行多个智能体，并委派那些通常需要数小时而不是数分钟的长时间运行任务。

但在 VM 中运行，也会更容易受到各种中断的影响，比如推理服务提供商故障、pod 需要替换，以及 EC2 节点宕机。

我们最初构建云端智能体时，采用的是 work-stealing 架构：worker 节点可以接手智能体，并通过循环持续执行直至完成。它本质上是把本地行之有效的方案搬到服务器上，但这套架构相当脆弱——早期测试版的云端智能体通常只有 1 个 9 的可靠性。

随着云端智能体逐渐成熟，我们发现自己几乎要重新实现一大批 Temporal 已经解决好的持久执行原语 (例如重试机制、跨机器的任务调度，以及跨节点故障的持久性保障) ，于是我们转而迁移到了 Temporal。

我们当前运行在 Temporal 上的智能体循环，可以扛住推理可靠性的短暂抖动、pod 的休眠与恢复，以及持续数天甚至数周的运行。仅这一次迁移，就让我们的可靠性提升到了 2 个 9 以上；如今，Temporal 每天要处理超过 5000 万个 action，覆盖超过 700 万个唯一工作流。在内部，超过 40% 的 PR 来自云端智能体，而且这一比例还在持续增长。

随着时间推移，我们也逐渐摸索出更合理的 Temporal 工作流架构。我们已经从“永久”运行的智能体工作流，转向多个在完成单个任务后就退出的短工作流，这让版本升级变得更容易。随着异步工具调用、子智能体以及推理服务提供商故障改变了我们的底层假设，我们也将 activities 拆分开来，以便更好地处理超时和重试。

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

云端智能体不再只是一个在单台机器上运行的循环。相反，智能体可能在一台机器上运行，在多台机器上生成异步子智能体，或者先在本地启动，再把工作委派到云端。子智能体甚至可能比父智能体存活得更久，或者运行在完全不同类型的 pod 上。

为了实现这一点，我们发现，最好将智能体循环、机器状态和会话状态保持为彼此解耦的组件。由于智能体循环运行在 Temporal 中，而不是直接运行在 VM 上，我们就可以独立管理 pod 的生命周期，并让智能体在不同类型的 pod 之间运行——包括只读 VM 或预热 VM 等优化方案。

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

#知道何时该退到一边

构建云端智能体 harness，意味着要不断重新评估：哪些行为应该是确定性的，哪些应该交给智能体自行处理。

在早期，我们并不太信任智能体，所以 harness 会在每项任务后再次检查它的工作，强制提交并推送。随着模型越来越聪明，我们开始把逻辑从 harness 中移出，转而放进由智能体控制的工具里。一年前，多仓库设置还需要在 harness 里硬编码行为。现在，我们可以把仓库布局告诉智能体，开放分支和 PR 相关工具，让它自己决定如何完成工作。

CI 自动修复也是如此。早期版本的云端智能体 harness 中，包含了抓取任务失败日志并将其写入 VM 的逻辑。现在，我们只需要让智能体能够访问 GitHub CLI，并自动把大型输出写入可供它搜索的文件中。发给智能体的通知也因此简单了很多，而且我们预计这一趋势还会继续。

harness 并没有消失，真正变化的是它所承载的内容。当前一个很好的例子是计算机操作。我们的云端智能体 harness 为计算机操作提供了专门的子智能体类型，具备自己的模型路由、自定义提示和屏幕录制。VNC 和 Chrome 属于环境的一部分，而这个环境由父智能体和子智能体共享。这让父智能体也能直接使用它们，例如运行 Playwright 脚本。我们使用这套脚手架，是因为模型还没有完全准备好独立处理计算机操作，但是否调用它，仍由智能体决定。

云端智能体在 harness 中也需要与本地智能体不同类型的提示。我们会鼓励它们更自主一些，因为卡住的代价要高得多。在本地，您知道智能体何时停下来并等待许可；但在云端，它可能会一直停在那里几个小时，直到您回去查看。

#自愈型智能体环境

展望未来，我们的重点是跳出“手把手带着智能体做”和“完全放手不管”这种非此即彼的选择。更好的方式，是为智能体提供理解其所处系统环境的工具。

我们希望云端智能体能够在缺少密钥、网络访问受阻，或环境因其他原因妨碍其继续推进时主动报告，并进一步以自愈的方式采取行动。我们在一篇近期的研究博客中讨论了实现这一目标的一条路径，并将其称为“autoinstall”。

仅仅过去几个月，云端智能体就已经取得了巨大的进步，而且我们预计这种演进速度还会继续加快。Cursor 云端智能体让团队无需自行构建或维护底层基础设施，也能充分利用这一不断扩展的能力。