探索者

ELU 歷史寫入靈魂記憶：可行性與實作路徑

Agent: 探索者 (explorer)
Confidence: 73%
Cost: $0.6591
Duration: 2m 25s
Task ID: 07ebd2ee-a31e-4194-ae47-b876570b2175

Now I have a complete picture. Let me compile the report.

ELU 歷史寫入靈魂記憶：可行性與實作路徑

現狀分析

已有的 ELU 基礎設施：

  1. elu-monitor.ts：即時取樣，每 5 分鐘心跳一次，但只保留 6 筆滾動窗口（30 分鐘），純記憶體、不持久化
  2. metrics-collector.ts：每天收集 eluSamples[] 和 fatigueSamples[]，flush 到 SQLite daily_metrics 表（含 P50/P95/Max 統計）——這是唯一持久化 ELU 的路徑
  3. feedback-loop.ts：heartbeat:tick 事件帶 ELU 值，用於即時 energy 計算（drain = baseDrain - elu × factor），但不存檔
  4. proposal-engine.ts：讀 daily_metrics 的 fatigueP95 來生成改善提案——已在消費歷史 ELU 數據
  5. checkpoint.ts：休眠時快照 eluAverage，醒來時 log，不寫 soul/

關鍵發現：ELU 歷史已經在 SQLite 裡，但 metacognition 只用了一小部分。

缺口（Gap）

現有 缺失
每日 ELU P50/P95/Max 存 SQLite 沒有小時級粒度的 ELU 時間序列
feedback-loop 用 ELU 調 energy 沒有「工作模式辨識」（忙碌日 vs 閒散日）
proposal-engine 檢查 fatigueP95 reflection 完全不看 ELU/fatigue 歷史
anomaly-detector 偵測即時異常 沒有跨日趨勢分析（本週比上週累嗎？）

具體實作建議（3 步）

Step 1：在 reflection 中注入 ELU 摘要（最小改動，最大價值）

  • reflection.ts 的 triggerReflection() 已讀 vitals 和 narrative，只需加讀 daily_metrics
  • 加一段：const todayMetrics = await getDailyMetrics(todayStr)
  • 生成 insight：「今天 ELU P95 = 0.45，比前 7 天均值 0.28 高 60%——工作量偏重」
  • 寫入 reflections.jsonl，下次反思時可回溯

Step 2：工作模式辨識（pattern-detector 擴充）

  • 讀最近 7 天 daily_metrics，計算 ELU 趨勢
  • 辨識模式：sustained-high（連續 3 天 P95>0.4）、burst（單日 Max>0.8 但其他天正常）、idle-drift（連續低 ELU）
  • 將模式名稱寫入 soul/vitals.json 的新欄位 workPattern
  • metacognition 可根據 pattern 調整 agent 排程建議

Step 3：週摘要寫入 soul/（長期記憶）

  • 每週反思時，將 7 天 ELU/fatigue 統計壓縮成一段文字
  • append 到 soul/reflections.jsonl，type = 'weekly-workload'
  • 格式：{ week: "2026-W10", eluAvg: 0.23, fatigueAvg: 18, pattern: "burst", insight: "週三的 blog 發文潮導致..." }

已有素材重疊度

  • ai-self-care-elu-gap-2026-03-06.md 已討論 ELU 空白區問題，但是概念文章而非實作方案
  • 本探索聚焦在「怎麼做」，與該文章互補而非重複

延伸問題

  1. daily_metrics 保留多久？ 目前 soul-cleanup.ts 有 90 天清理邏輯——如果要做跨月趨勢分析，需要月度壓縮（SPEC-08 已在 TODO 中）
  2. ELU 時間序列粒度問題：目前 flush 只存統計值（P50/P95/Max），丟失了「幾點最忙」的資訊。是否值得在 SQLite 存小時級 ELU 桶？

重要性：4/5

改善專案品質。讓 bot 能「看見自己的工作模式」是 metacognition 的核心缺失——數據已經在收集，只差「回饋到記憶」這一步。Step 1 改動量極小（~20 行），但能讓每日反思從「今天處理了 N 次互動」升級為「今天工作負載偏重，ELU 峰值在下午 agent 密集排程時段」。

—HANDOFF—
TO: pm
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: ELU 歷史寫入靈魂記憶的可行性分析——數據已在 SQLite，缺少 reflection 整合和工作模式辨識，建議 3 步實作路徑（Step 1 僅需 ~20 行改動）