[Amazon Bedrock] 在 Amazon Bedrock AgentCore 上构建 agentic AI 平台

人工智能

在 Amazon Bedrock AgentCore 上构建 agentic AI 平台

如果你试过把 agent 推进生产环境，模型和工具使用并不是拦路石。真正的瓶颈是它们周围的一切：有多少团队能在安全环境里做开发、每个模型和工具归哪个团队、AgentOps 和错误处理如何守在预先划定的边界内，以及平台、Workstream 和财务团队如何跨账户查看成本与健康状况。对一个想支撑多种 agentic 用例的 Platform 团队来说，这是一件需要设计和运营的平台产品。在本文中，我们把管理该平台的团队称为 Platform 团队，把基于它构建的团队称为 Workstream 团队。Workstream 团队就是在平台上构建并拥有 agent 的领域团队或产品团队。

每个 Workstream 团队都需要一条铺好的路：获批的模型和工具、短期的工作负载身份、隔离的 runtime 和 memory、自动化的评估、回滚、遥测，以及成本归属。这些控制措施必须在 Workstream 团队定制 prompt、工具、数据访问和应用行为时保持一致。一旦每个团队都自己拼装，控制就会漂移，共享服务变成瓶颈，归属关系也难以审计。

在本文中，我们一步步讲清在 Amazon Bedrock 和 Amazon Bedrock AgentCore 上构建企业级 agentic AI 平台的架构与参考实现。我们会覆盖多账户运营模型、Platform 控制平面、可复制的按 Workstream 部署模式、相互独立的推理与工具网关，以及一条在每个 agent 晋级生产之前设卡关的评估流水线。读完本文，你应该能够从配套 blueprint 部署一个受治理的 Workstream，验证它的安全与生命周期契约，并把它作为组织内自建 agentic AI 平台的基础。

Amazon Bedrock AgentCore 提供了用于大规模构建、部署和运营 agent 的模块化服务，包括 runtime、gateway、identity、memory、policy、registry 和 evaluations。建立在 AgentCore 之上的 Enterprise Agentic AI Platform Blueprint，把这些企业级契约也补成可部署的基础设施即代码：归属、账户边界、软件交付、可观测性、成本治理和退役。

架构原则

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

受治理的模型访问： 每一次不受信任的推理请求都必须经过获批的推理网关。网关会套用组织的 guardrail（例如 Amazon Bedrock Guardrails 或第三方 provider），限制每个 Workstream 可用的模型和推理 AWS 区域，并强制执行按 Workstream 计的速率限制、token 配额和预算，避免任何单个团队耗尽共享容量。它还承载工作负载身份，并输出归属数据。 受治理的工具访问： agent 只能通过经过认证的 Model Context Protocol (MCP) 网关发现和调用获批工具，并配有精确的 target、最小权限的执行角色、策略决策和可审计的负责人。 委派式交付： Workstream 团队（比如产品团队）需要能在预先批准的边界内独立发布和回滚，既不用等平台团队替他们部署每个应用，也不用给开发者直接写基础设施的通道。 集群运营与成本： 多类角色需要跨账户的可见性，但不应获得对团队工作负载的写权限。Agent 运维工程师需要日志、指标、链路追踪和配额。Workstream 负责人需要每个 agent 对照预算的成本。FinOps 和财务团队需要通过 AWS Cost Explorer 和 AWS Cost and Usage Report (CUR) 按团队或业务单元做成本分摊。安全与治理负责人需要证据，证明是哪个工作负载调用了哪个模型和工具。 有边界的证据与生命周期： 每次 agent 发布，都需要在它触碰到的每个边界上留下证明： Model access： 调用获批模型成功，调用未获批的模型或区域被拒绝。Tool access： 调用已订阅的工具成功，调用 agent 订阅范围之外的工具则以预期错误被拒绝。Identity： 来自其他 workstream 账户或身份的请求被拒绝。Release： 之前的 agent runtime 版本可以恢复。Retirement： 拆除过程按依赖顺序移除 agent 的 runtime、memory、tool gateway 和工具授权，并确认没有残留。

blueprint 通过四个相互衔接的平面来回应这些需求：开发者体验、平台控制、Workstream 执行，以及保障与运营。扩展的单位是 Workstream 单元，而不是手工配置的 agent 或共享的单一工作负载账户。blueprint 的 README 详细记录了每个平面的职责。而你会在后面的段落里读到两个主要平面：Agentic AI Platform 控制平面和可复制的 Workstream 单元。

运营模型与平台组件

企业在 agentic AI 上通常会采用以下三种运营模型之一：

集中式： 由单一的一个人工智能与机器学习（AI/ML）团队构建并运行所有 agent。治理是一致的，但随着用例数量增长，这个团队很快会成为瓶颈。 去中心化： 每个业务单元各自构建并运营自己的 agent。团队可以推进很快，但如果没有统一标准，控制措施容易漂移、投入重复、成本可见性变差。 联邦式： 中心的 Platform 团队提供共享且受治理的服务，领域团队仍保有自己 agent、工具和数据的归属权。这种模式在团队自主性与一致的 guardrail 之间取得平衡，也是多数企业最终落脚的形态。 需要选择建议的话，可以参考 AWS Prescriptive Guidance 中关于治理模型的页面。

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

在这个 blueprint 中，Platform 团队拥有每个组件的定义：模板、版本、策略和准入。每个 Workstream 账户各自运行一份按团队划分的组件实例（Runtime、Memory、Tool Gateway），因此故障或回滚都留在单个团队的边界内。

方案概览

本方案交付的是一个受治理的多账户 agentic AI 平台：由平台团队运营，Workstream 团队（比如内部的产品和工程团队）则通过带版本的自助接口来使用它。

在企业规模下，开发者体验平面就是一份组织认可、带版本的 agent 模板目录。blueprint 提供了 Strands、LangGraph 和 CrewAI 的参考模板，但只要模板保持相同的推理网关、工具网关、身份、策略、评估和交付契约，你也可以用自选的框架。应用团队拥有 prompt、agent 逻辑、工具和评估用例。Platform 团队拥有通用控制措施和发布要求。

四个平面中，有两个承载了架构的主体：

Agentic AI Platform 控制平面： Platform 账户发布带版本的模板和接口，运营 AWS Agent Registry 的治理记录和共享的 Inference Gateway，负责模型与 Guardrails 的准入，编排经过评审的发布，并汇聚集群信号。团队通过代码、描述符和流水线来消费这些能力，而不是靠管理员会话或部署工单。 可复制的 Workstream 单元： 每个产品或领域都会获得一个隔离的边界，其中包含团队自有的源码仓库、一条 Workload 流水线，以及三项 Amazon Bedrock AgentCore 能力：AgentCore Runtime、按 actor 划分的 AgentCore Memory，以及一个使用 AWS_IAM 授权、只暴露获批工具 target 的 AgentCore Gateway。该单元还持有本地的客户托管 AWS KMS 密钥、标签、告警、预算，以及一个 CloudWatch Observability Access Manager (OAM) source link。一个单元的部署、故障、回滚或退役，都不必与另一个团队的发布协调。

关键组件

下面的示意图展示了本方案的运营模型和受治理的流转。

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

架构由以下账户层构成：

管理与治理基础。 AWS Organizations、AWS IAM Identity Center、预防性策略、审计、保留策略和成本策略共同确立企业边界。这些是逻辑职责，可以映射到已有的 AWS Control Tower landing zone，而不要求另建一套重复的账户结构。 安全、审计与可观测性层。 AWS CloudTrail、AWS Config、AWS Security Hub、Amazon GuardDuty、日志归档和一个 Amazon CloudWatch OAM sink 提供独立的控制平面证据和集群可见性。中央运维人员可以查询共享信号，而不会获得对 Workstream 资源的写权限。 Agentic AI Platform 的平台层。 相互独立的 Platform 环境各自拥有黄金路径、治理目录、Guardrails、共享的 Inference Gateway、精确的工具别名、流水线、兼容性、配额和通用运维接口。Platform 的变更会先在有代表性的单元上测试，然后才推广。 Workstream 集群层。 每个产品、领域或受监管边界都会获得一个或多个非生产和生产单元。团队拥有 Runtime、Memory、Tool Gateway、工具、数据、prompt、评估用例、应用事故和服务水平目标（SLOs）。同一套基线可以在许多单元上重复，同时保持账户级隔离。

方案详解

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

账户拓扑与组织单元

blueprint 定义了若干逻辑账户角色，把企业治理、共享的 Platform 服务和团队自有的执行分开：

角色landing zone 位置用途 管理基础根账户 / Security and ManagementOrganizations、Identity Center、预防性策略、审计、保留策略和成本策略 安全与日志归档SecurityCloudTrail、AWS Config、Security Hub、GuardDuty 以及留存的审计数据 可观测性Security 或 OperationsCloudWatch OAM sink 以及集群日志、指标、链路追踪和成本视图 Agentic AI PlatformAgent Platform黄金路径、AWS Agent Registry、Guardrails、Inference Gateway、流水线和集群控制 Workstream 单元Agent Workstreams团队自有的 Runtime、Memory、Tool Gateway、工具、数据、评估和应用 SLOs 其他 Workstream 单元Agent Workstreams按产品、领域、环境或受监管边界重复同一套基线

这套拓扑可以融入已有的 landing zone，也就是一个预先配置好、安全且可扩展的多账户 AWS 环境；其中 Management、Platform 和 Workstream 这些标签描述的是职责，而不是固定的三账户架构。一个组织可以运营多个经过验证的 Platform 环境和多对 Workstream 账户。先从一个有代表性的单元开始，把接入、生产晋级、回滚、集中可观测性和零残留退役都验证一遍，再复制这套基线。

服务控制策略

服务控制策略限定 Platform 账户和 Workstream 账户可用的最大权限。它们是 IAM、网关授权、Guardrails、资源策略、网络控制和流水线证据的补充，而不是替代。blueprint 会针对具体账户和区域渲染并评审实际生效的策略，而不是只依赖源码里的意图。

模型与区域准入： 组织策略和 Gateway 执行角色把推理限制在获批的模型和受支持的区域内。新增一个模型或区域，需要验证服务可用性、数据驻留、IAM、质量、成本、回滚、可观测性和拒绝行为。 Guardrail 与推理的执行： agent 不直接调用模型 provider。推理要经过受治理的网关，在那里套用阶段性 Guardrail 和模型允许列表。 只允许通过流水线变更 Workstream： Workstream 团队提交 pull request 并使用 Workload 流水线。开发者直接向 Workstream 账户部署不在受支持的运营模型之内，这让经过评审的发布与证据路径无法被绕过。 Registry 与 Gateway 治理： 当已订阅的 Registry 记录缺失、被改动或未获批时，Workstream Gateway 的合成会失败。 受限范围的部署角色： Bootstrap 策略按账户和区域生成，用 AWS Identity and Access Management Access (IAM) Analyzer 校验，并通过实际生效策略的模拟来检查。管理员访问权限只保留给初始搭建，而不是日常流水线执行。 职责分离与对抗性验证： Platform 控制模型、Guardrail、Registry 和共享服务的准入。Workstream 团队控制应用行为。每一条被拒绝的路径都配有一次获授权的正向调用，以及一次能证明预期控制确实导致了拒绝的变更。

Workstream 账户内的管理员无法绕开这些控制走出一条受支持的捷径。新增或修改组织策略，需要先在沙箱或有代表性的单元上做一段时间的观察，再做精确的允许与拒绝测试，并准备好回滚方案，然后才能大范围挂载。

带评估关卡的 CI/CD 流水线

blueprint 用经过评审的 Platform 流水线和 Workload 流水线来强制执行下面的晋级顺序：

源码与评审： pull request 确立不可变的源码版本。流水线会锁定预期的分支，这样未合并的改动就不会悄悄按仓库默认分支来构建。 构建与合成： 流水线编译代码、运行测试和 lint、生成 agent manifest、扫描按 digest 绑定的镜像、校验策略、解析获批的 Registry 描述符，并检查合成的 AWS CloudFormation 和 cdk-nag 输出。 稳定角色与权限交接： Workload 流水线创建稳定的 Workstream 角色后暂停。Platform 流水线把精确的工具别名授予精确的 Gateway 角色，实际生效的策略得到验证，然后 Workload 流水线才继续。 部署到非生产环境： 流水线把 Runtime、Memory、Tool Gateway、可观测性、告警、预算、标签和应用资源部署到该单元的非生产边界内。 评估已部署的 agent： 关卡会调用真实的 Runtime，测量回归、质量、工具成功率、拒答行为、首 token 延迟和成本。每次获授权的调用都配一个对抗孪生调用：关卡先调用获批模型并确认成功，再调用未获批模型并确认被拒绝。相同的模式也适用于工具、跨账户身份和限流。如果预期的拒绝没有出现，关卡就判定构建失败。 人工批准： 评审者查看已部署的证据、已知限制和残留风险。当必需的探针、资源或预期拒绝缺失时，一个泛泛的绿色构建是不够的。 晋级、观察与回滚： 生产晋级使用经过评审的版本并做连续性检查。Runtime 会话会经过更新、取消、回滚、恢复和重跑的抽样测试，让流水线同时证明前进路径和恢复路径。

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

安全与治理

blueprint 通过相互加固的身份、策略、交付、数据和证据控制来实现纵深防御：

身份与信任边界： AgentCore Identity（Amazon Bedrock AgentCore 的一项能力）和 Amazon Cognito 提供短期的推理凭证。AWS_IAM 和 SigV4 对工具流量做认证。精确的 Runtime 与 Gateway 角色、签发方与接收方校验、账户和区域上下文，以及受限范围的 bootstrap 信任，把每个主体限制在它应有的路径上。 模型安全与准入： 推理流经方案概览中描述的受治理网关，每次调用前都会套用 Guardrails 和模型允许列表。 工具授权： Tool Gateway 只调用 Registry 批准的别名，细节见方案概览。授权由 Cedar 策略提供，并保留一个 AWS Lambda 包装层用于纵深防御。 租户数据保护： Workstream 账户隔离应用状态。AgentCore memory 使用按 actor 划分的命名空间和客户托管的 KMS 密钥。工具和应用数据仍归团队所有，保留、删除和访问策略都是显式声明的，而不是从一个共享且可变的工作负载账户继承而来。 软件供应链与发布： 经过评审的源码、manifest 哈希、可复现构建、按 digest 绑定的镜像扫描、策略校验、cdk-nag 检查、已部署 runtime 的评估、人工批准、回滚，以及按依赖顺序的拆除，共同构成一份发布契约。任何一项检查缺失都按失败处理。 审计、可观测性与成本治理： CloudTrail 和留存的控制平面数据可与流水线证据互相印证。OAM 把日志、指标和链路追踪共享给中央运维人员。标准的分配标签、预算、配额以及 AWS Cost and Usage Report 的对账共同确定归属，而不会给 agent 改写自身归属的权限。

这个仓库是一份参考实现。开发者可以按自己的需求调整。部署方式和可用功能都基于 eu-west-1（爱尔兰）区域。替换组件、换用其他区域，或在更大范围内推广到组织，都需要各自提供可用性、安全性、负载、回滚、可观测性和拆除方面的证据。

结论

在本文中，我们走查了建立在 Amazon Bedrock AgentCore 之上的企业级 agentic AI 平台。这套架构把集中治理的 Platform 控制平面与可复制、团队自有的 Workstream 单元分开，推理网关和工具网关也彼此独立，生产晋级则由已部署 runtime 的评估来把关。

配套仓库里包含一份 blueprint，端到端地验证这些控制，从流水线关卡、对抗性边界测试一直到零残留拆除。支持声明也止步于这个经过测试的边界。

要开始上手，就从配套仓库部署一个有代表性的 Workstream 单元，验证它的完整生命周期，然后再从同一套带版本的基线自动部署更多单元。

相关资源：

GitHub 上的 Enterprise Agentic AI Platform Blueprint 在 AWS 上于生产环境运行 agentic AI 的企业多账户架构（Prescriptive Guidance） 在 Amazon Bedrock AgentCore 上构建企业级 agentic AI 平台的 Workshop Amazon Bedrock AgentCore 文档

关于作者