> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # Agent 云：一个应用服务百万人 → 百万个 agent 各跑各的 - URL: https://www.hubwiz.com/blog/agent-cloud-six-pillars-vs-classic-cloud/ - Published: 2026-11-09T17:11:39.000Z - Updated: 2026-11-09T17:12:05.000Z - Description: 上一代云的设计中心是"一个应用服务百万用户"；这一代反过来——百万个 agent 各跑一个小应用，要隔离、要状态、要冷启动。 - Author: admin - Tags: AI 基础设施, 云计算, 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 编译整理，转载请注明出处。 ## 来源 - 原文：[Clouded Judgement 11.6.26 — The Agent Cloud](https://cloudedjudgement.substack.com/p/clouded-judgement-11626-the-agent)（Jamin Ball，2026-11-06） - 原文图表：EV / NTM 收入倍数、周涨跌、按增速分组、散点与 FCF 图均为交互式渲染，本文以数字表替代，图请回原文 - 数据口径与免责声明出自原文；本文对标题与结构做了中文重排，未改动任何结论 > **这是「AI 基建 / 评测 / 安全」专题的一部分。**完整地图见：[AI 基建 / 评测 / 安全完全指南](https://www.hubwiz.com/blog/ai-infra-stack/)