推荐这篇,Cursor 把一年来构建云端 agent 的工程经验全部写了出来——从单 9 到双 9 的可靠性、从 work-stealing 到 Temporal 的架构迁移、agent 和机器状态与对话状态的解耦、环境自愈。如果你们团队在做 agent 基础设施,这篇等于一个季节的架构文档。
Cursor 构建云端 agent 的工程经验
一年前云端 agent 看起来像本地 agent 的直接延伸。现在它们在独立 VM 上跑,有自己的环境和依赖,能并行工作、无人值守、处理比笔记本上更长的任务。
开发环境就是产品本身
过去一年最大的教训:云端 agent 输出质量的最关键因素不是模型,而是它是否有完整的开发环境。本地 agent 免费继承你笔记本的工作环境。云端你得从零重建,而且很难感知你做得不完美。不是报错——只是输出质量微妙的下降。你第一次可能注意不到,或者注意到之后归咎于模型。一遍又一遍,我们发现根因是同一个:云端 agent 没有它需要的环境来执行或验证自己的工作。一年前这不重要因为模型也用不好环境。但当它们变聪明后,环境设置变成了它们是否能发挥全部潜力的决定因素。
现在要达到"完整环境"需要重建大量基础设施:用于构建 agent 环境的用户工具、高效休眠和恢复 agent VM 的方法、快速持久检查点/恢复/分支 VM 镜像的管道、紧密结合的 harness 和客户端集成。而且随着云端 agent 承担更多工作,它们需要有控制的网络访问来创建 PR、拉取依赖和做研究。Cursor 最终建了企业 IT 给 agent——完整的秘密信息脱敏、网络策略和凭证管理。
长时间运行的 agent 需要持久执行
云端 agent 跑在隔离 VM 里,而不是笔记本上,更容易并排跑很多 agent 和委派几小时的长任务。但运行在 VM 里暴露了模型服务端宕机、pod 替换、EC2 节点挂掉的风险。
最初用 work-stealing 架构——worker 节点抓取 agent 并循环到完成。早期 beta 经常只有单 9 可靠性。
后来迁移到 Temporal。当前在 Temporal 上的 agent 循环能扛过推理可靠性波动、pod 休眠恢复、跨几天甚至几周的运行。迁移后达到双 9 可靠性,现在每天处理 5 千万次操作、7 百万个独特工作流。内部超过 40% 的 PR 来自云端 agent,且仍在增长。
Cursor 的 Temporal 架构也在进化:从"永恒"agent 工作流变成了多个运行后退出、每完成一个任务退出的短工作流,版本升级更容易。拆分活动以更好地捕获超时和重试。
解耦 agent 和机器状态与对话状态
云端 agent 不再是一个循环跑在一台机器上。它可能在机器 A 跑、在 B 和 C 上孵化异步子 agent、从本地开始然后委派到云端。子 agent 可能比父 agent 活更久,跑在完全不同类型的 pod 上。
关键是保持 agent 循环、机器状态和对话状态解耦。agent 循环在 Temporal 里而非 VM 上,就能独立管理 pod 生命周期,在只读 VM 或预热 VM 上跑 agent。
对话层:分离了存储和流层。高效的只追加存储机制将对话更新流到 web 和桌面客户端。这一层处理重试——agent 循环的某步在流了部分输出后失败了然后重试了,客户端能检测、回退、展示新数据而不是旧的。
知道什么时候让开
早期不相信 agent,harness 每个任务后都检查、强制 commit、推送。现在把逻辑从 harness 移出来变成 agent 控制的工具。一年前多仓库设置需要硬编码 harness 行为。现在给 agent 仓库布局、分支和 PR 工具,让它自己决定。
harness 不会消失,但它包含的内容在变。Computer use 是个例子——云端 agent harness 有专用的子 agent 类型给 computer use,有自己的模型路由、custom prompt 和屏幕录制。但因为模型还没准备好自己处理 computer use,harness 保留了脚手架。
云端 agent 还需要不同的 prompt——鼓励更高自治性,因为本地 agent 能看见停了在等权限,云端可能是几小时后你才回来检查。
自愈式 agent 环境
未来不在"手把手管"和"放手不管"之间二选一。更好的模式是给 agent 理解和操作系统环境的工具。让它们能报告缺失密钥、网络被阻、环境阻止了进展,然后自愈。
原文:Cursor (Josh Ma), "What we've learned building cloud agents", 2026-06-02
#
Agent工程# #
云端基础设施# #
Cursor#