这不是简单把 Agent 放到云上
Conductor 和 Vercel Sandbox 的案例，真正有价值的地方不是远程跑命令，而是把并行编码 Agent 从本机资源限制里解放出来。一个开发者可以同时开多个隔离 workspace，让不同 Agent 在不同分支上推进任务，然后自己负责 review、合并和继续指挥。这种模式对 AI 编程产品很关键，因为本地机器的 CPU、内存、电量和网络，都会限制 Agent 的数量和运行时长。
核心工作流怎么理解
Conductor 原来的体验是本地 GUI 管多个 coding agent。用户喜欢这种并行感，但硬件很快成为瓶颈。迁到 Cloud Workspaces 后，每个 workspace 在远程 sandbox 里运行，本地界面不需要明显改变。开发者仍然像管理本地任务一样创建、查看、合并和重定向 Agent，只是执行环境变成了云端隔离机器。
架构上要补哪些能力
- 每个 Agent 必须绑定独立分支或独立工作区，避免多个 Agent 写同一份文件。
- 远程 sandbox 要支持快速启动、快照、持久文件系统和安全销毁。
- 本地 UI 只做指挥和审查，不承担长时间执行。
- 代码输出必须回到可 review 的 diff，而不是直接写进主分支。
- 所有命令、日志、失败原因和最终 patch 都要能回放。
适合哪些团队先试
最适合的是任务拆分比较清楚、review 文化成熟、CI 反馈稳定的工程团队。例如一个产品改版可以拆成前端组件、接口适配、测试补齐、文档更新四个分支并行跑。每个 Agent 不需要知道整个世界，只需要在自己的 sandbox 里解决一小块问题。人类工程师则负责选择哪个结果进入主线，哪些分支需要继续迭代。
不要忽略安全边界
远程 sandbox 跑的是代码和命令，安全边界必须比本地更清楚。要限制密钥注入范围，禁止默认访问生产凭据，网络出口要可控，文件系统要按 workspace 隔离。Agent 需要拉依赖、跑测试、访问 issue 或 PR 时，最好通过最小权限 token 和临时凭据完成。sandbox 关闭后，凭据和临时文件要能确定地清理。
产品体验上的关键点
用户不能被迫理解远程执行细节。好的体验应该是，创建任务、等待结果、查看 diff、追问 Agent、合并分支这些动作保持一致。真正需要暴露的是状态和证据，哪个 Agent 正在跑、卡在哪个命令、用了多少时间、产生了哪些文件、CI 是否通过。云端能力如果只增加不透明感，就会降低信任。
建议产出
如果你要为自己的团队设计并行编码 Agent，可以先画一张工作区生命周期图，从创建、拉代码、注入上下文、启动 Agent、执行命令、产出 diff、人工 review、合并或销毁。只要生命周期图里有一个环节说不清权限和状态，就说明云端 Agent 还不能放心交给更多人使用。