从开发者体验到智能体体验：AI 云基础设施要改变什么

当云平台的使用者变成智能体

传统云基础设施主要面向人类开发者：阅读文档、编写 YAML、查看仪表盘，再结合经验判断故障原因。即使工具之间存在信息断层，人也能补齐一部分上下文。

智能体则对这些断层更加敏感。它需要在环境中完成一整套操作：编写代码、执行程序、检查输出、修改环境、排查失败，然后再次尝试。 因此，基础设施不仅要提供算力，还要支持带有充分上下文的快速反馈闭环。

这也是“智能体体验”（Agent Experience）与传统开发者体验的关键区别：基础设施需要让智能体能够直接、连续地操作，而不只是方便人类理解。

1. 从人工配置走向程序化控制

沙箱是这一变化的直观体现。智能体可以通过程序创建隔离环境，在其中运行代码、检查结果并继续迭代。

Modal 的技术讨论覆盖无服务器函数、基于装饰器的基础设施配置、沙箱、持久化存储和容器联网等能力。它们对应的不只是应用部署，也包括后台智能体、自动化研究，以及由智能体发起的 GPU 实验。

重点不只是“能否运行代码”，而是能否让环境操作成为工作流的一部分。

2. AI 工作负载要求更强的弹性

Modal 联合创始人兼 CTO Akshat Bubna 的一个核心判断是：传统云平台的设计假设，并不完全适合突发性强、计算密集的 AI 工作负载；他也据此讨论了 Kubernetes 在这类场景中的适配问题。

相关需求包括：

• 自定义模型的弹性推理：涉及音频、视频、机器人和计算生物学等领域。
• 突发 GPU 计算：需要关注资源调度与冷启动。
• 后训练与多节点训练：涉及跨节点通信和算力组织。
• 强化学习 rollout：可能需要大规模并行的执行环境；讨论中提到，这类任务可能需要十万个沙箱。

GPU 快照、推测解码、RDMA 和无服务器多节点训练，都是此次讨论涉及的技术方向。但这些方向各自能带来多少收益，不能仅凭议题介绍作出判断。

3. 代码由智能体编写，可观测性就更重要

当智能体参与编写代码时，只阅读代码并不足以理解系统实际如何运行。执行输出、运行状态与失败反馈，也必须进入调试闭环。

这使可观测性不再只是供人查看的运维界面，也是智能体继续行动所需的上下文。与此同时，生产环境中的智能体仍需要专门设计的沙箱和硬性护栏。更强的自主操作能力，并不意味着可以取消隔离与限制。

4. AI 云的竞争不止于出租 GPU

Modal 讨论的能力还包括弹性推理、Auto Endpoints、联网沙箱、私有 IPv6，以及跨 17 家云提供商组织的容量池。

这些议题指向一个更具体的问题：除了提供 GPU，平台还能否把推理部署、环境管理、存储、网络和反馈机制组织成智能体可以操作的基础设施？

对于正在构建智能体应用的团队，值得关注的不只是单次模型调用，而是完整的执行闭环：智能体能否获得合适的环境，及时看到结果，并在明确边界内继续迭代。