·

Sequential Thinking MCP với Claude Code CLI and VS Code

Cài đặt Sequential Thinking MCP trong Claude Code CLI and VS Code để 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.

Claude Code — CLI agentic coding (viết code có agent hỗ trợ) chính thức của Anthropic — hỗ trợ MCP (Model Context Protocol) như một first-class citizen, cả khi chạy độc lập trên terminal và khi nhúng vào VS Code qua extension. Bài này hướng dẫn cài Sequential Thinking MCP vào cả hai môi trường, rồi đi sâu vào cách dùng nó để phân rã một refactor lớn thành các bước có thể kiểm chứng từng phần, thay vì để agent "đập một phát" toàn bộ codebase.

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

Claude Code cung cấp lệnh claude mcp add để đăng ký MCP server mà không cần sửa tay file JSON. Cách nhanh nhất:

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

Dấu -- ngăn cách tên server và command thực thi — phần sau -- chính là command + args mà Claude Code sẽ spawn làm subprocess giao tiếp qua stdio (transport mặc định cho local MCP server). Sau khi add, kiểm tra lại:

claude mcp list
claude mcp get sequential-thinking

Claude Code hỗ trợ 3 scope khi add server: --scope local (chỉ máy bạn, mặc định), --scope project (ghi vào file .mcp.json ở root repo, share cho cả team qua git), --scope user (dùng chung cho mọi project của riêng bạn). Với team dev, khuyến nghị dùng scope project để đảm bảo mọi người cùng có tool này khi checkout repo:

claude mcp add sequential-thinking --scope project -- npx -y @modelcontextprotocol/server-sequential-thinking

Lệnh trên tạo/cập nhật file .mcp.json ở root:

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

Với VS Code (dùng extension Claude Code chính thức), nếu bạn đã add server ở scope user hoặc project từ CLI, extension sẽ tự nhận diện vì nó dùng chung config với Claude Code CLI — không cần setup riêng. Trong panel chat của extension, gõ /mcp để xem danh sách server đang kết nối và trạng thái (connected/failed) — rất hữu ích để debug nhanh khi server không khởi động được (thường do thiếu Node.js trong PATH mà VS Code đang dùng).

Mẹo: Nếu VS Code báo server "failed to connect" nhưng CLI chạy được, khả năng cao VS Code đang dùng một PATH khác (đặc biệt trên macOS khi mở app từ Finder/Dock, không load .zshrc). Mở VS Code từ terminal (code .) sau khi đã source shell profile để đảm bảo cùng PATH.

Phân Rã Một Refactor Lớn Thành Các Bước Suy Luận Có Thể Kiểm Chứng

Giả sử bài toán: tách một module OrderService đang xử lý cả validation, pricing, và inventory reservation thành 3 service riêng, giữ nguyên hành vi (behavior-preserving refactor), trong một codebase có ~40 file phụ thuộc trực tiếp vào OrderService. Prompt trực tiếp kiểu "hãy tách OrderService ra 3 service" gần như chắc chắn khiến agent sửa sai thứ tự, quên update một import, hoặc phá vỡ test.

Ví dụ prompt kích hoạt Sequential Thinking đúng cách:

Tôi cần tách OrderService (src/services/order_service.py) thành 3 service:
ValidationService, PricingService, InventoryReservationService.
Hãy dùng sequential thinking để lập plan an toàn trước khi sửa code:
- Liệt kê toàn bộ điểm gọi vào OrderService hiện tại (dùng grep/code search).
- Xác định thứ tự tách an toàn nhất để mỗi commit vẫn giữ test pass.
- Với mỗi bước, nêu rõ file nào bị đổi và rủi ro gãy chỗ nào.
Sau khi có plan, dừng lại và cho tôi review trước khi bắt đầu sửa code.

Trong quá trình xử lý, agent sẽ gọi tool sequentialthinking nhiều lần, ví dụ luồng thought thực tế thường trông như:

{"thought": "Bước 1: cần grep toàn bộ import OrderService và các nơi gọi trực tiếp method của nó trước khi quyết định thứ tự tách.", "thoughtNumber": 1, "totalThoughts": 6, "nextThoughtNeeded": true}

{"thought": "Có 3 nhóm caller: API layer (12 file), background job (5 file), test (23 file). Nên tách PricingService trước vì nó có ít side-effect nhất và không phụ thuộc state của 2 service còn lại.", "thoughtNumber": 2, "totalThoughts": 6, "nextThoughtNeeded": true}

Điểm mạnh của cách làm này: bạn có thể yêu cầu Claude Code dừng lại sau bước lập plan (như trong prompt mẫu ở trên), đọc toàn bộ chuỗi thought, và chỉ approve khi thấy thứ tự hợp lý — thay vì phát hiện agent làm sai sau khi đã sửa 15 file.

Mẹo: Luôn thêm câu "dừng lại và cho tôi review trước khi sửa code" vào prompt khi làm refactor rủi ro cao. Sequential Thinking giúp lập plan tốt hơn, nhưng không tự động nghĩa là plan đó đúng — review của con người vẫn là bước bắt buộc trước khi apply lên codebase thật.

Dùng Revision và Branching Để Sửa Một Nhánh Suy Luận Sai

Tình huống thực tế: ở thought số 2, agent giả định PricingService không phụ thuộc state — nhưng tới thought số 4, khi đọc code chi tiết hơn, phát hiện PricingService thực ra có đọc self.discount_cache được set trong InventoryReservationService. Đây chính là lúc field isRevision phát huy tác dụng:

{
  "thought": "Phát hiện PricingService thực ra đọc discount_cache do InventoryReservationService set — giả định ở bước 2 sai. Cần revise: tách InventoryReservationService trước, expose discount_cache qua interface rõ ràng, rồi mới tách PricingService.",
  "thoughtNumber": 5,
  "totalThoughts": 7,
  "nextThoughtNeeded": true,
  "isRevision": true,
  "revisesThought": 2
}

Khác với việc bắt agent "làm lại từ đầu", revision giữ nguyên các thought đúng trước đó (ví dụ việc grep caller ở bước 1 vẫn còn giá trị), chỉ sửa lại phần kết luận sai — giúp chuỗi lập luận đọc lại vẫn mạch lạc và tiết kiệm token so với reset toàn bộ.

Với các trường hợp cần so sánh song song 2 hướng thay vì sửa hẳn một hướng, dùng branching:

{
  "thought": "Nhánh A: tách theo thứ tự Inventory -> Pricing -> Validation, ưu tiên an toàn nhưng cần 3 PR riêng.",
  "thoughtNumber": 3,
  "totalThoughts": 8,
  "nextThoughtNeeded": true,
  "branchFromThought": 2,
  "branchId": "order-by-inventory-first"
}

{
  "thought": "Nhánh B: tách đồng thời cả 3 sau một bước introduce interface chung, rủi ro cao hơn nhưng gộp được 1 PR duy nhất.",
  "thoughtNumber": 3,
  "totalThoughts": 8,
  "nextThoughtNeeded": true,
  "branchFromThought": 2,
  "branchId": "all-at-once-with-interface"
}

Yêu cầu agent so sánh 2 branch bằng tiêu chí cụ thể (số PR, rủi ro rollback, thời gian review) trước khi chọn — đây chính là lúc structured reasoning tạo giá trị rõ ràng hơn hẳn một prompt đơn.

Mẹo: Khi thấy agent tạo nhiều branchId, hãy yêu cầu nó in ra một bảng so sánh ngắn (branch, ưu điểm, nhược điểm, khuyến nghị) ngay sau khi kết thúc chuỗi thought — đừng để bạn phải tự đọc lại từng thought để so sánh bằng tay.

Các Pattern Prompt Kích Hoạt Structured Thinking Reliably

Claude Code không tự động dùng Sequential Thinking cho mọi task — nó chỉ gọi tool này khi model tự đánh giá task đủ phức tạp, hoặc khi bạn yêu cầu rõ. Một số pattern prompt hiệu quả đã được kiểm chứng qua thực tế sử dụng:

  • Yêu cầu trực tiếp: "Dùng sequential thinking để lập plan trước khi sửa code" — cách chắc chắn nhất, nên dùng khi bạn biết trước task này rủi ro cao.
  • Đặt ràng buộc buộc phải cân nhắc trade-off: "Tôi cần chọn giữa 2 cách tiếp cận X và Y, hãy liệt kê rõ trade-off của từng cách trước khi quyết định" — câu này tự nhiên khiến model muốn dùng tool suy luận có cấu trúc dù không gọi tên tool.
  • Yêu cầu liệt kê unknown trước khi hành động: "Trước khi sửa, hãy liệt kê những điều bạn chưa chắc và cách xác minh từng điều đó" — pattern này đặc biệt hiệu quả cho debug.

Ngược lại, prompt càng ngắn, càng "ra lệnh hành động ngay" (ví dụ "sửa cái bug này đi") thường khiến agent bỏ qua Sequential Thinking và code trực tiếp — đúng với các task nhỏ, nhưng cần tránh với task lớn.

Mẹo: Nếu team bạn có một bộ custom slash command trong Claude Code (file trong .claude/commands/), hãy nhúng sẵn cụm "dùng sequential thinking trước khi sửa code, dừng lại chờ review" vào các command dùng cho refactor/migration — tránh việc mỗi engineer phải nhớ gõ tay mỗi lần.

Tiếp Sequential Thinking MCP với OpenCode