如果你曾尝试将智能体投入生产，就会发现模型和工具的使用并不是阻碍。主要瓶颈在于它们周围的一切：有多少团队可以在安全环境中构建、每个模型和工具由哪个团队负责、AgentOps 和错误处理如何保持在预定义边界内，以及平台、Workstream 和财务团队如何跨账户查看成本和健康状况。对于希望支持众多智能体用例的平台团队来说，这是一个需要设计和运营的平台产品。在本文中，我们将管理平台的团队称为平台团队，将基于平台构建的团队称为 Workstream 团队。Workstream 团队是在平台上构建和拥有智能体的领域或产品团队。

每个 Workstream 团队都需要一条铺好的道路，包含经批准的模型和工具、短期工作负载身份、隔离的运行时和内存、自动化评估、回滚、遥测和成本归属。当 Workstream 团队自定义提示词、工具、数据访问和应用程序行为时，这些控制措施需要保持一致。如果每个团队都自行组装这些控制措施，控制就会发生漂移，共享服务会成为瓶颈，所有权也难以审计。

在本文中，我们将逐步介绍在 Amazon Bedrock 和 Amazon Bedrock AgentCore 上构建企业智能体 AI 平台的架构和参考实现。我们涵盖多账户运营模式、平台控制平面、可重复的每 Workstream 部署模式、独立的推理和工具网关，以及在每个智能体晋升到生产之前对其进行门控的评估流水线。读完后，你应该能够从配套蓝图部署一个受治理的 Workstream，验证其安全和生命周期契约，并将其作为组织内自有智能体 AI 平台的基础。

Amazon Bedrock AgentCore 提供模块化服务，用于大规模构建、部署和运营智能体，包括运行时、网关、身份、内存、策略、注册表和评估。基于 AgentCore 构建的企业智能体 AI 平台蓝图将周围的企业契约作为可部署的基础设施即代码添加：所有权、账户边界、软件交付、可观测性、成本治理和退役。

架构原则

在深入解决方案细节之前，有必要了解驱动平台架构的组织需求。我们从建立智能体平台的客户那里听到的常见挑战分为以下五类：

• 受治理的模型访问：每个不受信任的推理请求都必须通过经批准的推理网关。网关应用组织的护栏（例如 Amazon Bedrock Guardrails 或第三方提供商），限制每个 Workstream 可以使用的模型和推理 AWS 区域，并强制执行每 Workstream 的速率限制、令牌配额和预算，以确保没有单个团队可以耗尽共享容量。它还携带工作负载身份并发出归属数据。

• 受治理的工具访问：智能体必须通过经过身份验证的 Model Context Protocol (MCP) 网关发现并仅调用经批准的工具，具有精确的目标、最小权限执行角色、策略决策和可审计的所有者。

• 委托交付：Workstream 团队（例如产品团队）需要在预先批准的边界内独立发布和回滚，而无需等待平台团队部署每个应用程序，也无需授予开发人员直接的基础设施写入路径。

• 队列运营和成本：多个角色需要跨账户可见性，而无需获得对团队工作负载的写入权限。智能体运营工程师需要日志、指标、跟踪和配额。Workstream 所有者需要根据其预算了解每个智能体的成本。FinOps 和财务团队需要通过 AWS Cost Explorer 和 AWS Cost and Usage Report (CUR) 按团队或业务部门进行计费分摊。安全和治理负责人需要证明哪个工作负载调用了哪个模型和工具。

• 有界证据和生命周期：每个智能体发布都需要在其触及的每个边界提供证明：模型访问：经批准的模型调用成功，而对未经批准的模型或区域的调用被拒绝。工具访问：已订阅的工具调用成功，而对智能体订阅之外的工具的调用被拒绝并返回预期错误。身份：来自另一个 Workstream 账户或身份的请求被拒绝。发布：可以恢复之前的智能体运行时版本。退役：拆除按依赖顺序移除智能体的运行时、内存、工具网关和工具授权，并确认没有遗留任何内容。

该蓝图通过四个相互连接的平面来满足这些需求：开发者体验、平台控制、Workstream 执行以及保障与运营。扩展单元是 Workstream 单元，而不是手动配置的智能体或一个共享工作负载账户。蓝图 README 详细记录了每个平面的职责。你将在后续段落中了解主要平面：智能体 AI 平台控制平面和可重复的 Workstream 单元。

运营模式和平台组件

企业通常采用三种运营模式之一来实施智能体 AI：

• 集中式：由单一的人工智能与机器学习（AI/ML）团队构建并运行所有智能体。治理保持一致，但随着用例数量增长，该团队很快会成为瓶颈。

• 分散式：每个业务单元构建并运营自己的智能体。团队可以快速行动，但缺乏共享标准，控制容易漂移，工作重复，成本可见性也会受损。

• 联邦式：中央平台团队提供共享的、受治理的服务，而领域团队保留对其智能体、工具和数据的所有权。该模式在团队自主性与一致的护栏之间取得平衡，也是大多数企业最终采用的模式。

• 如需选择帮助，请参阅 AWS Prescriptive Guidance 中关于治理模型的页面。

根据我们在客户合作中观察到的模式，该蓝图实现了联邦式模型。平台团队是枢纽，通常包括平台产品经理、架构师、平台工程师、智能体运维工程师以及安全与治理负责人。工作流团队是辐条，由智能体开发者、领域技术负责人和 AI/ML 工程师组成。执行发起人和 CISO 位于两者之上。

在该蓝图中，平台团队负责每个组件的定义：模板、版本、策略和准入。每个工作流账户运行自己所属的每团队组件实例（Runtime、Memory、Tool Gateway），因此故障或回滚会限制在一个团队的边界内。

解决方案概述

该解决方案提供一个受治理的多账户 Agentic AI 平台，由平台团队运营，内部产品和工程团队等工作流团队通过版本化、自助式接口使用。

在企业规模下，开发者体验平面是一个组织批准、版本化智能体模板的目录。该蓝图提供了 Strands、LangGraph 和 CrewAI 的参考模板，但当模板保留相同的推理网关、工具网关、身份、策略、评估和交付契约时，你可以使用自己选择的框架。应用团队拥有提示词、智能体逻辑、工具和评估用例。平台团队拥有通用控制和发布要求。

在四个平面中，有两个承载了大部分架构：

• Agentic AI 平台控制平面：平台账户发布版本化模板和接口，运营 AWS Agent（智能体） Registry 治理记录和共享推理网关，准入模型和 Guardrails，编排经过审查的发布，并聚合队列信号。团队通过代码、描述符和管道使用这些能力，而不是通过管理员会话或部署工单。

• 可重复的工作流单元：每个产品或领域获得一个隔离边界，包含团队拥有的源代码仓库、工作负载管道，以及三项 Amazon Bedrock AgentCore 能力：AgentCore Runtime、按参与者作用域隔离的 AgentCore Memory，以及使用 AWS_IAM 授权并仅暴露已批准工具目标的 AgentCore Gateway。该单元还包含本地客户管理的 AWS KMS 密钥、标签、告警、预算和 CloudWatch Observability Access Manager（OAM）源链接。一个单元可以部署、失败、回滚或退役，而无需与其他团队的发布协调。

关键组件

下图说明了该解决方案的运营模型和受治理流程。

图 1：企业 Agentic AI 平台运营模型，展示了治理基础、平台控制平面、可重复的团队自有工作流单元，以及它们之间的软件交付、推理、工具、遥测和所有权流程。

该架构由以下账户层组成：

• 管理与治理基础。AWS Organizations、AWS IAM Identity Center、预防性策略、审计、保留和成本策略共同确立企业边界。这些是逻辑职责，可以映射到现有的 AWS Control Tower 着陆区，而无需重复的账户结构。

• 安全、审计与可观测性层。AWS CloudTrail、AWS Config、AWS Security Hub、Amazon GuardDuty、日志归档和 Amazon CloudWatch OAM 接收端提供独立的控制面证据和队列可见性。中央操作员可以查询共享信号，而无需获得对 Workstream 资源的写入权限。

• Agentic AI Platform 的平台层。独立的 Platform 环境拥有黄金路径、治理目录、Guardrails、共享 Inference Gateways、精确工具别名、流水线、兼容性、配额和通用操作接口。平台变更在更广泛推广之前会针对代表性单元进行测试。

• Workstream 队列层。每个产品、领域或受监管边界接收一个或多个非生产与生产单元。团队拥有 Runtime、Memory、Tool Gateway、工具、数据、提示词、评估用例、应用事件和服务级别目标（SLO）。相同的基线可以在多个单元中重复，同时保持账户级隔离。

解决方案演练

以下各节梳理关键设计决策：账户拓扑、预防性和检测性控制、AgentCore 执行路径以及交付流水线。

账户拓扑与组织单元

该蓝图定义了逻辑账户角色，将企业治理、共享 Platform 服务和团队拥有的执行环境分离：

| 角色 | 着陆区放置位置 | 用途 |
| --- | --- | --- |
| 管理基础 | 根 / 安全与管理 | Organizations、Identity Center、预防性策略、审计、保留和成本策略 |
| 安全与日志归档 | 安全 | CloudTrail、AWS Config、Security Hub、GuardDuty 和保留的审计数据 |
| 可观测性 | 安全或运营 | CloudWatch OAM 接收端和队列日志、指标、跟踪及成本视图 |
| Agentic AI Platform | 智能体平台 | 黄金路径、AWS Agent Registry、Guardrails、Inference Gateways、流水线和队列控制 |
| Workstream 单元 | 智能体 Workstreams | 团队拥有的 Runtime、Memory、Tool Gateway、工具、数据、评估和应用 SLO |
| 附加 Workstream 单元 | 智能体 Workstreams | 按产品、领域、环境或受监管边界重复相同基线 |

此拓扑集成到现有的着陆区中，即一个预配置、安全且可扩展的多账户 AWS 环境，其中 Management、Platform 和 Workstream 标签描述的是职责，而非固定的三账户资产。一个组织可以运行多个经过验证的 Platform 环境和许多 Workstream 账户对。从单个代表性单元开始，证明入职、生产推广、回滚、集中可观测性和零残留退役，然后再重复基线。

服务控制策略

服务控制策略限制 Platform 和 Workstream 账户可用的最大权限。它们补充而非替代 IAM、网关授权、Guardrails、资源策略、网络控制和流水线证据。该蓝图针对确切的账户和区域渲染并审查有效策略，而不是仅依赖源代码意图。

• 模型与区域准入：组织策略和 Gateway 执行角色将推理限制在已批准的模型和支持的区域。添加模型或区域需要服务可用性、驻留、IAM、质量、成本、回滚、可观测性和拒绝验证。

• Guardrail 与推理强制执行：智能体不直接调用模型提供商。推理经过受治理的网关，在那里应用阶段 Guardrail 和模型允许列表。

• 仅流水线 Workstream 变更：Workstream 团队提交拉取请求并使用 Workload 流水线。直接由开发者部署到 Workstream 账户不在支持的操作模型范围内，这使经过审查的发布和证据路径不可绕过。

• Registry 与 Gateway 治理：当订阅的 Registry 记录缺失、更改或未批准时，Workstream Gateway 合成失败。

• 范围化部署角色：引导策略按账户和区域生成，使用 AWS Identity and Access Management Access (IAM) Analyzer 验证，并通过有效策略模拟进行检查。管理员访问权限保留用于初始设置，而非日常流水线执行。

• 职责分离与对抗性证明：Platform 控制模型、Guardrail、Registry 和共享服务准入。Workstream 团队控制应用行为。每个被拒绝的路径都配有一个授权的正向调用和一个变更，以证明预期的控制导致了拒绝。

Workstream 账户内的管理员无法围绕这些控制创建受支持的快速路径。新的或更改的组织策略需要沙盒或代表性单元浸泡、精确的允许和拒绝测试，以及在广泛附加之前制定回滚计划。

带评估门禁的 CI/CD 流水线

该蓝图使用经过审查的 Platform 和 Workload 管道来强制执行以下晋升顺序：

• 源与审查：拉取请求建立不可变的源修订版本。管道固定预期分支，因此未合并的更改无法静默地构建仓库默认分支。

• 构建与合成：管道编译代码、运行测试和 linting、创建智能体清单、扫描摘要绑定的镜像、验证策略、解析已批准的 Registry 描述符，并检查合成的 AWS CloudFormation 和 cdk-nag 输出。

• 稳定角色与权限交接：Workload 管道创建稳定的 Workstream 角色并暂停。Platform 管道将精确的工具别名授予精确的 Gateway 角色，验证实时策略，然后 Workload 管道才继续。

• 部署到非生产环境：管道将 Runtime、Memory、Tool Gateway、可观测性、告警、预算、标签和应用程序资源部署到该单元的非生产边界中。

• 评估已部署的智能体：门禁调用真实的 Runtime 并测量回归、质量、工具成功率、拒绝行为、首令牌延迟和成本。每个授权调用都配有一个对抗性孪生调用：门禁调用已批准的模型并确认成功，然后调用未批准的模型并确认拒绝。同样的模式适用于工具、跨账户身份和限流。如果缺少预期的拒绝，门禁将使构建失败。

• 人工审批：审查者检查已部署的证据、已知限制和残余风险。当缺少必需的探测、资源或预期拒绝时，仅凭通用的绿色构建是不够的。

• 晋升、观察和回滚：生产晋升使用经过审查的修订版本和连续性检查。通过更新、取消、回滚、恢复和重新运行对 Runtime 会话进行采样，以便管道证明正向路径和恢复路径。

任何 Workstream 部署步骤都没有手动快速通道。Platform 团队拥有发布契约，但 Workstream 团队运营自己的管道实例和部署节奏。退役遵循严格的依赖顺序：首先撤销 Platform 别名授权，然后撤销 Workstream Gateway 和工具角色，最后撤销 Runtime、Memory 和应用程序资源。每一步在继续之前都会进行验证，最终清单确认零残余资源保留。

安全与治理

该蓝图通过强化身份、策略、交付、数据和证据控制来实现纵深防御：

• 身份与信任边界：AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）和 Amazon Cognito 提供短期推理凭证。AWS_IAM 和 SigV4 对工具流量进行身份验证。精确的 Runtime 和 Gateway 角色、颁发者和受众检查、账户和区域上下文以及作用域引导信任将每个主体限制在其预期路径上。

• 模型安全与准入：推理流经解决方案概述中描述的受治理网关，在每次调用之前应用 Guardrails 和模型允许列表。

• 工具授权：Tool Gateway 仅调用 Registry 批准的别名，如解决方案概述中所述。Cedar 策略提供授权，并保留 AWS Lambda 包装器以实现纵深防御。

• 租户数据保护：Workstream 账户隔离应用程序状态。AgentCore 内存使用参与者作用域命名空间和客户管理的 KMS 密钥。工具和应用程序数据仍归团队所有，保留、删除和访问策略是明确的，而不是从共享的可变工作负载账户继承的。

• 软件供应链与发布：经过审查的源、清单哈希、可重现构建、摘要绑定的镜像扫描、策略验证、cdk-nag 检查、已部署运行时评估、人工审批、回滚和按依赖顺序拆除构成一个发布契约。缺少检查即失败关闭。

• 审计、可观测性与成本治理：CloudTrail 和保留的控制面数据佐证管道证据。OAM 与中央操作员共享日志、指标和跟踪。标准分配标签、预算、配额和 AWS 成本与使用报告对账分配所有权，而不授予智能体重写自身归属的权限。

该仓库是一个参考实现。开发者可以调整它以满足自己的需求。部署和可用功能基于 eu-west-1（爱尔兰）区域。替换组件、其他区域或更广泛的组织推广需要其自身的可用性、安全性、负载、回滚、可观测性和拆除证据。

结论

在本文中，我们介绍了一个基于 Amazon Bedrock AgentCore 构建的企业级 Agentic AI 平台。该架构将集中治理的 Platform 控制面与可重复的、团队拥有的 Workstream 单元分离，具有独立的推理和工具网关，并且生产晋升由已部署运行时评估进行门控。

配套仓库包含一个蓝图，可端到端验证这些控制，从管道门禁和对抗性边界测试到零残余拆除。支持声明止于该测试边界。

要开始使用，请从配套仓库部署一个代表性的 Workstream 单元，证明其完整生命周期，然后从同一版本化基线自动化其他单元。

• GitHub 上的 Enterprise Agentic AI Platform Blueprint

• 在 AWS 上运行生产级智能体 AI 的企业多账户架构（规范性指导）

• 在 Amazon Bedrock AgentCore 上构建企业级 Agentic AI 平台研讨会

• Amazon Bedrock AgentCore 文档

转载声明：本文为转载整理，原文版权归原作者及原站点所有。

原文来源：AWS Machine Learning Blog

原创地址：https://aws.amazon.com/blogs/machine-learning/building-an-agentic-ai-platform-on-amazon-bedrock-agentcore/