Three storage tiers — Rules, Wiki, Raw — with write gating and periodic maintenance forming a fully automated knowledge loopRules · Wiki · Raw 三层存储，写入门控与每周维护构成全自动知识闭环
The core tension for a long-running agent is a bounded context window against an ever-growing body of experience. This system partitions agent memory into three storage tiers — always-resident rules (Rules), a structured knowledge base (Wiki), and raw session records (Raw) — each with a strict injection budget governing its share of the LLM context. Every write passes through a gate (deduplication, supersession, conflict detection); the knowledge base is maintained by periodic lint passes; and raw records are distilled daily back into the wiki, forming a knowledge loop that requires no manual curation.长期运行的 Agent 面临的核心矛盾是：上下文窗口有限，而经验持续累积。本系统将 Agent 记忆划分为三个存储层——常驻规则（Rules）、结构化知识库（Wiki）、原始会话记录（Raw）——并以严格的注入预算控制每层进入 LLM 上下文的份额。知识的写入经过门控（去重、取代、冲突检测），知识库本身由周期性 lint 维护，原始记录经每日蒸馏回流知识库，形成不依赖人工整理的知识闭环。
The three tiers have orthogonal roles: Rules are injected unconditionally, Wiki is recalled on demand, and Raw serves only as material for search and distillation — it is never injected directly.三个存储层职责正交：Rules 无条件常驻，Wiki 按需召回，Raw 仅作检索与蒸馏的原料，从不直接注入。
Figure 1图 1 — System architecture. Left: three write paths pass through a unified gate into the Wiki; center: the three storage tiers; right: three budgeted channels into the LLM context.系统架构。左：三条写入路径经统一门控进入 Wiki；中：三个存储层；右：进入 LLM 上下文的三条预算通道。
Every piece of knowledge passes through five stages; the outputs of maintenance and distillation are written back into the wiki and join the next recall round — knowledge compounds.每条知识经历五个阶段；维护与蒸馏的产物回写知识库，参与下一轮召回，实现知识复利。
Figure 2图 2 — Knowledge lifecycle: the Write → Index → Recall → Maintain → Distill loop.知识生命周期：写入 → 索引 → 召回 → 维护 → 蒸馏的闭环。
Everything lives inside the agent workspace as plain text and SQLite files — directly reviewable, version-controllable, no external services.全部落在 Agent 工作区内的纯文本与 SQLite 文件，可直接审阅、可版本化、无外部服务。
workspace/ ├── prompt/ # RULES tier — resident, injected every turn │ ├── SOUL.md # persona & hard rules │ ├── IDENTITY.md # agent identity │ └── USER.md # user settings & preferences ├── MEMORY.md # distilled facts & lessons (≤3000 chars) ├── memory/ │ ├── topics/ # WIKI tier — structured knowledge base │ │ ├── _index.json # global index (auto-maintained, ≤2 KB injected) │ │ └── {namespace}/{slug}/ │ │ ├── summary.md # summary ≤1000 chars — the recall unit │ │ ├── detail.md # detail ≤8000 chars — read on demand │ │ ├── history.jsonl # append-only change history │ │ └── meta.json # state / timestamps / reference counts │ ├── proposals/ # conflict & merge proposals awaiting user ruling │ └── metrics.jsonl # observability: injection share, recall hits └── .starchild/ ├── sessions.db # RAW tier — SQLite + FTS5 full-text index └── chroma/ # vector index (topic-summary level)workspace/ ├── prompt/ # RULES 层 — 每轮常驻注入 │ ├── SOUL.md # 人格与硬性规则 │ ├── IDENTITY.md # Agent 身份 │ └── USER.md # 用户设定与偏好 ├── MEMORY.md # 精炼事实与教训（≤3000 字符） ├── memory/ │ ├── topics/ # WIKI 层 — 结构化知识库 │ │ ├── _index.json # 全局索引（自动维护，≤2 KB 注入） │ │ └── {namespace}/{slug}/ │ │ ├── summary.md # 摘要 ≤1000 字符 — 召回单元 │ │ ├── detail.md # 详情 ≤8000 字符 — 按需读取 │ │ ├── history.jsonl # 追加式变更历史 │ │ └── meta.json # 状态 / 时间戳 / 引用计数 │ ├── proposals/ # 矛盾与合并提案，待用户裁决 │ └── metrics.jsonl # 可观测性：注入占比、召回命中 └── .starchild/ ├── sessions.db # RAW 层 — SQLite + FTS5 全文索引 └── chroma/ # 向量索引（topic summary 级）
Figure 3图 3 — Storage layout. Summary/detail separation controls injection cost; append-only history keeps everything auditable.存储布局。摘要与详情分离控制注入成本；历史追加保证可审计。
| Principle原则 | Implementation实现 |
|---|---|
| Injection is budgeted注入有预算 | Resident ≈13 KB, index ≤2 KB, recall ≤6 KB; knowledge tokens capped at 5–10% of total input — over budget means trimming, never accumulation常驻 ≈13 KB、索引 ≤2 KB、召回 ≤6 KB；知识 token 占总输入 5–10%，超限即裁剪而非累积 |
| Writes are gated写入有门控 | All write paths pass one gate: semantic dedup, explicit supersession of stale knowledge, same-key conflicts resolved via unique IDs所有写入路径经统一门控：语义去重、旧知识显式取代（supersede）、同键冲突以唯一 ID 消解 |
| Conflicts never auto-overwrite矛盾不自动覆盖 | Mutually exclusive knowledge is kept on both sides, marked conflict, and surfaced as a proposal for the user to rule on — stale knowledge is more dangerous than no knowledge检测到互斥知识时双方保留并标记 conflict，生成提案交用户裁决——过期知识比没有知识更危险 |
| Index before retrieval索引先于检索 | The model must know something exists before it can retrieve it; the global index is rebuilt ≤1 s after every write and injected into the prompt模型必须先"知道存在"才能检索；全局索引在每次写入后 ≤1 s 内重建并注入 |
| Raw records stay out of context原始记录不注入 | The Raw tier serves only full-text search and distillation; all knowledge in context comes from the gated Rules / Wiki tiersRaw 层只服务全文检索与蒸馏；上下文中的知识一律来自受控的 Rules / Wiki 层 |
| Maintenance is zero-resident维护零常驻 | Periodic jobs piggyback on normal wakeups with lazy due-checks — compatible with host auto-suspend, no daemon required周期任务借正常唤醒触发（piggyback），懒惰到期检查，兼容宿主机自动休眠 |
| Observable可观测 | Injection share, recall hit rate, topic growth, and invalidation ratio are continuously written to metrics — preventing silent degradation注入占比、召回命中、topic 增长与失效比例持续写入 metrics，防止系统静默退化 |
| Parameter参数 | Value取值 | Notes说明 |
|---|---|---|
| topics.max | 100 | knowledge-base capacity cap; overflow triggers archival知识库容量上限，超限触发归档 |
| summary / detail | ≤1000 / ≤8000 chars | summary is the recall unit; detail is read on demand摘要为召回单元，详情按需读取 |
| index / recall budget | ≤2 KB / ≤6 KB | hard per-turn injection caps每轮注入硬上限 |
| idle flush | 30 min | capture window after a session goes idle会话空闲后的沉淀窗口 |
| distill window | 7 d, daily | raw-session distillation range原始会话蒸馏范围 |
| lint interval | 7 d | knowledge-base maintenance cycle知识库维护周期 |
| stale threshold | 90 d unaccessed未访问 | demoted in recall and queued for archival降权并候选归档 |
| dedup threshold | cos > 0.92 | semantic-duplicate merge threshold语义查重合并阈值 |