Memory MCP Là Gì?

Một trong những giới hạn khó chịu nhất khi làm việc với AI agent hiện nay là agent "quên sạch" mọi thứ ngay khi session kết thúc. Bạn giải thích kiến trúc dự án, convention đặt tên, lý do vì sao team chọn PostgreSQL thay vì MongoDB — rồi ngày mai mở lên, agent lại hỏi lại từ đầu. Memory MCP (Model Context Protocol server chuyên về bộ nhớ) giải quyết đúng bài toán này: nó cho agent một nơi để "ghi sổ" lại kiến thức dưới dạng knowledge graph (đồ thị tri thức) có thể truy vấn lại bất cứ lúc nào, ở bất cứ session nào, thậm chí bất cứ công cụ AI nào miễn là công cụ đó nói được MCP. Bài này sẽ đi từ mô hình dữ liệu, bộ công cụ (tool) cốt lõi, cách cài đặt, đến việc quyết định nên lưu gì và tuyệt đối không nên lưu gì — để bạn dùng Memory MCP đúng cách ngay từ ngày đầu, tránh biến nó thành một bãi rác context gây hại nhiều hơn lợi.

Bộ Công Cụ Cốt Lõi Của Memory MCP: Store, Retrieve, Search Và Knowledge Graph Entities

Memory MCP phổ biến nhất hiện nay (bản tham chiếu @modelcontextprotocol/server-memory do chính team MCP duy trì) không lưu memory dưới dạng văn bản tự do như một file note. Nó dùng mô hình knowledge graph (đồ thị tri thức) gồm ba khái niệm:

• Entity (thực thể): một "node" trong graph, có name (tên duy nhất), entityType (loại, ví dụ person, project, decision, convention) và một danh sách observations — các câu ghi chú rời rạc, ngắn gọn, dạng atomic fact (sự kiện đơn lẻ).
• Relation (quan hệ): một cạnh nối hai entity, có hướng, biểu diễn dưới dạng động từ chủ động, ví dụ works_at, depends_on, supersedes.
• Observation: một fact cụ thể gắn vào entity, ví dụ "Chọn PostgreSQL vì cần transaction phức tạp cho module billing".

Agent tương tác với graph này qua một bộ tool cố định, agent tự quyết định khi nào gọi:

Trong thực tế, bạn hiếm khi gọi tool trực tiếp — bạn ra lệnh bằng ngôn ngữ tự nhiên, agent tự map sang tool call. Ví dụ prompt thực tế:

Hãy ghi lại vào memory: dự án này dùng feature-flag pattern LaunchDarkly cho mọi
rollout lớn, lý do là team cần kill-switch tức thời khi có incident.
Gắn observation này vào entity "project-conventions".

Agent sẽ tự sinh ra lệnh gọi tool tương đương:

{
  "tool": "add_observations",
  "arguments": {
    "observations": [
      {
        "entityName": "project-conventions",
        "contents": [
          "Sử dụng LaunchDarkly cho mọi feature rollout lớn để có kill-switch tức thời khi incident"
        ]
      }
    ]
  }
}

Và khi bạn hỏi lại ở session khác: "Team mình dùng feature flag tool nào?", agent sẽ gọi search_nodes với query "feature flag", đọc lại observation cũ, rồi trả lời chính xác mà không cần bạn nhắc lại.

Mẹo: Khi mới làm quen, hãy chủ động yêu cầu agent gọi read_graph và in ra toàn bộ nội dung để bạn "nhìn" được graph đang trông như thế nào — nhiều engineer bỏ qua bước này và không hình dung được dữ liệu thật sự được lưu ra sao.

Cài Đặt Memory MCP: Storage Backend, Vị Trí File Và Phạm Vi Scope

Bản tham chiếu của Memory MCP lưu graph dưới dạng file JSON Lines (.jsonl) trên local disk — mỗi dòng là một entity hoặc relation được serialize riêng, giúp việc append cực nhanh và tránh corrupt khi ghi liên tục. Không cần database, không cần server riêng.

Cài nhanh qua npx (không cần install global):

npx -y @modelcontextprotocol/server-memory

Vị trí file lưu được kiểm soát bằng biến môi trường MEMORY_FILE_PATH. Nếu không set, server dùng file memory.json ngay trong thư mục cài đặt của package — điều này rất dễ gây nhầm lẫn vì nhiều dự án sẽ vô tình share chung một file memory. Luôn set path rõ ràng:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "env": {
        "MEMORY_FILE_PATH": "/Users/you/projects/my-app/.agent/memory.jsonl"
      }
    }
  }
}

Về scoping (phạm vi), có ba chiến lược phổ biến:

• Scope theo project: đặt MEMORY_FILE_PATH bên trong thư mục dự án (thường thêm vào .gitignore hoặc commit thẳng nếu team muốn share memory qua Git — tuỳ policy). Phù hợp cho convention, architecture decision riêng của dự án.
• Scope theo user (global): một file memory chung ở home directory, dùng cho sở thích cá nhân, style code cá nhân, không liên quan project cụ thể.
• Scope theo team (shared): file memory được đồng bộ qua một network share hoặc commit vào repo — mọi thành viên team và mọi agent đều đọc/viết vào cùng một graph. Cách này mạnh nhưng rủi ro conflict khi nhiều agent viết đồng thời, nên cần review định kỳ.

Mẹo: Đừng bao giờ dùng một memory file "toàn cục duy nhất" cho tất cả dự án. Kiến thức của dự án A lẫn vào context của dự án B là nguyên nhân phổ biến nhất khiến agent trả lời sai — team gọi hiện tượng này là context poisoning (ô nhiễm context).

Vì Sao Persistent Memory Tốt Hơn Việc Phải Giải Thích Lại Context Mỗi Session

Context window (cửa sổ ngữ cảnh) của LLM, dù lớn đến đâu, vẫn là tài nguyên hữu hạn và có chi phí thực — mỗi token nhồi vào system prompt hay đầu conversation là token bạn phải trả tiền và cũng là token cạnh tranh với phần "suy nghĩ" thực sự của model. Nếu ngày nào bạn cũng phải paste lại 2.000 token giải thích kiến trúc dự án, bạn đang đốt tiền và làm loãng khả năng tập trung của agent vào task hiện tại.

Persistent memory (bộ nhớ bền vững) giải quyết vấn đề này bằng cách tách "kiến thức nền" ra khỏi context window của từng session. Agent chỉ cần gọi search_nodes hoặc open_nodes để lấy đúng phần thông tin liên quan đến task đang làm, thay vì nạp toàn bộ history vào đầu mỗi lần. Lợi ích cụ thể:

• Tiết kiệm token thật sự đo được: một project brief đầy đủ có thể tốn 3.000–5.000 token nếu paste tay; qua memory, agent chỉ lấy 200–400 token observation liên quan trực tiếp đến câu hỏi.
• Consistency (tính nhất quán) giữa các session và giữa các thành viên team: hai kỹ sư dùng chung memory graph sẽ nhận được câu trả lời giống nhau cho cùng một câu hỏi về convention, vì cả hai đọc từ một nguồn sự thật (single source of truth).
• Onboarding nhanh hơn: một agent "mới" (session mới, hoặc thậm chí một AI agent khác chạy trên IDE khác) có thể đọc toàn bộ graph và nắm được ngữ cảnh dự án trong vài giây, tương đương việc một kỹ sư mới đọc xong toàn bộ tài liệu nội bộ.
• Giảm rủi ro "ảo giác" do thiếu context: khi model không biết một quyết định đã có, nó dễ tự suy đoán và đưa ra gợi ý mâu thuẫn với quyết định cũ. Memory giúp model luôn có sẵn "ground truth" thay vì phải đoán.

Mẹo: Đo thử: yêu cầu agent trả lời một câu hỏi về convention dự án khi KHÔNG có memory, rồi lại hỏi khi CÓ memory kèm theo. Chênh lệch chất lượng câu trả lời sẽ thuyết phục cả những đồng nghiệp hoài nghi nhất về giá trị của persistent memory.

Nên Lưu Gì Và Tuyệt Đối Không Nên Lưu Gì Vào Memory Của Agent

Memory chỉ hữu ích khi nó "sạch" — nhiều dự án thất bại với Memory MCP không phải vì công cụ tệ mà vì graph bị nhồi quá nhiều thông tin rác, mâu thuẫn, hoặc lỗi thời, khiến agent lấy nhầm fact cũ và trả lời sai (chính là context poisoning nhắc ở trên).

Nên lưu:

• Architecture decision record (ADR) tóm tắt — lý do chọn công nghệ, kèm ngày quyết định.
• Naming convention, coding style riêng của team không thể suy ra từ linter (ví dụ: "mọi service method trả về Result<T, E> thay vì throw exception").
• Domain knowledge nghiệp vụ mà chỉ team mới biết (ví dụ: "trường status = 3 nghĩa là đơn hàng đang chờ đối soát với ngân hàng, không phải đã hoàn tất").
• Các quyết định "đã cân nhắc và từ chối" — để agent không đề xuất lại giải pháp đã bị team loại bỏ có lý do.
• Sở thích làm việc cá nhân ổn định (ví dụ: "luôn viết test trước khi implement", "ưu tiên function thay vì class khi có thể").

Tuyệt đối không lưu:

• Secret, API key, token, connection string — memory file thường lưu plaintext trên disk, không phải nơi an toàn để giữ credential.
• Thông tin cá nhân nhạy cảm (PII) của người dùng thật, dữ liệu khách hàng.
• Log debug tạm thời, stack trace của một bug đã fix xong — đây là rác làm phình graph mà không còn giá trị tham chiếu.
• Thông tin có khả năng thay đổi liên tục (ví dụ: "sprint hiện tại là sprint 14") — memory không phải nơi track state runtime, hãy dùng nó cho tri thức tương đối ổn định.
• Ý kiến, giả định chưa được xác nhận — nếu lưu, phải ghi rõ đó là giả định ("cần xác minh") để tránh agent coi là fact tuyệt đối.

Mẹo: Đặt quy tắc đơn giản cho team: "chỉ lưu vào memory những gì bạn sẵn sàng nói trước cả team và sẽ còn đúng sau 3 tháng nữa". Bất cứ điều gì không qua được bài test này thì không nên vào knowledge graph.

Mẹo Hay Khi Sử Dụng Memory MCP

Trước khi chuyển sang các bài hướng dẫn cấu hình cụ thể cho từng công cụ (Claude Code, OpenCode, Gemini CLI, Cursor), hãy note lại vài nguyên tắc vận hành then chốt:

• Định kỳ (hàng tuần hoặc hàng sprint) yêu cầu agent read_graph toàn bộ và tự rà soát observation nào đã lỗi thời để delete_observations — coi đây như "dọn nhà" bắt buộc, không phải việc tuỳ chọn.
• Đặt entityType nhất quán ngay từ đầu (decision, convention, person, component...) — một taxonomy rõ ràng giúp search_nodes trả kết quả chính xác hơn nhiều so với entity đặt tên tuỳ hứng.
• Với team nhiều người, review file memory trong code review như review bất kỳ artifact quan trọng khác — đừng để nó âm thầm phình to không kiểm soát.
• Backup file memory trước khi để agent thực hiện các thao tác xoá hàng loạt — một lệnh delete_entities sai phạm vi có thể xoá sạch kiến thức tích lũy nhiều tháng.

Mẹo: Nếu bạn quản lý nhiều dự án song song, hãy đặt tên file memory theo pattern rõ ràng như <project-slug>.memory.jsonl và luôn kiểm tra lại giá trị MEMORY_FILE_PATH mỗi khi chuyển context — nhầm path là lỗi phổ biến nhất khi mới bắt đầu dùng Memory MCP.