北京
一个在笔记本里跑通的智能体，和真正上线的智能体，是两回事。真实用户涌入后，你要操心的事情跟智能体的推理能力毫无关系——隔离不同用户的会话、跨轮次甚至跨天保持状态、给每个工具调用做鉴权、给底层操作系统打补丁。这还只是十项运维负担里的四项。
亚马逊云科技最新发布的这篇技术文章，把从开发环境迁移到生产环境的完整路径拆成了三个阶段。起点是一个你已经拥有的LangGraph客服智能体：它能分类每条消息、对愤怒客户升级处理、用三个工具回答其余问题，模型调用已经跑在Amazon Bedrock上。但文章指出，推理是迁移中唯一不需要改动的一环——所以"已经在用Bedrock"并不是你想象中那么大的优势。
两个阶段，一次迁移
整个迁移分两步走。第一阶段把智能体迁到Amazon Bedrock AgentCore的Runtime、Gateway和Memory上，图结构保持不变。第二阶段把循环重建成模型驱动的规划，交给Strands Agents。停在第一阶段，你就拥有了一个托管智能体，工具和状态都由平台管理。第三阶段则是把循环交给AgentCore的harness——这是AgentCore自带的能力，文档里已有说明，不需要自己构建。
迁移在代码层面是有限的，只涉及四个结构。但你要运维的东西远不止这些。LangGraph里的build_graph()加上你运行的容器和Web服务器，对应的是AgentCore的Runtime——通过BedrockAgentCoreApp和@app.entrypoint函数，每个会话跑在一个独立的微虚拟机上。工具函数从ToolNode(tools)和llm.bind_tools(tools)变成从MCPClient.list_tools_sync()获取，再传给Agent，通过Gateway发布为MCP工具。状态管理从MemorySaver()换成AgentCoreMemorySessionManager，按actor_id和会话做键控。
生产环境的安全护栏
智能体进入生产环境后，还需要加上Amazon Bedrock Guardrails：过滤有害内容、对照源文档验证grounding、拦截提示注入攻击。这些控制适用于任何智能体，无论你停在哪个阶段。文章里那张对照表最后一行写得很直白：LangGraph里的条件边（add_conditional_edges）在AgentCore里没有直接对应物——要么用模型驱动的规划替代分支逻辑，要么保留原图让Runtime托管，两者都不需要额外构建。
换句话说，迁移的核心不是重写智能体的推理逻辑，而是把运维负担从自己肩上卸下来。容器、Web服务器、会话状态——这些原本在你进程里的东西，交给托管服务。你的智能体还是那个智能体，但你不必再半夜爬起来打补丁了。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
