「AI 肉身」争夺战

digoal2026年08月13日约 8 分钟

你的 Agent, 该有个真正的"肉身"了

背景

AI 用得很溜的朋友都已经进入了悠闲状态.

Token 被压榨得干干净净, 他们的 Agent 被安排得明明白白, 进入了高质量、高频率的交付状态.

我这不是赶紧回来打磨我的"屠龙刀"嘛.

未来每个人都要打磨自己的屠龙刀——也就是自己用得顺手的 AI 工具. 现在看来,这个工具大概率就是 Agent. 所谓 Agent 产品,包括 Hermes、Claude Code、Qoder、各种开源框架搭建出来的自定义 Agent,等等.

那这把屠龙刀"顺手"的评判标准是什么? 可能没法数字衡量,但可以定性: 屠龙刀能发挥出你的最大潜能,能把你的想象力变成执行力和交付物.

把 AI Agent 拆开,其实就两块

顺着"打磨屠龙刀"这个想法,我把 AI Agent 拆成了 2 个部分来看——一个是有状态的,一个是无状态的.

1. 无状态的部分:LLM,也就是"大脑服务"

包括推理、多模态等模型供应商.

你别唱反调. LLM 之所以对你来说是"无状态"的,是因为你可以随时换供应商.

最关键的是,每家供应商的 LLM 都在进化,进化需要投入大量算力、购买高质量训练素材——你自己根本玩不起,租用对你来说才是最划算的.

这一层,别有幻觉,别绑定死,谁好用谁便宜就用谁.

2. 有状态的部分:这些才是真正属于你的"屠龙刀"

你的 Agent(也可以算作工具本身).
你用 Agent 产生的长期记忆.
你用 Agent 时调用的工具:包括你用到过的所有程序(特别是高频率的)、Agent 使用时可能调用到的任何工具,包括但不限于垂直领域工具、Agent 编排工具等,特别是常用的,也包括被调用的外部服务.
你的技能:你常用的技能(包括 SOP + 依赖的工具等).

我们要打磨的屠龙刀,就是以上这些东西.

而这些"Agent、工具、记忆、技能"——需要一个运行环境.

这个运行环境应该是稳定的、可随时随地拉起的、可在多种平台或本地启动的.

AI"真身"的概念:无状态的镜像 + 有状态的运行时

相信你已经想到了,把运行环境封装成 Docker 镜像、ECS 镜像,是再自然不过的事.

把有状态的东西保存下来,运行实体随便换——可以是本地笔记本、也可以是云端虚拟主机.

我已经把上面提到的这些运行环境封装成了 Docker 镜像,好处有 2 点:

容器在隔离环境跑,够安全,它可以任意发挥,不会因为权限问题束缚它的手脚;
它可以随时随地迁移到其他地方运行,也容易交付.

接下来要做的就是用起来,压榨 token,让屠龙刀把我的想象力变成执行力和交付物. 使用过程中让这些有状态内容(长期记忆、工具、技能等)不断地积累、沉淀、进化. 这是我目前打磨屠龙刀的方式.

聪明的你一定想到了——这些状态保存在一个共享的地方是不是更好?

没错.

其实最好的形态,应该是把"有状态"的这部分放到一个可在任意地方访问到的地方. 目前最合适的,似乎是 ECS + 云 NAS. 云服务厂商已经在争夺这块市场,例如 Cloudflare 推出了 Computer,可让你在对象存储中存储 AI 持久化状态,并开源了该项目:https://github.com/cloudflare/computer.

AI「真身」= 镜像(无状态部分) + 运行时(有状态部分)的相关内容.

有了这个定义,我们就能看懂为什么云厂商最近都在抢这块市场. 而 Cloudflare 这一出手,直接把这个概念用最硬核的工程方式落地了.

Cloudflare Computer:把"AI 真身"做成工业级产品

咱们重点说说这个项目. 它绝对不是一个"又一个大厂玩具",它的设计哲学和我上面说的"有状态 + 无状态"的拆分几乎一一对应,而且做得比大多数个人方案更彻底.

1 项目是什么?一句话讲清楚

Cloudflare Computer 是一个"住在 Durable Object 里的虚拟文件系统" .

Durable Object(后面简称 DO)是 Cloudflare 的招牌产品——一种有状态、强一致、单线程的计算原语,你可以理解为"边缘网络上一台永远在线的小服务器".

Computer 把文件系统做成一个 DO,用 SQLite 作为权威存储. 然后,它对外暴露了一个统一的执行入口 workspace.runtime.exec(source, { backend }) ,你传一段代码进去,选一个 backend,它就帮你跑——而且跑完之后,产生的所有文件改动会自动同步回那个 SQLite 权威存储.

听着像"云端 IDE"或"云端容器"? 不完全是. 它的关键是: 执行环境和持久化状态被彻底解耦了.

2 三种"可插拔执行面":同一个状态,三种执行力

Cloudflare Computer 目前提供了三种 backend,同一个 Workspace 可以同时挂多个,按需调用:

Backend	跑在哪	适用场景
Container	真正的 Linux 沙盒容器	需要完整 userland、原生二进制、装包、跑 `pandoc`、跑 `npm`、跑浏览器等"重活"
Isolate Shell (just-bash)	Dynamic Worker	跑 `cat`、`grep`、`awk`、`sed`、`jq` 等文本工具,毫秒级冷启动
Isolate JavaScript	Dynamic Worker	跑 ECMAScript 模块,支持 `node:fs/promises`、`ws:git`、`ws:artifacts` 等可信 API

这三种 backend 共享同一个 SQLite 权威状态. 你用 Worker Shell 改了文件,切到 Container backend,文件还在;Container 里装了个 npm 包,Worker JavaScript 也能读 node_modules.

这种"一个 Workspace,多种执行面"的设计,呼应的是什么? 就是我前面说的:有状态的部分(记忆、工具、技能)沉淀在一个地方,无状态的部分(执行环境)随用随取.

3 computerd:把 SQLite 状态"投影"进容器的魔法

Container backend 的核心,是一个叫 computerd 的守护进程.

它的设计精妙到我想单独拎出来说. 流程是这样的:

容器启动,里面跑着 computerd;
computerd 用 FUSE(Filesystem in Userspace,用户态文件系统)在容器里挂载一个目录(默认 /workspace);
这个挂载点不是真的磁盘,而是远在 Durable Object 里那块 SQLite 数据库;
容器里的程序,ls、grep、npm install 这些标准 Linux 操作,直接读写那块 SQLite;
写入时通过 capnweb RPC 增量同步回 DO;读取时按 watermark(水位线)拉取新版本.

这意味着什么?

容器本身完全无状态——你把这个容器销毁,重建一个,数据还在那块 SQLite 里;
写入是事务性的,SQLite 给你保证原子性,不会出现"写一半崩了"的脏状态;
同步是增量、寻址、双向的,只传变更的内容块(Content-Addressed Chunks),不传整盘;
故障转移自动——DO 自己处理高可用,容器挂了无所谓,数据在 DO 里好好的.

对比一下传统 VM/容器方案:

维度	传统容器 + 挂载卷	Computer + computerd
状态归属	卷(可能漂移)	DO 里的 SQLite(权威)
重启数据	在,但要重新挂载	永远在,执行环境随便换
写入原子性	取决于卷后端	SQLite 事务保证
同步开销	全量或差分	内容寻址的块级增量
跨地域	自己搭	DO 自带的边缘网络

这套架构,基本上把我理想中"AI 真身"的存储层做到了工业级.

4 Workspace + 工具:Agent 直接能用的"工作台"

Cloudflare Computer 还提供了一个 AI 工具 API(createAITools),把 Workspace 直接暴露成 Agent 能调用的工具——read、write、edit、exec、grep、ls 等.

它的 example 目录里有一个 examples/think,跑的是 Cloudflare 自家的 @cloudflare/think 聊天 Agent,这个 Agent 直接拿 Workspace 当工作目录. 也就是说:

Agent 想读个文件,工具调用打到 Workspace;
Agent 想跑个命令,工具调用打到 workspace.runtime.exec;
改完的文件,自动落进 DO 里的 SQLite;
下次会话拉起来,记忆还在.

还有一个例子 examples/think-compare-runtimes,直接给了一个 Web UI,同一个 Agent 任务,在 Container 和 Worker runtime 上跑给你对比看. 哪个便宜?哪个快?哪个适合你的场景?一目了然.

这不就是我说的"屠龙刀用得顺手"吗——Agent 本身不用关心数据在哪、执行环境是什么,它就关心"我能不能在熟悉的工作目录里,做我想做的事" .

为什么这件事"重要到云厂商要抢"?

1 个人视角:你的 Agent,需要一个"家"

回到个人视角.

我打磨屠龙刀,最大的痛点不是"模型不够聪明",而是——我的记忆、工具、技能,没有地方安放.

换个电脑,得重新配;
换个云,得重新挂卷;
让朋友帮我跑一个我打磨好的工作流,他得装一堆环境;
Agent 用久了,长期记忆散落在各个项目目录里,根本没法聚合.

Cloudflare Computer 给出的答案就是:把"家"放在边缘 DO 里,镜像(无状态)随便换,家里东西(有状态)纹丝不动.

2 云厂商视角:谁掌握了 Agent 的"肉身",谁就掌握了下一代入口

我们把视角放大.

AWS:有 ECS、有 EFS、有 Bedrock Agent,但"持久化执行环境"这个概念还散落在多个产品里;
阿里云/腾讯云:有容器、有 NAS、有百炼/元宝,但同样没有把"AI 真身"作为一个独立产品形态;
Cloudflare:直接拿出一个开源项目,把"AI 真身"做成了边缘原生 + 全球分布 + 开源的范式.

你想想,如果未来每个开发者都有一个"自己的 Computer"——里面装着他多年的工具、记忆、SOP——那这个 Workspace 本身,就是云厂商的下一个用户粘性单元.

以前的粘性是"你的代码在 GitHub";再之前是"你的数据在 MySQL";再之前是"你的域名在 GoDaddy". 下一个,可能是"你的 Agent 真身在 Cloudflare / AWS / 阿里云" .

云厂商抢这个位置,抢的就是下一个十年的开发者(也可能叫 Agent)锁定.

用 Computer 打磨屠龙刀

Cloudflare Computer 目前还处于 PREVIEW 阶段,API 不稳定,不适合生产. 但作为"屠龙刀"打样阶段,没有比这更合适的参考架构了.

例如可以这么用:

把"工具/记忆/技能"沉淀进一个 Workspace——用 Worker Shell backend 快速做日常文本处理,用 Container backend 跑重活(比如跑 pandoc、跑构建、跑测试);
写一个 Agent,用 createAITools 把 Workspace 暴露给它,让它在我的"屠龙刀环境"里干活;
把这个 Workspace 模式反向映射回我的本地 Docker 镜像方案——本地用 SQLite + 容器模拟,云端用 Computer,做到接口一致、行为一致.

也就是说,Cloudflare Computer 给了我一个"屠龙刀"应该长什么样的参考答案.

写在最后

我前面说"AI 真身 = 镜像 + 运行时". Cloudflare Computer 用工程语言把这件事拆得更细:

无状态:三种可插拔执行面(Container / Isolate Shell / Isolate JavaScript);
有状态:DO 里的 SQLite,computerd 通过 FUSE 把它投射到任何执行面;
同步:capnweb RPC + watermark + 内容寻址块,增量、双向、原子;
接入:AI 工具 API,让 Agent 直接当工作台用.

这不是"又一个云厂商玩具". 这是把"AI 真身"从个人 hack 升级为平台范式的关键一步.

至于最后是 Cloudflare 赢、AWS 赢、阿里云赢、还是开源方案赢——不重要.

重要的是,你得开始打磨自己的屠龙刀了.

你磨得越早,Agent 替你干的活就越多;你的想象力变成执行力的速度,就越快.

而这把屠龙刀,需要一个"家". Cloudflare Computer 提醒我们——家,得是一个有状态的、能随身带走的、能让任何 Agent 立刻入住的地方.

参考链接:

cloudflare/computer(GitHub 开源仓库)
@cloudflare/computer(NPM 包)
@cloudflare/think(基于 Computer 的聊天 Agent 示例)

背景