AWS发布七层可插拔Agentic AI参考架构，基于Amazon Bedrock AgentCore
AWS机器学习博客介绍了这一参考架构的七个分层、各层职责与可替换组件，并附零售客服退款场景的示例实现。作者强调各层服务选型只是参考实现的示例，并非强制要求。
AI解读：这篇博客面向的问题是原型能跑通、但难以在生产环境承受并发流量、成本压力和安全审查。作者将这一差距归因于团队各自重复搭建路由、护栏和可观测性，并且这些能力通常在事后才补上。
七个分层依次为数据与知识、模型与推理、编排、安全与护栏、应用、可观测性、Agentic运营。各层有独立职责和稳定契约，博客明确各层列出的服务和技术属于参考实现，组织可以替换为符合自身基础设施的方案。
对读者最需要弄清的一个具体问题——拆分多个agent是否必要——博客给出的判断标准是任务复杂度：简单任务用单个agent端到端处理；跨领域复杂流程用supervisor委派专职agent。理由是工具和上下文累积会推高延迟、降低准确率，并可能让agent越出授权边界。博客称这是其设计主张，未提供量化效果数据。
示例实现是零售客服的订单状态与退款资格场景：supervisor接收退款请求后交给Order agent和Refund agent，前者从DynamoDB查交付与购买信息，后者从知识库取分层政策规则并按交付日期、当前日期和会员等级计算资格。每次调用经AgentCore Gateway做细粒度访问控制，并全程追踪。
博主还表示该框架可与第三方供应商集成，涵盖推理层的模型与托管、编排层的搜索、应用层的决策API、安全层的护栏、可观测层的追踪与监控。博客提醒，上手实现不能替代生产环境的安全加固、测试与评审。
AWS机器学习博客发布文章，介绍一套名为Pluggable Agentic AI Framework的七层可组合企业Agentic AI参考架构，运行在Amazon Bedrock AgentCore之上，用于把多agent应用从原型推进到生产规模。文章作者为Sindhura Palakodety。
博客把问题定义为原型与生产系统之间的差距：原型只证明模型能完成任务，不负责在真实流量、成本压力和安全审查下可靠运行。作者称多数agentic AI项目停滞在这一步，并归因于每个团队重复搭建自己的路由逻辑、护栏和可观测性，而且这些通常在事后追加，并非一开始就内置。
七个分层与稳定契约
该框架把多agent应用组织为七层，每层有独立职责和稳定契约：数据与知识、模型与推理、编排、安全与护栏、应用、可观测性、Agentic运营。博客明确，每层列出的服务和技术的示例属于参考实现，并非强制选择，组织可按自身基础设施和需求替换。
数据与知识层负责检索、嵌入，并以“接收查询、返回最相关信息作为上下文”的契约访问结构化与非结构化数据。博客举出的构建块包括Amazon Bedrock Knowledge Base、Vector Engine for Amazon OpenSearch Serverless、Amazon S3 Vectors和Amazon DynamoDB。
模型与推理层主张模型选择由配置驱动，不硬编码进agent或应用逻辑；简单任务用小而快的模型，需要细致推理的请求用大模型。博客还建议用真实且有代表性的业务数据做模型评测，并提到可用LiteLLM这类代理在各供应商之间提供统一接口。
编排为何主张拆分专职agent
编排层决定工作如何分配。博客的建议是：简单任务由单个agent端到端处理；复杂、跨领域的流程由supervisor把任务委派给专职agent，每个专职agent限定在特定能力和一组特定工具内。作者明确反对用一个agent包揽所有事情。
其理由是工具、指令和上下文累积会撑大上下文窗口，推高延迟并可能损害准确率；工具泛滥还可能让agent越出预期边界，导致非预期动作和安全问题。拆分职责可以让每个agent的上下文更聚焦、延迟更可预测，也便于独立测试、扩展和定义安全模型。
博客提出的做法还包括把专职agent与supervisor解耦：supervisor从集中式agent注册表发现专职agent，并通过MCP、A2A等标准化协议调用。注册表记录每个agent的工具、技能和负责人。博客举例称专职agent可用Strands Agents，编排器可用Amazon Bedrock AgentCore harness，发现与路由可用AWS Agent Registry和AgentCore Gateway。
上述拆分主张是博客作者的设计观点，文章未给出并发规模、延迟或准确率的实测数据。
安全、应用、可观测性与运营
安全与护栏层被要求从第一天起内置。博客列出prompt注入、工具滥用、记忆与数据投毒等风险，建议默认把外部内容视为不可信；对来自用户、其他agent或自动化流程的每个请求做身份认证；工具调用执行前做细粒度访问控制；发放临时、限定范围的凭证而非长期密钥。数据侧要对PHI和PII做掩码，并用防篡改审计记录关键决策、对高影响动作设置人工审批闸门和熔断。
应用层被要求保持薄，只负责呈现对话并把请求传给编排层；博客建议不要在应用层嵌入业务逻辑，还提到可在这一层边界放一个决策模型，用一次调用给请求打分，判断是否在范围内、是否需要人工或是否紧急。
可观测性层要观测所有层，除日志和指标外还要有端到端agent追踪，并采集每次请求的成本与token用量、首token时间、调用是否安全，上线前提供延迟、错误率和支出的看板。博客举例可用Amazon CloudWatch搭配OpenTelemetry和CloudWatch Omni。
Agentic运营层负责持续评估：对每个生产会话在依据性、准确性和安全性上打分，并设回归闸门，在质量下降触达客户前拦截。博客举例可用Amazon Bedrock AgentCore Evaluations和AgentCore optimization。
零售客服示例实现
框架附带一个可运行的参考实现，场景是零售客服的订单状态与退款资格。博客称选这个场景是因为它贯穿全部七层，又足够直观，便于团队按需调整。
流程是：supervisor agent接收客户的退款请求，委派给Order agent和Refund agent，二者各带限定工具集。Order agent从Amazon DynamoDB查交付与购买信息；Refund agent从知识库取分层政策规则，用交付日期、当前日期和客户会员等级计算退款资格。
据博客描述，这些调用都经AgentCore Gateway，并在工具执行前通过Policy in AgentCore实施细粒度访问控制；每次调用都经可观测层端到端追踪，计算出错时可查看具体是哪一层、哪个决策点导致。
博客还称该框架通过与第三方供应商在各层的集成来演示可插拔性，涉及推理层的模型与托管、编排层的搜索、应用层的决策API、安全层的护栏、可观测层的agent追踪与监控，以及业务价值与成本跟踪。文章结尾提醒，上手实现不替代生产环境的安全加固、测试与评审。