“我们如何在生产环境中大规模运行 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 实现集中式发现和路由。
安全与护栏 应当是首要关注点，从第一天起就融入设计中。Agentic AI 使组织面临一类新的风险，从提示注入和工具滥用到记忆和数据投毒，这些都是传统安全框架未曾针对的。默认将所有外部内容视为不可信。通过诸如 Amazon Bedrock AgentCore Identity之类的服务对每个请求进行身份验证，无论其来自用户、另一个智能体还是自动化工作流。然后使用细粒度访问控制在执行前确定每个工具调用是否被允许。为智能体授予临时的、范围受限的凭证，而不是持久密钥。在数据保护方面，在智能体和工具的请求与响应中对敏感数据（如 PHI（Personal Health Information）和 PII（Personally Identifiable Information））进行掩码处理，以避免敏感客户信息出现在智能体输出中或残留在内存中。为了实现问责，将每个重要决策记录在防篡改的审计跟踪中，将高影响操作通过人工审批网关进行路由，并部署熔断器在异常行为升级之前将其制止。考虑使用 Amazon Bedrock Guardrails 处理用户输入，使用 Amazon Bedrock AgentCore Identity 和 Policy in Amazon Bedrock AgentCore 进行身份验证和访问控制，并结合 AWS 安全与治理控制以实现纵深防御安全。
应用层 是最终用户体验所在之处，无论是聊天界面、API 接口还是嵌入式组件。保持这一层有意地精简。它的唯一职责应是呈现对话并将请求传递给下方的编排层。抵制在此嵌入业务逻辑的冲动。分离越清晰，就越容易在不破坏后端稳定性的情况下迭代用户体验。一个决策模型可以作为快速、廉价的检查放在这一边界处：在单次调用中，它会评估请求是否在范围内、是否需要人工介入或是否紧急，并返回概率而不是自由文本。您的代码通过简单的阈值对这些评分进行处理，直接回答离题请求并标记需要升级的情况，从而只有当完整的 agentic 循环能够创造价值时才运行它。在构建应用层时，考虑除了人类之外，另一个 AI 智能体消费和与您的 AI 智能体交互需要什么，并据此构建您的外部接口。
可观测性 应从第一天起就监视每一层，而不是在第一次事故之后。除了日志和指标之外，端到端的智能体追踪对于衡量智能体是否正确执行其任务至关重要。除了追踪之外，还应收集每个请求的成本和 token 使用量、首 token 时间、调用是否安全，并在上线之前提供延迟、错误率和支出的仪表板。主动监控比被动救火成本更低。考虑将 Amazon CloudWatch 与 OpenTelemetry 一起使用，并结合 Amazon CloudWatch Omni 进行追踪和指标收集，以获得对整个技术栈的全面可见性。
Agentic Operations 通过持续评估闭环，因此要从第一天起就进行设置。对每个生产会话在事实依据、准确性和安全性方面进行评分，并设置回归门禁，以便在质量下降波及客户之前发现它。没有这一点，您只知道智能体在发布时是正常的；有了这一点，您可以证明它在随后的每次发布之后仍然正常。考虑使用 Amazon Bedrock AgentCore Evaluations 进行评分，以及 Amazon Bedrock AgentCore optimization 用于持续的性能调优。
零售客户支持代理的参考实现
图 2：零售客户支持参考实现的功能流程
为了将这一架构付诸实践，该框架包含一个可即时运行的参考实现，该实现基于一个覆盖订单状态和退款资格的零售客户支持场景。我们选择这个用例是因为它能够调用技术栈的每一层，同时足够直观，便于团队理解并按自身需求进行改造。
一个主管（supervisor）智能体接收客户的退款请求，并将其委派给 Order 智能体和 Refund 智能体，每个智能体都是拥有 scoped 工具集的专家。Order 智能体从 Amazon DynamoDB 查询配送和购买详情。Refund 智能体从知识库检索基于会员等级的策略规则，并根据配送日期、当前日期和客户的会员等级计算资格。每一次调用都会经过 AgentCore Gateway，在工具执行前由 Policy in AgentCore 实施细粒度访问控制，并且每次调用都通过可观测性层进行端到端追踪，因此当计算出错时，追踪记录可以准确显示是哪一层、哪个决策点导致了问题。
任何构建类似“主管+专家”模式的人都可以克隆该参考实现，并逐层替换为自己的领域逻辑。
为什么可插拔性与分层本身同等重要
七层架构的价值不仅在于它如何分离职责，还在于每一层能够以多快的速度演进。 可插拔性 使之成为可能。层边界处的稳定契约——从身份检查和访问策略到遥测接口——让你无需重新设计技术栈其余部分就能更换底层技术。本质上，构建智能体 AI 系统时应采用架构优先的方法，而非技术驱动的方法。
该框架通过与各层第三方提供商的集成来展示可插拔性：推理层的模型和托管提供商、编排层的搜索能力、应用层的决策 API、安全层的护栏，以及可观测性层中与业务价值和成本追踪并行的智能体追踪与监控解决方案。它在每一层都支持行业标准提供商，因此你可以组合出满足自身特定需求的解决方案。
对企业而言，灵活性保护了现有投资。团队可以保留他们已经信任的可观测性、安全和推理工具，在需要时填补空缺，并逐步采用新能力。该架构提供了一致的基础，而不要求每一项技术决策都来自同一供应商。
结论
一个能运行的原型证明了智能体能做什么。而一个设计良好的架构决定了你的企业能否依赖它。迈向 AI 运营意味着从第一天起就将安全、治理、可见性、成本控制、可靠性和适应性融入设计之中，而不是在系统建成后再补加。
Pluggable Agentic AI Framework 将这些关注点纳入一个具有清晰原则的架构：构建稳定的基础，而不锁定每一项技术选择。模型会变化。工具会演进。业务需求会转移。你的架构应该让这些变化可控，而不是把每一次变化都变成一次重建。
将这一原则付诸实践。从 Workshop Studio 体验开始，探索 公开示例仓库，并将这一动手实现作为你自己架构的起点。它不能替代生产环境的安全加固、测试和评审。
构建你今天所需的能力，以及你明天所需的 灵活性 。