AWS 发布 AgentCore 企业 Agent 平台蓝图：把治理写成可部署基础设施

• 核心发布：AWS 在机器学习博客公布企业级 Agentic AI 平台参考实现，基于 Amazon Bedrock AgentCore 的 runtime、gateway、identity、memory、policy、registry 与 evaluations 模块，叠加一层可部署的基础设施代码，覆盖所有权、账号边界、软件交付、可观测性、成本治理与退役。配套蓝图已放入 aws-samples/sample-ai-agent-factory 仓库。

• 组织模型：方案实现联邦式运营——中心 Platform 团队定义模板、版本、策略与准入，各 Workstream 团队在预批准边界内自主交付。扩展单元不是单个手工配置的 Agent，也不是一个共享工作负载账号，而是可复制的「Workstream cell」：每个 cell 有自己的仓库、流水线、Runtime、按 actor 隔离的 Memory、受 IAM 授权的 Gateway，以及本地 KMS 密钥、标签、告警与预算。文章同时列出集中式与去中心式两种运营模型的失效方式：前者随用例增长成为瓶颈，后者缺乏共享标准导致控制漂移与成本不可见。

• 两套网关分离：所有推理必须经过受治理的 Inference Gateway，在网关侧应用 Guardrails、模型与 Region 允许列表、按 Workstream 的速率限制、token 配额与预算；工具调用只能经 MCP Gateway 访问 Registry 中已批准的别名，使用最小权限执行角色与 Cedar 策略，并保留可审计的 owner。文章强调 Agent 不直接调用模型提供方。

• 发布门禁：流水线顺序为 PR 固定源码版本 → 构建与 synth（含镜像摘要扫描、策略校验、cdk-nag）→ 稳定角色与权限交接 → 部署到非生产 → 对已部署 Runtime 做评估 → 人工审批 → 生产发布与回滚演练。评估环节不只测质量、工具成功率、拒绝行为、首 token 延迟与成本，还要求每个授权调用配一个对抗性孪生：调用批准模型确认成功，再调用未批准模型确认被拒绝；预期拒绝缺失则构建失败。

• 退役与残余：退役按依赖顺序执行——先撤销 Platform 侧别名授权，再撤销 Workstream 的 Gateway 与工具角色，然后是 Runtime、Memory 与应用资源，每步验证通过才继续，最终盘点确认零残留。文章把「零残留退役」与模型访问、工具访问、身份隔离、版本回滚并列为需要逐项举证的边界。

• 边界与状态：Blueprint 提供 Strands、LangGraph、CrewAI 三类参考模板，部署与功能基于 eu-west-1（爱尔兰）区域，可接入既有 AWS Control Tower landing zone 而非重建账号体系。公开材料为参考架构与可运行示例，未披露生产规模、延迟与成本基准；替换组件、更换区域或扩大组织范围需自行补齐可用性、安全、负载、回滚与退役证据。

• 行业意义：文章把 Agent 上生产的阻碍定位在模型与工具之外——多少团队能在安全环境内构建、谁拥有某个模型与工具、AgentOps 与错误处理如何留在预定边界内、平台与财务团队如何跨账号看到成本与健康度。对准备把单团队 Agent 试用扩展为组织级平台的团队，可复用的部分是把所有权、账号边界与评估门禁做成版本化的准入契约，而不是继续在提示词层叠加约束。

🔗 AWS Machine Learning Blog | Enterprise Agentic AI Platform Blueprint | Amazon Bedrock AgentCore 文档