Ninth Wave 在 Amazon Bedrock 上搭多智能体接入系统

接入开放金融网络的银行，各家应用程序接口（API）的字段命名和格式规范都不一样。据 AWS 介绍，验证这些 API、把字段映射到 Financial Data Exchange（FDX）标准、并评估是否具备上生产的条件，过去要靠专业人员花数周时间，在邮件往来和电子表格之间完成。

Ninth Wave 负责金融机构与第三方应用之间的数据连接，对接 Plaid、Finicity、MX 等数据聚合方，以及 Intuit QuickBooks、Xero、Sage 等会计系统。其平台按 FDX 标准对银行 API 做归一化，银行只需接入一次即可触达整个网络。为了让接入过程变成自助式，公司开发了助手 Compass，运行在 Amazon Bedrock AgentCore 上。

七个专用智能体取代单一智能体

团队先试过在 Amazon EC2 上自托管模型，控制权完整但运维负担增加；也试过单智能体的检索增强生成（RAG）方案，结构更简单，但在字段映射、分析、检索和交互问答上准确率都偏低。多智能体架构前期更复杂，好处是每个智能体只做一件事，拥有自己的上下文和指令提示。编排由 Strands Agents 框架承担：识别意图，再把请求分发给七个专用智能体之一。

上下文在应用层组装。调用智能体之前，Compass 会从 Amazon OpenSearch Service 和 Amazon S3 中按租户维度的索引与前缀，取出该银行自己的 API 文档和配置数据。虽然各家银行共用同一套模型基础设施，这层隔离用于避免一家银行的信息进入另一家的会话。就绪度分析是唯一从 Amazon Bedrock 知识库检索的智能体，原因是它需要在 FDX 参考资料上做综合。

安全方面，流量经 Amazon CloudFront 和 AWS WAF v2 进入，会话在 AWS Fargate 上的 Amazon ECS 中，对接启用多因素认证的 OAuth2/OIDC 身份提供方完成校验。人工智能负载则跑在独立账号的 AgentCore 运行时中，通过跨账号 IAM 角色调用。

完整架构见 AWS 博客文章。