在 Amazon Bedrock AgentCore 上构建 Agentic AI 平台
如果你试过把 Agent 推上生产环境，会发现模型和工具调用并不是卡点。真正的瓶颈在它们周围：有多少团队能在安全环境中构建 Agent，每个模型和工具归哪个团队负责，AgentOps 和错误处理如何保持在预先划定的边界内，以及平台团队、Workstream 团队和财务团队怎样跨账户看清成本与健康状况。对一个想支撑大量 Agent 场景的平台团队来说，这本身就是个需要设计和运营的平台产品。
在本文中，管理平台的团队称为平台团队（Platform team），在平台上开发的团队称为 Workstream 团队。Workstream 团队是领域团队或产品团队，负责在平台上构建并持有 Agent。
每个 Workstream 团队都需要一条铺好的路（paved road）：经过审批的模型和工具、短期的工作负载身份、隔离的运行时和内存、自动化评估、回滚、遥测，以及成本归属。当 Workstream 团队自定义提示词、工具、数据访问和应用行为时，这些控制项必须保持一致。如果每个团队各自去拼装，控制就会走样，共享服务会变成瓶颈，责任归属也难以审计。
本文介绍基于 Amazon Bedrock 和 Amazon Bedrock AgentCore 的企业级 Agentic AI 平台架构与参考实现。内容涵盖多账户运营模型、平台控制平面、可复用的 Workstream 部署模式、独立的推理网关和工具网关，以及在每个 Agent 晋升到生产环境前进行把关的评估流水线。
读完之后，你可以从配套蓝图部署一个受治理的 Workstream，验证它的安全与生命周期契约，并把它作为组织内部自建 Agentic AI 平台的基础。
Amazon Bedrock AgentCore 提供一组模块化服务，用来大规模构建、部署和运营 Agent，包括运行时、网关、身份、内存、策略、注册表和评估。
企业级智能体 AI 平台蓝图（Enterprise Agentic AI Platform Blueprint）构建在 AgentCore 之上，把周边一系列企业治理要求做成可部署的基础设施即代码：归属关系、账户边界、软件交付、可观测性、成本治理和退役下线。
架构原则
在深入方案细节之前，先理解推动平台架构设计的组织需求会很有帮助。我们与搭建智能体平台的客户交流时，听到的常见挑战可以归为以下五类：
受管控的模型访问：每一个不受信任的推理请求都必须经过批准的推理网关。网关执行组织的护栏策略（比如 Amazon Bedrock Guardrails 或第三方提供商），限制每个工作流（Workstream）可以使用哪些模型和哪些 AWS 推理区域，并强制执行按工作流的速率限制、Token 配额和预算，确保没有哪个团队能独占共享容量。它还携带工作负载身份，并输出归属数据。
受管控的工具访问：智能体只能通过经过身份验证的模型上下文协议（Model Context Protocol，MCP）网关发现和调用已批准的工具，并具备明确的目标、最小权限执行角色、策略决策和可审计的负责人。
委托式交付：工作流团队（比如产品团队）需要在预先批准的边界内独立发布和回滚，不必等待平台团队部署每个应用，也不需要给开发者直接写基础设施的权限。
整个机群的运营与成本：多种角色需要跨账户的可见性，但不能获得对团队工作负载的写权限。智能体运维工程师需要日志、指标、链路追踪和配额。工作流负责人需要按智能体查看成本与预算的对比。FinOps 和财务团队需要通过 AWS Cost Explorer 和 AWS 成本与使用报告（CUR）按团队或业务单元进行费用分摊。安全与治理负责人需要证据，证明哪个工作负载调用了哪个模型和工具。
有边界的证据与生命周期：每次智能体发布都需要在它所触及的每个边界上提供证明。模型访问方面：调用已批准模型成功，调用未批准的模型或区域则被拒绝。
工具访问：已订阅的工具调用成功，未订阅的工具调用被拒绝并返回预期错误。身份：来自其他 Workstream 账户或身份的请求会被拒绝。发布：可以恢复上一个 agent 运行时版本。退役：拆除时按依赖顺序移除 agent 的运行时、内存、工具网关和工具授权，并确认没有遗留。蓝图通过四个相互连接的平面满足这些需求：开发者体验、平台控制、Workstream 执行，以及保障与运营。扩展的单位是 Workstream 单元，而不是手动配置的 agent 或一个共享的工作负载账户。蓝图 README 详细记录了每个平面的职责。后续段落将介绍主要平面：Agentic AI 平台控制平面和可重复的 Workstream 单元。
运营模式与平台组件
企业通常为 agentic AI 采用三种运营模式之一：
集中式： 由单一的人工智能与机器学习（AI/ML）团队构建并运行所有 agent。治理一致，但随着用例数量增长，这个团队很快会成为瓶颈。
分散式： 每个业务单元构建并运营自己的 agent。团队可以快速行动，但缺乏共享标准时，控制容易漂移，工作重复，成本可见性也会变差。
联邦式： 中央平台团队提供共享的、受治理的服务，领域团队保留对其 agent、工具和数据的所有权。这种模式在团队自主权与一致的护栏之间取得平衡，也是大多数企业最终选择的模式。如需选择帮助，请参阅 AWS Prescriptive Guidance 中关于治理模式的页面。
根据我们在客户合作中观察到的模式，蓝图实现了联邦式模型。平台团队是枢纽，通常包括平台产品经理、架构师、平台工程师、agent 运维工程师，以及安全与治理负责人。Workstream 团队是辐条，由 agent 开发者、领域技术负责人和 AI/ML 工程师组成。高管发起人和 CISO 位于两者之上。
在这套方案里，每个组件的定义都由平台团队负责：模板、版本、策略和准入规则。每个 Workstream 账户各自运行一套按团队隔离的组件（Runtime、Memory、Tool Gateway），所以某个团队出故障或回滚，影响都关在自己边界内。
方案概览
这套方案交付的是一个受治理的多账户 Agentic AI 平台：平台团队负责运营，内部产品、工程等业务线团队则通过带版本的自助式接口来使用。
放到企业规模上看，开发者体验层就是一份「组织批准、带版本」的 Agent 模板目录。方案里提供了 Strands、LangGraph 和 CrewAI 的参考模板，但你也可以换成自己选的框架——只要模板遵守同一套契约：推理网关、工具网关、身份、策略、评测和交付。
应用团队负责提示词、Agent 逻辑、工具和评测用例；平台团队负责通用管控和发布要求。
四个平面中，有两个承载了大部分架构：
Agentic AI 平台控制面：Platform 账户发布带版本的模板和接口，维护 AWS Agent Registry 的治理记录和共享推理网关，对模型和护栏（Guardrails）做准入，编排经过评审的发布流程，并汇总全局运行信号。团队用代码、描述文件和流水线来消费这些能力，而不是靠管理员登录控制台或提部署工单。
可复制的工作流单元（Workstream cell）：每个产品或领域都拿到一个隔离边界，里面有团队自己的源码仓库、一条工作负载流水线，以及三项 Amazon Bedrock AgentCore 能力：AgentCore Runtime、按调用者（actor）划分作用域的 AgentCore Memory，还有一个使用 AWS_IAM 授权、只暴露已批准工具目标的 AgentCore Gateway。这个单元还带上本地的客户自管 AWS KMS 密钥、标签、告警、预算，以及一条 CloudWatch Observability Access Manager（OAM）源链接。
一个单元可以独立部署、故障、回滚或下线，不需要与其他团队的发布协调。
关键组件
下图展示了这套方案的运作模式和受治理的流程。
图 1：企业级 Agentic AI 平台的运营模式。图中展示了治理基础、平台控制面、可重复且由团队负责的 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 平台的平台层。 独立的平台环境负责维护黄金路径（golden paths）、治理目录、Guardrails、共享推理网关、精确的工具别名、流水线、兼容性、配额和通用运维接口。平台变更会先在具有代表性的单元中测试，确认无误后再扩大范围上线。
Workstream 集群层。 每个产品、业务域或受监管边界都会分配一个或多个非生产单元和生产单元。团队负责 Runtime、Memory、Tool Gateway、工具、数据、提示词、评测用例、应用事故和服务等级目标（SLO）。同一套基线可以在多个单元中重复使用，同时保留账户级隔离。
方案详解
以下各节梳理关键设计决策：账户拓扑、预防性与检测性控制、AgentCore 的执行路径，以及交付流水线。
账户拓扑与组织单元
这套蓝图定义了若干逻辑账户角色，把企业治理、共享的平台服务和团队自有的执行环境分离开来：
| 角色 | 在 Landing Zone 中的位置 | 用途 |
|---|---|---|
| 管理基础 | 根 / 安全与管理 | Organizations、Identity Center、预防性策略、审计、数据保留与成本策略 |
| 安全与日志归档 | 安全 | CloudTrail、AWS Config、Security Hub、GuardDuty，以及留存的审计数据 |
| 可观测性 | 安全或运维 | CloudWatch OAM 汇聚端，以及整个组织的日志、指标、追踪和成本视图 |
| Agentic AI 平台 | 平台 | 黄金路径、AWS Agent Registry、Guardrails、推理网关、流水线和组织级管控 |
| 工作流单元（Workstream cell） | Agent 工作流 | 团队自有的 Runtime、Memory、Tool Gateway、工具、数据、评测和应用 SLO |
| 更多工作流单元 | Agent 工作流 | 按产品、领域、环境或合规边界重复同一套基线 |
这套拓扑可以接入已有的 Landing Zone。Landing Zone 是预先配置好、安全且可扩展的多账户 AWS 环境。其中的 Management、Platform 和 Workstream 只是职责标签，并不代表固定只有三个账户。一个组织可以运行多个经过验证的平台环境，以及许多成对出现的工作流账户。
建议先从一个有代表性的单元做起，验证入驻、生产发布、回滚、集中可观测性和「零残留」下线都跑通，然后再复制这套基线。
服务控制策略
服务控制策略（SCP）限制平台账户和工作流账户能获得的最高权限。它和 IAM、网关授权、Guardrails、资源策略、网络控制以及流水线证据是互补关系，并非替代关系。
这套蓝图会针对具体的账户和区域渲染并审查实际生效的策略，而不是只看源代码想表达的意图。
模型与区域准入：组织策略和网关执行角色把推理限制在获批的模型和支持的区域之内。要新增一个模型或区域，必须同时通过服务可用性、数据驻留、IAM、质量、成本、回滚、可观测性和拒绝场景等多项验证。
-
护栏与推理强制管控：Agent 不会直接调用模型提供方。所有推理请求都经受过管控的网关，由它在相应阶段施加护栏（Guardrail）和模型白名单。
-
仅允许通过流水线变更 Workstream：Workstream 团队提交拉取请求，并使用 Workload 流水线。开发者直接部署到 Workstream 账户不在受支持的运维模式之内，这样就能确保经过审查的发布与证据路径不可绕过。
-
注册表与网关治理：当已订阅的注册表记录缺失、被改动或未获批准时，Workstream 网关的合成（synthesis）会失败。
-
限定范围的部署角色：引导（Bootstrap）策略按账户和区域分别生成，用 AWS IAM Access Analyzer 校验，并通过实际生效策略模拟进行检查。管理员访问权限只保留给初始设置，不用于日常流水线执行。
-
职责分离与对抗性验证：平台方管控模型、护栏、注册表和共享服务的准入；Workstream 团队管控应用行为。每一条被拒绝的路径都配有一个经授权的正向调用，以及一次能证明确实是预期控制导致了拒绝的变更操作。Workstream 账户内的管理员无法绕过这些控制建立受支持的快速通道。
-
组织策略变更需先验证：新增或变更的组织策略，需要先在沙箱或代表性单元中进行浸泡测试（soak），做精确的允许与拒绝测试，并准备回滚方案，之后才能广泛附加。
带评估门禁的 CI/CD 流水线
该蓝图使用经过审查的 Platform 和 Workload 流水线，强制执行以下晋级顺序：
-
源码与审查：拉取请求确立不可变的源码修订版。流水线锁定预期的分支，避免未合并的变更悄悄构建仓库的默认分支。
-
构建与合成：流水线编译代码、运行测试和 lint 检查、生成 Agent 清单（manifest）、扫描与摘要绑定的镜像、校验策略、解析已获批准的注册表描述符，并检查合成出的 AWS CloudFormation 与 cdk-nag 输出。
-
稳定角色与权限交接：Workload 流水线创建稳定的 Workstream 角色，然后暂停。
平台管线会把精确的工具别名授予精确的网关角色，验证线上策略，然后工作负载管线才会继续。部署到非生产环境：管线将运行时、记忆、工具网关、可观测性、告警、预算、标签和应用资源部署到该单元的非生产边界内。评估已部署的智能体：门禁调用真实运行时，衡量回归、质量、工具成功率、拒绝行为、首token延迟和成本。每个被授权的调用都配有一个对抗性双胞胎：门禁先调用一个已批准的模型并确认成功，再调用一个未批准的模型并确认拒绝。同样的模式适用于工具、跨账户身份和限流。如果预期的拒绝没有出现，门禁就会让构建失败。人工审批：审核者检查已部署的证据、已知限制和残余风险。当缺少必需的探针、资源或预期拒绝时，仅仅构建通过是不够的。晋升、观察和回滚：生产晋升使用已审核的修订版和连续性检查。运行时会话会在更新、取消、回滚、恢复和重跑过程中被采样，这样管线既能证明正向路径，也能证明恢复路径。工作流部署步骤没有手动快速通道。平台团队拥有发布契约，但工作流团队运营自己的管线实例和部署节奏。退役遵循严格的依赖顺序：先撤销平台别名授权，然后撤销工作流网关和工具角色，最后撤销运行时、记忆和应用资源。每一步都经过验证后才会继续，最终盘点确认没有残留资源。安全与治理蓝图通过强化身份、策略、交付、数据和证据控制来实现纵深防御：身份与信任边界：AgentCore Identity（Amazon Bedrock AgentCore的一项能力）和 Amazon Cognito 提供短期推理凭证。AWS_IAM 和 SigV4 对工具流量进行身份验证。
精确的运行时和网关角色、签发者和受众检查、账户和区域上下文，以及限定范围的引导信任，共同把每个主体限制在预期路径内。模型安全与准入：推理经由解决方案概述中描述的受治理网关流转，每次调用前都会应用护栏和模型白名单。工具授权：工具网关只调用注册表中已批准的别名，详见解决方案概述。Cedar 策略负责授权，同时保留 AWS Lambda 包装层以实现纵深防御。租户数据保护：工作负载账户隔离应用状态。AgentCore 内存使用按参与者作用域划分的命名空间和客户管理的 KMS 密钥。工具和应用数据仍归团队所有，保留、删除和访问策略都有明确规定，而不是从共享的可变工作负载账户继承。软件供应链与发布：经过审查的源代码、清单哈希、可重现构建、绑定摘要的镜像扫描、策略验证、cdk-nag 检查、已部署运行时评估、人工审批、回滚，以及按依赖顺序拆除，共同构成一份发布契约。任何一项检查缺失都会默认拒绝。审计、可观测性与成本治理：CloudTrail 和保留的控制面数据为流水线证据提供佐证。OAM 将日志、指标和追踪共享给中央运维人员。标准分配标签、预算、配额和 AWS 成本与使用报告对账，用于分配归属，同时不给智能体修改自身归属的权限。该仓库是参考实现，开发者可以根据自身需求调整。部署和可用功能基于 eu-west-1（爱尔兰）区域。替换组件、更换区域或扩大组织范围推广时，都需要单独提供可用性、安全性、负载、回滚、可观测性和拆除方面的证据。
结论
本文介绍了一个构建在 Amazon Bedrock AgentCore 上的企业级 Agentic AI 平台。该架构将集中治理的平台控制面与可重复、团队自有的工作负载单元分开，并设置独立的推理网关和工具网关；生产发布则由已部署运行时评估来把关。
配套仓库里有一个蓝图，可以端到端验证这些控制措施，从流水线门禁、对抗性边界测试，一直覆盖到零残留拆除。支持范围就到这个经过测试的边界为止。上手时，先从配套仓库部署一个有代表性的 Workstream 单元，验证它的完整生命周期，然后基于同一版本化基线去自动化更多单元。
相关资料：
- Enterprise Agentic AI Platform Blueprint on GitHub
- Enterprise multi-account architecture for running agentic AI in production on AWS（规范性指南）
- Building an Enterprise Agentic AI Platform on Amazon Bedrock AgentCore 研讨会
- Amazon Bedrock AgentCore 文档
关于作者
Omar Elkharbotly
Omar 是 AWS 的高级 GenAI/ML 专家解决方案架构师。他与英国和爱尔兰的企业客户合作，使用 Amazon Bedrock 和 Amazon Bedrock AgentCore 设计和部署生成式 AI 与机器学习解决方案，帮助客户构建可扩展、可用于生产环境的应用。
Mia Chang
Mia 是专注于 Agentic AI 的专家解决方案架构师，常驻德国柏林。她帮助 EMEA 地区的企业客户设计、运营并扩展 agentic AI 工作负载——从最初的智能体到在托管平台上投入生产，也包括基于自管理基础设施的混合架构。她的专业领域涵盖 agentic 应用架构、智能体安全与治理、负责任 AI，以及平台工程。
Siva Shanmugam
Siva 是 Amazon Web Services 的高级解决方案架构师，专长于 AI/ML、数据和云原生架构。他的专业领域涵盖生成式与 Agentic AI 应用、开发者体验转型（包括 Agentic Coding 和 AI 驱动的工程实践），以及端到端的企业云解决方案。
搭建一套受治理、多账户的智能体 AI（Agentic AI）平台，底层依托 Amazon Bedrock AgentCore。本文介绍整体架构和一份开源参考蓝图，内容包括运营模型、控制平面、按工作流划分的单元、彼此独立的推理网关与工具网关，以及一条 CI/CD 评估流水线，让每个智能体在上线前都先过评估这道关。