AWS发布LangGraph智能体迁移至Amazon Bedrock AgentCore的分阶段指南
AWS机器学习的博客文章详细介绍了如何将现有的LangGraph客服智能体迁移到Amazon Bedrock AgentCore，分两个阶段转移运行时、工具网关和会话状态，以减少运维负担。
AI解读：AWS发布了一篇迁移指南，针对那些已用LangGraph等框架构建但尚未真正上线的智能体：在开发环境能跑，不等于在生产环境能扛住真实用户。文章把迁移拆成两个阶段：第一阶段，把智能体的运行环境搬到AgentCore的Runtime、Gateway和Memory上，让AWS托管计算资源、工具鉴权和跨会话状态，开发者的代码几乎不用改，比如一个 45 行的变更就能省去自己打补丁、管理会话隔离的工作；第二阶段才改用模型驱动规划，替换掉手写的路由逻辑。这对企业的价值在于，迁移后智能体可以跨多个实例共享会话历史，工具调用也更安全，不需要在代码里自己写鉴权。不过文章强调，身份管理、网络配置和密钥轮换仍然需要企业自己负责，而且普通用户其实不急着做任何事——这只是给正在运维自建智能体的团队看的操作说明。
AWS机器学习博客发布了一篇迁移指南，面向已经用LangGraph等框架构建了智能体、但尚未在亚马逊云上实现生产级运维的开发者。文章指出，一个在笔记本里运行的智能体不等于在生产环境能稳定运行，开发者需要承担至少十项与智能体推理无关的运维负担，例如会话隔离、跨轮次状态保持、工具调用的鉴权以及底层操作系统补丁。
迁移分两个阶段
该指南以一个LangGraph客户支持智能体为起点，它能分类消息、对愤怒客户升级处理，并使用三个工具回答其他问题，模型调用已直接使用Amazon Bedrock。迁移的第一阶段是将其部署到Amazon Bedrock AgentCore的Runtime、Gateway和Memory上，保持图结构不变；第二阶段则使用Strands Agents进行模型驱动的规划，替换手写的路由逻辑。
- 第一阶段涉及约 45 行代码改动、22 行新增支持代码，剩余 85 行直接导入保持不变。
- AgentCore Runtime默认在AWS托管基础设施上运行，并可为每个会话提供独立的微虚拟机（microVM）以实现隔离。
Gateway和Memory的配置
工具lookup_order和process_return被发布为MCP工具，通过AgentCore Gateway调用Lambda函数，鉴权委托给网关的执行角色；search_faq则保留为本地Python函数，因为该工具无需跨智能体共享或策略控制。会话状态原先保存在MemorySaver中，迁移后由AgentCore Memory支持的检查点（checkpointer）取代，键基于actor_id和会话ID，而非线程ID。
- 转换工具用两条调用完成：创建网关（选择AWS_IAM或CUSTOM_JWT授权类型）和注册目标（声明工具的JSON schema）。
- Memory使用langgraph-checkpoint-aws包中的AgentCoreMemorySaver，并在每次调用时从RunnableConfig读取actor_id和thread_id。
部署和验证
部署使用CreateAgentRuntime调用，附带一个包含源代码和依赖的zip文件，存储在Amazon S3中，无需容器或Docker；唯一的构建工具是pip。作者提醒两个常见陷阱：需要在ARM64 Linux平台上安装依赖（包括指定平台为manylinux2014_aarch64），且zip中的requirements.txt无效，必须预先捆绑所有依赖。
- 验证通过测试套件进行，确保网关调用以supportTools___lookup_order前缀和正确的参数到达，从而捕捉任何重命名或参数丢失。
- 该指南还提到可以启用Amazon CloudWatch Transaction Search来查看追踪日志，但需注意此功能可能需要额外配置。