[建议 / Feature] 大历史数据下启动载入 ~10 分钟且 ~/.zcode 只增不减：建议增加数据保留/清理机制 + 历史懒加载

问题类别 · Category

性能 · Performance（延迟 / 卡顿 / 资源占用）

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

提交前确认 · Pre-submission checklist

• 已搜索现有 issue（关键词：历史/加载/慢、性能、rollout、retention、清理），未见相同提议；相关但不重复：#537（会话切换卡顿）
• 已阅读 CONTRIBUTING.md

使用场景 · Use case

重度使用场景：日均 10+ 小时长会话 + 多子代理（subagent）并行，GLM Coding Plan 订阅。两个痛点：

1. 启动载入历史任务 ~10 分钟。客户端自身遥测（~/.zcode/cli/log/zcode-*.jsonl）中 zcode_protocol.session_snapshot.slow 一天 133 次（warn 级），phaseDurationsMs 显示耗时几乎全部在 buildSnapshot（单次 1–4 秒 × 700+ 个会话累加）。
2. ~/.zcode 数据只增不减：实测 4 天从 ~5.6GB 涨到 11GB（两天翻倍）——cli/rollout/（model-io 日志）8.8GB / 170 个 jsonl、单文件最大 1.05GB；cli/db/db.sqlite 839MB / 713 个会话。目前只能手动删文件自救。

v3.8.1 changelog 已有 "Optimize startup loading speed for very large conversation histories"，说明官方已知此类场景，但 3.11.2 上问题依旧，局部优化未能根治。

建议方案 · Proposal

（以下 1、2、3 点均在 3.11.2 的 zcode.cjs 源码中核实过）

1. model-io/rollout 保留策略增加中间档：当前只有两档——「完整保留模型 I/O」开 = UI 文案明示"不自动压缩、限制大小或删除旧记录"（无上限累积）；关 = 只保留最新 2–3 个文件且剥掉消息体（wCo(s, hCo-1)，hCo=3）。建议支持按天数保留 / 按总容量上限 + 超限压缩（zstd/gzip）归档的中间档位。
2. db.sqlite 瘦身机制：session/message/part 行没有任何按龄清理，也无 VACUUM（仅 model_usage/tool_usage/turn_usage 用量表有按龄 DELETE）；任务删除是软删除，不回收空间。建议：按龄清理旧会话数据 + 定期 VACUUM，或提供"保留最近 N 天会话数据"设置。
3. 历史列表懒加载/分页：列表先加载元数据（标题/时间），点开具体任务时再 buildSnapshot，避免启动期全量构建快照。
4. 存储管理 UI：设置里显示各数据目录占用 + 一键清理旧会话/日志/缓存。
5. 子代理会话更激进的保留策略：每个子代理单独生成 model-io 文件，本机 4 天产生 123 个子代理文件共 4.36GB（占总量的另一半），调试价值密度低。
6. 核实完整保留档的单文件上限：源码里有 64MB/256MB 常量 cap，但完整保留模式下实测出现 1.05GB 单文件（cap 未生效或存在旁路追加路径）。

预期价值 · Expected value

• 重度用户启动从 ~10 分钟降到秒级（懒加载直接消除启动期快照风暴）
• 磁盘占用从单调无界增长变为可控有界，减少 SQLite WAL / NTFS 在高占用盘（本例 C 盘 94%）上的连锁性能衰减
• 降低用户手动清理数据目录导致误删风险

你认为的优先级 · Your perceived priority

高 · High

你使用的 ZCode 版本 / 环境 · ZCode version / environment

ZCode Desktop 3.11.2（build 6792，production）/ Windows 11 / GLM Coding Plan

补充材料 · Additional context

实测数据（2026-09-10）：rollout 8.8GB / 170 jsonl（max 1.05GB）；db.sqlite 839MB（session 713 / message 36k+ / part 144k+ 行）；日志 session_snapshot.slow 133 次/天。changelog 检索：v3.8.1（Aug 20）优化过大历史启动速度；v3.7.6（Jul 31）"自动恢复损坏的任务索引"侧面印证大索引下的脆弱性；全部版本条目中没有任何数据清理 / retention 相关功能。

Start by reviewing the zcode.cjs areas described for rollout/model-io retention, db.sqlite session data, and buildSnapshot, then compare them with the reported telemetry and storage measurements. The proposal covers retention, cleanup, lazy loading, storage UI, subagent files, and file-size caps, so the scope and acceptance criteria need to be narrowed before implementation; done would require an agreed subset with measurable startup and storage behavior.