Serverless 之后，为什么 agent 需要一套新的云计算积木
网页请求通常来得快、结束得也快；agent 任务却可能运行几十分钟，在中途打开浏览器、执行代码、等待审批、失败重试，然后从上一次状态继续。
这不是把 API 响应时间调长一点就能解决的变化。
Guillermo Rauch 的完整观点
Vercel CEO Guillermo Rauch 宣布，Google Cloud Run 的创造者 Steren 将加入 Vercel，负责 Fluid 系列计算产品，包括 Functions、Containers、Sandbox 和 Builds。
他把云计算的演进分成两个阶段：serverless 是上一章，Steren 曾在 Google 帮助定义这一范式；agents 是下一条前沿，它们需要专门为其设计的新 compute primitives。Vercel 希望由同一个理解 serverless 的人，再次推动这次基础设施转换。
Matrix 的判断
Agent 对计算的需求，和传统网页后端有四个明显差异。
第一，它的生命周期更长，需要暂停、恢复和跨部署保存状态。第二，它会运行模型生成的代码，需要隔离权限与资源。第三，它经常调用外部工具，失败不是返回一个 500 就结束，而要决定重试、补偿还是请求人工。第四，它的成本路径不固定，一次错误循环可能同时消耗模型、浏览器和计算资源。
Functions、Containers、Sandbox、Builds 分别解决其中一部分，但真正的新积木应该让这些能力可以被同一个任务编排，并拥有统一的身份、日志、预算和停止机制。
产品团队现在应该问什么
不要先问 agent 要部署在哪种 runtime，先画出一次任务的生命周期：什么时候开始、状态放在哪里、会调用什么、哪里需要审批、失败后如何恢复、最高允许花多少钱。
如果这张图画不出来，换任何基础设施都只是把不确定性搬到云上。Agent 时代的云产品，最终竞争的不是能跑多少进程，而是谁能让长任务在不确定环境里仍然可理解、可恢复、可控制。