運作原理¶

流程一圖概覽¶

公開新聞來源(RSS、Yahoo Finance……)
        │
        │ 每 20 分鐘共用爬取一次(Celery Beat)
        ▼
┌─────────────────────────────────────────────────────────┐
│  Per-user fanout(每使用者扇出)                          │
│                                                          │
│   對每位活躍使用者:                                     │
│     1. 用該使用者自選股的別名過濾原始項目                │
│        (本地關鍵字比對,成本低)。                      │
│     2. 合成引擎針對每篇通過的項目                        │
│        並行跑 5 個智慧代理。                             │
│     3. Aggregate + Reflexion 產出 top signal。          │
│     4. 寫入 Signal 列(Postgres,RLS 範圍內)。         │
│     5. Embed 到使用者的 ChromaDB 集合。*(規劃中——      │
│        截至 2026-04-22,`embedding_worker` 仍是 stub;   │
│        Claw chat 目前只透過 BM25 檢索。)*              │
│     6. Publish 到 Redis 頻道 signals:<user_id>。         │
│     7. 把 FLASH + ALERT 推送到 Telegram(若已綁定)。    │
│     8. 把 FLASH + ALERT 推送到 Web Push(若已訂閱)。    │
└─────────────────────────────────────────────────────────┘
        │
        ▼
您的儀表板(透過 WebSocket 即時更新)、您的手機、您的桌機。

核心概念¶

共用爬取、每使用者合成¶

公開新聞爬取在全域做一次——否則十個人同時關注 NVDA,就得打 Yahoo 十次。但 LLM 密集的合成步驟是每 (user, news-item) pair 跑一次,所以評分和 ticker 影響反映的是您自選股的情境,而不是一體適用的單一分數。

五個專職智慧代理,而不是一個¶

我們不用一個大 prompt 問「這則新聞重不重要、為什麼」,而是並行跑五個更小、更聚焦的智慧代理——每個有自己的通道(ticker 事實、總經情境、產業動態、散戶情緒、法規)。它們的輸出以加權平均彙整成最終訊號。詳見智慧代理。

低信心草稿跑 Reflexion¶

當彙整分數落在邊界,引擎會跑一次 reflexion:第二次 LLM 呼叫會批判並改寫草稿。您可以在每條訊號的 Agent breakdown 面板看到它觸發的頻率。

資料庫層的列級安全¶

每張使用者資料表(signals、watchlists、user_settings、rag_query_logs……)都有一條 PostgreSQL RLS 策略:user_id = current_setting('app.current_user')。FastAPI session 以 Postgres authenticated 角色執行——不是超級使用者——所以 RLS 實際強制執行。跨使用者資料外洩由 Postgres 本身擋下,而不是靠應用層程式碼。

下一步¶

智慧代理 —— 五個智慧代理各自做什麼
評分機制 —— 緊急程度分層、impact / confidence、以及 link type
Claw chat(RAG) —— 自由提問如何從您自己的訊號得到答案