“你只需为代码运行的毫秒数付费”这一无服务器神话，在尝试于 AWS Lambda 上运行 AI agent 时便会破灭。实际上，最大的开支项目并非 Lambda 的计算费用，而是冷启动延迟、重试循环以及这些循环所产生的 Token 使用量。

为什么传统的无服务器图景会误导 AI agent

大多数开发者将 Lambda 函数视为纯粹的计算沙箱：保持 handler 快速运行，设置适中的内存大小，然后观察账单保持平稳。这对于简单的 HTTP 端点行之有效，但一个需要调用语言模型、评估响应并可能重试整个循环的 agent，并不能与单次 Lambda 调用一一对应。Agent 的内部工作流会使模型调用次数成倍增加，而每一次额外的调用都会增加 Token 成本，其规模可能远超计算费用。

冷启动是隐藏的价格标签

当 Lambda 容器首次配置时，必须解压部署包。由于相关的 agent 会引入大量的 Python 库，因此镜像可能会很大。剔除仅用于开发的工具（例如仅用于本地测试的浏览器自动化库）可以减小镜像体积，从而缩短解压时间。更精简的包意味着函数能更快地准备好处理请求，减少等待容器预热的时间。

第二个杠杆是初始化代码的位置。通过在模块导入时构建 agent 的图（graph），繁重的工作只需在每次容器启动时执行一次，而不是在每次请求时执行。这样，热调用（warm invocations）就可以完全跳过这些工作。权衡之处在于冷启动时间会略微延长，但回报是在容器预热后，每次请求的设置时间几乎为零。

内存兼作延迟调节旋钮

在 Lambda 上，你分配的内存量也决定了函数获得的 CPU 份额。将函数设置为 1 GB 内存可以为其分配一个完整的虚拟 CPU 核心。额外的 CPU 可以加速库的导入和 agent 图的创建，从而缩短冷启动和预热延迟。

循环成本：重试会使 Token 支出成倍增加

Agent 遵循“工作者-评估者”（worker-evaluator）循环。工作者生成响应，评估者进行检查，如果评估者标记了错误，任务就会被发回给工作者。该循环在放弃之前最多可以重复五次。这意味着单次外部请求可能会触发：

  • 最多五次对工作者模型的调用
  • 最多五次对评估者模型的调用
  • Agent 决定进行的任何次数工具调用

Lambda 账单是可预测的，因为 AWS 按执行的毫秒数计费，但 Token 账单可能会根据所需的重试次数而剧烈波动。

超时陷阱：API Gateway vs. Lambda

API Gateway 对其承载的 HTTP 请求施加了 29 秒的硬性超时限制。即使底层的 Lambda 函数配置了五分钟的执行窗口，一个五轮的 agent 循环也可能轻易超过该限制。通过使用 Lambda Function URLs 来绕过 API Gateway，可以消除 29 秒的上限，允许函数在不被中断的情况下完成其循环。

开发者应该为哪些项目做预算

教训很简单：为无服务器 AI agent 做预算，不仅仅是累加 Lambda 的运行毫秒数。你需要考虑以下因素：

  • 部署包的大小以及由此产生的冷启动延迟
  • 决定 CPU 性能进而影响导入速度的内存设置
  • 工作者-评估者循环中预期的重试次数，这直接驱动了 Token 使用量
  • 前端选择（API Gateway vs. Function URL）以避免过早超时

忽略其中任何一个变量，都可能导致你的实际账单与预期完全不符。