人工智能
在Amazon Bedrock Agent Core上建立一个代理AI平台
若你想让agent投入生产，主要瓶颈在于他们周围的一切：有多少团队可以在安全的环境中建设，哪个团队拥有每个模型和工具，AgentOps和错误处理如何停留在预先确定的边界内，以及平台，工作流，和财务团队如何看待跨账户的成本和健康。 对于一个想要支持许多代理使用案例的平台团队来说，这是一个设计和操作的平台产品。 在此帖子中，指管理平台的团队为"平台团队"，并指以"工作流团队"为基础发展起来的团队。 工作流团队是平台上建立和拥有agents的域或产品团队。
每个工作流小组都需要铺平的道路，包括经核准的模型和工具、短期工作量识别、孤立的运行时间和内存、自动评价、回滚、遥测和成本归属。 这些控制需要保持一致性，因为工作流团队自定义了提示、工具、数据访问和应用行为。 每个团队集合后，控制漂移，共享服务成为瓶颈，所有权难以审计。
在这个帖子中，我们走过一个企业Agentic AI平台在Amazon Bedrock和Amazon Bedrock Agent Core上的架构和参考执行。 我们覆盖多账户操作模式，平台控制平面，可重复的每个工作流部署模式，单独的推论和工具网关，以及一个在晋升到生产前将每个agent打开的评价管道。 到最后，你应该能够从同伴蓝图中部署一个受管的工作流，验证其安全和生命周期合同，并将其作为你自己的代理AI平台在组织中的基础。
Amazon Bedrock Agent Core为agents规模的建设，部署和运行提供模块化服务，包括运行时间，网关，身份，内存，政策，注册和评价。 企业代理AI平台蓝图建立在AgentCore，新增上，其周围的企业合同作为可部署的基础设施作为代码：所有权、账户界限、软件交付、可观察性、成本治理和退休。
建筑原则
在潜入解决方案细节之前，它有助于理解推动平台架构的组织需要。 我们从建立agent平台的客户那里听到的共同挑战属于这五个类别：
- 管理模式访问：每一个不可信的推断请求都必须通过经批准的推断网关。 网关应用组织的护栏(例如Amazon Bedrock Guardrails或第三方供应商)，限制每个工作流可以使用的AWS区域模型和推断，并强制实施每个工作流的费率限制、象征性配额和预算，以便任何单一团队都无法耗尽共享能力。 该系统还载有工作量标识并发布归属数据。
- 管理工具访问：Agents必须通过经认证的示范背景协议(MCP)网关发现和引用经批准的工具，其中包含精确的目标、最低优先的执行角色、政策决定和可审计的所有人。
- 委托交付：工作流团队(例如产品团队)需要在事先批准的边界内独立运送并滚回，而不必等待平台团队部署每个应用程序或给予开发者直接的基础设施写道。
- 车队业务和费用：有几个人需要各账户的能见度，而不能书面了解小组的工作量。 Agent操作工程师需要日志，度量衡，痕迹和配额。 工作流程所有者需要按agent计算其预算的费用。 FinOps和财务团队需要团队或业务单位通过AWS Cost Explorer和AWS Cost and Usage Report(CUR)进行收费。 安全和治理领导需要证据，说明哪些工作量需要哪种模式和工具。
- 有界证据和生命周期：每释放agent，就需要每个边界的证据：
- 模式访问：核准的模式呼叫成功，对未经核准的模式或地区的呼叫被拒绝。
- 工具访问：一个已订阅工具呼叫成功，一个在 agent 订阅之外的工具的呼叫以预期错误被拒绝。
- 身份：来自另一工作流程账户或身份的请求被拒绝。
- 发布：可以恢复先前的agent运行时版本。
退休：Deardown将agent的运行时间、内存、工具网关和工具授予按依赖顺序取消，并证实没有任何东西留下。
蓝图通过四个相通的平面解决了这些需要：开发者经验，平台控制，工作流执行，以及保证和操作。 规模单位是工作流单元格，而不是一个手动配置的agent或一个共享工作量账户。 README蓝图详细记录了每架飞机的责任。 您将读取主平面：Agentic AI 平台控制平面和可重复工作流单元格在后段。
运营模式和平台组件
企业通常采用代理AI三种操作模式之一：
- 集中化：一个单一的人工智能和机器学习(AI/ML)小组建立和运行每个agent. 治理是始终如一的，但随着使用案件数量的增加，这一团队很快会成为一个瓶颈。
- 权力下放：每个业务单位建立和运营自己的agents。 团队可以快速行动，但没有共同的标准，控制往往会漂移，努力会被重复，成本能见度会受到影响。
- 联邦：一个中央平台小组提供共享、管理服务，而域小组保留对agents、工具和数据的所有权。 这种模式平衡了团队自主权与连贯的护栏，也是大多数企业登陆的地方。
- 关于选择的援助，见关于治理模式的AWS说明性指导页。
按照我们在客户业务约定中观察到的模式，蓝图采用了联邦模式。 平台团队是中枢，一般是平台产品管理员，建筑师，平台工程师，agent操作工程师，以及安全和治理领导。 工作流团队由发言人组成，由agent开发者，一个域技术领跑者和AI/ML工程师组成。 执行赞助人和CISO都居于两地之上。
在这个蓝图中，平台团队拥有每个组件的定义：模板，版本，政策和招生。 每个工作流账户都运行自己的每组组件实例(运行时间，内存，工具网关)，因此失败或回滚会留在一个团队的边界内。
解决办法概述
这个解决方案提供了一个受管，多账户的Agentic AI平台，平台团队运行，内部产品和工程团队等工作流程团队通过版本，自助界面消耗。
在企业规模中，开发者体验平面是组织批准，版本为agent模板的目录。 Strands、LangGraph和CrewAI的蓝图船参考模板，但模板保存同一推断网关、工具网关、身份、政策、评价和交货合同时，可以使用您对框架的选择。 应用团队拥有提示，agent逻辑，工具和评价案例。 平台团队拥有共同的控制和发布要求。
在四架飞机中，两架飞机承载大部分建筑：
- Agentic AI平台控制平面：平台账户发布版本模板和接口，运行AWS Agent 注册治理记录并共享推论网关，接受模型和Guardrails，管弦乐团审查发布，并汇总车队信号。 团队通过代码、描述符和管道来消耗这些能力，而不是管理员会议或部署门票。
-可重复工作流细胞：每个产品或域都接收一个与团队拥有的源寄存器相隔离的边界，一个Workload管道，以及三个Amazon Bedrock Agent Core能力：Agent Core Runtime,Agent-scoped Agent Core Memory，以及一个Agent Core Gateway，使用AWS IAM授权，并只曝光被批准的工具目标。 手机还持有本地客户管理的AWS KMS密钥，标签，提醒，预算，以及云表可观察性访问管理器(OAM)源链接。 一个小组可以部署、失败、退缩或退休，而不必与另一个小组的释放进行协调。
主要组成部分
下图说明了该溶液的操作模式和受管流。
架构由以下账户层组成：
- 管理和治理基金会。 AWS组织，AWS IAM身份中心，预防政策，审计，保留，成本政策确定企业界限。 这些逻辑责任可以映射到现有的AWS控制塔着陆区，而不需要重复的账户结构。
- 安全、审计和观察层 AWS CloudTrail,AWS Config,AWS安全枢纽，Amazon GuardDuty，日志存档，和Amazon Cloud Watch OAM sink提供独立的控制飞机证据和舰队能见度。 中央运营商可以查询共享信号而无需获得Workstream资源的写入。
- 代理AI平台的平台层。 单独的平台环境拥有金色路径，治理目录，Guardrails，共享推论网关，精确工具化名，管道，兼容性，配额，以及共同的操作界面。 平台变化在更广阔的推出之前，会针对代表性细胞进行测试。
- 工作流车队层。 每个产品、域或受管制的边界都接收一个或多个非生产和生产电池。 团队拥有"运行时间","记忆","工具网关","工具","数据","提示","评价案例","应用事件"，以及服务级目标(SLO). 在许多单元格中可以重复同样的基线，同时保留账户一级的隔离。
解决方案走过
以下各节追踪关键设计决定：账户地形学，预防和侦探控制，Agent Core执行路径，以及交付管道。
账户地质和组织单位
蓝图界定了将企业治理，共享平台服务，团队自主执行分开的逻辑账户作用：1.
这种地貌融合到现有的起落区，一个预先配置，安全，可伸缩的多账户AWS环境，其中管理，平台，和工作流标签描述的是责任而不是固定的三账户地产。 一个组织可以运行多个经验证的平台环境和许多工作流账户对。 从一个代表性的细胞开始，在重复基准之前证明上岗，生产推广，回滚，集中可观察，零剩余退休。
服务控制政策
服务控制政策限制了平台和工作流账户的最大权限。 它们补充而不是取代IAM、网关授权、护栏、资源政策、网络控制和管道证据。 该蓝图提出并审查了关于准确帐户和区域的有效政策，而不是仅仅依赖源代码意图。
- 模式和区域接纳：组织政策和网关执行作用仅限于对核定模式和受支助区域的推断。 增加一个模型或区域需要服务、居住、IAM、质量、成本、回滚、可观察性和拒绝验证。
- Guardrail和推论执行：Agents不直接呼叫模型提供者。 推论跨越受管网关，在其中应用了舞台护栏和模型允许列表。
- 仅管式工作流突变：工作流团队打开牵引请求并使用工作负荷管道。 直接将开发人员部署到工作流账户，不在支持的操作模式之外，这种模式使经过审查的释放和证据路径无法通过。
- 莱吉斯
本文由 AI宝库自动抓取并翻译，版权归原作者所有；如需查看原文请点下方链接。
Artificial Intelligence
Building an Agentic AI Platform on Amazon Bedrock AgentCore
If you’ve tried to get an agent into production, the model and tool use are not the blocker. The main bottleneck is everything around them: how many teams can build within a secure environment, which team owns each model and tool, how AgentOps and error handling stay inside a pre-defined boundary, and how platform, Workstream, and finance teams see cost and health across accounts. For a Platform team that wants to support many agentic use cases, that’s a platform product to design and operate. In this post, we refer to the team that manages the platform as the Platform team, and to the teams that build on it as Workstream teams. Workstream teams are the domain or product teams that build and own agents on the platform.
Each Workstream team needs a paved road with approved models and tools, short-lived workload identity, isolated runtime and memory, automated evaluation, rollback, telemetry, and cost attribution. These controls need to remain consistent as Workstream teams customize prompts, tools, data access, and application behavior. When every team assembles them, controls drift, shared services become a bottleneck, and ownership is difficult to audit.
In this post, we walk through the architecture and reference implementation of an enterprise Agentic AI Platform on Amazon Bedrock and Amazon Bedrock AgentCore. We cover the multi-account operating model, the Platform control plane, a repeatable per-Workstream deployment pattern, separate inference and tool gateways, and an evaluation pipeline that gates each agent before promotion to production. By the end, you should be able to deploy a governed Workstream from the companion blueprint, validate its security and lifecycle contracts, and use it as the foundation for your own agentic AI platform in the organization.
Amazon Bedrock AgentCore provides modular services for building, deploying, and operating agents at scale, including runtime, gateway, identity, memory, policy, registry, and evaluations. The Enterprise Agentic AI Platform Blueprint, built on AgentCore, adds the surrounding enterprise contracts as deployable infrastructure as code: ownership, account boundaries, software delivery, observability, cost governance, and retirement.
Architectural principles
Before diving into the solution details, it helps to understand the organizational needs that drive the platform architecture. The common challenges we have heard from customers who establish an agent platform fall into these five categories:
- Governed model access: Every untrusted inference request must pass through an approved inference gateway. The gateway applies the organization’s guardrails (for example, Amazon Bedrock Guardrails or a third-party provider), restricts which models and inference AWS Regions each Workstream can use, and enforces per-Workstream rate limits, token quotas, and budgets so that no single team can exhaust shared capacity. It also carries workload identity and emits attribution data.
- Governed tool access: Agents must discover and invoke only approved tools through an authenticated Model Context Protocol (MCP) gateway, with exact targets, least-privilege execution roles, policy decisions, and an auditable owner.
- Delegated delivery: Workstream teams (for example, product teams) need to ship and roll back independently inside pre-approved boundaries, without waiting for the platform team to deploy each application or granting developers a direct infrastructure write path.
- Fleet operations and cost: Several personas need visibility across accounts without gaining write access to team workloads. Agent operations engineers need logs, metrics, traces, and quotas. Workstream owners need cost per agent against their budgets. FinOps and finance teams need chargeback by team or business unit through AWS Cost Explorer and the AWS Cost and Usage Report (CUR). Security and governance leads need evidence of which workload called which model and tool.
- Bounded evidence and lifecycle: Every agent release needs proof at each boundary it touches:
- Model access: An approved model call succeeds, and a call to an unapproved model or Region is denied.
- Tool access: A subscribed tool call succeeds, and a call to a tool outside the agent’s subscription is denied with the expected error.
- Identity: A request from another workstream’s account or identity is rejected.
- Release: The previous agent runtime version can be restored.
- Retirement: Teardown removes the agent’s runtime, memory, tool gateway, and tool grants in dependency order, and confirms nothing is left behind.
The blueprint addresses these needs through four connected planes: developer experience, platform control, Workstream execution, and assurance and operations. The unit of scale is the Workstream cell, not a manually configured agent or one shared workload account. The blueprint README documents the responsibilities of each plane in detail. And you will read the main planes: Agentic AI Platform control plane and Repeatable Workstream cell in the later paragraphs.
Operating models and platform components
Enterprises usually adopt one of three operating models for agentic AI:
- Centralized: A single artificial intelligence and machine learning (AI/ML) team builds and runs every agent. Governance is consistent, but that team quickly becomes a bottleneck as the number of use cases grows.
- Decentralized: Each business unit builds and operates its own agents. Teams can move quickly, but without shared standards, controls tend to drift, effort gets duplicated, and cost visibility suffers.
- Federated: A central Platform team provides shared, governed services while domain teams retain ownership of their agents, tools, and data. This model balances team autonomy with consistent guardrails and is where most enterprises land.
- For assistance choosing, see the AWS Prescriptive Guidance page on Governance Models.
Following patterns we have observed in customer engagements, the blueprint implements the federated model. The Platform team is the hub, typically a Platform product manager, architect, platform engineers, agent operations engineers, and a security and governance lead. Workstream teams are the spokes, made up of agent developers, a domain tech lead, and AI/ML engineers. An executive sponsor and the CISO sit above both.
In this blueprint, the Platform team owns the definition of each component: templates, versions, policies, and admission. Each Workstream account runs its own instance of the per-team components (Runtime, Memory, Tool Gateway), so a failure or rollback stays inside one team’s boundary.
Solution overview
This solution delivers a governed, multi-account Agentic AI Platform that platform teams operate, and workstream teams such as internal product and engineering teams consume through versioned, self-service interfaces.
At enterprise scale, the developer experience plane is a catalog of organization-approved, versioned agent templates. The blueprint ships reference templates for Strands, LangGraph, and CrewAI, but you can use your choice of framework when the template preserves the same inference gateway, tool gateway, identity, policy, evaluation, and delivery contracts. Application teams own prompts, agent logic, tools, and evaluation cases. The Platform team owns the common controls and release requirements.
Out of the four planes, two carry most of the architecture:
- Agentic AI Platform control plane: The Platform account publishes versioned templates and interfaces, operates AWS Agent Registry governance records and shared Inference Gateways, admits models and Guardrails, orchestrates reviewed releases, and aggregates fleet signals. Teams consume these capabilities through code, descriptors, and pipelines rather than administrator sessions or deployment tickets.
- Repeatable Workstream cell: Each product or domain receives an isolated boundary with a team-owned source repository, a Workload pipeline, and three Amazon Bedrock AgentCore capabilities: AgentCore Runtime, actor-scoped AgentCore Memory, and an AgentCore Gateway that uses AWS_IAM authorization and exposes only the approved tool targets. The cell also holds local customer managed AWS KMS keys, tags, alarms, budgets, and a CloudWatch Observability Access Manager (OAM) source link. One cell can deploy, fail, roll back, or retire without coordinating with another team’s release.
Key components
The following diagram illustrates the operating model and governed flow of the solution.
The architecture consists of the following account layers:
- Management and governance foundation. AWS Organizations, AWS IAM Identity Center, preventive policy, audit, retention, and cost policy establish the enterprise boundary. These are logical responsibilities that can map to an existing AWS Control Tower landing zone rather than requiring a duplicate account structure.
- Security, audit, and observability layer. AWS CloudTrail, AWS Config, AWS Security Hub, Amazon GuardDuty, log archive, and an Amazon CloudWatch OAM sink provide independent control-plane evidence and fleet visibility. Central operators can query shared signals without gaining write access to Workstream resources.
- Platform layer of Agentic AI Platform. Separate Platform environments own golden paths, the governance catalog, Guardrails, shared Inference Gateways, exact tool aliases, pipelines, compatibility, quotas, and common operational interfaces. Platform changes are tested against representative cells before wider rollout.
- Workstream fleet layer. Each product, domain, or regulated boundary receives one or more nonproduction and production cells. Teams own Runtime, Memory, Tool Gateway, tools, data, prompts, evaluation cases, application incidents, and service-level objectives (SLOs). The same baseline can be repeated across many cells while preserving account-level isolation.
Solution walkthrough
The following sections trace the key design decisions: account topology, preventive and detective controls, the AgentCore execution path, and the delivery pipeline.
Account topology and organizational units
The blueprint defines logical account roles that separate enterprise governance, shared Platform services, and team-owned execution:
This topology integrates into an existing landing zone, a pre-configured, secure, and scalable multi-account AWS environment, where the Management, Platform, and Workstream labels describe responsibilities rather than a fixed three-account estate. An organization can operate multiple validated Platform environments and many Workstream account pairs. Start with one representative cell and prove onboarding, production promotion, rollback, centralized observability, and zero-residual retirement before repeating the baseline.
Service control policies
Service control policies constrain the maximum permissions available to Platform and Workstream accounts. They complement, rather than replace, IAM, gateway authorization, Guardrails, resource policies, network controls, and pipeline evidence. The blueprint renders and reviews the effective policies for the exact account and Region instead of relying on source-code intent alone.
- Model and Region admission: Organization policy and Gateway execution roles restrict inference to approved models and the supported Region. Adding a model or Region requires service availability, residency, IAM, quality, cost, rollback, observability, and denial validation.
- Guardrail and inference enforcement: Agents do not call model providers directly. Inference crosses the governed gateway, where the stage Guardrail and model allow-list are applied.
- Pipeline-only Workstream mutation: Workstream teams open pull requests and use the Workload pipeline. Direct developer deployment into Workstream accounts is outside the supported operating model, which keeps the reviewed release and evidence path non-bypassable.
- Regis
Auto-fetched and translated by AI Gem Box. All rights belong to the original author.