Memory MCP với Gemini CLI

Gemini CLI của Google là một agentic coding tool chạy trong terminal, hỗ trợ MCP từ khá sớm và có điểm đặc biệt là vốn đã có sẵn một cơ chế "memory" đơn giản riêng của nó (lệnh /memory add, lưu vào file GEMINI.md). Điều này khiến nhiều người nhầm rằng không cần Memory MCP nữa — thực tế hai cơ chế phục vụ mục đích khác nhau, và bài này sẽ chỉ rõ ranh giới đó. Chúng ta sẽ đi qua cách cài Memory MCP cho Gemini CLI, cách capture quyết định và constraint kỹ thuật thành memory có thể truy xuất, một ví dụ xây dựng knowledge base cho cả team, và so sánh hành vi thực tế của Memory MCP giữa Gemini CLI và Claude Code — vì hai công cụ này xử lý tool-calling cho memory không hoàn toàn giống nhau.

Cài Đặt Và Kết Nối Memory MCP Với Gemini CLI

Gemini CLI đọc cấu hình MCP server từ file settings.json, có thể đặt ở phạm vi user (~/.gemini/settings.json) hoặc phạm vi project (.gemini/settings.json trong root repo). Thêm Memory MCP ở phạm vi project để mỗi dự án có graph riêng:

{
  "mcpServers": {
    "memory": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-memory"],
      "env": {
        "MEMORY_FILE_PATH": ".gemini/memory.jsonl"
      },
      "trust": true
    }
  }
}

Trường trust: true giúp Gemini CLI không hỏi xác nhận mỗi lần agent gọi tool của server này — hợp lý với một server chỉ đọc/ghi memory nội bộ, không có tác động phá hoại như chạy shell command tuỳ ý. Sau khi lưu file, khởi động lại Gemini CLI và kiểm tra bằng lệnh trong phiên chat:

/mcp list

Kết quả phải hiện memory với trạng thái kết nối thành công, kèm danh sách tool khả dụng (create_entities, search_nodes,...). Nếu server không lên, kiểm tra log bằng cách chạy Gemini CLI với --debug, thường lỗi hay gặp là do Node.js version quá cũ (Memory MCP yêu cầu Node 18+) hoặc thư mục .gemini/ chưa tồn tại nên không tạo được file memory.

Mẹo: Nếu bạn từng dùng lệnh /memory add gốc của Gemini CLI trước khi cài Memory MCP, đừng xoá dữ liệu cũ trong GEMINI.md ngay — hãy đọc lại và cân nhắc cái nào nên giữ nguyên trong GEMINI.md (rule cố định) và cái nào nên chuyển sang Memory MCP (kiến thức phát sinh dần) trước khi dọn dẹp, tránh mất thông tin.

Ghi Lại Quyết Định Và Constraint Kỹ Thuật Thành Memory Có Thể Truy Xuất

Điểm mạnh của việc dùng Memory MCP thay vì chỉ ghi chú tự do là mọi quyết định (decision) và ràng buộc kỹ thuật (constraint) được cấu trúc thành entity có thể truy vấn chính xác, không phải "chìm" trong một file text dài. Ví dụ khi team quyết định một constraint quan trọng về rate limit:

Ghi vào memory: API public của chúng ta giới hạn 100 request/phút cho mỗi
API key, áp dụng từ Q3 vì có khách hàng từng gây quá tải downstream service
thanh toán. Tạo entity "constraint-api-rate-limit" (entityType: "constraint"),
và tạo relation "constrains" tới entity component "component-public-api".

Agent thực hiện gọi tool tương ứng:

{
  "tool": "create_entities",
  "arguments": {
    "entities": [
      {
        "name": "constraint-api-rate-limit",
        "entityType": "constraint",
        "observations": [
          "Giới hạn 100 request/phút mỗi API key, áp dụng từ Q3 do sự cố quá tải downstream payment service."
        ]
      }
    ]
  }
}

theo sau bởi:

{
  "tool": "create_relations",
  "arguments": {
    "relations": [
      {
        "from": "constraint-api-rate-limit",
        "to": "component-public-api",
        "relationType": "constrains"
      }
    ]
  }
}

Vài tuần sau, khi bạn yêu cầu agent implement thêm một endpoint mới trong public API, chỉ cần hỏi:

Trước khi thêm endpoint mới vào public API, kiểm tra memory xem có constraint
nào cần tuân thủ không.

Agent gọi search_nodes với "public-api" hoặc "component-public-api", tìm ra relation constrains và observation rate-limit liên quan, từ đó tự động nhắc bạn áp dụng đúng rate-limit 100 req/phút cho endpoint mới — không cần bạn phải nhớ và nhắc lại thủ công.

Mẹo: Khi ghi constraint, luôn kèm lý do ("vì sao") trong observation, không chỉ ghi con số. Một constraint không có lý do rất dễ bị agent (hoặc đồng nghiệp) đề xuất bỏ đi trong tương lai vì không hiểu vì sao nó tồn tại.

Ví Dụ Thực Tế: Xây Dựng Knowledge Base Của Team Mà Agent Có Thể Query

Với team scope, giá trị lớn nhất của Memory MCP là biến kiến thức rải rác trong đầu từng người (và trong các cuộc họp không ai ghi lại) thành một graph mà mọi agent của mọi thành viên đều truy vấn được — miễn là mọi người cùng trỏ vào một MEMORY_FILE_PATH chung (thường đặt trên một shared drive hoặc sync qua Git repo riêng cho memory).

Quy trình thực tế cho một team 5 người dùng Gemini CLI:

1. Tạo repo riêng (hoặc thư mục con trong monorepo) team-memory/, chứa file memory.jsonl, mọi máy trỏ MEMORY_FILE_PATH vào bản clone local của repo này.
2. Sau mỗi buổi standup hoặc technical discussion, một người được phân công chạy prompt tổng hợp:

Tổng hợp các quyết định từ cuộc họp technical hôm nay và ghi vào memory:
1. Quyết định dùng gRPC thay REST cho giao tiếp nội bộ giữa order-service và
   inventory-service, lý do cần streaming và giảm overhead serialize JSON.
2. Constraint: schema proto phải backward-compatible, không được xoá field
   đã publish, chỉ được deprecate.
Tạo entity tương ứng và relation "affects" tới các component liên quan.

1. Định kỳ commit và push memory.jsonl lên repo chung — vì file là JSON Lines, git diff theo dòng khá dễ review trong PR, giống như review một changelog.
2. Các thành viên khác định kỳ git pull để đồng bộ graph mới nhất trước khi bắt đầu ngày làm việc.

Với setup này, một kỹ sư mới join team có thể hỏi ngay trong Gemini CLI:

Đọc toàn bộ memory và cho tôi biết những quyết định kiến trúc quan trọng
nhất của hệ thống này, sắp xếp theo component.

Agent gọi read_graph, tổng hợp lại toàn bộ decision, constraint, gotcha theo cấu trúc — tương đương việc đọc một tài liệu onboarding được cập nhật tự động, thay vì một wiki thường bị bỏ quên không update.

Mẹo: Phân công rõ một người "memory owner" mỗi sprint chịu trách nhiệm tổng hợp và ghi lại quyết định — nếu để "ai cũng có thể ghi, không ai chịu trách nhiệm", memory sẽ nhanh chóng thiếu sót hoặc trùng lặp giống mọi tài liệu chung không có chủ.

So Sánh Hành Vi Của Memory MCP Giữa Gemini CLI Và Claude Code

Dù cùng dùng chung một Memory MCP server bên dưới, hành vi thực tế khi sử dụng qua hai công cụ khác nhau đáng kể, chủ yếu vì khác model nền và khác cách agent loop được thiết kế:

Điểm cần lưu ý nhất trong thực tế: nếu bạn cấu hình Gemini CLI dùng model tier thấp hơn (ví dụ Gemini Flash) để tiết kiệm chi phí, khả năng agent tự quyết định "lúc nào nên query memory" sẽ kém nhất quán hơn so với model tier cao. Với các task quan trọng liên quan nhiều tới lịch sử quyết định, nên cân nhắc chuyển tạm sang model tier cao hơn, hoặc ép rule tường minh trong GEMINI.md để bù lại.

Mẹo: Nếu đang dùng Gemini CLI với model Flash để tiết kiệm, thêm dòng rule tường minh vào GEMINI.md: "LUÔN gọi search_nodes trước khi trả lời bất kỳ câu hỏi liên quan tới lịch sử quyết định kỹ thuật" — bù lại phần chủ động mà model tier thấp có thể thiếu.

Mẹo Hay Khi Dùng Memory MCP Với Gemini CLI

• Tách rõ vai trò GEMINI.md (rule cố định, luôn nạp) và Memory MCP (kiến thức tra cứu theo nhu cầu) ngay từ đầu, đừng để cả hai cùng chứa nội dung trùng lặp.
• Với team dùng chung memory qua Git, luôn review file .jsonl trong PR như review changelog — đừng merge mù.
• Kiểm tra định kỳ model tier đang dùng có ảnh hưởng tới hành vi tool-calling của memory hay không, đặc biệt sau khi đổi model để tối ưu chi phí.

Mẹo: Viết một checklist ngắn trong GEMINI.md liệt kê chính xác khi nào agent PHẢI query memory (ví dụ: trước khi sửa API public, trước khi thay đổi schema database) — checklist tường minh luôn đáng tin hơn việc kỳ vọng model "tự hiểu" khi nào cần nhớ lại.