可插拔智能体 AI 框架：基于 Amazon Bedrock AgentCore 的七层可组合企业智能体 AI 参考架构

“我们如何在生产环境中大规模运行我们的 AI 智能体？”这是每位客户最终都会提出的问题。它伴随着多个子问题：我们如何安全、自信地处理成千上万的并发用户请求？我们如何确保智能体在真实流量下依然可靠，而不是默默失效？我们如何判断一个智能体是否仍符合其在测试阶段通过的质量和安全标准？智能体安全的最佳实践是什么？应该是确定性的还是非确定性的？还有更多问题。概念验证无法回答这些问题，因为它旨在证明智能体模型能够完成任务，而非经受住生产流量、成本压力和安全审查的考验。 从可用的原型到能够在规模上可靠、安全、经济且负责任地运行的系统之间存在的鸿沟，正是大多数智能体 AI 项目停滞不前的原因，而这很少是模型本身的过错。每个构建智能体的团队往往都要从头重建相同的基础设施：自己的路由逻辑、自己的护栏机制、自己的可观测性系统，而这些通常都是事后才添加上去的，而非一开始就内置的。各团队需要一种共享的、可直接投入生产的架构，让每个智能体都能在其基础上进行构建。 本文将介绍一种七层可组合参考架构，旨在帮助多智能体 AI 应用从原型阶段扩展到生产规模。 可组合架构 可插拔智能体 AI 框架是一种面向多智能体应用的参考架构，分为七层，每一层都有明确的职责和稳定的接口契约。每层中展示的服务和技术均基于参考实现，并非强制性选择。组织可以根据自身现有基础设施和需求选用替代方案。这些层共同提供了一种 用于在生产规模上构建、保障和运行智能体 AI 应用的蓝图。 图 1：可插拔智能体 AI 框架的七层架构 数据与知识是智能体 AI 的基石。一个智能体的能力取决于其可访问的数据质量。无论智能体是在查阅医疗处方集、追踪库存，还是解读合规规则，它都需要相关且最新的信息才能做出正确响应。这一层负责检索、嵌入以及通过清晰的契约和协议访问结构化和非结构化数据：接收查询并返回最相关的信息，作为智能体的上下文。Amazon Bedrock Knowledge Base、适用于 Amazon OpenSearch Serverless 的 Vector Engine、Amazon S3 Vectors 和 Amazon DynamoDB 都是构建这一基石的示例组件。 模型和推理选项应由配置驱动，而非硬编码到智能体或应用逻辑中。对于简单任务使用较小、较快的模型，而对于需要更精细推理的请求则使用较大的模型。重要的是，针对您正在构建的用例，使用真实且具有代表性的业务数据进行全面的模型评估。模型路由层通过依赖一致的请求-响应契约，使 AI 智能体与模型托管环境及特定提供商的 API 解耦。诸如 LiteLLM 之类的代理提供跨提供商的通用接口，因此您可以根据评估结果更换模型，而无需重写应用逻辑。 编排决定了工作如何分配，选择正确的方法至关重要。对于简单的任务，可使用单个智能体从头到尾处理所有工作。对于复杂的跨领域工作流，则应使用主管来委派专业智能体，每个智能体都限定于特定的 能力和特定的一组工具紧密相关。避免构建一个无所不能的单一智能体。随着工具、指令和上下文的不断积累，上下文窗口会变大，延迟会增加，准确性也可能受到影响。工具蔓延现象随之出现，这可能使智能体超出其预期边界，导致意外行为和安全漏洞。将职责拆分有助于保持每个智能体的上下文聚焦，并使延迟更加可预测。您还可以独立测试每个智能体的行为、对其进行扩展并定义其安全模型。强制实施有限自主性：专业智能体应严格在其被授予的工具范围内执行，不得越界。 除了分解为特定的专业智能体并设定其边界外，还应将专业智能体与主管智能体解耦。允许主管智能体从集中式智能体注册表中发现专业智能体，并通过 MCP（模型上下文协议）和 A2A（智能体到智能体）等标准化协议调用它们。维护一个集中式智能体注册表，记录每个智能体的工具、技能及其所有者。这能为您的组织提供大规模治理所需的可见性，通过可重用来提高 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 中的 AgentCore Identity 和 Policy 进行身份验证与访问控制，同时搭配 AWS 安全与治理控制措施，构建纵深防御的安全体系。 应用层是终端用户体验的承载之处，无论是聊天界面、API 表面还是嵌入式小部件。请有意保持这一层的轻量级设计。其职责应仅限于呈现对话并把请求传递给下层的编排层。切勿在此处嵌入业务逻辑。分离越清晰，就越容易迭代用户体验，而不会导致后端不稳定。决策模型可以作为快速且经济的检查机制置于这一边界：它只需一次调用即可评估请求是否在范围内、是否需要人工介入或是否紧急，并返回概率值而非自由文本。您的代码可根据这些分数设置简单的阈值进行处理， 直接回复与主题无关的请求并标记升级情况，这样完整的智能体驱动循环仅在真正增值时才会运行。在构建应用层时，设想如果另一个 AI 智能体需要与您的 AI 智能体及人类共同消费和交互，您需要哪些功能。据此构建您的外部接口。 可观测性应从第一天起就覆盖每一层，而非等到首次故障后才开始。除了日志和指标外，端到端的智能体追踪对于衡量智能体是否正确执行任务至关重要。在进行追踪的同时，收集每次请求的成本和令牌使用量、首个令牌生成时间、调用是否安全等信息，并在上线前提供延迟、错误率和费用支出的仪表板。主动监控比被动救火更经济。建议结合 OpenTelemetry 使用 Amazon CloudWatch，并搭配 Amazon CloudWatch Omni 进行追踪和指标分析，以实现对整个技术栈的全面可见性。 智能体运维通过持续评估来闭环管理，因此请从第一天起就做好相关设置。针对每次生产会话，从稳健性、准确性和安全性三个维度进行评分，并设置回归门禁机制，以便在质量问题影响到客户之前及时发现。否则，您只能知道智能体在上线时运行正常；而有了这套机制，您就能证明它在每次后续发布后依然有效。建议使用 Amazon Bedrock AgentCore Evaluations 进行评分，并利用 Amazon Bedrock AgentCore 优化持续性能调优。 零售客服智能体的参考实现 图 2：零售客服参考实现的功能流程 为使该架构更具实用性，框架中包含了一个基于零售客服场景的开箱即用参考实现，涵盖订单状态查询和退款资格判定。我们 选择这个用例，是因为它涵盖了整个技术栈的每一层，同时又足够直观，便于团队遵循并根据自身需求进行调整。 一个主管智能体接收客户的退款请求，并将其委派给订单智能体和退款智能体，这两个智能体都是拥有特定工具集的专业角色。订单智能体从 Amazon DynamoDB 中查询配送和购买详情。退款智能体则从知识库中获取基于等级的政策规则，并结合配送日期、当前日期以及客户的忠诚度等级来计算是否符合退款条件。所有这些调用都经过 AgentCore 网关，在工具在 AgentCore 中执行策略之前，该网关会实施细粒度的访问控制；而且每一次调用都会通过可观测性层进行端到端追踪，因此当计算出错时，追踪信息能够准确显示是哪一层、哪个决策点导致了问题。 任何构建类似主管与专家模式的开发者都可以克隆参考实现，并逐层替换为自己的领域逻辑。 为什么可插拔性与各层本身同样重要 七层架构的价值不仅在于它如何划分职责，更在于每一层能够以多快的速度演进。可插拔性使这一切成为可能。在各层边界上建立稳定的合作契约，从身份验证和访问策略到遥测接口，使您能够在不重新设计整个技术栈其余部分的情况下更换底层技术。本质上，应采取架构优先的方法来构建智能体 AI 系统，而非单纯的技术驱动方法。 该框架通过在各层与第三方提供商的集成来展示可插拔性，从而将这一理念付诸实践：推理层的模型和托管提供商、搜索功能层的 编排层、应用层的决策 API、安全层的护栏，以及可观测性层的智能体追踪与监控解决方案，并辅以业务价值和成本追踪。它支持各层的行业标准提供商，因此您可以组合出满足特定需求的解决方案。 对于企业而言，灵活性能够保护现有投资。团队可以保留其已信赖的可观测性、安全性和推理工具，在需要时填补空白，并逐步采用新功能。该架构提供了一致的基础，而无需让每个技术决策都来自同一供应商。 结论 一个可用的原型证明了智能体的能力。而精心设计的架构则决定了您的企业能否依赖它。迈向 AI 运营意味着从第一天起就将安全性、治理、可见性、成本控制、可靠性和适应性融入设计之中，而不是在系统构建完成后才添加这些要素。 可插拔智能体 AI 框架将上述考量融入到一种具有明确原则的架构中：构建稳定的基础，同时避免将每项技术选择锁定。模型会变化，工具会演进，业务需求也会转变。您的架构应使这些变化易于管理，而不是让每一次变化都变成一次重建。 将这一原则付诸实践。从 Workshop Studio 体验开始，探索公共示例仓库，并将动手实现作为您自己架构的起点。但这并不能替代生产环境的安全加固、测试和审查。 构建您今天所需的功能，以及您明天所需的灵活性。 关于作者