Tại sao lập trình viên vứt bỏ MCP để chọn CLI? Xu hướng công cụ AI mới nhất
Chào mọi người, dạo gần đây khi lập trình AI Agent, các bạn có sử dụng "MCP (Model Context Protocol)" không? Khoảng một năm qua, MCP từng được tung hô như "HTTP của kỷ nguyên AI!". Bản thân tôi ban đầu cũng rất phấn khích cắm đầu vào triển khai với suy nghĩ: "Từ nay AI có thể sử dụng hàng loạt công cụ một cách có cấu trúc rồi!". Nhưng khi thực sự đưa vào chạy thực tế, tôi bắt đầu cảm nhận một sự "cấn" nhẹ, cảm giác như mình đang lún vào một cái đầm lầy phức tạp. Và gần đây, khi dạo quanh các cộng đồng lập trình viên quốc tế, tôi nhận ra một làn sóng hoàn toàn ngược lại đang hình thành.
Đúng vậy, đó là hướng tiếp cận: "Giảm thiểu việc sử dụng MCP, cho phép các Agent gõ trực tiếp các lệnh CLI (Command Line Interface)". Một kỹ sư tên Eric Holmes đã đăng một bài blog có tựa đề (MCP is dead. Long live the CLI.) với một câu chốt cực gắt mang tính biểu tượng cho xu hướng này:
"MCP is dead. Long live the CLI." (MCP đã chết. CLI muôn năm)
Thoạt nghe qua, câu này giống như một kiểu giật tít câu view ngược dòng, nhưng nếu áp nó vào môi trường phát triển (development) thực tế, đây hoàn toàn không phải là chuyện nói quá. Lần này, tôi muốn lạm bàn một chút về lý do thực chất đằng sau việc vì sao ngay lúc này, "CLI-first" (Ưu tiên CLI) lại lên ngôi.
Tư duy thiết kế của MCP vốn dĩ rất hoàn hảo
Nói đi cũng phải nói lại để tránh hiểu lầm, ý tưởng cốt lõi của MCP thực sự có lý.
- Định nghĩa các chức năng bên ngoài như các Tool.
- Mô tả các tham số của Tool bằng Schema.
- Agent load các Tool này dưới dạng Context (ngữ cảnh).
- Agent gọi các công cụ này để thực thi nhiệm vụ.
Cách tiếp cận này mang lại lợi ích khổng lồ: cấu trúc rõ ràng, tính mở rộng cao và giao diện được tiêu chuẩn hóa. Nếu vẽ sơ đồ kiến trúc ra, nó sẽ trông "đẹp không tì vết".
Nhưng than ôi, lý thuyết và thực tế lập trình phần mềm luôn là hai thế giới khác nhau.
"3 cái bẫy của MCP" chực chờ trong thực tế
Khi cố gò ép MCP vào workflow thường ngày, nó phát sinh những khoản "nợ kỹ thuật" ngoài dự tính. Cụ thể có 3 vấn đề lớn:
1. Hao hụt Token (Overhead) tới mức bực mình
Với MCP, để Model hiểu được Tool, bạn phải đút cho nó "Schema + Đoạn mô tả". Sẽ ra sao nếu Agent kết nối đến nhiều máy chủ MCP cùng lúc?
- Tên của công cụ
- Mô tả chi tiết chức năng
- Cấu trúc JSON của tham số
Tất tần tật những thứ này sẽ chiếm dụng dã man bộ nhớ Context (Context Window). Thử lấy ví dụ: bạn có 10 dịch vụ MCP, mỗi dịch vụ cung cấp 5 công cụ. Trước khi Agent kịp làm bất cứ một công việc thực tế nào trót lọt, hàng nghìn Token đã "bốc hơi" chỉ để đọc mô tả công cụ. Với những task cần chuỗi suy luận dài (long-chain reasoning), việc Overhead cỡ này là thứ không thể nhắm mắt làm ngơ cả về chi phí lẫn hiệu năng.
2. Nỗi khổ "Phát minh lại bánh xe"
Nói trắng ra, rất nhiều MCP Server hiện tại chẳng khác gì một cái Wrapper (lớp bọc) vô hồn.
- Thao tác GitHub
- Quản lý Docker
- Phân tích log
- Trigger CI/CD
- Quản lý tài nguyên đám mây (Cloud)
Nhìn kìa, để làm mấy việc này, chúng ta đã có sẵn vô số CLI tool cực xịn mà anh em dev ngày nào chả gõ rào rào.
Ví dụ như git, gh, docker, kubectl, aws, curl v.v.
Thế nhưng, nếu cố đấm ăn xôi dùng MCP, mọi thứ sẽ biến thành một hệ thống cồng kềnh như sau:
CLI -> API -> MCP Server -> Agent
Mỗi lần đẻ thêm một Layer, độ phức tạp trong bảo trì sẽ tăng vọt. Dùng để làm gì khi nó chỉ khiến mọi việc rườm rà hơn?
3. Phá vỡ Pipeline của Unix
Với cá nhân tôi, đây là điểm gây lấn cấn nhất. Trái tim của triết lý Unix là: "Make small tools that work together" (Tạo ra các công cụ nhỏ gọn, làm tốt một việc và kết hợp chúng lại).
Linh hồn của CLI nằm ở đặc tính Composability (Khả năng lắp ghép/Kết hợp) qua các 파이프라인 (Pipeline) giữa những grep, jq, awk, rg, tail...
# Workflow kinh điển mà dev nào cũng xài
tail -f logs/server.log | grep error | jq .
Sức mạnh luân chuyển dữ liệu linh hoạt, thứ vốn là chuyện cơm bữa trong dev hằng ngày lại bị băm nát thành "các cuộc gọi hàm đơn lẻ, rời rạc" nếu dùng MCP. Đánh đổi sự linh hoạt vô giá lấy cấu trúc cứng nhắc, thật sự quá lãng phí.
Tại sao CLI lại là thứ "tự nhiên" nhất với AI Agent?
Hãy chậm lại một nhịp và quay về nguyên thủy. Các Model LLM hiện đại giỏi dùng CLI một cách đáng sợ.
Lý do cực kỳ đơn giản: trong bụng chúng chứa hàng chục triệu cục Data về các kho lưu trữ GitHub, Bash config, tài liệu DevOps, file cấu hình CI/CD và hàng triệu câu hỏi đáp trên... Stack Overflow.
Các Model hiểu rõ những thứ sau đây rõ như lòng bàn tay:
- Các cờ (flags/options)
- Xử lý 파이프 (pipes)
- Bắt lỗi bash shell
- Đọc tài liệu (man page)
Khi bạn cấp quyền thực thi Shell cho Agent, nó sẽ tự tung tự tác một cách mượt mà đến bất ngờ. Tìm kiếm code, sửa file trực tiếp, chạy test, dò lỗi debug, rồi tự tạo commit. Cả một vòng lặp vĩ đại này gói trọn "chỉ trong một màn hình Terminal".
"Tính tái lập" - Tuyệt chiêu đẩy nhanh Debug
CLI còn sở hữu một năng lực tối thượng đè bẹp MCP: Tính tái lập (Reproducibility).
Giả sử Agent đang gõ lệnh dưới đây và bị ăn báo lỗi:
kubectl get pods
Chúng ta - những con người bằng xương bằng thịt - chỉ cần chép nguyên câu lệnh đó vứt vào Terminal là bắt được ngay 100% bệnh tình thực tại của AI. Nó trực diện đến vậy đấy.
Còn nếu crash trong lúc gọi MCP thì sao? Ngồi hì hục đọc JSON Payload, bới tung log tìm trace, check coi server MCP sập hay chưa... Hệ thống càng phức tạp, quỹ thời gian của bạn nướng vào việc tìm nguyên nhân càng kinh hãi.
Xu hướng dạt về "Agent với CLI-First"
Nếu chịu khó quan sát các AI coding tool ra mắt dạo gần đây, bạn sẽ thấy rõ bánh lái đang bẻ quặt sang các thiết kế CLI-first.
- Claude Code
- Codex CLI
- Gemini CLI
Điểm chung của tụi này hiển nhiên rành rành:
- Chạy thẳng trên Terminal.
- Mở khóa cho Agent được quẩy Shell command.
- Can thiệp trực tiếp vào File System trên máy local.
- Tái sử dụng trọn vẹn mọi Tool Chain của hệ sinh thái Dev cũ.
Điều đó có nghĩa là: "Chẳng việc gì phải vẽ ra thêm một hệ sinh thái Tool mới tinh cho Agent cả". Tại sao không mài giũa những món vũ khí sắt đá mà loài người đã tôi luyện hằng thập kỷ và đưa cho chúng múa?
Workflow kinh điển của CLI Agent
Ví dụ cho tác vụ Refactor code diện rộng:
rg "oldDeprecatedFunction" .
git diff
npm test
git commit
Điều tra và Fix bug trên Production:
tail -f logs/server.log
grep error
curl -v api/auth/check
docker-compose up
Quay mới một dịch vụ API từ con số 0:
cargo new my_api
cargo add axum sqlx
cargo watch
curl localhost:3000/health
Chẳng cần giao thức Protocol mới nào, máy chủ nào hay những bộ trừu tượng rắc rối nào. Cứ vơ lấy những CLI sờ sờ ngay trước mắt mà nã lệnh. Simple is best! (Đơn giản là nhất!).
Nhưng khoan, MCP vẫn có lúc tỏa sáng chứ?
Đừng vội ném đá, bài viết này không hề có ý xui bạn "ném MCP vào sọt rác". Chọn đúng công cụ cho từng bối cảnh, MCP vẫn là ông hoàng không bàn cãi trong những case sau:
- Tích hợp chéo qua lại các hệ thống SaaS doanh nghiệp khổng lồ.
- Các thao tác gọi API cực căng về an toàn kiểu dữ liệu (Type-safe).
- Hệ thống rào bằng các luật bảo mật, giới hạn truy cập gắt gao.
- Phần mềm ứng dụng dành cho bà nội trợ, người già - không phải cho vọc sĩ.
Ở những vũng nước sâu này, các protocol được rèn cấu trúc sắt thép là luật chơi sống còn. Tuy nhiên, nếu gói gọn trong môi trường "Vòng lặp Code của lập trình viên" hằng ngày, CLI vẫn đỉnh chóp.
Tóm gọn lại: AI vừa "Khai quật" lại Terminal
Vài năm qua, ta hay bị ảo lý trí: "AI xịn sò thì đòi hỏi protocol cũng phải tối thượng ngầu lòi". Thực tiễn chứng minh điều ngược lại hoàn toàn.
Công nghệ AI không hề "phát minh" ra một trật tự Development mới. Lẳng lặng mà nói, nó chỉ đang phủi bụi và phát hiện lại giá trị bất diệt của một cỗ máy đã nằm đó hàng thập kỷ: "Chiếc Terminal mộc mạc".
Dễ bắt cặp xâu chuỗi, xắn tay áo lên là debug được ngay, ai cũng chạy lại y xì được, và khả năng mở rộng vô hạn. Đi một vòng trái đất, hóa ra thanh gươm bén nhất luôn nằm ngay ngắn bên hông các coder.
Trong dự án hiện tại của đội bạn, MCP hay CLI đang nắm trùm? Bạn đang xài Stack gì hay có cấn chỗ nào khi build AI Agent không, lôi ra mổ xẻ tí nhỉ! Để lại vài lời ở khung bình luận bên dưới nhé, tôi đứng đây đợi anh em thảo luận cho xôm!
Link tham khảo:
All Rights Reserved
