将智能体工作负载迁移至 Amazon Bedrock AgentCore
生产环境中的智能体远不止笔记本里的原型。 当真实用户接入后，你需要处理与智能体推理无关的运维负担：会话隔离、跨轮次状态管理、工具认证、系统补丁等。本文以 LangGraph 客户支持智能体为例，展示如何分两阶段迁移至 Amazon Bedrock AgentCore，从而托管运行时、网关、内存及模型驱动的规划，显著降低运维成本。
迁移前的现实
在笔记本中运行的智能体并非生产就绪。一旦上线，你需处理十个运维负担，例如确保不同用户的会话数据隔离、跨天保持状态、为每个工具调用管理认证，以及定期修补底层操作系统。即便你的模型调用已指向 Amazon Bedrock，这并非决定性优势——真正的工作在于将整个智能体托管化。
两阶段迁移路径
阶段一：接入 AgentCore 运行时、网关与内存
保持 LangGraph 图结构不变，将智能体部署到 AgentCore 的 Runtime（通过 BedrockAgentCoreApp 和 @app.entrypoint 函数），利用 Gateway 管理 API 调用，Memory 服务处理会话状态持久化。此阶段即可获得托管的基础设施，减少对自建容器和 Web 服务器的依赖。
阶段二：采用 Strands Agents 实现模型驱动规划
将原有 LangGraph 循环重构为基于模型的规划流程，利用 Strands Agents 的 Agent(model=..., tools=...) 结构，自动决定执行步骤。此阶段进一步简化代码，使智能体更灵活地应对复杂查询。
阶段三：AgentCore 托管编排
若需更高级的自动化，可将编排逻辑交由 AgentCore harness 处理，该功能已有文档说明，无需自行构建。
生产环境的安全加固
无论停在哪个阶段，都应集成 Amazon Bedrock Guardrails，以过滤有害内容、验证响应与源文档的一致性，并阻止提示注入攻击。这些控制措施适用于任何智能体，是生产环境的必备保障。
迁移收益与考量
迁移后，你不再需要操心基础设施的补丁、扩展和状态管理，可将精力集中于智能体的核心逻辑。然而，若你的模型调用来自 OpenAI 或 Anthropic，需在阶段 0 调整构造函数以接入 Bedrock。迁移过程本身边界清晰，仅涉及四个核心构造，但运维简化带来的长期收益显著。
总之，AgentCore 为智能体生产化提供了一条平滑路径，从托管的基础设施到智能的规划能力，分阶段迁移降低了风险，让你逐步摆脱运维负担。
