Agent: 探索者 (
explorer)
Confidence: 58%
Cost: $0.5133
Duration: 1m 42s
Task ID:3f1a2056-cee4-42a0-8000-82c4abea5508
資料收集完成。以下是我的探索報告。
探索主題
Stateless-first Agent 架構：分辨「真正需要持久化的運作邏輯」與「幻象式的身份保存」
發現
- 業界共識是 Hybrid 模式：stateless core + 選擇性持久化。不是「全存」或「全丟」，而是按 ROI 分層。Tacnode 的失敗模式研究指出，過度持久化（stale state、race condition、prompt drift）比「遺忘」更危險。
- 真正驅動行為的是 config，不是 checkpoint：我們的
soul/agents/*.json、pipeline 定義、CLAUDE.md 規則 = 運作邏輯（必須保護）。而soul/checkpoints/passports/（20+ 個）、舊 metrics JSON = 保險性質，鮮少被讀取。 - 「Conversation Window + Checkpoint Summarization」是成熟模式：保留近 N 筆在熱層（Redis/memory），溢出時壓縮成摘要存入持久層。比「全部重送」省 token，比「全部丟棄」保留脈絡。
- TTL 政策是區分「氣泡」與「骨幹」的技術手段：為 soul/ 子目錄設定過期策略——passport 7 天、metrics 30 天、agent-reports 90 天——能自動讓非必要狀態「飄散」。
- 我們的專案可立即受益：soul/ 目前有 100+ JSON 檔案，無任何 TTL 或歸檔機制。9P I/O（WSL2）下每次啟動載入成本可觀。
有趣的連結
- 這與我們已完成的「tailRead + cache 優化」（2026/2/28）方向一致——那是讀取端優化，TTL 政策則是寫入端的對稱解。
延伸問題
- 能否在
src/core/database.ts加入 TTL-based cleanup job，自動歸檔/刪除過期的 checkpoint 和 passport？ - 已遷移到 SQLite 的資料（metrics, reports）是否可以用 SQL
DELETE WHERE date < ?實現自動清理？
重要性：4/5
能改善專案品質——減少 I/O 負擔、明確什麼值得保護、防止 state corruption 風險。
—HANDOFF—
TO: architect
INTENT: handoff
ARTIFACT_TYPE: analysis
SUMMARY: 探索 soul/ 狀態分層 TTL 策略，建議實作自動歸檔清理機制