基于 Lambda + S3 + DynamoDB 的 Claude Agent 实现 Serverless 中的有状态 Agent
帮一个朋友分享一下他的大作,我觉得这个 Agent+Serverless 架构在工程层面是一个很棒的实现,希望各位佬友能够指教.
省流
一种远程部署 Agent 的方法:
基于 FileSystem 持久化的无状态容器 Agent 部署架构.
实现 Serverless 部署有状态 Agent,基本无单点故障,成本 500-1000 刀 / 月降到 30 刀 / 月。
让 Agent 无痛上云而不必要单点部署!
项目源码
项目简介
为了解决部署 AI Agent 的两难问题:
- 单机部署有状态但 “不容易负载均衡”“成本高”“各个功能耦合” 问题.
- Serverless 便宜,很多即开即用的组件,不需要管理底层架构,但每次调用丢失状态 (对话历史等)。
本项目实现 Lambda + S3 + DynamoDB 来部署 Claude Agent,实现成本 30 刀 / 月的有状态 Agent,彻底解决以上问题。
这个架构打破了 "Serverless = 无状态" 的固有观念。通过在 S3 中维持会话历史,Lambda 获得了有状态 Agent 的能力,同时保持按需计费的成本优势。
状态管理不需要绑定在容器上,可以与计算完全分离。结合 DynamoDB 的映射、S3 的持久化、Lambda 的弹性计算,用更少的钱,更耦合的组件实现了更好的可靠性。
适用场景
- Telegram / 微信 / Slack Bot (本项目用 TelegramBot 做示例的,Client 还可以实现其他)
- SaaS 应用中的 AI 助手 (需要重新写 Client)
- 多租户平台
Agent 为什么难以 Serverless 化
Claude Agent SDK 需要维护对话状态,与无状态 API 完全不同:
- 每个 Agent 需要持久 shell、工作目录、完整对话树
- Lambda 环境是无状态的:每次调用都是干净环境,/tmp 会被清空
- 官方推荐四种部署模式中,Hybrid Sessions(临时容器 + 状态恢复)成本最优
项目框架 (这个只是当前我需要集成到 TG, 各位大佬如果有需要可以把 Client 改为其他客户端。欢迎 Fork 或者提 PR 来兼容更多客户端!)
Telegram User → Bot API → API Gateway → Producer Lambda → SQS Queue → Consumer Lambda
↓ ↓
Return 200 agent-server Lambda
immediately ↓
DynamoDB (Session mapping) + S3 (Session files) + Bedrock (Claude)
参考
本文永久链接
https://forum.beginner.center/t/topic/2575