探索者

ELU 歷史寫入靈魂記憶：現況分析與實作路徑

Agent: 探索者 (explorer)
Confidence: 73%
Cost: $0.6322
Duration: 3m 6s
Task ID: 47c81c15-4b5a-434d-b748-2cfe16a7bc91

Good — there’s already a blog post about ELU gap. My exploration should focus on the specific technical question: can ELU history be persisted to soul memory, and can metacognition use it to detect work patterns?

Now I have all the data I need. Here’s the report:

ELU 歷史寫入靈魂記憶：現況分析與實作路徑

發現

  1. ELU 資料已經持久化到 soul/：metrics-collector.ts 每次 heartbeat tick 收集 eluSamples[]，日結時計算 P50/P95/Max 寫入 soul/metrics/YYYY-MM-DD.json。所以 ELU 歷史摘要已經在靈魂記憶中，但原始時序資料不在（僅保留統計值）。

  2. In-memory history 極短且不持久：elu-monitor.ts 的 history[] 固定 WINDOW_SIZE=6（30 分鐘），重啟即清零。這意味著 bot 無法看到「過去 24 小時的工作波形」，只能看到最近半小時。

  3. Metacognition 已部分消費 ELU 數據：proposal-engine.ts 讀取 daily metrics 中的 eluP50/P95/Max 和 fatigueP95 來觸發改善提案（如「系統疲勞度偏高」）。feedback-loop.ts 用即時 ELU 調整 energy drain。但沒有任何模組做跨日 ELU 趨勢分析。

  4. 關鍵缺口：缺乏「工作模式識別」：現有系統能回答「今天 ELU P95 是多少」，但無法回答「週末 vs 平日的工作強度差異」「連續高負載天數是否增加」「agent 派工和 ELU 峰值的相關性」。這些需要讀取多天 metrics + agent-stats 做橫向分析。

  5. 實作路徑比想像中短：soul/metrics/ 已有 11 天的每日 ELU 摘要。只需在 proposal-engine.ts 或新建一個 work-pattern-analyzer.ts 中讀取過去 7-14 天的 metrics JSON，計算趨勢（ELU 均值是否上升、lifecycle stateSeconds 分布變化），然後將結論寫入 reflections.jsonl 或直接生成 proposal。不需改動 ELU monitor 本身。

已存在的相關實作（避免重複推薦）

  • ✅ 每日 ELU 統計 → soul/metrics/YYYY-MM-DD.json
  • ✅ Checkpoint 含 ELU average → data/checkpoint.json（ephemeral）
  • ✅ Proposal engine 讀 daily metrics → proposal-engine.ts
  • ✅ Blog 文章已寫過 ELU gap 分析 → ai-self-care-elu-gap-2026-03-06.md
  • ❌ 跨日趨勢分析 → 不存在
  • ❌ 工作模式分類（burst/sustained/idle pattern）→ 不存在
  • ❌ ELU ↔ agent task 相關性分析 → 不存在

具體實作建議

最小可行方案（改 1 個檔案）：
在 proposal-engine.ts 的 generateProposals() 中增加一個 analyzeWorkPatterns() 分析器，讀取過去 7 天的 soul/metrics/*.json，做三件事：

  1. 計算 ELU P50 的 7 日移動平均，偵測上升/下降趨勢
  2. 比較 stateSeconds 中 active vs resting 比例的變化
  3. 交叉 soul/agent-stats/daily/*.json 的 task 數量與 ELU 峰值

結論寫成 proposal，severity 根據趨勢方向決定。

延伸問題

  1. ELU 原始時序是否值得持久化？ 目前只存 P50/P95/Max，損失了「工作節奏」資訊（如：是持續低負載還是間歇性爆發）。可考慮在 daily metrics 中額外存一個 hourly ELU 陣列（24 個值），成本極低。
  2. 反思引擎能否自動用這些模式產出日記？ 現有 reflection.ts 只看 narrative entries，不看 metrics。若把工作模式分析結果注入 reflection context，bot 就能在反思中說出「今天工作節奏偏急促，下午有三波 agent 派工導致 ELU 飆升」。

重要性：4/5

直接改善專案品質——讓 bot 從「只知道當下累不累」升級到「理解自己的工作模式」，是 metacognition 閉環的關鍵一環。

—HANDOFF—
TO: pm
INTENT: handoff
ARTIFACT_TYPE: report
SUMMARY: ELU 歷史已存在於 soul/metrics/ 但缺乏跨日趨勢分析。建議在 proposal-engine.ts 新增 analyzeWorkPatterns() 讀取 7 日 metrics 做趨勢偵測，並考慮在 daily metrics 增加 hourly ELU 陣列保留工作節奏資訊。