过去，人们与大模型的交互是一条相对简单的链路：输入 Prompt，模型生成 Response。
进入 Agent 时代，这条链路变成了“规划—推理—行动—反馈”的循环。
一次用户请求，可能进一步调用网页、API、数据、工具、代码和其他系统，展开为成千上万个机器动作。
以“分析销售数据并生成报告”为例，Agent 需要读取文件、准备依赖、编写并运行代码、检查结果，再根据反馈修改重试。
生成文字只是其中一步，任务要靠一连串实际操作才能完成。
CPU 也因此不再只是为 GPU 做配套，而要参与整个工作流的编排和 Action 执行。
问题随之而来：当 AI 从“生成答案”走向“执行任务”，过去围绕模型推理设计的基础设施，还够用吗？
腾讯云与英特尔围绕智能体基础设施的协同，正是从这条更长的执行链路出发，回应计算、内存与执行环境上的三重挑战。
第一重挑战：算力有起伏，现场不能丢 Agent 并不是始终满负荷计算。
它更像“想一下，干一下，再想一下”：等待模型或工具返回时，CPU 需求回落；处理数据、执行代码、运行测试时，计算需求又迅速上升。
这是 Agent 负载的常态——资源需求随任务推进起起伏伏，要求基础设施能够跟随行动节奏灵活调配算力，而不是始终按照峰值预留。
计算可以暂歇，工作现场却不能随之消失。
已经载入的数据、装好的依赖、执行到一半的程序，以及多轮交互中累积的状态，都需要跨越多个 Action 持续保留。
第一重挑战由此出现：：应对突发性计算负载（bursty workloads），同时保障任务状态的持久化（state persistence），让 Agent 在下一次行动时能够接着干。
按峰值长期预留资源，等待阶段容易闲置；每次空闲都拆掉环境，下一步又要重新搭建现场。
Agent 需要的弹性基础设施，不能只做到“忙时加核、闲时收核”，还要能够保存现场，并在新的行动到来时恢复执行。
弹性的对象，不只是算力，也包括支撑任务推进的状态。
腾讯云 Cube Sandbox 把这一需求拆成两种弹性。
计算弹性，强调快速启动、高密度和大规模并发；状态弹性，强调暂停与恢复、快照与克隆，以及跨节点恢复。
平台不再只管理一次请求需要多少资源，还要管理一段任务如何等待、接续和分支执行。
这也明确了双方协同的方向：Cube Sandbox 在运行时层面管理环境的创建、保存和接续，英特尔至强在底层支撑环境编排、任务执行与状态处理。
当越来越多的 Agent 需要同时保留工作现场，软硬件配合要解决的下一个问题，就是这些现场究竟放在哪里、如何高效容纳。
第二重挑战：核心够用，内存可能先不够
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接