构建云代理的经验教训（12分钟阅读）

# 构建云代理的经验总结 来源：https://cursor.com/blog/cloud-agent-lessons 一年前我们首次推出云代理时，它们看上去只是本地代理的简单延伸。自那时起，云代理的能力已大幅扩展。 如今，云代理在专属虚拟机上运行，拥有自己的环境、依赖和网络访问能力。它们可以并行工作、无人值守运行，并能承担比本地笔记本电脑上的代理更长的任务。 这些能力带来了环境搭建、可靠性和编排方面的挑战，而当代理运行在笔记本电脑上时，这些问题并不那么突出。 在本文中，我们希望分享构建云代理过程中学到的最重要的经验，以及为何这项工作越来越不像将本地代理移植到服务器，而更像在其周围构建一个操作系统层。 ## https://cursor.com/blog/cloud-agent-lessons#the-development-environment-is-the-product 开发环境即产品 过去一年我们体会到，影响云代理输出质量的单一最大因素，是确保它拥有一个完整的**开发环境**（https://cursor.com/blog/cloud-agent-development-environments），就像开发者所拥有的那样。 这在本地环境中不需要过多考虑，因为本地代理直接从你的笔记本电脑中继承了你的工作开发环境。而在云端，你必须从头重建一切，并且很难判断自己是否做得完美。 没有崩溃或错误信息，唯一迹象往往是输出质量出现微妙下降。你可能一开始没注意到，或者即使注意到了，也可能归咎于模型。 但我们反复发现，问题都指向同一个根源：云代理缺少执行或验证工作所需的环境。一年前这还不那么重要，因为模型本身还无法充分利用环境。但随着模型越来越智能，环境设置已成为决定其能否充分发挥潜力的关键因素。 云代理架构 云代理架构 今天，要实现“完整环境”，需要重建相当数量的基础设施： - 更好的用户工具，用于构建**代理环境**（https://cursor.com/blog/cloud-agent-development-environments） - 在消息之间高效休眠和恢复代理虚拟机的方法 - 快速且持久地检查点、恢复和复制虚拟机镜像的流水线 - 紧密的框架与客户端集成，使代理和人类都能理解和交互环境 随着云代理承担更多工作，它们需要受控的网络访问来创建PR、拉取依赖和进行研究。久而久之，我们最终构建了本质上是面向代理的企业IT系统，包含秘密脱敏、网络策略和凭证管理等组件。 ## https://cursor.com/blog/cloud-agent-lessons#long-running-agents-need-durable-execution 长时间运行的代理需要持久化执行 云代理带来了与本地代理不同的可靠性挑战。它们不在你的笔记本电脑上争夺本地资源，而是在各自隔离的虚拟机中运行。这使得开发者更容易并行运行多个代理，并委托那些通常需要数小时而非数分钟的长时间任务。 但是，在虚拟机中运行会暴露于推理服务中断、Pod需要替换、EC2节点宕机等干扰。 我们最初采用任务窃取架构构建云代理，工作节点可以拾取代理并循环直至完成。这种架构将本地工作方式移植到了服务器上，但设置很脆弱——我们早期的云代理测试版通常只有一个9的可靠性。 原始云代理架构 原始云代理架构 随着云代理的成熟，我们发现自己快要重建很多Temporal已经解决的持久化执行原语（如重试机制、跨机器调度工作、跨节点故障的持久性），因此我们转而迁移到Temporal。 基于Temporal的当前云代理架构 基于Temporal的当前云代理架构 当前我们在Temporal上的代理循环能够承受推理可靠性的波动、Pod休眠和恢复，以及跨越数天甚至数周的执行。仅这一迁移就使我们的可靠性超过了两个9。如今，Temporal每天处理超过5000万次动作，覆盖超过700万个独立工作流。内部来看，超过40%的PR来自云代理，且这一比例还在增长。 云代理合并到Cursor单仓库的PR比例随时间变化 云代理合并到Cursor单仓库的PR比例随时间变化 随着时间的推移，我们学会了如何更好地架构Temporal工作流。我们从“永久”代理工作流转向了多个更短的工作流，这些工作流在完成单个任务后退出，这使得版本升级更加容易。我们还拆分了活动，以便更好地捕获超时和重试，因为异步工具调用、子代理和推理服务中断改变了我们的底层假设。 云代理工作流中每天执行的Temporal动作 云代理工作流中每天执行的Temporal动作 ## https://cursor.com/blog/cloud-agent-lessons#decoupling-agents-and-machines-from-conversation-state 将代理和机器与会话状态解耦 云代理不再只是单台机器上的一个循环。相反，一个代理可能在一台机器上运行，在多个机器上生成异步子代理，或者从本地启动然后将任务委托到云端。子代理甚至可能比它的父代理存活得更久，或者在完全不同的Pod上运行。 解耦了代理、机器和会话状态的云代理循环 解耦了代理、机器和会话状态的云代理循环 为了实现这一点，我们发现将代理循环、机器状态和会话状态保持为解耦组件非常有价值。由于代理循环位于Temporal中而非虚拟机本身，我们可以独立管理Pod生命周期，并在不同类型的Pod上运行代理——包括只读虚拟机或预热虚拟机等优化。 在会话方面，我们将存储和流式传输层与核心代理工作流分离。我们构建了一个高效的只追加存储机制，将会话更新流式传输到Web和桌面客户端。这一层考虑了重试机制，因此如果代理循环的某个步骤在流式传输部分输出后失败并重试，客户端能够检测到、回退流，并显示新数据而非旧数据。 ## https://cursor.com/blog/cloud-agent-lessons#knowing-how-to-get-out-of-the-way 知道如何让路 云代理会话流程 云代理会话流程 构建云代理框架意味着不断重新评估有多少行为是确定性的，有多少交给代理处理。 早期，我们不太信任代理，因此框架会在每个任务后双重检查其工作，强制提交并推送。随着模型变得更智能，我们开始将逻辑从框架中移出，放到代理控制的工具中。一年前，多仓库设置需要硬编码的框架行为。现在，我们可以给代理仓库布局，公开用于分支和PR的工具，让它决定如何完成工作。 CI自动修复也是如此。早期版本的云代理框架包含获取作业失败日志并将其写入虚拟机的逻辑。现在，我们只需让代理访问GitHub CLI，并自动将大输出写入它可搜索的文件中。给代理的通知变得简单得多，我们预计这一趋势将继续。 框架并没有消失，而是其包含的内容在变化。计算机使用就是一个很好的例子。我们的云代理框架有一个专门的子代理类型用于计算机使用，配有独立的模型路由、定制提示和屏幕录制。VNC和Chrome属于环境，由父代理和子代理共享。这使得父代理可以直接使用它们，例如运行Playwright脚本。我们使用这一脚手架，因为模型还不能完全独立处理计算机使用，但代理仍然控制何时调用它。 云代理在框架中也需要比本地代理不同类型的提示。我们鼓励它们更加自主，因为阻塞的成本更高。在本地，你知道代理何时停止并等待许可；但在云端，它可能在你返回检查之前，在那里坐等数小时。 ## https://cursor.com/blog/cloud-agent-lessons#self-healing-agent-environments 自我修复的代理环境 展望未来，我们专注于超越在“牵着代理的手”和“让路”之间的二元选择。一个更好的模式是给代理提供理解周围系统的工具。 我们希望云代理能够报告秘密缺失、网络访问被阻止，或环境阻碍其进展的情况，然后以自我修复的方式行动。在**最近的研究博客**（https://cursor.com/blog/bootstrapping-composer-with-autoinstall）中，我们讨论了一种实现这一目标的路径，称为“自动安装”。 仅在过去几个月里，云代理就有了巨大的改进，我们预计变化的速度只会从这里加快。Cursor云代理让团队能够利用这一广阔的领域，而无需构建或维护底层基础设施。