·

Sequential Thinking MCP với Gemini CLI

Cài đặt Sequential Thinking MCP trong Gemini CLI để AI agent có thể chia nhỏ vấn đề phức tạp thành các bước suy luận có cấu trúc ngay trong trình soạn thảo.

Gemini CLI là agentic coding CLI mã nguồn mở của Google, chạy model Gemini (mặc định Gemini 2.5 Pro/Flash tuỳ config) và hỗ trợ MCP qua file settings.json. Vì Gemini có context window (cửa sổ ngữ cảnh) rất lớn theo thiết kế, nhiều engineer có xu hướng nhồi toàn bộ context vào một prompt và bỏ qua structured reasoning — đây là sai lầm phổ biến, vì context lớn giúp model đọc được nhiều thông tin hơn, không đồng nghĩa nó suy luận có tổ chức hơn. Bài này hướng dẫn cài Sequential Thinking MCP cho Gemini CLI, cách dùng nó để dẫn dắt phân tích trade-off nhiều bước, một ví dụ chọn kiến trúc, và so sánh chất lượng suy luận với Claude Code.

Cài Đặt và Kết Nối Sequential Thinking MCP Vào Gemini CLI

Gemini CLI đọc cấu hình MCP từ ~/.gemini/settings.json (global) hoặc .gemini/settings.json ở root project (scope theo project, ưu tiên hơn global khi trùng key). Thêm server dưới key mcpServers, cùng format với Claude Desktop:

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
    }
  }
}

Ngoài sửa file tay, Gemini CLI cũng hỗ trợ lệnh CLI để thêm server nhanh:

gemini mcp add sequential-thinking npx -y @modelcontextprotocol/server-sequential-thinking

Kiểm tra trạng thái kết nối trong session Gemini CLI bằng lệnh nội bộ:

/mcp

Lệnh này in ra danh sách server, trạng thái (connected/disconnected/error) và số tool mỗi server expose ra. Với Sequential Thinking, bạn sẽ thấy đúng 1 tool duy nhất: sequentialthinking.

Nếu Gemini CLI báo tool bị "auto-approve" cần xác nhận mỗi lần gọi (do cơ chế tool confirmation mặc định), bạn có thể whitelist trước để tránh bị hỏi liên tục trong một session phân tích dài — thêm vào settings.json:

{
  "mcpServers": {
    "sequential-thinking": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"],
      "trust": true
    }
  }
}

trust: true bỏ qua bước confirm cho riêng server này — chấp nhận được vì Sequential Thinking chỉ ghi state trong memory, không đọc/sửa file hệ thống hay gọi network, nên rủi ro an toàn gần như không có.

Mẹo: Chỉ set trust: true cho các MCP server không có side-effect thật (không sửa file, không gọi API ngoài) như Sequential Thinking. Với server có quyền ghi file hay gọi network, giữ nguyên cơ chế confirmation để tránh agent thực thi hành động ngoài ý muốn mà bạn không kịp review.

Điều Khiển Phân Tích Nhiều Bước và Đánh Giá Trade-off Trong Gemini CLI

Gemini CLI có xu hướng tận dụng context window lớn để "đọc hết" trước khi trả lời — điều này tốt cho việc thu thập thông tin, nhưng không tự động tạo ra so sánh trade-off có cấu trúc. Muốn ép ra so sánh rõ ràng, cần prompt kết hợp với yêu cầu dùng sequential thinking:

Đọc toàn bộ module payment/ (đã có trong context). Dùng sequential thinking
để đánh giá: có nên chuyển từ đồng bộ gọi trực tiếp Stripe API sang mô hình
async qua queue (SQS) không? Đánh giá theo: độ trễ trải nghiệm người dùng,
độ phức tạp xử lý lỗi/retry, khả năng audit giao dịch, và chi phí vận hành thêm.
Sau mỗi tiêu chí, chấm điểm 1-5 cho từng hướng trước khi đưa ra khuyến nghị.

Yêu cầu "chấm điểm 1-5 cho từng tiêu chí" là một kỹ thuật hiệu quả: nó buộc model phải tạo ra các thought có cấu trúc định lượng (không chỉ mô tả chung chung), giúp chuỗi suy luận sau này dễ audit và dễ so sánh giữa các lựa chọn thay vì chỉ đọc văn xuôi mơ hồ.

Mẹo: Với các quyết định có nhiều tiêu chí, luôn yêu cầu model tạo ra một "scoring rubric" (thang chấm điểm) tường minh ngay ở thought đầu tiên trước khi chấm — tránh tình trạng model chấm điểm cảm tính không nhất quán giữa các phương án khi so sánh ở các thought sau.

Ví Dụ Thực Tế: Chọn Architecture Bằng Các Bước Suy Luận Rõ Ràng

Bài toán: team cần chọn giữa 2 hướng cho tính năng search full-text mới — dùng Postgres tsvector/GIN index có sẵn, hay thêm Elasticsearch như một service riêng. Traffic hiện tại ~500 query/s vào giờ cao điểm, dataset ~5 triệu document, team chỉ có 2 backend engineer không có kinh nghiệm vận hành Elasticsearch trước đó.

Prompt:

Dùng sequential thinking để quyết định giữa Postgres full-text search (tsvector + GIN)
và Elasticsearch cho tính năng search mới. Bối cảnh: 500 query/s peak, 5M document,
team chỉ có 2 backend engineer chưa vận hành Elasticsearch. Đánh giá theo: hiệu năng
đáp ứng traffic hiện tại, chi phí vận hành/học tập, khả năng mở rộng 2 năm tới,
và độ phức tạp tích hợp với hệ thống hiện có.

Chuỗi thought thực tế thường đi theo hướng cân nhắc rất cụ thể tới ràng buộc nhân sự — điểm khác biệt lớn so với hỏi trực tiếp "Postgres hay Elasticsearch cho search":

{"thought": "Với 500 query/s và 5M document, Postgres GIN index trên tsvector hoàn toàn đáp ứng được về hiệu năng thô — đây không phải điểm nghẽn quyết định.", "thoughtNumber": 2, "totalThoughts": 6, "nextThoughtNeeded": true}

{"thought": "Yếu tố quyết định thực ra là vận hành: Elasticsearch cần thêm cluster riêng, kiến thức về shard/replica, mapping, và một engineer để bảo trì — với team 2 người chưa có kinh nghiệm, đây là chi phí ẩn lớn hơn lợi ích hiệu năng chưa cần dùng tới.", "thoughtNumber": 3, "totalThoughts": 6, "nextThoughtNeeded": true}

{"thought": "Khuyến nghị: dùng Postgres tsvector trước, thiết kế query layer qua một interface trừu tượng để có thể chuyển sang Elasticsearch sau nếu traffic vượt ngưỡng ~5000 query/s hoặc dataset vượt 50M document mà không cần đổi lại toàn bộ tầng gọi search.", "thoughtNumber": 5, "totalThoughts": 6, "nextThoughtNeeded": true}

Đây là ví dụ điển hình cho giá trị thực sự của Sequential Thinking: quyết định cuối không chỉ dựa trên "công nghệ nào mạnh hơn" mà tính đến ràng buộc con người/vận hành — thứ dễ bị bỏ qua nếu chỉ hỏi một câu ngắn.

Mẹo: Luôn đưa ràng buộc về con người/team (số engineer, kinh nghiệm sẵn có, khả năng on-call) vào prompt khi hỏi quyết định kiến trúc — đây là loại thông tin model không thể tự suy ra, và thiếu nó thường dẫn tới khuyến nghị "đúng về kỹ thuật nhưng sai về thực tế".

So Sánh Chất Lượng Suy Luận Giữa Gemini CLI và Claude Code

Qua thực tế dùng cả hai với cùng Sequential Thinking MCP cho các task tương tự, một số khác biệt đáng chú ý:

  • Độ dài thought: Gemini CLI có xu hướng sinh thought dài hơn, đôi khi lặp lại thông tin đã có trong context trước khi đi tới kết luận mới — hệ quả của việc model được train để tận dụng context lớn. Claude Code (dùng model Claude) thường sinh thought ngắn gọn, súc tích hơn cho cùng độ sâu lập luận.
  • Xu hướng dừng đúng lúc: Claude có xu hướng đặt nextThoughtNeeded: false sớm hơn khi đã đủ thông tin để kết luận, trong khi Gemini đôi khi kéo dài thêm 1-2 bước "double-check" không thực sự cần thiết nếu không giới hạn rõ totalThoughts mong muốn trong prompt.
  • Chất lượng revision: cả hai đều dùng isRevision đúng cách khi phát hiện mâu thuẫn, nhưng Claude Code thường nêu rõ hơn lý do cụ thể dẫn tới revision (trích dẫn lại thông tin gây mâu thuẫn), còn Gemini đôi khi chỉ nói "cần xem lại bước trước" mà không trích rõ nguyên nhân — bạn nên yêu cầu tường minh "khi revise, nêu rõ thông tin nào khiến bạn đổi ý" để cải thiện việc này.
  • Tốc độ round-trip: phụ thuộc nhiều vào tier API đang dùng hơn là bản chất model, nên không có kết luận cố định — nhưng vì mỗi thought là một round-trip riêng, sự khác biệt latency giữa 2 CLI sẽ lộ rõ hơn khi chuỗi thought dài (6-8 bước trở lên).

Kết luận thực dụng: không có CLI nào "thắng tuyệt đối" cho Sequential Thinking — chọn theo model bạn đang có license/quota, nhưng nếu dùng Gemini CLI, nên set giới hạn totalThoughts rõ trong prompt để tránh chuỗi thought bị kéo dài không cần thiết.

Mẹo: Khi so sánh chất lượng giữa 2 agent cho cùng một quyết định quan trọng, chạy song song cả 2 với cùng prompt Sequential Thinking, rồi đưa cả 2 bản tóm tắt kết luận cho một người review độc lập chấm — cách này khách quan hơn nhiều so với tự cảm nhận "cái nào nghe hay hơn".

Tiếp Sequential Thinking MCP với Cursor