从 LangGraph POC 到 AgentCore：企业 Agent Runtime 迁移不该同时重写大脑和身体
企业 Agent 最危险的迁移方式，是把模型、工作流、状态、工具、身份和部署环境一次性全部替换。新平台上线后效果变差，团队无法判断是模型、prompt、规划器、网络还是权限造成；发生重复动作时，也找不到可回滚的单一变量。
AWS 在 9 月 3 日发布的 AgentCore 迁移指南提供了一个很值得借鉴的顺序：先把已有 LangGraph Agent 原样迁到 Runtime、Gateway 和 Memory，保持图结构不变；验证运行层后，再选择是否用 Strands 的模型驱动规划替换手写分支；更完整的 Harness 迁移放到后续阶段。
先拆清楚“谁负责什么”
迁移顺序是先替换承载执行的“身体”，再决定是否替换负责规划的“大脑”，以缩小故障定位范围。
Runtime 决定 Agent 在哪里运行、如何隔离会话、扩缩容和采集遥测；Gateway 决定工具怎样暴露、认证和执行；Memory 保存跨进程和跨天的状态；Harness 才决定下一步做什么。把 Runtime 换掉，并不要求把确定性的业务分支改成模型决策。
这条边界尤其重要。比如“愤怒客户必须升级人工”是合规规则，就应保留确定性路由；“从三个知识源选择更可能相关的一个”可以交给模型。迁移平台不应成为偷偷改变业务语义的借口。
阶段 0：建立可比较基线
迁移前至少固定一组真实任务和故障注入：正常查询、缺数据、工具超时、重复回调、凭证过期、人工升级、越权请求。记录成功率、P95 延迟、每个完成任务的模型成本、工具调用次数和人工接管率。
同时给每个任务生成贯穿全链路的 run_id，每个写动作生成 call_id。没有这些标识，迁移后的 CloudWatch trace 与迁移前日志无法比较。
阶段 1：只迁运行负担
AWS 的示例把 LangGraph 入口包装成 AgentCore Runtime 应用，把工具发布为 Gateway 后的 MCP 能力，并将 checkpoint 绑定 actor_id 与 session。实际企业落地还要补四项：
actor_id必须来自可信身份，不可直接相信请求参数；- Gateway 的执行角色按工具拆分，查询订单与退款不能共用权限；
- Memory 中的会话状态与业务系统事实分开，订单状态仍以业务库为准；
- 入口前保留 WAF、速率限制和租户隔离，托管 Runtime 不会替你设计网络边界。
这一阶段成功的标志不是“页面能聊天”，而是同一套测试在旧环境和新 Runtime 上产生等价业务结果，并且故障恢复不会重复副作用。
阶段 2：再评估规划器
模型驱动规划能减少脆弱的条件分支，但会引入非确定性。迁移时应该同时保留旧图作为 shadow evaluator：新规划器生成计划，旧规则检查必须满足的节点、禁止动作和升级条件。只有在真实任务集上达到门槛，才让新规划器获得写权限。
建议按工具风险逐步开放：先读知识库，再查业务状态，然后写低风险草稿，最后才是退款、权限和生产配置。每一级都有独立开关，遇到问题可以退回旧图，不必回滚整个平台。
平台托管后仍属于你的责任
托管 Runtime 会接手 OS 补丁、会话隔离和扩缩容，但 IAM 策略、VPC、WAF、密钥轮换、数据分类和业务补偿仍属于应用团队。AWS 指南也明确指出，Identity、Policy、Observability 等能力是逐项挂接的，并不会因为把容器移入 Runtime 就自动完成。
最终验收应回答：状态跨进程与跨天是否可恢复；工具令牌是否短时且按用户委派；Gateway 是否记录策略决定；模型切换是否不改变业务不变量；旧版本是否能恢复未完成任务；回滚时新旧 Memory 如何兼容。
企业 Agent 迁移的正确姿势，是一次只移动一个责任边界。先把“身体”放到可靠 Runtime，再决定是否更换“脑中的规划方式”，才能把平台升级从豪赌变成可观测、可回退的工程过程。