在 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 無法問筆記庫「你能做什麼？」它只能讀取既有的內容，並執行一般的檔案操作（讀取、寫入、文字搜尋）。無法向它暴露衍生操作（例如：給我這則筆記的反向連結圖表、執行這個 Dataview 查詢、告訴我哪些頁面是孤立頁面），除非 Agent 每次都從零重建那套邏輯，這會浪費上下文並增加錯誤風險。
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 或自訂 Agent），負責解讀請求並決定是否需要外部資料或工具。客戶端（Client）存在於主機內部，負責管理與每個伺服器的一對一連線，將抽象請求轉換為具體的 MCP 訊息，並管理連線的生命週期。伺服器（Server）則將協定與真實系統（在此例中是 Obsidian 筆記庫）連結起來，將 MCP 請求轉換為原生操作。
有兩個特性讓這不僅僅是表面的抽象層。第一個是動態能力發現：連線時，客戶端會詢問伺服器它能做什麼，伺服器即時回應。如果伺服器明天新增了一個功能，客戶端不需要重新程式設計就能使用它。第二個是智慧與資料的解耦：建立 Obsidian 的 MCP 伺服器的人不需要知道哪個模型會使用它，而建立 Agent 的人也不需要每次更換模型時就重新建立整合。
MCP 伺服器暴露三種基本類型。資源（Resources）是模型可以讀取但不能修改的資料：筆記的內容、搜尋結果、反向連結圖表。工具（Tools）是模型可以主動呼叫的動作：建立筆記、更新標籤、執行結構化查詢。提示詞（Prompts）是可重複使用且可參數化的指令範本，例如「總結此來源並產生對應的 Wiki 頁面」作為一個命名操作，而不是每次都要重寫的純文字。
具體應用於 Obsidian
在 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。
