多交易所 Algo Trading 操作架構
一個與交易所解耦的 Algo Trading 操作層，由 adapter contract 連接研究、回測、模擬盤、受控實盤、風控與可觀測性；目前以 UMX 作為第一個實作。
這個項目證明甚麼
AI Agent 協助程式探索、實作、測試及文件整理；系統邊界、風控規則、操作流程與發布判斷由我負責。
目前以 UMX adapter 驗證的去敏感化架構與可診斷 Paper-to-Live 設計；其他交易所 adapter 屬清楚標示的發展路線。
證據路徑
最近核證2026-08-24一眼分清已上線、受保護與下一步。
公開案例只展示已清理的系統邊界與控制語義；帳戶、策略、倉位、P&L 及內部端點保持排除，多交易所兼容亦不提前當成完成項。
已清理的目標架構
公開圖只保留 Venue Adapter、研究、執行、風控與可觀測性之間的通用邊界，不含內部識別資料。
第一個 Venue Adapter 實作
UMX 是目前已實作的交易所邊界；Portfolio 說明 adapter contract 與操作責任，不公開 SDK 密鑰或帳戶資料。
策略、帳戶與實盤結果
策略參數、持倉、P&L、客戶及真實交易結果不屬公開證據；合成情境只用來解釋控制語義。
Binance、OKX 與 Coinbase Adapters
多交易所 contract 是明確方向，但目前不聲稱三個額外 adapter 已完成或已投入實盤。
2加密資產與證券 API 領域
4研究、回測、模擬、實盤驗證階段
3限頻重試、斷線恢復、狀態確認防線
問題
策略若直接綁定單一交易所 API，市場資料、下單規則與狀態處理很快便難以移植。核心問題是建立穩定的 adapter contract，同時讓研究、回測、模擬盤與實盤共用一致語義。
做法
以 UMX SDK 作為目前第一個 venue adapter，並在其上設計與交易所解耦的 Algo 操作平台，把市場資料、策略、執行、帳戶、風控、研究記錄與監控分成可獨立演進的服務層。
結果
一個正在演進的多交易所架構基礎：目前 UMX adapter 支援完整策略生命週期；下一步可在不重寫策略與風控核心的前提下加入 Binance、OKX 與 Coinbase adapter。
由交易所 Adapter 到可受控的策略生命週期
以統一 contract 包裝行情、帳戶、下單與事件流；目前由 UMX 實作，並把限頻、重試、重連和交易所特定規則留在邊界內。
策略研究、參數化回測與交易成本模擬共用同一套 signal semantics，減少由研究搬到執行時的偏差。
模擬盤先驗證狀態與行為；實盤在下單前檢查數量、最低名義價值、帳戶與風控條件，只有確認成功才推進狀態。
風控規則、系統事件、連線健康、策略診斷與研究記錄形成可追蹤的操作層，而不是把問題留在散落日誌中。
互動式控制路徑
一個 Intent，三種完全不同的狀態決定
切換交易所回應，觀察相同策略意圖如何經過風控、Adapter 與證據判斷。這是合成控制情境，不代表真實訂單或交易結果。
去敏感化情境沒有訂單或帳戶資料
Strategy Intent
純計算只提出方向與數量意圖，不先改變策略狀態。
Risk Gate
檢查權限、數量、最低名義價值、限制與資料新鮮度。
Venue Adapter
隔離認證、精度、限頻、重試及交易所特定語義。
Venue Evidence
把接受、拒絕、逾時及後續事件正規化為明確證據。
Strategy State
只按已確認證據 commit、hold 或進入 reconciliation。
狀態決定COMMIT
已確認接受，狀態才可以推進
Adapter 收到可識別及可關聯的接受證據，執行層保存結果後，策略才把 intent 標記為已處理。
- 01Intent 建立，策略狀態未改變
- 02Pre-trade checks 通過
- 03Adapter 正規化 venue request
- 04接受證據已確認並保存
- 05Strategy state 安全推進
狀態決定HOLD
明確拒絕是「沒有執行」的證據
拒單原因被正規化並保留作診斷；策略狀態不推進，修正條件後可建立新的 intent，而不是假裝原請求成功。
- 01Intent 建立，策略狀態未改變
- 02Pre-trade checks 通過
- 03Venue 明確拒絕 request
- 04Adapter 保存正規化原因
- 05State 保持，等待修正或新 intent
狀態決定RECONCILE
Timeout 不是失敗，也不是成功
沒有足夠證據時禁止盲目重試，避免重複副作用。系統凍結狀態，透過查詢、事件流或人工操作完成 reconciliation。
- 01Intent 建立，策略狀態未改變
- 02Request 已送出但確認逾時
- 03結果標記為 uncertain
- 04自動重複下單被阻止
- 05進入 reconciliation queue
公開界線： 只展示控制語義及故障處理；API key、帳戶、策略參數、倉位、P&L、內部 endpoint 與真實交易結果全部排除。
最重要的規則：狀態必須跟隨證據
策略只產生意圖；下單前風控攔截無效請求，Venue Adapter 隔離交易所差異。只有明確確認的結果才推進策略狀態；拒單、逾時或不確定結果保留為可診斷及可重試事件。
這個項目不是單一 Dashboard，而是一個將交易所接入與策略核心分開的架構：Venue Adapter 負責交易所差異，Algo 平台負責策略生命週期、風控、執行及操作可觀測性。
目前第一個 adapter 來自日常開發的 UMX framework。UMX 的公開網站說明其 WebSocket／REST API 面向算法交易與專業交易團隊；這裡只把它作為現有實作證據，而不是整個架構的品牌。SDK 與 Dashboard 原始碼、API 憑證、帳戶、策略參數及真實交易結果仍保持私有。
我的範圍：第一個 Venue Adapter 與 Algo 平台架構
我參與目前 UMX adapter 的可靠性建設，包括 rate limiting、HTTP retry、WebSocket reconnect 與 staleness detection；在應用層則以交易所無關的 contract 設計策略研究、回測、Paper Trading、Live Trading、Execution、Risk、Monitoring 與操作介面。平台仍在持續演進，因此不把未完成的其他 adapter 或 UI 包裝成成熟產品。
Paper 成功，不代表 Live 安全
模擬盤很容易讓每次下單都看似成功，但實盤會遇上最低下單量、餘額不足、交易所拒單、網絡延遲、過期行情與連線中斷。核心狀態規則因此非常明確：只有執行層確認成功，策略才可以把 signal 標記為已處理。 下單失敗時保留重試能力和診斷證據，避免策略狀態與真實持倉脫節。
Risk 必須在下單之前
平台把憑證加密、數量精度、最低名義價值、持倉限制、最大回撤及策略狀態放在執行鏈上，而不是事後才生成一份風險報表。系統事件、連線健康與 diagnose 流程讓操作人員能回答「策略為何沒有交易」，而不是逐行翻查容器日誌。
多交易所兼容與 SimpleTerminal 的協同方向
目前實盤執行以 UMX adapter 為基礎；下一階段目標是在同一 contract 下加入 Binance、OKX 與 Coinbase，將各所的認證、限頻、精度及拒單語義留在 adapter 內。SimpleTerminal 繼續負責跨所公共行情觀察，再把經研究與風險閘門批准的意圖交給 Algo 平台。這是明確的兼容路線，並非聲稱多交易所實盤或跨市場套利已經完成。