本文整理自 QCon 北京 2026《陶宇田 OpenSandbox重新思考Agent时代的Runtime》通过AI音视频转录总结工具Ai好记视频转文字整理以下为精炼整理后的会议笔记内容。聊 AI 系统大多数人的第一反应是模型选哪个、数据怎么喂。可陶宇田在 QCon 北京 2026 抛出的观点恰恰相反当软件越来越多以 Agent 的形态运行执行环境 Runtime 会决定整个系统的上限。过去一两年大家卡住的点不是模型而是 Runtime。作为阿里 OpenSandbox 的技术负责人他把这套从零设计 Runtime 的思路完整拆开了Agent 时代的 Workload 长什么样、Docker/K8s 差在哪、ProtoFirst 怎么设计、批量交付为什么能快一个数量级。这篇是完整的技术梳理。一、Agent 时代的 Workload和传统应用根本不一样他不讲空概念直接摆出三种典型场景1. 自主智能体Autonomous Agent要能操作特定文件系统、执行命令、自主提供服务还得统一对外暴露有时要暴露长连接。管控上不能简单粗暴断网需要更细粒度的网络策略。2. 批量评测系统单个环境不复杂但它是典型的批量交付场景要强隔离保证评测任务互不影响得给评测提供一个公平的「考场」。3. RL 训练场景海量短生命周期的环境系统批量交付的效率直接决定整体训练效率。抽象出来的共性诉求很清晰高并发、高吞吐的沙箱交付明确的生命周期管理可控联网能力统一的访问接口和执行通道一句话标准已经从「能让 Agent 跑起来」上升到了「能不能批量、稳定、可控地跑」。二、Docker/K8s 很好但缺了一层执行模型他特意做了声明不是否定 Docker 和 K8s这些系统很稳也很出色。核心问题是它们从诞生第一天起就不是为 Agent 时代的执行模式设计的。具体缺在四块缺失能力具体问题批量交付效率单个在线服务启动慢点能忍批量时延迟叠加放大K8s 控制面写放大线性上涨访问链路抽象K8s/Docker 没有典型的访问路径抽象HTTP、SSE、VNC 各种暴露方式让上层系统越来越散细粒度网络管控需要明确描述沙箱内 Agent 能访问哪些网络资源、不许碰哪些统一执行契约没有一个纯粹面向沙箱语义的契约描述生命周期、交互形式、命令通道、文件准备核心结论问题不是容器跑不跑得起来而是传统系统缺失了一层面向 Agent 时代的统一执行模型描述能力OpenSandbox 正是想补上这一层。三、核心设计哲学ProtoFirst先定义契约再选RuntimeOpenSandbox 从一开始就没先定用 Docker 还是 K8s而是先为业务定义清楚「Specs Layer」的契约。这套契约包含四部分契约部分核心内容对应协议生命周期管理create、get、list、delete 等语义操作LifecycleProtocol命令执行执行命令、操作文件系统、代码执行、后台任务ExecutionProtocol网络与策略允许访问的网络资源、HTTP/SSE/WebSocket 协议栈、FQDN 级或 IP 网段级 egress 策略Network/PolicyContract访问控制统一暴露对外服务统一 HTTP、SSE、WebSocket 等不同形式AccessContract架构分层从上层到下层应用层批量评测系统、训练系统等用户交互层统一 SDKPython/JS/Java/C/Go CLI/MCP IngressLayer Protocol 层核心协议OpenSandbox Server 层Runtime 层目前提供 Docker 和K8s 两种引擎Sandbox Agent Instance 层execd、egress networkpolicy 等核心组件设计价值很多系统架构初期设计得不错但一旦 SDK 层跟底层实现绑定场景一扩充系统演进就会越来越难。OpenSandbox 从设计之初就在规避这个问题将来想从 Docker 换 K8s甚至自定义更强的 Runtime上层业务不用跟着改。四、性能实测批量交付快一个数量级最硬核的是 benchmark。同样是拉起 100 个 sandbox、都用上池化OpenSandbox 的整体交付效率比社区同类项目 agentsandbox 高一个数量级。差距的根源拆开看很清晰。传统 K8s 路径100个创建请求 → APIServer 创建 100 个 sandboxclaim 资源对象 → 控制器逐个改 ownerReference100次更新 → 逐个更新 status100次更新 → 背后 etcd 还有一串更新 控制面严重线性写扩散OpenSandbox 的做法BatchSandbox 批量交付对象1个 BatchSandbox 实例标识交付100个 → 控制器在内存里批量选出可用 sandbox → 批量打标到该实例1次更新 更少的资源对象写入和状态同步更少的协调步骤核心思路不是简单提供一个资源池而是把整个交付链路梳理了一遍让系统层面的协调开销更小。这比单纯靠池子省冷启动时间是更深一层的优化。五、安全三层隔离、网络控制、访问治理Agent 能力越强安全越绕不开尤其企业级部署。OpenSandbox 的安全体系分三层层级功能技术手段隔离增加不可信负载与宿主的隔离边界gVisor用户态-内核态统一隔离、Kata/FirecrackerVM级网络控制细粒度管控网络资源NS 劫持域名级 IP/网段过滤网络层访问治理统一服务暴露、平台治理、审计Ingress 统一架构核心目标很明确在 Agent 不可控的情况下防止内核逃逸影响同宿主的其他 sandbox 环境。六、从选型角度聊聊这种偏底层的技术分享光靠听容易记住结论忘掉细节。我的办法是用 Ai好记 把整场演讲转成图文笔记它会自动截取 PPT 画面、生成精华速览和思维导图把 BatchSandbox 的交付链路、四层契约、三层安全这些结构化内容抓出来回头真要选型或复盘时翻出来对照着用。选 Runtime 时给你三个判断点看批量交付是不是把批量建模成统一对象而不是一个一个建单体环境。看契约层有没有稳定的沙箱语义抽象能不能跟底层 Runtime 解耦。看安全隔离、网络管控、访问治理三层是否齐备。Runtime 这个容易被当成「基础设施小事」的环节正在成为 Agent 系统的关键杠杆。把它想清楚可能比盲目堆模型参数带来更实在的收益。FAQAgent Runtime 高频问题QOpenSandbox 和 Docker、K8s 是什么关系A它是建立在 Runtime 之上的执行模型抽象目前提供 Docker 和 K8s 两种引擎底座通过统一契约层把上层业务和具体 Runtime 解耦。Q为什么批量交付能快一个数量级A关键是把批量创建建模成统一对象 BatchSandbox大幅减少控制面的资源写入和状态同步从线性写扩散变成批量协调。Q什么叫 ProtoFirst 设计A先定义沙箱语义的契约生命周期、命令执行、网络策略、访问控制而不是先定死底层 Runtime保证系统演进时不会越改越难。Q大批量沙箱的技术难点是什么A主要是生命周期管理、可控联网、统一访问接口和高效批量交付外加企业级部署强相关的安全隔离与网络管控。以上内容由 Ai好记 转录整理。Ai好记是一款支持音视频转图文笔记的AI知识库工具支持B站、小红书、抖音、小宇宙等平台链接及本地音视频文件视频转文字后自动生成精华速览、思维导图和结构化图文笔记帮助你把几小时的视频内容变成可搜索、可复习的图文笔记。