AI 基础设施

Agent 云：一个应用服务百万人 → 百万个 agent 各跑各的

上一代云的设计中心是"一个应用服务百万用户"；这一代反过来——百万个 agent 各跑一个小应用，要隔离、要状态、要冷启动。

上一代云的整套设计，是为了让一个应用服务几百万人：应用层无状态、可以随便复制，状态全推到数据库里，一切都在优化吞吐和利用率。你租一台机器，机器跑你的代码，其中很大一部分存在意义就是用更少的机器塞进更多的人的请求。

所以经典云栈就四样东西：虚拟机（EC2）、文件存储（S3）、托管数据库（RDS）、负载均衡。

现在，agent 把这个需求结构翻了过来。

Agent 云正在长出来

我认为"agent 云基础设施"的核心支柱正在显现，而且它看起来会比传统云基础设施大得多。

换个说法：旧云是"一个应用服务几百万人"，agent 云是"几百万个 agent 各自跑一个自己的小应用"——而且负载类型非常杂。这些小应用有的只跑几秒，有的跑几天，什么长度都有。更要紧的是：每个 agent 要自己的一台机器，而不是某台大机器上切出来的一片——因为正在跑的那段代码，很可能是模型几秒钟前才写出来的。每一个都要存自己的状态、记住干到哪儿了，以便暂停和继续。而且这些负载不可预测，是成批涌进来的。

黄仁勋今年在 Vera 的发布会上把这层讲得很清楚：老一代 CPU 是围绕"可租用的核心"设计的，但一个 agent 不想租一个核心，它想让这件事快点干完。

所以优化目标变了：过去优化利用率与吞吐，现在优化的是隔离、内存、冷启动时间。

要搭的东西，已经开始长成这样：

沙箱：这是新的"虚拟机"。每个 agent 任务一台一次性、被隔离的计算机。
持久状态：这是新的"文件存储"。一套比单个任务活得久的文件系统，这样 agent 才能暂停、打快照、分叉（fork）。顺带一提：Tigris 本周被 Dropbox 收购了。
推理：最不用解释的一块。Baseten、Fireworks、Modal 这类推理云正在起飞。
路由 / 网关：这是新的"负载均衡"。过去是把流量分摊到一堆一模一样的服务器上；现在你要把负载分摊到不同的模型上。
RL 与训练回路：把开放权重模型变成你自己的模型所需要的那套基础设施——你要环境、要评测、还有一堆别的服务。
底下的 CPU、存储、网络：很无聊，但仍然需要——而且需要的量比过去那种简单的云基础设施大得多。

这些只是最初的核心支柱。围绕它们，还有一圈正在形成：工作流 / 持久执行、让 agent 能用 web 的浏览器基础设施、为所有被写出来的代码准备CI/CD 与测试算力、每天能存 PB 级的新 git 后端（顺带：Pierre Computer Company 被 OpenAI 收购了）、身份与支付轨道、以及量级大一个数量级的可观测性（agent 吐出来的指标数据太多了）、还有记忆存储等等。

净结论：我认为所有这些 agent 云基础设施，最终会让经典云基础设施显得很小（我说"经典云基础设施"时，更多指的是"云上的应用基础设施"）。第一代云，是给人跑应用准备的算力、网络与存储；新的云核心原语一样，但是为 agent 重造的，而且下面的单元数量多得多。

未来 12 个月 agent 云会怎么演化，我很想看到——我觉得我们该迎来一次爆发了。

这一周的数字：软件公司估值

原文这部分以周度图表呈现（EV / NTM 收入倍数、周涨跌、按增速分组、散点等），图表是交互式渲染的，这里把可核的数字抽成表，图请回原文看。

整体

指标	值
全部样本中位数	4.5x
前 5 名中位数	25.2x
10 年分位	4.8%

按增速分组（高增长 = 未来 12 个月预期增速 >22%，中增长 15%–22%，低增长 <15%）

分组	EV / NTM 收入中位数
高增长	15.9x
中增长	5.6x
低增长	3.8x

作者自己说明了 22% 这个切点是"为了每桶里大约有 10 家公司、样本量够"，承认它偏任意。

运营指标中位数

指标	中位数
未来 12 个月增速（NTM）	13%
过去 12 个月增速（LTM）	17%
毛利率	76%
营业利润率	4%
FCF 利润率	21%
净留存（NRR）	109%
CAC 回收期	31 个月
销售与市场占收入	34%
研发占收入	22%
管理占收入	13%

口径说明（原文）：SaaS 公司的估值多用"企业价值 ÷ 未来 12 个月预期收入"；企业价值 = 市值 + 债务 − 现金。负 FCF 的公司不进入 FCF 倍数图。数据来源含 Bloomberg、Pitchbook 与公司财报。

编者补充

把原文那六根柱子跟旧云并排放在一起，差异一眼能看出来——变的是"计费和扩展的粒度"，不变的是"算力、网络、存储"这层底座：

维度	旧云（应用云）	Agent 云
计算单元	虚拟机 / 容器，长期驻留	沙箱，一次性、按任务、强隔离
状态	无状态应用 + 数据库	持久文件系统，跨任务存活、可快照可分叉
路由	负载均衡：同构服务器之间分摊	模型路由：异构模型之间分摊
扩展方式	加机器加副本，优化利用率	冷启动要快、隔离要硬，优化的是并发 agent 数
谁来写代码	人	模型刚写的（所以必须一个任务一台机器）
计费口径	席位 / 用量	任务、时长、token、沙箱分钟数

三点边界要说明。其一，这是投资人视角的行业判断，作者 Jamin Ball 的每周报本身就是做云软件数据与估值的，立场偏向"这层会变大"，文中"会让经典云显得很小"是不可验证的预测。其二，文中点到的收购（Tigris 被 Dropbox、Pierre Computer Company 被 OpenAI）是当周事件，我按原文转述，未独立核实。其三，估值数字是周度快照，中位数会随时间明显漂移，引用时务必带日期。

对我们自己的含义：我们做的 MCP 网关和工具桥接，位置在原文说的"第二圈"——不是沙箱、不是推理云，而是身份、权限、审计、工具接入那一层。这层在旧云时代是"顺带附带"的（IAM、API Gateway），在 agent 云里会变成单独的品类，因为做动作的主体从人变成了会自己写代码的进程。这也解释了为什么过去一年"给 agent 一把能操作工程/产线的手"这件事突然有市场：它不解决模型能力，它解决的是"动作的边界"。

本文由汇智网 · Software 2.0 编译整理，转载请注明出处。