Chuyển tới nội dung chính

1MCP Agent: gom mọi MCP server về một cửa, và bớt ngốn context

· 10 phút để đọc
Nguyễn Huỳnh Minh Tiến
Fullstack Developer @ Utop.io
Tóm tắt

Dùng vài MCP server cho Claude Code, Cursor, Codex… thì sớm muộn bạn cũng phải khai báo lặp lại cùng một danh sách ở từng client, và mỗi server lại đổ toàn bộ schema tool vào context ngay khi phiên bắt đầu. 1MCP Agent (@1mcp/agent) là một proxy đứng giữa: bạn đăng ký các MCP server một lần, chạy 1mcp serve, rồi client nào cũng chỉ cần trỏ về một địa chỉ. Ngoài ra nó có chế độ CLI cho phép agent khám phá và gọi tool theo từng bước (instructions → inspect → run) để không phải nạp hết schema từ đầu.

Bài bắt đầu từ một vấn đề tôi gặp thật (máy nặng vì mỗi session Claude Code tự khởi động bản sao MCP server của riêng nó), rồi chuyển sang giới thiệu 1MCP dựa trên README của repo và tài liệu tại docs.1mcp.app. Phần giới thiệu công cụ chưa phải đánh giá sau thời gian dài dùng. Chỗ nào tài liệu không nói rõ thì tôi ghi là chưa rõ, không đoán.

Diagram Design: dạy AI agent vẽ sơ đồ kỹ thuật gọn, đẹp và đúng màu thương hiệu

· 30 phút để đọc
Nguyễn Huỳnh Minh Tiến
Fullstack Developer @ Utop.io
Tóm tắt

Diagram Design là một skill mã nguồn mở (giấy phép MIT) của Cathryn Lavery, dùng cho các AI agent như Claude Code, Codex và GitHub Copilot. Cài vào rồi, bạn chỉ cần bảo agent "vẽ sơ đồ kiến trúc cho hệ thống này" là nhận về một file HTML chứa sơ đồ gọn gàng, bố cục rõ ràng, không còn cảnh hộp chồng hộp hay mũi tên chéo lung tung. Nó vẽ được 44 loại sơ đồ và vẽ lại được sơ đồ cũ từ draw.io, Mermaid, Excalidraw. Màu, font và nền tối đổi được theo thương hiệu của bạn. Riêng với tiếng Việt, bạn nên đổi font tiêu đề, vì font mặc định thiếu nhiều chữ có dấu.

Bài này là bài giới thiệu, chưa phải đánh giá sau thời gian dài sử dụng. Thông tin lấy từ README trên GitHub và file hướng dẫn SKILL.md của bản 2.6.68. Phần font tiếng Việt và độ tương phản màu là tôi tự kiểm tra.

Phát triển hướng kiểm thử (TDD) trong vòng đời phát triển hướng AI (AI-DLC): tổng quan bằng chứng và đề xuất thực hành

· 35 phút để đọc
Nguyễn Huỳnh Minh Tiến
Fullstack Developer @ Utop.io
Tóm tắt

Tóm tắt. Phát triển hướng kiểm thử (Test-Driven Development, TDD) là kỹ thuật lặp ba bước: viết một kiểm thử thất bại (Red), viết lượng mã tối thiểu để kiểm thử đó đạt (Green), rồi tái cấu trúc mã trong khi giữ toàn bộ kiểm thử đạt (Refactor). Các nghiên cứu thực nghiệm trước kỷ nguyên AI cho kết quả không đồng nhất: nghiên cứu tình huống trên bốn đội công nghiệp ghi nhận mật độ lỗi giảm 40–90% với chi phí thời gian ban đầu tăng 15–35%, trong khi phân tích tổng hợp 27 nghiên cứu chỉ thấy cải thiện nhỏ về chất lượng. Trong vòng đời phát triển hướng AI (AI-Driven Development Life Cycle, AI-DLC), nơi mã nguồn ngày càng do mô hình ngôn ngữ lớn (LLM) sinh ra, kiểm thử có thêm một chức năng: đóng vai trò đặc tả thực thi được, qua đó làm rõ ý định và kiểm chứng đầu ra của AI. Các nghiên cứu về sinh mã dẫn dắt bởi kiểm thử từ 2023 đến 2026 cho thấy việc cung cấp kiểm thử cho LLM cải thiện kết quả trên các bộ chuẩn, và hướng mới nhất cho phép mô hình tự sinh rồi tinh chỉnh đồng thời cả kiểm thử lẫn mã. Tuy vậy, bằng chứng chủ yếu đến từ bài toán chuẩn quy mô nhỏ, và chất lượng của chính bộ kiểm thử đặt giới hạn cho mọi kết luận về tính đúng đắn. Chưa có đánh giá nào ở cấp toàn bộ vòng đời AI-DLC.

Từ khoá: TDD, AI-DLC, kiểm thử đơn vị, mô hình ngôn ngữ lớn, đặc tả thực thi được, tái cấu trúc.

Cài skill rồi code tiếp: cơ chế đằng sau và phần tri thức bị bỏ lại

· 15 phút để đọc
Nguyễn Huỳnh Minh Tiến
Fullstack Developer @ Utop.io
Tóm tắt

Một skill không phải plugin, không phải thư viện, không phải đoạn code được thực thi. Nó là văn bản được nạp vào cửa sổ ngữ cảnh theo ba tầng: tên và mô tả luôn nằm sẵn (~100 token), thân bài chỉ nạp khi model thấy khớp, còn file đính kèm thì không tốn gì cho tới lúc thật sự mở ra. Model đọc skill rồi tự quyết định làm theo, chứ không "chạy" nó. Ba tầng đó giải thích gần hết những câu hỏi thực dụng — vì sao description quyết định việc kích hoạt chứ không phải nội dung, vì sao viết skill dài là phản tác dụng. Và vì skill là bản nén phán đoán của một người trong một bối cảnh cụ thể, cài nó vào mà không đọc nghĩa là nhận cả những giả định bạn chưa từng kiểm chứng.

Quy trình phổ biến hiện nay: vào một danh mục skill, chọn preset, chạy một lệnh cài, rồi code tiếp. Hỏi vì sao agent đột nhiên viết test theo kiểu đó, vì sao nó nhất quyết dùng pattern kia, thì câu trả lời thường là "tại skill nó thế".

Đó là chỗ tri thức rơi rụng. Không phải vì skill xấu — nhiều skill viết rất tốt — mà vì bản chất của skill là nén phán đoán lại thành hướng dẫn, và người nhận thường chỉ lấy phần hướng dẫn.

Bài này mổ hai lớp: cơ chế skill hoạt động thế nào, và chuyện gì bị bỏ lại khi ta chỉ cài mà không đọc.

Thêm 4 index làm INSERT chậm 6 lần: cái giá không ai nhắc khi bảo bạn đánh index

· 13 phút để đọc
Nguyễn Huỳnh Minh Tiến
Fullstack Developer @ Utop.io
Tóm tắt

Index tăng tốc đọc bằng cách trả giá ở mỗi lần ghi, và cái giá đó lớn hơn hầu hết người ta hình dung. Đo trên PostgreSQL 16 với cùng 200.000 dòng: bảng không index chèn xong trong 287,8 ms và chiếm 10,2 MB; bảng có bốn index mất 1.722,3 ms và chiếm 27 MB. Tức là chậm gấp 6 lần và tốn gấp 2,6 lần dung lượng — chỉ để thêm bốn cấu trúc mà có thể chẳng câu truy vấn nào dùng tới. Câu hỏi đúng không phải "cột này có nên có index không" mà là "phần đọc tiết kiệm được có bù nổi phần ghi phải trả không".

Mọi bài viết về tối ưu database đều kết thúc bằng lời khuyên thêm index. Rất ít bài nói về hoá đơn đi kèm, và càng ít bài đưa con số.

Bài này đào sâu bài Thiết kế database và bài Index trong series học SQL 30 ngày. Mọi số liệu đo thật trên PostgreSQL 16.11.