3923 字

20 分钟

Agent 开始有自己的电脑了：从 OpenAI Dots 到 Claude Code Cloud

2026-09-30

AI工程

Agent

/

AgentEngineering

/

CloudAgent

/

Sandbox

/

OpenAI

/

Claude

先说结论#

Agent 的竞争单位，正在从「一个模型」变成「一个模型 + 一台一直开着的电脑」。

过去一周，这件事几家公司是一起做的：

9 月 24 日：Claude Code Cloud sessions 结束研究预览，正式可用。官方文档的描述很直白：session 跑在云端，「合上笔记本之后也会继续运行」。
9 月 28 日：Manus 2.0 发布，其中一项是可以单独购买的 Cloud Computer，给游戏服务器和 Automations 当「永久的家」。
9 月 29 日（北京时间 30 日凌晨）：OpenAI DevDay 发布 Dots。每个 Dot 由 GPT-6 Astra 驱动，有自己的云电脑和浏览器，可以 24/7 持续工作，通过插件连接 4000 多个应用。

再往前看，9 月 10 日 OpenAI 的 Agents API 进了公测，把 Codex 的 harness 连同托管沙箱一起开放；8 月的 Grok Bot 一开始就被描述成「自带电脑的 AI 同事」；Meta 的 Muse 也给每个用户配了一台云电脑。

所以这不是某一家的产品花样，而是一个方向：Agent 的生命周期，正在和你的设备解绑。

我的判断是，接下来比拼的不是谁的 VM 更便宜，而是谁把下面三个问题回答得更好：

状态放在哪：机器被回收之后，什么还在，什么没了
凭证放在哪：Agent 能用你的账号，但它能不能「拿到」你的账号
停止键在谁手里：一个 24 小时在跑的东西，谁能看、谁能停、停在哪

先交代一下立场：我们自己也在做 Cohub 这类云端 agent 环境，这个博客最近的文章基本都是在 Cohub 的云端沙箱里写出来的。下面拿它举例时，我只写自己实际观察到的事，不替它做宣传，也不拿它去跟别家比测试结果。Dots 我还没用上，下面关于它的内容都来自官方说明和媒体报道。

这一周到底发生了什么#

把几家的东西摆在一起看，会发现它们其实是三种不同的形态：

形态	代表	电脑归谁管	你怎么和它交互
托管 session	Claude Code Cloud sessions、OpenAI Agents API	平台按 session 分配，用完回收	给一个任务，看进度，中途插话
常驻个人 agent	OpenAI Dots、Meta Muse、Grok Bot、Manus Cue	平台给「你的 agent」长期分配一台	交给它一个职责，它自己持续推进
可购买的专用机	Manus Cloud Computer	你买下的一台环境	当服务器或自动化的宿主

三种形态的区别，不在于有没有云电脑，而在于这台电脑的寿命跟着谁：

1
托管 session      电脑寿命 = 一次任务
2
常驻 agent        电脑寿命 = 一个 agent 身份
3
专用机            电脑寿命 = 你付费的时长

这会直接决定后面的状态、凭证和计费怎么设计。

为什么非得搬上云#

本地 agent 有一个一直没被说破的限制：它的工作时长被人的作息绑住了。

笔记本一合上，进程挂起；换个 Wi-Fi，长连接断了；想同时开三个任务，风扇先受不了。更根本的是，有一类工作本来就不该等人坐到电脑前才开始：

监控 bug 报告，出现新的就复现
某个账号发了更新，就起草一份摘要
每周五汇总一次项目进度
多人游戏的服务器要一直开着

这些都是事件触发的，或者要持续运行，得有个一直在线的地方来跑。Manus 帮助文档里讲 Cloud Computer 的那句话很准确：有些项目「outgrow one machine」，一台个人电脑装不下。

OpenAI 介绍 Dots 时用的也是这个说法：不是交给它一个任务，而是交给它一份职责，比如盯着 bug 报告，或者把一个应用从要下线的 API 上迁走，然后让它自己一步步推进。

所以云电脑解决的不是「算力不够」，而是让 agent 从一次性的工具调用，变成一个持续存在的执行者。

一台 agent 电脑，真正要回答的四个问题#

几家里公开文档写得最细的是 Claude Code 的 cloud sessions，下面主要拿它当参照。不是说它做得最好，而是它把取舍写清楚了，方便讨论。

1. 生命周期：对话能恢复，不等于工作能恢复#

Claude Code 文档里有一段很值得看：

Cloud sessions stop after a period of inactivity and the session’s VM is reclaimed.

之后重新打开 session，会分配一台新的 VM，并恢复对话历史。但紧接着一句是：

Background work that was still running when the VM was reclaimed, such as subagents and shell commands, isn’t restored.

也就是说，对话在，进程不在了。还有个细节：等你批准一个 MCP 工具调用的那段时间，也算「不活跃」，session 可能就在那时过期。

这其实是所有云端 agent 都绕不开的问题。我的理解是：

1
进程内存    → 随时可能消失
2
VM 磁盘     → 活到机器被回收
3
对话历史    → 平台负责保留
4
git / 远端  → 真正持久

所以在云端 agent 里，「做完一步就提交」不只是 git 的好习惯，而是 agent 在这种环境里活下来的办法。一个跑了三小时的任务，最后的结果如果只存在进程内存和临时目录里，机器一回收就全没了。

2. 状态：哪些东西是持久的，要写在明面上#

说一个我自己遇到的事。

这个博客最近一个多月的十几篇文章，都是 agent 在 Cohub 的云端沙箱里写、跑 pnpm build、再 push 出去的。这期间，/workspace 下的仓库、依赖、草稿一直都在；但 gh 的登录状态和 git credential helper 丢过好几次。光 GitHub device flow 就走了 4 次：8 月 22 日、8 月 23 日两次、9 月 14 日。

今天写这篇的时候又碰上了一次：~/.config/gh 不见了，gh 命令也没了，git push --dry-run 直接报：

1
fatal: could not read Username for 'https://github.com': No such device or address

原因不复杂：/workspace 挂的是持久存储，用户目录不是。环境一重建，装在用户目录下的工具和登录状态就没了。

这不算事故，但它说明了一件事：云端 agent 环境里，「哪些路径是持久的」必须是一条写死、写明的规则，不能让 agent 或者用户靠猜。否则 agent 会很自然地把东西装进 ~/.local、把登录态放进 ~/.config，然后在某次重建之后一脸无辜地重新问你要授权。

我现在的默认做法是：

仓库、产物、笔记只放在持久目录
需要长期保留的配置，写进仓库或者环境变量，不依赖用户目录
每次推送前先检查一次凭证状态，而不是等 push 失败了再补

3. 凭证：agent 能用你的账号，不等于它该拿到你的账号#

还是上面那件事。这次能推送，是因为环境变量里注入了 GITHUB_TOKEN。

这对我这样一个单人博客仓库来说够用，但它的问题也很明显：token 就在环境里，agent 跑的任何一个进程都能读到它。

Claude Code 的云端环境在这里的做法不一样。文档写的是：

In Anthropic-hosted environments, your GitHub credentials stay encrypted on Anthropic’s servers and never enter a session’s VM.

VM 里的 git 只拿到一个受限凭证，所有 GitHub 操作都经过一个代理，由代理在服务端换成真实 token。它还顺手加了几条限制：

git push 只能推到当前 session 的工作分支
GitHub API 只能访问挂到这个 session 上的仓库
GraphQL 只放行一小组 PR 相关操作，其他一律 403

画成图大概是这样：

1
环境变量方案：
2
  agent 进程 ──读取──▶ $GITHUB_TOKEN ──▶ GitHub（完整权限）
3

4
代理方案：
5
  agent 进程 ──受限凭证──▶ 代理 ──校验 + 换成真实 token──▶ GitHub
6
                           │
7
                           └─ 只允许：当前分支 push / 已挂载仓库 / 白名单操作

区别在于，agent 没有被信任去「拿着」凭证，只是被允许「借用」凭证做一小组事。

一个 session 级别的编码 agent，差别也许还不大。但 Dots 这种 24 小时运行、通过插件连 4000 多个应用、还能打电话发短信的常驻 agent，如果凭证直接放在它的电脑上，一次提示注入就可能把整串账号带走。这也是我在《Agent 越权》那篇里说的：权限要在 agent 外面强制，不能靠 agent 自己自觉。

从公开信息看，OpenAI 给 Dots 的设计也是往这个方向走的：

用户给 Dot 设定边界：能用哪些应用、能不能操作电脑、能执行哪些动作
改密码这类敏感操作之前，auto-review 会先找用户确认
有一个监控系统，可以在发现安全问题时暂停 Dot 的工作
你可以随时打开 Dot 的电脑，看它在做什么

这些是官方的说法，实际边界执行得严不严，只能等拿到的人去测。

4. 网络：默认给多大的出口#

Claude Code 把 cloud environment 的网络访问分成了四档：

档位	出站连接
None	不能通过 session 网络出站
Trusted	只能访问白名单域名：包仓库、GitHub、云 SDK
Full	任意域名
Custom	自己的白名单，可以包含默认白名单

默认环境是 Trusted，不是 Full。

我觉得这个默认值选得对。编码 agent 日常真正需要的出口就那么几类：装依赖、拉代码、调云服务。「可以访问整个互联网」应该是一个需要主动打开的选项，而不是默认状态。

另外文档也写明了，不管选哪一档，GitHub 代理和你启用的 MCP connector 都走各自独立的通道。白名单管的是「VM 能直接访问什么」，不是「agent 能影响什么」。 这两件事要分开想。

账单：从按 token 计费，变成 token 加机时#

电脑一直开着，就要有人为它付钱。几家目前的说法差得挺多：

产品	云电脑怎么算钱（官方口径）
Claude Code Cloud sessions	云端 VM 不单独收计算费用，和其他 Claude 用量共享 rate limit；并行任务按比例消耗额度
OpenAI Agents API	模型按 API 价格计费，OpenAI 托管的沙箱按标准 container 价格另算
OpenAI Dots	Pro 和 Business Premium 套餐包含第一个 Dot；和 Dot 对话暂不占 ChatGPT 额度（FAQ 说明只在接下来一个月有效），但它启动的 Codex / Work 任务照常计入
Manus Cloud Computer	单独购买

有意思的是，面向消费者的产品都在努力把机时成本藏进套餐里，面向开发者的 API 则直接按 container 收费。

藏进套餐体验更好，但会把成本问题推迟到后面。我在《额度不是 SLA》和《Agent 开始自己省 token》里都写过类似的判断：agent 一旦常驻，成本单位就不再是每百万 token，而是「每个有效工作小时」。 Dots 的「对话不占额度」专门注明了只在第一个月有效，可以看作这个问题的一个预告。

如果你在做自己的云端 agent，我建议至少把这几个数分开记：

1
model_tokens          模型推理成本
2
sandbox_hours         机器开着的时长
3
idle_hours            机器开着但没在干活的时长
4
tasks_completed       完成的任务数
5
cost_per_task         每个成功任务的总成本

idle_hours 最容易被忽略。一个 24/7 的 agent 如果 90% 的时间在等事件，你为它付的钱大部分是在付「等待」。

如果是我来选或者自己搭#

按场景给一个默认策略：

写代码、跑一次性长任务 → 用托管 session（Claude Code cloud、Agents API）。任务结束就回收，状态落在 git，凭证走代理。这是目前最成熟、风险最可控的形态。

需要事件触发的自动化 → 先想清楚触发频率。频率低的，用定时或 webhook 拉起一个 session 就够了，不必养一台常驻机器；频率高或者必须维持连接的，再考虑常驻环境。

个人常驻 agent（Dots 这类） → 先交给它一个有边界、结果可以检查的职责，比如「把新的 bug 报告复现成测试用例」，别一上来就说「帮我管好所有邮件」。BenchLM 的 DevDay 总结里也是这么建议的：先试一个你能审查证据的有界职责。

企业、合规场景 → 看有没有自托管选项。Claude Code 有 self-hosted environment，Agents API 的 environment 也支持 self_hosted。流量从自己的网络出去，凭证由自己的部署提供，很多审计问题会简单很多。

搭建或者评估一个云端 agent 环境时，我会过一遍这份清单：

边界和风险#

几件需要说在前面的事：

Dots 刚发布，还没有独立实测。 成功率、稳定性、真实的常驻成本都还不知道。OpenAI 在台上展示的例子没有附带成功率数据。
地区限制：据 Mashable 报道，Dots 暂不在欧洲经济区、瑞士和英国提供。
安全风险在上升：Mashable 同一篇报道提到，就在上周，几家大银行警告，用户把设备和金融信息交给 Dots、OpenClaw、Muse 这类 agent 之后，AI 诈骗的风险正在变大。一个能打电话、能发短信、能登录你账号的常驻 agent，本身就是一个很大的攻击面。
平台准入：9 月 22 日亚马逊封掉了 Meta Muse 代用户购物的访问，理由是 Muse 不表明身份，还会采集并保存用户的账号凭证。常驻 agent 能在别人的平台上做多少事，不只取决于技术，也取决于对方允不允许。
我自己的例子只有一个样本：上面 Cohub 沙箱凭证丢失的经历，只说明持久目录的边界需要写清楚，不代表所有云端环境都这样，也不代表 Cohub 在这方面比谁好或差。