2026 年 11 月 9 日，AWS 在官方机器学习博客发布 7 层可插拔智能体参考架构，由 4 位解决方案架构师署名。开篇列出企业把智能体推向生产时集中冒出的问题，上千并发请求怎么安全接住、真实流量下会不会静默失效、上线后还能不能证明它仍符合测试期通过的质量标准。AWS 的判断是多数项目卡在原型与生产之间，原因很少出在模型，而是每支团队把路由、护栏与可观测性各写一遍，且都是事后补。
7 层依次是数据与知识、模型与推理、编排、安全与护栏、应用、可观测性、智能体运营，层间用稳定契约隔开。官方把列出的服务说成参考实现示例而非必选项，数据层举了 Bedrock Knowledge Base、S3 Vectors 与 DynamoDB，模型层建议用 LiteLLM 代理让换供应商不必重写逻辑，编排层建议跨域任务由主管分派给工具范围受限的专才，通过中心注册表按 MCP 与 A2A 协议发现它们。
配套零售客服参考实现覆盖订单状态与退款资格。主管智能体接到退款请求后分派给订单与退款 2 个专才，前者从 DynamoDB 查配送与购买明细，后者从知识库取分层政策规则；每次工具调用经 AgentCore Gateway 做访问控制并被端到端追踪，算错时可定位到具体层与决策点。AWS 在结论里写清这是设计指南而非客户部署公告，示例仓库不能替代生产安全加固、测试与评审。
把可插拔写成架构主线，等于把避免技术锁定放进分层契约，而不是留在采购条款里。官方点名在推理、编排、安全与观测各层接入第三方供应商，不要求整套栈出自同一家；这与 1560 号的四智能体迁移模式、1418 号的 Runtime V2 改动不是同一件事，那两条讲产品能力，这条给分层方法。
博客未给出参考实现的并发量、时延与每请求成本，也没有第三方部署的效果数据；文中提及的 10 月 23 日拜耳作物科学 22 个专才智能体产线运行属另一条公告，不能算作这套架构的验证结果。示例仓库地址、可用区域与企业迁移成本同样没有披露。