过去，人们与大模型的交互是一条相对简单的链路：输入 Prompt，模型生成 Response。进入 Agent 时代，这条链路变成了“规划—推理—行动—反馈”的循环。一次用户请求，可能进一步调用网页、API、数据、工具、代码和其他系统，展开为成千上万个机器动作。
以“分析销售数据并生成报告”为例，Agent 需要读取文件、准备依赖、编写并运行代码、检查结果，再根据反馈修改重试。生成文字只是其中一步，任务要靠一连串实际操作才能完成。CPU 也因此不再只是为 GPU 做配套，而要参与整个工作流的编排和 Action 执行。
问题随之而来：当 AI 从“生成答案”走向“执行任务”，过去围绕模型推理设计的基础设施，还够用吗？腾讯云与英特尔围绕智能体基础设施的协同，正是从这条更长的执行链路出发，回应计算、内存与执行环境上的三重挑战。
第一重挑战：算力有起伏，现场不能丢
Agent 并不是始终满负荷计算。它更像“想一下，干一下，再想一下”：等待模型或工具返回时，CPU 需求回落；处理数据、执行代码、运行测试时，计算需求又迅速上升。这是 Agent 负载的常态——资源需求随任务推进起起伏伏，要求基础设施能够跟随行动节奏灵活调配算力，而不是始终按照峰值预留。
计算可以暂歇，工作现场却不能随之消失。已经载入的数据、装好的依赖、执行到一半的程序，以及多轮交互中累积的状态，都需要跨越多个 Action 持续保留。第一重挑战由此出现：：应对突发性计算负载（bursty workloads），同时保障任务状态的持久化（state persistence），让 Agent 在下一次行动时能够接着干。
按峰值长期预留资源，等待阶段容易闲置；每次空闲都拆掉环境，下一步又要重新搭建现场。Agent 需要的弹性基础设施，不能只做到“忙时加核、闲时收核”，还要能够保存现场，并在新的行动到来时恢复执行。弹性的对象，不只是算力，也包括支撑任务推进的状态。
腾讯云 Cube Sandbox 把这一需求拆成两种弹性。计算弹性，强调快速启动、高密度和大规模并发；状态弹性，强调暂停与恢复、快照与克隆，以及跨节点恢复。平台不再只管理一次请求需要多少资源，还要管理一段任务如何等待、接续和分支执行。
这也明确了双方协同的方向：Cube Sandbox 在运行时层面管理环境的创建、保存和接续，英特尔至强在底层支撑环境编排、任务执行与状态处理。当越来越多的 Agent 需要同时保留工作现场，软硬件配合要解决的下一个问题，就是这些现场究竟放在哪里、如何高效容纳。
第二重挑战：核心够用，内存可能先不够
增加 CPU 核心，并不必然带来同比例增长的 Agent 承载能力。在高密度执行平台上，内存既要服务正在运行的程序，也要承载需要继续保留的状态。当大量环境同时存在，制约密度的可能先是内存容量，而不是核心数量。算力能否充分利用，也取决于这些核心能否获得足够的内存。
英特尔数据中心集团软件技术总监胡勇以一组示例配置进行了测算：假设每个 Agent 占用约 2GB 内存，每个 vCPU 承载 4 个 Agent，则每个 vCPU 需要约 8GB DRAM；而在一套 256 vCPU、12 内存通道、每条 DIMM 128GB 的配置中，平台平均可提供约 6GB DRAM/vCPU，由此形成约 2GB/vCPU 的容量缺口。面向这一问题，可以从三个互补方向提升容量效率。
1. 让现有内存更高效，英特尔 IAA（存内分析加速器）可承担内存压缩与解压。在此次测试配置下，软件 LZ4 方案与 IAA Deflate 方案均达到约 2.1∶1 的压缩比；相较软件方案，IAA 将压缩延迟从 5.70 毫秒降至 0.51 毫秒，将解压延迟从 0.96 毫秒降至 0.08 毫秒，分别约为原来的 1/11 和 1/12。
2. 扩大本地 DRAM 容量，在支持的服务器上，从每通道一条内存的 1DPC 扩展到两条的 2DPC，直接增加本地容量。
3. 引入 CXL 内存扩展路径，为访问频率较低、但仍需保留的状态提供空间，减轻本地 DRAM 的压力。