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

#在 Amazon Bedrock AgentCore 上构建企业级智能体 AI 平台

如果你试过把智能体（agent）送进生产环境，模型和工具使用并不是阻碍。主要瓶颈是它们周围的一切：有多少团队能在安全环境里构建，哪个团队拥有每个模型和工具，智能体运维（AgentOps）和错误处理如何留在预先划定的边界内，以及平台团队、业务工作流团队（Workstream）和财务团队如何跨账户看到成本和健康状况。对一个想支持许多智能体用例的平台团队（Platform team）来说，这是要设计并运营的平台产品。在本文中，我们把管理平台的团队称为平台团队，把在其上构建的团队称为业务工作流团队。业务工作流团队是在平台上构建并拥有智能体的领域或产品团队。

每个业务工作流团队都需要一条铺好的路：已批准的模型和工具、短生命周期的工作负载身份、隔离的运行时和记忆、自动评测、回滚（rollback）、遥测（telemetry）和成本归因（cost attribution）。当业务工作流团队定制提示词、工具、数据访问和应用行为时，这些控制仍须保持一致。若每个团队各自拼装，控制就会漂移，共享服务会变成瓶颈，所有权也难以审计。

在本文中，我们走读 Amazon Bedrock 与 Amazon Bedrock AgentCore 上企业级智能体 AI 平台的架构和参考实现。我们涵盖多账户运营模型、平台控制面、可重复的按业务工作流部署模式、分开的推理网关和工具网关，以及在每个智能体晋升到生产之前把它拦住的评测流水线。读完后，你应能从配套蓝图部署一个受治理的业务工作流，验证其安全与生命周期契约，并把它用作组织内自有智能体 AI 平台的基础。

Amazon Bedrock AgentCore 提供模块化服务，用于大规模构建、部署和运营智能体，包括运行时、网关、身份、记忆、策略、注册表和评测。建在 AgentCore 之上的企业智能体 AI 平台蓝图（Enterprise Agentic AI Platform Blueprint），把周围的企业契约做成可部署的基础设施即代码（infrastructure as code）：所有权、账户边界、软件交付、可观测性、成本治理和退役。

架构原则

在进入方案细节之前，先理解推动平台架构的组织需求会有帮助。我们从建立智能体平台的客户那里听到的常见挑战，落在这五类：

• 受治理的模型访问：每一条不可信的推理请求都必须经过已批准的推理网关。网关施加组织的护栏（例如 Amazon Bedrock Guardrails 或第三方提供方），限制每个业务工作流可以使用哪些模型和哪些推理 AWS 区域（Region），并执行按业务工作流的速率限制、令牌配额和预算，使任何一个团队都不能耗尽共享容量。它还携带工作负载身份，并发出归因数据。

• 受治理的工具访问：智能体必须通过已认证的模型上下文协议（Model Context Protocol，MCP）网关发现并调用仅限已批准的工具，带有确切目标、最小权限（least privilege）执行角色、策略决策和可审计的所有者。

• 委托式交付：业务工作流团队（例如产品团队）需要在预先批准的边界内独立发布和回滚，而不等待平台团队部署每个应用，也不授予开发者直接的基础设施写入路径。

• 机群运营与成本：若干角色需要跨账户可见性，但不能获得对团队工作负载的写入权限。智能体运营工程师需要日志、指标、追踪和配额。业务工作流所有者需要对照预算看每个智能体的成本。财务运营（FinOps）和财务团队需要通过 AWS Cost Explorer 和 AWS 成本与使用情况报告（AWS Cost and Usage Report，CUR）按团队或业务单元做费用分摊。安全与治理负责人需要证据，说明哪个工作负载调用了哪个模型和工具。

• 有边界的证据与生命周期：每次智能体发布都需要在它触及的每个边界上留下证明：

• 模型访问：对已批准模型的调用成功，对未批准模型或区域的调用被拒绝。

• 工具访问：对已订阅工具的调用成功，对智能体订阅之外工具的调用以预期错误被拒绝。

• 身份：来自另一个业务工作流的账户或身份的请求被拒绝。

• 发布：可以恢复上一个智能体运行时版本。

• 退役：拆除按依赖顺序移除智能体的运行时、记忆、工具网关和工具授权，并确认没有残留。

蓝图通过四个相连的平面满足这些需求：开发者体验、平台控制、业务工作流执行，以及保证与运营。扩展单位是业务工作流单元（Workstream cell），而不是手工配置的单个智能体或一个共享工作负载账户。蓝图 README 详细记录每个平面的职责。后文会读到两个主要平面：智能体 AI 平台控制面，以及可重复的业务工作流单元。

运营模型与平台组件

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

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

• 去中心化：每个业务单元构建并运营自己的智能体。团队可以走得很快，但没有共享标准时，控制容易漂移，工作被重复，成本可见性变差。

• 联邦式：中央平台团队提供共享的、受治理的服务，领域团队保留对其智能体、工具和数据的所有权。该模型在团队自主与一致护栏之间取得平衡，也是大多数企业最终落点。

• 若需要协助选择，见 AWS 规范性指导（AWS Prescriptive Guidance）中关于治理模型的页面。

按照我们在客户项目中观察到的模式，蓝图实现联邦式模型。平台团队是枢纽，通常包括平台产品经理、架构师、平台工程师、智能体运营工程师，以及安全与治理负责人。业务工作流团队是辐条，由智能体开发者、领域技术负责人和 AI/ML 工程师组成。执行赞助人和首席信息安全官（CISO）位于两者之上。

在此蓝图中，平台团队拥有每个组件的定义：模板、版本、策略和准入。每个业务工作流账户运行按团队组件（运行时、记忆、工具网关）的自有实例，因此一次失败或回滚停留在一个团队的边界内。

方案概览

本方案交付一个受治理的多账户智能体 AI 平台，由平台团队运营，并由业务工作流团队（例如内部产品和工程团队）通过带版本的自助接口使用。

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

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

• 智能体 AI 平台控制面：平台账户发布带版本的模板和接口，运营 AWS 智能体注册表（AWS Agent Registry）治理记录和共享推理网关，准入模型和护栏，编排经过评审的发布，并汇总机群信号。团队通过代码、描述符和流水线使用这些能力，而不是通过管理员会话或部署工单。

• 可重复的业务工作流单元：每个产品或领域获得一个隔离边界，包含团队自有的源码仓库、工作负载流水线，以及三项 Amazon Bedrock AgentCore 能力：AgentCore 运行时、按行动者限定范围的 AgentCore 记忆，以及使用 AWS_IAM 授权且只暴露已批准工具目标的 AgentCore 网关。该单元还持有本地客户托管的 AWS KMS 密钥、标签、告警、预算，以及一条 Amazon CloudWatch 可观测性访问管理器（CloudWatch Observability Access Manager，OAM）源链接。一个单元可以部署、失败、回滚或退役，而不必与另一个团队的发布协调。

关键组件

下图说明本方案的运营模型和受治理的流向。

图注：把治理基础、平台控制面和团队自有业务工作流单元连起来的运营模型

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

架构由以下账户层组成：

• 管理与治理基础。AWS Organizations、AWS IAM Identity Center、预防性策略、审计、留存和成本策略确立企业边界。这些是逻辑职责，可以映射到现有的 AWS Control Tower 落地区（landing zone），而不要求一套重复的账户结构。

• 安全、审计与可观测层。AWS CloudTrail、AWS Config、AWS Security Hub、Amazon GuardDuty、日志归档，以及一个 Amazon CloudWatch OAM 汇，提供独立的控制面证据和机群可见性。中央操作者可以查询共享信号，而不会获得对业务工作流资源的写入权限。

• 智能体 AI 平台的平台层。分开的平台环境拥有黄金路径（golden path）、治理目录、护栏、共享推理网关、确切的工具别名、流水线、兼容性、配额和共同运营接口。平台变更在更广铺开之前，先对照代表性单元测试。

• 业务工作流机群层。每个产品、领域或受监管边界获得一个或多个非生产单元和生产单元。团队拥有运行时、记忆、工具网关、工具、数据、提示词、评测用例、应用事件和服务级别目标（service-level objective，SLO）。同一基线可以在许多单元上重复，同时保持账户级隔离。

方案走读

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

账户拓扑与组织单元

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

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

服务控制策略

服务控制策略（service control policy，SCP）约束平台账户和业务工作流账户可用的最大权限。它们补充而非替代 IAM、网关授权、护栏、资源策略、网络控制和流水线证据。蓝图针对确切账户和区域渲染并评审生效策略，而不是只依赖源代码意图。

• 模型与区域准入：组织策略和网关执行角色把推理限制在已批准模型和受支持区域。增加一个模型或区域，需要服务可用性、数据驻留、IAM、质量、成本、回滚、可观测性和拒绝验证。

• 护栏与推理强制：智能体不直接调用模型提供方。推理穿过受治理的网关，在那里施加阶段护栏和模型允许列表。

• 仅流水线可变更业务工作流：业务工作流团队开启拉取请求，并使用工作负载流水线。开发者直接部署进业务工作流账户不属于受支持的运营模型，从而使经过评审的发布和证据路径不可绕过。

• 注册表与网关治理：当已订阅的注册表记录缺失、被更改或未获批准时，业务工作流网关合成失败。

• 限定范围的部署角色：引导策略按账户和区域生成，用 AWS Identity and Access Management Access Analyzer（IAM Access Analyzer）验证，并通过生效策略模拟检查。管理员访问保留给初始设置，而不是例行流水线执行。

• 职责分离（separation of duties）与对抗性证明：平台控制模型、护栏、注册表和共享服务准入。业务工作流团队控制应用行为。每条被拒绝的路径都配有一次已授权的正向调用，以及一次证明“预期控制导致了拒绝”的变更。

业务工作流账户内的管理员不能绕过这些控制造出一条受支持的捷径。新的或变更后的组织策略，在广泛附加之前，需要沙箱或代表性单元的浸泡、确切的允许与拒绝测试，以及回滚计划。

带评测门禁的持续集成与持续交付流水线

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

• 源与评审：拉取请求确立不可变的源修订。流水线钉住预期分支，使未合并的变更不能静默地构建仓库默认分支。

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

• 稳定角色与权限交接：工作负载流水线创建稳定的业务工作流角色并暂停。平台流水线把确切的工具别名授予确切的网关角色，现场策略得到验证，然后工作负载流水线才继续。

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

• 评测已部署的智能体：门禁调用真实运行时，并度量回归、质量、工具成功率、拒绝行为、首令牌延迟和成本。每一次已授权调用都配有一个对抗孪生：门禁调用已批准模型并确认成功，再调用未批准模型并确认拒绝。同一模式适用于工具、跨账户身份和限流。如果预期的拒绝缺失，门禁使构建失败。

• 人工批准：评审者检查已部署的证据、已知限制和残余风险。当必需的探测、资源或预期拒绝缺失时，一次泛泛的绿色构建并不够。

• 晋升、观察与回滚：生产晋升使用经过评审的修订和连续性检查。运行时会话通过更新、取消、回滚、恢复和重新运行进行抽样，使流水线同时证明前进路径和恢复路径。

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

安全与治理

蓝图通过相互加强的身份、策略、交付、数据和证据控制实现深度防御（defense in depth）：

• 身份与信任边界：Amazon Bedrock AgentCore 的一项能力 AgentCore Identity，以及 Amazon Cognito，提供短生命周期的推理凭证。AWS_IAM 和 SigV4 认证工具流量。确切的运行时角色和网关角色、签发者与受众检查、账户与区域上下文，以及限定范围的引导信任，把每个主体限制在其预期路径上。

• 模型安全与准入：推理流经方案概览中描述的受治理网关，在每次调用之前施加护栏和模型允许列表。

• 工具授权：工具网关只调用注册表已批准的别名，详见方案概览。策略语言（Cedar）策略提供授权，并保留一个 AWS Lambda 包装器作为深度防御。

• 租户（tenant）数据保护：业务工作流账户隔离应用状态。AgentCore 记忆使用按行动者限定的命名空间和客户托管的 KMS 密钥。工具和应用数据仍由团队拥有，留存、删除和访问策略是显式的，而不是从共享的可变工作负载账户继承。

• 软件供应链（software supply chain）与发布：经过评审的源、清单哈希、可复现构建、绑定摘要的镜像扫描、策略验证、cdk-nag 检查、已部署运行时评测、人工批准、回滚，以及按依赖顺序的拆除，构成一份发布契约。缺失的检查以失败关闭。

• 审计、可观测性与成本治理：CloudTrail 和留存的控制面数据印证流水线证据。OAM 与中央操作者共享日志、指标和追踪。标准分摊标签、预算、配额，以及 AWS 成本与使用情况报告的核对，在不给予智能体改写自身归因权限的前提下指定所有权。

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

结论

在本文中，我们走读了建在 Amazon Bedrock AgentCore 上的企业级智能体 AI 平台。该架构把集中治理的平台控制面与可重复的、团队自有的业务工作流单元分开，使用各自的推理网关和工具网关，并由已部署运行时评测来门禁生产晋升。

配套仓库包含一份蓝图，端到端验证这些控制，从流水线门禁和对抗性边界测试，直到零残留拆除。支持声明停在该已测试边界。

开始时，从配套仓库部署一个代表性业务工作流单元，证明其完整生命周期，然后用同一带版本的基线自动化更多单元。

PRIMARY_SOURCE: https://aws.amazon.com/blogs/machine-learning/building-an-agentic-ai-platform-on-amazon-bedrock-agentcore