MCP 是连接 Claude Code 和你的 Obsidian 库的缺失环节

MCP 是 Claude Code 与你的 Obsidian vault 之间缺失的那一块 July 15, 2026 · 7 min read · View source ↗ MCP Claude Obsidian 2026 年，把一个代码代理连接到一个 Obsidian vault，已经不再是什么异想天开的点子了。它很可能是当下最被低估的知识管理配置。然而，几乎所有这么做的人，都停在了第一级台阶：把 Claude Code 指向一个文件夹，让它读写 markdown。这能行。但那只是开始，而要理解为什么下一步——MCP——很重要，需要先真正搞懂我们现在已经拥有了什么，以及它在哪里崩坏。 没有 MCP 已经能做到什么 当 Claude Code 直接指向一个 vault 时，它的行为就像任何一个有文件系统访问权限的代理：读取文件夹结构，用 grep 和 glob 定位相关内容，并按照你给它的约定（YAML frontmatter、wikilinks、按内容类型划分的文件夹层级）读写或编辑 markdown 文件。没有插件、没有数据库、没有 API：只有纯文本，以及一个懂得如何有判断力地读写它的代理。 当这个系统设计得当的时候，结果比看上去更强大。作为一个真实的、而非假设性的参照：一个我一直密切关注的 vault，用完全同样的方法，从 78 个原始来源（论文、文章、文档）变成了 180 个相互关联的 wiki 页面（其中 83 个是概念页，其余是工具、人物、对比和来源摘要），全部带有交叉引用，而且每当有新内容进来时，代理自己就会把这些引用保持更新。没有一个人亲手写过任何一页。 直接访问文件的天花板 但这个模型有一个结构性的极限，而不只是性能上的限制。Claude Code 需要事先知道你的 vault 是怎么组织的：哪个文件夹是不可变的，frontmatter 的约定是什么，概念放在哪里、工具又放在哪里。实际上，每一个新 vault 都是一次不同的集成，需要在 system prompt 里从头重新解释一遍。 此外，代理无法向一个 vault 问"你能做什么？"。它只能读取已存在的内容，执行通用的文件操作（读、写、按文本搜索）。没有任何办法向它暴露一个派生操作（给我这条笔记的 backlink 图、跑一下这条 Dataview 查询、告诉我哪些页面成了孤儿页），除非让代理自己每次都从零重建那段逻辑，在这个过程中消耗上下文，并增加出错的空间。 MCP 深入解决了什么 MCP（Model Context Protocol）是 Anthropic 在 2024 年 11 月发布的开放标准，正是为了解决这个问题：AI 模型与外部系统之间的集成。在 MCP 之前，如果 N 个 AI 助手需要连接到 M 个不同的工具或数据源，就需要 N×M 个定制集成：当一个应用想支持 Notion 时，它从零构建；当另一个应用想要同样的东西时，它又从零重建一遍。MCP 把那个 N×M 变成了 N+M：构建通用客户端（每个应用一个）和通用服务器（每个系统一个），任何客户端都能与任何服务器对话，无需定制集成。 正确的类比是 USB-C：以前，每个外设都有自己的接口；有了 USB-C，设备只需要会说这个协议，而不用在乎它连的是 Mac 还是 PC。 这个架构有三层。host 是面向用户的应用（Claude Code、Claude Desktop，或你自己的代理），它解读被要求做的事，并决定是否需要外部数据或工具。client 住在 host 内部，管理与每个服务器之间一对一的连接，把抽象请求翻译成具体的 MCP 消息，并管理会话的生命周期。server 把协议连接到一个真实系统——在这里就是一个 Obsidian vault——把 MCP 请求翻译成本地操作。 有两个属性让它不只是一层装饰性的抽象。第一是能力的动态发现：连接时，客户端问服务器它能做什么，服务器实时作答。如果服务器明天新增了一个函数，客户端无需被重新编程就能使用它。第二是智能与数据的解耦：为 Obsidian 构建 MCP 服务器的人不需要知道哪个模型会用它，而构建代理的人也不需要每次换模型时重建集成。 一个 MCP 服务器暴露三种原语。resources 是模型可以读取但不能修改的数据：一条笔记的内容、一次搜索的结果、backlink 图。tools 是模型可以主动调用的动作：创建一条笔记、更新一个 tag、执行一条结构化查询。prompts 是可复用、可参数化的指令模板，比如"总结这个来源并生成对应的 wiki 页面"，作为一个具名操作存在，而不是每次都要重写的自由文本。 具体应用到 Obsidian Obsidian 的开源生态系统里，已经存在专门为它构建的 MCP 服务器，通常依托于 Obsidian 自带的本地 REST API 插件，暴露的操作包括：对 vault 的语义搜索、创建和编辑笔记、管理 tag 和元数据、读取链接图，而代理无需事先知道确切的文件夹结构。 实践中的变化细微但重要：没有 MCP 时，Claude Code 管理你的 vault，用的是你一条一条讲给它的规则。有了 MCP，你的 vault 变成了一件工具，Claude Code 可以像操作一个 API 或一个数据库那样操作它，在连接的当下发现它的能力，而不是事先记住它们。而且这同一个连接还能服务于任何其他 MCP 客户端，不仅仅是 Claude Code：同一个服务器可以驱动另一个应用里的另一个代理，而不动 Obsidian 一侧的一行代码。 实用框架：三个成熟度层级 为了定位你自己的配置处在哪，这是我所用的框架： 第 0 级：手工复制粘贴上下文。每一场对话都从零开始；用户把自己笔记里的相关片段粘贴到聊天里。对付一次性任务还行，但无法规模化。 第 1 级：代理直接访问文件。这就是今天大多数 Claude Code + Obsidian 配置所处的位置，包括本文中那个 78→180 页的例子。代理直接读写 vault，遵循一份说明文件里解释过的约定。这已经比第 0 级强出不少，而且对于一个由单个代理管理的单个 vault 来说，可能在很长时间内都够用了。 第 2 级：通过 MCP 连接的代理。vault 被暴露为一个服务器，能力可动态发现，可在不同模型和应用之间复用。一旦涉及不止一个代理、不止一个 vault，或需要暴露超出"逐个文件读写"的操作时，它就有意义了。 你不需要直接跳到第 2 级，才能从一个 AI 管理的 vault 里榨出价值。相对于完全没有系统，第 1 级已经是一次真正的跃升。但理解 MCP 解决了什么，就是理解这件事的走向：从"我的 AI 能读我的笔记"到"我的知识是一个任何 AI 都能操作的系统"。 你自己现在的配置处在哪个层级？在评论里告诉我。如果兴趣足够，下一篇将是一份分步指南：如何为 Obsidian 搭建你的第一个 MCP 服务器。 如果这对你有用，请关注我 @chesny 这只是这个系列的第一篇文章，讲的是那些不再只是读系统、而是开始操作系统本身的代理。 Tags: # X # MCP # Claude # Obsidian Related articles Every Morning I Re-Taught Claude My Whole Life. It Forgot by Lunch. One File Ended the Loop People spent years hunting the perfect prompt. The answer was never how you ask. It was what the AI already knows about you before you open your mouth. Claude AI Obsidian MCP