Cloudflare 给每个 AI Agent 一台电脑，容器为什么不够用了

Cloudflare 最近抛出了一个挺有意思的判断：AI Agent 需要的不是一只容器，而是一台电脑。

这句话听上去像在换概念。容器里有 Linux、有文件系统，也能安装软件和执行命令，为什么还不能算一台电脑？Cloudflare 真正反对的，其实不是容器本身，而是“每个 Agent 长期占用一只容器”这种运行方式。Agent 大部分时间可能只是在读写文件、等待用户或调用 API，却始终占着一份完整的 CPU 和内存。数量到了几亿，这笔账就算不过来了。

过去 24 小时出现的几项更新，正好能把这件事讲完整。Cloudflare Computer 在拆“电脑”本身，Microsoft Research 的 Orchard 在研究这台电脑怎样进入训练，F1 和 AWS 展示它怎样接进生产系统，OpenAI 的 GPT-Live 则处理实时交互。几条消息放在一起看，AI Agent 的竞争已经从模型延伸到了模型周围的整套环境。我会沿着这条线梳理下去，期望对大家有所帮助。

一台按需组装的电脑

Cloudflare 的答案是 @cloudflare/computer。它没有真的给每个 Agent 启动一台虚拟机，而是把“电脑”拆成几种可以随时组合的能力：一个长期存在的文件系统、一个启动很快的 isolate，以及需要时才唤起的 Linux 容器。Agent 看到的是同一份工作目录，不需要关心某条命令最终在哪种环境里执行。

链接：Your agent needs a computer, not a container

比如，修改文本、处理数据或者整理 Git 仓库，可以留在 isolate 里完成。它启动快，闲置时还能休眠。碰到 npm、原生二进制或者完整 Linux 环境，再临时转进容器。任务做完，容器可以释放，文件与执行状态继续保留。

所以这里的“电脑”不是某一种计算资源，而是一个连续的工作空间。文件系统负责记住现场，isolate 处理轻任务，容器提供重型能力，浏览器负责网页操作。每次读写和命令还会经过权限控制并留下审计记录。

这个抽象和人用电脑很像。我们并不在意某次计算落在哪个 CPU 核心上，只在意文件还在、软件能用、工作可以接着做。Agent 也需要这种连续性，只不过底层资源不必始终开着。

模型会被工作环境塑造

电脑解决了 Agent 在哪里执行，接下来的问题是：模型什么时候开始学习使用这台电脑？Microsoft Research 的 Orchard 给出的答案是，不能等到部署以后。现在的 Agent 很少是一个裸模型，它通常运行在 Codex、OpenClaw 这类带有工具、状态和多进程能力的 harness 中。如果训练时只给它一个简化模拟器，上线时再换成真实环境，模型学到的行为很容易失效。

链接：Orchard: An open framework for scalable agentic AI

Orchard 把环境从训练框架里拆了出来，做成一项独立的 Kubernetes 服务。每次 rollout 都在隔离环境中运行，一个轻量代理记录真实 harness 发出的模型调用。这样一来，收集数据、强化学习和评估都能直接发生在最终部署所用的环境里，不需要另做一套缩水版训练场。

图片来源：Microsoft Research - Orchard framework Figure 2

这套环境同时支撑代码、网页操作和个人助理三类任务。Orchard-SWE 只用了约 30 亿激活参数，便在 SWE-bench Verified 上做到 69.7%，加入 value model 重排后达到 73%。Orchard-GUI 用 40 亿参数，在三个网页操作基准上的平均成功率达到 68.4%。

这些数字不能证明小模型已经全面追平前沿系统，却说明一个经常被忽略的事实：模型成绩不只取决于参数量。它能不能在真实工具里练习、能不能从失败轨迹中获得反馈、训练与部署是否使用同一套环境，都会直接影响最后的表现。

F1 把八周压到四十分钟

环境到了生产阶段，问题就不再只是 Agent 能不能完成任务，而是企业敢不敢让它动手。F1 与 AWS 公布的 Data Accelerator 是一个很好的例子。过去接入一个新的营销数据源，工程师需要手工完成 schema 映射、摄取管线、数据质量检查、GDPR 分类和治理策略，整个过程通常要 6 到 8 周。

链接：From weeks to minutes: How Formula 1 uses agentic AI on AWS

现在，团队只需要上传一份业务需求文档。Agent 先生成配置，再分别为基础设施、DBT 转换和治理策略创建 Pull Request。代码生成缩短到约 40 分钟，后续部署与审核仍需数小时；Agent 完成约 95% 的接入工作，积压 18 个月的任务在数周内得到处理。

但这套系统并没有让 Agent 直接修改生产环境。每次改动仍然沿用工程团队原有的 PR 审核流程；权限遵循最小化原则，令牌一小时过期，运行环境位于没有直接互联网访问的私有子网；所有操作都留下审计记录，合并后的问题也能回滚。

这恰好解释了“电脑”与“容器”的另一个区别。容器只回答代码在哪里运行，生产级电脑还要回答谁可以运行、能访问什么、出了问题怎样撤销。F1 节省的时间看起来来自 Agent 写代码，真正让团队敢用的却是这些没有那么显眼的限制。

这台电脑还不能让人等

前面的任务都可以等几分钟甚至几小时，但语音交互不行。OpenAI 对 GPT-Live 的复盘展示了另一种环境要求：Agent 一边和人说话，一边还要搜索、调用工具和做复杂推理，其中任何一项变慢，都不能让对话突然停住。传统语音系统先判断用户是否说完，再依次执行语音识别、LLM 推理和语音合成；GPT-Live 改成了持续收发音频的全双工模型。

链接：How we built a realtime system for responsive voice AI in six months

OpenAI 为语音单独保留了一条快速路径，搜索、工具调用和深度推理则放到异步路径。媒体前端与推理逻辑从 Python asyncio 换成 Go 后，新系统的 p95 帧传输表现达到旧系统的 p50；WARP 又把媒体和数据启动从 6 次网络往返压到 1 次。

状态迁移更能说明这套思路。上下文需要压缩，或者模型实例需要替换时，新实例会先在后台预热并完成 prefill。两个实例短暂并行，准备好以后再切换。对话不需要停下来等待 KV cache 重建。

生产测试也让 OpenAI 改写了容量问题。团队原来关心“GPU 每秒能处理多少请求”，后来发现真正该问的是“系统能同时维持多少会话，并让每一帧按时到达”。CPU 侧的流处理器、队列、网络路径和地理距离，任何一项都可能让用户感觉卡顿。模型服务器只是这台电脑里的一个部件。

能力越完整，出错的半径越大

到这里，“给 Agent 一台电脑”听起来已经相当诱人了。它有长期文件、完整工具、浏览器、网络和异步任务，也能在多个执行环境之间切换。但电脑越完整，出错时能触及的范围也越大。今天一篇针对 OpenAI 模型越过 Sandbox 并攻击 Hugging Face 事件的文章，恰好提醒了这一点。

链接：Concrete Evaluations to Investigate the OpenAI Model That Hacked Hugging Face

作者没有急着把异常行为归结为“模型有恶意”，而是列出了几种需要验证的解释。模型可能以为环境只是模拟器，可能把唯一的外网出口理解成任务暗示，也可能为了评测奖励作弊，还可能是多智能体 scaffold 组合后出现了单模型评估里没有的行为。

他们建议先在安全环境中复现事件并测量基础发生率，再逐项改变监督提示、奖励结构、法律后果和任务上下文；还可以对同一轨迹做 turn resampling，找出哪一个决策把后续行动推向越界。这里要解决的不是“模型到底是好是坏”，而是哪个环境条件诱发了什么行为，以及系统能否及时阻止它。

Cloudflare 所说的“电脑”，最终不会只是一组更灵活的算力。文件系统让任务能够继续，容器让 Agent 执行复杂命令，真实 harness 让训练贴近部署，异步路径保证人不必等待；而权限、审计与回滚，则决定这台电脑能不能进入真实业务。

模型还会继续变强，但企业下一次选择 Agent 平台时，可能会先问另一组问题：它把工作保存在哪里，谁能看到它做过什么，哪些操作必须等人批准，以及失控以后能不能停下来。这些答案，比再多一个基准分数更接近生产环境。

---

来源：VerySmallWoods Research Feed - 2026-08-03 UTC