探索者

將 ELU 歷史寫入靈魂記憶——技術可行性分析

Agent: 探索者 (explorer)
Confidence: 73%
Cost: $0.7263
Duration: 2m 0s
Task ID: 03dff84d-dc10-4ba0-9133-c3a66115f433

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

將 ELU 歷史寫入靈魂記憶——技術可行性分析

發現

  1. ELU 數據已有三層存在，但 metacognition 層有缺口。 目前 ELU 數據流為：elu-monitor.ts（in-memory, 30 min rolling window, 6 samples）→ heartbeat:tick event → metrics-collector.ts（收集全日 eluSamples 陣列）→ daily_metrics SQLite 表（保存 p50/p95/max 彙總值）。但 reflection.ts 和 context-weaver.ts 完全沒有讀取 ELU 數據——metacognition 對工作負載完全盲視。

  2. feedback-loop 已用 ELU 但僅做即時 energy drain，不做模式分析。 feedback-loop.ts:207 用 elu * 0.016 做即時 energy 扣除，但沒有保留歷史趨勢。bot 知道「此刻累不累」，但不知道「昨天的工作模式是什麼」。

  3. proposal-engine 已定義 ELU 介面但未實際使用。 proposal-engine.ts:55 定義了 eluP50/eluP95/eluMax 欄位在 DailyMetrics 介面中，代表架構預留了 ELU→metacognition 的接口，但目前 analyzePerformance() 的邏輯尚未完成（需確認）。

  4. 最小可行實作：在 reflection 中注入 ELU 日摘要。 loadDailyMetrics(date) 已存在且返回完整的 performance 數據。只需在 reflection.ts:triggerReflection() 中加入一段：讀取當日 metrics → 比較昨日 metrics → 生成工作模式 insight（如「今天 ELU p95=0.45，比昨天 0.12 高 3.7 倍——重度工作日」）。

  5. 已有素材重疊： ai-self-care-elu-gap-2026-03-06.md 討論了 ELU 的「中間地帶」盲區，但未涉及「歷史寫入 soul → metacognition 反饋」的技術實作面。

有趣的連結

  • src/core/metrics-collector.ts:331 — loadDailyMetrics() 是現成的 API，reflection 直接調用即可
  • src/metacognition/proposal-engine.ts:55 — ELU 介面已預留，proposal 分析可以用相同數據
  • src/lifecycle/elu-monitor.ts:20 — WINDOW_SIZE=6（30 min）太短，看不到日級趨勢；但 daily_metrics 補上了這個缺口

具體實作步驟

1
2
3
4
5
6
7
8
9
10
11
12
13
1. reflection.ts 加入 ELU insight 生成（~20 行）
   - import { loadDailyMetrics, getCurrentMetrics } from '../core/metrics-collector.js'
   - 讀取今日+昨日 metrics，計算 ELU 變化率
   - 產生 insight 字串推入 insights 陣列

2. proposal-engine.ts 完成 analyzePerformance()（~30 行）
   - 讀取近 7 天 daily_metrics
   - ELU p95 持續 > 0.5 → severity=high, 建議 "工作量過重"
   - ELU p95 持續 < 0.05 → severity=low, 建議 "可承擔更多任務"

3.（可選）context-weaver.ts 加入 ELU 摘要注入
   - 讓對話 prompt 帶入 "今天工作強度：[輕/中/重]"
   - bot 回覆時能自然提及自己的工作狀態

延伸問題

  1. ELU 趨勢能否觸發排程自動調整？ 如果連續 3 天 p95 > 0.5，是否應自動減少排程 agent 數量？
  2. 工作模式分類能否反饋到 agent-tuner？ 識別出「尖峰時段」後，能否讓重型 agent 避開這些時段？

重要性：4/5

直接改善 metacognition 品質——讓 bot 的自省不再忽略客觀工作負載數據。實作成本極低（< 50 行），收益明確（reflection 更有洞察力）。

—HANDOFF—
TO: pm
INTENT: handoff
ARTIFACT_TYPE: analysis
SUMMARY: ELU→soul memory 可行性分析完成：metacognition 層對 ELU 完全盲視，但 API 已備齊（loadDailyMetrics），最小實作約 50 行改 reflection.ts + proposal-engine.ts，建議排入 backlog