现在有很多给 cloud agents 用的 server-side sandbox 服务，比如 @modal ，但是却不太看到有给用户自己的 local agents 用的 client-side sandbox。这里应该是有一个开源库的生态位置，来满足开发者在应用中允许用户隔离环境运行 local agents 的需求的，否则权限管理是大麻烦。

Cursor 推出Self-Hosted Machines自托管机器： 企业本地执行，Cursor 负责云端推理 Cursor 推出了 Self-Hosted Machines： 允许 Cloud Agents 在企业自有机器上执行文件、终端、浏览器和本地 MCP 操作； 智能体循环、推理和规划仍在 Cursor 云端运行。 此前，Cloud Agents 默认在 Cursor 管理的远程虚拟机中运行。 现在，执行环境可以换成公司内网服务器、企业云主机、Mac、GPU 机器或本地设备；任务规划、模型推理和会话管理仍由 Cursor 云端完成。

SpaceXAI 工程师 Lauren Tan（@poteto）一场 AMA 对谈，基本是她本人出镜答问。中间闪过六人视频会议画面。没有白板、没有录屏。 她讲的核心不是逐个催 Bot。多个 Bot 可以共用一台底层电脑，但记忆和聊天记录分开。 复杂活适合专岗小队；Chief of Staff 当唯一入口，负责分派。她的 Bot 当外环：接 Slack、邮件、日历这类外部集成，再触发 Cursor 里的内环，拉起 cloud agents。 Bot 里暂时不能随意换模型，派出去的 cloud agents 可以用任意模型。举例：盯 Slack 反馈频道 → 触发 Cursor 内环 → 用 potato mode 开云 Agent。 Agent 团队先养参谋，再扩工人。别把自己变成催办员

我用 xBubble Coding 做了一个 Nexus-Group 社交电商平台后，才明白它为什么不像 Cursor，更像 OPC 的商业基础设施 xBubble 的核心定位是 low-prompt AI agent，用户只需陈述商业目标，系统便会自动调用 Bubble Pilot 进行任务拆解，利用 Bubble Engine 生成并测试任务级 SOP。 在 Work Mode 下，Website Development 被作为现成能力直接调用，这种意图驱动的开发模式，让构建一个复杂的 Web3 协议产品变得像发一条社交动态一样简单。 我用 @dappOS_com 的 @xBubble_ai 生成出来了一个逻辑清晰的电商协议。Nexus-Group 的核心视觉、以社交拼团为核心的 CTA、以及拼团挖矿 / 智能撮合 / 稳定币支付 / NXG 治理奖励为核心卖点的四段式信息架构，逻辑清晰。 用户先通过钱包登录，进入拥有 $NXG 代币余额、每日签到、AI 智能推荐商品的 Home 页；然后可以切到拼团引擎页面，查看正在进行的拼团活动，支持一键发起或加入；再往后还有 AI 智能撮合的订单管理、资产中心、以及一整套从下单到链上结算的完整闭环。

欢迎大家前来体验 AI coding 的价值从来不只是更快地补代码，而是更快地把一个想法变成能被用户理解、能被传播、甚至能被继续商业化的产品外壳。 xBubble 强调用户不需要学习如何搭模型、选工具、写复杂 prompt；真正做这些学习和组合工作的，是 Bubble Engine 和 Bubble Pilot。 Cursor 主打 agents、cloud agents、MCPs、skills、hooks，以及让开发团队把想法更快变成代码；Claude Code 是能 reads your codebase, edits files, runs commands 的 agentic coding tool；OpenAI 的 Codex 则进一步强化了 command center for agentic coding 的定位，强调并行 agent、cloud environments、worktrees，以及面向 Business 和 Enterprise 的 hosted sites 能力。 这些产品大多仍然在把软件开发做得更高效这条线上继续演进；而 xBubble 正在做的，是把问题重新定义成怎样让一个不懂技术的人更快跑通一门生意。 这意味着如果一个 AI coding 产品不仅能生成页面，还能天然朝钱包登录、稳定币支付、链上记录、数字资产所有权这些方向延伸，它面对的就不只是帮人做个网站的市场，而是帮普通人低成本试运行全球化生意的市场。 它已经展示出一种非常清晰的产品方向：未来很多高利润、强时效、强垂类、强非标的小生意，未必需要先组技术团队，再写 PRD，再搭开发环境；它们更可能先由一个懂用户、懂机会的人，用一句需求把第一版产品拉出来，再决定要不要继续打磨、投流、接支付、做增长。 AI Coding 的进化终点，正在让普通人以极低的成本，拥有试运行全球化生意的底气。

推荐这篇，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#