1. 为什么个人 LLM 工作台这件事最后都绕回了 Obsidian先说一个我观察了很久的现象身边折腾大模型的人几乎都经历过同一个循环——一开始用聊天网页觉得够用然后开始攒提示词散落在备忘录、Notion、微信收藏里再然后发现每次对话都是失忆的昨天喂给模型的背景资料今天还得重新贴一遍最后忍无可忍开始找能长期存东西、又能被模型读取的容器。这个容器试来试去很多人最后停在了 Obsidian 上。注意我的措辞——是停在了不是一开始就选了。这中间有个很关键的认知转变大多数人最初把 Obsidian 当成一个更好看的笔记软件用了一阵子才发现它真正的价值不在记笔记而在于它是一个纯本地、纯文本、结构开放的文件系统。而这三条恰好是大模型工作流最需要的地基。我先把结论摆出来免得你看到一半才发现方向不对Obsidian 之所以能成为个人 LLM 工作台也就是标题里说的 harness中文可以理解成驾驭层承载层的底座核心就三点——Markdown 是模型最友好的输入格式、本地文件夹是模型最容易读写的存储、双向链接和标签是模型最容易理解的结构化上下文。这三点单独看都不稀奇但能同时满足、还免费、还跨平台的选择其实不多。但标题后半句同样重要什么时候你不该选它。我见过太多人一上来就 All in Obsidian结果发现自己根本不需要本地文件、不需要长期积累、只是想让模型帮忙改改文案那这套东西对ta来说就是纯负担。所以这篇我会把该选和不该选都讲透而不是无脑吹。这篇文章适合三类人看一是已经在用大模型、但资料管理一团乱的人二是听说过 Obsidian 但不知道它跟 LLM 有什么关系的人三是已经搭了一半工作流、卡在某个环节想找参考的人。不管你是哪类我都会尽量把为什么这么做讲清楚而不是只丢一堆插件名字给你。2. 拆开看Obsidian 到底给 LLM 工作流提供了什么2.1 Markdown 为什么是模型最舒服的母语大模型训练语料里Markdown 的占比高得惊人。GitHub 上的 README、技术文档、论坛帖子、Stack Overflow 的回答大量都是 Markdown 格式。这意味着模型对 Markdown 的语法结构——标题层级、列表、代码块、引用——有天然的语感。这件事的实际影响比你想的大。你给模型一段纯文本它得自己猜哪里是标题、哪里是重点你给它一段结构清晰的 Markdown它一眼就能看出层级关系。我做过对比测试同样一份产品需求文档用纯文本喂给模型让它总结和用带##、-、**加粗**的 Markdown 喂后者的总结质量明显更稳尤其是提取三级标题下的要点这类任务Markdown 版本几乎不会出错。Obsidian 的底层存储就是纯 Markdown 文件你写的每一个字、每一个标题落盘就是.md。这意味着你的笔记天然就是模型的优质输入不需要任何转换。这一点是很多富文本笔记软件做不到的——它们的数据存在数据库里导出成 Markdown 往往格式会乱链接会丢图片路径会断。提示如果你现在用的笔记软件导出 Markdown 后需要大量手动修复那它就不适合做 LLM 工作台的底座。这是第一个筛选标准。2.2 本地文件夹模型读写最省事的存储形态第二个关键点是本地。Obsidian 的库vault本质上就是一个文件夹里面全是.md文件外加一个.obsidian配置目录。这个结构简单到什么程度你用命令行ls就能看到全部内容用任何文本编辑器都能打开用脚本能批量处理。为什么这对 LLM 工作流重要因为现在主流的模型调用方式无论是通过 API 还是本地部署最终都要落到读文件、写文件上。你的工作流如果是让模型读我的笔记然后生成新内容存回去那文件系统就是最直接的接口。Obsidian 的库就是一个标准文件夹模型生成的 Markdown 直接写进去Obsidian 立刻就能识别、渲染、建立链接。我自己的做法是把 Obsidian 库放在一个固定路径然后用脚本或工具让模型能访问这个路径。模型读的时候直接读.md写的时候直接写.md中间没有任何格式转换的损耗。这种零转换的体验用过就回不去了。对比一下云端笔记数据在别人的服务器上你要么用它的 API受限于它的能力要么导出有延迟、格式可能变。本地文件夹没有这些问题你对数据的控制是完整的。2.3 双向链接与标签给模型一份上下文地图这是 Obsidian 最被低估、但对 LLM 工作流最有价值的一点。双向链接[[笔记名]]和标签#标签在 Obsidian 里是显式写在 Markdown 里的。也就是说你的笔记之间的关联关系是明文存在文件里的不是藏在某个数据库的关联表里。模型读你的笔记时能直接看到这篇笔记引用了哪几篇这篇笔记属于哪个主题。这为什么重要因为大模型最大的短板之一就是不知道上下文边界。你问它一个问题它不知道你之前写过什么、相关的是什么。但如果你的笔记里有清晰的双向链接和标签你就可以让模型顺着链接去读相关笔记把上下文喂给它。这相当于给模型画了一张知识地图它不用猜照着走就行。举个具体场景我有一篇笔记叫[[RAG 检索增强]]里面链接了[[向量数据库选型]]和[[文本分块策略]]。当我让模型基于我的笔记回答我的 RAG 方案是怎么设计的时它可以先读主笔记再顺着链接读那两篇拼出一个完整的答案。如果这些笔记是散落的纯文本模型根本不知道它们相关。标签同理。#项目/进行中、#领域/前端这种层级标签等于给模型提供了分类维度。你可以让模型只读所有#领域/前端的笔记它就能精准定位范围。2.4 一个容易被忽略的点Obsidian 的不打扰还有一点我想单独说因为它不太技术但很影响长期使用体验Obsidian 不逼你做任何事。它不逼你联网不逼你注册账号不逼你用它的云服务不逼你按它的模板走。你打开就是一个空白文件夹想怎么组织就怎么组织。这种低干预的特性对 LLM 工作流来说反而是优点——因为你的工作流会随着模型能力的变化不断调整如果底座软件本身很重、很固执你每次调整都要跟它对抗。我用过一些功能很全的笔记软件它们预设了太多结构结果我想让模型按自己的方式读写数据时处处受限。Obsidian 没有这个问题它就是个文件夹加一个编辑器剩下的全交给你。3. 把 Obsidian 接进 LLM 工作流几种真实可行的接法3.1 最轻的接法手动复制粘贴 结构化模板别笑这是最多人实际在用的方式而且如果配合好模板效率并不低。核心思路是在 Obsidian 里维护一份上下文笔记里面用固定结构写清楚你的背景、当前任务、约束条件。需要问模型时把这份笔记的内容复制过去。因为它是 Markdown模型理解起来很顺。我自己的模板大概长这样## 背景 - 我在做xxx - 已有资料[[相关笔记A]]、[[相关笔记B]] - 约束xxx ## 本次任务 - 目标xxx - 输出格式Markdown带三级标题 ## 参考资料 粘贴相关笔记内容这个模板的好处是模型每次都能拿到一致的上下文结构输出质量稳定。缺点是手动复制麻烦笔记一多就累。所以这只适合笔记量不大、或者刚开始搭建的人。注意这个阶段不要急着上自动化。先用手动方式跑通什么样的上下文结构能让模型输出最好这个经验后面自动化时会直接复用。3.2 中等接法用脚本让模型读写库文件当你笔记多起来手动复制就不现实了。这时候可以写个简单脚本让模型能直接读库里的文件、把结果写回去。思路很朴素Obsidian 库就是个文件夹脚本遍历文件夹读.md把内容拼成 prompt 发给模型拿到结果再写成新的.md。Python 的话核心逻辑就几行import os from pathlib import Path vault Path(/path/to/your/vault) def read_notes(tagNone): notes [] for md in vault.rglob(*.md): text md.read_text(encodingutf-8) if tag is None or tag in text: notes.append((md.name, text)) return notes def write_note(name, content): (vault / f{name}.md).write_text(content, encodingutf-8)这段代码没什么技术含量但它是整个工作流的地基。你可以基于它做各种事批量总结某个标签下的所有笔记、把模型生成的内容按主题存成新笔记、让模型检查笔记之间的链接是否合理。关键经验写回文件时一定要保留 Markdown 结构。模型有时候会输出带多余空行、或者把标题层级搞乱的内容写回前最好做一次简单校验。我一般会检查标题是否从##开始、代码块是否闭合、链接格式是否正确。3.3 进阶接法把 Obsidian 当记忆层模型当推理层这是我觉得最有价值的一种架构也是harness这个词真正的含义——Obsidian 负责长期记忆和结构化存储模型负责临时的推理和生成。具体怎么运作你的库里有大量笔记这些是记忆。当你要解决一个问题时不是把所有笔记都塞给模型那样 token 会爆而是先用检索的方式找到相关笔记再把它们喂给模型。模型基于这些笔记推理、生成结果再存回库里成为新的记忆。这个循环跑起来之后你的库会越来越厚模型能调用的上下文越来越丰富输出质量也会随之提升。这就是为什么我说 Obsidian 适合做底座——它承载的是长期积累而不是一次性对话。检索这一步简单点可以用关键词匹配比如按标签、按链接复杂点可以上向量检索。但我的建议是先从关键词和标签开始别一上来就搞向量库。因为你的笔记量在早期根本不大关键词匹配足够用而且可解释性强出问题好排查。等笔记上千篇了再考虑向量检索也不迟。3.4 关于harness这个词以及它和 agent 的区别既然标题和热词里都出现了 harness我顺带把这个概念理一理因为很多人搞混。Agent智能体通常指能自主决策、调用工具、多步执行的系统。Harness 更偏向承载和驾驭——它是 agent 运行所依赖的那层基础设施包括记忆存储、上下文管理、工具接口、状态持久化。打个比方agent 是司机harness 是车和路。司机再厉害没有车和路也跑不起来。Obsidian 在这个比喻里就是路和车库——它不负责开车但负责让车有地方停、有路可走、有油可加记忆。所以Obsidian 成为个人 LLM harness 的底座翻译成人话就是它成了你个人 AI 工作流里负责存储和管理上下文的那一层。它本身不聪明但它让聪明的东西有了依托。4. 实测下来哪些场景 Obsidian 真的香4.1 长期知识积累 反复调用如果你有一个领域需要长期深耕比如你在研究某个技术方向、在写一本书、在做长期调研那 Obsidian 的价值会非常明显。原因是这类场景的共同特征是资料会不断累积且需要反复交叉引用。你今天读的一篇论文可能三个月后写东西时要用你上个月记的一个想法可能这个月和另一个想法碰撞出火花。这种长期、交叉、反复的需求正是 Obsidian 双向链接和本地存储的强项。配合 LLM你可以让模型定期帮你整理库——比如找出孤立笔记没有任何链接指向的、发现潜在关联两篇笔记主题相近但没互链、生成主题综述把某个标签下的笔记汇总成一篇。这些操作在 Obsidian 的纯文本结构下都很好实现。4.2 需要严格数据掌控的场景有些内容你不放心放在云端比如个人日记、商业想法、未公开的研究。Obsidian 的本地存储让你对数据有完全控制权。你可以选择不同步、不上传模型调用也可以用本地部署的方案整个链路都在你自己手里。这一点在当下越来越重要。不是说云端不好而是有得选本身就是价值。Obsidian 给了你这个选项。4.3 需要自定义工作流的技术型用户如果你会写点脚本、愿意折腾Obsidian 的可扩展性会让你很舒服。它的库是开放的文件结构你可以用任何语言、任何工具去处理。想加个自动摘要写脚本。想做个每日回顾生成器写脚本。想把模型输出自动分类归档还是写脚本。这种什么都能自己接的自由度是封闭式笔记软件给不了的。代价是你得自己动手但对技术型用户来说这恰恰是乐趣所在。4.4 跨工具、跨平台的资料汇总Obsidian 能读 Markdown而 Markdown 是当下最通用的文档格式之一。你在别处写的东西——代码注释、文档、网页剪藏——只要转成 Markdown就能进 Obsidian。这让它天然适合做资料汇总中心。我自己的做法是所有外部资料先转 Markdown 再进库。网页用剪藏工具转PDF 用转换工具转代码文档直接复制。进库之后统一管理模型调用时也是统一格式省去了大量格式适配的麻烦。5. 什么时候你不该选 Obsidian几种劝退场景5.1 你只是想让模型帮忙改改文案如果你用大模型就是为了帮我润色这段话帮我写个邮件帮我翻译一下那 Obsidian 对你来说是杀鸡用牛刀。这类需求是一次性、无积累的——你不需要把每次的文案都存起来不需要建立链接不需要长期检索。直接用聊天界面就够了搭 Obsidian 工作流纯属给自己找事。我见过有人为了显得专业硬是把简单的文案需求套进 Obsidian 工作流结果每次改个文案要先建笔记、打标签、跑脚本效率反而更低。工具是服务于需求的别本末倒置。5.2 你极度依赖移动端和实时协作Obsidian 的移动端体验说实话跟桌面端有差距。它的强项在桌面端的文件管理和插件生态移动端更多是能用而非好用。如果你大部分时间在手机上处理笔记或者需要多人实时协作编辑同一份文档Obsidian 不是最优解。实时协作这块尤其明显。Obsidian 的设计哲学是本地优先、个人优先多人同时编辑同一份文件不是它的强项。如果你的场景是团队协作得考虑别的方案。5.3 你不愿意花时间搭建和维护Obsidian 的自由度是双刃剑。它不预设结构意味着你得自己想清楚怎么组织它插件丰富意味着你得自己选、自己配、自己维护。如果你希望打开就能用、不用配置、不用维护那 Obsidian 会让你痛苦。它的价值需要你投入时间去挖掘前期有个明显的搭建期。如果你没这个耐心或者你的需求根本不需要这么灵活那选个开箱即用的方案更合适。5.4 你的资料量极小且不增长如果你的笔记总共就几十篇而且基本不增加那 Obsidian 的检索、链接、结构化优势都发挥不出来。这种规模下任何笔记软件都够用没必要为了未来可能用得上而提前上重装备。我的建议是先用最简单的方案等它真的不够用了再升级。不要因为听说 Obsidian 好就盲目迁移迁移成本也是成本。6. 搭建过程中最容易踩的几个坑6.1 一上来就追求完美结构这是新手最常见的坑。刚开始用 Obsidian就想着要设计一套完美的文件夹结构、标签体系、链接规则结果花了两周设计一篇笔记没写。我的经验是结构是长出来的不是设计出来的。先随便写写到一定程度你自然会发现有哪几类笔记、它们怎么关联。这时候再整理结构比一开始空想靠谱得多。LLM 工作流也一样。别一上来就设计复杂的自动化流程先手动跑通读笔记、问模型、存结果这个最小闭环跑顺了再优化。6.2 把模型输出直接当成品存进库模型生成的内容质量参差不齐。直接存进库时间长了你的库会被大量低质量内容污染检索时噪音很大。我的做法是模型输出先存到一个待整理区域人工过一遍确认有价值再移到正式区域。或者至少在笔记里标注AI 生成待核实。这样既保留了 AI 的产出又不让它污染核心知识库。6.3 忽略文件命名和路径规范Obsidian 的链接是基于文件名的。如果你文件名起得随意比如笔记1、新建文档、未命名那链接会一团乱模型读的时候也分不清哪篇是哪篇。建议从一开始就定个命名规范比如日期-主题或者领域-主题。文件名清晰链接才清晰模型理解上下文才准确。这个习惯越早养成越好后期改起来很痛苦。6.4 过度依赖插件忽视原生能力Obsidian 插件生态很丰富但插件多了会拖慢启动、增加冲突风险、提高维护成本。而且很多插件功能原生能力配合简单脚本就能实现。我的原则是能用原生就用原生能用脚本就用脚本实在不行再上插件。插件是最后的选择不是第一选择。尤其是涉及 LLM 工作流的插件更新频繁、稳定性参差用之前先想清楚是不是真的需要。6.5 忘了备份本地存储的优点是掌控权在你缺点是掌控权在你意味着数据安全也归你管。硬盘坏了、误删了、同步冲突了都可能丢数据。Obsidian 库就是个文件夹备份很简单——定期复制一份到别处或者用版本控制工具管理。我自己的库是用 Git 管理的每次大改动前提交一次出问题能回滚。这个习惯救过我好几次。7. 我个人的一些实操心得聊了这么多最后分享几个我自己踩坑踩出来的经验都是文档里不会写的。第一个是关于什么时候该让模型读全库。我的答案是几乎永远不该。全库内容塞给模型token 消耗巨大而且噪音多模型反而抓不住重点。正确做法是先检索、再喂给模型。检索可以用标签、可以用链接、可以用关键词但一定要有个筛选步骤。第二个是关于模型输出的格式稳定性。不同模型、不同版本输出的 Markdown 格式习惯不一样。有的喜欢用###有的喜欢用**加粗**代替标题。如果你要把输出写回库最好在 prompt 里明确指定格式比如标题只用##和###不要用加粗代替标题。指定了之后格式会稳定很多。第三个是关于库的规模。我的库现在有几千篇笔记检索速度依然很快因为 Obsidian 本身对纯文本的处理效率很高。但如果你的库里有大量图片、附件那体积会涨得很快备份和同步都会变慢。建议图片附件单独管理别和笔记混在一起。第四个是关于别把 Obsidian 当数据库用。它是笔记工具不是关系型数据库。如果你需要复杂的查询、统计、关联分析用专门的工具更合适。Obsidian 的强项是人可读、模型可读的文本管理别让它干它不擅长的事。第五个也是最重要的先想清楚你的需求再选工具。Obsidian 不是万能的它只是在本地、纯文本、结构化、可扩展这几个维度上做得特别好。如果你的需求正好落在这几个维度上那它很合适如果不是别硬套。工具选对了事半功倍选错了再努力也是白费。我自己是从手动复制粘贴一路走到脚本自动化的中间换过好几次方案也推翻过自己设计的结构。这个过程没有捷径但每一步的踩坑都让我更清楚自己要什么。如果你也在搭自己的 LLM 工作流我的建议是别追求一步到位先跑起来再慢慢优化。跑起来的那一刻你就已经超过大多数还在纠结选什么工具的人了。