构建云代理的教训：Cursor的经验分享

Cursor团队在构建云代理的过程中积累了丰富的经验。最初，他们认为云代理只是本地代理的自然延伸，但很快发现，由于云代理运行在独立虚拟机上，拥有自己的环境、依赖和网络访问权限，它们能够并行工作、无需人工值守，并处理更长时间的任务。然而，这也带来了环境搭建、可靠性和编排方面的挑战。

开发环境是影响云代理输出质量的最关键因素。本地代理可以直接继承开发者的工作环境，但在云端，必须从头重建整个环境。即使环境不完美，也不一定会导致崩溃或错误信息，而只是输出质量的微妙下降。随着模型能力增强，环境配置已成为决定代理能否充分发挥潜力的关键因素。为此，Cursor团队重建了大量基础设施，包括更好的用户工具、高效的休眠与恢复机制、快速检查点与恢复以及紧密的集成。

长期运行的云代理面临可靠性挑战。它们运行在隔离的虚拟机中，容易受到推理提供商故障、节点替换等中断的影响。起初，Cursor采用了“工作窃取”架构，但可靠性仅达到一个9。后来迁移到Temporal平台，实现了耐久执行，能够抵御推理中断、pod休眠与恢复等问题，可靠性提升到两个9以上。目前，Temporal每天处理超过5000万次操作，Cursor内部超过40%的PR来自云代理。

为了实现灵活性和可扩展性，Cursor将代理循环、机器状态和对话状态解耦。代理循环运行在Temporal上，而非虚拟机内，从而可以独立管理pod生命周期。对话存储和流式传输层与核心代理工作流分离，采用高效的追加存储机制，并支持重试和流回退。

随着模型智能的提升，Cursor逐渐减少了对代理的严格控制。早期，系统会在每个任务后强制提交和推送；现在，代理可以自主决定如何工作。例如，多仓库设置不再需要硬编码的行为，CI自动修复功能也赋予了代理更多工具。计算机使用功能目前仍需要专门的子代理和定制提示，但代理可以自行决定何时调用。此外，云代理的提示鼓励更高自主性，因为等待人工响应的成本更高。

展望未来，Cursor致力于让云代理具备自愈能力，能够报告问题并自主修复。例如，代理可以检测缺失的密钥或网络阻塞，并采取行动。近期研究中的“自动安装”是实现这一目标的一个方向。云代理的能力在过去几个月显著提升，预计还将加速发展。Cursor的云代理让团队能够利用这一广阔空间，而无需自行构建和维护基础设施。