Article · AI translation
如果你尝试过将智能体投入生产环境，就会发现模型和工具的使用并非障碍。主要瓶颈在于它们周围的一切：有多少团队能够在安全环境中开发、每个模型和工具由哪个团队负责、如何使 AgentOps 和错误处理保持在预先定义的边界内，以及平台、Workstream 和财务团队如何跨账户了解成本与运行状况。对于希望支持众多智能体用例的平台团队来说，这是一款需要设计和运营的平台产品。在本文中，我们将管理平台的团队称为平台团队，将在平台上进行开发的团队称为 Workstream 团队。Workstream 团队是领域或产品团队，负责在平台上构建智能体并对其负责。每个 Workstream 团队都需要一条铺好的路，提供经批准的模型和工具、短期有效的工作负载身份、隔离的运行时和记忆、自动化评估、回滚、遥测以及成本归属。当 Workstream 团队定制提示词、工具、数据访问和应用行为时，这些控制措施仍需保持一致。如果每个团队都自行组装这些措施，控制措施就会逐渐偏离标准，共享服务会成为瓶颈，责任归属也难以审计。本文将介绍基于 Amazon Bedrock 和 Amazon Bedrock AgentCore 的企业级智能体 AI 平台的架构与参考实现。我们将介绍多账户运营模式、平台控制平面、可重复的逐 Workstream 部署模式、独立的推理网关和工具网关，以及在每个智能体晋升到生产环境前对其进行把关的评估流水线。读完本文，你应该能够使用配套蓝图部署受治理的 Workstream，验证其安全与生命周期契约，并以此作为在组织内构建自己的智能体 AI 平台的基础。Amazon Bedrock AgentCore 提供模块化服务，用于大规模构建、部署和运营智能体，包括运行时、网关、身份、记忆、策略、注册表和评估。基于 AgentCore 构建的 Enterprise Agentic AI Platform Blueprint 以可部署的基础设施即代码形式，补充了周边的企业级契约：责任归属、账户边界、软件交付、可观测性、成本治理和退役。架构原则 在深入探讨解决方案细节之前，了解推动平台架构形成的组织需求会有所帮助。根据我们从建立智能体平台的客户那里了解到的情况，常见挑战可归为以下 5 类：受治理的模型访问：每个不受信任的推理请求都必须经过获批的推理网关。网关应用组织的防护措施（例如 Amazon Bedrock Guardrails 或第三方提供商的防护措施），限制每个 Workstream 可使用的模型和用于推理的 AWS 区域，并强制执行各 Workstream 的速率限制、令牌配额和预算，以免任何单个团队耗尽共享容量。它还传递工作负载身份并生成归属数据。受治理的工具访问：智能体必须仅通过经过身份验证的模型上下文协议（MCP）网关发现和调用获批工具，且调用须有明确的目标、遵循最小权限原则的执行角色、策略决策以及可审计的负责人。委派式交付：Workstream 团队（例如产品团队）需要在预先批准的边界内独立发布和回滚，无须等待平台团队部署每个应用，也无须向开发人员授予直接写入基础设施的权限。整体运营与成本：多个角色需要跨账户的可见性，同时不能获得对团队工作负载的写入权限。智能体运营工程师需要日志、指标、追踪和配额信息。Workstream 负责人需要了解每个智能体相对于其预算的成本。FinOps 和财务团队需要通过 AWS Cost Explorer 和 AWS 成本和使用情况报告（CUR），按团队或业务部门进行成本分摊。安全和治理负责人需要能够证明哪个工作负载调用了哪个模型和工具。 有界证据与生命周期：每次智能体发布都需要在其涉及的每个边界提供证明：模型访问：对获批模型的调用成功，对未获批模型或区域的调用被拒绝。工具访问：对已订阅工具的调用成功，对智能体订阅范围之外工具的调用被拒绝，并返回预期错误。身份：来自其他工作流账户或身份的请求被拒绝。发布：可以恢复先前版本的智能体运行时。退役：按依赖顺序拆除智能体的运行时、记忆、工具网关和工具授权，并确认没有遗留任何内容。该蓝图通过4个相互连接的平面满足这些需求：开发者体验、平台控制、工作流执行，以及保障与运维。扩展的基本单元是工作流单元，而非手动配置的智能体或一个共享的工作负载账户。蓝图的README详细说明了每个平面的职责。后文将介绍其中的主要平面：Agentic AI Platform控制平面和可重复部署的工作流单元。运营模式与平台组件 企业通常采用3种智能体AI运营模式之一：集中式：由单一人工智能和机器学习（AI/ML）团队构建并运行所有智能体。治理具有一致性，但随着用例数量增长，该团队很快会成为瓶颈。分散式：每个业务部门构建并运营自己的智能体。团队可以快速推进，但如果缺乏共同标准，控制措施往往会偏离，工作会重复，成本可见性也会下降。联邦式：中央平台团队提供共享且受治理的服务，同时领域团队保留对其智能体、工具和数据的所有权。这种模式在团队自主权与一致的防护措施之间取得平衡，也是大多数企业最终采用的模式。如需帮助选择，请参阅AWS Prescriptive Guidance中关于治理模式的页面。遵循我们在客户合作中观察到的模式，该蓝图采用联邦式模式。平台团队是枢纽，通常包括平台产品经理、架构师、平台工程师、智能体运维工程师，以及安全与治理负责人。工作流团队是辐射节点，由智能体开发者、领域技术负责人和AI/ML工程师组成。执行发起人和首席信息安全官（CISO）位于两者之上。在该蓝图中，平台团队负责定义每个组件：模板、版本、策略和准入。每个工作流账户都运行自己的团队级组件实例（运行时、记忆、工具网关），因此故障或回滚会局限在单个团队的边界内。解决方案概述 该解决方案提供一个受治理的多账户Agentic AI Platform，由平台团队运营，工作流团队（例如内部产品和工程团队）通过版本化的自助服务接口使用。在企业规模下，开发者体验平面是一个由组织批准、带版本的智能体模板目录。该蓝图提供Strands、LangGraph和CrewAI的参考模板，但只要模板保持相同的推理网关、工具网关、身份、策略、评估和交付契约，就可以使用您选择的框架。应用团队负责提示词、智能体逻辑、工具和评估用例。平台团队负责通用控制措施和发布要求。在4个平面中，有2个承载了大部分架构：Agentic AI Platform控制平面：平台账户发布版本化模板和接口，运营AWS Agent Registry治理记录和共享推理网关，准入模型和Guardrails，编排经过审核的发布，并汇总整个智能体群的信号。团队通过代码、描述文件和流水线使用这些能力，而非通过管理员会话或部署工单。 可重复部署的工作流单元：每个产品或领域都有一个隔离边界，其中包含由团队拥有的源代码仓库、一条 Workload 流水线，以及三项 Amazon Bedrock AgentCore 功能：AgentCore Runtime、按参与者限定范围的 AgentCore Memory，以及使用 AWS_IAM 授权且仅公开获批工具目标的 AgentCore Gateway。该单元还包含本地客户托管的 AWS KMS 密钥、标签、告警、预算，以及一个 CloudWatch Observability Access Manager (OAM) 源链接。一个单元可以独立部署、发生故障、回滚或退役，而无需与其他团队的发布协调。关键组件 下图展示了解决方案的运行模式和受治理流程。图 1：企业级代理式 AI 平台运行模式，展示治理基础、Platform 控制平面、可重复部署且由团队拥有的工作流单元，以及它们之间的软件交付、推理、工具、遥测和所有权流。该架构包含以下账户层：管理与治理基础层。AWS Organizations、AWS IAM Identity Center、预防性策略、审计、保留和成本策略确立企业边界。这些是逻辑职责，可映射到现有的 AWS Control Tower 登陆区，而无须建立重复的账户结构。安全、审计与可观测性层。AWS CloudTrail、AWS Config、AWS Security Hub、Amazon GuardDuty、日志归档以及 Amazon CloudWatch OAM 接收端提供独立的控制平面证据和整个单元群的可见性。中央运维人员无需取得工作流资源的写入权限，即可查询共享信号。代理式 AI 平台的 Platform 层。彼此独立的 Platform 环境负责标准路径、治理目录、Guardrails、共享 Inference Gateways、精确的工具别名、流水线、兼容性、配额和通用运维接口。Platform 变更会先在代表性单元上测试，再进行更大范围的推广。工作流单元群层。每个产品、领域或受监管边界都配有一个或多个非生产和生产单元。团队负责 Runtime、Memory、Tool Gateway、工具、数据、提示词、评估用例、应用事件以及服务级别目标 (SLO)。同一基线可在多个单元中重复部署，同时保持账户级隔离。解决方案详解 以下各节梳理关键设计决策：账户拓扑、预防性与侦测性控制、AgentCore 执行路径以及交付流水线。账户拓扑与组织单位 该蓝图定义了逻辑账户角色，以区分企业治理、共享 Platform 服务和由团队拥有的执行环境：角色 登陆区位置 用途 管理基础层 根 / 安全与管理 Organizations、Identity Center、预防性策略、审计、保留和成本策略 安全与日志归档 安全 CloudTrail、AWS Config、Security Hub、GuardDuty 和保留的审计数据 可观测性 安全或运营 CloudWatch OAM 接收端，以及整个单元群的日志、指标、跟踪数据和成本视图 代理式 AI 平台 Agent Platform 标准路径、AWS Agent Registry、Guardrails、Inference Gateways、流水线和整个单元群的控制 工作流单元 Agent Workstreams 由团队拥有的 Runtime、Memory、Tool Gateway、工具、数据、评估和应用 SLO 其他工作流单元 Agent Workstreams 按产品、领域、环境或受监管边界重复部署相同基线 此拓扑可集成到现有登陆区，即预先配置、安全且可扩展的多账户 AWS 环境；其中 Management、Platform 和 Workstream 标签描述的是职责，并不意味着固定的三个账户架构。一个组织可以运行多个经过验证的 Platform 环境和多组 Workstream 账户配对。先从一个代表性单元开始，在重复部署该基线之前，验证接入、生产环境晋级、回滚、集中式可观测性以及无残留退役。 服务控制策略 服务控制策略限制平台账户和工作流账户可获得的最高权限。它们是对 IAM、网关授权、Guardrails、资源策略、网络控制和流水线证据的补充，而非替代。该蓝图会针对确切的账户和区域生成并审查实际生效的策略，而不只是依赖源代码表达的意图。模型和区域准入：组织策略和网关执行角色将推理限制在获批准的模型和受支持的区域。添加模型或区域时，必须验证服务可用性、数据驻留要求、IAM、质量、成本、回滚、可观测性和拒绝行为。Guardrail 和推理执行：智能体不直接调用模型提供商。推理经由受治理的网关，在那里应用对应阶段的 Guardrail 和模型允许列表。仅通过流水线变更工作流账户：工作流团队提交拉取请求并使用工作负载流水线。开发人员直接部署到工作流账户不属于受支持的运行模式，从而确保经过审查的发布和证据路径无法被绕过。Registry 和 Gateway 治理：如果订阅的 Registry 记录缺失、发生变更或未获批准，工作流 Gateway 的合成过程就会失败。限定范围的部署角色：引导策略按账户和区域生成，使用 AWS Identity and Access Management Access (IAM) Analyzer 验证，并通过生效策略模拟进行检查。管理员权限仅用于初始设置，不用于常规流水线执行。职责分离和对抗性验证：平台方控制模型、Guardrail、Registry 和共享服务的准入。工作流团队控制应用程序行为。每条被拒绝的路径都配有一个获授权的成功调用，以及一次用于证明预期控制措施确实导致拒绝的变更。工作流账户内的管理员无法创建绕过这些控制措施的受支持捷径。新的或变更后的组织策略在大范围附加之前，需要在沙盒或有代表性的单元中经过一段观察期，完成精确的允许和拒绝测试，并制定回滚计划。带评估关卡的 CI/CD 流水线 该蓝图使用经过审查的平台流水线和工作负载流水线，强制执行以下晋级顺序：源代码和审查：拉取请求确定不可变的源代码修订版本。流水线固定目标分支，防止尚未合并的变更悄然构建仓库的默认分支。构建和合成：流水线编译代码、运行测试和代码检查、创建智能体清单、扫描与摘要绑定的镜像、验证策略、解析获批准的 Registry 描述符，并检查合成后的 AWS CloudFormation 和 cdk-nag 输出。稳定角色和权限交接：工作负载流水线创建稳定的工作流角色后暂停。平台流水线向确切的 Gateway 角色授予确切的工具别名，验证实际生效的策略，然后工作负载流水线才继续。部署到非生产环境：流水线将 Runtime、Memory、Tool Gateway、可观测性组件、告警、预算、标签和应用程序资源部署到该单元的非生产边界内。评估已部署的智能体：关卡调用真实的 Runtime，并衡量回归情况、质量、工具调用成功率、拒绝行为、首个 token 延迟和成本。每个获授权的调用都配有一个对抗性对应调用：关卡调用获批准的模型并确认成功，然后调用未获批准的模型并确认遭到拒绝。同样的模式也适用于工具、跨账户身份和限流。如果预期的拒绝没有发生，关卡就会使构建失败。人工批准：审查人员检查部署后的证据、已知局限和剩余风险。如果缺少必需的探测、资源或预期拒绝，构建显示一般性的绿色通过状态并不足够。晋级、观察和回滚：生产环境晋级使用经过审查的修订版本和连续性检查。 运行时会话会经过更新、取消、回滚、恢复和重新运行的抽样检验，以证明流水线的正向流程和恢复流程均有效。任何 Workstream 部署步骤都没有人工快速通道。Platform 团队负责发布契约，但各 Workstream 团队自行运行其流水线实例并安排部署节奏。退役遵循严格的依赖顺序：首先撤销 Platform 别名授权，然后撤销 Workstream Gateway 和工具角色，最后移除 Runtime、Memory 和应用程序资源。每一步都经过验证后才继续，最终清单会确认残留资源为零。安全与治理 该蓝图通过相互强化的身份、策略、交付、数据和证据控制措施实施纵深防御：身份与信任边界：Amazon Bedrock AgentCore 的一项功能 AgentCore Identity 与 Amazon Cognito 提供短期推理凭证。AWS_IAM 和 SigV4 对工具流量进行身份验证。精确限定的 Runtime 和 Gateway 角色、颁发者和受众检查、账户和区域上下文，以及限定范围的引导信任，将每个主体限制在其预定路径内。模型安全与准入：推理流量经过“解决方案概述”中所述的受治理网关，在每次调用前应用 Guardrails 和模型允许列表。工具授权：如“解决方案概述”中详述，Tool Gateway 仅调用经 Registry 批准的别名。Cedar 策略提供授权，同时保留 AWS Lambda 包装层以实现纵深防御。租户数据保护：Workstream 账户隔离应用程序状态。AgentCore Memory 使用按参与者划定范围的命名空间和客户管理的 KMS 密钥。工具和应用程序数据仍归各团队所有，保留、删除和访问策略均明确规定，而非从共享且可变的工作负载账户继承。软件供应链与发布：经过审查的源代码、清单哈希、可复现构建、绑定摘要的镜像扫描、策略验证、cdk-nag 检查、已部署运行时评估、人工审批、回滚以及按依赖顺序拆除，共同构成一个发布契约。缺少任何一项检查都会使流程以拒绝方式关闭。审计、可观测性与成本治理：CloudTrail 和保留的控制平面数据为流水线证据提供佐证。OAM 与中央运维人员共享日志、指标和跟踪数据。标准成本分配标签、预算、配额以及 AWS 成本与使用情况报告的核对明确了归属，同时不赋予代理改写自身归属信息的权限。该存储库是一个参考实现。开发人员可以根据自身需求对其进行调整。部署和可用功能基于 eu-west-1（爱尔兰）区域。替换组件、使用其他区域或在更大范围的组织内推广，都需要各自提供有关可用性、安全性、负载、回滚、可观测性和拆除的证据。结论 在本文中，我们介绍了一个基于 Amazon Bedrock AgentCore 构建的企业级智能体 AI 平台。该架构将集中治理的 Platform 控制平面与可重复部署、由团队自行负责的 Workstream 单元分开，设有独立的推理网关和工具网关，并以已部署运行时评估作为生产环境晋级的门槛。配套存储库包含一个蓝图，可对这些控制措施进行端到端验证，涵盖从流水线门禁和对抗性边界测试到零残留拆除的整个过程。支持范围仅限于经过测试的边界。要开始使用，请从配套存储库部署一个具有代表性的 Workstream 单元，验证其完整生命周期，然后从同一个版本化基线自动部署更多单元。相关资源：GitHub 上的 Enterprise Agentic AI Platform Blueprint；Enterprise multi-account architecture for running agentic AI in production on AWS（规范性指导）；Building an Enterprise Agentic AI Platform on Amazon Bedrock AgentCore Workshop；Amazon Bedrock AgentCore 文档。作者简介 Omar Elkharbotly Omar 是 AWS 的高级生成式 AI/机器学习专家解决方案架构师。 他与英国和爱尔兰各地的企业客户合作，使用 Amazon Bedrock 和 Amazon Bedrock AgentCore 设计和部署生成式 AI 与机器学习解决方案，以构建可扩展、可投入生产的应用程序。Mia Chang：Mia 是一名专注于智能体 AI 的专家解决方案架构师，常驻德国柏林。她帮助欧洲、中东和非洲地区的企业客户设计、运营化和扩展智能体 AI 工作负载，涵盖从首批智能体到在托管平台上投入生产的全过程，以及采用自管理基础设施的混合架构。她的专业领域包括智能体应用架构、智能体安全与治理、负责任的 AI 以及平台工程。Siva Shanmugam：Siva 是 Amazon Web Services 的高级解决方案架构师，专注于 AI/ML、数据和云原生架构。他的专业领域涵盖生成式 AI 和智能体 AI 应用、开发者体验转型——包括智能体编程和 AI 赋能的工程实践——以及端到端的企业云解决方案。