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

人工智能

在 Amazon Bedrock AgentCore 上构建 Agentic AI 平台

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

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

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

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

架构原则

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

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

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

运营模型和平台组件

企业通常为智能体 AI 采用以下三种运营模型之一：

集中式： 单个人工智能和机器学习 (AI/ML) 团队构建并运行每个智能体。治理是一致的，但随着用例数量的增长，该团队很快会成为瓶颈。
分散式： 每个业务部门构建并运营自己的智能体。团队可以快速行动，但如果没有共享标准，控制措施往往会偏移，工作会重复，成本可见性也会受到影响。
联邦式： 中央平台团队提供共享的受治理服务，而领域团队保留对其智能体、工具和数据的归属。该模型平衡了团队自主性与一致的防护机制，也是大多数企业最终采用的模式。
如需选择帮助，请参阅 AWS 规范性指导中关于治理模型的页面.

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

在该蓝图中，平台团队负责每个组件的定义：模板、版本、策略和准入。每个工作流账户运行自己的一套按团队划分的组件实例（运行时、内存、工具网关），因此故障或回滚都局限在一个团队的边界内。

解决方案概述

该解决方案提供一个受治理的多账户 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) 源链接。一个单元可以独立部署、失败、回滚或退役，无需与其他团队的发布协调。

关键组件

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

Operating model linking the governance foundation, Platform control plane, and team-owned Workstream cells

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

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

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

解决方案详解

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

账户拓扑和组织单位

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

角色	着陆区放置位置	用途
管理基础	根 / 安全与管理	Organizations、Identity Center、预防性策略、审计、保留和成本策略
安全与日志归档	安全	CloudTrail、AWS Config、Security Hub、GuardDuty 和保留的审计数据
可观测性	安全或运营	CloudWatch OAM 接收端以及机群日志、指标、跟踪和成本视图
Agentic AI 平台	智能体平台	黄金路径、AWS Agent Registry、Guardrails、推理网关、流水线和机群控制
工作流单元	智能体工作流	团队自有的运行时、内存、工具网关、工具、数据、评估和应用 SLO
额外的工作流单元	智能体工作流	按产品、领域、环境或受监管边界重复同一基线

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

服务控制策略

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

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

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

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

蓝图使用经过审查的平台和工作负载流水线来强制执行以下晋升顺序：

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

没有任何工作流部署步骤拥有人工快速通道。平台团队拥有发布契约，但工作流团队运营自己的流水线实例和部署节奏。退役遵循严格的依赖顺序：首先撤销平台别名授权，然后是工作流网关和工具角色，接着是运行时、内存和应用程序资源。每一步在继续之前都经过验证，最终清单确认零残余资源留存。

安全与治理

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

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

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

结论

在本文中，我们介绍了一个基于 Amazon Bedrock AgentCore 构建的企业级 Agentic AI 平台。该架构将集中治理的平台控制面与可重复、由团队自主负责的工作流单元分离，并设有独立的推理网关和工具网关，且生产环境的上线由已部署运行时评估进行门禁校验。

配套仓库包含一份蓝图，可对这些控制措施进行端到端验证，涵盖从流水线门禁、对抗性边界测试到零残余拆除的全过程。支持范围仅限于该经过测试的边界。

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