摘要： Ninth Wave 用 Amazon Bedrock AgentCore 打造 Compass，把開放金融上線流程交給七個專責代理協作。系統採用意圖路由、依任務選模型與租戶範圍 grounding，降低 context 干擾並隔離每家銀行資料。FDX readiness 分數由應用程式碼確定性計算，不交給模型推估，以滿足稽核要求。
開放金融的整合難題，核心並不在模型能力本身，而在於每家銀行端出的 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 在自己的範圍內行使。
對產品建置者的啟示
這個案例有幾項取捨值得一提：多代理的複雜度，換來的是每個任務的準確度與可維護性；在合規要求之下，租戶範圍的 grounding 屬於必要設計；確定性評分則把模型輸出與稽核需求切開來各自處理。
假如你正在規劃的 AI 產品要處理多種任務，而且對資料隔離的要求很嚴，不妨直接把「每個代理只做一件事」當成預設架構，而不是等到 prompt 開始互相干擾之後才回頭重構。