8.0
热点
AI SCORE
技术实践2026-09-14 23:58
Ninth Wave 基于 Amazon Bedrock 构建 AI 开户助手，周期从数周压缩到分钟级
AWS ML Blog#AWS#Agent#金融科技
Editor brief · 编辑速览
Ninth Wave 在 Amazon Bedrock AgentCore 上搭建多 Agent 开户系统，集成银行 API 验证、FDX 标准合规评分和 SOC2/PCI DSS 要求，全流程从数周缩短到分钟级。
参与开放金融（银行通过标准化 API 与第三方应用共享客户授权财务数据的网络）的金融机构面临一个持续的集成挑战。每家银行的 API 都有自己的字段名称、格式约定，以及相对于金融数据交换（FDX）标准的各种缺口。验证这些 API、映射字段、评估生产连接就绪程度，传统上需要跨多个邮件线程和电子表格，花费数周的专家工作。
Ninth Wave 在金融机构和第三方应用之间提供安全的数据连接，将它们连接到 Plaid、Finicity、MX 等聚合商，以及 Intuit QuickBooks、Xero、Sage 等会计系统。该系统将银行 API 标准化为 FDX 标准，因此银行只需一次性集成到 Ninth Wave 平台，即可触达整个开放金融网络。为进一步提升入职效率和响应能力，Ninth Wave 构建了 Compass，这是一款由 Amazon Bedrock AgentCore 驱动的 AI 赋能入职助理。Compass 提供协作式自助服务体验，同时继续满足 Ninth Wave 已建立的安全和金融服务合规标准。
在本文中，我们描述了 Ninth Wave 如何在 Amazon Bedrock AgentCore 上设计和部署用于受监管、特定领域工作流的多智能体系统。我们将介绍 Compass 背后的多智能体架构、基于银行自身数据进行接地的方法、生产环境中按任务配置模型的方案，以及支持企业安全需求的更广泛 AWS 技术栈。
Ninth Wave Compass 旨在通过自助服务门户提升入职体验，银行工程师、聚合商集成团队和 Ninth Wave 的入职团队在共享的 AI 赋能工作空间中协作。
该项目有三个需求：
提升入职效率 —— 简化 API 验证、字段映射和就绪程度评分，有效利用工程资源，加快响应时间，并在团队之间保持一致、最新的信息。
为外部合作伙伴提供受治理的 AI 体验 —— 为银行开发者和金融科技合作伙伴提供可靠的 AI 支持洞察，辅助集成决策，同时延续 Ninth Wave 的基础承诺：多租户数据隔离、内容安全控制和审计日志。
维持金融服务合规标准 —— 在 Compass 中继续 Ninth Wave 已建立的安全和合规实践，包括最小权限访问静态加密和传输中加密，以及符合 SOC 2 和 PCI DSS 要求。
我们评估了 Amazon Elastic Compute Cloud（Amazon EC2）上的自托管模型，这种方案提供完全控制但带来额外开销；也评估了单智能体检索增强生成（RAG）模式，这种方案更简单，但在映射、分析、搜索和交互式问答方面的准确性较低。多智能体架构前期更复杂，但每个智能体专注于单一任务，拥有自己的上下文和指令提示词。不存在争夺提示词空间的问题，准确性随任务类型数量增长。Amazon Bedrock AgentCore 提供托管的智能体运行时来托管和扩展这些智能体，而 Strands Agents 框架处理编排逻辑：意图分类和专家之间的路由。
三个设计决策定义了该架构：
基于意图的路由 —— 编排器一次性对用户意图进行分类，并路由到正确的专家。每个智能体的上下文窗口保持干净，输出保持可预测。
按任务选择模型 —— 轻量级模型处理高流量任务，高推理能力模型处理映射、分析和交互式问答。我们将模型能力与任务复杂度相匹配，而不是将所有任务都通过一个模型路由。
租户作用域的接地 —— 在调用智能体之前，应用程序将该银行自身的上下文组装到请求中。这实现了每个租户对每个智能体可见内容的控制，因此一家银行的数据不会进入另一家银行的会话。
Amazon Bedrock 在单一服务下提供托管的多智能体编排、多种模型访问和企业安全控制（AWS Identity and Access Management（IAM）、AWS Key Management Service（AWS KMS）、私有网络），因此团队可以专注于领域逻辑而不是大型语言模型（LLM）基础设施。关于各 AWS 区域的模型可用性，请参阅 Amazon Bedrock 中的按 AWS 区域划分的支持模型。
以下架构图说明了 Compass 如何端到端处理入职请求。编号步骤对应于系统中的数据流。
步骤 1：边缘安全 —— 流量通过 Amazon CloudFront（TLS 1.2+、HSTS）和 AWS WAF v2（默认拒绝 Web ACL）进入。由于 Compass 同时为外部银行开发者和内部用户服务，所有请求在到达应用逻辑之前都会被限定到单个租户：AWS WAF 提供边缘层流量保护，应用授权将每家银行限制在其自己的入职工作空间中。请求然后路由到内部 Application Load Balancer（TLS 1.3）。
步骤 2：身份验证和身份 —— Amazon Elastic Container Service（Amazon ECS） on AWS Fargate 针对强制执行多因素认证（MFA）的 OAuth2/OIDC 身份提供者验证会话。身份提供者将银行的租户身份传递到下游服务，下游服务使用它来限定每个数据查询。它从 AWS Secrets Manager（每个环境客户托管的 KMS 密钥）检索凭证，AWS IAM 强制执行最小权限访问，AWS CloudTrail 记录支持的 AWS API 活动。
步骤 3：租户作用域的接地 —— 在调用智能体之前，Compass 从 Amazon OpenSearch Service（每个租户索引）和 Amazon Simple Storage Service（Amazon S3）（每个租户前缀）获取该特定银行的上下文。引擎将该银行自己的 API 文档、配置数据和先前的交互上下文组装到请求中。租户作用域的上下文组装旨在防止一家银行的信息被包含在另一家银行的智能体会话中，尽管两者共享相同的模型基础设施。
步骤 4：多智能体编排 —— 接地的请求通过跨账户 IAM 角色进入专用 Amazon Bedrock AgentCore 运行时，这会在账户级别将 AI 工作负载与应用工作负载分离以控制爆炸半径。基于在 AgentCore 上运行的 Strands Agents 构建的主 Compass 智能体对意图进行分类并路由到七个专家之一：
每个智能体都在有边界的上下文窗口内运行。编排器的分类步骤有助于防止提示词稀释。映射请求不会与文档搜索争夺 token 空间。这种分离使得系统能够扩展到新的任务类型而不会降低现有智能体的准确性。
步骤 5：知识库检索 —— Readiness analysis 是唯一从 Amazon Bedrock 知识库检索的专家。这是一个有意的范围决策：其他智能体完全在应用层接地（步骤 3），这使团队能够完全控制检索逻辑和排序。Readiness analysis 是例外，因为它需要综合处理太大的 FDX 参考文档语料库，无法在单个请求中传递。这使得 RAG 成为该特定智能体的正确模式。
步骤 6：FDX 就绪程度评分 —— 就绪程度评分在应用代码中根据 OpenSearch 中必填字段映射覆盖范围确定性地计算，而不是由模型估算。与字段覆盖绑定的确定性计算以审计要求满足的方式处理，这是概率模型输出无法做到的。
步骤 7：可观测性 —— ECS 向 Amazon CloudWatch 发出每个智能体的指标（调用次数、token 使用量、延迟、成本），CloudWatch 通过 Amazon Simple Notification Service（Amazon SNS）触发警报，并向 Amazon Managed Grafana 仪表板提供数据。按智能体维度化的指标使团队能够在单个智能体级别检测回归，而不是仅仅将其视为系统级问题。
智能体行为和安全约束在应用层按每个智能体强制执行。这使团队能够调整一个智能体的范围和输出边界而不影响其他智能体。
我们用五个聚焦的冲刺交付了 Compass，每个冲刺都建立在前一个的基础上。
我们配置了核心基础设施：具有每个租户索引的 Amazon OpenSearch Service、用于文档存储和知识库内容的 Amazon S3，以及使用 AWS Cloud Development Kit（AWS CDK）管理的跨专用工作负载、Bedrock 和共享服务账户的 AWS CloudFormation 堆栈。我们在每个任务模型组合的情况下配置了 Amazon Bedrock AgentCore，并建立了用于工作负载到 AgentCore 通信的跨账户 IAM 角色。
我们构建了银行工程师和聚合商合作伙伴交互的门户界面，包括自动映射指南生成、入职脚本和定制品牌合作伙伴门户。
我们部署了基于在 Amazon Bedrock AgentCore 上运行的 Strands Agents 构建的主编排器和专家智能体，集成了租户作用域接地，并建立了用于就绪程度分析的 Amazon Bedrock 知识库。
因为 Compass 向外部合作伙伴提供 AI，安全加固是一个专用阶段：
Compass 继续 Ninth Wave 已建立的安全和合规实践，包括最小权限访问静态加密和传输中加密，以及符合 SOC 2 和 PCI DSS 要求。
我们于 2026 年 3 月 1 日将 beta 客户入职到实时应用。生产环境于 2026 年 5 月 15 日就绪，2026 年 6 月 1 日全面上市。
多智能体 AI 系统需要在两个层面实现可观测性：基础设施健康和智能体行为。Compass 对两者都进行了检测。
Amazon CloudWatch 监控基础设施：负载均衡器延迟、Amazon ECS 任务数量和 OpenSearch 集群健康。每个环境的 Amazon SNS 主题将警报路由到值班团队。应用层自定义指标跟踪 Amazon Bedrock 调用次数、token 使用量、延迟和成本，按智能体维度化。这种细节级别将问题隔离到单个智能体级别，而不仅仅是系统故障。
我们的持续集成和持续交付（CI/CD）管道通过 GitHub Actions 运行。每次推送都会构建容器镜像、将其推送到 Amazon Elastic Container Registry（Amazon ECR）、注册新的 ECS 任务定义，并执行到 AWS Fargate 的滚动部署和断路器回滚。断路器自动回滚健康检查失败的部署。当提示或接地变更可能在指标浮出水面之前影响智能体准确性时，这种保护措施尤为重要。
借助 Amazon Bedrock AgentCore，Ninth Wave 通过自助式、AI 赋能的体验增强了其已建立的入职流程。这种体验提高了效率和响应能力，同时在整个集成过程中支持银行、聚合商和金融科技合作伙伴。Compass 延续了 Ninth Wave 对安全、治理和金融服务合规的基础承诺。
API 映射和分析时间减少 95% —— AI 赋能的能力自动化该流程，提高效率，在几分钟内交付结果。
增强入职协作 —— 集中式、AI 赋能的工作空间改善了协调、信息一致性和跨参与团队的响应能力。
扩展自助服务支持 —— 文档聊天机器人和 API Explorer 帮助外部开发者快速获取集成问题的答案。
更高效的就绪程度评分 —— 自动化能力提供更快、更一致的评估，同时优化工程资源。
合作伙伴自助服务 —— 每个银行都有定制品牌的开发者门户，可用于邀请聚合商和金融科技合作伙伴进行自助服务。
如今该系统按智能体跟踪 Amazon Bedrock 调用量、token 使用量、延迟和成本，以及基础设施健康指标，让运营团队对入职性能有实时可见性。
在本文中，我们描述了 Ninth Wave 如何构建 Compass，这是一个用于开放金融的多智能体 AI 入职系统。Ninth Wave 基于 Amazon Bedrock AgentCore 和 Strands Agents 编排框架构建了它，采用按任务模型组合、租户作用域接地和企业级 AWS 安全基础。通过用自助式 AI 体验增强其已建立的入职流程，Ninth Wave 实现了 API 映射和分析时间减少 95%。
"AI 从根本上改变了金融机构构建、集成和创新的方式，但它需要对底层基础设施的信任。Compass 代表了我们将智能、治理和自动化整合在一起的愿景——使银行能够更快入职、降低运营复杂性，并为下一代 AI 驱动的金融服务构建所需的可信基础。"
—— George Anderson，Ninth Wave 创始人兼 CEO
作为下一步，探索以下资源：
开始使用 Amazon Bedrock AgentCore。
了解如何使用 Amazon Bedrock Knowledge Bases 为智能体响应接地。
阅读更多关于金融服务中的代理 AI：如何为多智能体系统选择正确的模式。
访问 Ninth Wave Compass 了解更多。