Agentic AI 的开发和大量落地，正在把一批过去不够显眼的基础设施问题推到台前。

过去两年，市场谈 AI 算力有一种简化认知：AI 算力，几乎等同于 GPU。

类似的简化也发生在云上。在很多人眼中，云计算等同于“租算力”。云像是一座远程大机房，负责把算力供给出去，至于应用如何运行、协作、演进，往往被放在次要位置。

这套认知已经脱离产业事实了。

AI 产业逐步从单纯聚焦模型训练，转向同时重视模型部署、推理效率与真实应用落地。在 Agent 爆发的背景下，AI 工作负载正变得更碎片化、更动态，也更依赖高频任务调度、内存管理、工具调用与系统编排。

随着 AI 负载类型和规模的变化，云计算和 CPU 都被委以重要使命和新的期待。

首先，CPU 正在重新获得更高的关注度。

Agent 负载的特点，正在催高市场对高核心数 CPU 的需求，尤其是在云端多租户、沙箱执行、会话并发和多 Agent 协作等场景里，CPU 承担着任务编排、执行铺开与资源调度的关键职责。

这种变化已经传导到业务侧。AMD 全球副总裁、中国区互联网事业部总经理刘宏兵也提到，过去几个月，公司一直在尽最大可能保障客户需求及 AI 基础设施。

与此同时，云计算的角色在发生变化。阿里云智能集团研究员、容器服务负责人易立表示，过去云计算主要提供的是算力，而现在，云还要提供一整套能够让智能体安全运行、稳定交付、持续进化的平台能力。

作为云原生的操作系统，容器的重要性因此再次凸显。它是 Agent 在云端部署的主流承载方式，提供标准化、轻量隔离的运行环境，并协同编排系统实现任务调度、弹性扩容，为上层的持续治理与监控奠定基础。根据 Docker 发布的《State of Agentic AI》报告，94% 的受访者在 Agent 的开发或生产环境中使用容器，其中 98% 延续了传统软件时代的云原生工作流。这表明，当 Agent 从实验走向生产，行业并没有舍弃已有的基础设施体系，反而更加依赖这些经过验证的交付和治理能力。

这背后对应的，其实正是 Agent 开发和使用者最在意的几件事：安全、稳定和可持续迭代。

最近爆火的 Agent 项目，包括 Kimi 的深度研究、通用 Agent 模式“OK Computer”、MiniMax 的 MaxClaw、MaxHermes 等产品，背后都有阿里云支撑。而 AMD 也为阿里云提供了底层算力支撑。

为了支撑这一轮变化，云计算和芯片厂商分别做了哪些调整，又如何共同应对 Agent 负载带来的新压力？

在本期《C 位面对面》中，极客邦科技创始人、CEO 霍太稳邀请阿里云智能集团研究员、容器服务负责人易立，以及 AMD 全球副总裁、中国区互联网事业部总经理刘宏兵，一起讨论 Agent 时代基础设施正在发生的变化，以及这些变化把云计算和芯片引向什么方向。

技术和商业的早熟，推动龙虾爆发

OpenClaw 的爆火，让行业第一次更直观地看到 Agent 接管工作的可能。随后，越来越多厂商开始推出“国产龙虾”，把部署门槛、使用成本和上手难度一起拉低。结果是，Agent 不再只是少数人的玩具，而是在更大范围内快速扩散。

阿里云智能集团研究员、容器服务负责人易立，已经把龙虾真正嵌入了自己的工作流。他在不同环境里部署了不同角色的 Agent。云上 Agent，会在他上班路上提前整理好关注的新闻、热点和技术论文；作为容器服务团队负责人，他还需要 24 小时值守的 SRE Agent，帮助分析线上集群问题、处理异常；而桌面端的 Agent，则负责日程整理、技术规划、会议安排和纪要输出。

InfoQ 也关注到了更加“激进”的应用。霍太稳表示，TGO 鲲鹏会硅谷分会长黄东旭与超过 2500 个智能体协作，已经重写了过去一个团队花 10 年才完成的 TiDB 体系，他每天消耗的 Token 量，已经超过 10 亿。

与此同时，一些平台开始让 Agent 与 Agent 之间直接通信与协作，智能体逐渐形成网络结构，不再只是围绕人展开。

在观察到这种规模跃迁后，AMD 全球副总裁、中国区互联网事业部总经理刘宏兵打趣说，也许未来会出现一个“龙虾社会”。当越来越多人同时拥有、调用、依赖多个 Agent，而这些 Agent 又彼此协作时，这个略带玩笑意味的说法，正在变成一种现实。

这轮增长不只是技术能力带来的，也与商业闭环比过去来得更快有关。

AMD 全球副总裁、中国区互联网事业部总经理刘宏兵提到，互联网客户过去一直有时间焦虑，即前期的大规模投入，究竟什么时候才能真正变现。无论是早年的云计算，还是后来的 AI，产业都曾经历过很长的投入期，商业闭环来得很慢。

这一轮 Agent 热潮的特别之处在于，从模型、平台到应用，整个链条的变现速度都明显加快了。提供 Token 和云资源的大厂可以更快获得收入；个人用户和中小企业，也能更直接地把 Agent 转化为效率提升，甚至业务收益。

AI 负载的新需求

随着 Agent 应用的规模化落地，AI 工作负载正经历结构性分化。

与传统软件处理确定性、边界清晰的任务不同，Agent 需面向开放式目标进行自主决策、持续环境交互与长链路任务执行。这种范式转变，使得 Agent 在应用、推理与训练三个层面呈现出与传统 AI 负载截然不同的技术特征。

在应用层面，Agent 不再仅是简单的文本生成，它可以调用工具、连接系统，甚至执行代码。安全、隔离和可控性成为首要前提。每个 Agent 都需要运行在沙箱环境中，依托计算、存储和网络的协同控制，才能既安全又高效地完成任务。与此同时，Agent 常将复杂任务拆解成多步并行操作，例如新闻检索、数据分析或子 Agent 协作，这就对冷启动延迟、并发吞吐能力提出了高要求。再加上任务跨越多轮对话和多阶段执行，状态保存与休眠唤醒能力，成为保障连续性和降低成本的关键。

推理层的负载特征也发生显著变化。Agent 的上下文窗口不仅包含用户指令，还需动态嵌入规则定义、工具返回数据及历史交互轨迹，导致内存占用与计算开销呈非线性增长。这要求底层架构打破单一 GPU 加速的传统思路，转向 CPU、GPU、内存与高速网络的协同优化，以在保障长窗口推理稳定性的同时实现成本控制。

易立还指出，Agent 模型训练与传统的预训练也很不一样。传统预训练更关注 GPU 性能，但 Agent 模型必须在真实场景中模拟、学习复杂任务决策，其能力很大程度上取决于对工具调用的掌控，这意味着 CPU 计算吞吐、内存带宽以及分布式调度架构的协同效率，反而成为影响训练迭代速度的关键瓶颈。

整体而言，Agent Infra 的核心命题早已不再是高效运行模型，而是实现智能体的安全隔离、状态管理与规模化运行。

Agent Infra 的四个关键问题

AI 负载的变化，也在改变行业真正关心的指标。刘宏兵说，过去大家更关注模型刷分，看榜单、看参数、看单点能力；但到了生产环境里，客户最终关心的，是能不能稳定交付业务结果，以及端到端体验和 ROI。

在这种前提下，Agent Infra 至少要解决四个问题：强隔离、高并发和低时延、状态和记忆管理，以及长链路执行。

首先是强隔离。

Agent 不只是生成文本，它还会调用工具、连接企业系统，甚至执行代码。到了这个阶段，安全已经不是一个额外补丁，而必须成为默认前提。基础设施需要提供安全沙箱、细粒度权限控制，以及计算、存储、网络的一体化隔离能力。只有先把边界划清楚，Agent 才能从“跑得起来”走向“跑得可控”。

第二个问题是高并发和低时延。

Agent 往往会把一项复杂任务拆成多个步骤并行推进，比如工具调用、子 Agent 协作、搜索和分析。这意味着，系统面对的不是少量持续运行的大任务，而是大量同时涌入的小任务。沙箱系统的冷启动时延和并发吞吐能力，会直接影响 Agent 的执行效率，也直接影响用户体验。

第三个问题是状态和记忆管理。

Agent 任务往往跨越多轮对话，不是一次调用就结束。它需要保留上下文、记忆用户意图，还要在任务中断后继续接上此前的状态。因此，Agent 沙箱基础设施必须具备高效的“休眠—唤醒”能力，让任务可以像人一样，随时暂停，随时恢复，保持记忆连续。

最后，是长链路带来的系统复杂度。

Agent 并不是一次性的模型响应，而是一个持续多轮交互、持续规划、调用工具、观察结果、修正决策的长链路过程。这样的执行方式能够提升复杂任务的完成质量，但也会显著放大系统复杂度、Token 消耗、故障排查难度。因此，Agent Infra 不只是“把 Agent 跑起来”的运行环境，而是支撑 Agent 在生产环境中稳定、可控、可观测、可持续优化的系统。

更进⼀步看， 未来的智能形态将从单智能体向动态⽣成的集群进化。Kimi 的 Agent Swarm，OpenClaw 对 Agent Client Protocol (ACP)⽀持都指向同⼀个⽅向：Agent 从单体应⽤，演进成分布式、⾃规划、⾃组织的软件系统。 这要求 Agent Infra 的职责从单一智能体的生命周期管理，升级为对动态协作集群的编排、治理与资源统筹。

这一架构演进同时带来效率范式的重构。在企业侧，竞争逻辑从固定流程优化转向智能驱动的价值创新，通过多智能体协同实现数据到决策的自动化闭环；在个人侧，开发者可借助“一人多 Agent”模式完成团队级产出。

面对集群化协作与长链路执行带来的工程复杂性，易立指出，Agent 的开发范式正从早期的提示词工程转向上下文工程与 Agent Harness；Agent Infra 需将安全沙箱、全链路可观测性、自动化评测体系、与安全护栏等沉淀为标准化平台能力。

云计算与芯片的新任务

在新的负载形态和 Agent Infra 的要求下，云和 CPU 的任务都在发生变化。

阿里云看到，云的角色不再只是提供算力，还要提供一整套让智能体安全运行、稳定交付、持续进化的平台能力。换句话说，云正从“资源池”进一步变成“Agent 工厂”，要负责智能体如何启动、如何隔离、如何调度、如何恢复、如何监控，以及如何在生产环境中被持续运营。

正在推进 Agent 创新的新锐 AI 厂商，已经着手联合云与芯片厂商解决这个问题。无论是 Kimi 的深度研究和通用 Agent 模式“OK Computer”，还是 MiniMax 的 MaxClaw 及其他全栈 Agent 产品，背后都离不开阿里云的支撑，而 AMD 则为这套云基础设施提供了更底层的算力底座。

这种变化，首先体现在运行时设计上。为了应对 Agent 的强隔离和突发式并发的需求，云基础设施需要更快地创建执行环境，也需要更强的弹性调度能力。

为此，阿里云 ACS Agent Sandbox 可以做到百毫秒级的沙箱创建、按需供给的弹性资源池，并且围绕 MicroVM、NetworkPolicy、安全挂载、身份授权和审计能力，建立起了端到端隔离。

ACS Agent Sandbox 通过自定义模板预热，将镜像、依赖和配置提前加载到缓存中，再结合 MicroVM 的轻量化特性，把 Agent 实例的拉起时间压缩到 20 到 40 毫秒。同时，它还能支持最高每分钟 15000 个沙箱的弹性伸缩，任务触发时按需创建，结束后自动释放。

Agent 的另一项关键要求，是云必须更擅长处理“有状态”的任务。传统云服务更擅长处理无状态、短生命周期的请求，但 Agent 的很多任务需要跨越多轮对话，甚至在暂停一段时间后再继续执行。因此，基础设施要能保留上下文、保存运行现场，并在任务恢复时以接近实时的速度把它重新拉起。对用户而言，这是“记忆连续”；对底层系统而言，则是更复杂的状态管理能力。

为了解决这个问题，阿里云把运行环境与状态解耦，并通过持久化存储保障任务续接。状态实时保存在 ESSD 和 NAS 中，即便遭遇节点故障、实例迁移或弹性调度，Agent 也能基于历史状态快速恢复上下文。ACS Agent Sandbox 同时提供运行时 Checkpoint 能力，使实例在迁移或网络波动期间仍能保持执行链路不断。再加上 阿里云容器服务 ACK 作为统一控制面，负责集中处理任务编排和状态管理，原本分散在单机上的逻辑被提升成了平台级能力。对于长链路任务来说，这意味着系统既能快速拉起，也能在中断之后接着跑下去。

由于 Agent 的状态被持久化存储，任务可以随时暂停或迁移而不中断执行，这让计算资源可以按需释放而非持续占用；同时，每个 Agent 实例的恢复和调度需要秒级响应、高并发支持和灵活扩缩容。正是在这种情况下，Serverless 的事件驱动、动态编排和细粒度调度的特性，天然契合 Agent 的状态管理和弹性需求。

过去，Serverless 更多被理解为一种简化开发和节约资源的云服务模式；但在 Agent Infra 场景里，它的重要性已经不只是“省资源”，而是其事件驱动、动态编排、细粒度调度的机制，天然更贴近 Agent 的工作方式。函数计算沙箱和 ACS Agent Sandbox 的运行机制，和 Agent 的并发执行、动态触发、会话亲和、快速弹性有高度一致性。这意味着，Serverless 在 Agent 时代不再只是一个可选项，可能会成为很多智能体应用的默认底座。

另一边，AMD 看到的第一个变化是，CPU 在 Agent 时代被提到了更加重要的位置。

AMD 的判断是，Agent 业务会把算力需求从集中式的大任务，拉向高并发的海量小任务。在这种变化下，CPU 的角色被重新抬高了。因为任务编排、工具调用、数据处理、安全隔离、状态管理，这些支撑 Agent 正常运转的环节，更多依赖的是通算能力，而不只是 GPU 的矩阵计算能力。

Agent Infra 对芯片提出的要求，至少包括三个层面：一是更高的多核并发能力，用来承接大量同时涌入的小任务和沙箱线程；二是更强的单核和指令集效率，用来加速检索、解析、压缩、加解密、向量计算等工具调用背后的通用计算；三是更高的内存带宽和 I/O 能力，用来支撑上下文保留、状态维护和快速恢复。

以第五代 AMD EPYC Turin 为例，192 核、全链路 AVX-512、12 通道 DDR5 这些指标，在 Agent 场景中，能够满足高峰期并发承载需求，优化单任务完成时间与执行环境恢复速度。

在安全上，云计算与芯片也需要联合解决新的问题。

易立提到，Agent 从一个聊天伙伴，变成真正的工作同事之后，会调用工具、执行命令，但它并不承担责任，这给用户和基础设施构建者都带来了新的挑战。易立认为，不能默认 Agent 不会犯错，必须给它一个受约束的执行环境，让它在可控边界内行动。

所以，安全必须成为平台默认能力。ACS Agent Sandbox 在计算层面用 MicroVM 为每个 Agent 实例提供独立内核，安全边界接近完整虚拟机；也允许开发者进一步控制它是否能访问互联网、是否能访问公司核心应用，同时配合细粒度授权和安全审计。

随着 Agent 权限扩大，只靠过去最小权限、纵深防御这些思路，也开始显得不够。易立提到，在下一代 Agent Infra 里，数据可用不可见会成为一个越来越核心的要求。比如涉及支付、账户、隐私数据的场景，企业当然希望 Agent 可以完成任务，但不会希望它直接暴露用户的银行密码、账号或其他敏感信息。也因此，机密计算开始从一个偏底层、偏专业的能力，走向 Agent 基础设施的中心位置。以 AMD 的 SEV 为代表的机密计算能力，可以让数据在执行过程中依然处于受保护状态，只能被受控的 Agent 使用，而不能被平台方或其他恶意 Agent 直接调用。

安全始终伴随代价。

刘宏兵指出，若加密导致 CPU 算力损失达 30%~50%，多数企业将难以承受；而 AMD 凭借将 CPU 内部硬件加密性能损耗控制在 3%~5% 以内的成绩，显著提升了客户接受度。

如果说上一轮 AI 基础设施竞争，核心是把模型训得更大、把 GPU 堆得更多，那么 Agent 时代真正考验的，则是谁能把一整套系统组织起来。

也正因如此，云计算和芯片的角色都在被重新定义。云不再只是资源池，而要变成运行和治理智能体的平台；CPU 也不再只是 GPU 的配角，更需重新成为并发、状态、安全和成本的关键支点。

今天外界看到的，是 Kimi、MiniMax 等厂商旗下 Agent 产品在台前快速推进；但真正决定它们能走多远的，往往是背后那套更重、更复杂，也更少被看见的基础设施。