知识沉淀闭环方案

背景

当前知识库只能通过 git push 更新，无法从日常活动中自动沉淀知识。
目标：建立一条通用的「内容来源 → 知识库文档更新」Pipeline，支持多种触发来源。

这个模式在业界称为 Knowledge Ingestion Pipeline，是 RAG 闭环的核心环节。

核心抽象

Pipeline 的输入是「一段待沉淀的内容」，来源无关。无论是对话、代码提交、还是其他事件，进入 Pipeline 后走相同的处理流程。

内容来源（Source）
    ↓
[统一入口] pipeline.capture(content, source_type, hint=None)
    ↓
Step 1：LLM 提炼结构化摘要
    ↓
Step 2：RAG 寻址相关文档
    ↓
Step 3：LLM 决策写入位置 + 生成变动概述
    ↓
Step 3.5：推送预览，等待人工确认 ← Human-in-the-Loop
    ↓（确认）
Step 4：LLM 合并内容，写入文档
    ↓
触发 RAG 索引重建

内容来源（Sources）

来源	source_type	触发方式	状态
TG Bot 对话	`tg_session`	`/note` 命令，传入 session_id	阶段一实现
AI Assistant 对话	`web_session`	前端"沉淀"按钮，传入 session_id	阶段一实现
Git Commit	`git_commit`	git push 后 webhook 触发，传入 commit diff	阶段二
手动文本	`manual`	`/note <内容>` 直接传入文本，跳过 Step 1	阶段一实现

扩展原则：新增来源只需实现「内容提取」逻辑，将内容规范化后交给 pipeline.capture()，Pipeline 内部流程不变。

各步骤说明

Step 1：内容提炼

输入：原始内容（对话历史 / commit diff / 手动文本）+ source_type
输出：结构化摘要，包含核心观点、结论、可沉淀的知识点
模型：minimax-m2.1（成本优先）
特殊处理：

manual 类型：用户已提供摘要，跳过此步
git_commit 类型：Prompt 侧重提取「技术决策、架构变更、踩坑记录」

Step 2：RAG 寻址

输入：Step 1 的摘要操作：调用 retriever.search_with_sources()，top_k 取 RETRIEVAL_CONFIG["capture_top_k"]（默认 5）输出：list[{"text": str, "file_path": str, "score": float}] 目的：找到知识库中与本次内容最相关的已有文档，为 Step 3 提供候选

Top-K 配置：在 router.py 的 RETRIEVAL_CONFIG 中统一管理，问答（qa_top_k=3）和沉淀（capture_top_k=5）分开配置。

Step 3：写入位置决策

输入：Step 1 的摘要 + Step 2 的检索结果
输出：

update: <文件路径> — 更新现有文档，附变动概述
create: <建议路径> — 新建文档，附建议目录和文件名
skip — 内容不值得沉淀（重复、过于碎片化）

判断依据：

相似度高（> 0.7）且内容互补 → 更新
相似度低或主题全新 → 新建
内容已完全覆盖 → skip

模型：claude-haiku

Step 3.5：人工确认（Human-in-the-Loop）

输入：Step 3 的决策结果
操作：通过 TG Bot 推送预览消息，包含：

摘要内容
决策动作（update / create / skip）
目标文件路径
变动概述（将新增哪些内容、修改哪些段落）

用户通过 TG inline button 回复 ✅ 确认或 ❌ 取消。
确认后继续 Step 4；取消则终止并告知用户。

超时处理：10 分钟无响应自动取消，避免挂起状态。

无论内容来源是 TG Bot 还是 AI Assistant，人工确认统一通过 TG Bot 推送。TG 是唯一的通知和操作入口。

Step 4：内容合并写入

场景 A：更新现有文档 输入：原文档内容 + 新摘要操作：LLM 将新内容合并进原文档，保持原有结构风格，避免重复模型：claude-haiku

场景 B：新建文档 输入：新摘要 + 建议路径操作：LLM 生成符合知识库风格的 md 文档模型：minimax-m2.1

写入完成后，通过 GitHub API 将文件 push 到仓库，触发 deploy.yml 全量重建 RAG 索引并重启服务。写入前备份原文件（重命名为 .bak），写入失败时恢复。

与现有架构的关系

现有组件	在 Pipeline 中的角色
`memory.py`	提供 session 历史，作为 TG/Web 来源的原始内容
`retriever.search()`	Step 2 直接复用，无需改动
`router.py`	提供各步骤的模型配置
`robot.ask()`	执行各步骤的 LLM 调用
`pipeline.py`	新增 `capture()` 入口，编排 Step 1~4，不改动现有 `ask()`
`main.py`	新增 `/note` 命令，调用 `pipeline.capture()`

触发方式

阶段一：命令触发

/note                  → 对当前 session 执行完整 Pipeline（source_type=tg_session）
/note <自定义摘要>      → 跳过 Step 1，直接走 Step 2~4（source_type=manual）

AI Assistant 前端：会话页面增加「沉淀」按钮，调用后端接口触发 pipeline.capture()（source_type=web_session）。

阶段二：事件触发

Git push 后通过 webhook 触发，传入 commit diff（source_type=git_commit）。
暂不实现，原因：需要先验证 Pipeline 核心流程的质量，再扩展来源。

实现步骤

Step	内容	优先级	状态
1	`pipeline.capture()` 骨架 + `/note` 命令	P0	✅ 已完成
2	Step 1：内容提炼 Prompt（tg_session / manual）	P0	✅ 已完成
3	Step 2：RAG 寻址（复用 retriever）	P0	✅ 已完成
4	Step 3：写入位置决策 Prompt + 变动概述	P0	✅ 已完成
5	Step 3.5：TG inline button 人工确认	P0	✅ 已完成
6	Step 4：内容合并写入 + 索引重建	P0	✅ 已完成
7	AI Assistant 前端「沉淀」按钮（source_type=web_session）	P1	待实现
8	Git Commit 来源（source_type=git_commit）	P2	待实现

关键决策

为什么不直接 append 到临时笔记？

append 方案内容不归位，知识库结构退化，需要人工整理，违背闭环初衷。
Pipeline 在写入时就完成归位，知识库结构保持健康。

为什么用多步 LLM 而不是一个？

单步 prompt 让 LLM 同时做「提炼 + 寻址 + 决策 + 合并」，上下文过长，容易出错。
拆分后每步 prompt 简单、可独立调试、可单独替换模型。

为什么人工确认统一走 TG？

TG 是当前唯一的实时通知通道，inline button 交互成本最低。
AI Assistant 前端触发的沉淀，确认消息同样推送到 TG，不需要在前端实现确认 UI。

2026-03-08-会话沉淀闭环方案