在 Amazon Bedrock AgentCore 上构建 Agentic AI 平台

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

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

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

Amazon Bedrock AgentCore 提供用于大规模构建、部署和运营 Agent 的模块化服务，包括 runtime、gateway、identity、memory、policy、registry 和 evaluations。基于 AgentCore 构建的 Enterprise Agentic AI Platform Blueprint以可部署的基础设施即代码的形式添加了周围的企业契约：所有权、账户边界、软件交付、可观测性、成本治理和退役。

架构原则

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

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

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

运营模型与平台组件

企业通常采用以下三种运营模型之一来管理代理式AI（agentic AI）：

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

根据我们在客户项目中观察到的模式，该蓝图实现了联邦式模型。平台团队是中心，通常由平台产品经理、架构师、平台工程师、代理运维工程师以及一名安全与治理负责人组成。工作流团队是分支，由代理开发人员、领域技术负责人和AI/ML工程师组成。高管发起人和CISO位于两者之上。

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

解决方案概览

该解决方案提供一个受治理的多账户代理式AI平台，由平台团队运营，并由内部产品与工程团队等工作流团队通过版本化的自助服务接口进行消费。

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

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

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

关键组件

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

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

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

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

解决方案演练

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

账户拓扑与组织单元

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

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

服务控制策略

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

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

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

带评估门的 CI/CD 流水线

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

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

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

安全与治理

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

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

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

结论

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

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

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

相关资源：

1. GitHub 上的 Enterprise Agentic AI Platform Blueprint
2. 在 AWS 上运行生产级 Agentic AI 的企业多账户架构（Prescriptive Guidance）
3. 在 Amazon Bedrock AgentCore 上构建企业级 Agentic AI 平台研讨会
4. Amazon Bedrock AgentCore 文档

关于作者