跳到主要内容

写入管线

写入管线的目标不是“把一段文本塞进数据库”，而是把外部输入转成可信、可控、可召回的记忆对象。真正困难的部分不在持久化，而在判断与分流。

主流程​

User / Agent
  -> Adapter
  -> API Gateway
  -> Ingest Service
  -> Memory Judge
  -> Stable Memory Service / History Recall Service
  -> Search & Index 更新

各阶段职责​

1. 宿主表达写入意图​

写入可能来自用户显式命令，也可能来自某种受控自动化。但无论来源如何，外部宿主只负责表达“要写什么”，不负责决定最终存储策略。

2. API Gateway 做统一入口控制​

在真正进入业务判断前，Gateway 先完成：

  • 认证与鉴权
  • 参数校验
  • 基础限流
  • 统一错误翻译

这一步前置，是为了避免后续业务模块被无效输入和异常协议污染。

3. Ingest Service 收口所有写入路径​

Ingest Service 统一接住稳定记忆、历史材料和未来可能的批量导入请求。它的价值在于确保系统里没有任何“绕过 Judge 直接入库”的后门。

4. Memory Judge 做判断与分流​

Judge 至少要完成以下决策：

  • 是否接受写入
  • 目标层是 Stable 还是 History
  • 类型、标签、重要性、可信度
  • 是否存在 semantic_key 覆盖或冲突

Judge 的三段式模型是：

  1. 硬规则拦截
  2. LLM 结构化判断
  3. 规则兜底

这个顺序不能轻易改，因为它先用确定性规则挡住明显不合法或高风险输入，再用模型补强语义判断，最后保证在模型不可用时系统仍能退回稳定行为。

5. 对应存储服务落库​

Judge 确认目标层后，才进入对应的存储服务：

  • Stable Memory 负责版本化、状态管理和覆盖逻辑
  • History Recall 负责追加写入和历史材料存储

6. 更新检索索引​

写入并不是“落库成功就结束”。为了保证后续显式搜索和任务召回都能看到最新状态，写入后还要及时同步检索底座。

特殊场景​

场景处理方式
临时模式开启直接拒绝写入
命中敏感内容规则阻断并返回明确原因
semantic_key 相同且内容无变化直接跳过，避免重复噪声
semantic_key 相同但内容冲突写入新版本或标记冲突，供召回侧显式提示
批量写入每条独立经过 Judge，不共享判断结果

为什么写入链路要这么严格​

因为记忆系统一旦允许噪声、重复和高风险内容无门槛流入，后面的召回质量和控制成本都会迅速恶化。写入阶段多做一道判断，不是为了让流程复杂，而是为了保护后续整个系统的信噪比。