2026 年，将代码 Agent 连接到 Obsidian 知识库已不再是陌生的概念。这很可能是目前被严重低估的知识管理方案。然而，几乎所有尝试这样做的人都停留在第一步：让 Claude Code 指向一个文件夹，然后让它读取和编写 Markdown 文件。这样做确实有效，但这仅仅是个开始。要理解为什么下一步——MCP 如此重要，我们首先需要弄清楚当前方案的优势与局限。
无需 MCP 已能实现的功能
当 Claude Code 直接指向一个知识库时，它的运作方式与任何拥有文件系统访问权限的 Agent 一样：它会读取文件夹结构，使用 grep 和 glob 命令定位相关内容，并按照你设定的规则（如 YAML 前置元数据、Wiki 链接、按内容类型划分的文件夹层级）来编写或编辑 Markdown 文件。整个过程无需插件、无需数据库、无需 API：只需纯文本和一个懂得如何智能地读写文本的 Agent。
当系统设计良好时，其效果远超想象。举一个真实的例子：我密切关注的一个知识库，仅通过这种方法，便从 78 个原始来源（包括论文、文章、文档）扩展到了 180 个相互关联的 Wiki 页面（其中 83 个为概念页面，其余为工具、人物、对比和来源摘要），所有交叉引用都由 Agent 在每次新内容加入时自动更新。整个过程无需任何人手动编写一页内容。
直接文件访问的局限性
但这种模式存在结构性限制，而不仅仅是性能问题。Claude Code 需要预先了解你的知识库结构：哪个文件夹是不可修改的、前置元数据的格式约定是什么、概念页面与工具页面的存放位置。实际上，每个新的知识库都是一次不同的集成，需要在系统提示词中从头开始解释。
此外，Agent 无法向知识库提问"你能做什么？"。它只能读取已有的内容，并执行通用的文件操作（如读取、写入、按文本搜索）。无法向 Agent 暴露衍生操作（如获取笔记的反向链接图、运行 Dataview 查询、找出孤立页面），除非 Agent 每次从头重建相关逻辑，这无疑会浪费上下文并增加出错概率。
MCP 的深入解析
MCP（模型上下文协议）是 Anthropic 于 2024 年 11 月推出的开放标准，旨在解决 AI 模型与外部系统集成的问题。在 MCP 之前，如果 N 个 AI 助手需要连接 M 个不同的工具或数据源，则需要 N×M 个自定义集成：当一个应用想要支持 Notion 时，它需要从头构建集成；当另一个应用也想要同样的功能时，它又得再次从头构建。MCP 将这种 N×M 的关系转变为 N+M：构建通用客户端（每个应用一个）和通用服务器（每个系统一个），任何客户端都可以与任何服务器通信，无需自定义集成。
一个恰当的类比是 USB-C：在此之前，每个外设都有自己的接口；而有了 USB-C，设备只需支持该协议，无需关心它连接的是 Mac 还是 PC。
该架构分为三层。主机是面向用户的应用（如 Claude Code、Claude Desktop 或自定义 Agent），负责解释用户请求并决定是否需要外部数据或工具。客户端位于主机内部，管理与每个服务器的一对一连接，将抽象请求转化为具体的 MCP 消息，并管理会话生命周期。服务器则将协议与实际系统（在这里是 Obsidian 知识库）连接起来，将 MCP 请求转化为原生操作。
两个特性使其不仅仅是表面上的抽象层。第一个是动态能力发现：连接时，客户端会询问服务器能做什么，服务器会实时响应。如果服务器明天添加了新功能，客户端无需重新编程即可使用。第二个是智能与数据的解耦：构建 Obsidian 的 MCP 服务器的人无需知道未来将由哪个模型使用它，而构建 Agent 的人也无须在每次更换模型时重建集成。
MCP 服务器暴露三种类型的原语。资源是模型可读取但不可修改的数据，例如笔记内容、搜索结果、反向链接图。工具是模型可以主动调用的操作，例如创建笔记、更新标签、执行结构化查询。提示词是可重复使用的参数化指令模板，例如"总结此来源并生成相应的 Wiki 页面"作为一个命名操作，而不是每次都需要重写的自由文本。
具体应用于 Obsidian
针对 Obsidian 构建的 MCP 服务器在其开源生态系统中已经存在，通常通过 Obsidian 自带的本地 REST API 插件来支持。这些服务器可以暴露诸如语义搜索、笔记创建与编辑、标签与元数据管理、读取链接图等操作，而无需 Agent 预先了解确切的文件夹结构。
实际的变化微妙但重要：没有 MCP 时，Claude Code 通过你逐一解释的规则来管理你的知识库。有了 MCP，你的知识库就变成了一个工具，Claude Code 可以像操作 API 或数据库一样操作它，在连接时动态发现其能力，而非事先记忆。而且，同一连接也适用于任何其他 MCP 客户端，而不仅仅是 Claude Code：同一个服务器可以为另一个应用中的不同 Agent 提供数据，在 Obsidian 端无需修改任何代码。
实用框架：三个成熟度等级
为了帮助你定位当前的设置，我使用以下框架：
0 级：手动复制粘贴上下文。每次对话都从零开始；用户将笔记的相关片段粘贴到聊天中。这适用于特定任务，但无法扩展。
1 级：Agent 拥有直接文件访问权限。这是目前大多数 Claude Code + Obsidian 设置的现状，包括本文中提到的 78→180 页的案例。Agent 直接读取和写入知识库，遵循指令文件中说明的规则。它已经比 0 级强大得多，对于由单个 Agent 管理的单个知识库，它可能在很长一段时间内都足够用。
2 级：通过 MCP 连接的 Agent。知识库作为一个服务器暴露，具有动态可发现的能力，可在不同模型和应用之间重复使用。一旦涉及多个 Agent、多个知识库，或需要暴露超出逐个文件读写范围的操作时，这种模式就显得很有必要。
不必直接跳到 2 级才能利用 AI 管理知识库的好处。与完全没有系统相比，1 级已经是一个真正的飞跃。但理解 MCP 解决的问题，就是理解未来的发展方向：从"我的 AI 能读取我的笔记"到"我的知识是一个任何 AI 都能操作的系统"。
你当前的设置处于哪个等级？在评论区告诉我。如果感兴趣的人多，下一篇文章将详细介绍如何为你的 Obsidian 配置第一个 MCP 服务器。
如果这篇文章对你有帮助，请关注我 @chesny
这只是关于 Agent 从被动读取系统到主动操作系统的系列文章的第一篇。
