探索者

探索主題

Agent: 探索者 (explorer)
Confidence: 83%
Cost: $0.4795
Duration: 2m 16s
Task ID: b36e9d62-18a2-44da-a439-c9b90ebc2335

Now I have the full picture. The existing blog post (2/17) covers agent metrics failures as a snapshot. My dream seed points to something deeper and more actionable: when “success” itself drifts. Our codebase already has Z-score anomaly detection for system metrics, but lacks concept drift detection on agent performance metrics. This is a genuine gap.

Here’s my exploration report:

探索主題

Goodhart 效應偵測：當 Agent 的「勝利」指標悄悄變質

發現

  • 我們的系統有指標盲點：anomaly-detector.ts 用 Z-score 偵測系統資源異常（RSS、ELU），但 agent 的成功率、成本、產出品質等「業務指標」完全沒有漂移偵測。analyst.ts 用成功率決定進化策略（>80% → aggressive），但從不質疑「成功率本身是否還可信」。

  • ADWIN 演算法適合我們的場景：它會自動調整滑動視窗大小，偵測兩段資料的均值是否顯著不同。比固定視窗的 Z-score 更能捕捉「緩慢漂移」（例如 agent 成功率從 85% 花兩週慢慢降到 70%，Z-score 每天看都不異常）。MITRE 的 menelaus 庫提供 Python 實作。

  • Goodhart’s Law 已在我們系統顯現：analyst.ts:62-66 的邏輯是「成功率 > 80% → 可以更大膽」。但如果 agent 的「成功」定義本身在漂移（例如 blog-writer 每次都「成功」產出文章，但品質逐漸下降、主題重複），這條規則就會把系統推向更激進但更空洞的產出。

  • 具體可實作方案：在現有 anomaly-detector.ts 框架上擴展，新增一個 MetricDriftDetector 類別，對 agent 的 cost/task、completion_time、retry_count 等指標做雙視窗比較（Page-Hinkley test），當累積偏差超過閾值時觸發 metric:drift 事件。

  • 「延遲命名」模式（deferred labeling）值得引入 pattern-detector.ts：目前的模式偵測器在偵測到重複模式後立即建立 skill。但有些模式需要「再長一會兒」—— 可以加一個 incubation period（例如至少觀察 7 天、跨 3 個不同 context 出現），避免把短期巧合固化成永久 skill。

有趣的連結

  • 我們 2/17 的文章〈當數字打臉直覺：agent 系統的成功率危機〉討論的正是這個問題的「症狀」版本——61% 成功率是表象，深層問題是我們只看瞬時快照，不追蹤趨勢漂移。
  • pattern-detector.ts 的「一回生二回熟」哲學（Arc 的原話）和「延遲命名」形成有趣對話：重複 ≠ 該固化，有時候重複的東西正在變形，過早命名會凍結它。

延伸問題

  • 能否在 get_agent_trends MCP tool 的基礎上加一層 ADWIN 漂移偵測，讓 agent-tuner 在調參前自動檢查「這個指標最近是否在漂移」？
  • pattern-detector.ts 加入 incubation period 後，需要什麼 UI 讓主人看到「正在孵化中的模式」？

素材重疊度評估

既有文章〈當數字打臉直覺〉聚焦於單次快照分析（成功率 61% 的診斷），本次探索聚焦於時間維度的漂移偵測，角度不同但有部分重疊（約 30%）。若要寫新文章，建議定位為「續篇：從快照到趨勢」。

重要性：4/5

能直接改善 agent 系統的品質管控——目前缺乏趨勢漂移偵測是真實的架構盲點，修復後可避免「虛假成功」累積導致的隱性退化。