AWS发布基于Bedrock AgentCore的企业级Agentic AI平台蓝图
AWS机器学习博客介绍一套开源参考架构：平台团队统一管理模型、工具和发布边界，各业务团队在自己的隔离账户内构建和运行智能体，上线前须通过评测流水线。
AI解读：蓝图采用联邦式运营模型：中央平台团队提供受治理的共享服务，业务团队（Workstream）保留对智能体、工具和数据的归属，各自账户运行独立的Runtime、Memory和Tool Gateway。
架构把推理与工具访问分成两个网关：推理请求须经批准网关并套用Guardrails、模型与区域白名单及配额；工具调用须经MCP网关，只暴露注册表中已获批的工具别名。
交付流水线在部署到非生产环境后运行评测门禁，检查质量、工具成功率、拒绝行为、首token延迟与成本，并把每次授权调用与一次预期被拒绝的对抗调用配对；缺少预期拒绝即判定构建失败。
这是AWS在其官方博客发布的参考实现与设计说明，文中未给出客户部署数量或实际运行效果数据。
AWS机器学习博客发布一篇文章，介绍基于Amazon Bedrock和Amazon Bedrock AgentCore构建的企业级Agentic AI平台蓝图。作者Omar Elkharbotly称，模型和工具调用并非智能体投产的主要瓶颈，难点在安全环境、归属、运维边界和成本可见性等周边环节。
蓝图以开源参考实现和基础设施即代码形式提供，README记录各平面的职责；文章建议先从一个有代表性的Workstream单元开始，验证入驻、生产晋升、回滚、集中可观测性和零残留退役，再复制基线。
平台与业务团队的分工
文章把管理平台的团队称为Platform团队，把在平台上构建智能体的领域或产品团队称为Workstream团队。文中列举三种运营模型：集中式由单一AI/ML团队构建和运行所有智能体，治理一致但随用例增长成为瓶颈；分散式由各业务单元自建，速度快但控制容易漂移、成本可见性差；联邦式由中央平台团队提供受治理的共享服务，领域团队保留归属。蓝图采用联邦式。
- Platform团队负责模板、版本、策略和准入的定义，并运营共享推理网关、Guardrails、注册表和发布编排。
- 每个Workstream账户运行自己的Runtime、Memory和Tool Gateway，一次失败或回滚留在一个团队边界内。
- 蓝图附带Strands、LangGraph和CrewAI的参考模板，但保留推理网关、工具网关、身份、策略、评测和交付契约时也可使用其他框架。
网关与准入控制
架构把模型访问和工具访问分别放在两个网关之后。文章称，所有不受信任的推理请求须经过批准的推理网关，由网关套用组织Guardrails，限制各Workstream可用的模型和AWS区域，并执行按团队的速率限制、token配额和预算。工具方面，智能体须通过经过认证的MCP网关发现和调用已批准工具，网关使用精确目标和最小权限执行角色。
策略层面使用服务控制策略限制Platform和Workstream账户的最大权限。文章明确，服务控制策略是IAM、网关授权、Guardrails等控制的补充，不替代它们；新增模型或区域需要经过可用性、数据驻留、IAM、质量、成本、回滚、可观测性和拒绝验证。
- 智能体不直接调用模型提供商，推理须穿过受治理网关。
- Workstream团队通过拉取请求和流水线变更，直接由开发者部署到Workstream账户不在支持范围内。
- 当订阅的注册表记录缺失、变更或未获批时，Workstream网关合成会失败。
- 每个被拒绝的路径须配一次授权成功调用，以证明是预期控制导致拒绝。
评测门禁与发布流程
蓝图的流水线规定了一套晋升顺序：拉取请求确定不可变源版本，构建并合成CloudFormation与cdk-nag输出，Workload流水线创建稳定角色后暂停，由Platform流水线授予精确工具别名并核验生效策略，随后部署到非生产边界。
部署后，门禁调用真实Runtime，测量回归、质量、工具成功率、拒绝行为、首token延迟和成本。每次授权调用都配一次对抗调用：先调用获批模型确认成功，再调用未获批模型确认被拒；工具、跨账户身份和限流采用同一模式。若预期拒绝没有出现，构建失败。之后由人工审查部署证据、已知限制和剩余风险。文章称，缺少必需探测项、资源或预期拒绝时，通用的绿色构建不足以通过。
- 生产晋升使用已审查的修订版本，并对Runtime会话在更新、取消、回滚、恢复和重跑中采样。
- 退役按依赖顺序执行：先撤销平台别名授权，再处理Workstream网关和工具角色，然后是Runtime、Memory和应用资源，最后清点确认没有残留资源。