一句话结论
亚马逊云科技发布 AgentCore Gateway，结合 MCP 协议实现多账户 AI 代理架构，将数据隔离于业务线账户，仅通过网关统一调度工具与推理服务。
关键要点
- AgentCore Gateway 作为中央枢纽，支持 HTTP 目标、AgentCore Runtime 代理及 A2A 服务，提供单一端点用于跨业务线（LOB）工具发现与调用。
- LOB 团队通过 MCP over Streamable HTTP 部署独立服务器，数据保留在各自账户中，仅查询时流出特定数据，架构采用 Hub-and-Spoke 模式。
- 安全机制使用 OAuth 2.0 M2M 凭证，LOB 服务器通过 Okta OIDC 端点验证令牌，生产环境限制运行时调用仅接受包含 Gateway 身份链的请求。
- AgentCore Policy 以 ENFORCE 模式运行，使用 Cedar 策略语言执行默认拒绝模型，可限制如 transfer_funds 至特定角色，阻止 delete_customer 操作。
- 新 LOB 上线仅需添加 Gateway 目标，代理通过 tools/list 方法在下次调用时发现新工具，无需更新现有代理或 MCP 服务器。
背景与事实
亚马逊云科技（AWS）在其机器官方博客发布了一项开发实战指南，展示了如何利用 Bedrock AgentCore Gateway 与 Model Context Protocol（MCP）构建多账户 AI 代理架构。该架构的核心设计原则是将数据保留在各自业务线（Line of Business，LOB）账户中，仅在实际查询时流出特定数据，而非集中存储。中央平台账户托管代理层及大语言模型（LLM）推理服务，LOB 团队则负责将自身数据封装为 MCP 服务器。
AgentCore Gateway 在这一架构中扮演枢纽角色，提供单一端点用于跨注册 LOB 的工具发现与调用。它支持多种目标类型，包括 HTTP 端点、AgentCore Runtime 代理以及 Agent-to-Agent（A2A）服务。具体而言，LOB 团队通过 MCP over Streamable HTTP 部署独立的 MCP 服务器，Gateway 则作为枢纽聚合这些端点。AgentCore Runtime 提供了一个无框架依赖的执行环境，具备会话隔离、专用微型虚拟机、按消费定价以及内置认证功能，确保了多租户场景下的隔离性与成本可控性。
在安全与治理层面，Gateway 从 AgentCore Identity 获取 OAuth 2.0 机器对机器（M2M）凭证，并将其附加至出站请求。LOB 服务器通过 Okta OIDC 端点验证这些令牌。MCP 服务器使用 FastMCP 框架构建，配置 customJWTAuthorizer 以验证来自 Okta OIDC 端点的入站 OAuth 令牌。在生产环境中，通过 allowedWorkloadConfiguration 限制运行时调用，仅接受包含 Gateway 身份链的请求。此外，AgentCore Policy 以 ENFORCE 模式运行，使用 Cedar 策略语言执行默认拒绝模型，精确控制工具调用权限。例如，策略可限制 transfer_funds 工具仅对特定角色可用，并阻止 delete_customer 操作，从而在代理行为层面实施细粒度访问控制。
评估与监控通过 AgentCore Evaluations 实现。在线评估对生产流量的 10% 样本进行评分，使用内置评估器追踪工具选择准确性等指标，相关数据展示于基于 Amazon CloudWatch 的仪表板中。系统还支持按需评估，允许在持续集成/持续部署（CI/CD）流水线中回放场景。AgentCore Optimization 功能分析生产环境中的执行跟踪，推荐改进措施。当需要更新代理提示词或模型时，必须发布新版本并更新端点，这一过程不影响 LOB 的 MCP 服务器。通过 Gateway 进行 A2A 测试后，基于统计显著性结果推广配置变更。
在成本与部署方面，数据平面成本保留在 LOB 账户，而 LLM 推理和网关调用成本在平台账户通过执行角色标签进行分配。数据平面日志投递至 CloudWatch Logs，控制平面操作由 CloudTrail 捕获。启用数据事件日志可追踪单个工具调用，组织级审计跟踪将日志聚合至专用账户。生产环境支持 VPC 连接及 AWS PrivateLink 接口端点，AgentCore Runtime 默认的公共网络模式仅适用于开发环境。新 LOB 的接入流程极为简化，仅需添加 Gateway 目标，代理即可通过 tools/list 方法在下次调用时发现新工具。部署脚本使用 AWS Cloud Development Kit（CDK）跨四个账户引导资源，并在 Amazon ECS 上部署 React Web 应用作为前端。
影响分析
对于中文开发者与企业架构师而言，该架构提供了一套可落地的多租户 AI 代理治理方案。传统单账户部署模式在企业级场景中面临数据孤岛与合规挑战，而 AgentCore Gateway 结合 MCP 的 Hub-and-Spoke 架构将数据主权保留在业务线账户，仅通过标准化协议交换必要信息，符合金融、医疗等强合规行业的数据驻留要求。Cedar 策略语言与默认拒绝模型的结合，为代理行为提供了可编程的安全边界，开发者无需修改底层 MCP 服务器即可通过策略引擎动态调整工具权限。这一设计显著降低了代理系统的安全审计成本，使企业能够以最小权限原则管理 AI 代理的操作范围。
从工程实践角度，新 LOB 接入仅需添加 Gateway 目标而无需更新代理本身，大幅降低了多业务线协同扩展的维护成本。按消费定价与执行角色标签的成本分配机制，使企业能够将 LLM 推理成本精确归因至特定业务单元，解决 AI 项目预算核算难题。不过，该架构依赖于 Okta 等第三方身份提供商，且生产环境需额外配置 PrivateLink 与 VPC 连接，对现有基础设施有一定改造要求。中文企业在采用时需评估其身份系统与 AWS AgentCore Identity 的集成成本，以及 Cedar 策略语言的学习曲线对开发团队的影响。
适用边界
该结论不适用于数据需要集中存储与全局分析的场景，因为架构核心原则是数据保留在 LOB 账户，仅查询时流出。对于无法部署在 AWS 多账户体系或无法使用 Okta OIDC 端点验证令牌的企业，需调整安全配置。AgentCore Runtime 默认公共网络模式仅适用于开发环境，生产环境必须启用 VPC 连接与 PrivateLink，不适用于对网络隔离无要求或无法配置私有端点的场景。此外，10% 的生产流量在线评估采样率可能不适用于低流量或高合规要求需全量审计的场景。
孤本观察
该架构将 MCP 从单一工具协议提升为企业级多租户服务总线，Gateway 的 tools/list 动态发现机制在扩展性上优于静态注册，但 Cedar 策略与 M2M 凭证的复杂性也意味着实施门槛高于单账户部署。这是判断该方案在大型企业落地时需权衡的核心矛盾。
常见问题
新业务线（LOB）接入 AgentCore Gateway 架构需要修改现有的 AI 代理或 MCP 服务器吗？
不需要。新 LOB 接入仅需添加 Gateway 目标，代理通过 tools/list 方法在下次调用时即可自动发现新工具，无需更新现有代理或 MCP 服务器。
生产环境中 AgentCore Runtime 的网络连接模式有何限制？
AgentCore Runtime 默认的公共网络模式仅适用于开发环境。生产环境必须启用 VPC 连接及 AWS PrivateLink 接口端点，不支持仅使用默认公共网络模式。
在线评估机制对生产流量采用多大的采样率？
在线评估对生产流量的 10% 样本进行评分，使用内置评估器追踪工具选择准确性等指标，并展示在基于 Amazon CloudWatch 的仪表板中。
AgentCore Policy 使用什么策略语言执行权限控制，其默认模型是什么？
AgentCore Policy 使用 Cedar 策略语言执行默认拒绝模型。在 ENFORCE 模式下，可精确控制工具调用权限，例如限制 transfer_funds 至特定角色或阻止 delete_customer 操作。
该多账户架构的数据安全机制依赖哪些身份验证组件？
Gateway 从 AgentCore Identity 获取 OAuth 2.0 M2M 凭证，LOB 服务器通过 Okta OIDC 端点验证令牌。生产环境限制运行时调用仅接受包含 Gateway 身份链的请求。