为什么把知识变更当成 Pull Request？
- 核心答案: 把知识库当成代码库，把每次知识变更当成一个 Pull Request（PR）;
- 适用范围: 不只适用于 User as Code 这类 Python 形式的可执行记忆；Markdown 知识库、用户记忆文件和规则文档同样应当进入 Git，见 可执行代码记忆;
- 收益: 获得差异审查、版本历史、责任追溯和一键回滚能力;
- 红线: 生产环境不应让任何一个模型绕过审核，直接改主分支或线上向量库;
增量更新的四步闭环是什么？
- 第一步 Proposer 提交 PR: 从原始证据中发现新事实、冲突或过期内容，在工作分支上提出尽可能小而完整的 diff;
- 第一步的做法: 不是把最新一次对话粗暴追加到文件末尾，而是先检索相关已有知识，再增、删、改对应条目，同步维护链接、索引、时间元数据和证据引用;
- 第二步 Reviewer 独立审核: 拿到变更前的知识、diff 和原始证据（execution trajectory、原始对话、业务文档或工具执行结果）;
- 第二步的检查项: 每个新断言是否能被证据支持、是否遗漏限定条件、是否与其他文件冲突、删除或改写是否过度;
- 第二步的输出要求: 审核不通过时返回指向具体证据和行号的可执行意见，而不是模糊地说“还需要改进”;
- 第三步 迭代至收敛: Proposer 根据拒绝理由修改 diff，Reviewer 再次回到原始证据复核，只有 Reviewer 明确批准 PR 才可合入; 同时设置最大迭代次数或成本预算，超出上限仍未收敛时转人工审核，不能默认放行;
- 第四步 合入后再发布: CI 先检查格式、链接、元数据、权限标签；若知识以代码表示，还要运行类型检查和测试，通过后才从已合入版本增量重建受影响的分块、摘要和向量索引;
- 推论: 索引是可重建的派生物，Git 中已审核的知识才是真正的来源;
为什么三层数据要分开？
- 原始证据层: 保存只增不改的对话、轨迹和原始文档;
- 知识层: 保存经过提炼、可持续修订的 Markdown 或代码;
- 服务层: 保存从特定已合入版本生成的检索索引;
- 可追溯性: PR 需要记录证据标识、知识库版本、审核意见和最终决定，使线上每条知识都能回答“从哪条证据而来、谁在什么时候批准”;
为什么 Proposer 与 Reviewer 必须是 Agent？
- 不是固定调用: 知识更新不是只对一段预先挑好的文本做摘要——Proposer 往往要主动搜索其他相关的用户记忆文档和规则;
- Reviewer 的工作: 要追溯证据、对比多份文档、运行检查，并在发现新线索时继续查询;
- 所需工具: 文件搜索、版本比较、测试执行和证据检索，现成的 Coding Agent 通常就能胜任;
- 检索范围: 两个 Agent 都应能按需查询完整的知识库和原始证据库，而不是只接收上游挑选的几个片段;
- 范围限制: “完整”指其被授权的租户或用户范围，不能因审核而突破隐私边界;
- 归档: 它们的工作轨迹、工具输出引用和审核反馈也应以文本归档，保证可追溯性;
为什么要用异源模型互审？
- 原则: Proposer 与 Reviewer 优先使用能力相近但来自不同家族的模型，例如 Proposer 用 Claude、Reviewer 用 GPT，或 Proposer 用 DeepSeek、Reviewer 用 Kimi;
- 理由: 不同的训练数据、偏好和推理习惯可降低两者在同一处犯同类错误的概率;
- 能力匹配: 两者能力不宜悬殊，否则 Reviewer 可能根本跟不上 Proposer 对复杂证据的处理;
- 局限: 异源互审能增加独立性，但不能替代原始证据——Reviewer 应主要核对证据和 diff，而不是沿着 Proposer 的结论再讲一遍;
- 权限分工: Proposer 只能写工作分支，Reviewer 只读证据并提交审核结果，只有合并流程可以更新主分支和线上索引;
为什么还需要定期全量整理？
- 增量的盲区: 增量更新每次只看到一个局部，多次局部正确的修改仍可能累积出全局问题;
- 典型症状: 同一事实散落在多个文件中、新旧说法同时存在、摘要逐渐偏离原始证据、目录结构不再适合当前知识规模;
- 性质: 相当于第九章“睡眠学习”在知识管理中的具体实现——前台累积证据与局部更新，后台在周期性窗口从全局视角重新审视整个知识体系;
- 旁证: Claude Code 的自动记忆在索引接近容量上限时，会主动合并或移出细节;
定期整理要完成哪三项核心工作？
- 一 去重、去旧与合并: 全量扫描，识别语义重复、已被取代、过度碎片化或只有表述差异的条目，将其删除、归并或重写; 同时重建文件间链接、入口页和索引页，必要时拆分过大文件、合并过小文件或调整目录层次;
- 一的边界: 删除的是可服务的知识表达，不是下层只增不改的原始证据;
- 二 回到原始数据核查: 逐段对照原始对话、execution trajectory、业务文档和工具输出，检查旧摘要是否遗漏关键事实、丢失否定词或时间条件、把推测错当成了事实; 不能只在已有摘要之间相互改写，否则早期遗漏和误读会一代代传下去;
- 二的分批策略: 大型知识库可按目录、时间或主题分批扫描，但必须保留覆盖清单，确保分批处理最终覆盖全量，而不是随机抽样;
- 三 冲突解决与场景限定（qualification）: 遇到矛盾说法时不简单“保留最新一条”或让模型猜哪条正确，而要追溯各自原始信息源，检查是否分别在不同时间、对象、地域、任务或前置条件下成立;
- 三的结论: 两者都有效时不是删除其中一条，而是把各自适用场景明确写入知识；证据仍不足时保留冲突和待确认状态，不得强行收敛成一个确定结论;
整理结果如何发布与验收？
- 同样过 PR: 由 Proposer Agent 在分支上提交重组 diff，再由异源 Reviewer Agent 结合原始证据审核;
- 拆分: 全量重组 diff 往往较大，可按目录或主题拆成多个 PR，但应共享同一份整理计划和覆盖清单;
- 验收: 全部 PR 通过后，除了重建全量派生索引，还应回放一组典型检索与问答用例，确认新结构没有让原本可找到的知识变得不可见;
- 触发条件: 可按时间（如每周或每月）触发，也可在新增条目数、冲突数或检索质量下降超过阈值时触发;
失效内容如何检测与下线？
- 风险: 一篇被新版取代的旧政策若仍留在库中，检索时可能与新版一起被召回，让模型给出自相矛盾甚至过时的答案;
- 做法: 给每个分块附加版本号、生效/失效时间等元数据，在检索阶段就过滤掉已失效内容;
- 做法: 或在提炼摘要时显式标注“此条已于某日废止”;
- 一致性: 这与用户记忆里的版本化冲突检测是同一思路，只是搬到了共享知识库的尺度上;
多用户共享时如何做权限与租户隔离？
- 原则: “所有用户”不等于“所有内容对所有人可见”，不同部门、租户、权限等级的用户能看到的文档范围往往不同;
- 关键要求: 检索必须按调用者的权限过滤，绝不能让越权文档进入某个用户的上下文;
- 为什么下推到检索层: 一旦敏感内容进入 LLM 上下文，就很难保证它不以某种形式泄露到最终回答里;
- 多租户: 需保证租户之间的向量索引和元数据相互隔离，避免一个租户的查询“串味”检索到另一个租户的私有知识;