QuantDinger：開源 AI 量化交易工作台，把研究、回測與實單執行留在自己伺服器的 Docker 自架方案

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

把策略程式碼、歷史回測資料、交易所 API 金鑰全部交給雲端量化平台，是很多交易者最猶豫的一步；功能強不強反而是其次，資料主權流失才是真正的痛點。QuantDinger 走的是反方向：它是一套以 Apache-2.0 釋出的開源 AI 量化交易工作台，主打把研究、策略撰寫、回測、模擬與實單執行收回到你自己伺服器上的 Docker 自架方案。這是工具介紹，不是投資建議；實單交易涉及高風險，盈虧自負。

同樣是 Docker 自架的 Python 開源工作台，ai-goofish-monitor 把焦點換到閒魚商品監控，用 Playwright 與視覺模型取代量化回測引擎，示範了「自架服務＋AI 判讀」的另一種切入點。

授權結構先講清楚：QuantDinger 的後端原始碼以 Apache-2.0 釋出（倉庫根目錄的 LICENSE 檔），但桌面網頁前端（QuantDinger-Vue）與行動 H5 / native 客戶端（QuantDinger-Mobile）都是 Open Byte Inc. 自訂的 source-available 授權，商標與商業授權另行管理。換句話說，自架用戶能讀、能改、能再散布的是後端這一層；前端與行動客戶端能讀但不能任意商用再散布。專案由 Open Byte Inc. 維護，GitHub 上累積約 9,897 顆星、2,081 個 fork，最新版本 v5.0.8 在 2026 年 7 月 22 日釋出。值得注意的是，部份早期介紹連結寫的還是舊 owner 帳號 brokermr810/QuantDinger，實際上 GitHub 已經 301 重導向到公司實體 OpenByteInc/QuantDinger，是典型的開發者個人專案轉為公司營運的中間期狀態。專案從 2025 年 12 月 28 日建立，推進速度相當快，v5 後端改造的重點是把 HTTP API 與 long-running 任務徹底拆開，這在量化工具裡屬於比較少見的生產級工程拆分。

Pin

Open Byte Inc. 同時營運託管版本 ai.quantdinger.com 與自架版本，兩條路線共享同一套後端程式碼。選 SaaS 等於把策略、憑證與資料交給 Open Byte Inc. 的雲端基礎設施；選自架等於自己扛 Postgres 資料庫、Redis、worker 進程、備份與資安。對「想試試量化但不想花心力運維」的人來說，SaaS 是合理入口；對「已經有伺服器、想把資料主權留在自己機房」的獨立交易者來說，自架才是這套工具真正的賣點。後續段落以自架路線為主。

從一鍵安裝到六個獨立後端進程

QuantDinger 的部署入口是倉庫根目錄的 install.sh（Linux 或 macOS）與 install.ps1（Windows PowerShell）。安裝腳本會詢問初始管理員帳密、產生所需金鑰、下載 GHCR Compose 映像檔並啟動整個堆疊。裝完之後，本機會開出三個綁在 loopback 的連接埠：8888 是桌面網頁用戶端、8889 是行動 H5 用戶端、5000 是直接打 API 與健康檢查端點。

從 docker-compose.yml 來看，整個服務不是單一 backend 容器吃全部工作。v5 之後的後端圍繞六個獨立進程展開：migration 負責資料庫 schema 遷移並在應用服務啟動前退出；backend 處理 HTTP、驗證與持久命令提交；trading-worker 擁有策略執行階段、未成交訂單、broker 連線與對帳；scheduler-worker 跑組合、部署、付款與訊號排程；celery-worker 處理 AI、回測、實驗、報表與維護任務；celery-beat 發送週期性 Celery 任務。HTTP API 不再 owns long-running trading loops 是 v5 的核心改造，這意味著 API 重啟不會把正在跑的策略打斷。

基礎設施層用 PostgreSQL 18、Redis 8、Celery，並且把 cache Redis 與 job Redis 拆成兩套不同 eviction policy 的實體：cache 走 allkeys-lru 可隨時丟，job 走 noeviction 配合 appendonly 持久化，不能丟。這套設計在工具型開源專案裡屬於比較「重型」的選擇，反映 QuantDinger 對「任務不可遺失」的工程承諾。

需要留意的是 docker-compose.yml 預設時區是 Asia/Shanghai，時區與台灣相同所以直接可用，但你要部署到其他時區的伺服器，記得在 .env 改 TZ。另一項預設值是 POSTGRES_PASSWORD=quantdinger123 與沿用舊版的 quantdinger/123456 管理員帳密，README 明確標示這「不適合網際網路對外的部署，第一次啟動前或首次登入後必須改掉」，而一鍵安裝腳本本身會拒絕 123456 作為密碼。如果你打算用 production overlay 跑對外服務，這組預設值是第一件要換掉的事。

另一個藏在映像檔來源裡的細節：docker-compose.yml 的 base image 預設走 docker.1ms.run/library/python:3.12-slim-bookworm 這類中國鏡像站，BUILD_REGION=cn 會切換到 Aliyun apt 與 PyPI 鏡像。這是貼近中國開發者網路環境的選擇，但對台灣或其他地區的使用者來說，IMAGE_PREFIX 與 BUILD_REGION=global 兩個環境變數可以切回官方 Debian 與 PyPI 來源。

AI 研究助理與 MCP 伺服器是怎麼掛進來的

QuantDinger 的 README 把「AI Multi-Agent 研究系統」定位為研究助理，而非股價預測 AI。它做的事大致涵蓋把網路金融新聞與宏觀資料彙整成研究素材，並根據你的想法生成 Python 策略程式碼框架；回測跑完後也會從結果反推參數調整建議。AI 在這套工具裡負責的是研究與寫程式這一端，買賣訊號的判斷不在它身上。

實際的 AI provider 清單從 README 與 .env.example 可以看出是 BYOK 模式：支援 OpenRouter、OpenAI 相容 API、Google、DeepSeek、Grok、MiniMax 與自訂端點。使用者自填 API key、自己選模型、用量與費用直接向 provider 支付。值得點名的是 DeepSeek 與 MiniMax 屬於中國廠商的 LLM 服務，選擇前要意識到「策略開發過程的對話內容會送到這些 provider」這件事；這條邊界不在 QuantDinger 本身能控制的範圍內，是 BYOK 模型本身的限制。

差異化比較強的一點是內建 MCP 伺服器。QuantDinger 的 Agent Gateway 走 /api/agent/v1 路徑，MCP 伺服器讓 Cursor、Claude Code、Codex 這類外部 AI 客戶端可以呼叫核可過的工具，而不需要拿到 broker 憑證或管理員 JWT。也就是說，你可以在 Claude Code 裡下一句「幫我把昨天那條策略跑一次回測」，中間透過 MCP 把任務轉交給 QuantDinger 的 Agent Gateway，由後端按 scope 與 rate limit 執行。Agent 預設是 paper-only，要走實單必須滿足四個獨立條件，下面會另段說明。

把這條 MCP 整合放回 2026 年的 AI agent 浪潮裡看，定位會更清楚。Claude Code、Cursor、Codex 這類 agentic coding 工具在 2025 下半年到 2026 年間快速成熟，越來越多開發工作流程是「對話式下指令、AI agent 執行」。QuantDinger 把交易工作台的 API 層包成 MCP，等於搭上這波趨勢，讓量化研究與 AI 編碼工具共用同一個資料流。對已經把 Claude Code 當日常開發環境的 Python 工程師來說，這個整合點的吸引力比「再多一家雲端量化平台」更實質。

broker 與交易所整合：十家連接器加 BYOK 金鑰加密

從 README 的整合面表格來看，QuantDinger 目前支援的交易所與 broker 分兩類。加密貨幣交易所部分涵蓋 Binance、OKX、Bitget、Bybit、Gate、HTX、Coinbase Exchange、Kraken；傳統券商部分則有 IBKR（Interactive Brokers）與 Alpaca。這十家都是透過 adapter pattern 串接，README 另外提到「adapter extensions」，表示社群可以自行擴充其他交易所。

值得附帶揭露的是：README 對 Binance、Bitget、Bybit、OKX、Gate.io、HTX 這六家（注意只占十家中的六家）另列有 referral 註冊連結，並明文說 QuantDinger 可能在使用者透過這些連結註冊時收取佣金或手續費回扣。這與 broker 是否被 QuantDinger 支援無關（十家都支援），但反映 upstream 與這六家存在商業合作關係。文章這裡不代為判斷 referral 是否影響你選 broker，純粹揭露 README 透明聲明。

以台灣的使用情境來說，Binance、OKX、Bybit、Bitget 這幾家在台灣有實際使用者群，但合規狀態會隨主管機關公告變動；Coinbase Exchange 與 Kraken 對台灣使用者的可用服務範圍也與當地法規掛鉤。IBKR 與 Alpaca 則是美股與外匯期貨的主要管道。選擇 broker 之前，建議先回該平台官方查最新服務區域與合規公告，這篇文章不代為認定任何一家在台灣的合法狀態。

API 金鑰的處理是另一條誠實軸。Broker 憑證與 MFA 密鑰在 QuantDinger 內以 CREDENTIAL_ENCRYPTION_KEY 加密儲存，而不是明文寫進資料庫；Agent token 則經過 hash、scope 限制、rate limit 與 audit log。這套設計意味著即使 PostgreSQL 資料檔被接觸，沒有加密金鑰也還原不出 broker API secret。生產環境的 production overlay 另外把容器設成 non-root、read-only rootfs、dropped capabilities 與 resource limits，並要求 PostgreSQL 與 Redis 只綁 loopback，對外只能透過 TLS reverse proxy。

自架不等於零風險：實單的四道開關

README 開頭就點明：「QuantDinger can submit real orders when live trading is explicitly enabled. Start with paper trading, use restricted API keys, and review the risk and compliance requirements for your jurisdiction. This project does not provide investment advice.」這是一條 YMYL（Your Money or Your Life）旗標，任何自架量化工具的使用者都應該把它當真。QuantDinger 在這條邊界上做了幾層工程保護：預設 paper_only、live trading 需要四個獨立開關同時成立。

Agent 想透過 MCP 或 Agent Gateway 走實單，必須同時滿足四個獨立條件：token 本身具備 trading scope、該 token 被設成 paper_only=false、伺服器端環境變數 AGENT_LIVE_TRADING_ENABLED=true、operator 設好限額與白名單。四道開關分屬不同設定層（token 後設、伺服器環境、operator 限額），沒有任一個能單獨觸發實單，這是設計上對「AI agent 誤下單」風險的回應。

README 另有法律聲明明文禁止把 QuantDinger 用於市場操縱、制裁規避、洗錢或其他非法用途，並要求 operator 自負各司法管轄區的法規遵循、稅務、broker 條款與資料法規責任。在台灣自架這條意味著自架者要自己搞清楚加密貨幣交易的稅務申報義務、海外券商（IBKR、Alpaca）的申報門檻、以及交易所（Binance、OKX 等）的台灣合規狀態。

對使用者的實際意義是：剛裝好時一切是 paper trading，不會動到真錢；想開實單之前，broker API key 要先用交易所提供的「restricted」權限（例如只開交易、禁止提幣），限額要寫進 operator 設定，並把 AGENT_LIVE_TRADING_ENABLED 留作最後一道顯式開關。把這四道當成部署清單而非阻礙。對自架量化工具來說，「防呆」比「好用」更該被當成設計品質的指標。這裡再次重申：QuantDinger 是工具介紹，不是投資建議。

broker 那一端的 API key 權限分級也很關鍵。以 Binance 為例，交易所後台可以勾選「Enable Spot Trading」但關掉「Enable Withdrawals」，這種受限的 API key 即使外洩，攻擊者也只能下單、不能把資產搬走；OKX、Bybit、Gate、Bitget 都提供類似粒度的權限分級。IBKR 與 Alpaca 的 API 權限模型不同，IBKR 走的是 TWS 或 Gateway 連線 + 帳號級權限，Alpaca 則是 key/secret 配對加上 paper/live 兩組端點。把這些 broker 各自的受限 key 設定流程搞清楚，是自架量化工具上線前的必要功課。

跟 TradingView、Freqtrade、nautilus_trader 比起來差在哪

把 QuantDinger 放回開源量化交易生態裡看，定位會比較清楚。

TradingView 的強項在於龐大的歷史資料、社交圖表與 Pine Script 生態，但策略程式碼、圖表、回測結果都留在雲端，QuantDinger 想處理的正是這一塊；對「不想把 API 金鑰交給第三方」的人來說，這條邊界比圖表好不好看更重要。Freqtrade 與 Backtrader 著重在純 Python 的策略回測與執行，生態成熟但沒有 QuantDinger 這種「研究助理 + MCP + broker credentials 加密」整合的工作台層；nautilus_trader 更貼近底層事件驅動框架，適合寫高頻策略的工程師，不適合想要 GUI 與 AI 輔助的使用者。

另一個值得提的差異是：QuantDinger 同時有 Live SaaS（ai.quantdinger.com）與自架兩條路線。想保留資料主權的人選自架；想省運維負擔的人選 SaaS，但 SaaS 等於把策略程式碼、broker 金鑰交給 Open Byte Inc. 營運的雲端。這條二選一是 QuantDinger 比純開源框架（Freqtrade/nautilus_trader）多出來的商業模式選擇，使用者要清楚自己在哪一邊。

活躍但仍有 Bug：截至 2026 年 7 月的問題清單

從 GitHub 開放議題追蹤來看，QuantDinger 處於快速迭代的活躍期，但仍然存在已知 Bug 與未完成功能，這部分是任何想投入使用的讀者都該先看的。

2026 年 7 月的開放議題類型集中在幾個面向：#181 是回測時間 BUG（7 月 22 日開）；#178 是組合策略執行時間問題；#177 反映 MDD（最大回撤）metric 可能不正確；#171 則是「配置 AI/LLM 後做診斷分析正常，但策略研發顯示 Chat API 尚未接入」，意味著部分 AI 整合流程仍在開發中。Windows PowerShell 安裝路徑也有已知問題（#170），加密貨幣幣對新增流程有未修 Bug（#168）。整體來看，回測引擎的時間處理與績效 metric 計算這兩塊是 7 月這波議題的主戰場，要把 QuantDinger 用在正式回測之前，建議先在 paper trading 模式下完整跑過你想用的策略類型。

Pin

v5.0.8 在 2026 年 7 月 22 日釋出，multi-arch 映像檔同時支援 amd64 與 arm64，可以從 GHCR 拉取：docker pull ghcr.io/OpenByteInc/quantdinger-backend:v5.0.8。整個 v5 後端的改造重點是把 HTTP API 與 long-running 任務徹底拆開，這對穩定性是正向訊號，但也代表從 v4 升級要跟著調整部署架構。

適合誰、不適合誰

QuantDinger 對「獨立交易者加 Python 開發者」這個交集群體最有價值。你已經會寫 Python、知道 Pandas 與 NumPy 在做什麼、想把散落的策略腳本整合進一個有 GUI 與 AI 輔助的環境、同時不接受把 API 金鑰交給第三方。這個組合下的讀者會比較能發揮它的價值。

對「只想看圖表、不想部署伺服器」的人來說，TradingView 或各交易所原生圖表會更輕；對「只想跑加密貨幣自動交易、不在乎 GUI」的人來說，Freqtrade 的 CLI 流程更直接；對「要寫高頻或事件驅動策略」的工程師，nautilus_trader 的底層抽象更貼手。QuantDinger 的甜區是「想自己顧機器、想用 MCP 讓 AI agent 幫忙跑回測、想把研究到實單整段收在自己基礎設施」這個需求組合。

部署負擔也要誠實說：六個獨立後端進程加上 PostgreSQL、Redis、可選的 Prometheus/Grafana/Alertmanager 監控堆疊，這是生產級的基礎設施規模。沒有 Linux 伺服器與 Docker Compose 經驗的人，第一次架起來可能會花不少時間在排查 port binding、volume 掛載與映像檔來源上。如果你的需求只是「跑個簡單回測看看」，可以先用 paper trading 模式裝在本機，跑通了再考慮搬上伺服器。

常見問答

QuantDinger 是開源嗎？

後端是 Apache-2.0，允許商業使用、修改與再散布，附帶專利授權條款；桌面網頁前端（QuantDinger-Vue）與行動客戶端（QuantDinger-Mobile）則是 Open Byte Inc. 自訂的 source-available 授權，能讀但不能任意商用再散布。Open Byte Inc. 另外營運 Live SaaS 版本（ai.quantdinger.com），自架版本與 SaaS 版本共享同一套後端程式碼。

預設是實單還是模擬？

預設是 paper trading（模擬交易）。Agent 透過 MCP 或 Agent Gateway 走實單需要四個獨立開關同時成立：token 具備 trading scope、該 token 設為 paper_only=false、伺服器 AGENT_LIVE_TRADING_ENABLED=true、operator 限額與白名單設定完成。建議先在 paper 模式完整測過策略，再考慮開實單。

AI 會幫我預測股價嗎？

不會。QuantDinger 的 AI 是研究助理角色，做的是聚合網路金融新聞、輔助寫 Python 策略程式碼框架、根據回測結果反推參數調整建議。它不提供投資建議、不預測股價方向，也不保證策略績效。BYOK 模式下你自填 LLM provider key（OpenAI、DeepSeek、MiniMax 等），用量與費用向 provider 支付。

在台灣部署要注意什麼？

部署時要注意時區、映像來源與 broker 選擇這幾件事。時區方面，docker-compose.yml 預設 Asia/Shanghai，台灣時區相同所以不需改，但部署到其他地區要在 .env 改 TZ。映像方面，BUILD_REGION=cn 預設用 Aliyun 鏡像，在中國境外網路下可切回 global 走官方源。broker 方面，加密貨幣交易所（Binance、OKX、Bybit 等）在台灣的合規狀態要自行追蹤主管機關公告，IBKR 與 Alpaca 走的是海外券商路線，相關稅務與申報責任由使用者自負。

已知的 Bug 與未完成功能？

截至 2026 年 7 月 22 日的開放議題：回測時間 BUG（#181）、組合策略執行時間（#178）、MDD metric 可能不正確（#177）、Windows PowerShell 安裝問題（#170）、加密貨幣幣對新增 BUG（#168）、AI/LLM 配置後策略研發尚未接入 Chat API（#171）。實際投入前建議先追蹤對應 issue 的修復狀態。

對「結構化金融資料」這個主題有興趣的讀者，也可以參考我們對 巴菲特股東信知識庫 的分析。同樣是處理大量財經文件，但那是把歷史股東信結構化成可檢索的知識圖譜，與 QuantDinger 的即時交易工作台是不同切角。

結語：自架是手段，紀律才是門檻

把這幾個面向綜合起來，可以整理出一份部署前的決策清單，方便讀者快速檢查自己適不適合投入。基礎條件這一端，你需要一台能跑 Docker Compose 的 Linux 伺服器（或本機開發環境）、對 PostgreSQL 與 Redis 有基本操作經驗、以及對 broker API 權限分級的掌握。策略條件這一端，你已經有想回測或自動化的交易想法，而不只是「想找一個能看 K 線的工具」。風險條件這一端，你接受 paper trading 作為上線前的必經階段，願意把四道實單開關都設好，並理解 broker API key 在自己伺服器等於自己扛資安與合規責任。這三組條件都成立，自架才會比用 SaaS 更划算；任一組薄弱，回到 SaaS 或純回測框架會更省事。

QuantDinger 解決的問題不在於「量化能不能做」，而在於「這段從研究到實單的流程，你想不想放在自己機器上」。把它架起來，得到的是一套 Apache-2.0、可審計、可改寫的量化工作台；失去的是雲端 SaaS 那種「打開瀏覽器就能用」的便利。對獨立交易者與 Python 工程師來說，這個交換是划算的，前提是你願意花時間把基礎設施架對、把四道實單開關設清楚、並且接受 YMYL 邊界。工具再強，最終承擔盈虧的還是你自己。如果你想再往上一層，把 AI agent 與 MCP 帶進自己的研究流程，這套工具目前的整合深度在同類專案裡屬於前列。

對相同主題有興趣的讀者，可以一併參考我們對 Data-Analysis-Agent 這套自然語言轉 SQL 的 AI 資料分析助手 的分析，兩者在「AI 輔助分析」這個維度上屬於同一個討論脈絡；或者看看 TablePro 開源資料庫客戶端，了解 self-host 工具鏈在資料庫介面這一層的選項。