Building an Agentic AI Platform on Amazon Bedrock AgentCore

在 Amazon Bedrock AgentCore 上构建 Agentic AI 平台 | 人工智能

在 Amazon Bedrock AgentCore 上构建 Agentic AI 平台

如果你尝试将智能体投入生产环境，模型和工具的使用通常不是瓶颈。真正的关键挑战在于围绕它们的各个方面：有多少团队能够在安全环境中进行开发，每个模型和工具由哪个团队负责，AgentOps 和错误处理如何在预定义边界内运行，以及平台、工作流和财务团队如何跨账户查看成本和健康状况。对于希望支持多种智能体用例的平台团队而言，这需要设计和运营一个平台产品。在本文中，我们将管理平台的团队称为平台团队，而基于平台构建的团队称为工作流团队。工作流团队是负责在平台上构建和拥有智能体的领域或产品团队。

每个工作流团队都需要一条经过批准的模型和工具路径，包括短暂的负载身份、隔离的运行时和内存、自动化评估、回滚、遥测和成本归属。这些控制机制需要在工作流团队自定义提示、工具、数据访问和应用行为时保持一致性。当每个团队自行组装这些组件时，控制机制会逐渐偏离，共享服务成为瓶颈，且所有权难以审计。

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

Amazon Bedrock AgentCore 提供了构建、部署和规模化运营智能体的模块化服务，包括运行时、网关、身份、内存、策略、注册表和评估功能。基于 AgentCore 构建的企业级 Agentic AI 平台蓝图，将围绕的企业的合同作为可部署的基础设施代码进行扩展：所有权、账户边界、软件交付、可观测性、成本治理和退役管理。

架构原则

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

• 受控模型访问：每个未经信任的推理请求必须通过批准的推理网关。网关应用组织的防护措施（例如 Amazon Bedrock 防护措施或第三方供应商），限制每个工作流可使用的模型和推理 AWS 区域，并实施按工作流的速率限制、令牌配额和预算，以防止任何单一团队耗尽共享资源。它还携带工作负载身份并生成归属数据。

• 受控工具访问：智能体必须通过经过身份验证的模型上下文协议（MCP）网关，仅发现和调用批准的工具，具有精确的目标、最小权限执行角色、策略决策和可审计的所有者。

• 委托交付：工作流团队（例如产品团队）需要在预先批准的范围内独立进行发布和回滚，而无需等待平台团队部署每个应用程序，或为开发人员提供直接的基础设施写入路径。

• 机队运营和成本：多个角色需要跨账户的可见性，而无需获得团队工作负载的写入权限。代理运维工程师需要日志、指标、追踪和配额。工作流负责人需要了解每个代理的成本是否符合预算。FinOps 和财务团队需要通过 AWS Cost Explorer 和 AWS Cost and Usage Report (CUR) 按团队或业务单元进行费用分摊。安全和治理负责人需要证明哪些工作负载调用了哪些模型和工具。

• 有界证据和生命周期：每个代理发布都需要在接触的每个边界上提供证明：模型访问：经批准的模型调用成功，未经批准的模型或区域调用被拒绝。工具访问：已订阅的工具调用成功，代理订阅范围外的工具调用会返回预期错误。身份验证：来自其他工作流账户或身份的请求被拒绝。发布：可以恢复上一个代理运行时版本。退役：按依赖顺序拆除代理运行时、内存、工具网关和工具授权，并确认没有遗留任何内容。

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

运营模式和平台组件

企业通常采用三种运营模式之一来部署代理 AI：

• 集中式：一个单一的人工智能和机器学习（AI/ML）团队构建并运行每个代理。治理保持一致，但随着用例数量的增长，该团队会迅速成为瓶颈。

• 分散式：每个业务单元构建并运营自己的代理。团队可以快速行动，但缺乏共享标准会导致控制措施偏离、重复劳动和成本可见性下降。

• 联邦式：一个中央平台团队提供共享的受控服务，而领域团队保留其代理、工具和数据的所有权。这种模式在团队自主性和一致的防护措施之间取得平衡，也是大多数企业最终采用的模式。

• 如需帮助选择，请参阅 AWS Prescriptive Guidance 页面上的治理模式。

根据我们在客户合作中观察到的模式，该蓝图实现了联邦模式。平台团队是中心，通常由平台产品经理、架构师、平台工程师、代理运维工程师和安全与治理负责人组成。工作流团队是外围，由代理开发人员、领域技术负责人和 AI/ML 工程师组成。执行赞助人和首席信息安全官位于两者之上。

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

解决方案概览

该解决方案提供了一个受控的多账户智能代理AI平台，由平台团队负责运营，内部产品和工程等工作流团队则通过版本化的自助服务接口进行使用。

在企业级规模下，开发者体验平面是组织批准的版本化代理模板目录。该蓝图提供了Strands、LangGraph和CrewAI的参考模板，但当模板保持相同的推理网关、工具网关、身份、策略、评估和交付合同时，您也可以选择使用其他框架。应用团队负责提示词、代理逻辑、工具和评估案例。平台团队负责通用控制功能和发布要求。

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

• 智能代理AI平台控制平面：平台账户发布版本化模板和接口，运营AWS代理注册表治理记录和共享推理网关，接收模型和防护措施，协调审核后的发布，并汇总舰队信号。团队通过代码、描述符和流水线而非管理员会话或部署工单来使用这些能力。

• 可重复的工作流单元：每个产品或领域都会获得一个隔离的边界，包含团队拥有的源代码仓库、工作负载流水线，以及三个Amazon Bedrock AgentCore功能：AgentCore运行时、Actor作用域的AgentCore内存，以及使用AWS_IAM授权并仅暴露已批准工具目标的AgentCore网关。该单元还包含本地客户管理的AWS KMS密钥、标签、警报、预算，以及CloudWatch可观测性访问管理器（OAM）源链接。一个单元可以独立部署、失败、回滚或退役，而无需与其他团队的发布进行协调。

关键组件

下图展示了该解决方案的操作模型和受控流程。

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

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

• 管理与治理基础层：AWS Organizations、AWS IAM Identity Center、预防性策略、审计、保留和成本策略建立了企业边界。这些是逻辑责任，可以映射到现有的AWS Control Tower落地区，而无需重复的账户结构。

• 安全、审计和可观测性层：AWS CloudTrail、AWS Config、AWS Security Hub、Amazon GuardDuty、日志归档和Amazon CloudWatch OAM汇点提供独立的控制平面证据和舰队可见性。中央操作员可以查询共享信号，而无需获得工作流资源的写入权限。

• 智能代理AI平台平台层：独立的平台环境拥有黄金路径、治理目录、防护措施、共享推理网关、精确的工具别名、流水线、兼容性、配额和通用操作接口。平台变更在大规模推广前会针对代表性单元进行测试。

• 工作流舰队层。每个产品、领域或受监管边界会分配一个或多个非生产环境和生产环境单元。团队拥有运行时、内存、工具网关、工具、数据、提示、评估案例、应用程序事件和服务级别目标（SLOs）。相同的基线可以跨多个单元重复使用，同时保持账户级别的隔离性。

解决方案概述

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

账户拓扑与组织单元

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

| 角色 | 落地区位置 | 目的 | |------|------------|------| | 管理基础 | 根账户/安全与管理 | 组织、身份中心、预防性策略、审计、保留策略和成本策略 | | 安全与日志归档 | 安全 | CloudTrail、AWS Config、Security Hub、GuardDuty 和保留的审计数据 | | 可观测性 | 安全或运维 | CloudWatch OAM 汇总点和舰队日志、指标、追踪及成本视图 | | 代理AI平台 | 代理平台 | 金路径、AWS代理注册表、防护措施、推理网关、管道和舰队控制 | | 工作流单元 | 代理工作流 | 团队拥有的运行时、内存、工具网关、工具、数据、评估和应用程序SLOs | | 其他工作流单元 | 按产品、领域、环境或受监管边界重复相同基线 |

此拓扑结构可集成到现有落地区中，即预配置的、安全的、可扩展的多账户AWS环境。其中“管理”、“平台”和“工作流”标签描述的是职责而非固定的三账户架构。组织可以运营多个经过验证的平台环境和许多工作流账户对。建议从一个代表性单元开始，验证入职流程、生产推广、回滚、集中可观测性和零残留退役流程后，再重复基线。

服务控制策略

服务控制策略限制平台和工作流账户可获得的最大权限。它们是对IAM、网关授权、防护措施、资源策略、网络控制和管道证据的补充而非替代。蓝图会为特定账户和区域生成并审查实际生效的策略，而非仅依赖源代码意图。

• 模型与区域准入：组织策略和网关执行角色限制推理仅限于批准的模型和受支持区域。新增模型或区域需要验证服务可用性、驻留性、IAM权限、质量、成本、回滚、可观测性和拒绝策略。
• 防护措施与推理执行：代理不直接调用模型提供方。推理需通过受控网关，此时会应用阶段防护措施和模型白名单。
• 仅限管道的工作流变更：工作流团队通过提交拉取请求并使用工作负载管道进行变更。直接开发者部署到工作流账户超出支持的操作模型范围，这确保了已审查的发布流程和证据路径不可绕过。
• 注册表与网关治理：当订阅的注册表记录缺失、变更或未获批准时，工作流网关合成会失败。

• 作用域限定的部署角色：引导策略按账户和区域生成，通过 AWS Identity and Access Management Access (IAM) Analyzer 验证，并通过有效策略模拟进行检查。管理员权限仅保留用于初始设置，而非常规流水线执行。

• 职责分离与对抗性验证：平台控制模型、防护栏、注册表和共享服务准入机制由平台团队管理。工作流团队控制应用行为。每个被拒绝的路径都会配对一个授权的正向调用和一个证明预期控制导致拒绝的变更操作。

工作流账户内的管理员无法绕过这些控制创建受支持的快速通道。新增或修改的组织策略需要经过沙箱环境或代表单元的浸泡测试、精确的允许/拒绝测试以及回滚计划，才能进行广泛部署。

带评估门的 CI/CD 流水线

该蓝图使用经过审核的平台和工作负载流水线，强制执行以下升级序列：

• 源码与审核：拉取请求确立不可变的源码版本。流水线固定目标分支，防止未合并的变更静默构建仓库默认分支。

• 构建与合成：流水线编译代码，运行测试和代码检查，生成代理清单，扫描绑定摘要的镜像，验证策略，解析已批准的注册表描述符，并检查合成后的 AWS CloudFormation 和 cdk-nag 输出。

• 稳定角色与权限交接：工作负载流水线创建稳定的工作流角色并暂停。平台流水线向网关角色授予精确的工具别名，实时策略经过验证后，工作负载流水线才会继续执行。

• 部署至非生产环境：流水线将运行时、内存、工具网关、可观测性、告警、预算、标签和应用资源部署到单元的非生产边界。

• 评估已部署代理：门禁机制调用真实运行时，测量回归、质量、工具成功率、拒绝行为、首次令牌延迟和成本。每个授权调用都会配对一个对抗性镜像：门禁机制调用已批准模型并确认成功，再调用未批准模型并确认拒绝。相同模式适用于工具、跨账户身份和限流。如果预期的拒绝缺失，门禁机制将终止构建。

• 人工审批：审核人员检查已部署的证据、已知限制和残留风险。当缺少必要探针、资源或预期拒绝时，通用绿色构建结果不足以通过审批。

• 升级、观察与回滚：生产环境升级使用已审核的版本和连续性检查。通过更新、取消、回滚、恢复和重新运行采样运行时会话，流水线同时证明正向路径和恢复路径。

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

安全与治理

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

• 身份与信任边界：AgentCore Identity（Amazon Bedrock AgentCore 的一项功能）与 Amazon Cognito 提供短期推理凭证。AWS_IAM 和 SigV4 用于验证工具流量。精确的运行时和网关角色、签发者与受众检查、账户和区域上下文以及范围限定的启动信任机制，可将每个主体限制在其预期的路径内。

• 模型安全与准入：推理流量通过解决方案概述中描述的受控网关，每次调用前均会应用防护措施和模型白名单。

• 工具授权：工具网关仅调用注册中心批准的别名，如解决方案概述中所述。Cedar 策略提供授权，并保留 AWS Lambda 包装器以实现纵深防御。

• 租户数据保护：Workstream 账户隔离应用状态。AgentCore 内存使用基于角色的作用域命名空间和客户管理的 KMS 密钥。工具和应用数据保持团队所有，保留、删除和访问策略是显式定义的，而非从共享的可变工作负载账户继承。

• 软件供应链与发布：经过审查的源代码、清单哈希、可重现构建、基于摘要的镜像扫描、策略验证、cdk-nag 检查、部署运行时评估、人工审批、回滚和依赖顺序的拆除构成一个发布合同。缺少任一检查将导致发布失败。

• 审计、可观测性与成本治理：CloudTrail 和保留的控制平面数据可验证流水线证据。OAM 将日志、指标和追踪信息共享给中央操作员。标准分配标签、预算、配额和 AWS 成本与使用报告对账可明确所有权，而不会授予代理重写自身归属信息的权限。

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

结论

在本文中，我们介绍了基于 Amazon Bedrock AgentCore 的企业级智能体 AI 平台。架构将中央管控的平台控制平面与可重复使用的、团队拥有的 Workstream 单元分离，通过独立的推理和工具网关实现隔离，并通过部署运行时评估控制生产环境的推广。

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

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

相关资源：

• GitHub 上的企业级智能体 AI 平台蓝图

• AWS 上运行智能体 AI 的企业多账户架构（指导方案）

• 在 Amazon Bedrock AgentCore 上构建企业级智能体 AI 平台工作坊

• Amazon Bedrock AgentCore 文档

作者简介