将智能体工作负载迁移至 Amazon Bedrock AgentCore 的实战指南

生产环境中的智能体与实验环境中的智能体面临截然不同的挑战。当真实用户开始使用时，开发者需要处理十项核心运维负担：会话隔离、跨轮次状态持久化、工具调用鉴权、操作系统补丁、自动扩缩容、依赖更新、日志与追踪、网络配置、密钥轮换以及 Web 应用防火墙规则。这些工作与智能体的推理逻辑毫无关系，却占据了大量工程资源。Amazon Bedrock AgentCore 的设计目标正是逐项接管这些负担，让开发者专注于智能体本身的能力建设。

本文的迁移起点是一个已在 Amazon Bedrock 上运行模型调用的 LangGraph 客服智能体。该智能体对每条消息进行意图分类，对情绪激动的客户执行升级处理，对其他用户则通过三个工具查询订单状态或退货信息。智能体运行在开发者自行管理的容器中，包含 Web 服务器和进程内会话状态。迁移不会触碰推理调用本身，因此已使用 Amazon Bedrock 并不构成额外优势；若模型调用指向 OpenAI 或 Anthropic，只需修改一处构造函数即可完成适配。

第一阶段将智能体接入 AgentCore Runtime、Gateway 和 Memory，LangGraph 图结构保持完整不变。Runtime 将每个会话运行在独立的微型虚拟机上，自动处理扩缩容与会话隔离；Gateway 为工具调用提供统一鉴权，以自身执行角色调用 AWS Lambda 目标函数，并将工具以 MCP 协议格式发布；Memory 则将 MemorySaver 替换为 AgentCoreMemorySessionManager，实现跨轮次、跨进程、跨天的状态持久化。完成第一阶段后，开发者即拥有一个托管智能体，无需再维护容器、Web 服务器和检查点存储。

第二阶段将手写的条件路由逻辑替换为基于 Strands Agents 的模型驱动规划。原有的 add_conditional_edges 分支判断由模型自主决策取代，智能体定义简化为 Agent(model=..., system_prompt=..., tools=...)，工具列表直接来自 Gateway 通过 MCPClient 暴露的接口。这一阶段建立在已验证的 Runtime 和 Gateway 之上，确保每次只有一个变量发生变化。对于本身就在重写智能体的团队，也可以直接从第二阶段起步，因为 Gateway、Lambda 目标和 Memory 存储在两个阶段中通用。

在安全与可观测性方面，无论停在哪个阶段，开发者均可为智能体附加 Amazon Bedrock Guardrails，用于过滤有害内容、验证输出与源文档的一致性，以及拦截提示注入攻击。Observability 服务会自动将 Runtime 的日志、指标和追踪数据发送至 Amazon CloudWatch，无需额外配置。IAM 策略、VPC 配置、WAF 规则和密钥轮换在所有阶段始终由开发者自行负责，平台不会替代这些安全决策。Identity 服务可为智能体代表用户调用第三方 API 时管理 OAuth 令牌，但本次演示未涉及该能力。

从工程实践角度看，本次迁移的核心价值在于分阶段、可验证地转移运维职责。样本仓库按阶段组织目录结构，每个阶段均可与前一阶段进行差异对比。环境准备仅需 Python 3.12、AWS CLI 以及四个新增依赖包，测试套件无需凭证即可运行验证。建议团队按顺序推进各阶段：第一阶段只改变智能体的运行位置，第二阶段只改变规划方式，两个变量严格分离，便于问题定位与回滚决策。

要点

• 生产级智能体需承担十项运维负担，AgentCore 通过 Runtime、Gateway 和 Memory 三项服务逐步接管其中大部分，但 IAM、VPC 和密钥管理仍由开发者负责
• 迁移分两阶段进行：第一阶段保持 LangGraph 图结构不变，仅转移运行环境；第二阶段用模型驱动规划替换手写条件路由，两个变量严格分离
• 推理调用在整个迁移过程中无需改动，已使用 Amazon Bedrock 的团队可直接开始，使用其他模型提供商只需修改一处构造函数
• Amazon Bedrock Guardrails 可在任意阶段附加，提供有害内容过滤、输出一致性验证和提示注入防护，与所用框架无关
• Gateway 以 MCP 协议格式发布工具，Runtime 为每个会话分配独立微型虚拟机，Memory 实现跨进程跨天的状态持久化，三者共同消除最核心的运维痛点