Vào năm 2026, việc kết nối một code agent với một kho Obsidian không còn là một ý tưởng xa lạ. Đây có lẽ là thiết lập quản lý kiến thức bị đánh giá thấp nhất hiện nay. Và thế nhưng, hầu như tất cả những ai làm điều này đều chỉ dừng lại ở bước đầu tiên: trỏ Claude Code vào một thư mục và để nó đọc và ghi các file markdown. Cách này hoạt động. Nhưng đó chỉ là sự khởi đầu, và để hiểu tại sao bước tiếp theo, MCP, lại quan trọng, trước tiên cần hiểu những gì chúng ta đã có và điểm yếu của nó.
Những gì đã có thể làm mà không cần MCP
Khi Claude Code trỏ trực tiếp vào một kho, nó hoạt động như bất kỳ agent nào có quyền truy cập hệ thống file: nó đọc cấu trúc thư mục, sử dụng grep và glob để định vị nội dung liên quan, và ghi hoặc chỉnh sửa các file markdown tuân theo các quy ước bạn đã đưa ra (YAML frontmatter, wikilinks, phân cấp thư mục theo loại nội dung). Không có plugin, không có cơ sở dữ liệu, không có API: chỉ là văn bản thuần túy và một agent biết cách đọc và ghi nó một cách có phán đoán.
Kết quả, khi hệ thống được thiết kế tốt, sẽ mạnh mẽ hơn vẻ ngoài của nó. Tham khảo một ví dụ thực tế, không phải giả định: một kho mà tôi theo dõi sát sao đã, với chính phương pháp này, đi từ 78 nguồn thô (bài báo, bài viết, tài liệu) lên 180 trang wiki có liên kết với nhau (83 trong số đó là trang khái niệm, phần còn lại là công cụ, con người, so sánh và tóm tắt nguồn), tất cả đều có tham chiếu chéo mà chính agent cập nhật mỗi khi có nội dung mới. Mà không cần ai viết một trang nào bằng tay.
Giới hạn của truy cập file trực tiếp
Nhưng mô hình này có một giới hạn về cấu trúc, không chỉ là giới hạn về hiệu suất. Claude Code cần biết trước cách tổ chức kho của bạn: thư mục nào là bất biến, quy ước frontmatter là gì, khái niệm nằm ở đâu so với công cụ. Trên thực tế, mỗi kho mới là một tích hợp khác nhau cần được giải thích từ đầu trong prompt hệ thống.
Hơn nữa, agent không thể hỏi một kho "bạn có khả năng làm gì?". Nó chỉ có thể đọc những gì đã tồn tại và thực hiện các thao tác file chung chung (đọc, ghi, tìm kiếm theo văn bản). Không có cách nào để hiển thị một thao tác dẫn xuất cho nó (đưa cho tôi đồ thị backlink của ghi chú này, chạy truy vấn Dataview này, cho tôi biết trang nào bị mồ côi) mà không có chính agent tự xây dựng lại logic đó từ đầu mỗi lần, lãng phí ngữ cảnh và biên độ sai sót.
MCP giải quyết vấn đề gì, một cách chuyên sâu
MCP (Model Context Protocol) là tiêu chuẩn mở mà Anthropic ra mắt vào tháng 11 năm 2024 để giải quyết chính xác vấn đề này: sự tích hợp giữa các mô hình AI và các hệ thống bên ngoài. Trước MCP, nếu N trợ lý AI cần kết nối với M công cụ hoặc nguồn dữ liệu khác nhau, cần N×M tích hợp tùy chỉnh: khi một ứng dụng muốn hỗ trợ Notion, nó xây dựng từ đầu; khi một ứng dụng khác muốn điều tương tự, nó lại xây dựng lại từ đầu. MCP biến N×M đó thành N+M: các client chung được xây dựng (một cho mỗi ứng dụng) và các server chung (một cho mỗi hệ thống), và bất kỳ client nào cũng có thể nói chuyện với bất kỳ server nào mà không cần tích hợp tùy chỉnh.
Sự tương tự chính xác là USB-C: trước đây, mỗi thiết bị ngoại vi có một đầu nối riêng; với USB-C, thiết bị chỉ cần nói giao thức, mà không cần quan tâm nó được kết nối với Mac hay PC.
Kiến trúc có ba lớp. Host là ứng dụng hướng tới người dùng (Claude Code, Claude Desktop, hoặc một agent tùy chỉnh) diễn giải những gì được yêu cầu và quyết định xem có cần dữ liệu hoặc công cụ bên ngoài hay không. Client nằm bên trong host và quản lý kết nối 1:1 với mỗi server, dịch các yêu cầu trừu tượng thành các thông điệp MCP cụ thể và quản lý vòng đời phiên. Server kết nối giao thức với một hệ thống thực, trong trường hợp này là một kho Obsidian, dịch các yêu cầu MCP thành các thao tác bản địa.
Hai thuộc tính làm cho điều này không chỉ là một lớp trừu tượng hóa về mặt hình thức. Đầu tiên là khả năng khám phá năng lực động: khi kết nối, client hỏi server nó có khả năng làm gì, và server phản hồi trong thời gian thực. Nếu ngày mai server thêm một chức năng mới, client không cần phải được lập trình lại để sử dụng nó. Thứ hai là sự tách rời giữa trí thông minh và dữ liệu: người xây dựng server MCP cho Obsidian không cần biết mô hình nào sẽ sử dụng nó, và người xây dựng agent không cần xây dựng lại tích hợp của họ mỗi khi họ thay đổi mô hình.
Một server MCP hiển thị ba loại nguyên thủy. Resources là dữ liệu mà mô hình có thể đọc nhưng không thể sửa đổi: nội dung của một ghi chú, kết quả tìm kiếm, đồ thị backlink. Tools là các hành động mà mô hình có thể chủ động gọi: tạo một ghi chú, cập nhật một thẻ, thực thi một truy vấn có cấu trúc. Prompts là các mẫu hướng dẫn có thể tái sử dụng và tham số hóa, ví dụ "tóm tắt nguồn này và tạo trang wiki tương ứng" như một thao tác được đặt tên, không phải văn bản tự do phải viết lại mỗi lần.
Áp dụng cụ thể cho Obsidian
Các server MCP được xây dựng riêng cho Obsidian đã tồn tại trong hệ sinh thái mã nguồn mở của nó, thường được hỗ trợ bởi plugin REST API cục bộ của riêng Obsidian, hiển thị các thao tác như tìm kiếm ngữ nghĩa trong kho, tạo và chỉnh sửa ghi chú, quản lý thẻ và siêu dữ liệu, hoặc đọc đồ thị liên kết, mà không cần agent biết trước cấu trúc thư mục chính xác.
Điều thay đổi trong thực tế là tinh tế nhưng quan trọng: không có MCP, Claude Code quản lý kho của bạn bằng các quy tắc mà bạn đã giải thích cho nó từng cái một. Với MCP, kho của bạn trở thành một công cụ mà Claude Code có thể vận hành chính xác như cách nó vận hành một API hoặc cơ sở dữ liệu, khám phá các khả năng của nó tại thời điểm kết nối, không phải ghi nhớ chúng trước. Và cùng một kết nối đó hoạt động cho bất kỳ client MCP nào khác, không chỉ Claude Code: cùng một server có thể cung cấp cho một agent khác, trong một ứng dụng khác, mà không cần chạm vào một dòng mã nào ở phía Obsidian.
Khung thực tế: ba cấp độ trưởng thành
Để xác định thiết lập của bạn đang ở đâu, đây là khung mà tôi sử dụng:
Cấp độ 0: sao chép-dán thủ công ngữ cảnh. Mỗi cuộc trò chuyện bắt đầu từ đầu; người dùng dán các đoạn liên quan từ ghi chú của họ vào khung chat. Nó hoạt động cho các nhiệm vụ cụ thể, nhưng không mở rộng được.
Cấp độ 1: agent với quyền truy cập file trực tiếp. Đây là nơi hầu hết các thiết lập Claude Code + Obsidian hiện nay, bao gồm cả ví dụ 78→180 trang trong bài viết này. Agent đọc và ghi kho trực tiếp, tuân theo các quy ước được giải thích trong một file hướng dẫn. Nó đã mạnh hơn đáng kể so với cấp độ 0, và đối với một kho duy nhất được quản lý bởi một agent duy nhất, nó có thể đủ dùng trong một thời gian dài.
Cấp độ 2: agent được kết nối qua MCP. Kho được hiển thị như một server với các khả năng có thể khám phá động, có thể tái sử dụng qua các mô hình và ứng dụng khác nhau. Nó có ý nghĩa ngay khi có nhiều hơn một agent, nhiều hơn một kho, hoặc nhu cầu hiển thị các thao tác vượt ra ngoài việc đọc và ghi từng file một.
Không cần thiết phải nhảy thẳng lên cấp độ 2 để tận dụng một kho do AI quản lý. Cấp độ 1 đã là một bước nhảy vọt thực sự so với việc không có hệ thống. Nhưng hiểu được MCP giải quyết vấn đề gì là hiểu được hướng đi của điều này: từ "AI của tôi có thể đọc ghi chú của tôi" đến "kiến thức của tôi là một hệ thống mà bất kỳ AI nào cũng có thể vận hành."
Thiết lập của bạn hiện đang ở cấp độ nào? Hãy cho tôi biết trong phần bình luận. Nếu có đủ sự quan tâm, bài viết tiếp theo sẽ là hướng dẫn từng bước về cách thiết lập server MCP đầu tiên của bạn cho Obsidian.
Và nếu điều này hữu ích cho bạn, hãy theo dõi tôi @chesny
Đây chỉ là bài viết đầu tiên trong một loạt bài về các agent không còn đọc hệ thống nữa mà bắt đầu vận hành chúng.
