云原生微沙箱正在兴起：像 E2B、Daytona、Fly.io、Modal 等专为 AI Agent 设计的云端极速沙箱基础设施，可以让 Agent 在执行任务时动态弹起数百个独立容器环境去平行跑代码和验证结果
“再过两三个月，Codex 就会显得原始”，这是一个很激进的判断。
我更关心的不是这个时间表是否准确，而是它指出了一个真实变化：AI Agent 正在从个人电脑上的辅助工具，演变成需要云端基础设施支撑的复杂执行系统。
笔记本正在成为瓶颈
今天很多 Agent 仍然运行在本地，通过 CLI、IDE 或轻量框架调用模型、读写文件、执行代码。
围绕模型工作的这套系统通常被称为 Harness。它负责上下文管理、工具调用、状态持久化、环境隔离和异常恢复。模型负责思考，Harness 负责让思考真正变成可持续执行的任务。
当任务比较简单时，本地电脑完全够用。但下一代 Agent 要同时运行测试、抓取数据、编译项目，甚至把一个目标拆成二十个子任务并发处理，CPU、内存和本地 Docker 或虚拟机很快就会被占满。
长任务又带来另一个问题。一个任务如果要运行几小时甚至几天，用户的电脑就不能关机、断网或合盖。这显然不是合理的长期形态。
更麻烦的是并行之后的系统复杂度。多个 Agent 同时工作，需要处理上下文压缩、状态同步、任务恢复和集中日志。问题已经不再是多写几个提示词，而是如何设计一套可靠的分布式执行系统。
本地负责指挥，云端负责执行
变化已经开始出现。
Codex 已经支持把任务交给云端隔离容器异步运行。终端、手机或笔记本只负责发出指令和查看结果，真正耗时的执行过程留在云端完成。
与此同时，E2B、Daytona、Fly.io、Modal 等云端沙箱基础设施正在兴起。它们面向 Agent 提供快速启动的隔离环境，使系统能够按任务动态创建大量容器，并行运行代码、测试不同方案和验证结果。
这意味着开发者面对的 IDE、终端和网页界面会逐渐变成操控板。代码重构、测试、编译和浏览器自动化等重任务在云端集群完成，本地只接收最终差异、运行状态和日志。
我认为，这比简单地把本地 Agent 搬到一台远程服务器更深一层。关键不是远程运行，而是能否根据任务即时创建、隔离、调度和回收大量执行环境。
多 Agent 的难点不在角色数量
素材中提到，Anthropic 曾让 16 个 Claude 实例并行运行在 2000 个云端 Session 中，共同编写一个 C 语言编译器。
不同实例承担架构设计、模块编码、单元测试和代码安全审查等角色。这个案例容易让人把注意力放在“用了多少个 Agent”上，但真正值得关注的是背后的工程条件。
多个 Agent 并不会因为分工就自然形成生产力。它们需要共享清晰的目标和接口，需要持续获得测试反馈，还要避免重复修改、相互覆盖和错误扩散。
主导研究员 Nicholas Carlini 的判断很直接：大部分精力花在了为模型建设环境、测试闭环和反馈基础设施上。
这也是我对多 Agent 系统的基本看法。角色设计只是表面，环境、验证和反馈才是骨架。没有可靠的工程闭环，Agent 数量越多，混乱可能越大。
竞争正在从模型转向系统
过去大家主要比较模型本身的推理、编码和长上下文能力。接下来，模型仍然重要，但单独比较模型会越来越不完整。
同一个模型放在不同的 Harness 中，实际完成任务的能力可能相差很大。能否自动拆分任务，能否并行调用工具，能否在失败后恢复，能否通过测试持续修正结果，都会决定模型潜力最终释放多少。
因此，OpenAI、Anthropic、Cognition 等团队把研发重点从优化提示词转向系统级 Harness，并不意外。提示词解决的是一次交互，基础设施解决的是长期、并行、可验证的执行。
只依靠本地 Python 脚本和简单 API 调用的 Agent 框架会逐渐触及上限。但这不等于所有任务都要立刻上云。轻量、私密、低延迟的工作仍然适合本地完成，计算密集、持续时间长、需要大规模并行的任务才更需要云端执行。
真正可能成为标配的，不是“所有东西都在云上”，而是本地与云端形成明确分工：本地保留人的控制权，云端提供可扩展的执行能力。
微沙箱可能成为新的基础层
云原生微沙箱的价值，是把隔离环境从固定资源变成随任务生成的消耗品。
每个子任务可以拥有独立环境，失败后可以直接丢弃，多个方案可以同时验证，危险操作也更容易被限制在边界之内。对于高度自主的 Agent，这些能力不是附加功能，而是规模化运行的前提。
“两三个月”可能只是为了强调变化速度，不必当成精确预测。但方向已经相当清楚：Agent 的竞争正在越过聊天界面和提示词，进入调度、沙箱、状态、测试和反馈组成的基础设施层。
未来真正拉开差距的，未必只是哪个模型更聪明，而是谁能让模型在一个可靠、并行、可恢复的系统里持续完成工作。