如何在 Amazon Bedrock AgentCore 上构建企业级 Agentic AI 平台

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

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

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

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

架构原则

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

1. 受治理的模型访问：每个不受信任的推理请求都必须经过经过批准的推理网关。网关应用组织的防护栏（例如 Amazon Bedrock Guardrails 或第三方提供商），限制每个 Workstream 可以使用的模型和推理 AWS 区域，并强制执行每 Workstream 的速率限制、令牌配额和预算，确保没有任何单一团队耗尽共享容量。它还携带工作负载身份并发出归因数据。
2. 受治理的工具访问：智能体必须通过经过身份验证的模型上下文协议（MCP）网关来发现和调用已批准的工具，具有精确的目标、最小权限执行角色、策略决策和可审计的所有者。
3. 委托交付：工作流团队（例如产品团队）需要在预先批准的边界内独立发布和回滚，而无需等待平台团队部署每个应用，也无需授予开发者直接写入基础设施的路径。
4. 舰队运维与成本：多个角色需要跨账户查看情况，但不能获得对团队工作负载的写权限。智能体运维工程师需要日志、指标、追踪和配额。工作流负责人需要按预算查看每个智能体的成本。FinOps 和财务团队需要通过 AWS Cost Explorer 和 AWS Cost and Usage Report (CUR) 按团队或业务部门进行成本分摊。安全与治理负责人需要哪个工作负载调用了哪个模型和工具的证据。
5. Bounded evidence and lifecycle: Every agent release needs proof at each boundary it touches:
   1. 模型访问：对已批准模型的调用成功，对未批准模型或区域的调用被拒绝。
   2. 工具访问：对已订阅工具的调用成功，对智能体订阅范围之外工具的调用被拒绝并返回预期错误。
   3. 身份：来自其他工作流账户或身份的请求被拒绝。
   4. 发布：可以恢复上一个智能体运行时版本。
   5. 退役：拆除操作按依赖顺序移除智能体的运行时、内存、工具网关和工具授权，并确认没有遗留任何内容。

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

运营模式与平台组件

企业通常采用以下三种 Agentic AI 运营模式之一：

• 集中式：由一个人工智能与机器学习（AI/ML）团队构建并运行所有智能体。治理是一致的，但随着用例数量增长，该团队很快会成为瓶颈。
• 分散式：每个业务部门构建并运营自己的智能体。团队可以快速行动，但在没有共享标准的情况下，管控往往会出现漂移，工作重复，成本可见性也会受损。
• 联邦式：中央平台团队提供共享的、受治理的服务，同时领域团队保留对其智能体、工具和数据的所有权。这种模式在团队自主性与一致的防护措施之间取得平衡，也是大多数企业最终采用的模式。
• 如需选择帮助，请参阅 AWS Prescriptive Guidance 关于治理模式的页面。

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

在此蓝图中，平台团队负责定义每个组件：模板、版本、策略和准入。每个 Workstream 账户运行各团队组件（Runtime、Memory、Tool Gateway）自己的实例，因此故障或回滚只会影响单个团队的边界内。

解决方案概览

该解决方案提供了一个受治理的多账户智能体 AI 平台（Agentic AI Platform），由平台团队运营，并由工作流团队（例如内部产品和工程团队）通过版本化的自助服务界面进行消费。

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

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

1. 智能体 AI 平台控制平面：平台账户发布版本化的模板和接口，运营 AWS Agent Registry 治理记录和共享的推理网关，准入模型和 Guardrails，编排经过审核的发布，并聚合机群信号。团队通过代码、描述符和管道来使用这些能力，而不是通过管理员会话或部署工单。
2. 可重复的 Workstream 单元：每个产品或领域都会获得一个隔离的边界，其中包含团队自有的源代码仓库、一个 Workload 管道，以及三项 Amazon Bedrock AgentCore 能力：AgentCore Runtime、按参与者划分作用域的 AgentCore Memory，以及一个使用 AWS_IAM 授权并仅暴露已批准工具目标的 AgentCore Gateway。该单元还包含本地的客户托管 AWS KMS 密钥、标签、告警、预算，以及一个 CloudWatch Observability Access Manager（OAM）源链接。一个单元可以独立部署、失败、回滚或退役，而无需与其他团队的发布进行协调。

关键组件

下图展示了该解决方案的运营模式和受治理的流程。

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

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

1. 管理与治理基础。AWS Organizations、AWS IAM Identity Center、预防性策略、审计、保留和成本策略确立了企业边界。这些是逻辑上的职责，可以映射到现有的 AWS Control Tower 着陆区，而无需重复的账户结构。
2. 安全、审计和可观测性层。AWS CloudTrail、AWS Config、AWS Security Hub、Amazon GuardDuty、日志归档，以及一个 Amazon CloudWatch OAM 汇聚点，可提供独立的控制平面证据和机群可见性。中央运维人员可以查询共享信号，而无需获得对 Workstream 资源的写入权限。
3. Agentic AI 平台的平台层。各独立的平台环境拥有黄金路径、治理目录、Guardrails、共享的推理网关、精确的工具别名、管道、兼容性、配额以及通用运维接口。平台变更在更大范围推广之前，先在代表性单元上测试。
4. 工作流舰队层。每个产品、领域或受监管边界都会获得一个或多个非生产与生产单元。团队拥有 Runtime、Memory、Tool Gateway、工具、数据、提示词、评估用例、应用事故以及服务级目标（SLO）。同一基线可以在多个单元中重复使用，同时保持账户级隔离。

方案演练

以下章节将梳理关键设计决策：账户拓扑、预防性与检测性控制、AgentCore 执行路径以及交付管道。

账户拓扑与组织单元

该蓝图定义了逻辑账户角色，将企业治理、共享平台服务与团队自有的执行环境分开：

该拓扑可集成到现有落地区（landing zone，即预先配置、安全且可扩展的 AWS 多账户环境）中，其中 Management、Platform 和 Workstream 标签描述的是职责，而非固定的三账户结构。组织可以运行多个经过验证的平台环境以及多对工作流账户。从单个代表性单元开始，先验证接入、生产晋升、回滚、集中可观测性以及零残留退役，然后再重复该基线。

服务控制策略

服务控制策略（SCP）约束 Platform 和 Workstream 账户可用的最大权限。它们是对 IAM、网关授权、Guardrails、资源策略、网络控制和管道证据的补充，而非替代。该蓝图会渲染并审查特定账户和 Region 的生效策略，而不是仅依赖源代码意图。

1. 模型与 Region 准入：组织策略和网关执行角色将推理限制在已批准的模型和受支持的 Region 内。新增模型或 Region 需要验证服务可用性、数据驻留、IAM、质量、成本、回滚、可观测性以及拒绝行为。
2. Guardrail 与推理强制执行：智能体不直接调用模型提供商。推理必须经过受治理的网关，在那里应用阶段级 Guardrail 和模型允许列表。
3. 仅限管道的工作流（Workstream）变更：Workstream 团队通过拉取请求并使用 Workload 管道。开发人员直接部署到 Workstream 账户不受支持的运营模式支持，这确保了已评审的发布和证据路径无法被绕过。
4. 注册表（Registry）与网关（Gateway）治理：当订阅的 Registry 记录缺失、变更或未获批准时，Workstream Gateway 合成将失败。
5. 范围受限的部署角色：引导策略按账户和区域生成，通过 AWS Identity and Access Management Access（IAM）Analyzer 验证，并通过有效策略模拟进行检查。管理员访问权限仅保留用于初始设置，而非日常管道执行。
6. 职责分离与对抗性验证：平台团队控制模型、Guardrail、Registry 和共享服务的准入。Workstream 团队控制应用行为。每条被拒绝的路径都配有一次授权的正向调用和一次变更，用以证明是预期的控制导致了拒绝。

Workstream 账户内的管理员无法创建绕过这些控制的受支持的捷径。新增或变更的组织策略在大范围附加之前，需要在沙箱或代表性单元中进行浸泡验证、精确的允许和拒绝测试，并制定回滚计划。

带评估门禁的 CI/CD 管道

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

1. 源码与评审：拉取请求确定不可变的源代码修订版本。管道固定目标分支，因此未合并的变更无法悄悄构建仓库的默认分支。
2. 构建与合成：管道编译代码、运行测试和 lint、创建智能体清单、扫描摘要绑定的镜像、验证策略、解析已批准的 Registry 描述符，并检查合成后的 AWS CloudFormation 和 cdk-nag 输出。
3. 稳定角色与权限交接：Workload 管道创建稳定的 Workstream 角色并暂停。Platform 管道向确切的 Gateway 角色授予确切的工具别名，实时策略经验证后，Workload 管道才会继续。
4. 部署到非生产环境：管道将 Runtime、Memory、Tool Gateway、可观测性、告警、预算、标签和应用资源部署到该单元的非生产边界内。
5. 评估已部署的智能体：门禁调用真实的 Runtime，并衡量回归、质量、工具成功率、拒绝行为、首字延迟和成本。每次授权调用都配有一个对抗性孪生调用：门禁调用一个已批准的模型并确认成功，然后调用一个未批准的模型并确认被拒绝。相同的模式适用于工具、跨账户身份和限流。如果缺少预期的拒绝，门禁将使构建失败。
6. 人工审批：评审人员检查已部署的证据、已知局限和残余风险。当缺少必要的探针、资源或预期拒绝时，仅仅构建通过是不够的。
7. 晋升、观察与回滚：生产晋升使用经过评审的修订版本和连续性检查。在更新、取消、回滚、恢复和重新运行过程中对 Runtime 会话进行采样，以便管道同时验证前进路径和恢复路径。

没有任何 Workstream 部署步骤提供人工快速通道。Platform 团队负责发布契约，但 Workstream 团队自行运营各自的流水线实例和部署节奏。退役遵循严格的依赖顺序：先撤销 Platform 别名授权，然后是 Workstream Gateway 和工具角色，再是 Runtime、Memory 和应用资源。每一步在继续之前都要经过验证，最后的盘点确认没有残留资源。

安全与治理

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

1. 身份与信任边界：Amazon Bedrock AgentCore 的一项能力 AgentCore Identity 以及 Amazon Cognito 提供短时效的推理凭证。AWS_IAM 和 SigV4 对工具流量进行身份验证。精确的 Runtime 和 Gateway 角色、签发者与受众检查、账户与区域上下文，以及限定范围的 bootstrap 信任，将每个主体限制在其预期路径内。
2. 模型安全与准入：推理流量经过解决方案概述中所述的受治理网关，在每次调用之前应用 Guardrails 和模型允许列表。
3. 工具授权：Tool Gateway 仅调用 Registry 批准的别名，详见解决方案概述。Cedar 策略提供授权，并保留一个 AWS Lambda 包装器以实现纵深防御。
4. 租户数据保护：Workstream 账户隔离应用状态。AgentCore memory 使用按 actor 划分作用域的命名空间和客户托管的 KMS 密钥。工具和应用数据保持由团队所有，保留、删除和访问策略是显式定义的，而不是从共享的可变工作负载账户继承。
5. 软件供应链与发布：经过评审的源代码、清单哈希、可复现构建、与摘要绑定的镜像扫描、策略验证、cdk-nag 检查、已部署运行时评估、人工审批、回滚，以及按依赖顺序的拆除，共同构成一份发布契约。任何缺失的检查都会导致失败关闭。
6. 审计、可观测性与成本治理：CloudTrail 和保留的控制平面数据可佐证流水线证据。OAM 与中央运营人员共享日志、指标和追踪。标准分配标签、预算、配额以及 AWS Cost and Usage Report 对账明确了归属，同时不给智能体重写自身归因的权限。

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

结论

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

配套仓库包含一个蓝图，可端到端验证这些控制措施，从流水线门禁和对抗性边界测试到零残留拆除。支持声明仅限于这个经过测试的边界之内。

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

相关资源：

1. GitHub 上的企业级智能体 AI 平台蓝图
2. 在 AWS 上生产环境运行智能体 AI 的企业多账户架构（规范性指导）
3. 在 Amazon Bedrock AgentCore 上构建企业级智能体 AI 平台研讨会
4. Amazon Bedrock AgentCore 文档

关于作者