亚马逊把15分钟死刑改成无限续命，AI代理开发者集体倒戈

去年有组数据让Lambda团队很尴尬：Bedrock AgentCore上线6个月，迁移过来的生产级AI代理项目增长了340%。这些不是Demo，是带着持久化内存、护栏规则和凌晨2点SLA承诺的真家伙。

作者Raj Murugan是其中之一。他在GitHub开源了自己的生产架构（rajmurugan01/bedrock-agentcore-starter），并写了6篇深度复盘。第一篇就扔了个炸弹：「没人告诉你，AI代理最难的不是模型，是模型周围那堆基础设施。」

Lambda的15分钟死刑

如果你在AWS上写过无服务代码，第一反应肯定是Lambda。工具链成熟，CDK支持完善，能缩到零成本。Bedrock简单封装——收消息、调InvokeModel、返回——Lambda完全够用。

但对话代理不是单次调用。模型要调工具、处理结果、再调工具、推理整合，复杂交互轻松跑5-10分钟。Lambda的15分钟硬上限开始悬在头顶。

更麻烦的是会话连续性。用户20分钟后回来继续聊，Lambda新开一个实例，上下文归零。你要自己搭DynamoDB存会话状态，每次调用先读再写，代码里塞满和核心业务无关的基础设施胶水。

记忆系统更是一场噩梦。用户偏好联系方式、会员等级、上月账单纠纷——这些语义记忆需要向量数据库、摘要流水线、每次调用前的检索步骤。全自建，全自己维护。

AgentCore的容器魔术

Bedrock AgentCore的定位很直白：专门伺候长运行、有状态的AI代理负载。你交一个Docker容器，它托管运行时、会话状态、记忆检索、流式响应、自动扩缩容。

架构对比像两个时代：

Lambda路径：用户消息→API Gateway→Lambda（冷启动？）→DynamoDB读会话→调Bedrock→DynamoDB写会话→返回→Lambda销毁。

AgentCore路径：用户消息→运行时（JWT校验）→你的容器（已预热）→调Bedrock→流式返回→容器保温等下一条。

关键差异在「保温」。AgentCore的容器会话持续存在，状态内存里直接取，不用来回倒腾数据库。流式响应走原生WebSocket，不是Lambda那种拼装HTTP的别扭方案。

成本账的隐藏项

Lambda按调用次数和持续时间计费，看着便宜。但复杂代理的DynamoDB读写、冷启动延迟、状态序列化开销，账单里藏得很深。

AgentCore按容器运行时长计费，透明得多。作者没给具体数字，但提了句「省下的工程时间够重构两次核心逻辑」——这对25-40岁的技术负责人来说，比单价小数点后几位更有说服力。

迁移的真实阻力

不是所有人都拥抱AgentCore。Lambda的生态惯性太强，现有CI/CD流水线、监控告警、团队技能栈全是沉没成本。作者承认自己的项目能迁，是因为从零开始，没有历史包袱。

他留了个开放问题在GitHub issue里：「如果你有一个跑了3年的Lambda代理集群，什么条件会让你下决心整体搬迁？」

评论区最高赞回复来自一个金融科技团队：「当第17次凌晨被DynamoDB节流告警叫醒的时候。」