TencentDB Agent Memory · 第 7 章 知识引擎:Wiki 与 CodeGraph 章节摘要:第 4 章的四层记忆处理的是「对话」,本章处理另外两类同样重要、但形态完全不同的内容——文档与代码。文档被整理成 Wiki:由 LLM 增量维护、生成结构化页面与链接图谱,让 Agent 不必先读完所有文件目录再开工。代码被索引成 CodeGraph:含符号、文件、调用关系与影响路径,Agent 不只能查「代码在哪」,还能在改代码前做 impact analysis(改了可能影响哪)。两者都不整库注入上下文,而是作为「按需调用的工具」存在——Agent 先用 发现有哪些能力,再用 读取真正需要的页面或符号。
章节摘要:第 4 章的四层记忆处理的是「对话」,本章处理另外两类同样重要、但形态完全不同的内容——文档与代码。文档被整理成 Wiki:由 LLM 增量维护、生成结构化页面与链接图谱,让 Agent 不必先读完所有文件目录再开工。代码被索引成 CodeGraph:含符号、文件、调用关系与影响路径,Agent 不只能查「代码在哪」,还能在改代码前做 impact analysis(改了可能影响哪)。两者都不整库注入上下文,而是作为「按需调用的工具」存在——Agent 先用
/v3/tools/list发现有哪些能力,再用/v3/tools/call读取真正需要的页面或符号。本章带你读这两个引擎的工作机制,以及它们背后 Auto-Sync 的 FIFO 队列与 worker pool 如何让知识「一直新鲜」。读完本章你会理解为什么「知识不整库注入而是按需调用」是对有限上下文窗口最聪明的工程应对。
阅读完本章,你应当能够:
/v3/tools/list 与 /v3/tools/call 的「自发现 + 按需调用」机制,以及它为何优于整库注入一句话金句:Wiki 和 CodeGraph 让「文档和代码」也成了记忆,但它们平时是工具、用到了才进上下文——这是把无限增长的资料塞进有限窗口的唯一解法。
讲清 Wiki 如何由 LLM 增量维护、从原始文档生成结构化页面与彼此链接,灵感来源于「把文档视为可持续复利的知识产物」的思路。
讲清 CodeGraph 索引的四类信息,重点解释「影响路径(impact analysis)」为何是它区别于普通代码搜索的独特价值。
/v3/tools/list 与 /v3/tools/call讲清 Agent 如何先用 list 发现能力、再用 call 读取片段,解释这种「自发现 + 按需调用」为何优于整库注入。
讲清知识如何随源仓库变化自动更新:FIFO 队列保序、worker pool 并发处理、状态机跟踪 ready。
本章前两节讲「两类知识是什么」,后两节讲「它们如何被调用与保持新鲜」:
┌──────────┐ ┌──────────┐ │ 01 Wiki │ │ 02 CodeGraph│ (两类知识:是什么) │ 文档图谱 │ │ 代码图谱 │ └──────────┘ └──────────┘ │ │ └──────┬───────┘ ▼ ┌────────────┐ ┌────────────┐ │ 03 按需调用 │──▶│ 04 Auto-Sync│ (两条机制:怎么用+怎么新) │ list+call │ │ 队列+worker │ └────────────┘ └────────────┘
铺垫说明:本章聚焦知识引擎本身的工作机制,不展开「人在哪里发起构建」(第 5 章 Knowledge 工坊)与「代理层如何把知识作为工具暴露给 Agent」(第 8 章 injection 的 toolize 策略)。本章是知识引擎的内部视角,第 8 章是它与代理层的接口视角。
前置知识:
本章为后续章节奠定的基础:
/v3/tools/list + /v3/tools/call 机制是第 8 章 toolize 注入策略的工具来源