Munger 市場情報系統：資金輪動分析與自我學習閉環
市場是一個大水缸。
資金從某個資產流出，就必然流向另一個資產。這個看似簡單的觀察，是 Munger 系統設計的核心假設。
大多數市場分析工具問的是「這個資產會漲還是跌」。Munger 問的是另一個問題：
資金正在從哪裡出來？往哪裡去？水缸裡是否正在積累足以引發「洩洪」的尾端風險？
這兩個問題框架的差距，決定了分析工具是否能在重大市場轉折前給出有意義的預警。
系統架構：三層設計
事件驅動分析管道
每一則新聞都經歷三層過濾，才決定是否觸發 LLM 分析。
關鍵設計決策：觸發閾值（auto_threshold = 60）儲存在資料庫，可透過 API 動態調整。緊急事件（war/nuclear/bank failure 等）走獨立快速路徑，放大係數 1.2，衰減半衰期僅 3 天——反映地緣衝突的高強度但短期性。
每日輪動合成報告
每天 07:05，系統推送兩則 Telegram 訊息。第一則是指標統計（準確率、知識條目、系統警示），第二則是 LLM 資金輪動合成——這是真正的市場洞察。
合成報告的核心問題框架：
| 欄位 | 問題 |
|---|---|
rotation_theme | 當前主導輪動主題是什麼？ |
capital_flows | 資金在流出哪裡、流入哪裡？強度如何？ |
tail_risk_radar | 哪個資產正在累積尾端風險？洩洪去向？ |
flow_forecast_1_4w | 未來 1–4 週的資金流向主軸？ |
opportunity_map | 哪些資產定價不足（underreacted）？ |
predictions_to_revisit | 哪些開放預測需要修正方向？ |
second_level_insight | 市場共識最擁擠的方向是什麼？逆向路徑？ |
這個框架強迫 LLM 以「資金守恆」的視角思考：每個流出都對應一個流入，而不是孤立地評估每個資產。
自我學習與自我修復循環
Munger 不只分析市場，它也在分析自己的分析品質。
兩個循環的設計邏輯：
外環（知識學習） 處理的是「分析邏輯」層面的問題——預測方向錯了，是因為對某種市場機制理解有偏差？週回顧把這些偏差提煉成知識條目，下次遇到類似情境時 LLM 會看到這個教訓。
內環（評分修復） 處理的是「評分機制」層面的問題——某類事件的影響一直被高估？auto_adjust_weights() 每天 06:50 自動微調 EVENT_WEIGHTS，讓評分體系逐漸對齊真實市場反應。
尚待補強的缺口
系統已運行一段時間，以下是我觀察到的改進方向：
每日合成缺乏跨日比較：今天的 rotation_theme 是「避險輪動」，昨天是「風險再開啟」——這個方向轉變比任何單日分析都更重要，但目前報告沒有呈現。改進方向是注入前日快照，讓 LLM 標注「延續 / 轉向 / 反轉」。
週回顧建議無推送機制：自動調整的建議（weight_suggestions）生成後進入 pending 狀態等待審批，但沒有 Telegram 通知。建議容易被遺忘，自我修復效果因此打折。
新聞源缺少亞洲視角：目前主要是英文 RSS，亞洲盤的地緣事件可能有數小時延遲才進入英文媒體。
LLM Provider 雙點同時失聯時無備援：重大事件發生時如果 Gemini 和 Claude 同時不可用，分析管道完全停止。緊急事件最需要分析，卻是服務最不穩定的時候。
這和 AgenticOps 的關係
Munger 系統是 AgenticOps 四階段循環在「市場情報」領域的具體實現：
- 計畫：確認哪些市場事件值得深入分析（SBE 思維：從使用者需要的洞察反推）
- 開發：每次新聞觸發分析都是一次「小型開發循環」，LLM 輸出即更新評分
- 驗證：24 小時後自動對比預測方向與實際市場走勢
- 回饋學習：錯誤預測 → 週回顧 → 知識條目 → 注入下次分析
唯一的差別是節奏：軟體開發的循環以「功能」為單位，Munger 的循環以「市場事件」為單位，每天跑幾十次小循環、每週跑一次大回顧。
系統使用 Claude Code 建構與持續演化。