Judgment, Oversight & Execution
一個五角色AI團隊,獨立分析盤前新聞,在Alpaca上管理核心-衛星組合,每天收盤後對照SPY基準自我覆盤。24/7跑在一台家用NAS上。
分享這篇案例 →難點在於:硬性風控寫在模型改不了的程式碼裡,還有一個自我提升迴圈——同一個錯誤反覆出現之後,會從一條教訓升級成寫死在程式碼裡的硬性攔截。
APScheduler-based; wakes each expert on a market-driven schedule
Python, Postgres, Alpaca, Claude, DeepSeek, Qwen
一個基於APScheduler的編排器按行情節奏喚醒每個agent。分析師在美東時間08:30用DeepSeek V4 Pro運作——重推理、每天一次——讀隔夜新聞、總體經濟日曆,還有自己過去的教訓,寫出盤前簡報。交易員在09:10到15:50每20分鐘運作一次,用DeepSeek V4 Flash——輕量,每天約21次呼叫——決定開平哪些倉位、多大倉位、停損設在哪。在任何有實質影響的開倉之前,一個挑戰者角色會用Claude Opus覆核同一筆交易——刻意選用和交易員的DeepSeek不同家族的模型,因為同一家族的「第二意見」往往會因為同樣的理由認同自己第一次的錯誤判斷。挑戰者可以否決這筆交易;如果它連不上,系統會選擇放行而不是凍結整個交易檯。評估者在中午用DeepSeek V4 Pro運作,重新檢視每個持倉是否還符合當初的邏輯。覆盤者在收盤時運作,驅動下面的自我提升迴圈。只有交易員能真正下單。
每一個交易決策函式都是純函式——零I/O、零副作用、完全可單元測試。52週高點動能訊號(引用George & Hwang 2004年的研究)即便候選標的沒通過篩選,也會回傳全部診斷欄位,從不做黑箱式拒絕。核心倉位的再平衡器同樣是純函式:沒有I/O、沒有LLM,只輸出一份訂單清單交給一層薄的包裝函式去執行。實際效果是:大約90%的交易邏輯不需要連接真實券商就能單元測試,不需要mock,也沒有測試時誤下真實訂單的風險。
交易員是五個agent裡工具集最豐富的一個,但無論模型怎麼判斷,都要受幾道確定性關卡約束。一套冷卻機制防止它在連續幾輪裡反覆交易同一檔股票——開倉後冷卻120分鐘,評估後未採取行動冷卻40分鐘,而且冷卻時間只會延長、不會縮短。一個出場管理器給每筆平倉都打上標準化的原因標籤,並把持倉超過48小時的標記為「逾期」——這是Triple Barrier方法裡「時間屏障」的純函式實作。在這兩道關卡之上還有一個每日熔斷:只要組合當天回撤達到或超過2%,當天就徹底停止開新倉,沒有例外。如果分析師的盤前簡報缺失或過期,交易員會硬性攔截新開倉,而不是矇著眼交易——這是一條安全預設值,不是模型可以繞過去的建議。
投資組合被機械地拆成兩個獨立倉位。核心倉位(SPY/QQQ/VOO,占60%)用零LLM的drift-band再平衡——純數學計算,只有偏離超過8%才下單。衛星倉位(主動,占40%)完全由LLM驅動,每20分鐘透過DeepSeek V4 Flash自主決策。這個拆分保證了即便衛星agent的判斷完全跑偏,60%的組合依然紋絲不動、緊跟大盤。資本保全是架構層面寫進去的,不只是一條政策。
每個交易日收盤時,覆盤者會計算損益歸因、在多筆交易裡找規律,把帶日期和編號的教訓寫進一份日誌檔案——提交並推送到Gitea,不涉及向量資料庫或RAG流程,git歷史本身就是記憶系統。大多數教訓只是用來充實隔天早上的簡報。但當同一個錯誤反覆出現,它就會「升級」:在多次記錄到「20日均線以下開倉、結果虧損」之後,這條門檻不再只是一條要記住的筆記,而是變成了風控模組裡一條寫死的檢查——把「我們發現這樣做會出問題」閉環成了「程式碼從此不再允許這樣做」。
Python、Claude API、DeepSeek API、Alpaca、Finnhub、EDGAR、pgvector、APScheduler、Docker、自建Gitea Actions CI/CD。