Article · AI translation
“我们如何在生产环境中大规模运行 AI 智能体？”是每位客户最终都会提出的问题。随之而来的还有一系列问题。我们如何安全、可靠地处理数千个并发用户请求？如何确保智能体在真实流量下保持可靠，而不是悄然失效？如何知道智能体是否仍符合测试时达到的质量和安全标准？智能体安全有哪些最佳实践？这些做法应该是确定性的，还是非确定性的？还有许多其他问题。概念验证无法回答这些问题，因为它旨在展示智能体模型能够完成任务，而不是应对生产流量、成本压力和安全审查。从可用的原型到能够大规模可靠、安全、节约成本且负责任地运行的系统，这中间的差距正是多数智能体 AI 项目停滞的地方，而问题很少出在模型本身。构建智能体的每个团队往往都要从零开始重复搭建同样的支撑体系：自己的路由逻辑、自己的防护措施、自己的可观测性，而且这些都是事后补上的，而非从一开始就融入设计。团队需要一个所有智能体都能基于其构建的共享生产级架构。本文将介绍一种由 7 层组成、可组合的参考架构，旨在帮助多智能体 AI 应用从原型走向规模化生产。
可组合架构
Pluggable Agentic AI Framework 是面向多智能体应用的参考架构，由职责各异且具有稳定契约的 7 层组成。每一层展示的服务和技术反映的是参考实现，并非必须采用的选择。组织可以根据现有基础设施和需求替换为其他方案。这些层共同提供了在生产规模下构建、保护和运营智能体 AI 应用的蓝图。
图 1：Pluggable Agentic AI Framework 的 7 层
数据与知识是智能体 AI 的基础。智能体的表现取决于它能访问的数据。无论智能体是在查询医疗保健药品目录、跟踪库存，还是解读合规规则，它都需要相关且最新的信息才能正确回答。这一层负责检索、嵌入，以及通过明确的契约和协议访问结构化与非结构化数据：接收查询，并返回可作为智能体上下文的最相关信息。Amazon Bedrock Knowledge Base、Vector Engine for Amazon OpenSearch Serverless、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 Identity 和 Amazon Bedrock AgentCore 中的 Policy 进行身份验证与访问控制，并结合 AWS 安全与治理控制措施实现纵深防御。
应用层承载终端用户体验，无论是聊天界面、API 接口还是嵌入式组件。应有意保持这一层的轻量化。它的职责应仅限于呈现对话，并将请求传递给下方的编排层。不要把业务逻辑嵌入这里。分层越清晰，迭代用户体验时就越不容易扰乱后端。可以在这一边界设置一个决策模型，作为快速且低成本的检查：它通过一次调用评估请求是否在处理范围内、是否需要人工介入或是否紧急，并返回概率而非自由文本。代码依据这些分数和简单阈值采取行动，直接回答离题请求并标记需要升级处理的情况，使完整的智能体循环只在能带来价值时运行。构建应用层时，应考虑除人类之外，其他 AI 智能体需要什么才能使用你的 AI 智能体并与之交互，并据此构建外部接口。
可观测性应从第一天起覆盖每一层，而不是等首次事故发生后才建立。除了日志和指标，端到端智能体追踪对于衡量智能体是否正确完成任务也至关重要。除追踪数据外，还应收集每次请求的成本和令牌用量、首个令牌生成时间、调用是否安全，并在上线前建立展示延迟、错误率和支出的仪表板。主动监控的成本低于事后应急处置。可以考虑使用 Amazon CloudWatch 和 OpenTelemetry，并结合 Amazon CloudWatch Omni 进行追踪和指标收集，以全面了解整个技术栈的运行情况。
智能体运营通过持续评估形成闭环，因此应从第一天起就建立起来。对每次生产会话的依据充分性、准确性和安全性进行评分，并设置回归关卡，在质量下降影响客户之前将其发现。没有这一机制，你只能知道智能体在发布时有效。有了它，你就能证明智能体在此后的每次发布后仍然有效。可以考虑使用 Amazon Bedrock AgentCore Evaluations 进行评分，并使用 Amazon Bedrock AgentCore optimization 持续调优性能。
零售客户支持智能体的参考实现
图 2：零售客户支持参考实现的功能流程
为了让这一架构落地，框架提供了一个可直接运行的参考实现，基于涵盖订单状态和退款资格的零售客户支持场景。我们选择这一用例，是因为它涵盖技术栈的每一层，同时又足够直观，便于团队理解并根据自身需要调整。监督智能体接收客户的退款请求，并将任务委派给订单智能体和退款智能体；两者都是只配备限定范围工具的专业智能体。订单智能体从 Amazon DynamoDB 查询配送和购买详情。退款智能体从知识库检索基于客户等级的政策规则，并根据配送日期、当前日期和客户忠诚度等级计算退款资格。所有这些调用都经过 AgentCore Gateway，由 AgentCore 中的 Policy 在工具执行前实施细粒度访问控制；每次调用也都会通过可观测性层进行端到端追踪。因此，当计算出错时，追踪记录会准确显示问题发生在哪一层、哪一个决策点。任何构建类似监督智能体与专业智能体模式的人，都可以克隆这一参考实现，逐层替换为自己的领域逻辑。
为什么可插拔性与各层本身同样重要
7 层架构的价值不仅在于分离职责，也在于每一层能够快速演进。可插拔性使之成为可能。从身份检查和访问策略到遥测接口，各层边界处的稳定契约让你能够更换底层技术，而无需重新设计技术栈的其他部分。简而言之，构建智能体 AI 系统时应采用架构优先的方法，而不是技术驱动的方法。该框架通过展示各层与第三方提供商的集成，将可插拔性付诸实践：推理层集成模型和托管提供商，编排层集成搜索能力，应用层集成决策 API，安全层集成防护措施，可观测性层集成智能体追踪和监控方案，同时跟踪业务价值和成本。它在每一层都支持行业标准提供商，因此你可以组合出满足特定需求的解决方案。对企业而言，灵活性可以保护现有投资。团队可以保留已信赖的可观测性、安全和推理工具，按需补足缺口，并逐步采用新能力。该架构提供一致的基础，无需让所有技术选择都来自同一家供应商。
结论
可用的原型证明智能体能做什么。精心设计的架构决定企业能否依赖它。转向 AI 运营意味着从第一天起，就将安全、治理、可见性、成本控制、可靠性和适应性融入设计，而不是等系统建成后再添加。Pluggable Agentic AI Framework 将这些事项纳入架构，并遵循一个明确原则：构建稳定的基础，同时不锁定每一项技术选择。模型会变化。工具会演进。业务需求会改变。你的架构应让这些变化易于管理，而不是让每一次变化都变成重新构建。将这一原则付诸实践。从 Workshop Studio 体验入手，探索公开的示例代码库，并将动手实践的实现作为构建自身架构的起点。它不能代替生产环境的安全加固、测试和审查。构建今天所需的能力，也构建明天所需的灵活性。
关于作者
Sindhura Palakodety
Sindhura 是 Amazon Web Services（AWS）的高级解决方案架构师，也是 ISV 生成式 AI 的单线程负责人（STL），致力于帮助客户开发符合 Well-Architected 原则的企业级解决方案。她专注于生成式 AI 和数据分析领域，帮助组织运用创新技术取得变革性的业务成果。
Sujatha Kuppuraju
Sujatha 是 AWS 的首席解决方案架构师，专注于云和智能体 AI 解决方案。她与软件公司高管合作，在 AWS 上设计安全、可扩展的产品，并指导战略性产品开发。
Mythili Annamalai Sekar
Mythili 是 Amazon Web Services（AWS）的解决方案架构师，负责与独立软件供应商（ISV）合作，指导客户依据 AWS 最佳实践设计安全的企业级架构。她的工作聚焦于无服务器技术和生成式 AI，帮助软件公司将新的云能力转化为实际可用的生产级业务成果。
Madhu Samhitha Vangara
Madhu 是 AWS 的全球生成式 AI 专家解决方案架构师，专注于 Amazon Bedrock AgentCore 和 Strands Agents 的智能体 AI 技术市场推广。她拥有深厚的企业经验，擅长将新兴 AI 能力转化为可衡量的客户成果。Madhu 在 AI 会议上担任演讲嘉宾，专注于生产级智能体 AI。