技术研究：Memfit AI 内置知识库系统与 Agentic RAG 实现

当AI Agent碰到它不知道的东西

我们在上一篇文章：Memfit AI: 连续渗透测试N小时不迷路的生产级AI Agent 中聊了 Memfit AI 如何像一个真人渗透测试工程师一样自主工作——规划任务、执行攻击、动态调整策略。跑了两个多小时，产出了 18 个漏洞发现和一份完整的渗透测试报告。

但是有一个问题，我们当时回避了。

如果 AI Agent 在执行过程中遇到一份它从未"见过"的企业内部安全规范，比如 GB/T 34944-2017《Java 语言源代码漏洞测试规范》，它该怎么办？这份国标文档定义了 Java 安全审计中需要关注的漏洞类型、测试方法和判定标准。大模型的训练数据里未必包含这些细节，即便包含，版本和准确性也无从保证。

这个场景在实际工作中非常常见。安全团队有自己的 checklist、企业有私有的合规要求、甲方的安全基线文档一般都不会公开发表。AI Agent 如果只能依赖大模型自身的"记忆"，那它对这些私有知识的处理能力就是零——甚至更糟，它可能会"幻觉式"地编造一些看起来合理但完全错误的回答。

那么如何解决这个问题？市面上的常见方案是外挂一个 RAG 系统或者通过 MCP 协议接入外部知识库服务。这当然可以工作，但存在一个根本性的割裂：知识库是知识库，Agent 是 Agent，两者通过一个管道传数据，Agent 对知识的使用方式非常被动——问一次，拿一次，拿到什么用什么。

Memfit AI 的知识库系统走了一条不同的路。我们把知识库做成了 Agent 的"内置器官"，整个系统完全本地化运行，Agent 可以在任务执行过程中自主地、多轮地查询和探索知识库。这意味着 Agent 拿到第一轮搜索结果后，会根据结果判断信息是否充分，如果不够，它会调整查询策略再搜一轮——最多迭代 3 到 5 轮，直到凑齐足够的信息来做决策。

笔者认为这是 Memfit 知识库最值得关注的设计。知识库和 Agent 的关系应该是"知行合一"的——知识库负责记住海量的私有数据、来不及训练或者无法训练进模型的专业内容；Agent 则根据这些知识做出判断和行动。两者熔在一个系统里，才能真正发挥价值。

在本文中，我们将会为大家完整地介绍 Memfit 知识库系统：

01 如何创建和使用知识库

02 两种知识构建模式的差异与选择

03 查询验证与 Agentic RAG 的实际效果

04 Agent 在生产任务中如何调用知识库

05 底层的技术实现——从索引构建到多轮搜索的完整链路

进入知识库

Memfit AI 的知识库功能集成在主界面中。打开 Memfit 后，在顶部导航栏可以看到"知识库"标签页，点击即可进入知识库管理界面。

在这个界面的左侧，我们可以看到已有的知识库列表——包括在线知识库和本地知识库。右侧区域是 AI Agent 的对话窗口，知识库和 Agent 共享同一个工作空间。这个布局本身就暗示了两者的紧密关系。

创建一个知识库

接下来我们实际操作一下。点击"快捷创建知识库"按钮，或者在知识库列表下方找到"新建知识库"入口。

系统会弹出一个参数填写窗口：

我们需要填入以下几个关键参数：

01 知识库名称：给知识库起一个语义化的名字，方便后续在 Agent 中引用

02 上传文件：支持直接拖拽或选择文件路径，可以导入 PDF、文档、文本等格

03 构建模式：这里有两个选项——"增强知识图谱索引"和"仅构建知识索引"

04 Tags：可选的分类标签，用于组织和筛选

两种构建模式

构建模式的选择直接影响知识库的存储结构和查询能力。我们用一张表来对比：

"增强知识图谱索引"模式会对文档进行深度分析：先切片，然后通过 ERM（Entity Relationship Model）抽取实体和关系，构建知识图谱；同时还会为每个切片生成问题索引，用于向量化检索。整个过程涉及多轮 AI 调用，因此构建时间会更长，但查询质量也更高。

"仅构建知识索引"模式更轻量。它跳过了实体关系抽取的步骤，直接对切片内容生成查询强化索引，然后向量化入库。如果你的文档本身已经是高质量的结构化知识（比如 API 文档、技术规范），这个模式的性价比更高。

实战：导入 GB/T 34944-2017

我们用一个具体的例子来走完整个流程。这次选择导入 GB/T 34944-2017《Java 语言源代码漏洞测试规范》这份国标文档。

在弹窗中填入知识库名称为"我的知识库"，上传文件选择本地的 PDF 文件路径，构建模式选择"增强知识图谱索引"——因为国标文档包含大量的漏洞分类、测试方法和判定标准之间的关联关系，适合构建知识图谱。

点击"确定"后，构建过程开始执行。在执行面板中可以实时看到构建进度：

从日志中可以观察到几个关键阶段：

01 文档解析：系统识别 PDF 文件类型，解析文档内容

02 分片处理：将长文档切分为多个 chunk，每个 chunk 保持语义完整性

03 实体图谱构建：start build entity graph concurrency 表明系统开始并行地抽取实体和关系

04 索引入库**：抽取完成后，实体、关系和向量索引写入本地存储

构建完成后，我们可以在知识库界面看到结果。

知识图谱可视化

这是最直观的部分。切换到知识库的图谱视图，可以看到系统自动抽取出来的实体和关系网络：

选择任意一个节点，可以查看该实体的详细属性和关联关系。这个图谱在后续的查询中会发挥重要作用——当 Agent 搜索到一个实体时，可以通过 K-hop 遍历找到与它关联的其他知识点，这就是多跳知识查询的基础。

查询验证

知识库构建好了，接下来验证一下查询效果。

简单召回

在知识库界面的"AI 召回"功能区，我们可以直接测试知识库的召回能力。点击"AI 召回"标签，在搜索框中输入一个问题，比如：

Java 中关于日志的相关安全设置应该如何操作？

系统会将问题转化为搜索查询，在选中的知识库中检索相关内容。搜索框下方的 @ 选择器可以指定搜索范围——是搜索所有知识库，还是只搜索特定的某一个。

Agentic RAG 召回

这才是真正有意思的部分。

当我们发起一次 Agentic RAG 查询时，系统会将用户的问题转化为一个 Agent 搜索任务。AI 会自主决定搜索策略，然后逐步探索知识库中的内容。

我们可以观察到几个关键行为：

01 AI 先理解用户问题的意图，将其拆分或泛化为多个子查询

02 调用 search_knowledge_semantic 和 search_query 等搜索函数

03 对每轮搜索结果进行评估，判断信息是否充分

04 如果需要更多细节，自动调整查询内容进行下一轮搜索

查询结果

来看一个典型的查询结果。我们问了一个关于"Java 日志安全设置"的问题，系统返回了结构化的回答：

这个结果有几个值得注意的地方。AI 对搜索到的多个知识片段进行了去重、合并和结构化整理，形成了"日志安全守则"这样的归纳性标题，下面按"日志访问控制"、"禁止日志记录敏感信息"等维度组织具体内容。每个要点都可以追溯到原始的知识库条目——这些内容来自 GB/T 34944 中关于日志安全的多个章节，AI 把它们关联起来了。

从Agent中直接使用知识库

到现在为止，我们展示的还是在知识库界面中手动查询的场景。那么更核心的问题来了：Agent 执行任务的时候，如何使用知识库？

在 Memfit AI 的对话界面中，我们可以通过 @ 符号引用知识库。

Agent 在规划和执行任务的过程中，会根据当前任务的需要自主决定是否查询知识库、查询哪个知识库、用什么问题去查。

举个具体的例子。我们让 Agent 回答一个综合性问题，这个问题涉及 Java 安全领域的多个方面。Agent 在执行过程中，自动触发了知识库的 Agentic 搜索。

我们搜索一个综合问题，可以看到 Agentic 的两轮搜索过程。第一轮搜索拿到了部分结果，Agent 评估后认为还缺少某些维度的信息，于是调整了查询内容进行第二轮搜索。

这种自我调整的能力，一般的独立知识库系统做不到——它们只会被动地接收查询、返回结果。Agent 的"主动探索"才是 Agentic RAG 真正的价值所在。

这也是为什么我们说"知行合一"。知识库提供记忆，Agent 提供行动力，两者在同一个运行时内紧密协作。Agent 遇到不确定的问题时，会像一个经验丰富的工程师翻阅参考手册一样，反复查找、交叉验证，直到获得足够的信心来做出判断。

Memfit是如何实现这些的？

讲完了使用体验，我们来看看底层的技术实现。这部分面向对 RAG 系统和 Agent 架构有兴趣的读者，我们会结合实际代码来分析几个关键模块。

强化索引构建与知识图谱构建

文档从上传到可查询，需要经过一条完整的处理管线。我们用一张流程图来说明：

两种模式的差异体现在中间环节。"增强知识图谱索引"模式走完整链路：ERM 抽取 + 问题索引 + 向量化；"仅构建知识索引"模式跳过 ERM，直接从分片内容生成问题索引。

问题索引构建是一个值得展开说的环节。系统会调用 AI 对每个文档切片生成一组"检索问题"——这些问题模拟的是真实用户可能会搜索的内容，覆盖了操作方法、概念定义、原因分析、最佳实践、故障排查等多个维度。核心逻辑在 BuildIndexQuestions 函数中：

funcBuildIndexQuestions(rawInput []string, aiService aicommon.AICallbackType)
(map[string][]string, error) {
    linedInput := utils.PrefixLinesWithLineNumbers(rawInput)
    query, err := LiteForgeQueryFromChunk(indexBuildPrompt, "",
chunkmaker.NewBufferChunk([]byte(linedInput)), 200)
    // ...
    result, err := aicommon.InvokeLiteForge(query, forgeOpts...)
    // ...
    entries, err := index2KnowledgeEntity(result.Action, rawInput)
    return entries, nil
}

这个函数做了几件事：把原始文本加上行号标记，组装成带有详细指令的 prompt，调用 LiteForge（Memfit 的轻量级 AI 执行引擎）生成问题列表，最后将问题和原文中对应的答案片段映射起来。生成的每个问题都附带了精确的行号范围，指向原文中能回答这个问题的具体段落。

这些问题随后会被向量化，和原始文本的向量一起存入 HNSW（Hierarchical Navigable Small World）向量索引中。查询的时候，用户的问题会同时和"原始内容向量"以及"生成的问题向量"进行匹配——因为生成的问题更接近用户的搜索习惯，召回率会显著提升。

知识图谱的构建则通过 ERM 实体关系抽取完成。系统利用 AI 从文档中识别出实体（如漏洞类型、安全标准、测试方法等）和它们之间的关系（如"属于"、"测试方法"、"防护措施"等），构建成一张有向图。这张图存储在本地数据库中，支持 K-hop 多跳遍历查询。

多策略搜索管线

一条用户查询进来之后，系统不会只做一次简单的向量搜索。实际上，Memfit 的搜索管线会并行执行多种搜索策略，然后将所有结果融合排序。

五种搜索策略各有侧重，对应代码中的 SearchHandler 接口：

01 基础向量搜索（Basic）：用原始查询直接做向量相似度匹配，这是最基本的语义搜索

02 HyDE 假设回答（Hypothetical Document Embedding）：AI 先针对用户问题生成一段"假设的理想答案"，然后用这段答案作为查询内容去搜索。因为"答案"和"文档内容"的语义空间更接近，往往能搜到直接搜问题搜不到的结果

03 子问题拆分（Split Query）：将复杂问题拆解为多个可独立检索的子问题，分别搜索后合并结果。比如"Java 日志安全的最佳实践和常见漏洞"会被拆成两个子问题分别搜索

04 概念升维（Generalize Query）：把具体问题提升到更高层的概念维度进行搜索。比如"Redis 未授权访问漏洞"会被升维为"NoSQL 数据库安全风险"的相关搜索，捕获更宏观的综述性文档

05 关键词提取（Exact Keyword Search）：从问题中提取核心关键词进行精确的词条匹配，弥补向量搜索在专有名词上的不足

我们以 HyDE 为例看一下具体实现。HypotheticalAnswer 函数的核心逻辑是让 AI 生成一段控制在 100 字以内的"理想答案摘要"：

func(h *LiteForgeSearchHandler) HypotheticalAnswer(ctx context.Context, query string)
(string, error) {
    prompt := `你是⼀个精通信息检索的AI助⼿。
根据⽤户提出的【问题】，精准地提炼出其核⼼概念，
并⽣成⼀段信息密度极⾼的"理想答案摘要"。
严格控制在100字以内。`
    // ...
    result, err := aicommon.InvokeLiteForge(inputPrompt, ...)
    document_paragraph := result.GetString("hypothetical_answer")
    return document_paragraph, nil
}

这段假设回答会被向量化，然后用它的向量去搜索真实的文档——这个技巧来自学术界的 HyDE 方法，在实践中对提升召回率非常有效。

AI 重排与精炼

五种策略并行执行后，会产生大量的候选结果，其中不可避免地存在重复和噪音。这时候需要两道"精炼"工序：

第一道：RRF 重排（Reciprocal Rank Fusion）

每个搜索策略会对自己的结果集按相关度排序。RRF 算法将不同策略的排名信息融合成一个统一的分数，核心公式是：

$$RRF(d) = \sum_{i=1}^{n} \frac{1}{k + rank_i(d)}$$

其中 $k$ 是一个平滑常数（Memfit 默认设为 60），$rank_i(d)$ 是文档 $d$ 在第 $i$ 个策略中的排名。如果一个文档在多个策略中都排名靠前，它的 RRF 分数就会很高。实现代码很简洁：

funcRRFRank[TRRFScoredData](scoredDataList []T, k int) []T {
    // 按搜索⽅法分组，计算每个⽂档在各⽅法中的排名
    // 然后对每个⽂档求 RRF 累加分
    // 最后按 RRF 分数降序排列
}

RRF 的好处是它不依赖原始分数的绝对值，只看排名——因此可以安全地融合来自不同评分体系的结果。

第二道：AI 摘要精炼

RRF 排序后取 Top-K 个结果，如果启用了 EnableAISummary，系统会将这些结果汇总送给 AI，生成一份精炼的回答。AI 的工作指令很明确：

仅基于知识库条目的内容回答用户问题，不要引入外部知识或主观推断；若无法从条目中得到答案，请直接回复"未在知识库中找到相关信息"。

这确保了最终回答严格基于知识库内容，不会混入大模型的"幻觉"。

Agentic 自我调整与多轮迭代

到这里，我们已经讲清楚了单次查询的完整流程。那么 Agentic RAG 的"多轮搜索"又是怎么实现的？

核心机制可以拆解为三个环节：

01 搜索计划制定。

Agent 收到一个需要知识支撑的问题后，首先分析问题涉及哪些知识维度。比如"Java 安全审计的完整流程"可能涉及漏洞分类、测试方法、工具使用、报告规范等多个方面。Agent 会据此决定第一轮搜索的查询内容。

02 结果评估与调整。

每轮搜索完成后，Agent 会评估已有结果是否足以回答用户的问题。如果发现某个维度的信息缺失——比如搜到了漏洞分类和测试方法，但没有搜到报告规范相关的内容——Agent 会调整下一轮的查询，专门补充这个缺口。

03 多轮结果合并。

所有搜索轮次完成后（或者 Agent 判断信息已经充分），系统将多轮结果进行去重（同一个知识片段可能在不同轮次中被多次命中）、合并（相关度高的片段聚合在一起），最终生成一份结构化的回答。

这个过程和真人查阅资料的行为模式非常相似：先快速浏览一遍，发现某个方面的内容不够，再针对性地深入查找。区别在于 Agent 可以在几秒钟内完成这个迭代，而人类可能需要翻半天文档。

当然，这里有一个工程上的平衡问题。搜索轮次越多，召回的信息越全面，但耗时也越长。我们暂时设定了 3 到 5 轮的上限，在大多数场景下这个范围足够覆盖一个综合性问题的各个维度。后续我们会根据实际使用数据持续调优这个参数。

Agent干活的时候也可以查资料吗？

前面我们演示了在知识库界面中查询和在对话中 @ 知识库的场景。但这些都还停留在"问答"层面——用户主动提问，系统被动回答。

那么，真正的生产场景呢？

如果我们给 Agent 下达一个具体的任务——比如"对一个 Java SpringBoot2 项目进行代码审计"——Agent 在执行过程中能不能自己去翻阅知识库里的安全规范？

我们来试一下。在 Memfit AI 的对话框中输入任务指令，同时通过 @ 符号挂载上刚才创建的知识库：

注意看这个操作：我们告诉 Agent "进行代码审计"，并且指定使用 @我的知识库 中的内容来辅助审计过程。Agent 接到指令后，会将知识库作为自己的"参考资料"带入整个任务执行链路。

先查知识，再规划任务

Agent 启动任务后，做的第一件事很有意思——它没有直接开始扫描代码，而是先去知识库里查了一轮资料。

从执行日志中可以看到，Agent 在规划阶段就触发了知识库搜索。它从 GB/T 34944 中检索到了 Java 代码审计需要关注的漏洞类型和测试方法，然后基于这些知识来制定任务计划。

这个顺序值得留意：先查资料，再定方案。这和一个有经验的安全工程师接到审计任务时的行为模式完全一致——拿到项目之后，先翻一遍安全规范，搞清楚要审什么、按什么标准审，然后才开始动手。

更值得关注的是，执行过程中我们看到了上一篇文章中介绍过的动态任务规划能力。Agent 在查阅知识库之后，根据检索到的安全规范条目，主动修改了自己的任务列表——把原本比较笼统的"代码审计"拆分成了更具体的子任务，比如针对 SQL 注入的检测、针对 XSS 的检测、针对日志安全的检测等等。每个子任务的目标和方法都贴合了知识库中的规范要求。

这就是知识库和 Agent 深度融合之后产生的化学反应：知识库的内容直接影响了 Agent 的行为决策，Agent 的任务规划会随着知识的注入而变得更加精准和有针对性。

执行结果

当然我们毫不意外的可以收获一些漏洞：

当我们等待系统执行完毕，可以看到如下内容：

这个流程和前面"在对话中 @ 知识库问问题"的场景有本质区别。对话中的查询是一次性的，Agent 问完就结束了；而在任务执行中，知识库被反复调用，贯穿了规划、执行、判定、报告的全过程。

Agent 真正把知识库当成了自己随身携带的"参考手册"——需要的时候翻一下，不需要的时候放在一边，但始终带在身上。

回顾

我们在本文中完成了四件事：

第一，从操作层面走通了整个流程。

从进入知识库界面、创建知识库、选择构建模式、导入 PDF 文档，到查看知识图谱、执行查询验证——这些步骤在 Memfit AI 中都可以在几分钟内完成。

第二，展示了 Agentic RAG 的实际效果。

通过对 GB/T 34944 的查询测试，我们看到了 Agent 如何自主地多轮搜索、逐步完善答案。这种能力在处理综合性问题时尤为明显——单轮搜索拿不到的信息，多轮迭代后往往可以覆盖到。

第三，在真实的生产任务中验证了知识库与 Agent 的协作。

代码审计任务的执行过程表明，Agent 会在规划阶段主动查阅知识库，根据检索到的安全规范调整任务计划，并在整个执行链路中持续引用知识库内容来辅助判定。知识库对 Agent 的影响贯穿了从规划到输出的全过程。

第四，深入了底层实现。

从问题索引构建到五策略并行搜索，从 RRF 重排到 AI 摘要精炼，再到 Agentic 多轮迭代——整条链路的设计目标很一致：让知识库成为 Agent 的有机组成部分，让"查知识"变成一个主动的、可迭代的、有策略的过程。

Memfit AI 的知识库系统目前已经在产品中上线。如果你有兴趣体验，可以直接访问 https://memfit.ai/ 下载 Memfit AI。内测推广阶段不收取任何 Token 费用，当然也支持配置你自己的 AI APIKEY 使用。

memfit:: 记得住的知识库，看得见的行动力

在接下来的文章中，我们会为大家介绍 Memfit AI 的更多高级能力——包括技能系统（Skills）的定制、多 Agent 协作，以及如何将知识库应用到实际的安全审计工作流中。

---

本文首发于 Yak Project 公众号，阅读原文。