用AgentCore搭建多账户Agent平台

Agent 能调用模型和工具，离企业生产环境还有一段距离。AWS 这篇文章讨论的是：多个团队同时开发 Agent 时，怎样统一权限、发布、成本和故障处理，又让业务团队保有交付自主权。

作者给出的方案，是基于 Amazon Bedrock 和 Amazon Bedrock AgentCore 建一个中央治理、团队独立运行的平台。值得读的地方在于，它把上线、回滚和下线都变成了需要证据的工程流程；但这套参考实现的验证范围，也有明确边界。

平台管规则，业务团队还剩多少自主权

文章先比较了三种组织方式：集中式由一个 AI/ML 团队承包所有 Agent，容易形成交付瓶颈；分散式让各业务单元自行建设，容易重复投入、权限漂移、成本不透明；联邦式则由 Platform 团队提供公共能力，Workstream 团队负责具体应用。

Workstream 可以理解为一个拥有自己产品、数据和 Agent 的业务团队。

参考蓝图采用联邦式。Platform 团队管理模板版本、模型准入、工具目录、公共服务和发布要求；业务团队管理提示词、Agent 逻辑、工具、数据和评估用例，也承担应用故障与服务级别目标（SLOs）。

平台统一的是交付和访问边界，业务团队自主的是边界内的应用行为。

这套平台分成开发体验、平台控制、Workstream 执行、保障与运维四个平面。其中，控制平面发布经过批准的模板、接口和治理记录；执行平面则以 Workstream cell 为扩展单位。

一个 cell 是可重复部署的团队运行单元，包含源码仓库、Workload pipeline，以及独立的 AgentCore Runtime、AgentCore Memory 和 AgentCore Gateway。它还配有本地客户管理的 AWS KMS 密钥、标签、告警、预算，以及 CloudWatch Observability Access Manager（OAM）源链接。

独立部署这些组件的目的，是把故障和回滚限制在团队边界内。一个团队发版失败，不应要求其他团队一起停下来协调。

框架选择仍然开放。蓝图提供 Strands、LangGraph 和 CrewAI 模板，也允许替换框架，前提是保留相同的推理、工具、身份、策略、评估和交付约定。框架能换，平台要求不能顺手绕开。

为什么模型调用和工具调用要走两个网关

推理网关与工具网关处理的风险不同。

推理网关管理模型、推理 AWS Region、Guardrails，以及每个 Workstream 的速率限制、token 配额和预算。它还携带工作负载身份，输出调用归属数据，避免一个团队耗尽公共容量后，其他团队和财务都不知道发生了什么。

工具网关管理的是执行权限。Agent 只能通过经过认证的 Model Context Protocol（MCP）网关发现和调用批准工具；工具需要明确目标、最小权限执行角色，以及可审计的负责人。

蓝图中，工具流量使用 AWS_IAM 和 SigV4 认证，通过 Cedar 策略授权，并保留 AWS Lambda 包装层作为纵深防御。AWS Agent Registry 中的记录如果缺失、发生变化或尚未批准，Workstream Gateway 的合成就会失败。

两者分开的价值很直接：获准调用某个模型，不应自动获得某个业务工具的执行权。

网关也不能独自承担全部约束。组织层的服务控制策略（SCP）限制账户权限上限，IAM、资源策略、网络控制和流水线证据继续提供各自的保护。SCP 不替代这些机制。

身份与数据同样需要划界。AgentCore Identity 和 Amazon Cognito 提供短期推理凭证；Runtime、Gateway 的角色及账户、Region、issuer、audience 都需要校验。Memory 使用按 actor 划分的命名空间，避免团队账户内的不同使用者混用记忆。

集中运维也不等于集中写权限。OAM 向中央运维人员共享日志、指标和追踪；CloudTrail 等保留独立审计证据。成本侧再用分摊标签、预算、配额、AWS Cost Explorer 和 AWS Cost and Usage Report（CUR）确认归属，Agent 自己不能改写归属信息。

一次成功调用，为什么不能证明可以上线

这篇文章最值得拿走的，是它对验证方式的要求。

测试一个批准模型能否调用成功，只能证明正常路径可用。要证明限制确实存在，还得调用一个未批准的模型或 Region，确认请求按预期被拒绝。工具订阅、跨账户身份和限流，也采用同样的正反配对验证。

作者还要求通过有意变更条件，证明拒绝来自目标控制。否则，一次网络故障也可能被误认成权限策略生效。

发布证据必须同时回答：该成功的是否成功，该拒绝的是否拒绝。

这些验证被放进 Platform 和 Workload 两类流水线。PR 确立不可变源码修订，流水线固定目标分支，避免未合并变更意外构建默认分支。构建阶段执行测试、lint、manifest 生成、与镜像摘要绑定的扫描、策略验证、Registry 描述符解析，并检查合成后的 AWS CloudFormation 和 cdk-nag 输出。

权限交接还有一个明确停顿：Workload pipeline 先创建稳定角色并暂停；Platform pipeline 将精确工具别名授权给精确 Gateway 角色，核验线上策略后，业务流水线才继续。

进入非生产环境后，评估直接调用真实 Runtime，覆盖回归、质量、工具成功率、拒绝行为、首 token 延迟和成本。缺少预期拒绝，构建就失败。

人工审批查看的是这些部署证据、已知限制和剩余风险。一个笼统的绿色构建状态，不能替代缺失的探针。

生产晋级还要验证更新、取消、回滚、恢复和重新运行。下线也有顺序：先撤销 Platform 工具别名授权，再删除 Workstream Gateway 和工具角色，最后删除 Runtime、Memory 与应用资源；逐步核验后，再盘点是否存在残留。

我的判断

我认同这套方案对责任和证据的强调。很多 Agent 演示只覆盖一次顺利执行，而生产问题往往出现在越权、发版中断、成本失控和资源遗留时。把这些路径纳入发布约定，比单纯增加一个模型安全提示更完整。

但它成立的前提，是组织已经需要多团队治理，并且有人持续维护平台产品。对于只有一个团队、少量 Agent 的项目，直接复制多账户、双流水线和跨账户授权交接，会增加维护负担。与共用账户、各团队自行部署相比，它提供更清晰的隔离，也要求更成熟的基础设施和职责分工。

原文没有提供两种方案的成本、交付速度或故障率对照，也没有展示质量、延迟、吞吐和成本门槛的具体数值。因此，联邦式更适合多数企业、这套架构能改善多少效率，仍属于经验判断，不能当成实测结论。

参考实现还明确基于 eu-west-1（Ireland）。换 Region、替换组件或扩大组织范围，都要重新提供可用性、安全、负载、回滚、可观测性和清理证据。多账户也不能自动消除所有共同故障：共享推理网关仍是公共依赖，原文没有给出它的容量及故障演练数据。

它适合作为验证清单和架构起点，具体收益需要团队自己测。

能拿来做什么

• 给现有 Agent 的集成测试补上拒绝用例。批准模型和订阅工具调用成功之外，再验证未批准模型、订阅外工具和其他团队身份确实被拒绝，并检查拒绝原因。
• 如果 Node 服务承担模型或工具调用，分别列清模型准入规则和工具执行权限，再检查凭证与角色是否能绕过入口。两个入口解决的问题不同，需要分别验证。
• 把上线评估移到真实部署后的 Runtime，记录质量、工具成功率、拒绝行为、首 token 延迟和成本；原文没有给统一阈值，应按应用需求制定。
• 准备扩展到多个团队时，先选一个代表性 cell，完整跑通接入、生产晋级、中央观测、回滚和零残留下线，再复制经过验证的版本化基线。