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

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

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

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

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

架构原则

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

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

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

运营模式与平台组件

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

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

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

在此蓝图里，平台团队负责定义每个组件：模板、版本、策略和准入。每个 Workstream 账户运行自己的一套按团队划分的组件实例（Runtime、Memory、Tool Gateway），因此故障或回滚都局限在一个团队的边界内。

解决方案概览

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

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

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

1. Agentic 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：企业 Agentic 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. 工作流集群层。每个产品、领域或受监管边界都会获得一个或多个非生产与生产单元。团队负责运行时、内存、工具网关、工具、数据、提示词、评估用例、应用事件以及服务级别目标（SLO）。同一基线可以在多个单元中重复使用，同时保持账户级隔离。

解决方案走查

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

账户拓扑与组织单元

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

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

服务控制策略

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

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

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

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

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

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

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

安全与治理

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

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

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

结论

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

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

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

相关资源：

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

关于作者

Omar Elkharbotly

Omar 是 AWS 的高级 GenAI/ML 专业解决方案架构师。他与英国和爱尔兰各地的企业客户合作，使用 Amazon Bedrock 和 Amazon Bedrock AgentCore 设计和部署生成式 AI 与机器学习解决方案，以构建可扩展、可用于生产的应用程序。

Mia Chang

Mia 是常驻德国柏林的 Agentic AI 专业解决方案架构师。她帮助 EMEA 各地的企业客户设计、运营和扩展 Agentic AI 工作负载，从最初的智能体到在托管平台上投入生产，以及采用自管理基础设施的混合架构。她的专业领域涵盖智能体应用架构、智能体安全与治理、负责任 AI 以及平台工程。

Siva Shanmugam

Siva 是 Amazon Web Services 的高级解决方案架构师，专精于 AI/ML、数据和云原生架构。他的专业领域涵盖生成式与 Agentic AI 应用、开发者体验转型——包括 Agentic Coding 和 AI 驱动的工程实践——以及端到端企业云解决方案。