AWS发布七层可插拔智能体架构，贯通模型路由到生产治理

摘要：AWS发布可插拔智能体AI参考架构，以数据与知识、模型推理、编排、安全护栏、应用、可观测性和智能体运维七层稳定契约，覆盖企业智能体从原型到生产的关键链路。架构支持通过统一接口替换模型、工具和监控组件，并以监督者—专业智能体模式构建零售客服示例。核心价值在于把身份认证、最小权限、审计、持续评测与成本治理前置，而非依赖单一模型或云厂商栈；实际效果仍取决于业务数据评测、权限边界和规模化运维能力。

---

AWS 发布了一套面向生产环境的七层可插拔智能体 AI 参考架构，试图解决企业智能体从“能演示”走向“可规模化运营”时的路由、权限、审计、成本和可靠性问题。

七层架构如何拆分职责

整个框架由七层组成，每层通过相对稳定的接口向上层提供能力：

1. 数据与知识层：负责检索、Embedding，以及结构化和非结构化数据访问。参考实现可接入 Amazon Bedrock Knowledge Bases、OpenSearch Serverless Vector Engine、S3 Vectors 和 DynamoDB。
2. 模型与推理层：通过统一请求与响应契约隔离模型托管环境和厂商 API，并按任务复杂度路由至不同尺寸的模型。LiteLLM 可用于提供跨提供商接口。
3. 编排层：决定工作如何分配。简单任务使用单智能体，跨领域任务则由监督者委派给专业智能体；专业智能体通过 MCP 或 A2A 等协议暴露能力，并登记在中央智能体注册表中。
4. 安全与护栏层：处理身份认证、细粒度授权、临时凭据、PII/PHI 脱敏、不可抵赖审计、人工审批和熔断机制。
5. 应用层：只负责呈现对话和转发请求，不承载复杂业务逻辑；可使用轻量决策模型判断请求是否在范围内、是否紧急或是否需要人工介入。
6. 可观测性层：为每次请求关联端到端 Trace、Token 与费用、首 Token 延迟、错误率、安全事件及模型调用信息。
7. 智能体运维层：持续评估生产会话的准确性、忠实性和安全性，并通过回归门禁阻止模型、提示词、工具或编排变更造成质量退化。

核心机制：把模型选择变成配置问题

该框架并未把模型提供商、向量数据库或监控产品写死在应用代码中，而是将它们置于稳定契约之后。这一设计类似微服务架构中的依赖反转：上层依赖业务级接口，而不是依赖某个 SDK 的具体类型。

模型路由尤其重要。简单任务不必调用参数更大的模型，复杂推理才进入高能力模型。工程上可以定义任务分类、上下文长度、风险等级和延迟预算，再由路由器选择模型。此举能够降低平均推理成本，但收益取决于路由准确率：误把复杂请求交给小模型会降低完成率，误把简单请求交给大模型则浪费 Token 和 GPU 时间。

AWS给出的参考方案还强调能力评估必须使用真实且有代表性的业务数据。没有固定数据集和回归阈值，“模型可替换”很容易退化为难以量化的供应商切换。

编排机制：监督者与专业智能体

一个处理所有任务的巨型智能体会持续扩张上下文、工具数量和权限集合，带来三类问题：

• 上下文变长后，推理延迟和缓存开销上升；
• 工具越多，误调用与越权概率越高；
• 单体智能体难以独立测试、扩缩容和定义安全边界。

AWS建议将任务拆为专业智能体，例如订单智能体只查询 DynamoDB，退款智能体只检索政策并计算资格。监督者根据中央注册表发现专业智能体并通过标准协议调用它们。注册表同时记录工具、技能和责任人，使权限治理、资产复用及责任追踪不再依赖散落代码。

不过，引入监督者并非无条件更优。每次委派都会增加一次或多次模型调用、网络往返和协议转换开销。若主管模型判断错误，原本可直接完成的请求会被路由到错误专家；系统还会出现部分失败、重试和状态同步问题。生产实现必须为委派深度、循环次数、超时和幂等性设置硬约束。

安全边界：从“调用前检查”转向全程授权

框架把安全控制放在执行路径内，而不是仅依赖输入输出过滤。每个用户请求、智能体间请求和工作流调用都需要认证；每次工具执行前再根据身份、资源和策略检查是否放行。

关键做法包括：

• 对所有外部内容默认视为不可信；
• 使用临时、限定作用域的凭据，而非持久密钥；
• 在请求、工具输入输出和记忆写入前对 PHI、PII 进行脱敏；
• 将高影响操作送入人工审批；
• 记录不可篡改的审计轨迹；
• 通过熔断器阻断异常行为扩大。

这比单纯依赖提示词约束更可靠，因为策略执行发生在模型之外。不过，身份系统并不会自动消除间接提示注入：如果恶意网页内容诱导智能体调用一个权限合法但业务语义危险的工具，最终授权检查仍可能放行。因此，工具参数验证、用途约束、业务不变量和风险分级仍需叠加使用。

零售客服参考实现

AWS以零售客服场景展示了完整链路。监督者接收退款请求后，将任务委派给订单智能体和退款智能体：

• 订单智能体从 DynamoDB 获取配送及购买信息；
• 退款智能体从知识库读取分层退款规则，并结合配送日期、当前日期和客户会员等级判断资格；
• 所有工具调用均经过 AgentCore Gateway，并由 Policy in AgentCore 执行细粒度授权；
• 每次调用通过可观测性层形成端到端 Trace，以便定位错误来自检索、日期计算、政策解释还是授权环节。

示例说明“专家分工”可减少上下文污染，但退款资格属于高业务风险逻辑时，确定性规则应优先负责金额、期限和资格判断，让模型承担意图识别与政策检索，避免纯概率推理直接决定资金操作。

工程权衡与评测边界

该框架的主要收益不是提升某个模型基准分数，而是控制生产系统的耦合度和故障半径。其代价同样明显：七层会增加网络延迟、组件数量、调试难度和云资源费用；中央注册表、网关、身份、Trace 和评测系统也会形成新的关键依赖。

框架没有给出统一的端到端延迟、吞吐、并发承载、成本或故障恢复基准，因此不能据此判断其性能优于其他智能体编排平台。尤其是多智能体调用次数、MCP/A2A 序列化开销、冷启动时间、限流策略和区域网络延迟，都需要在真实负载下测量。

持续评测也不应只依赖离线基准。AWS建议按生产会话评估 groundedness、accuracy 和 safety，但生产评分器本身也可能存在偏差。较稳妥的做法是组合使用确定性断言、规则校验、人工抽检和线上回归，并按业务损失而非单一平均分设置门禁。

开发者落地建议

• 先选择一个工具数量少、结果可验证的业务流程，不要直接复制七层复杂度。
• 为每层定义版本化契约，尤其是模型请求、工具授权、智能体发现和 Trace 数据结构。
• 将模型路由、工具调用、检索结果与审批动作全部写入 Trace，同时避免记录未经脱敏的敏感上下文。
• 为多智能体委派设置最大深度、循环检测、超时、预算和熔断策略。
• 对退款、删除、发布及外部通信等高影响操作设置确定性规则和人工审批。
• 使用真实业务流量构造离线评测集，并在每次模型、提示词、工具及编排变更后运行回归测试。
• AWS公开了示例代码和 Workshop，但该参考实现不能替代生产环境所需的安全加固、渗透测试和容量验证。

---

消息来源：AWS Machine Learning Blog (2026-11-09)

—— 完 ——

主题标签： #AWS 关注 #Bedrock AgentCore 关注 #多智能体编排 关注 #智能体安全 关注 #可观测性 关注