背景
我在玩 Polymarket——一個基於加密貨幣的預測市場。你可以買入「某事件會發生」或「不會發生」的合約，價格反映市場共識的機率。如果你認為市場定價錯了，就有套利空間。
一開始是手動看新聞、手動下單。後來想自動化，畢竟我已經有一個跑在 VPS 上的 AI agent（用 OpenClaw 串接 Telegram），何不讓它幫我盯盤？
第一版：全自主 agent
最初的版本很粗暴：
- 每 30 分鐘，cron 喚醒 AI agent
- Agent 自己用 CLI 查持倉、掃新聞、分析信號、下單
- 所有邏輯都在一個大 prompt 裡
問題很快浮現：
- 成本高：每次喚醒都用高階模型（因為需要推理能力），30 分鐘一次，token 消耗驚人
- 不可預測：同一組資料，不同次執行可能產生完全相反的結論
- 難以除錯：出了問題很難回溯「當時為什麼這樣決定」
- 浪費算力：90% 的時間市場沒有變化，agent 做了一堆分析然後什麼都沒做
核心矛盾：資料收集不需要推理能力，但決策需要。把兩者混在一起，等於用高階模型的價格做低階模型的工作。
第二版：分層架構
改版的核心想法：分離收集與決策，只在需要時才啟動高階模型。
┌─────────────┐ ┌──────────────┐ ┌─────────────┐
│ Cron 排程 │────▶│ 資料收集層 │────▶│ 決策層 │
│ (每 30 min) │ │ (低成本模型) │ │ (高階模型) │
└─────────────┘ └──────────────┘ └─────────────┘
│ │
有信號時才觸發 審閱 + 下單
│ │
┌──────▼──────┐ ┌─────▼──────┐
│ Exit 檢查 │ │ Telegram │
│ 新聞掃描 │ │ 回報結果 │
│ 跟單偵測 │ └────────────┘
└─────────────┘
資料收集層
一個 shell script 串接多個 Python 模組，每次執行輸出一份 JSON 摘要：
# collect.sh 的邏輯
# 1. 查餘額（CLI，不需要 LLM）
# 2. 跑 exit_manager.py（規則式，不需要 LLM）
# 3. 餘額夠才跑新聞掃描（需要 LLM，用低成本模型）
# 4. 輸出 JSON 到 stdout
Exit Manager 是純規則引擎，不需要任何 LLM：
# 三個出場條件，硬編碼
if percent_pnl >= 30:
reason = "take_profit"
elif percent_pnl <= -50:
reason = "stop_loss"
elif end_date and (end_date - now) < three_days:
reason = "expiry"
新聞掃描器 才用到低成本模型。它從多個來源（自建的社群摘要 pipeline、公開新聞源）抓最新資訊，交給模型分析是否有市場還沒反映的事件：
# 只看不確定的市場（Yes 價格在 0.20-0.80）
# 只看有流動性的市場（volume > $10K）
# 用低成本模型分析新聞 vs 當前定價是否有偏差
markets = [m for m in markets
if 0.20 <= get_yes_price(m) <= 0.80
and get_volume(m) > 10000]
決策層
關鍵設計：沒有信號就不喚醒高階模型。
# cron-wrapper.sh
TOTAL=$((HAS_EXIT + HAS_NEWS + HAS_COPY))
if [ "$TOTAL" -gt 0 ]; then
# 用 system event 通知高階 agent
openclaw cron add \
--name "polymarket-decision" \
--at "1m" \
--system-event "有 ${TOTAL} 個信號需要審閱..." \
--session main \
--wake now \
--delete-after-run
else
echo "No signals, skipping"
fi
高階模型收到通知後：
- 重新執行
collect.sh取得最新資料 - 審閱每個信號的合理性
- 決定是否執行（可以否決低成本模型的建議）
- 用 CLI 下單
- 透過 Telegram 回報結果
為什麼不全部用規則？
既然 Exit Manager 已經是純規則，為什麼新聞掃描不也用規則？
因為新聞分析本質上需要語言理解。你要判斷「某則新聞是否已經被市場定價反映」，這不是 if-else 能處理的。但這個判斷的品質要求沒有最終決策那麼高——它只需要「發現可能的機會」，不需要「做出完美的決策」。
這就是分層的意義：
| 任務 | 需要 LLM？ | 品質要求 | 適合的模型 |
|---|---|---|---|
| 查餘額、查持倉 | ❌ | N/A | CLI 直接跑 |
| 止盈/止損判斷 | ❌ | 規則即可 | Python 腳本 |
| 新聞掃描 | ✅ | 中（召回率 > 精確率） | 低成本模型 |
| 最終交易決策 | ✅ | 高（要考慮多因素） | 高階模型 |
實際效果
成本下降
舊版：每 30 分鐘喚醒高階模型 → 一天 48 次 → 大量 token 消耗 新版：低成本模型跑收集，90% 的時間沒信號 → 高階模型一天可能只被喚醒 2-3 次
可追溯性
每次收集的 JSON 都寫 log，可以回溯：
[2026-03-02 17:00:05] === 資料收集開始 ===
[2026-03-02 17:00:06] 餘額: $41.11
[2026-03-02 17:00:08] Exit signals: 1
[2026-03-02 17:00:08] 執行進場掃描...
[2026-03-02 17:00:15] News: 0 signals
實戰成績
架構上線後的幾筆交易：
- 某地緣政治事件合約 No：+41.4%（23 shares，自動止盈賣出）
- 某軍事行動合約 No：+40.7%（33 shares，自動止盈賣出）
兩次都是 Exit Manager 偵測到獲利超過門檻 → 通知高階模型 → 審閱確認 → 執行市價賣出 → Telegram 回報。整個流程從偵測到執行大約 2 分鐘。
踩過的坑
1. 低成本模型的 thinking 行為
我用的低成本模型（某家 API 相容服務）有個特性：它永遠會產生 thinking block，即使你設定 thinking: disabled 也沒用。
當輸入資料量大時（150+ 篇文章），thinking 會膨脹到 16000+ tokens，直接吃完 max_tokens 配額，導致實際回應被截斷。
解法： 設定 budget_tokens 限制 thinking 長度（我設了 2000），強制模型把 token 預算留給實際輸出。
2. 已結算倉位的幽靈信號
Exit Manager 會遍歷所有持倉，但已經結算的倉位（合約到期、結果確定）會顯示 cur_price: 0。如果不跳過，每次都會產生「虧損 100%」的假信號。
# 簡單但重要的一行
if cur_price == 0:
continue
3. 餘額不足時的無效掃描
新聞掃描需要呼叫 LLM API，有成本。如果餘額只剩 $5，就算找到機會也沒錢買。所以加了門檻：
if (( $(echo "$BALANCE >= 30" | bc -l) )); then
# 才跑新聞掃描
fi
4. Agent 自己把自己搞混
第一版讓 agent 同時負責分析和執行時，偶爾會出現它「說服自己」的情況：分析完覺得不該買，但在同一個 context 裡又找到一個理由，然後就買了。
分離收集和決策後，高階模型收到的是「乾淨的信號列表 + 原始資料」，沒有前一輪的分析結果干擾，決策品質明顯提升。
下一步構想
Copy Trading 模組
Polymarket 上有些大戶的勝率很高。計畫追蹤特定錢包的交易紀錄，當他們建倉時產生信號。這也是「收集層」的工作，不需要高階模型。
多市場關聯分析
目前每個市場獨立分析，但現實中事件是關聯的。例如「A 國是否出兵」和「B 資產是否漲」可能高度相關。這需要更複雜的推理，適合高階模型處理。
自動調整門檻
止盈 30%、止損 50% 是硬編碼的。理想的做法是根據市場類型（政治 vs 體育 vs 金融）和到期時間動態調整。規則式引擎可以做到一定程度，但完整的動態策略可能需要 LLM 輔助。
總結
這個專案最大的收穫不是交易本身，而是驗證了一種 AI agent 的架構模式：
能用腳本的不用 LLM。能用便宜模型的不用貴模型。把決策權留給品質最高的環節。
這不只適用於預測市場。任何需要「監控 → 篩選 → 決策 → 執行」的場景都可以套用：
- 監控： cron + CLI（零 LLM 成本）
- 篩選： 規則引擎 + 低成本模型（低成本）
- 決策： 高階模型（只在需要時啟動）
- 執行： CLI + API（零 LLM 成本）
最貴的資源應該花在最需要判斷力的地方。其他的，自動化就好。