从知识库到记忆系统：重新思考 AI 的知识架构

最近看到仍有人在建设数据库运维知识库，把技术文章整理成训练材料，从开源数据库源码中批量提取知识文章，或让 AI 参考官方文档生成 Skill。我越来越怀疑这类建设的必要性。从我的使用体验看，即便在数据库运维领域，当下的大模型凭借已有的知识与推理能力，也已经能解决绝大多数日常问题。涉及具体环境时，再调用 Tool（包括通过 MCP 接入的 Tool）触达现场、日志、数据库与源码，用 JIT Context 按任务即时获取所需上下文，就能继续调查、处置和验证。

我的判断是，知识库已经没有必要成为 AI 应用的默认前置工程。通用知识无须重复整理，特殊场景也不意味着值得提前穷举案例。更值得建设的，是获取证据、验证判断的能力，以及对具体环境与真实经历的记忆。

AI 的知识架构，应当从提前囤积答案，走向按需理解问题、持续积累经验。

模型与 Tool 在进步，预先建库的前提也要改变

回看 ChatGPT 刚出现的时候，我常遇到它连基本事实、事件时间都答错的情况。那时，把材料筛选好、把步骤写全、把问题整理成问答，确实能补偿模型的不足。如今，越来越多的问题已经可以交给模型配合 Tool 解决，联网读取最新资料也让回答突破了训练数据的时间限制。模型本可以运用更广泛的知识、查找新证据，如果系统仍让检索命中的几篇文章主导答案，原本用来弥补模型不足的知识库，反而可能限制强模型的推理和调查范围。

对于模型已经掌握的概念和方法，直接使用即可。需要补充版本细节、环境状态或诊断证据时，再按需查阅。

复杂任务也可以让 Agent 阅读原始材料、提出假设、获取证据，再根据执行反馈调整。工程应先把这条工作路径接通，让实际任务暴露缺口，再决定哪些知识需要专门整理。

因此，一份专门教模型通用 SQL 写法的长篇规范，和一份记录公司业务口径的说明，有不同的生命周期。前者的一部分可能随着模型升级失去必要性；后者承载了模型无法凭空知道的业务事实。

沿着这个方向推演，如果未来的 AGI 能够自主调查和解决更复杂的问题，预建知识库的必要性还会进一步下降。需要我们持续提供的，是它无法凭空知道的内部事实、业务约定与共同经历。这些内容可以通过原始系统和专有记忆取得，资料是否公开，并不决定是否需要另建一个知识库。

保留事实，让理解发生在需要的时候

一种值得重新审视的流程是：先让 AI 阅读源码和文档，生成摘要，再扩展成问答、知识点或 Skill，最后交给 AI 使用。AI 在消费 AI 生成的二手知识。

如果一个 Skill 只是把官方文档重新转述一遍，它增加的是某次生成时的筛选与解释。为什么不让模型在需要时直接读原文？尤其当这些解释被写成操作指令，原本需要结合场景判断的内容，还可能变成后续 AI 默认遵循的步骤。Skill 值得承载的是经过实际验证的方法、环境约束与配套脚本；把文档改写成 Skill，并没有自动完成这些工作。

如果模型最终只能读到这些加工结果，它面对的就是前一个模型筛选后的世界。被省略的分支、被压缩的限定条件、没有被识别出的关联，都可能无法再找回来。生成量越大，审核和同步工作也越多。

一份日志今天用于定位超时，明天可能用于分析资源变化；一段源码今天被检查权限逻辑，明天可能被调查并发问题。如果提前只保留“这次超时的原因”或“这个函数负责鉴权”，就把未来的问题限制在当时摘要者的视野里。

保留可追溯的原始信息，也是在保留让更强模型重新分析它的机会。 摘要适合帮助定位与复用，应当能够带人和 Agent 回到来源。

把这种思路落实到系统中，就是 Tool Use 与 JIT Context（Just-in-Time Context，即时上下文）：Tool 提供查询数据库、读取日志、搜索代码和查阅文档的能力；Agent 根据当前问题判断缺少什么证据，调用相应 Tool，再根据返回结果决定下一步查什么。上下文随着调查逐步形成。

例如排查一条慢 SQL，可以先查询执行计划和等待事件，发现锁等待后再追踪阻塞会话与事务；遇到版本相关行为，再查对应文档或源码。每一步取得的信息都服务于当前判断，无须提前把所有慢 SQL 案例装进上下文。

Tool 提供模型可调用的具体能力，可以封装 API 或命令行操作，也可以由 MCP Server 暴露。MCP 是发现和调用这些能力的标准协议，JIT Context 则描述按需获取信息的工作方式。

源码中的函数、类型、控制流、测试和提交历史已经表达了大量结构。针对一个开源项目，我会先保留精简的 Repo Wiki，说明模块职责、入口、构建测试方式和设计背景。具体问题出现后，再沿符号、调用关系和历史变化调查，必要时运行验证。Wiki 的价值是帮助找路，全面翻译源码则很容易形成需要同步维护的第二份实现说明。

常见的分片式 RAG 也有类似问题。文档中的结论、前提和例外，未必落在同一个片段里。一段操作步骤可能被准确命中，后文“不适用于某个版本”的限制却没有被取回。此时，局部检索看起来正确，完整判断却可能出错。检索到相关片段，不等于获得了足以理解问题的上下文。

模型需要围绕整个问题组织证据。片段可以作为入口，随后应能展开上下文、沿引用查找关联材料，必要时通读相关文档。整体理解并不要求一次塞入所有资料，但不能让切片边界变成推理边界。

上下文需要支付成本，覆盖率也有尽头

我早期曾把墨天轮和恩墨内部的文章整理成知识库。实际使用中，一个让我警惕的现象是：一旦命中资料，LLM 就容易围绕这些内容继续探索，调查范围随之收窄。但被检索到的文章，其质量、完整性和对当前问题的适用性，并没有因为“命中”而得到验证。资料作为提示上下文送入模型后，在当时的系统中，常常被当成了应当遵循的依据，仿佛成了“圣旨”。

检索偏差、切片丢失前提、内容质量和环境差异，都可能让模型更有把握地沿着错误方向走。检索命中是一条待核验的线索，不应成为调查的终点。 Agent 应当能够质疑取回的材料，并用原文与现场证据继续验证。

知识库扩张还会增加筛选难度。同一个报错，可能混着不同版本的解释、重复转载和相似却不适用的案例。在只取前几条结果的情况下，这些材料可能挤掉真正有用的证据；增加取回数量，又可能带入更多噪声。由此可见，缺乏去重、版本过滤和有效排序的扩库，可能同时降低结果的准确性与关键证据的召回率。LongRAG 的研究也将海量短片段带来的检索负担作为需要解决的问题。收录得更多，不等于找得更准。

这也有直接的性能代价：检索、重排和追加材料可能拉长响应时间，注入的内容占用更多输入 token，反复携带这些内容还会增加后续调用的消耗。我把这些代价理解为“上下文税”，其中还包括不同指令之间的冲突，以及持续校验材料的维护成本。上下文窗口更大，只意味着可以容纳更多内容；如何选择依然是系统的工作。

批量收集互联网文章，还涉及资料的使用权。公开可读并不等于可以任意复制、改编或对外提供；是否构成侵权，需要结合授权、具体使用方式和适用法律判断。通用知识库因此也可能承担授权核查与来源管理的成本。按需读取原文同样需要遵守相应规则，但没有必要为了“拥有知识”，无端增加一份需要长期管理的内容副本。

资料的时效性则直接影响判断。基于 Oracle 11g 写出的具体参数建议，可能仍适用于某个旧环境，却不该未经核对就指导另一个版本。错误材料被检索出来，有时比没有提供这份材料更难处理，因为它看起来像一条现成依据。

产品持续迭代，还会把一次性的建库投入变成长期开销。一个版本更新后，受影响的摘要、问答、切片和知识图谱关系都可能需要重新检查，旧结论要标记失效，新内容要重新索引，并验证检索结果是否仍然适用。维护成本会沿着加工链条累积。按任务读取适用版本的原始资料，仍需判断其正确性，但可以减少维护多份派生内容的同步负担。

从我之前建设 Oracle 知识库的经验看，实际用得上的文章很少，需求反而集中在表空间扩容、添加 Redo 日志等常用场景。这些方法，当下的 LLM 基本已经掌握。像 ORA-01555、ORA-00060，其基本原理和排查思路也已经是模型能够回答的内容，真正需要补充的是当前环境的运行状态、相关日志与诊断证据。

如果追求知识库的“完整”，是否要从穷举所有数据库报错代码开始？假设每个 ORA 报错平均准备 5—10 篇文章，再覆盖不同版本、触发条件和处理方法，生成、审核与持续更新的工作量就会迅速膨胀。

高频场景的通用方法，模型已经会；低频场景的具体组合，知识库又很难穷尽。 一个特定 ORA-600 问题可能多年都不会在某个环境出现，即使检索到同样的错误号，也仍需结合参数、版本和诊断信息确认原因。

即使掌握某个产品内部的 Bug 资料，也不必为了极低概率的命中，提前将所有特殊案例加工成知识库。保留原始记录和查询入口，问题发生时再结合现场调查，往往更划算。实际遇到并验证过的处置经验，则可以进入 Memory。反复发生或影响重大的经验值得沉淀，尚未发生的所有可能性不必逐一加工。

事实、上下文与记忆，各自承担什么

从静态积累走向动态使用，首先要明确三种角色。

事实来源保存权威记录：订单在业务系统，代码在仓库，当前运行状态在监控与数据库，决策过程在相应文档和讨论记录中。访问这些来源的能力，决定 Agent 能接触到多少真实世界。

上下文是本次任务的工作材料。它由目标、约束、相关事实、可用方法和执行反馈组成，需要随着任务推进而变化。开始时可能只需要入口和线索；发现异常后，再深入读取证据。它不必是所有相关资料的一次性全量装载。

记忆则承担跨任务的延续：我们经历过什么，为什么这样选择，哪些方法验证有效，哪些看似合理的路已经走不通。它让下一次任务不必从完全相同的起点重新开始。

对于反复读取、获取成本较高的资料，可以增加缓存：保留已验证的结果，记录来源、版本与失效条件，源数据变化后重新获取。这样，存储范围由实际使用决定。缓存保存可以重取的内容，Memory 保留难以重建的经历，两者有不同的价值和生命周期。

在运维场景中，我尤其看重让 AI 直接连接目标环境，通过数据库查询、监控接口和日志 Tool 取得现场证据。仅仅回答“这种故障一般怎么处理”，价值很有限。平台应能由巡检或监控事件触发调查，结合 Memory 中的环境特征与历史经验，发现异常、提前预警，并在既定权限和处置范围内及时修复或预防性处理。执行后重新查询现场，确认问题是否解决，再把结果写回记忆，才形成完整的工作过程。

例如，Memory 记得某个批处理窗口曾出现空间耗尽，平台就可以在下一次任务前查询剩余容量、增长趋势和当前任务安排，判断是否需要预警或执行预设处置。历史经验决定重点检查什么，实时证据决定这一次是否需要行动。Memory 要与现场连接起来，才能从“记得过去”走向“改善下一次运行”。

最值得记住的，是我们与通用答案之间的差异

模型知道怎样设计缓存，却不知道团队为什么暂时没有引入缓存；它知道怎样修改接口，却不知道某个看起来可以删除的字段仍被外部客户依赖；它会写文章，却不知道作者反复强调过的主张和表达偏好。

因此，我认为个人与组织的记忆应该优先保存四类内容：长期目标和偏好，实际约束与例外，决策背后的理由，以及经过验证的成功和失败经验。尤其是“为什么”和“试过但没成功”，往往比一份当前配置更难重新获得。

人们整理知识库时，往往更愿意写成功案例和最佳实践，排查中的误判、无效尝试和回滚过程容易被省略。但对运维而言，这些恰恰是珍贵的经验：某次参数调整为什么加剧了抖动，某种修复为什么引发了新的故障，哪些操作在这个环境里不能做。知道哪里走不通，也是解决问题的能力。 如同有经验的人会记得自己踩过的坑，Memory 应保留当时的环境、操作、后果与回滚原因，让 Agent 少重复一次错误。

这里可以设想一次接口改造。Agent 发现某个旧字段似乎没有调用，准备删除；调查后确认，一个外部客户仍在使用，只是访问记录不在当前仓库里。最终保留字段，并确定了后续迁移条件。

只记录“不要删这个字段”，会留下一个没有解释、可能永久阻碍改动的禁令。更有用的记忆应该包含：谁仍在依赖、根据什么确认、为何暂时保留，以及满足什么条件后可以重新评估。下一次需求到来，Agent 便知道先查什么，而不必重复撞上同一个问题。

同样的基础模型接入不同组织，最终能否表现出差异，很大程度上取决于能否获得这样的背景。通用能力可以购买，自己的经历需要积累；有价值的记忆保存的正是这种差异。

记忆系统要会回想，也要会整理和遗忘

如果把所有对话摘要都塞进一个库，每次取出一批，旧的问题还会以 Memory 的名字重新出现。动态记忆必须参与工作的整个过程。

首先是保留经历。任务中的关键输入、行动、反馈与结果，需要有可以回查的记录。临时假设与确认结论应当区分，否则模型在调查过程中的猜测就可能被后续任务当成既定事实。

其次是提炼与巩固。任务中及时记录证据与结果，跨任务的归并、去重和经验提炼可以交给后台，在任务结束或系统空闲时完成，避免每次响应都等待完整的记忆整理。重要性、复用机会与重新调查的成本，共同决定是否形成长期记忆；重大失败即使只发生一次，也值得保存。

接下来是有线索地回想。新任务先获得简短、相关的记忆，需要时再回到原始记录。一条记忆除了内容，还要知道属于谁、针对哪个系统和版本、何时验证过、依据在哪里。相似措辞不足以决定它适用于当前问题。

记忆还可以保存调查路径：某类问题该查哪个日志、调用哪个接口、沿哪条调用链追踪。上一次的答案可能已经过时，找到答案的方法仍可能有用。保存这些路径，能让下一次调查更快取得新证据。

最后是修正与遗忘。一次验证失败、一次版本升级或用户的新要求，都可能改变旧经验的地位。沿用前面的示意例子，如果外部客户已经完成迁移，“暂时保留字段”就应退出当前约束，原来的决策过程则可以作为历史留存。

这个过程可以让知识在不同层次之间流动：一次经历形成经验，多次验证的方法形成 Skill 或脚本；条件变化后，Skill 可以降级为参考，过时结论停止被召回。原始记录、经验与可执行方法之间，应保留关联，便于一处变化后检查其他内容。

这让我想到人脑的精妙：在约 20 瓦量级的能量预算下，支持着思考、记忆等复杂活动。回顾我们自己的学习过程，记住、遗忘、复习、总结和抽象也始终交织在一起。一次经历未必需要保留全部细节，但其中形成的理解，可以帮助我们处理下一次不同的问题。

我们并不需要把整个维基百科记在脑中。已经理解的概念、熟练的方法和亲身经历支撑日常判断，具体条目则可以在需要时借助笔记、书籍和互联网查找。一个数据库专家也不必背下全部官方文档和源码；他需要知道问题可能出在哪里、该查什么，以及如何判断查到的材料是否适用。记住知识，与知道如何找到并使用知识，可以共同构成能力。

遗忘也要有不同动作：从默认召回中降级、压缩、归档、标记失效，以及按要求删除。恢复预案不能只因低频就被淘汰，用户要求删除的数据也不能只在搜索结果里隐藏。记忆需要管理用途与责任，而不只是按时间衰减一个分数。

把工程投入到获取、验证与记忆的能力上

Coding 场景已经提供了参照：使用 Claude Code、Codex，通常不必先建设一套 Java 知识库，而是让 Agent 通过 Tool 读取项目、运行测试，根据结果修正判断。Harness 组织上下文、维护任务状态与执行反馈，跨任务的约定和经验则可以沉淀为 Memory。既然 AI 可以进入代码仓库解决问题，数据库运维也应让它直接面对现场，在行动与验证中形成理解。

近期自己做 IT 运维系统，我的建设起点是让 LLM 了解它要管理的环境。已有的资产资料可以直接录入，缺少的信息则通过 Tool 主动发现和学习（Discovery / Learning），查清主机、数据库、版本、部署拓扑、配置与依赖关系，形成可核验、可更新的资产基线。

接着，让它在现场开展调查与处置，用执行结果验证判断，再把环境约束和处理经验沉淀为 Memory。配合少量必要的 Skill，这条从了解环境到解决问题、积累经验的工作路径，已经能够支撑我接触的具体运维场景。

现场查询之外，企业还会有需要长期关联使用的私有资料，例如规章制度、客户合同和项目记录。确实需要为这些内容建立知识系统时，我更倾向于参考 Andrej Karpathy 提出的 LLM Wiki：保留原始文档，由 LLM 将内容增量编译成结构化、互相链接的 Markdown 页面。新资料到来时，更新相关主题、补充关联、标记矛盾；查询中形成并经核验的有价值分析，也可以写回 Wiki，供后续工作复用。这里值得预先积累的，是反复需要使用的跨文档关系、差异与变化，减少每次查询都重新梳理的成本。原文始终是事实依据，Wiki 是可以检查、修订和追溯的理解层，具体条款仍要回查原文与生效版本。

对于笃定要建设运维领域知识库，愿意持续投入大量资源搜集和加工资料的公司，我还有一个更进一步的建议：与其扩大预制答案的规模，不如评估把这些投入用于训练 IT 运维专用模型。尽可能全面地搜集可合法使用的文档、代码、故障案例、诊断过程与处置反馈，围绕真实运维任务训练，并用独立任务评估专业能力是否确实超越通用模型。训练值得追求的是更好的诊断与处置能力，现场事实和版本变化仍应按需获取。

TypeSafe AI 于 2026 年 9 月发布的 Jev 提供了一个观察角度：按官方介绍，它面向快速的结构化决策，输出带概率的结果，目前处于早期访问阶段。在我看来，追求 AGI 的通用能力之外，还会出现更多围绕特定任务与领域训练的专用模型。这是愿意深耕垂直领域的公司可以探索的方向。

工程投入最终要落到任务收益上：与直接使用更强模型、按需读取原文的方案相比，这些建设能改善多少结果，又增加多少调用、审核和维护成本？模型升级后，这笔账也应重新计算。

让模型更强，让记忆更懂我们

模型已经掌握的知识，无须重新整理；尚未遇到的特殊问题，也不必提前穷举答案。把 Tool 接到真实环境，让模型在需要时获取上下文、调查并验证，再将实际工作中的约束、决策与成败沉淀为 Memory——这就是我所主张的知识架构。建设的重心，应从预先替 AI 准备答案，转向支持它解决问题、积累经验。

下一次故障到来时，AI 能否记得这个环境曾经踩过的坑，主动查清现场，少走一条已经验证无效的路？一次版本升级后，它能否及时修正旧经验？这些变化，才是记忆系统成长的证据。

模型会继续进步，公开资料会继续更新。一个系统与我们共同工作得越久，就越应该懂得这里的目标、约束和历史。这种随经历积累的理解，才是记忆系统最值得建设的部分。