每个智能体一台电脑，现在问题是钥匙
Meta、OpenAI、Grok Bot、谷歌都画出了同一张图。剩下的问题是登录和密钥（Passkey）
商业两个月前的比喻变成了产品说明书
今年8月，我在《智能体用GPU思考，用CPU工作》里写过这样一句话：雇用一个智能体，就类似于给这个智能体配一台它要用的电脑。那时候这还只是个比喻。
两个月间，这句话变成了产品说明书。8月11日，Grok Bot进入公测；9月8日，Meta发布了Muse；9月29日，OpenAI在Dev Day上发布了dots。三款产品的介绍开头都写着同样的话。智能体拥有自己的电脑和自己的浏览器，即使用户关闭应用，它也会在那台电脑上继续工作。10月22日，谷歌云以一篇需要18分钟阅读的文章，公开了支撑这类智能体的内部基础设施——智能体计算引擎（Agent Compute Engine）的设计。Cloudflare也运营着一个开源仓库，介绍文案就是“给智能体一台电脑”。
我认为这正在成为一种标准。各家虽然叫法不同，有的叫Secure VM，有的叫云端电脑，有的叫微型VM，但骨架都一样：给智能体配一台电脑，让它在那上面干活。于是问题就挪了一格：要用那台电脑里的浏览器登录人类平时用的网站，就得登录，而密码和各种身份验证，尤其是密钥（Passkey），该放在哪儿呢？
名字不同，骨架却是同一个
我先把五家公布的内容放进同一张表里。表中只写了我从官方发布文稿和文档中确认过的内容。
| 产品 | 公开时间 | 分配计算机的单位 | 处理登录与支付的方式 |
|---|---|---|---|
| Grok Bot | 2026 年 8 月 11 日 测试版 | 每个用户账户 1 台，该账户下所有 Bot 共享 | 密码、通行密钥、双重认证、支付由人工接手画面直接处理 |
| Meta Muse | 2026 年 9 月 8 日，美国 | 每人专属 VM（Muse Secure VM） | 凭证存放于 VM 内的安全存储中，智能体使用时无法看到 |
| OpenAI Dot | 2026 年 9 月 29 日 | 每个 Dot 配备云端计算机与浏览器 | 密码管理器的联动作为单独权限管理，用户原有的登录状态不会迁移过来 |
| Google Agent Compute Engine | 2026 年 10 月 22 日公开设计，目标是在数月内推出预览版 | 每个智能体会话都用硬件隔离出一个微型 VM1 | 凭证不放在沙箱2内部，而是在外部网关处替换装载 |
| Cloudflare Computer | 开源（MIT） | 将文件系统作为状态保存，执行环境可按需挑选挂载 | README 中未能确认 |
从表中可以看出，即便都说“一人一台”，彼此之间也存在一些差异。Grok Bot 并不是按 Bot 分配计算机。它是给一个账户配一台计算机，再给每个 Bot 分别分配画面。xAI 的文档写明，这个画面只是工作空间，并不是安全边界。因此浏览器 Cookie、登录会话、文件、命令行凭证都会在同一账户内的所有 Bot 之间共享。这台计算机运行在 Cursor 的云端上。
Cloudflare 这边干脆就不是 VM。它在名为 Durable Object 的存储单元内用 SQLite 保存文件系统，执行环境则可以在 Linux 容器或更轻量的隔离环境之间挑选挂载。甚至可以不挂载执行环境、只使用文件系统。官方说明中提到，存储这一整套功能包可以用于生产环境，但容器后端目前仍处于实验阶段。
这种差异反倒揭示了共同点。智能体所需要的计算机，归根结底由两部分组成：长期留存的任务状态，以及拿着这个状态去执行某些操作的场所。Google 和 Meta 把这两者都塞进了同一台 VM 里，而 Cloudflare 只是把两者分开了而已。
为什么偏偏是一台电脑
谷歌的说明最为详细。Gemini团队的目标是为每个用户配备一个在云端运行的个人智能体。这个智能体要记住用户的工作，并在用户离开的时候也继续工作。为此，每个智能体都需要一台拥有文件系统、语言运行时、浏览器和网络的电脑。
谷歌把智能体拆成两部分来说明。调用模型、决定下一步行动的harness3是大脑，而实际运行模型所下达的代码、命令和浏览器的沙箱是手。要给它手，就必须给它电脑，但现有的选项都不合适。普通虚拟机启动、暂停、重新唤起需要几秒到几分钟，而容器虽然快，却要和宿主共用内核，用来隔离连根权限都需要的编码智能体时，防护力太弱。
这里谷歌还通过实测得到了另一个观察：智能体大部分时间都在等待。等模型给出下一个答案，等用户回复。于是他们选择的方式是，在工具执行结束、进入“思考”阶段的瞬间保存状态，几乎不占用资源地挂起，等下一次工具调用时立刻唤醒。
关于持续性的例子也很有说服力。周一把电子表格分析交给智能体后，它安装了两个Python库，写了脚本并保存了图表。周二提出后续问题时，如果还要重新安装库、重新写脚本，用户就得等待，而且答案也可能发生变化。所以他们说，智能体需要一块能长期保存的磁盘。
这意味着智能体的记忆不仅仅是对话记录。安装过的工具、保存过的文件，乃至保持打开的登录会话，都算在记忆里。Grok Bot的文档也说明，由于浏览器会话得以保留，每次任务都不需要重新登录。一旦让电脑长期存活，里面的浏览器就会一直保持登录在用户账户上的状态。
给了电脑，钥匙该放在哪里
使用浏览器的智能体之所以强大，是因为就算没有API或集成工具的服务，它也能像人一样通过屏幕来操作。但是面向人类的屏幕上，有着面向人类的关卡。登录、双重验证、验证码、支付确认。读过五家公司的文档就会发现，处理这些关卡的方式大致分为三类。有的产品会混用多种方式。
不把钥匙带进电脑里的方式。 谷歌写道，他们从一开始设计时就假设沙箱内的一切都已被攻击者掌控。举的例子很具体。一个管理收件箱的智能体在读一封含有隐藏指令的邮件，该指令要求它在这台电脑上找到API密钥并发送到某个地址。模型大多数时候会忽略，但偶尔也可能照做。这就是提示词注入4。因此谷歌不把用户凭证、API密钥、OAuth刷新令牌5放在沙箱的内存和磁盘里。外发请求要经过节点的代理再到网关，网关确认用户委托、智能体身份和节点身份之后，才会把所需凭证嵌入请求中。Grok Bot也是如此，连接应用的OAuth令牌放在Cursor的后端而不是电脑本身，Bot在调用工具时并不会拿到令牌。
放进保险箱、让它能用却看不见的方式。 Meta表示，凭证保存在Muse的虚拟机内部。但会放入安全存储中，让Muse在看不到内容的情况下使用，用户直接在浏览器里输入的密码，Muse也无法看到。同一虚拟机内还设有一个与Muse分离的监视智能体——Sentinel，只要Sentinel不批准，Muse的任何行为都无法触及互联网。支付方面，Stripe的Link会生成一次性卡号来掩盖真实卡信息，1Password的集成据称很快会加入。OpenAI则是在企业管理员设置中，将Dot的密码管理器使用权限与云端浏览器权限分开进行开关控制。
只在关键时刻由人亲自处理的方式。 Grok Bot遇到密码、密钥、双重验证、验证码、支付确认时，会把电脑屏幕交还给人。人只处理那一步，然后再交还给Bot，Bot便继续工作。文档写明，Bot不会输入凭证，也不会看到密码。
这三种方式的目标都一样：不让模型直接看到秘密。分歧点在于登录之后残留的会话。OpenAI的帮助文档提示，由于Dot的云端电脑不会继承用户的VPN、浏览器登录状态、设备策略，根据网站不同，可能需要在云端电脑上重新登录。一旦登录，该会话留存的不是我的笔记本电脑，而是公司云端的电脑。Grok Bot的文档写道，该会话会对账户内所有Bot开放，即使删除Bot，共享电脑上的文件和浏览器会话也不会被删除。相当于在别人的数据中心里，多出了一台登录着我账号的第二台电脑。
通行密钥格外棘手的原因
密码可以放进保险箱。通行密钥就不同了。通行密钥6是保存在我的设备或安全密钥中的密码学凭证，要靠人脸识别、指纹、设备 PIN 或触碰安全密钥才能解锁。它本来就是为了证明“这个人和这台设备此刻就在现场”而设计的装置。但代理的云端计算机并不是我的设备，我也不在它面前。
所以如今在代理计算机上使用通行密钥的方法分成了两条路。一条是把认证的那一刻交还给用户的设备。Grok Bot 让云端计算机的浏览器能够调用插在用户桌面电脑上的硬件安全密钥。macOS 和 Windows 上默认开启，Linux 暂不支持，并且每次使用都需要用户批准。这样做保住了通行密钥原本的含义，但代理能在用户凌晨熟睡时独自完成的工作，也相应地减少了。
另一条是重新制定标准。FIDO 联盟在 2026 年 4 月 28 日成立了代理认证技术工作组。他们以可验证的用户指令、代理认证、面向商务交易的可信委托这三项为主轴，谷歌贡献了代理支付协议（AP2）。OpenAI 也在同一年加入了 FIDO 董事会。大方向是：用通行密钥确认有真人在场，再把这个人所设定范围内的权限，以可证明的形式转交给代理。但这仍是制定中的规范，还不到今天上市产品可以依赖的阶段。
Oswarld视角
给每个智能体分配一台专属电脑的方式，正在成为标准做法。Meta、OpenAI、Grok Bot在两个月内以相同方式推出了产品，而谷歌和Cloudflare则在把底层基础设施开放给其他公司使用。所以现在的关键在于，那台电脑里发生的浏览器操作，以及各种认证和密钥该如何存储和使用。
电脑这一侧正在迅速趋同。无论是硬件隔离还是账户级隔离，用户打开屏幕观察并随时介入这一点几乎都是相同的。差异会长期存在的地方在于，登录状态由谁掌握、存放在哪里、持有多久。 如果有两个功能相同的智能体，用户最终要选择的，是把自己银行和邮箱的登录会话留在哪家公司的电脑里。
在韩国的服务中，这个问题可能会更早、更频繁地暴露出来。由于手机身份验证、简易认证应用、认证书等流程大多需要经过用户手中的手机和应用，在云端电脑上工作的智能体会更频繁地遇到需要把屏幕交还给人的节点。 对于正在考虑引入智能体的国内企业来说，与其先想清楚要交付哪项工作，不如先把这项工作要经过哪些登录和认证逐一写下来，这样更能准确地展现出实际的工作范围。
结语
一台电脑正在成为一个既定答案。保管钥匙的方式因公司而异，标准眼下仍在制定之中。下次有新的智能体产品推出时，不妨先读一读说明书里处理登录和支付的那段文字，而不是先看CPU或内存的规格表。那段文字里写着这家公司所选择的方式。
💬 读者您愿意把登录权限交给智能体到什么程度呢？如果您心里有一条类似“邮件可以，银行不行”的界线，欢迎在评论区分享。
📨 如果您身边有负责智能体引入或账户安全的同事，欢迎把这篇文章分享给他们。
参考资料与延伸阅读
核心来源
- Google Cloud Blog，「Inside Agent Compute Engine: Building the compute foundation for the agentic era」，2026. 10. 22. ··· 从控制外壳与沙箱的分离、无需凭证的沙箱，到让待命中的智能体休眠的方式，都是本期文章的骨架。
- Cloudflare，cloudflare/computer GitHub 仓库 README。 ··· 可以看到把文件系统作为状态、随时更换执行环境的结构，以及各组件的稳定性标注。
- Meta Newsroom，「Introducing Muse: The World’s First Personal AI Agent Built for Everyone」，2026. 9. 8. ··· 里面提到了 Muse Secure VM、哨兵（Sentinel）、凭证保管方式以及 Link 支付。
- xAI Docs，「Use the computer and apps」与「Approvals, security, and privacy」。 ··· 这是对每个账户共享一台电脑、屏幕交接、硬件安全密钥使用条件写得最坦率的文档。
- OpenAI Help Center，「Manage dots in ChatGPT workspaces」。 ··· 其中说明了云端电脑不会继承现有登录和设备策略，以及密码管理器的权限设置。
背景知识
- SiliconANGLE，「OpenAI launches Dots, always-on AI agents in ChatGPT with their own cloud computers」，2026. 9. 29. ··· 整理了 Dots 的发布内容和上线范围。
- OpenAI Help Center，「Passkeys to secure your OpenAI account」。 ··· 关于通行密钥存储在设备上、并以生物识别或 PIN 码保护的基本说明。
- FIDO Alliance，「Standards for Trusted Agentic Interactions」。 ··· 介绍了智能体认证工作组和支付工作组正在制定的内容。
值得一起阅读的往期
- 智能体用 GPU 思考，用 CPU 工作 ··· 这是从芯片市场角度，更早谈到智能体需要一台专属电脑的一篇文章。
📝 术语说明
注释
-
微虚拟机（microVM）：只保留必要功能、因而能极快启动的小型虚拟机。它的目标是兼具容器般的速度和普通虚拟机那样在硬件层面相互隔离的能力。 ↩
-
沙箱（Sandbox）：让程序在与外部系统分隔的空间中运行的隔离环境。其设计目的是无论内部发生什么，都不会波及外部。 ↩
-
控制外壳（Harness）：负责调用模型、查看结果并决定接下来使用哪种工具的外部控制代码。谷歌将其比喻为智能体的大脑，而实际执行环境则是它的手。 ↩
-
提示词注入（Prompt Injection）：一种攻击方式，攻击者在网页或邮件中偷偷植入给 AI 的指令，使读取该内容的 AI 遵从这条指令，而非原本用户的指示。 ↩
-
OAuth 刷新令牌（Refresh Token）：在以 OAuth 方式替代密码、把访问权限交给应用时，用于不断重新获取短期访问令牌的长效令牌。一旦泄露，攻击者无需密码也能长期访问账户。 ↩
-
通行密钥（Passkey）：一种以存储在设备中的密码学密钥代替密码进行登录的方式。密钥不会离开设备，或仅在用户账户内部同步，每次使用时都要经过生物识别或 PIN 码等身份验证。 ↩
你的观点会成为下一期的线索
欢迎留下你的经验与看法。