開放金融的整合瓶頸不在模型能力，而在每個銀行的 API 都有自己的欄位名稱、格式慣例，以及與 FDX 標準之間的落差。Ninth Wave 原本需要數週的人工驗證與對應，現在透過 Compass 這個 AI onboarding 助理，把流程變成一個多代理協作系統。
為什麼選擇多代理而不是單一 RAG
Ninth Wave 評估過三種做法：在 EC2 上自架模型、單一代理加 RAG、以及多代理架構。自架模型控制力最高但維運成本也高；單一代理較簡單，但在對應、分析、搜尋與互動問答等不同任務之間，準確度會互相稀釋。
多代理架構的前期複雜度較高，但每個代理只專注一種任務，有自己的 context 與指令。團隊在 AWS Machine Learning Blog 的文章中指出，這樣「沒有 prompt space 的競爭，準確度會隨著任務類型數量而擴展」。
實際的執行環境是 Amazon Bedrock AgentCore，負責託管與擴展這些代理；而 Strands Agents 框架處理意圖分類與路由。
三個關鍵設計決策
架構的核心是三個決策：
- 意圖路由：orchestrator 只分類一次，就把請求送給對應的專責代理。每個代理的 context window 保持乾淨，輸出也比較可預測。
- 依任務選模型：輕量模型處理高頻率任務，高推理模型處理對應、分析與互動問答。團隊是「把模型能力對齊任務複雜度，而不是把所有東西都丟給同一個模型」。
- 租戶範圍的 grounding：在呼叫代理之前，應用程式會先組裝該銀行自己的 context 到請求裡。這樣可以控制每個代理看到什麼，避免一家銀行的資料進入另一家銀行的 session。
七個專責代理與一個例外
Compass 的 Primary Agent 會把請求路由到七個 specialist：搜尋、文件問答、文件分類、欄位對應、分析、互動工作流程，以及 readiness 分析。
其中只有 readiness 分析會使用 Amazon Bedrock Knowledge Bases 做 RAG。這是刻意的範圍決策：其他代理完全在應用層做 grounding，讓團隊對檢索邏輯與排序有完整控制權。Readiness 分析需要綜合大量 FDX 參考文件，無法放進單一請求，所以 RAG 是那個特定代理的正確模式。
FDX readiness 分數則是在應用程式碼中，根據 OpenSearch 裡的必填欄位覆蓋率做確定性計算，而不是由模型估計。這種做法能滿足稽核要求，機率性的模型輸出做不到。
租戶隔離與可觀測性
因為 Compass 同時服務外部銀行開發者與內部使用者，每個請求在進入應用邏輯之前，都必須先限定到單一租戶。AWS WAF 提供邊緣層防護，應用程式授權則把每家銀行限制在自己的 onboarding workspace。
在可觀測性方面，ECS 會把每個代理的指標（呼叫次數、token 用量、延遲、成本）送到 CloudWatch，再觸發 SNS 警報並饋入 Grafana 儀表板。以代理為維度做指標，團隊可以在個別代理層級偵測回歸，而不是等到整個系統出問題才發現。
這種把 AI 工作負載與應用工作負載分離到不同 AWS 帳戶的做法，也呼應了我們先前討論過的流程編排執行模型：先決定誰能做決定，再談工具。Ninth Wave 在這裡的決定是，讓 orchestrator 只做分類，讓每個 specialist 在自己的範圍內做決定。
對產品建置者的啟示
Ninth Wave 的案例有幾個值得參考的取捨：多代理的複雜度換來的是每個任務的準確度與可維護性；租戶範圍的 grounding 是合規要求下的必要設計；而確定性評分則是把模型輸出與稽核需求分開處理。
如果你正在規劃一個需要處理多種任務、且對資料隔離有嚴格要求的 AI 產品，可以考慮把「每個代理只做一件事」當成預設架構，而不是等到 prompt 互相干擾之後再重構。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。