在信息爆炸的今天我收藏夹里的文章已经超过一千篇但真正能被我想起来、用上的可能不到十分之一。直到我看了 Andrej Karpathy 关于 LLM Wiki 的一系列分享才突然意识到问题不在“收藏量不够”而在“收藏之后没有人去整理、连接、更新”。他用一个很朴素的想法点醒了我如果 LLM 不是一个“问答盒子”而是一个能维护知识库的图书管理员那我的本地笔记库完全可以变成一张越用越密的网。于是我把 Obsidian 里的收藏文章作为原材料用 Codex 这个能读写本地文件、批量执行任务的智能体来跑这套“LLM Wiki 工作流”。这篇文章就是我完整复现这套流程的记录包含目录设计、Codex 配置、批量抽取、双向链接生成、图谱检验和大量报错排查经验希望能让和我一样在笔记坑里挣扎的人少走弯路。1. 先理解 LLM Wiki为什么“收藏”不等于“知识”很多人对 Karpathy 提出 LLM Wiki 的理解停留在“用 LLM 自动生成笔记”这个层面这其实低估了这件事。他想解决的是个人知识管理中最核心的一个矛盾传统 Wiki 需要人工维护链接断了没人管、目录过期了没人改、新知识和旧知识之间没有关联维护成本高到根本不可持续。而 LLM 的加入让知识库第一次有了一个“专职编辑”它可以读完全部笔记、理解条目之间的关系、自动补链接、生成索引甚至在你导入新文章时主动把它挂到已有的知识网络上。1.1 收藏夹的困境与 Karpathy 的思路我先说个真实感受。早期我用文件夹管理收藏文章按“产品、技术、AI、写作”分门别类。表面上看很整齐实际上每篇文章都是孤岛一篇关于 Agent Memory 的文章被丢进“AI”文件夹后再也没有出现过一篇讨论写作框架的文章和另一篇讲卡片盒笔记法的文章明明高度相关却因为路径不同永远碰不到面。文件夹是树状结构它天然不适合表达“一篇笔记属于多个主题”这种网状关系。Obsidian 的双向链接和关系图谱解决了“网状表达”的问题但是新的瓶颈又出现了创建链接、维护索引、补充摘要这些全是体力活纯靠手工做的成本极高。Karpathy 的思路恰好切在这个痛点上。他提出知识库不应该是一堆被动等待检索的文本而应该是一个可以不断被自动维护的结构化“Wiki”LLM 在这个 Wiki 里扮演的角色不是搜索框而是编辑和维护者它读入一篇新文章提炼要点找出和现有条目的关联写入新的页面更新总索引。这套循环跑起来之后知识管理的单位就从“单篇文章”变成了“整个网络”。1.2 为什么这套工作流值得用 Codex 而不是普通插件在选工具的时候自然要面对一个选择现在 Obsidian 生态里也有很多 AI 插件为什么非要用 Codex 构建工作流我的判断标准只有一条——谁才能真正“操作”整个库。Obsidian 里的绝大多数 AI 插件本质上是“问答助手”你问一句它答一句偶尔帮你生成一段文字但它没有能力批量扫描 200 篇旧笔记并主动重组文件链接。Codex 是一个能访问本地文件系统、能执行命令、能写代码、能一次性完成多步骤任务的智能体它更接近一个“代理”而不是聊天窗口。还有一个很现实的原因Codex 对纯 Markdown 文本的处理能力非常强而 Obsidian 的数据恰好就是一堆 Markdown 文件。这意味着 Codex 可以直接打开目录、遍历文件、修改 frontmatter、生成新的 .md 文件整个流程清晰可控。作为对比我也试过用思源笔记来搭这套东西思源的块级引用和双链能力其实很强但它的数据底层是 JSON 结构Codex 直接操作文件的成本明显更高远不如 Obsidian 这种“每个笔记一个文件”的形态来得顺手。所以这套方案的最终形态就是纯文本存储 智能体批量维护 图谱可视化。2. 动手前的基础Codex CLI 与 Obsidian 的环境准备在开始“织网”之前得先把两个工具打磨到能顺畅协作的状态。Codex 负责跑批量任务Obsidian 负责展示和维护知识库它们之间没有官方插件靠的就是文件目录和格式约定。这套约定一旦定好后面所有流程都能自动化。2.1 Codex CLI 安装与登录如果你还没装 Codex可以先通过官方渠道安装。macOS 上最简单的是直接用 Homebrew 安装命令就一行brew install codex如果你习惯用 npm也可以全局安装官方发布的 CLI 包npm install -g openai/codex装完之后需要登录认证。Codex 支持两种身份方式一种是直接用 ChatGPT 账号授权运行codex login后会在浏览器里打开授权页面这种方式适合个人轻度使用另一种是使用 API Key 方式在.codex/config.toml里配置模型和访问地址适合需要批量执行、对 token 用量可控的场景。我第一次用的时候直接跑了codex login就完成了全程不到一分钟。有一点要特别注意Codex 的模型配置很多样但并不是每个模型在你的账号体系下都可用。经常看到有人用 ChatGPT 账号登录却在配置里写了 API 专用模型名结果跑起来就报错。所以我的建议是先把codex exec --help和codex --version跑通再继续后面的操作。2.2 Obsidian 仓库结构设计Obsidian 本身不强制目录结构但为了配合 LLM Wiki 工作流我强烈建议从一开始就按“管道式目录”来设计仓库。我的主库结构大概是这样的10-inbox/收藏文章的原始落点所有通过剪藏插件保存的内容先进这里状态是未处理20-notes/由 Codex 生成的结构化主题卡片这是知识网的核心节点30-moc/Map of Content也就是总索引页负责把同一主题的卡片聚合在一起90-archive/已经处理完的原始文章归档在这里作为溯源材料。这个结构的核心思路是把“原始输入”“加工产物”“最终索引”三级分开避免 Codex 在处理过程中误改原始文章。原始文章的完整性和可追溯性一旦被破坏知识库的可信度就没了。我自己吃亏过早期让 LLM 直接在原文里做修改结果摘要写错了源头后来无论做得多细都不敢再动了。2.3 双工具的目录与命名约定Codex 只认文件和路径所以命名规则必须机器可读。我定了几条硬规则所有 Markdown 文件名用短横线连接例如agent-memory-notes.md避免空格和中文特殊字符每篇笔记必须有 YAML frontmatter字段统一用英文 key包含title、source、author、tags、status、related六个字段status字段标识笔记状态只有pending状态的笔记才被 Codex 当作待处理对象。这样的约定让 Codex 的身份判断特别简单它只需要扫描status: pending的文件处理完成后把状态改成processed即可完全不需要记忆上次跑到哪里。还有一个细节是 Obsidian 的双链语法。Codex 在生成关联时必须严格使用[[文件名]]格式而且文件名要和实际创建的 .md 文件名完全一致。很多人最终生成了一堆“看起来很像但就是打不开”的链接几乎都是因为文件名里多了空格或者生成了别名。我在后续给 Codex 的提示词里会反复强调这条规则。3. 实战把收藏文章变成可生长的 Wiki环境就绪之后就是整个流程最核心的部分。这一章我会完整拆解我是如何把 200 多篇收藏文章变成一张互链 Wiki 的。整个过程分为四步批量扫描和信息抽取、生成主题卡片与双链、图谱检验、增量维护。每一步我都写了可以直接拿来改用的 prompt 或规则。3.1 第一步收件箱与信息抽取先用 Obsidian 官方的 Web Clipper 插件把网页文章保存成 Markdown放进10-inbox/。这里有个小技巧剪藏时尽量保留原文 URL把它写在 frontmatter 的source字段里这样后面追溯来源方便Codex 在摘要时也多一个可参考的上下文。然后就是批量抽取。我用的是 Codex 的 in-repo workflows 机制在仓库根目录建一个workflows/文件夹里面放一个自然语言描述的流程文件Codex 会按照这个工作流规则自动执行。我的llm-wiki-processing.md大概长这样任务: LLM Wiki 批量处理 行为约束: - 只处理 10-inbox/ 下 status 为 pending 的文件 - 不允许修改原始文章内容只允许接收它的信息 - 所有输出文件一律写入 20-notes/ 处理步骤: 1. 阅读每篇文章提取核心观点、关键术语、作者立场 2. 为每篇文章生成一张主题卡片包含: - 一句话 TL;DR - 3-5 个关键概念 - 与已有 20-notes/ 笔记的潜在关联 - 原始来源链接 3. 更新 30-moc/ 下的总索引把新卡片挂到对应主题下 4. 将源文件的 status 改为 processed这个文件说白了就是“工作说明书”Codex 拿到之后会自行拆解执行。我第一次跑的时候选了 20 篇作为实验样本大概用了三分钟就完成了全部抽取和索引更新。它生成的卡片会放在20-notes/下结构清晰摘要质量比我预想的高很多。核心经验是任务描述越具体行为约束越明确产出越稳定。尤其是“只允许新建文件不允许改原文”这种约束必须从一开始就写明。3.2 第二步生成主题卡片和双向链接这一步是“织网”的关键。Codex 在抽取完信息后会在每张卡片的 frontmatter 里写related字段例如另一篇已经存在且主题相关的笔记[[2025-10-llm-agent-memory]]。同时在正文底部它也会生成一个“相关笔记”区块用 Obsidian 双链指向其他卡片。这背后的逻辑是单篇笔记的价值是线性的多篇互链笔记的价值是几何级的。比如我原来收藏过一篇讲 RAG 评估指标的文章也收藏过一篇讲 Agent 长期记忆的文章两篇文章没有任何交集。但 Codex 在抽取“知识图谱”时识别出了它们之间的关联RAG 评估里必须有“记忆准确率”这个维度而 Agent 记忆系统的设计也要考虑评估方法。于是它自动建了一条链接把两篇笔记连起来还生成了一段简短的关联说明。这个效果是手工整理很难达到的。为了减少幻觉导致错误链接我给 Codex 定了“三跳原则”的处理限令只有在概念上确实存在直接关联时才建立双向链接禁止为了凑链接而强行关联无关内容。宁可网络稀疏一点也不要因为错误链接把整个图谱污染了。这一步踩坑的代价很高因为一旦错误链接扩散到被后续任务当上下文整个库的质量就会持续恶化。3.3 第三步用图谱与索引检查“网”的成色写完一批卡片后打开 Obsidian 的关系图谱视图你会看到一张正在成形的网。这时候不要急着高兴要做一次人工抽检。我会先按目录路径给图谱染色20-notes/是主节点10-inbox/是外围原料30-moc/是聚合点。正常状态应该是每个主题形成一个小簇多个簇通过 MOC 页面汇合整个图谱是一张连通图而不是一堆互不相干的散点。如果你发现某些笔记变成了“孤岛”说明 Codex 没有为它们找到任何关联。这里有个常用的补救办法用 Dataview 插件做一次反向链接缺失检测生成一份“孤立笔记清单”然后把这些笔记的名字当作上下文重新丢给 Codex让它专门为这些孤儿笔记寻找潜在关联。我通常会手动判断一下这些建议是否合理再决定是否建立链接。Dataview 的检测查询不需要写得很复杂大概像下面这样TABLE file.name, status FROM 20-notes WHERE length(file.inlinks) 0它会把没有任何入链的笔记全部列出来。把这些列出来的笔记当作“待救援对象”处理知识网的质量就能逐步补齐。这个步骤看起来额外花时间但它恰恰是 LLM Wiki 工作流里最能体现“人机协作”价值的地方——机器负责规模和效率人负责判断和校准。3.4 第四步增量维护和归档LLM Wiki 的关键不是一次性整理完而是可持续运转。我的做法是把 Codex 的 workflow 做成了“两次运行机制”新收藏文章进来后先把它扔进10-inbox/然后跑一次增量任务Codex 只会处理status: pending的文件它处理完后把原始文章移到90-archive/保留备份。这样整个库始终在动态变化但不会出现新旧内容互相干扰的情况。增量维护中还有一个小任务很重要定期检查断链。Markdown 里最常见的断链原因是文件名被修改但链接没有同步更新。Obsidian 自身在改名时会自动更新出链但 Codex 生成的链接可能在改名后变成死链。我每个月会让 Codex 扫一遍所有笔记找出哪些[[双链]]的目标文件不存在然后生成一个修复清单我确认后再统一改。这个维护节奏跑下来我的知识库不仅没有随着时间膨胀而混乱反而越来越接近一张真正可用的网。4. 避坑实录Codex Obsidian 高频报错与排查这部分是我实际折腾过程中的翻车记录也是最有参考价值的内容。Codex 确实强大但配置和使用过程中的报错多到让人崩溃。我把遇到的高频问题整理成一个速查表每个问题都附上了我当时是怎么定位和解决的。报错信息出现原因处理方式the gpt-5.6-sol model is not supported when using codex with a chatgpt account用 ChatGPT 账号登录但配置里填写了当前账号不支持模型换成账号可用模型或把模型来源切换到 API providererror running remote compact task: codex ran out of room in the models context任务上下文窗口被撑爆多发生在批量处理超大文件时把任务拆小控制单次处理文件数降低输入文本长度local proxy failed while handling codex endpoint /responses本地请求转发服务没有正常监听通常是本地服务崩溃或配置变更导致的检查本地转发服务的端口与配置文件是否一致重启本地服务即可恢复若未配置此类服务直接卸载对应扩展即可Obsidian 图谱里链接显示为灰色点不进去链接目标文件名与笔记实际文件名不匹配按实际文件名修正双链统一用短横线命名去除空格下面我挑几个展开细说。4.1 认证与模型选择报错the gpt-5.6-sol model is not supported when using codex with a chatgpt account这个报错几乎是新手最容易撞上的墙。原因是 Codex CLI 允许你在配置里手动指定模型但不同身份能用的模型列表不一样ChatGPT 登录账号能用的模型和 API 账号能用的模型并不完全相同。我踩坑之后摸索出的处理方式是先运行codex models查看当前身份下可用模型清单然后把.codex/config.toml里的model字段改成清单里存在的模型。如果是 API 身份还要检查OPENAI_API_KEY环境变量有没有正确设置。这个问题本质上是配置和身份不匹配调哪里都不如先查身份。4.2 上下文溢出与批量任务崩溃另一个高频问题运行大批量任务时提示codex ran out of room in the models context。我第一次处理一批长文章时没有做前置压缩直接把整个文件丢进去结果上下文直接撑爆。后来我的处理策略是在任务描述里明确要求 Codex 先读文件的标题、摘要、小标题再决定是否进入正文细节对于特别长的文章先让 Codex 生成一个骨架再分段落补全。这样单次任务消耗的上下文能下降一半以上。如果你要在 Codex 的一个工作流里同时处理 10 篇以上长文强烈建议分成两批来跑宁可多花一次调用也不要一次性压垮上下文。代码写多了不重要上下文管理才是 Codex 批量任务的核心技能。4.3 本地网络与扩展服务报错使用过程中还会遇到local proxy failed while handling codex endpoint /responses这类报错。它的意思是 Codex 在请求响应时碰到了一个本地转发服务的连接异常。如果你在电脑上配置了本地请求转发工具或相关浏览器扩展这类问题通常和本地服务的存活状态有关服务没有正常启动、进程被杀、端口被占用都可能触发这个报错。排查方法很简单检查本机对应服务的运行状态如果没启动就启动一下如果配置变了就重启让它重新加载。假如你根本没有配置过任何本地转发服务却依然看到这个报错那就把近期安装过的相关配套插件或扩展卸载再用官方默认配置跑一次。这类报错的大方向就是“看本地服务、看端口、看配置”不复杂但容易让人误以为问题出在 Codex 本身。4.4 Obsidian 侧的显示问题好记性不如烂笔头但 Obsidian 也有自己的小脾气。最常见的问题是 Codex 生成的卡片里有[[]]链接图谱里却显示为灰色点不进去。基本原因都是文件名不匹配Codex 写链接时用了[[Agent Memory 笔记]]但实际文件名是agent-memory-notes.md。解决办法有两个方向一个是严格统一双链里的文字与实际文件名完全相同另一个是给笔记设置 alias允许链接显示别名而指向真实文件。我个人更偏向前者因为 alias 会让索引变得混乱而且 Codex 在后续读取时也会被 alias 干扰。还有一个 Obsidian 索引延迟的问题。当 Codex 在外部批量创建了大量新文件时Obsidian 需要一点时间重新扫描仓库图谱可能不会立刻更新。如果你发现新生成的卡片迟迟不出现别急稍等几秒或者手动重启 Obsidian 强制刷新索引。这个不算 bug只是同步机制。5. LLM Wiki 的边界与我的落地建议很多刚接触 LLM Wiki 的人都会问同一个问题这套方案能完全代替我手动整理笔记吗我的答案是不能也不应该。它真正擅长的事情是把“收藏-理解-关联-更新”这个循环里的机械劳动接管过去但它仍然需要你提供判断标准和验收视角。工具可以织网但“网”放在哪里、要捕捉什么知识始终是人的事。5.1 适合什么、不适合什么如果让我划一条边界LLM Wiki 最适合的内容是有明确概念结构的知识型文章论文、技术博客、行业报告、讲解底层原理的长文。这类内容信息密度高概念之间的关系清晰LLM 在抽取、摘要和链接时表现非常稳定。反之不适合的是碎片化信息和强个人隐私内容聊天截图、购物记录、日记式的琐碎记录。这类内容要么结构化程度太低不适合自动提炼要么不适合交给云端模型处理安全性上就得先画红线。还有一类内容要特别小心观点极其微妙、必须在特定语境下才能准确理解的文章。LLM 在压缩摘要时容易丢失语境导致摘要偏差甚至完全失真。比如一些偏哲学、偏文学的评论我的建议是不要纳入自动处理流程宁可保留原文也不要让摘要破坏了原意。5.2 给新手的落地路线如果你现在也有一堆收藏文章想处理我建议不要一上来就把整套 workflow 塞进去而是按最小闭环的方式先跑通一遍。具体来说分三批走第一批只处理 5-10 篇文章全部人工审查 Codex 生成的卡片质量、链接准确性、frontmatter 是否符合预期第二批扩大到 30 篇左右同时观察它的增量维护有没有把旧卡片搞乱第三批再全量处理。我自己的教训是跳过了第一步直接全量处理导致一次上下文溢出整体重跑成本很高。另外强烈建议给 Obsidian 装上 Git 插件让每一次 Codex 的批量改动都变成一个可回滚的 commit。这一步非常重要因为 Codex 生成内容大概率靠谱但“大概率”不等于“百分百”一旦出现批量错误链接或者摘要偏差git 回滚能让你在几分钟内恢复原状。有了这层保障你才敢放心把整理权交给智能体。还有一个额外提醒控制使用频率和成本。Codex 是按 token 消耗来计算的批量处理长文有一定的开销。所以我现在的策略不是每天都跑而是攒到一批新文章后再集中处理。这样既保证了知识库的更新节奏也能让每次调用的时长和成本都更加可控。从实际操作的角度我觉得整套 LLM Wiki 的价值不光是“终于把收藏夹吃灰问题解决了”更深层的是它改变了我跟知识的关系。以前我收藏一篇文章潜意识里是“以后可能用到”这其实是一种逃避。现在我会想“这篇东西放进我的知识网之后会跟哪几张卡片产生连接”。这个思维转变比任何工具都更重要。如果你也囤积了大量文章我建议你先别急着全量跑拿 10 篇收藏搭好10-inbox、20-notes、30-moc三个目录写好一个最基础的 Codex workflow跑通一遍再谈扩展。这十几分钟的投入可能比你过去一整年囤文章都更有价值。 在信息爆炸的今天我收藏夹里的文章已经超过一千篇但真正能被我想起来、用上的可能不到十分之一。直到我看了 Andrej Karpathy 关于 LLM Wiki 的一系列分享才突然意识到问题不在“收藏量不够”而在“收藏之后没有人去整理、连接、更新”。他用一个很朴素的想法点醒了我如果 LLM 不是一个“问答盒子”而是一个能维护知识库的图书管理员那我的本地笔记库完全可以变成一张越用越密的网。于是我把 Obsidian 里的收藏文章作为原材料用 Codex 这个能读写本地文件、批量执行任务的智能体来跑这套“LLM Wiki 工作流”。这篇文章就是我完整复现这套流程的记录包含目录设计、Codex 配置、批量抽取、双向链接生成、图谱检验和大量报错排查经验希望能让和我一样在笔记坑里挣扎的人少走弯路。1. 先理解 LLM Wiki为什么“收藏”不等于“知识”很多人对 Karpathy 提出 LLM Wiki 的理解停留在“用 LLM 自动生成笔记”这个层面这其实低估了这件事。他想解决的是个人知识管理中最核心的一个矛盾传统 Wiki 需要人工维护链接断了没人管、目录过期了没人改、新知识和旧知识之间没有关联维护成本高到根本不可持续。而 LLM 的加入让知识库第一次有了一个“专职编辑”它可以读完全部笔记、理解条目之间的关系、自动补链接、生成索引甚至在你导入新文章时主动把它挂到已有的知识网络上。1.1 收藏夹的困境与 Karpathy 的思路我先说个真实感受。早期我用文件夹管理收藏文章按“产品、技术、AI、写作”分门别类。表面上看很整齐实际上每篇文章都是孤岛一篇关于 Agent Memory 的文章被丢进“AI”文件夹后再也没有出现过一篇讨论写作框架的文章和另一篇讲卡片盒笔记法的文章明明高度相关却因为路径不同永远碰不到面。文件夹是树状结构它天然不适合表达“一篇笔记属于多个主题”这种网状关系。Obsidian 的双向链接和关系图谱解决了“网状表达”的问题但是新的瓶颈又出现了创建链接、维护索引、补充摘要这些全是体力活纯靠手工做的成本极高。Karpathy 的思路恰好切在这个痛点上。他提出知识库不应该是一堆被动等待检索的文本而应该是一个可以不断被自动维护的结构化“Wiki”LLM 在这个 Wiki 里扮演的角色不是搜索框而是编辑和维护者它读入一篇新文章提炼要点找出和现有条目的关联写入新的页面更新总索引。这套循环跑起来之后知识管理的单位就从“单篇文章”变成了“整个网络”。1.2 为什么这套工作流值得用 Codex 而不是普通插件在选工具的时候自然要面对一个选择现在 Obsidian 生态里也有很多 AI 插件为什么非要用 Codex 构建工作流我的判断标准只有一条——谁才能真正“操作”整个库。Obsidian 里的绝大多数 AI 插件本质上是“问答助手”你问一句它答一句偶尔帮你生成一段文字但它没有能力批量扫描 200 篇旧笔记并主动重组文件链接。Codex 是一个能访问本地文件系统、能执行命令、能写代码、能一次性完成多步骤任务的智能体它更接近一个“代理”而不是聊天窗口。还有一个很现实的原因Codex 对纯 Markdown 文本的处理能力非常强而 Obsidian 的数据恰好就是一堆 Markdown 文件。这意味着 Codex 可以直接打开目录、遍历文件、修改 frontmatter、生成新的 .md 文件整个流程清晰可控。作为对比我也试过用思源笔记来搭这套东西思源的块级引用和双链能力其实很强但它的数据底层是 JSON 结构Codex 直接操作文件的成本明显更高远不如 Obsidian 这种“每个笔记一个文件”的形态来得顺手。所以这套方案的最终形态就是纯文本存储 智能体批量维护 图谱可视化。2. 动手前的基础Codex CLI 与 Obsidian 的环境准备在开始“织网”之前得先把两个工具打磨到能顺畅协作的状态。Codex 负责跑批量任务Obsidian 负责展示和维护知识库它们之间没有官方插件靠的就是文件目录和格式约定。这套约定一旦定好后面所有流程都能自动化。2.1 Codex CLI 安装与登录如果你还没装 Codex可以先通过官方渠道安装。macOS 上最简单的是直接用 Homebrew 安装命令就一行brew install codex如果你习惯用 npm也可以全局安装官方发布的 CLI 包npm install -g openai/codex装完之后需要登录认证。Codex 支持两种身份方式一种是直接用 ChatGPT 账号授权运行codex login后会在浏览器里打开授权页面这种方式适合个人轻度使用另一种是使用 API Key 方式在.codex/config.toml里配置模型和访问地址适合需要批量执行、对 token 用量可控的场景。我第一次用的时候直接跑了codex login就完成了全程不到一分钟。有一点要特别注意Codex 的模型配置很多样但并不是每个模型在你的账号体系下都可用。经常看到有人用 ChatGPT 账号登录却在配置里写了 API 专用模型名结果跑起来就报错。所以我的建议是先把codex exec --help和codex --version跑通再继续后面的操作。2.2 Obsidian 仓库结构设计Obsidian 本身不强制目录结构但为了配合 LLM Wiki 工作流我强烈建议从一开始就按“管道式目录”来设计仓库。我的主库结构大概是这样的10-inbox/收藏文章的原始落点所有通过剪藏插件保存的内容先进这里状态是未处理20-notes/由 Codex 生成的结构化主题卡片这是知识网的核心节点30-moc/Map of Content也就是总索引页负责把同一主题的卡片聚合在一起90-archive/已经处理完的原始文章归档在这里作为溯源材料。这个结构的核心思路是把“原始输入”“加工产物”“最终索引”三级分开避免 Codex 在处理过程中误改原始文章。原始文章的完整性和可追溯性一旦被破坏知识库的可信度就没了。我自己吃亏过早期让 LLM 直接在原文里做修改结果摘要写错了源头后来无论做得多细都不敢再动了。2.3 双工具的目录与命名约定Codex 只认文件和路径所以命名规则必须机器可读。我定了几条硬规则所有 Markdown 文件名用短横线连接例如agent-memory-notes.md避免空格和中文特殊字符每篇笔记必须有 YAML frontmatter字段统一用英文 key包含title、source、author、tags、status、related六个字段status字段标识笔记状态只有pending状态的笔记才被 Codex 当作待处理对象。这样的约定让 Codex 的身份判断特别简单它只需要扫描status: pending的文件处理完成后把状态改成processed即可完全不需要记忆上次跑到哪里。还有一个细节是 Obsidian 的双链语法。Codex 在生成关联时必须严格使用[[文件名]]格式而且文件名要和实际创建的 .md 文件名完全一致。很多人最终生成了一堆“看起来很像但就是打不开”的链接几乎都是因为文件名里多了空格或者生成了别名。我在后续给 Codex 的提示词里会反复强调这条规则。3. 实战把收藏文章变成可生长的 Wiki环境就绪之后就是整个流程最核心的部分。这一章我会完整拆解我是如何把 200 多篇收藏文章变成一张互链 Wiki 的。整个过程分为四步批量扫描和信息抽取、生成主题卡片与双链、图谱检验、增量维护。每一步我都写了可以直接拿来改用的 prompt 或规则。3.1 第一步收件箱与信息抽取先用 Obsidian 官方的 Web Clipper 插件把网页文章保存成 Markdown放进10-inbox/。这里有个小技巧剪藏时尽量保留原文 URL把它写在 frontmatter 的source字段里这样后面追溯来源方便Codex 在摘要时也多一个可参考的上下文。然后就是批量抽取。我用的是 Codex 的 in-repo workflows 机制在仓库根目录建一个workflows/文件夹里面放一个自然语言描述的流程文件Codex 会按照这个工作流规则自动执行。我的llm-wiki-processing.md大概长这样任务: LLM Wiki 批量处理 行为约束: - 只处理 10-inbox/ 下 status 为 pending 的文件 - 不允许修改原始文章内容只允许接收它的信息 - 所有输出文件一律写入 20-notes/ 处理步骤: 1. 阅读每篇文章提取核心观点、关键术语、作者立场 2. 为每篇文章生成一张主题卡片包含: - 一句话 TL;DR - 3-5 个关键概念 - 与已有 20-notes/ 笔记的潜在关联 - 原始来源链接 3. 更新 30-moc/ 下的总索引把新卡片挂到对应主题下 4. 将源文件的 status 改为 processed这个文件说白了就是“工作说明书”Codex 拿到之后会自行拆解执行。我第一次跑的时候选了 20 篇作为实验样本大概用了三分钟就完成了全部抽取和索引更新。它生成的卡片会放在20-notes/下结构清晰摘要质量比我预想的高很多。核心经验是任务描述越具体行为约束越明确产出越稳定。尤其是“只允许新建文件不允许改原文”这种约束必须从一开始就写明。3.2 第二步生成主题卡片和双向链接这一步是“织网”的关键。Codex 在抽取完信息后会在每张卡片的 frontmatter 里写related字段例如另一篇已经存在且主题相关的笔记[[2025-10-llm-agent-memory]]。同时在正文底部它也会生成一个“相关笔记”区块用 Obsidian 双链指向其他卡片。这背后的逻辑是单篇笔记的价值是线性的多篇互链笔记的价值是几何级的。比如我原来收藏过一篇讲 RAG 评估指标的文章也收藏过一篇讲 Agent 长期记忆的文章两篇文章没有任何交集。但 Codex 在抽取“知识图谱”时识别出了它们之间的关联RAG 评估里必须有“记忆准确率”这个维度而 Agent 记忆系统的设计也要考虑评估方法。于是它自动建了一条链接把两篇笔记连起来还生成了一段简短的关联说明。这个效果是手工整理很难达到的。为了减少幻觉导致错误链接我给 Codex 定了“三跳原则”的处理限令只有在概念上确实存在直接关联时才建立双向链接禁止为了凑链接而强行关联无关内容。宁可网络稀疏一点也不要因为错误链接把整个图谱污染了。这一步踩坑的代价很高因为一旦错误链接扩散到被后续任务当上下文整个库的质量就会持续恶化。3.3 第三步用图谱与索引检查“网”的成色写完一批卡片后打开 Obsidian 的关系图谱视图你会看到一张正在成形的网。这时候不要急着高兴要做一次人工抽检。我会先按目录路径给图谱染色20-notes/是主节点10-inbox/是外围原料30-moc/是聚合点。正常状态应该是每个主题形成一个小簇多个簇通过 MOC 页面汇合整个图谱是一张连通图而不是一堆互不相干的散点。如果你发现某些笔记变成了“孤岛”说明 Codex 没有为它们找到任何关联。这里有个常用的补救办法用 Dataview 插件做一次反向链接缺失检测生成一份“孤立笔记清单”然后把这些笔记的名字当作上下文重新丢给 Codex让它专门为这些孤儿笔记寻找潜在关联。我通常会手动判断一下这些建议是否合理再决定是否建立链接。Dataview 的检测查询不需要写得很复杂大概像下面这样TABLE file.name, status FROM 20-notes WHERE length(file.inlinks) 0它会把没有任何入链的笔记全部列出来。把这些列出来的笔记当作“待救援对象”处理知识网的质量就能逐步补齐。这个步骤看起来额外花时间但它恰恰是 LLM Wiki 工作流里最能体现“人机协作”价值的地方——机器负责规模和效率人负责判断和校准。3.4 第四步增量维护和归档LLM Wiki 的关键不是一次性整理完而是可持续运转。我的做法是把 Codex 的 workflow 做成了“两次运行机制”新收藏文章进来后先把它扔进10-inbox/然后跑一次增量任务Codex 只会处理status: pending的文件它处理完后把原始文章移到90-archive/保留备份。这样整个库始终在动态变化但不会出现新旧内容互相干扰的情况。增量维护中还有一个小任务很重要定期检查断链。Markdown 里最常见的断链原因是文件名被修改但链接没有同步更新。Obsidian 自身在改名时会自动更新出链但 Codex 生成的链接可能在改名后变成死链。我每个月会让 Codex 扫一遍所有笔记找出哪些[[双链]]的目标文件不存在然后生成一个修复清单我确认后再统一改。这个维护节奏跑下来我的知识库不仅没有随着时间膨胀而混乱反而越来越接近一张真正可用的网。4. 避坑实录Codex Obsidian 高频报错与排查这部分是我实际折腾过程中的翻车记录也是最有参考价值的内容。Codex 确实强大但配置和使用过程中的报错多到让人崩溃。我把遇到的高频问题整理成一个速查表每个问题都附上了我当时是怎么定位和解决的。报错信息出现原因处理方式the gpt-5.6-sol model is not supported when using codex with a chatgpt account用 ChatGPT 账号登录但配置里填写了当前账号不支持模型换成账号可用模型或把模型来源切换到 API providererror running remote compact task: codex ran out of room in the models context任务上下文窗口被撑爆多发生在批量处理超大文件时把任务拆小控制单次处理文件数降低输入文本长度local proxy failed while handling codex endpoint /responses本地请求转发服务没有正常监听通常是本地服务崩溃或配置变更导致的检查本地转发服务的端口与配置文件是否一致重启本地服务即可恢复若未配置此类服务直接卸载对应扩展即可Obsidian 图谱里链接显示为灰色点不进去链接目标文件名与笔记实际文件名不匹配按实际文件名修正双链统一用短横线命名去除空格下面我挑几个展开细说。4.1 认证与模型选择报错the gpt-5.6-sol model is not supported when using codex with a chatgpt account这个报错几乎是新手最容易撞上的墙。原因是 Codex CLI 允许你在配置里手动指定模型但不同身份能用的模型列表不一样ChatGPT 登录账号能用的模型和 API 账号能用的模型并不完全相同。我踩坑之后摸索出的处理方式是先运行codex models查看当前身份下可用模型清单然后把.codex/config.toml里的model字段改成清单里存在的模型。如果是 API 身份还要检查OPENAI_API_KEY环境变量有没有正确设置。这个问题本质上是配置和身份不匹配调哪里都不如先查身份。4.2 上下文溢出与批量任务崩溃另一个高频问题运行大批量任务时提示codex ran out of room in the models context。我第一次处理一批长文章时没有做前置压缩直接把整个文件丢进去结果上下文直接撑爆。后来我的处理策略是在任务描述里明确要求 Codex 先读文件的标题、摘要、小标题再决定是否进入正文细节对于特别长的文章先让 Codex 生成一个骨架再分段落补全。这样单次任务消耗的上下文能下降一半以上。如果你要在 Codex 的一个工作流里同时处理 10 篇以上长文强烈建议分成两批来跑宁可多花一次调用也不要一次性压垮上下文。代码写多了不重要上下文管理才是 Codex 批量任务的核心技能。4.3 本地网络与扩展服务报错使用过程中还会遇到local proxy failed while handling codex endpoint /responses这类报错。它的意思是 Codex 在请求响应时碰到了一个本地转发服务的连接异常。如果你在电脑上配置了本地请求转发工具或相关浏览器扩展这类问题通常和本地服务的存活状态有关服务没有正常启动、进程被杀、端口被占用都可能触发这个报错。排查方法很简单检查本机对应服务的运行状态如果没启动就启动一下如果配置变了就重启让它重新加载。假如你根本没有配置过任何本地转发服务却依然看到这个报错那就把近期安装过的相关配套插件或扩展卸载再用官方默认配置跑一次。这类报错的大方向就是“看本地服务、看端口、看配置”不复杂但容易让人误以为问题出在 Codex 本身。4.4 Obsidian 侧的显示问题好记性不如烂笔头但 Obsidian 也有自己的小脾气。最常见的问题是 Codex 生成的卡片里有[[]]链接图谱里却显示为灰色点不进去。基本原因都是文件名不匹配Codex 写链接时用了[[Agent Memory 笔记]]但实际文件名是agent-memory-notes.md。解决办法有两个方向一个是严格统一双链里的文字与实际文件名完全相同另一个是给笔记设置 alias允许链接显示别名而指向真实文件。我个人更偏向前者因为 alias 会让索引变得混乱而且 Codex 在后续读取时也会被 alias 干扰。还有一个 Obsidian 索引延迟的问题。当 Codex 在外部批量创建了大量新文件时Obsidian 需要一点时间重新扫描仓库图谱可能不会立刻更新。如果你发现新生成的卡片迟迟不出现别急稍等几秒或者手动重启 Obsidian 强制刷新索引。这个不算 bug只是同步机制。5. LLM Wiki 的边界与我的落地建议很多刚接触 LLM Wiki 的人都会问同一个问题这套方案能完全代替我手动整理笔记吗我的答案是不能也不应该。它真正擅长的事情是把“收藏-理解-关联-更新”这个循环里的机械劳动接管过去但它仍然需要你提供判断标准和验收视角。工具可以织网但“网”放在哪里、要捕捉什么知识始终是人的事。5.1 适合什么、不适合什么如果让我划一条边界LLM Wiki 最适合的内容是有明确概念结构的知识型文章论文、技术博客、行业报告、讲解底层原理的长文。这类内容信息密度高概念之间的关系清晰LLM 在抽取、摘要和链接时表现非常稳定。反之不适合的是碎片化信息和强个人隐私内容聊天截图、购物记录、日记式的琐碎记录。这类内容要么结构化程度太低不适合自动提炼要么不适合交给云端模型处理安全性上就得先画红线。还有一类内容要特别小心观点极其微妙、必须在特定语境下才能准确理解的文章。LLM 在压缩摘要时容易丢失语境导致摘要偏差甚至完全失真。比如一些偏哲学、偏文学的评论我的建议是不要纳入自动处理流程宁可保留原文也不要让摘要破坏了原意。5.2 给新手的落地路线如果你现在也有一堆收藏文章想处理我建议不要一上来就把整套 workflow 塞进去而是按最小闭环的方式先跑通一遍。具体来说分三批走第一批只处理 5-10 篇文章全部人工审查 Codex 生成的卡片质量、链接准确性、frontmatter 是否符合预期第二批扩大到 30 篇左右同时观察它的增量维护有没有把旧卡片搞乱第三批再全量处理。我自己的教训是跳过了第一步直接全量处理导致一次上下文溢出整体重跑成本很高。另外强烈建议给 Obsidian 装上 Git 插件让每一次 Codex 的批量改动都变成一个可回滚的 commit。这一步非常重要因为 Codex 生成内容大概率靠谱但“大概率”不等于“百分百”一旦出现批量错误链接或者摘要偏差git 回滚能让你在几分钟内恢复原状。有了这层保障你才敢放心把整理权交给智能体。还有一个额外提醒控制使用频率和成本。Codex 是按 token 消耗来计算的批量处理长文有一定的开销。所以我现在的策略不是每天都跑而是攒到一批新文章后再集中处理。这样既保证了知识库的更新节奏也能让每次调用的时长和成本都更加可控。从实际操作的角度我觉得整套 LLM Wiki 的价值不光是“终于把收藏夹吃灰问题解决了”更深层的是它改变了我跟知识的关系。以前我收藏一篇文章潜意识里是“以后可能用到”这其实是一种逃避。现在我会想“这篇东西放进我的知识网之后会跟哪几张卡片产生连接”。这个思维转变比任何工具都更重要。如果你也囤积了大量文章我建议你先别急着全量跑拿 10 篇收藏搭好10-inbox、20-notes、30-moc三个目录写好一个最基础的 Codex workflow跑通一遍再谈扩展。这十几分钟的投入可能比你过去一整年囤文章都更有价值。