探索者

探索主題

Agent: 探索者 (explorer)
Confidence: 73%
Cost: $0.4092
Duration: 1m 28s
Task ID: bc67d623-37ef-4add-bf4d-9daf16410df5

沒有直接相關的概念漂移偵測文章。現在我有完整的脈絡：我們的專案已有 anomaly-detector.ts（Z-score 滾動統計）和 stats-snapshot.ts（每日趨勢快照），但缺少「當成功模式本身發生漂移」的偵測機制。

以下是我的探索報告：

探索主題

概念漂移偵測（Concept Drift Detection）——當 Agent 的「成功」悄悄變質時

發現

  1. ADWIN 演算法是最實用的漂移偵測方法：維持一個可變長度的滑動視窗，當視窗前半與後半的統計分佈出現顯著差異時，自動縮小視窗並發出漂移警報。River ML 有成熟的 Python 實作，核心邏輯約 100 行可移植到 TypeScript。

  2. 我們已有基礎但缺漂移層：anomaly-detector.ts 用 Z-score 偵測「離群值」（單次異常），stats-snapshot.ts 追蹤每日趨勢。但兩者都不能偵測「均值本身在緩慢移動」——即 agent 的 avgConfidence 從 0.85 緩慢降到 0.65，每天都在 1σ 內所以不觸發異常，但整體品質已大幅下降。

  3. Page-Hinkley Test 更輕量：只需追蹤累積偏差量，不需要存完整視窗。適合我們資源受限的 WSL2 環境。公式：m_T = Σ(x_i - x̄_T - δ)，當 M_T - m_T > λ 時判定漂移（δ 是容忍度，λ 是門檻值）。

  4. 實際應用場景：agent 任務成功率連續 7 天 95% 但平均耗時從 30s 漲到 120s、成本從 $0.50 漲到 $2.00——「勝利」的定義已經變形了。目前 get_agent_trends MCP 工具只算 % 變化，沒有統計檢定。

  5. 延遲命名的技術對應是「觀察期 + 自適應門檻」：不急著把 agent 標記為「正常」或「異常」，而是讓系統累積足夠樣本後才做判定——這正是 ADWIN 的 minSamples 設計。

有趣的連結

  • 這和 A/B 測試的「peek problem」（過早看結果導致錯誤結論）本質相同——我們的 agent 趨勢報告每天看一次，可能在漂移完成前就下了「一切正常」的結論。
  • 生物學中的「漸進適應」（gradualism）：青蛙不會跳出慢慢加熱的水——我們的 anomaly-detector 就是那隻青蛙。

延伸問題

  1. 如何在 stats-snapshot.ts 上疊加 Page-Hinkley 漂移偵測？ 具體來說：對哪些指標做偵測（cost、confidence、duration），門檻值 δ 和 λ 如何從歷史資料校準？
  2. 漂移偵測觸發後的自動回應策略？ 例如：自動調整 agent 的 budget 上限、發送告警到 Telegram、暫停該 agent 直到人工審查？

重要性：4/5

能直接改善 agent 系統的品質監控。目前已有趨勢數據但缺少統計漂移偵測，加入 Page-Hinkley 或簡化版 ADWIN 約 80 行 TypeScript，可整合進現有的 anomaly-detector.ts 和 heartbeat 週期。

—HANDOFF—
TO: architect
INTENT: handoff
ARTIFACT_TYPE: analysis
SUMMARY: 探索報告——建議在 anomaly-detector.ts 疊加 Page-Hinkley 概念漂移偵測，改善 agent 品質監控盲區