AWS 发布 Pluggable Agentic AI Framework 七层企业级 Agentic AI 参考架构

“我们如何在生产环境中大规模运行 AI 智能体？”是每个客户最终都会问的问题。它伴随着一系列问题：如何安全而放心地处理数千个并发用户请求？如何确保智能体在真实流量下保持可靠，而不是悄然失效？如何知道智能体是否仍然满足它在测试阶段通过的质量与安全标准？智能体安全的最佳实践是什么？这些实践应该是确定性的还是非确定性的？还有更多问题。概念验证无法回答其中任何一个，因为它的目的是展示智能体模型能够完成任务，而不是为了经受生产流量、成本压力和安全审查的考验。

从一个能运行的原型到一个能以可靠、安全、节约且负责任的方式大规模运行的系统之间的鸿沟，正是大多数智能体 AI 项目搁浅的地方，而这很少是模型的错。每个构建智能体的团队往往都要从零开始重建同样的脚手架：自己的路由逻辑、自己的防护栏、自己的可观测性，而且都是事后补救，而非从一开始就内建。这些团队需要一套共享的、可用于生产的架构，让每个智能体都能在其之上构建。

本文将介绍一个由七层组成的可组合参考架构，旨在将多智能体 AI 应用从原型推向生产级规模。

可组合架构

可插拔智能体 AI 框架是一个面向多智能体应用的参考架构，组织为七个层，每层职责明确、契约稳定。各层中展示的服务和技术反映的是参考实现，并非强制选择。各组织可以替换为符合自身现有基础设施和需求的替代方案。这些层共同提供了一套蓝图，用于在生产规模下构建、保护和运营智能体 AI 应用。

图 1：可插拔智能体 AI 框架的七个层

数据与知识是智能体 AI 的基石。智能体的表现取决于它能访问的数据。无论智能体是在查询医疗处方集、跟踪库存还是解读合规规则，它都需要相关且最新的信息才能正确作答。该层通过清晰的契约和协议负责检索、嵌入以及对结构化和非结构化数据的访问：接收查询并返回最相关的信息，作为智能体的上下文。Amazon Bedrock Knowledge Base、Vector Engine for Amazon OpenSearch Serverless、Amazon S3 Vectors 和 Amazon DynamoDB 是这一基石的示例构建模块。

模型与推理的选择应由配置驱动，而不是硬编码到智能体或应用逻辑中。对简单任务使用更小、更快的模型，对需要更细致推理的请求使用更大的模型。针对你正在构建的用例，使用真实且具有代表性的业务数据进行全面的模型评估非常重要。模型路由层通过依赖一致的请求与响应契约，使 AI 智能体与模型托管环境以及特定提供商的 API 保持解耦。诸如 LiteLLM 这样的代理可以提供跨提供商的统一接口，让你无需重写应用逻辑即可根据评估结果切换模型。

编排决定了工作如何分配，选择正确的方式至关重要。对于简单的任务，使用单个智能体端到端地处理工作。对于复杂的跨领域工作流，使用主管智能体来委派专业智能体，每个专业智能体限定于特定能力并绑定一组特定工具。避免构建一个无所不能的智能体。随着工具、指令和上下文不断累积，上下文窗口会变大，延迟会增加，准确性可能下降。工具蔓延随之而来，可能使智能体超出预期边界，导致意外行为和安全漏洞。拆分职责能让每个智能体的上下文保持聚焦，并使延迟更可预测。你还可以独立测试每个智能体的行为、进行扩展并定义其安全模型。实施有界自主：专业智能体应严格在其被授予的工具范围内执行，不得越界。

除了分解为具体的专业智能体并设定其边界之外，还应将专业智能体与主管智能体解耦。允许主管智能体从集中的智能体注册表中发现专业智能体，并通过 MCP（Model Context Protocol）和 A2A（Agent to Agent）等标准化协议调用它们。维护一个集中的智能体注册表，记录每个智能体的工具、技能和所有者。这能让你所在的组织获得大规模治理所需的可见性，通过复用提升 AI 智能体实施的速度，并避免重复开发的成本。考虑使用 Strands Agents 构建专业智能体，使用 Amazon Bedrock AgentCore harness 作为编排器，使用 AWS Agent Registry 和 Amazon Bedrock AgentCore Gateway 实现集中发现与路由。

安全与防护机制应是首要关注点，从第一天起就融入设计。智能体式 AI 使组织面临一类新的风险，而传统安全框架并非为此而设计，从提示词注入、工具滥用到记忆和数据投毒。默认将所有外部内容视为不可信。对每个请求进行身份验证，无论它来自用户、另一个智能体还是自动化工作流，可通过 Amazon Bedrock AgentCore Identity 等服务实现。然后使用细粒度访问控制在执行前确定每次工具调用是否被允许。为智能体授予临时的、限定范围的凭证，而非持久化的机密。在数据保护方面，在智能体和工具的请求与响应中屏蔽 PHI（个人健康信息）和 PII（个人身份信息）等敏感数据，使敏感的客户信息不会出现在智能体输出中或残留在记忆里。为实现可追责性，将每个重要决策记录在防篡改的审计跟踪中，让高影响操作经过人工审批关口，并部署熔断机制，在异常行为升级之前将其阻止。考虑使用 Amazon Bedrock Guardrails 处理用户输入，使用 Amazon Bedrock AgentCore Identity 和 Policy in Amazon Bedrock AgentCore 进行身份验证和访问控制，并结合 AWS 安全与治理控制实现纵深防御安全。

应用层是最终用户体验所在之处，无论是聊天界面、API 接口，还是嵌入式组件。请刻意保持这一层的精简。它的职责应该仅限于呈现对话，并将请求传递给其下的编排层。要抵制在这一层嵌入业务逻辑的冲动。分离越干净，你就越容易在不影响后端稳定性的情况下迭代用户体验。决策模型可以部署在这一边界上，作为一种快速、低成本的检查：它通过一次调用对请求进行评分，判断其是否在范围内、是否需要人工介入、是否紧急，并返回概率值而非自由文本。你的代码根据这些分数和简单的阈值采取行动，直接回复偏离主题的请求并标记需要升级的情况，从而让完整的智能体循环只在能创造价值时才运行。在构建应用层时，要考虑除了人类之外，还需要什么才能让另一个 AI 智能体也能消费你的 AI 智能体并与它们交互。据此构建你的外部接口。

可观测性应该从第一天起就监控每一层，而不是在第一次事故之后。除了日志和指标之外，端到端的智能体追踪对于衡量智能体是否正确完成了其任务至关重要。除了追踪之外，还要收集每个请求的成本和 token 用量、首个 token 的生成时间、调用是否安全，并在上线之前提供针对延迟、错误率和支出的仪表板。主动监控的成本低于被动救火。考虑将 Amazon CloudWatch 与 OpenTelemetry 以及 Amazon CloudWatch Omni 结合使用，以实现追踪和指标，从而对整个技术栈获得全面的可见性。

智能体运维通过持续评估来闭环，因此请从第一天起就进行设置。对每个生产会话在可信度、准确性和安全性方面进行评分，并设置回归门禁，在质量下降波及客户之前将其捕获。没有这一机制，你只能在上线时知道智能体正常工作。有了它，你就能证明在之后的每次发布中它依然正常工作。考虑使用 Amazon Bedrock AgentCore Evaluations 进行评分，使用 Amazon Bedrock AgentCore optimization 进行持续的性能调优。

零售客服智能体的参考实现

图 2：零售客服参考实现的功能流程

为了让这一架构落地，该框架包含一个可直接运行的参考实现，基于一个涵盖订单状态查询和退款资格判定的零售客服场景。我们之所以选择这一用例，是因为它既覆盖了技术栈的每一层，又足够直观，便于团队理解并根据自己的需求进行改造。

一个监督者智能体接收客户的退款请求，并将其委托给一个 Order 智能体和一个 Refund 智能体，每个都是配备了特定范围工具集的专家。Order 智能体从 Amazon DynamoDB 查询配送和购买详情。Refund 智能体从知识库中检索基于会员等级的政策规则，并根据配送日期、当前日期和客户的会员等级计算退款资格。每一次调用都经过 AgentCore Gateway，它在工具执行前通过 AgentCore 中的策略（Policy in AgentCore）实施细粒度的访问控制，并且每次调用都通过可观测性层进行端到端追踪，因此当计算出错时，追踪记录能准确显示是哪一层、哪个决策点导致了问题。

任何想要构建类似“监督者—专家”模式的人都可以克隆该参考实现，并逐层替换为自己的领域逻辑。

为什么可插拔性与各层本身同等重要

七层架构的价值不仅在于它如何划分职责，更在于每一层能以多快的速度演进。可插拔性让这成为可能。从身份检查、访问策略到遥测接口，层边界上的稳定契约让你可以在不重新设计技术栈其余部分的情况下更换底层技术。本质上，构建智能体 AI 系统时应采用架构优先而非技术驱动的方法。

该框架通过与各层第三方提供商的集成来实践可插拔性：推理层的模型和托管提供商、编排层的搜索能力、应用层的决策 API、安全层的防护栏，以及可观测性层的智能体追踪和监控解决方案（同时包含业务价值和成本跟踪）。它在每一层都支持行业标准提供商，因此你可以组合出满足自身特定需求的解决方案。

对企业而言，灵活性可以保护现有投资。团队可以保留他们已经信任的可观测性、安全和推理工具，在需要之处填补空白，并逐步采用新能力。该架构提供了一致的基础，而不要求所有技术决策都来自同一家供应商。

结论

一个可运行的原型能证明智能体能做什么；一个设计良好的架构则决定你的企业能否依赖它。迈向 AI 运营意味着从第一天起就把安全、治理、可见性、成本控制、可靠性和适应性设计进去，而不是在系统建成之后再补加。

可插拔智能体 AI 框架将这些关注点纳入一个架构，其原则清晰明了：构建稳定的基础，但不锁定每一个技术选择。模型会变，工具会演进，业务需求会变化。你的架构应当让这些变化易于管理，而不是让每一次变化都变成一次重建。

把这个原则付诸实践。从Workshop Studio 体验开始，探索公开示例仓库，并将这个动手实现作为你自己架构的起点。它不能替代生产环境的安全加固、测试和审查。

构建你今天需要的能力，以及你明天将需要的灵活性。

关于作者