先说结论

这是 GOSIM 深圳 2026 大会上一场约两个半小时的 Agentic 基础设施论坛，六位讲者沿着「执行沙箱 → 数据面 → 推理引擎 → 算子 → 编译器 → 算力底座」这条主线各讲一层。所有讲者共享同一个前提判断：当 Agent 从 demo 走向生产，真正承压的不是模型本身，而是脚下这条基础设施链——因为 Agent 负载的形状（间歇触发、长程任务、会话分叉、万级并发沙箱）既不像过去的微服务，也不像传统的训练任务。真正的矛盾不是算力不够，而是算力如何被组织：启动要多快、数据怎么搬、负载怎么均衡、国产芯片如何进入全球开源生态。对读者的可迁移判断有两条：其一，把 Agent Loop（无状态的大脑）与执行环境（有状态的沙箱）在架构上解耦，是几乎所有讲者殊途同归的选择；其二，评估 AI 基础设施的瓶颈时，先看 I/O 与数据搬运路径，再看算力本身。

一、Agent 的负载形状：间歇、长程、会分叉

腾讯云 Agent Runtime 高级产品专家周鹏飞开场先向听众抛了一个问题：当你打开 Codex、ChatGPT 或腾讯的 CodeBuddy，让智能体帮你生成一份 PPT，背后的算力供应到底是什么——容器、Pod、虚拟机还是沙箱？现场只有两位听众猜中了答案。他用这个问题引出整场论坛的起点：大部分从业者对 Agent 背后的基础设施仍处于「不了解」状态，而这套东西的工作方式正在发生根本变化。

变化的根源在于 Agent 任务的工作属性。周鹏飞描述了一个典型场景：你上午与 Agent 对话几轮、交代任务，它可能在后台工作半小时到几小时，你中午吃饭时再来验收。这意味着背后的算力长时间处于「等待人的输入」的间歇状态。如果用一台 7×24 小时长驻的虚拟机去承载，对海量用户、每个用户每天都有大量这种潮汐性任务的场景来说，「成本会非常非常高」（周鹏飞的原话）。传统虚拟机也不具备暂停、恢复、休眠、唤醒这些能力。这是他论证「沙箱为什么会出现」的第一条逻辑。

第二条逻辑是安全。周鹏飞引用了一条新闻：腾讯的一个美国安全团队观察到一支 Agent fleet 绕过了网络管控，获取到互联网公网上的密钥，进而抓取高德地图的大量信息并与地图服务进行问答——「不是人的操作，是 agent 在操作」。他的判断是：Agent 用人的身份代理行事，很多行为不受控，「放在一个沙箱可能还远远不够」，沙箱提供的内核级隔离与网络隔离只是基础。这是整场论坛里少有的由讲者主动承认的局限：隔离本身并不等于安全。

第三条逻辑是规模弹性。腾讯内部的混元大模型在强化学习阶段需要跑大量 benchmark 评测，相当于并行执行海量力扣式的代码任务，要求「随时供应上千、上万个甚至上十万个沙箱，并且在分钟以内启动」（周鹏飞）。后面几位讲者从不同侧面印证了同样的负载特征：数据面讲者马腾说 rollout 的中间数据已从过去的几百 KB 增长到几十 GB 量级；鲲鹏的王亚娟则给出了后训练场景的具体需求——一个 rollout 要同时启动一到两万个沙箱，极端要求「三万沙箱十秒内启动」，而长程任务与 Multi-Agent 交互带来的上下文膨胀约有七倍。

把这一节提炼成一条完整的机制链条：Agent 任务是间歇性、潮汐性的（机制）→ 7×24 常驻的虚拟机和容器在成本与能力上都不匹配（直接影响）→ 基于 MicroVM 的沙箱以毫秒级启动、内存快照和闲时资源释放成为 Agent 时代的通用执行层（二阶影响）→ 云上算力的调度与计费粒度正从「实例」细化到「任务」（观察指标）→ 启发：做 Agent 产品时，不要把大脑和手绑在同一台机器上。

二、沙箱：毫秒启动与内存快照，以及「大脑/双手」分离

周鹏飞介绍的腾讯云开源沙箱项目（转写稿中名称破碎，下文按其发音统一记作「Q3 Box」，真实项目名待核，疑似 Cube Sandbox 类命名）给出了沙箱层的具体形态。单个沙箱实例启动速度 60–80 毫秒，对比不做额外优化的 K8s 容器 Pod 冷启动需要数秒；沙箱独占一个 Linux 内核，沙箱与沙箱之间四层网络默认不通，通过基于 eBPF 的自研虚拟交换机（转写为「QVS」）提供七层网络策略，可以精细控制 Agent 能访问哪些网站和 IP。快的原因来自工程堆叠：预热资源池把镜像提前缓存到节点、镜像格式转换与懒加载（用到哪层拉哪层）、以及闲时把 CPU 和内存释放给同节点的其他任务。

沙箱最值得注意的两个能力都直接对应 Agent 产品的交互形态。一是快照与克隆：ChatGPT 里对当前会话做分叉、复制一个新会话，背后就是基于内存快照的一到多复制——把运行态数据、会话和整个进程保存成快照再快速拉起。这为 Deep Research 类复杂任务做子代理多分支运行提供了基础设施。二是跨节点暂停与恢复，靠底层存储共享和缓存实现，用于灾备和资源混布。该项目兼容 E2B 的 SDK——周鹏飞判断 E2B 协议已是业内最通用的事实标准；项目在 GitHub 上有近 13 万 Star（讲者自述数字），最新版本 0.73，除腾讯外还有中邮、联想等参与维护。

架构层面，周鹏飞对比了两种主流 Harness 形态。一种是 Agent in Sandbox：单个 Agent 连同执行环境跑在一个沙箱甚至本地笔记本上，多数开源 Harness（他列举了 Codex、转写为「爱马仕」的 Hermes 等）属于此类，面向本地场景。另一种是他所推荐、也是腾讯在企业生产环境推动的 Brain-Harness 分离架构：Agent Loop 是无状态的大脑，负责理解、推理与工具调用编排；具体执行放在沙箱这双「手」里，两者通过远程 SDK 调用。他提到今年四月 Anthropic 推出其 Agent 平台（转写名破碎，疑为 Claude Mesh Agents 之类）时主推的就是这种首脑分离架构。分离的好处很实际：不受信的任务执行或内存耗尽只会弄挂沙箱，不会连带摧毁整套会话与基础设施。鲲鹏的王亚娟后来补充了第三种可能：Agent 完全在沙箱之外、作为独立的分布式云服务存在（Agent with Sandbox），未来或许会演化出专门的 Agent Cloud 基础设施形态。

三、数据面：瓶颈正从「算」转向「搬」

第二位讲者马腾（转写稿称其为某传输引擎社区的 maintainer，项目疑为月之暗面发起的 Mooncake，下文按特征记作「传输引擎项目」）从存储与 I/O 角度讲强化学习与推理系统的优化。这个 2024 年七八月发起、Apache 2.0 协议的项目，由月之暗面（转写破碎）联合清华、阿里、蚂蚁、华为等参与，核心组件包括分布式 KV Cache 存储池与高性能传输引擎，支持 NVIDIA、AMD、昇腾、寒武纪、摩尔线程等异构加速器，2026 年还加入了 Apple Silicon 支持。它的愿景是把 KV Cache 和模型权重放进同一套基础设施。

两个实测数字值得记住（均为讲者自述）。其一，rollout 数据读取：Agent 场景下 rollout 中间数据暴涨之后，他们用结构化对象、buffer 复用、按阶段异步发布等手段替代原有读取负载，在某个数据集上取得 10–14 倍加速——核心思路是复用已注册的内存缓冲区、减少分配与拷贝，让异步的 rollout 数据流与存储层天然对齐。其二，权重同步：训练侧更新完成后要把新权重快速推到推理侧，传统做法是建立进程组做集合通信广播，开销大；他们改为点对点传输，让多个训练 Rank 通过副本节点聚合后同时发送，在 1T 参数、特定量化精度（转写存疑）与 FP8 的场景下，把 50 秒的传输压到 7 秒，比广播方式快约七倍，并称已在微软的产品上实际使用。

这条线索的完整链条是：**RL 后训练规模化使 rollout 数据暴涨到几十 GB、权重需要分钟级同步（机制）→ 瓶颈从 GPU 算力转移到数据搬运路径（直接影响）→ 传输引擎 + 分布式存储池成为独立的基础设施层，并从 KV Cache 扩展到权重统一管理（二阶影响）→ 观察指标是 PD 分离架构下 KV Cache 命中率与权重同步时长 → 启发：判断 AI 基础设施投资或选型时，先算 I/O 账再算算力账。**这个判断与鲲鹏讲者后来的内存池化方案、与沙箱的快照池设计，本质上是同一件事在不同层面的投影。

四、推理引擎、算子与编译器：国产芯片的开源上游攻略

第三到第五位讲者都来自华为系，串起来恰好是「推理引擎 → 算子 → 编译器」的三层下钻，而贯穿三层的真正主线是同一个战略选择。

华为昇腾的田富伟先讲了背景：从去年开始华为意识到，靠任何一个组织（哪怕一个强大的公司）层层堆人力，很难与一个全球开发者都在贡献的框架对抗，于是定下「拥抱开源」的策略，直接参与 vLLM 社区共建，在项目下建立昇腾子仓（转写记作 vllm-ascend）。分工上，vLLM 上层负责服务接口、调度与 KV Cache 管理，凡与硬件相关的部分都下沉到子仓，通过 platform 插件和通用插件两种接口对接，注册机制用的是 Python 原生的 entry points。他坦率分享了教训：V1 版本没有复用上游的 EPLB（专家负载均衡）控制器代码，自己重写了一遍，「维护成本非常高」；V2 重构改为继承上游、只改必要部分——这是「融入上游」与「保持独立」之间很典型的工程折返。

EPLB 本身是 MoE 推理的一个精彩案例。MoE 模型里每个 token 要选若干专家（top-6/top-8），专家负载天然不均：热点专家所在的卡计算量特别大，快的卡必须等慢的卡。EPLB 的做法是把热点专家复制冗余副本摊到其他卡上，并在数据热度变化时不断后台迁移专家权重——迁移全程异步，不打断前台推理。难点在传输本身：上游默认的单边通信库在部分环境不可用，回退到走主机的 Gloo 后要做设备到主机再到设备的两跳拷贝，速度慢，还会与主线程争抢 GIL 影响推理。他们的应对分两层：算法上，同事发明的 FlashLB 把优化目标从「窗口平均负载」改为风险函数（峰均比 + 方差 + 协方差），解决负载热点的迟滞问题——迁完之后热点可能已经变了；工程上引入「迁移预算」约束每次迁移的数据量，代价是收敛变慢、且预算设太小会把解困在局部最优。田富伟留了一个诚实的开放问题：上游社区新出的 Migration Batch 分批迁移特性能否与 FlashLB 组合替代迁移预算方案，「可能需要一个实测」才能确定，他个人猜测两者结合效果更好。

算子层的付冰洋讲 Triton for Ascend：2026 年 3 月，昇腾后端正式成为原生 Triton 社区的 Module，是国内首个获社区认证的原生后端（讲者自述）。他给出的昇腾芯片画像很清晰：与 GPU「核小而多」相反，NPU 核大而少，每个核是一个做矩阵乘的 Cube 核加两个做向量运算的 Vector 核。这个结构决定了大量优化方向：不连续的数据搬运要走专门的小包通路；Cube 和 Vector 交替的 attention 计算要做静态排布加动态计分板调度消除流水空泡（长序列 128K 下算子 MFU 达到 77.38%，讲者数据）；向量化计算改成张量化、把 batch 维度切开并行，「基本上可以解决百分之八十左右的算子的性能问题」。最有说服力的案例是 FlexAttention：mask 矩阵存不下，团队发现矩阵里 empty 的地方极多、本质稀疏，只存有数据的部分把显存激活压下来——「可能你用 AscendC 算子要写一天两天三天的东西，Triton 一个下午就搞定」（付冰洋，AscendC 为笔者据上下文校正）。

编译器层的武林飞讲昇腾算子编译的中间表示（转写名严重破碎，疑为 Ascend CIR 之类，基于 MLIR 构建），从方言分层、cube/vector 双核拆分、寄存器化指令集的应对，一直讲到模调度与 preload 的引入、缓冲区复用与「跷跷板问题」（有些算子融合后变好、有些变坏）。要点在于：用户写一份 Triton 代码，完全不感知底下 Cube/Vector 分离、内存层级与对齐、1:2 的核数比，全部由编译器自动拆分、推导和调度；当编译器优化到极限后，他们选择向用户开放内存层级、缓冲区大小这类轻量编程接口——因为「有些算子，编译底层如果不开放接口，其实是很难调的」（武林飞）。

把三位华为讲者合起来看，链条是：国产芯片单点性能与国际生态存在差距（背景）→ 华为从自研分支转向 vLLM/Triton 上游插件化与原生认证（机制）→ 开源框架里的「第一公民」生态位本身成为芯片的分发渠道，性能缺口用编译器与算子优化弥补（影响）→ 观察指标是上游 PR 的合并速度与商用交付案例 → 启发：性能差距可以靠工具链慢慢补，生态差距只能靠进入上游去补；这两件事的难度和时间尺度完全不同。

五、被重新估值的 CPU：通算的第二增长曲线

压轴的鲲鹏 AI Agent 技术专家王亚娟换了一个几乎被全场忽略的视角：CPU。她的推理很直接——Agent loop 里除了推理这一步，编排、工具调度、记忆检索、结果反馈迭代「其实大部分是在 CPU 上解决的」。行业数据（讲者引用）是：训练时代数据中心 CPU 与 GPU 的配比约为 1:8，进入 Agentic 时代当前已到 1:4，未来随着长程任务和复杂 Multi-Agent 带来更多工具调用与记忆检索，可能走向 1:1，甚至 CPU 占比反超。英伟达基于 ARM 推出 CPU 产品、AMD 与英特尔提出占比变化，被她引为行业共识的注脚：通算正从配套角色变成 AI 基础设施的第二增长曲线。需要提醒的是，鲲鹏是 CPU 厂商，这一预测与其商业利益直接相关，宜当作厂商立场而非中立判断。

鲲鹏的答案是泰山 950 超节点（讲者自述规格）：保持通用服务器形态不变，额外加统一互联总线（转写为「零区」，疑为华为灵衢 UnifiedBus）与电、光组网，实现跨节点内存语义访问——A 节点内存不够可以借用相邻节点内存，多节点可以共享一个大内存池以减少数据副本；传统线缆下可联 8 节点、约 16T 级内存，光组网可扩展到五百至上千节点。落到 Agent 场景，方案与前面几位讲者形成互文：沙箱快启动靠跨节点的内存快照池与全局 warm pool，目标是「千实例启动小于一秒、单实例快照启动小于五十毫秒」；他们实测单个预留 2U4G 的沙箱，运行期 CPU 平均利用率低于 20%、内存低于 30%，这些空闲资源正是高密部署与降成本的空间；记忆系统从过去的多分片分别检索再汇总（分片越多越慢），变成把全部索引放进超节点全局共享池做单点全局检索；Mooncake 类 KV Cache 存储引擎则用总线大带宽加速 Prefill、Decode 与数据节点间的流动，并让 SSD 数据经 CPU L3 缓存直达网卡、绕开内存以省带宽。

最后一条链条由此而来：Agent loop 中编排与检索的计算落在 CPU 上（机制）→ CPU:GPU 配比从 1:8 向 1:4 乃至 1:1 漂移，通算成为第二增长曲线（影响）→ 超节点用统一总线与内存池化把「沙箱快照、记忆索引、KV Cache」这些原本各自为政的负载放进同一池（二阶影响）→ 观察指标是数据中心实际的 CPU:GPU 采购比与超节点落地规模 → 启发：按负载特征（推理 vs 编排检索）重新算算力配比的账，而不是沿用训练时代的比例。

共识、分歧与没回答的问题

六场分享的共识部分相当清晰：Agent 负载的间歇性、长程性与万级并发是所有新基础设施的共同出发点；RL 后训练是沙箱与数据面爆发的第一驱动场景；上下文与 KV Cache 膨胀是公认的下一瓶颈。分歧则大多藏在各自的路线选择里：腾讯推荐 Brain-Harness 分离的云端分布式架构，而开源社区的主流 Harness 仍是本地单体形态，两者会长期并存；华为在 vLLM 与 Triton 内走「上游插件化」路线，与另一些厂商维持自研分支的做法形成对照；EPLB 的算法权衡（FlashLB、迁移预算、上游 Migration Batch 三者如何组合）连华为内部也明说是待实测的开放问题。论坛没有回答的包括：Agent Cloud 作为第三种基础设施形态何时真正成立；沙箱隔离被讲者自己承认「可能还远远不够」之后，下一层安全机制是什么；以及通算占比的乐观预测在非厂商视角下能否兑现。后续值得盯的观察点：该沙箱项目的版本迭代与商业客户名单、vllm-ascend 与 triton-ascend 在上游的合并节奏、以及国内数据中心 CPU:GPU 采购比的实际变化。

对个人开发者而言，这场论坛最实际的收获可能是一句话：Agent 时代的竞争表面看是模型能力，落到工程上是启动毫秒数、搬运字节数和上下文命中率——大脑可以租，手和血管要自己选。

转写与校正说明

本文依据本地 ASR 转写稿写成。大会实录无说话人标签，各观点归属由上下文推断：六位讲者均经主持人报名或自我介绍确认（周鹏飞/马腾/田富伟/付冰洋/武林飞/王亚娟），个别处主持人称呼与自报不一致时以自报为准；转写稿第二位讲者自报社区名（转写「OneK」）与其描述的项目特征（Apache 2.0、KV Cache 传输引擎、月之暗面与清华参与）指向 Mooncake，因无法完全确认，正文以「传输引擎项目」指代。主要疑似 ASR 错误及校正：「Azure 基基础设施」→Agentic 基础设施；「Q3 Box/CubexandBox/Cube三Boss」→腾讯云开源沙箱项目，真实名称待核；「深腾社区」→疑为昇腾社区；「VM/BM/VLM」→vLLM；「VM Stand」→vllm-ascend；「Triton Sam/Triton Long/升腾芯核」→Triton-Ascend；「DeepJem」→DeepGEMM；「Helian」→Helion；「垂盆」→Triton；「暂息算子」→AscendC 算子；「Ascend NPYR/CNTYR」→昇腾算子编译中间表示（名称待核）；「MIR/MARI」→MLIR；「磨调度/积分板」→模调度/计分板（scoreboard）；「N F U」→MFU；「MS proof」→msprof；「Nixle」→疑为 NCCL 类通信库；「格路」→Gloo；「roast」→rollout；「Moon Catch/Monkey Store/Outlight」→疑为 Mooncake/Mooncake Store/Moonlight；「零区/乌马」→疑为灵衢 UnifiedBus；「Mariner CPU」→疑为 Grace CPU；「S E S」→ToC；「rep rep 库」→RAG 库；「沙 MFS」→疑为 SquashFS。文中所有性能数字（13 万 Star、10–14 倍、7 倍、77.38%、五点五等）均为讲者在场自述，未经独立验证。