Cursor 6月初发了一篇「What we've learned building cloud agents」，标题听起来像复盘笔记，但读下来发现这是目前 Cursor 最诚实的一篇工程文档。它没有讲功能，讲的是架构选择——每一条"lesson"背后都是一个曾经踩过的坑，以及为什么最终走到了现在这条路。

最反直觉的教训：环境不是搭完就好的基础设施

Cloud agent 质量最大的影响因素，不是模型能力，不是提示词技巧，而是 agent 有没有完整的开发环境。这个结论听起来平淡，但细想很反直觉。

本地 agent 天然继承开发者的完整环境——本地电脑上的依赖、配置、工具链，都可以直接用。Cloud agent 跑在独立 VM 里，环境是从零重建的。问题在于，环境不完整时 agent 不会报错，只会在你没注意的地方悄悄降级输出质量。

这是一个很难 debug 的问题：代码跑通了，输出看起来合理，但仔细看发现有微妙的不对。大多数人会以为是模型不够聪明，Cursor 花了很长时间才追踪到真正原因：环境不完整。

这个教训对整个 AI coding 工具行业都有参考价值。当模型越来越强，环境的短板效应会越来越明显。再强的模型，读不到需要的依赖、写不进正确的路径，产出就会在你不察觉的地方打折。

从 Work-stealing 到 Temporal：可靠性的工程账

Cursor 最早做 cloud agent，用的是 work-stealing 架构——worker node 抢任务，loop 到完成。这套思路在单机本地场景够用，但云端有太多不可控因素：inference provider 中断、pod 需要休眠和恢复、EC2 节点宕机。Cursor 早期 cloud agent 的可靠性大约只有一个 9。

他们最后选择集成 Temporal，而不是自己造一个可靠执行层。Cursor 团队的原话是：我们在重建 Temporal 已经解决的那些原语（retry 机制、跨机器调度、节点故障下的 durability）。自己重建不如直接用。

这个决策很值得思考。工程上"自己造还是用现成"是个常见选择题，但 AI agent 领域很多团队会选择自己造——因为不确定性太大，担心被外部依赖绑架。Cursor 选择信任 Temporal，背后是对系统可靠性需求的诚实评估：耐久执行是个工程问题，不是个 AI 问题，值得交给专业方案。

现在 Temporal 每天处理超过 5000 万次 action、700 万个独立 workflow，Cursor 内部超过 40% 的 PR 来自 cloud agents。这个数字比任何 benchmark 都有说服力。

三个解耦：Agent loop、机器状态、对话状态

Cloud Agent Lessons 里最有价值的工程洞察是三个组件的解耦：

Agent loop 跑在 Temporal 上，而不是 VM 本地。 这意味着 pod 的生命周期可以独立管理，agent 可以在不同类型 pod 间调度——包括 readonly VM、prewarmed VM 等优化。Pod 可以随时暂停、恢复、销毁，agent 的执行不受影响。

对话状态从 agent loop 分离。 Cursor 做了 append-only 的存储机制，把对话更新流式推送给 web 和 desktop 客户端。重试时客户端可以检测到"这个步骤在重试后会吐出不同的内容"，主动回滚流再显示新数据，而不是同时显示新旧两份。这个细节解决的是流式输出在并发重试场景下的 UI 一致性问题。

机器状态和 agent loop 独立。 Cloud agent 不再是一个 loop 跑在一台机器上。它可能在一台机器启动，然后 spawn 异步 subagent 跑在别的 pod 上，parent agent 甚至可能在 subagent 还在跑的时候就退出。

这种架构选择背后的逻辑是：cloud agent 的复杂度已经从"把本地 agent 搬到服务器"变成了"构建一个多节点协作的分布式系统"。把各个 concerns 分离是管理这种复杂度的唯一方法。

Harness 的边界：什么时候该管，什么时候该放手

Cursor 早期对 agent 不够信任，harness 里塞了很多确定性逻辑：每完成一个任务就 double-check，强制 commit，强制 push。后来模型变强，他们开始把逻辑从 harness 移到 agent 可控的工具里。

一个具体例子：一年前多 repo 场景需要 harness 里写硬编码逻辑；现在只需要把 repo 布局和 PR/branch 工具暴露给 agent，让它自己决定怎么做。再比如 CI Autofix 场景，早期 harness 会抓取失败日志写到 VM 里让 agent 处理；现在直接给 agent 访问 GitHub CLI，大输出自动写到文件，agent 自己决定怎么处理。

这并不是说 harness 越来越小，而是 harness 的内容在改变：从"替 agent 做决定"变成"为 agent 提供可组合的工具"。Computer use 是目前的边界案例——Cursor 的 harness 里有一个专门的 subagent 类型来处理，需要自己的模型路由、自定义提示词、屏幕录制。VNC 和 Chrome 属于环境，在 parent agent 和 subagent 间共享。这套 scaffold 是因为模型还没准备好独立处理 computer use，但关键是：这套能力是作为工具暴露给 agent 的，不是 harness 直接代劳。

为什么这不只是 Cursor 的内部文档

Cloud Agent Lessons 的内容，对整个行业有几层意义：

第一层——它证明了 cloud agent 的可靠性问题可以被工程化解决，不靠等模型变强，靠的是架构选择。Temporal 方案、三个解耦、环境完整性检查，这些是系统层面的投资，不是调提示词能解决的。

第二层——它揭示了一个趋势：cloud agent 的复杂度已经需要"enterprise IT for agents"。Secret redaction、网络策略、凭证管理、定制的开发环境……Cursor 在做的不只是 AI 编程工具，是在建一套让 agent 安全运行的企业级基础设施。

第三层——它回答了"Cursor 和竞品到底在竞争什么"。GitHub Copilot 在"增强人的能力"，Cursor 现在在做的是"构建 agent 执行层"。这是两个不同层次的东西，后者更难，但护城河也更深。

Cloud Agent Lessons 是 Cursor 少有的技术深度文档，透露的工程选择比功能发布更有营养。当团队开始讨论"要不要自建"和"用什么架构"，背后的决策框架往往比最终结论更能启发其他做类似事情的人。

本期覆盖：Cloud Agent Lessons（2026-06-02）架构复盘、Improvements to Cursor Automations v3.8、Cloud Subagents in Agents Window