方法論答卷 B：知识不是越自動越好，而是越可見、可審、可关閉越好。操作步驟見 使用者指南 §15。
系列位置
完整导读見 系列导读与产品定位。
| 順序 | 文章 | 本題 |
|---|---|---|
| 0 | 系列导读与产品定位 | 系列导读与产品定位 |
| 1 | Agent 时代的数据分析工作流 | 可審閱的交付与執行授权 |
| 2 | 本文 | 可治理的 Agent Memory |
| 3 | Prompt 与 Context 工程 | Prompt 与 Context |
| 4 | AI Agent 架構 | Agent 架構 |
| 5 | 統一查詢层 | 統一查詢层 |
一、問題定義：自動 Memory 与无審批 RAG 为何不足
許多 AI 产品把「記住使用者說过的話」当成预设能力：对話结束就写入向量庫，下次檢索相似片段塞回 prompt。对数据分析場景，这会帶來三類風險——不是模型不夠聰明，而是記憶缺乏治理：
- 不可見：使用者不知道模型「以为」哪些规则成立。
- 不可控：錯誤推論或幻觉可能被当成长期事实。
- 不可关閉：合规或敏感專案需要明確切断記憶注入。
Lantide Data 的立場是：只有经使用者核准、写入正式知识檔的内容，才进入 Agent 上下文；其餘建議停留在佇列，直到 Apply 或 Dismiss。
部分产品透过「越問越懂 schema／业务规则」做会話内自适应記憶——方便，但跨專案口徑一旦写錯，代价高于「少記一点」。Lantide 选擇 Queued Knowledge + 人工 Apply：口徑須 evidence_quote 可驗、核准后才注入，与 工作流 §三 SQL-first 互補——知识檔沉澱的是已審閱的口徑，不是 Insights 終端的副产品。
二、分层 · 分型 · 審批
2.1 两层知识
| 层級 | 範圍 | 典型内容 |
|---|---|---|
| User Knowledge | 工作区全域 | 公司術语、全域分析偏好、跨專案规则 |
| Project Knowledge | 单一聚焦專案 | 該次活動定義、欄位语意、專案專属假设 |
專案知识仅在該專案被 focus 且 Agent Memory Enabled 时注入。
2.2 Rules 与 Info
每份知识檔固定两区（旧版四区会在读取时遷移）：
@@PROTECT0@@@@PROTECT1@@@@PROTECT2@@
萃取入佇列时标記 Type：@@PROTECT3@@ 或 @@PROTECT4@@，核准后写入对应区块。
2.3 总开关 Enabled 与 Automatic suggestions
- **Enabled（总开关）关閉后：**不背景萃取、不注入、不显示佇列紅点；Agent 提案与受控写入一併暫停。Agent 行为等同无記憶庫。
- **Automatic suggestions 关閉（Enabled 仍开）：**不跑对話结束后的背景萃取 LLM／入隊；已核准知识仍注入，手動编辑与佇列審批仍可用；Agent @@PROTECT5@@ 仍可入隊。
詳見 §15.3。
三、两段式知识流
@@PROTECT6@@@@PROTECT7@@@@PROTECT8@@
原则： 佇列項目永远不直接进模型；只有写入磁碟知识檔后才注入。
四、Queued Knowledge：審核入口
4.1 萃取规则
在 Enabled 与 Automatic suggestions 皆开启、且 LLM 可用时，对話正常结束后背景執行：
- 仅掃描最近一轮中的 user 讯息（预设最近 8 條）。
- System instruction（Execute Plan、Resolve Comments、HTML Report 指令等）不参与萃取。
- 每條建議須含 evidence_quote（使用者原話引述），后端校驗引述必須出现在上述 user 讯息中，否则丟棄。
- 每轮最多入隊 3 條。
- 有聚焦專案时，建議偏 project 层并预填專案 ID。
仅关閉 Automatic suggestions 时跳过上述背景流程；不影響已核准知识注入。
4.2 去重与取代
与已核准知识、pending 佇列、同專案知识檔做语意比对；重复则略过。若为更新表述，可 supersedes 取代语意相同的旧 pending 項。Dismiss 后会記录 hash，避免反覆建議同一條。
4.3 Agent 主動提案（@@PROTECT9@@）
分析中 Agent 可呼叫 @@PROTECT10@@ 将可重用口徑／欄位规则送入同一 Queued Knowledge 佇列。与被動萃取相同：核准前不注入。
与 Query Step Ledger 的分工：
| 内容類型 | 歸属 | 为何 |
|---|---|---|
| 本对話某步 SQL 的 pitfalls、欄位陷阱（仅本次分析） | Ledger / @@PROTECT11@@ | 对話内可追溯，不污染长期知识 |
| 跨对話可重用口徑、欄位定義、业务规则 | @@PROTECT12@@ → Queued | 須 evidence + 使用者 Apply |
提案須附可驗證的 evidence_quote，禁止把 SQL、快取表名等執行态内容写进知识檔；頻控与校驗細節見 AI Agent 架構 §八。
4.4 核准操作
Agent proposed 与 Chat extraction 共用同一佇列。入隊后可在两處審批：
- 对話串流知识提案卡片 — User / Project / Dismiss（不暫停 ReAct，与 @@PROTECT13@@ 不同）；卡片依佇列狀态持久化，重載对話后仍同步；有聚焦專案时 Project 预设写入該專案。
- Queued Knowledge 分页 — Apply to User、Apply to Project（Pick project 項須手動选專案）或 Dismiss；批次 Process all 会跳过仍須手動选專案的項目。
列表仅显示 pending 項，并区分來源；套用后自列表移除属预期。聊天卡片与 Agent Memory 透过佇列变更事件双向刷新；成功套用时 toast 标明 User 或 Project 落点。
操作介面見 §15.5。
五、知识檔契約
5.1 條目结構
- 以 Markdown 頂格 bullet 为主；可有一层缩排子條（目录模式）。
- 葉條目：实际规则／事实正文；仅作分组标題的父行不計入 Library status 的 Rules/Info 計数。
- Save 上限 8,000 字元（与注入预算 6,000 / 20,000 不同）。
5.2 Library status
编辑器右側显示 Rules/Info 葉條目数、字元数／注入上限、Last updated、Mode（flat / catalog）。統計以磁碟已儲存内容为准；未 Save 时提示 Counts update after Save。
六、Apply 与 Reorganize
6.1 Apply
核准后合併至对应 @@PROTECT14@@ 或 @@PROTECT15@@，新條目常以单行頂格 bullet 写入，待下次 Reorganize 整理。User 与 Project 落点不同，勿在錯誤分页查找。已 Dismiss 或已 processed 的佇列項再次 Apply 时不会重复写檔（重复操作安全）；前端以 Already dismissed / Already saved 提示，而非假成功。
6.2 手動 Reorganize
对目前左側选定的 User 或 Project 檔觸发 LLM：去重、濃缩贅字、依字数決定是否收成「短目录标題 + 缩排子條」。
| 檔案 | Reorganize 目录閾值 | 注入 Mode 閾值 |
|---|---|---|
| User | 2,500 字 | 未达：flat 全文；达：catalog |
| Project | 5,000 字 | 同上 |
- 重组前备份 @@PROTECT16@@；结構不合法不覆写。
- 未 Save 时 Reorganize 按鈕禁用。
- 进行中：编辑区蒙版 + 狀态文字，最长約 300 秒；可切換其他知识檔并行重组；关閉对話框不取消背景请求。
詳見 §15.6。
6.3 Pre-inject Reorganize
已达 catalog 字数但檔内仍全頂格（无父+子结構）时，新对話首次向 Agent 发送讯息前，系統可能自動 Reorganize 一次（介面提示「Reorganizing Agent Memory before injection…」）。同一 conversation 每檔最多试一次；失敗不阻断聊天，新开对話可再试。编辑器有未儲存变更时请先 Save，避免自動重组覆写磁碟。
七、flat → catalog → expand
知识檔較短时，模型一次看見全部 Rules/Info；超过字数门檻后，注入变成「目录标籤列表」，模型需用 @@PROTECT17@@ 按需展开——類似「先給索引，再查詳情」，避免长期知识撐爆 context。
7.1 注入模式
| Mode | 條件 | 注入内容 |
|---|---|---|
| flat | User < 2,500 字且 Project < 5,000 字 | Rules + Info 全文（在字元预算内） |
| catalog | 达上述閾值 | 目录索引：頂格父标籤为 lookup key；有子條的父行不帶子條正文 |
超过注入预算（User 6,000、Project 20,000 字元）时附加截断提示。
7.2 expand_knowledge_catalog
catalog 模式下，system prompt 会提示 Agent 以精確父标籤呼叫 @@PROTECT18@@ 批次載入完整條目（含缩排子條）。工具实作与狀态限制見 AI Agent 架構 §八。
7.3 project_id 语意
- 注入时使用的 @@PROTECT19@@ 以 session 聚焦專案为准。
- 萃取入佇列时优先使用对話 context 的聚焦專案，再 fallback session，以減少 Pick project。
八、与答卷 A（Agent 时代的数据分析工作流）的关系
| 维度 | Agent 时代的数据分析工作流 交付物 | 可治理的 Agent Memory 記憶 |
|---|---|---|
| 生命周期 | Plan / Report 版本化、Execute 锁定 | 跨对話累積、可 Reorganize |
| 協作載体 | 文件 + 批註 | 知识檔 + 佇列 |
| 进入模型 | 活躍分页内容、批註 Optimizer | 仅核准后 Rules/Info |
两者正交：好的交付流程不等于自動記憶；記憶也不应取代 Plan 上的明確假设。
九、反模式
| 反模式 | Lantide Data 做法 |
|---|---|
| 对話结束自動写入向量庫 | 先入 Queued，人工 Apply |
| 无引述的「业务规则」 | 必須 evidence_quote 对得上 user 原話 |
| 佇列項直接进 prompt | 仅核准后檔案注入 |
| 无法关閉記憶 | Enabled 总开关；仅停背景萃取用 Automatic suggestions |
| 知识檔无限膨脹无结構 | catalog + expand + Reorganize |
| 模型从对話自動「学会」口徑并 silent 注入 | evidence_quote + 佇列審批（§四） |
十、结语
Agent Memory 在 Lantide Data 里是治理系統，不是聊天記录的副产品：可見、可審、可关閉，口徑須经 evidence 与 Apply 才进模型。
这与工作流的 SQL-first 互補——Plan 承載单次分析的假设，知识檔承載跨專案口徑。下一篇 Prompt 与 Context 工程 說明核准后的知识如何与 Context Summary、State Prompt 一起组裝进模型。