2026 年 3 月，Durable（一家 6 人工程团队服务 300 万客户的公司）在博客中分享了他们的技术栈迁移故事。这个案例揭示了一个被很多开发者忽视的事实：AI Agent 的工作负载与传统 Web 应用有着本质差异，需要专门的基础设施支持。
Durable 的数据：每天 11 亿 tokens
Durable 是一个为小企业提供网站和 AI 客服的 SaaS 平台。他们的工作负载数据令人印象深刻：
- 每天处理 11 亿 tokens（全年约 3600 亿）
- 300 万客户，每个客户的 AI 使用模式差异巨大
- 6 人工程团队，每个人承担 10x 的杠杆效应
- 基础设施成本比自建低 3-4 倍
这组数据背后隐藏着一个关键问题：为什么一个 6 人团队能够处理如此规模的 AI 工作负载？
答案是：他们没有自己构建基础设施，而是全部运行在 Vercel 的 Agent 平台上。
Agent 工作负载的三大特征
1. 不可预测的计算模式
传统 Web 应用的请求响应周期通常在毫秒到秒级：
// 传统 API：响应时间 < 500ms
app.get("/api/user", async (req, res) => {
const user = await db.query("SELECT * FROM users WHERE id = ?", [req.userId])
res.json(user)
})而 Agent 的单次操作可能需要数分钟甚至更长：
// Agent 工作流：可能运行数分钟
async function analyzeCustomerData(customerId: string) {
// 步骤 1：从 CRM 获取历史数据（5-10s）
const history = await fetchCRMData(customerId)
// 步骤 2：调用 LLM 分析（10-30s）
const insights = await llm.analyze(history)
// 步骤 3：生成报告并发送邮件（5s）
await generateReport(insights)
await sendEmail(customerId, report)
}这种模式在传统的 serverless 环境中会遇到两个问题：
- 超时限制：大多数 serverless 平台的函数执行时间限制在 15 分钟以内
- 计费不合理：Agent 大部分时间在等待 I/O（LLM API 响应、数据库查询），但按总执行时间计费
2. 长运行时间和状态恢复
Agent 的多步骤操作需要在失败时恢复状态。假设一个 Agent 执行到第 5 步时 LLM API 宕机了：
传统做法（手动重试逻辑）：
async function customerOnboarding(userId: string) {
let retries = 0
let step = 1
while (step <= 5 && retries < 3) {
try {
switch (step) {
case 1:
await createProfile(userId)
step++
break
case 2:
await sendWelcomeEmail(userId)
step++
break
// ... 每一步都需要手动管理状态
}
} catch (error) {
retries++
await sleep(1000 * retries)
}
}
}这种代码既难维护，又无法应对进程崩溃的情况。
Durable Execution 做法（自动状态恢复）：
import { workflow } from "@vercel/workflows"
export const customerOnboarding = workflow(
"onboard-customer",
async (userId: string) => {
// 每一步失败会自动重试，状态持久化到数据库
await createProfile(userId)
await sendWelcomeEmail(userId)
await setupBillingAccount(userId)
await assignOnboardingAgent(userId)
await scheduleFollowUp(userId)
},
)Vercel Workflows 会自动处理重试、状态恢复、失败通知等逻辑。
3. 安全挑战：运行不受信任的代码
当 Agent 需要执行用户提供的代码或自己生成的代码时，安全隔离变得至关重要。
Notion Workers 的案例很有代表性：他们允许开发者为 Custom Agents 编写扩展代码。这带来了两个致命风险：
- Prompt injection：恶意用户诱骗 Agent 泄露凭证
- 代码逃逸：不受信任的代码访问主机系统
Notion 的解决方案是使用 Firecracker microVM（而非 Docker 容器）：
// Vercel Sandbox：每个 Worker 在独立 microVM 中运行
import { sandbox } from "@vercel/sandbox"
const result = await sandbox({
code: userProvidedCode,
// API keys 通过网络层注入，代码本身无法访问
credentials: { salesforceToken: process.env.SF_TOKEN },
// 动态网络策略：先安装依赖，然后锁定外部访问
networkPolicy: "restrictive",
})为什么不用容器？因为容器共享内核，存在逃逸风险。microVM 提供硬件级别的隔离。
为什么不自己搭建？
Durable 的工程师提到，他们之前尝试过自建基础设施，但很快发现：
- 成本高昂：自建 Kubernetes 集群、配置 SSL termination、实现 multi-tenancy，成本是现在的 3-4 倍
- 人力不足：6 人团队无法同时维护基础设施和开发产品功能
- 迭代变慢：每次部署新 Agent 需要等待 DevOps 流程
迁移到 Vercel 后，他们实现了：
- 单日发布新 Agent：从开发到生产的周期缩短到几小时
- 自动扩缩容：客户的 AI 工作负载峰值可以瞬间应对
- 成本可预测：按实际 CPU 使用（Active-CPU）计费，而非等待 I/O 时间
前端开发者需要关心吗？
可能有人会问：这些基础设施问题不是后端的事吗？
答案是：当你在构建 SaaS AI Copilot、智能表单、或任何需要 Agent 参与的产品时，基础设施的选择直接影响用户体验和成本结构。
举个例子：假设你在开发一个"智能简历优化"产品：
- 用户上传简历（前端）
- Agent 分析简历并生成建议（需要 20-30 秒）
- 前端实时展示进度（WebSocket/SSE）
如果你的 Agent 运行在传统 serverless 上：
- ❌ 超过 15 分钟可能会超时
- ❌ 用户刷新页面，状态丢失
- ❌ LLM API 故障，整个流程从头再来
如果使用 Durable Execution：
- ✅ 即使用户关闭浏览器，Agent 继续运行
- ✅ 失败自动重试，不需要手动处理
- ✅ 前端可以通过 workflow ID 恢复进度
下一步：深入安全隔离
本文建立了一个基本认知：Agent 需要专门的基础设施。但具体到实战，最关键的问题是：
如何安全地运行 Agent 生成的代码？
下一篇文章，我们将深入 Notion Workers 的实战经验，看看 Firecracker microVM、Credential Injection、动态网络策略是如何工作的。
系列文章：
- 第 1 篇：为什么 Agent 需要独立的基础设施？（本文）
- 第 2 篇：安全是第一要务 - Sandbox 和隔离（即将发布）
- 第 3 篇：Durable Execution - Agent 的可靠性保障
- 第 4 篇：Model Orchestration - 不要被单一提供商锁定
- 第 5 篇：成本优化 - Fluid Compute 和 Active-CPU 计费
- 第 6 篇：Observability - 理解 Agent 在做什么
- 第 7 篇：多租户 Agent - Context Isolation 和 Cost Attribution
- 第 8 篇：从原型到生产 - Agent 平台的完整图景
参考资料：