先把层名对准：官方原文与三份转述的差异
2026 年 11 月 9 日，Sindhura Palakodety、Mythili Annamalai Sekar、Sujatha Kuppuraju、Madhu Samhitha Vangara 四人在 AWS 机器学习博客发表《Pluggable Agentic AI Framework: A seven-layer composable enterprise agentic AI reference architecture on Amazon Bedrock AgentCore》，归类为 Amazon Bedrock AgentCore、Expert (400) 级别的 Thought Leadership（来源：AWS 官方博客原文，含作者行与分类行）。官方在 Composable architecture 一节写明框架按七层组织，每层职责不同且各有一份稳定契约，并强调文中列出的服务与技术属于参考实现而非强制选项。
把官方原文的加粗层名按顺序抄下来，依次是：Data and Knowledge、Model and Inference、Orchestration、Security and Guardrails、Application、Observability、Agentic Operations（来源：AWS 官方博客 Composable architecture 小节逐段直读）。这里先记下一个容易被忽略的顺序细节：Application 排在 Observability 之前，而 Agentic Operations 收尾。
同日及次日出现的多份转述并不一致。ainewstodays 与 kblip 一系把七层写成 Data and Knowledge、Model and Inference、Orchestration、Integration and Tools、Security and Governance、Observability and Monitoring、Application and Interface；dnainsider 与 explainX 则与官方顺序一致，列出 data and knowledge、model and inference、orchestration、security and guardrails、application、observability、agentic operations（来源：四篇转述全文对照）。
| 序位 | AWS 官方原文层名 | 其中一份转述的写法 | 差异性质 |
|---|---|---|---|
| 1 | Data and Knowledge | Data and Knowledge | 一致 |
| 2 | Model and Inference | Model and Inference | 一致 |
| 3 | Orchestration | Orchestration | 一致 |
| 4 | Security and Guardrails | Integration and Tools | 层名与职责均不同；官方把 Gateway 放在编排层描述内 |
| 5 | Application | Security and Governance | 官方用 Guardrails 而非 Governance，且序位不同 |
| 6 | Observability | Observability and Monitoring | 增字，职责范围相同 |
| 7 | Agentic Operations | Application and Interface | 转述漏掉运营层，并把 Application 挪到末位 |
按本文逐项点数，七层里层名与序位一致的是三层，约 42.9%；出现层名或序位变化的是四层，约 57.1%（原创结构折算，分母为官方七层，不含任何性能含义）。这个比例只说明转述不能当规范读，不指向框架本身的优劣。尤其第四层：官方原文并没有名为 Integration and Tools 的独立层，AgentCore Gateway 是在 Orchestration 段落里作为集中发现与路由组件被点名的；把 Gateway 抬成一层，会让读者误以为工具调用只在这一层受控，而官方把细粒度访问控制明确写在 Security and Guardrails 与 Policy in AgentCore 名下。
官方对框架的定义句是「按七层组织，每层各有独立职责与一份稳定契约」；转述容易把这句话读成「七个可采购的产品槽位」。一旦按槽位理解，就会去数每层选了哪个服务，而漏掉真正的设计对象——层与层之间的接口约定。本文后续所有层名与顺序均以 AWS 官方博客为准，转述差异只作为核对记录并列保留。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是七层契约是否附有形式化接口定义、层间调用是否规定超时与重试语义，以及转述差异源自编辑改写还是参考了不同版本的配图。
稳定契约约束的是接口，不是产品选型
官方对 Data and Knowledge 层给出的契约句式较完整：接受一个查询，返回最相关的信息作为智能体的上下文（来源：AWS 官方博客 Data and Knowledge 段）。这句话把该层的职责限定为检索而非生成，因此 Bedrock Knowledge Base、OpenSearch Serverless 向量引擎、S3 Vectors、DynamoDB 都是可替换的实现，替换为别的检索后端时，编排层只需继续按同一查询—返回约定调用。
Model and Inference 层同理：官方要求模型选择由配置驱动而非硬写进智能体逻辑，并用 LiteLLM 这类代理提供跨供应商的一致请求—响应契约，使模型切换不必重写应用代码。Orchestration 层则把契约落在发现与调用方式上：supervisor 通过集中式 agent registry 发现 specialist，经 MCP 或 A2A 调用，specialist 严格限定在被授予的工具范围内，即官方所称 bounded autonomy（来源：AWS 官方博客 Orchestration 段）。
| 层 | 官方写明的契约要点 | 点名的参考实现 | 替换时不应改动的部分 |
|---|---|---|---|
| Data and Knowledge | 接受查询、返回最相关信息作为上下文 | Bedrock Knowledge Base、OpenSearch Serverless、S3 Vectors、DynamoDB | 上游编排层的查询—返回接口 |
| Model and Inference | 配置驱动选模型，统一请求—响应契约 | LiteLLM 代理、大小模型分级路由 | 编排层对推理接口的调用代码 |
| Orchestration | single agent 处理简单流程；跨域用 supervisor 委派 specialist | Strands Agents、AgentCore harness、Agent Registry、AgentCore Gateway、MCP、A2A | 应用层的请求下发方式 |
| Security and Guardrails | 所有外部内容视为不可信，逐次鉴权、工具执行前做访问控制 | AgentCore Identity、Policy in AgentCore、Bedrock Guardrails | 工具执行前的鉴权次序 |
| Application | 薄层，只呈现会话并把请求下传；决策模型返回概率而非自由文本 | 未点名具体产品 | 后端编排接口 |
| Observability | 端到端 trace 加每请求成本、token、首 token 时延 | CloudWatch、OpenTelemetry、CloudWatch Omni | 指标采集点与上报时机 |
| Agentic Operations | 对生产会话持续评分，发布前设回归门禁 | AgentCore Evaluations、AgentCore optimization | 门禁触发条件与基线分 |
按本文对原文的逐项点数，七层中被明确点名参考实现或组件的共有六层，只有 Application 层未列出具体服务，只给了「薄层加决策模型」的设计建议（原创结构折算，分母为官方七层）。这不是遗漏评价，而是提示：应用层恰恰是官方最不希望绑定产品的一层，业务逻辑写进 UI 会反过来牵动后端。
官方在 Why pluggability matters 一节把可替换面逐一列出：推理层的模型与托管供应商、编排层的搜索能力、应用层的决策 API、安全层的护栏、可观测层的追踪与监控方案，共五类第三方接入点（来源：AWS 官方博客同节原文）。按七层分母折算约 71.4%（原创换算）。需要说清边界：Data and Knowledge 与 Agentic Operations 未在该段被点名，不等于不可替换，只说明官方没有在这两处举第三方例子。
把 LiteLLM 换成别的代理、把 CloudWatch 换成别的追踪后端，属于实现层替换；把「工具执行前必须完成细粒度鉴权」改掉，属于契约层改动。前者是框架宣称支持的能力，后者会破坏框架本身。两者都叫「换组件」，但只有前者落在稳定契约覆盖范围内。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是契约的版本管理方式、跨层 schema 的兼容性承诺，以及第三方组件替换后由谁提供一致性验证套件。
三层是横切的，不是流水线上的连续三站
七层按顺序列出，很容易被读成一次请求按七层顺序逐层流过。但把官方对后三层的职责描述摊开看，Security and Guardrails、Observability、Agentic Operations 的作用范围都是全层：安全层要求每次调用（无论来自用户、智能体还是自动化流程）都经 AgentCore Identity 鉴权，并在工具执行前判定权限；可观测层要求从上线首日就采集端到端 trace、每请求成本与 token、首 token 时延；运营层要求对每一次生产会话评分，并在下次发布前跑回归门禁（来源：AWS 官方博客对应三段）。
换句话说，这三层不与任何单一调用阶段绑定：鉴权发生在每次工具调用之前，trace 贯穿 supervisor、specialist 与 Gateway 的每一跳，回归门禁发生在发布之前而不是请求之中。把它们画成流水线末端的三个格子，会得出两个错误推论——一是认为可以「先上线再补安全与监控」，二是认为运营层只管上线之后的事。官方原文恰恰相反：安全与可观测都要 built in from day one，且结论段再次强调不能在系统建成后追加。
| 层 | 触发时机 | 覆盖范围 | 若按流水线误读会怎样 |
|---|---|---|---|
| Security and Guardrails | 每次请求鉴权、每次工具执行前授权、高影响动作走人工审批 | 所有层的调用方与工具出口 | 误以为只在入口做一次校验 |
| Observability | 上线首日起持续采集 | supervisor 委派、工具调用、策略判定的全链路 trace | 误以为日志够用，trace 可后补 |
| Agentic Operations | 生产会话持续评分、每次发布前回归门禁 | 全部历史基线分与新版表现 | 误以为上线即完成，无需版本间对照 |
| Application | 请求进入时 | 仅呈现与转发 | 误把业务规则写进薄层 |
| Orchestration | 请求处理中 | 任务分解与 specialist 调度 | 与横切层混在同一调用序位 |
这里能给出一个可操作的判定法：如果某层的动作无法归属到单次请求的某个固定时刻，它多半是横切层，应当按策略与门禁来配置，而不是按调用顺序来排期。按这个判据，七层里横切的是三层，约 42.9%；处在请求链路上的是四层，约 57.1%（原创结构折算，分母为官方七层，属于分类计数而非性能评估）。
官方配图按七层自下而上排列，表达的是依赖与职责分层，不是一次退款请求要依次穿过七个模块。本站此前解构的四层上下文工程（R-TECH-60）处理的是进入窗口的 token 量与复核分工，属于运行期资源账；这里的横切层处理的是权限、记录与发布门禁，属于治理账。两张账不能叠成一条调用链。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是横切层与请求链路之间的失败传播规则、人工审批超时如何处理，以及回归门禁未通过时的回滚路径。
零售退款样例：一次请求穿过的真实路径
官方给出的参考实现是零售客服场景，覆盖订单状态与退款资格。流程是：supervisor 收到退款请求，委派给 Order agent 与 Refund agent 两个 specialist；Order agent 从 DynamoDB 查交付与购买明细，Refund agent 从知识库取分层政策规则，按交付日期、当前日期与会员等级计算资格；每一次工具调用都经 AgentCore Gateway，由 Policy in AgentCore 在执行前做细粒度访问控制，并被可观测层端到端追踪，以便算错时能定位到具体层与决策点（来源：AWS 官方博客 Reference implementation 小节）。
| 环节 | 参与组件 | 对应层 | 该跳留下的记录 |
|---|---|---|---|
| 请求进入 | 聊天界面或 API 薄层、可选决策模型 | Application | 是否在范围内、是否需要人工、是否紧急的概率分 |
| 任务分解 | supervisor 经 registry 发现两个 specialist | Orchestration | 委派关系与所选工具集 |
| 订单事实查询 | Order agent 经 Gateway 读 DynamoDB | Orchestration 与 Data and Knowledge | 工具调用授权结果与返回证据 |
| 政策规则查询 | Refund agent 经 Gateway 读知识库 | Orchestration 与 Data and Knowledge | 规则版本与检索命中 |
| 资格计算与汇总 | supervisor 校验两个 specialist 的结构化结论 | Orchestration | 计算输入与最终判定 |
| 全程 | AgentCore Identity、Policy、Guardrails、OpenTelemetry trace | Security 与 Observability 横切 | 逐步鉴权、token 与成本、时延 |
| 发布之前 | AgentCore Evaluations 回归门禁 | Agentic Operations 横切 | 与基线分的差值 |
这个样例里值得单独拎出的是权限边界的形状：两个 specialist 各自只拿到被授予的工具，且官方明确二者都不直接触达付款系统；高影响动作要走人工审批门。按本文点数，样例涉及 1 个 supervisor、2 个 specialist、1 个承载全部工具调用的 Gateway、1 条贯穿全链路的 trace，比例约为 3 比 1 比 1（原创结构折算，仅描述组件数量关系，不代表并发能力或吞吐读数）。
样例仓库 aws-samples/sample-pluggable-agentic-ai-framework 的 README 把这些部件映射到具体服务：AgentCore Harness 作编排器、Registry 作发现、Gateway 提供 MCP 工具连接 Lambda 与知识库、Memory 管长短程状态；同时明确标注这是教学用示例代码，投入客户流量前仍需安全审查、IAM 加固、监控与错误处理。AWS 在博客结论段也写明，动手实现不能替代生产环境的安全加固、测试与评审（来源：explainX 对样例仓库 README 的整理与 AWS 官方博客结论段）。
官方说「每一次调用都经 Gateway 并全程被追踪」，但并未说 supervisor 如何校验两个 specialist 返回的结构化结论，也未说明两者结论冲突时的裁决规则。本文把这一步记为「待澄清的编排逻辑」，不替官方补写规则。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是样例的并发请求数、单请求成本、退款规则被绕过时的处置，以及回归门禁在样例仓库里的具体实现程度。
可插拔的代价：回归责任回到自己团队
官方把可插拔的价值说得很清楚：稳定契约让底层技术可换而不必重设计其余各层，企业可保留已有的可观测、安全与推理工具，按需补齐缺口并渐进采用新能力，避免每项技术决策都来自同一供应商（来源：AWS 官方博客 Why pluggability matters 与 Conclusion）。这是架构先行而非技术驱动的取向，也是框架对企业既有投资的保护。
代价同样写在原文与配套材料里。官方明确框架是参考架构而非托管产品 SKU，服务与技术只是参考实现，团队仍要自行决定租户模型、数据驻留与成本上限；第三方集成只是示例，AWS 不为其合规适用性背书。explainX 的整理进一步点出：可插拔会转移责任——能快速更换 LiteLLM 路由或可观测供应商之后，跨这些替换的回归测试由团队自己承担，七层给出的是插入点，并不取消红队与负载测试的必要（来源：explainX 的 Limits 小节）。
| 可替换面 | 官方举例 | 替换后需自证的项 | 官方是否给出量化验收线 |
|---|---|---|---|
| 推理层模型与托管 | LiteLLM 代理跨供应商统一接口 | 同一业务语料上的质量、时延与成本对照 | 未给阈值，只要求用真实业务数据做充分评测 |
| 编排层搜索能力 | 第三方搜索接入 | 检索命中与委派结果的一致性 | 未单列 |
| 应用层决策 API | 快速便宜的分类器返回概率 | 范围判定与升级阈值的误判率 | 未单列 |
| 安全层护栏 | 第三方 guardrails | 注入、工具滥用、记忆投毒的拦截回归 | 未单列 |
| 可观测层追踪 | 第三方 tracing 与监控 | trace 完整性与指标口径连续性 | 未单列 |
把五类插入点与官方列的三项自留决策（租户模型、数据驻留、成本上限）并列看，会发现一个结构性事实：灵活性增加的是组合数，不是保障。五处各换一次，理论上就产生五种需要单独回归的替换组合；若多处同时更换，组合数继续上升。这里不做具体组合数乘法，因为官方未声明各插入点相互独立，硬算会引入不存在的假设（原创口径说明）。
优势：契约隔离让模型、检索、追踪可分别演进，降低单一供应商绑定，保留既有工具投资。短板：官方未给跨替换的回归基线、质量阈值或成本上限的具体数值；样例代码明确不适配生产；回归门禁在框架中被点名，explainX 指出其在零售样例里并未完整实现。把「可插拔」读成「换完即用」是对这份材料最常见的误读。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是回归门禁的评分维度权重、基线分如何跨模型版本迁移，以及第三方替换后合规责任的划分方式。
与本站已解构的四套分层放在一张对照里
本站此前解构过多套同样叫「分层」的架构，把它们与本篇并排，能看清各自改的是哪一个对象。R-TECH-60 的四层上下文工程处理进入窗口的 token 量与独立验证；R-TECH-22 的 Google AX 是面向任务调度的声明式控制平面；R-TECH-24 的 Strands harness 是单智能体执行循环；R-TECH-61 的 HEELO 把使用能力绑进资源本身，经 MCP server 暴露给外部智能体。本篇七层处理的是企业生产系统的职责与契约边界。
| 架构 | 改动对象 | 层的性质 | 与七层框架能否叠加 |
|---|---|---|---|
| AWS 七层可插拔框架 | 企业系统的职责划分与层间契约 | 四层在请求链路上、三层横切 | 作为本篇对象 |
| R-TECH-60 四层上下文工程 | 进入上下文窗口的 token 与复核分工 | 运行期资源账 | 可落在 Data and Knowledge 与 Orchestration 内部，不新增层 |
| R-TECH-22 Google AX | 大规模智能体任务的调度控制面 | 控制平面 | 与 Orchestration 层职责邻近，属不同抽象层级，不宜简单相加 |
| R-TECH-24 Strands harness | 单智能体的执行循环与工具挂载 | 执行程序 | 可作 specialist 的内部实现，官方在本篇也点名 Strands Agents |
| R-TECH-61 HEELO 原语库 | 资源单元自带的可用能力 | 资源本身 | 接入位置不同，经 MCP 暴露；与七层不构成同一维度的层数比较 |
因此「层数」在这几套架构之间不是可比指标：四层、七层、三件套说的分别是资源账、治理账与执行账。本文给出的横切层计数与插入点占比，只在本篇七层内部成立，不能与别篇的层数相减或求倍数（原创口径辨析）。这也是读架构材料时的一条通用约束：先锁定分母属于哪套架构，再谈数字关系。
把时间线也摆上：官方博客 11 月 9 日发布；explainX 在 11 月 10 日补充更新，提到 Trovata 资金管理智能体在相同技术栈上以 RBAC 与定时智能体运行于生产财务场景；dnainsider 则回带一条 10 月 23 日的信息，称 Bayer Crop Science 的 Agentic Decision Engine 在 Bedrock AgentCore 上有 22 个 specialist 智能体处于生产运行（来源：三篇转述全文）。这三条都是第三方或关联材料的时间标注，不是七层框架本身的发布节奏或效果读数，本文按出处并列保留，不与架构层数合并。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未公开的是上述生产案例是否完整采用七层契约、22 个 specialist 的实测并发与成本，以及 Trovata 案例的回归门禁配置。
六组原创折算与它们各自的分母
以下六组数字均由本文依据官方原文与转述点数推算，原文未直接给出。每组标明分母与边界，避免把结构计数读成性能结论。
| 折算 | 依据 | 结果 | 分母与边界 |
|---|---|---|---|
| 层名一致率 | 七层里与官方层名及序位一致的三层 | 3 ÷ 7 ≈ 42.9% | 分母为官方七层；只描述转述差异，不评价框架 |
| 层名或序位变化率 | 同一份转述里四层出现改写或挪位 | 4 ÷ 7 ≈ 57.1% | 与上一组互补，合计 100%，不可与别篇混用 |
| 第三方插入点占比 | 官方点名五类可替换接入面 | 5 ÷ 7 ≈ 71.4% | 分母为七层；未被点名不等于不可替换 |
| 横切层占比 | 安全、可观测、运营三层 | 3 ÷ 7 ≈ 42.9% | 按「是否绑定单次请求固定时刻」判定 |
| 请求链路层占比 | 数据、推理、编排、应用四层 | 4 ÷ 7 ≈ 57.1% | 与上一组互补，同分母 |
| 零售样例组件比 | 1 supervisor、2 specialist、1 Gateway、1 trace | 3 比 1 比 1 | 组件数量关系，非吞吐或并发读数 |
六组里前五组都是同一分母下的结构计数，彼此可并列但不可相乘；第六组换了维度，只能单独读。特别要防止把 71.4% 与 42.9% 相加得出「覆盖 114% 的层」这类合成值——两组统计的是不同属性，前者数的是被点名的第三方接入面，后者数的是横切层，存在重叠（原创口径辨析）。
官方博客是参考架构说明，未报告并发请求数、单请求成本、延迟分位数、故障率或回归门禁阈值；样例仓库也标注为教学代码。因此本文所有量化都是对文本结构的点数，不是对系统表现的测量。凡涉及运行效果的判断，一律留到可证伪边界一节作为待验证项。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是七层契约是否存在正式规范文档、是否有跨版本的兼容性测试套件，以及参考实现在生产流量下的实测读数。
可证伪边界与未披露项
以下几处应保留怀疑，尤其是把这份框架当作选型依据或迁移清单时：
- 参考架构而非产品：官方明确服务与技术只是参考实现，团队仍需自定租户模型、数据驻留与成本上限；把七层当成可采购的七个 SKU 会偏离原意。
- 无运行量化：全文未给并发、时延、单请求成本、故障率或回归门禁阈值，本文的结构折算不能替代性能测量。
- 转述不一致：至少一份转述改写了第四层层名、漏列 Agentic Operations 并挪动 Application 序位，另有转述与官方一致；引用二手清单存在引入错误层名的风险。
- 样例不适配生产：样例仓库 README 自述为教学代码，需安全审查、IAM 加固、监控与错误处理；官方结论段同样写明不能替代生产加固与评审。
- 回归门禁完成度：框架点名 Agentic Operations 层要用 Evaluations 设门禁，但配套整理指出零售样例未完整实现该门禁，落地时需自行补齐。
- 责任转移未被量化：可插拔把跨替换的回归测试交给团队，官方未给回归用例规模、基线分维护成本或替换频率建议。
一条可证伪的检验路径是：保持任务集、模型与工具不变，只替换推理层的模型托管供应商，若编排层、应用层与可观测层代码无需改动且回归门禁分数在自设阈值内，则稳定契约在该替换面上成立；若必须改动编排逻辑才能跑通，说明契约未真正隔离该面。同理可逐层检验其余四类插入点。官方目前未给出这组替换实验的结果，本文把它列为待验证项而非结论。
另一个可核对点是层名本身：若 AWS 后续发布形式化的七层规范文档或更新配图，本文记录的转述差异应按新原文重校，而不是继续沿用任何二手清单。
目前官方及行业暂未披露更多细节，后续将持续跟进迭代动态。尚未说明的是契约规范文档、跨层失败传播规则、人工审批超时语义、回归门禁权重与生产环境实测读数。