1. 为什么你的 Agent 总是「失忆」从 RAG 检索到 LLM Wiki 的真实困境如果你正在做 Agent 应用大概率遇到过这种场景用户上周问过「我们的退款政策对海外订单怎么算」Agent 答得挺好这周用户换个说法再问Agent 又从头检索一遍甚至给出一个和上次矛盾的答案。你翻日志发现两次检索命中的文档片段还不一样——一次命中了「海外订单」章节一次命中了「退款时效」章节拼出来的上下文自然对不上。这不是模型不行是记忆架构的问题。RAGRetrieval-Augmented Generation检索增强生成解决的是「知识不在模型参数里」的问题它把文档切片、向量化、存进向量库提问时按语义相似度捞回 Top-K 片段塞进提示词。这套流程在「单次问答」场景下非常好用但一旦进入「长期陪伴型 Agent」场景三个硬伤就暴露了第一切片割裂。一篇 5000 字的规范文档被切成 20 个 256 token 的片段用户问「A 规范和 B 规范在超时重试上的差异」A 规范的重试策略在第 3 片B 规范的重试策略在第 17 片向量检索按相似度只捞回其中一片另一片因为措辞不同没被召回答案就残缺了。第二重复推演。同一个问题这周问、下周问Agent 每次都重新走一遍「检索→拼上下文→推理」的完整链路。上次推理出来的结论没有被保存下次还得重算。token 在烧延迟在涨答案还可能因为检索随机性而漂移。第三被动响应。RAG 不会主动告诉你「你知识库里有两份文档对同一个 API 的超时时间描述不一致」也不会主动说「这个概念你引用了三次但从来没定义过」。它只在你问的时候才动。这三个问题本质上是同一个问题知识被「存」起来了但没有被「编译」。RAG 像把书页撕下来塞进抽屉需要时按关键词翻抽屉LLM Wiki 像把这些书页重新编成一本有目录、有交叉引用、有版本记录的百科。前者解决「找不到」后者解决「重复找」和「不会整理」。这篇文章我会带你走一遍从 RAG 到 LLM Wiki 的落地路径先给出一套可复制的知识库目录结构再给出检索与写入的配置示例最后用一组问答验证记忆召回效果。中间会用到 TaoToken 作为模型接入层因为它的 API 兼容 OpenAI 格式配置成本低适合边写边测。2. TaoToken 前置准备把模型接入层先跑通在动手搭知识库之前得先把模型调用跑通。原因很简单LLM Wiki 的核心动作是「增量编译」——每次写入新知识时要让模型帮你抽取实体、建立关联、生成摘要。这些动作都要调模型。如果模型接入层不稳定后面所有步骤都是空中楼阁。TaoToken 在这里的角色是「统一的模型接入网关」。你不需要为每个模型单独维护一套 SDK 和鉴权逻辑它提供 OpenAI 兼容的接口Base URL 指向https://taotoken.net/api用一套 Key 就能切换不同模型。对于知识库这种「写入时用便宜模型做抽取、查询时用强模型做推理」的场景统一接入层能省掉大量胶水代码。先拿 Key。打开https://taotoken.net/api-keys登录后创建一个 API Key复制出来。注意这个 Key 只在创建时显示一次丢了就得重建。拿到 Key 之后先别急着写知识库代码用一条 curl 验证接入层是通的curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的Key \ -d { model: gpt-4o-mini, messages: [ {role: user, content: 用一句话解释什么是向量检索} ], temperature: 0.3 }如果返回里能看到choices[0].message.content说明接入层没问题。这一步看起来简单但它是后面所有「增量编译」动作的前提。我见过太多人卡在「知识库代码写完了但模型调不通」上排查半天发现是 Key 没配对或者 Base URL 写成了官网地址而不是/api。这里有个细节要注意Base URL 是https://taotoken.net/api不是https://taotoken.net。很多 OpenAI SDK 的默认行为是在 Base URL 后面拼/v1/chat/completions所以如果你在代码里写base_urlhttps://taotoken.net/api最终请求会打到https://taotoken.net/api/v1/chat/completions这是对的。但如果你写base_urlhttps://taotoken.net就会打到https://taotoken.net/v1/chat/completions直接 404。模型选择上写入阶段抽取实体、生成摘要用gpt-4o-mini这类便宜模型就够了查询阶段多跳推理、矛盾检测再切到gpt-4o或claude-3-5-sonnet。TaoToken 的好处是切换模型只改一个字符串不用动鉴权逻辑。如果你打算长期跑 Agent 记忆系统建议直接上 Coding Plan因为知识库的增量编译是持续动作按量计费容易失控包月更划算。入口在https://taotoken.net/coding-plan。3. 可复制的知识库目录结构与写入配置现在进入正题。LLM Wiki 和 RAG 最大的区别在于RAG 的存储是「扁平」的——所有切片扔进一个向量库靠相似度捞LLM Wiki 的存储是「分层」的——原始材料、实体、概念、综合摘要各占一层检索时按层路由。先给目录结构。这套结构参考了 OpenClaw memory-wiki 的组织方式但做了简化适合个人知识库起步knowledge-vault/ ├── sources/ # 原始材料文章、对话记录、文档导入 │ ├── 2024-01-15-rag-notes.md │ └── 2024-01-20-agent-memory.md ├── entities/ # 持久事物人物、系统、项目、工具 │ ├── taotoken.md │ └── gbrain.md ├── concepts/ # 抽象概念设计模式、架构思想 │ ├── incremental-compilation.md │ └── knowledge-graph.md ├── syntheses/ # 编译后的摘要整理后的知识汇总 │ └── agent-memory-comparison.md ├── reports/ # 仪表盘知识状态可视化 │ └── knowledge-health.md └── config/ ├── vault.toml # 知识库配置 └── models.json # 模型路由配置这个结构的关键在于sources/是只读的原始层entities/和concepts/是编译层syntheses/是综合层。写入新知识时不是往sources/里扔一个文件就完事而是要触发一次「编译」——让模型读原始材料抽取实体和概念更新对应的编译层文件。接下来是配置文件。config/vault.toml定义知识库的基本参数[vault] name my-agent-memory root ./knowledge-vault default_mode bridge # isolated / bridge / unsafe-local [retrieval] top_k 8 similarity_threshold 0.72 enable_multi_hop true max_hops 3 [compilation] auto_compile true compile_on_write true entity_extraction_model gpt-4o-mini synthesis_model gpt-4oconfig/models.json定义模型路由把不同任务映射到不同模型{ base_url: https://taotoken.net/api, api_key_env: TAOTOKEN_API_KEY, routes: { entity_extraction: { model: gpt-4o-mini, temperature: 0.1 }, concept_linking: { model: gpt-4o-mini, temperature: 0.2 }, synthesis: { model: gpt-4o, temperature: 0.3 }, multi_hop_reasoning: { model: claude-3-5-sonnet, temperature: 0.2 } } }注意api_key_env写的是环境变量名不是 Key 本身。Key 通过环境变量注入export TAOTOKEN_API_KEYsk-你的Key写入流程的代码大概长这样Python 示例import os import json from openai import OpenAI client OpenAI( base_urlhttps://taotoken.net/api, api_keyos.environ[TAOTOKEN_API_KEY] ) def compile_source(source_path: str, vault_root: str): with open(source_path, r, encodingutf-8) as f: raw f.read() # 第一步抽取实体和概念 extract_resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 从以下文本中抽取实体和概念输出 JSON。}, {role: user, content: raw} ], temperature0.1 ) extracted json.loads(extract_resp.choices[0].message.content) # 第二步更新 entities/ 和 concepts/ for entity in extracted.get(entities, []): entity_file os.path.join(vault_root, entities, f{entity[name]}.md) # 增量更新逻辑读旧文件、合并、写回 update_entity_file(entity_file, entity) # 第三步生成综合摘要 synthesis_resp client.chat.completions.create( modelgpt-4o, messages[ {role: system, content: 基于以下材料生成结构化摘要。}, {role: user, content: raw} ], temperature0.3 ) write_synthesis(vault_root, synthesis_resp.choices[0].message.content)这段代码的核心是「增量」不是覆盖是合并。update_entity_file要读旧文件、对比新信息、追加或修正而不是直接重写。这一步做不好知识库就会变成「每次写入都覆盖上一次」的假 Wiki。4. 验证请求用一组问答测试记忆召回效果配置写完了得验证它真的能工作。验证分两步先测「写入是否生效」再测「召回是否准确」。写入验证往sources/里放一篇新文档跑一次compile_source然后检查entities/和concepts/里是否出现了对应的新文件或更新。比如你放一篇讲「GBrain 矛盾检测」的文档跑完之后entities/gbrain.md应该被更新concepts/contradiction-detection.md应该被创建。召回验证设计一组「多跳问题」看 Agent 能不能跨层检索。多跳问题的定义是「需要两步以上查找才能回答」。比如问题一「TaoToken 的 Base URL 和 GBrain 的矛盾检测有什么关系」这个问题需要先查entities/taotoken.md拿到 Base URL再查entities/gbrain.md拿到矛盾检测的定义然后推理两者在「知识库写入流程」中的协作关系。问题二「增量编译和 RAG 的切片策略有什么本质区别」需要查concepts/incremental-compilation.md和sources/里的 RAG 笔记做对比推理。测试代码def multi_hop_query(question: str, vault_root: str): # 第一跳语义检索 search_resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 从知识库中找出与问题相关的实体和概念名称输出 JSON 列表。}, {role: user, content: question} ] ) related json.loads(search_resp.choices[0].message.content) # 第二跳读取相关文件 context for item in related: for layer in [entities, concepts, syntheses]: path os.path.join(vault_root, layer, f{item}.md) if os.path.exists(path): with open(path, r, encodingutf-8) as f: context f\n\n## {layer}/{item}\n f.read() # 第三跳基于上下文推理 answer_resp client.chat.completions.create( modelclaude-3-5-sonnet, messages[ {role: system, content: 基于以下知识库内容回答问题。如果信息不足明确说明缺什么。}, {role: user, content: f知识库内容\n{context}\n\n问题{question}} ], temperature0.2 ) return answer_resp.choices[0].message.content跑完这组测试你会看到两个结果如果召回准确答案会引用多个文件的内容并且能说清「A 和 B 的关系」如果召回失败答案会含糊其辞或者只引用一个文件。失败的时候去reports/knowledge-health.md里看知识缺口——通常是某个实体文件没建全或者概念之间的关联没写进去。这里有个实测经验similarity_threshold设 0.72 是个比较稳的起点。设太高0.85会漏召回设太低0.6-会引入噪声。多跳的max_hops设 3 足够超过 3 跳的问题通常说明知识库结构有问题该去补实体关联而不是加跳数。5. 常见报错排查401、local proxy failed、reading choices、OAuth搭这套东西的过程中报错基本集中在四类。我按出现频率排一下每类给排查路径。401 Unauthorized。最常见原因通常是 Key 没注入或者注入错了。检查三件事环境变量TAOTOKEN_API_KEY是否在当前 shell 里生效echo $TAOTOKEN_API_KEY代码里读的是不是这个变量名Key 有没有多余空格。如果用的是.env文件确认加载顺序——有些框架在 import 阶段就读环境变量.env加载晚了就会读到空值。local proxy failed。这个报错通常出现在你本地配了 HTTP 代理但代理没启动或者规则不对。排查先curl -v https://taotoken.net/api/v1/models看请求实际打到哪如果走了代理检查HTTP_PROXY/HTTPS_PROXY环境变量如果不需要代理直接unset掉。注意这里说的是本地开发环境的网络配置问题不是让你去搞什么特殊网络工具纯粹是排查环境变量污染。reading choices of undefined。这是 OpenAI SDK 的经典报错意思是响应体里没有choices字段。原因通常是请求根本没成功返回了错误 JSON但代码直接读了resp.choices[0]。修复方式是在读取前先判断if not resp or not hasattr(resp, choices) or not resp.choices: print(响应异常, resp) raise ValueError(模型返回为空)更根本的修复是加一层错误处理把 HTTP 状态码和响应体打出来。很多情况下这个报错背后是 401 或 429只是被 SDK 吞掉了。OAuth 相关报错。如果你用的是 Claude Code 或者某些需要 OAuth 的客户端可能会遇到 token 过期或者 scope 不对。这类问题的排查路径是先确认你用的是 API Key 模式还是 OAuth 模式如果用 API Key确保 Base URL 指向https://taotoken.net/api不要指向需要 OAuth 的端点。Claude Code 的接入配置里Base URL、Key、Model ID 三件套要写全{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: claude-3-5-sonnet }少写任何一个都会导致鉴权失败。Model ID 要写对claude-3-5-sonnet和claude-3.5-sonnet在某些客户端里不通用以文档为准。排查顺序建议先 curl 验证接入层再验证 SDK 调用最后验证知识库逻辑。不要一上来就怀疑知识库代码八成问题在接入层。6. 从 RAG 到 LLM Wiki你的下一步动作如果你读到这里说明你已经理解了从 RAG 到 LLM Wiki 的核心差异RAG 是「存起来需要时找」LLM Wiki 是「编译起来需要时直接用」。前者解决「找不到」后者解决「重复找」和「不会整理」。下一步动作建议按这个顺序走第一步先把 TaoToken 的接入层跑通用https://taotoken.net/api-keys拿 Key用 curl 验证/api/v1/chat/completions能返回。这一步不通过后面都是空谈。第二步把上面的目录结构复制到本地建一个最小的knowledge-vault/先放三篇sources/跑一次compile_source看entities/和concepts/有没有生成文件。生成失败就去查config/models.json里的模型名和 Key。第三步设计五个多跳问题跑multi_hop_query记录哪些问题召回准确、哪些失败。失败的问题去reports/knowledge-health.md里找缺口补实体关联。第四步如果你打算长期跑把模型路由切到 Coding Plan避免按量计费失控。入口在https://taotoken.net/coding-plan。最后说一个我踩过的坑不要试图一次性把知识库建「完整」。LLM Wiki 的价值在「增量编译」不在「初始完备」。你每次学新东西花五分钟编译进去三个月后知识库的复利效应会远超你一次性整理三天的成果。知识不是被「存」起来的是被「编译」成更有价值的结构——这句话值得贴在显示器上。