Kiến trúc Quản trị Công cụ cho Hệ thống Tác tử AI: Phương pháp MCP Thu hẹp Phạm vi
Tên: Khúc Ngọc Tuyên
Đơn vị: The Successful Investor (Nhà Đầu Tư Thành Công, TSI) | SSI Times City
Email: twainkhux@gmail.com
Tóm tắt
Các hệ thống tác tử (agent) dựa trên Mô hình Ngôn ngữ Lớn (LLM) ngày càng phụ thuộc vào công cụ bên ngoài để chuyển từ suy luận sang hành động thực tế. Giao thức Ngữ cảnh Mô hình (Model Context Protocol, viết tắt MCP) ra đời năm 2024 như một chuẩn mở kết nối AI với dữ liệu và công cụ ngoại vi. Tuy nhiên, việc triển khai MCP trong thực tế bộc lộ vấn đề nghiêm trọng: Quá tải Công cụ (Tool Overload) — hiện tượng suy giảm chất lượng ra quyết định của tác tử khi số lượng công cụ tăng quá ngưỡng. Bài báo trình bày MCP Thu hẹp Phạm vi (Micro-scoped MCP), một khung quản trị giúp chọn lọc công cụ tối thiểu cần thiết, kết hợp đánh giá bảo mật 5 bước và heuristic phân bổ MCP/Script. Khung đề xuất được kiểm chứng qua nghiên cứu tình huống triển khai máy chủ MCP GitHub chính thức trong hệ thống AI đa tác tử phục vụ 6 phòng ban doanh nghiệp, giảm từ hơn 50 công cụ xuống còn 8 (tỷ lệ phơi bày 16%) mà vẫn đảm bảo 100% năng lực nghiên cứu.
Từ khóa: Giao thức Ngữ cảnh Mô hình, Tác tử AI, Quản trị công cụ, Hệ thống đa tác tử, Kiến trúc phần mềm
1. Giới thiệu
1.1 Bối cảnh
Sự phát triển của các Mô hình Ngôn ngữ Lớn (Large Language Model — LLM) như GPT-4, Claude và Gemini đã mở ra kỷ nguyên mới cho tự động hóa tri thức. Tuy nhiên, dù có năng lực suy luận vượt trội, các mô hình này vẫn bị giới hạn bởi vấn đề Cô lập Dữ liệu (Data Isolation Problem): chúng chỉ có thể xử lý thông tin có sẵn trong cửa sổ ngữ cảnh (context window) và không thể tự truy cập dữ liệu thời gian thực, cơ sở dữ liệu nội bộ hay API bên ngoài.
Để giải quyết vấn đề này, khái niệm tác tử AI (AI Agent) ra đời, trong đó LLM được trang bị các công cụ (tools) cho phép nó tương tác với thế giới bên ngoài. Giao thức Ngữ cảnh Mô hình (Model Context Protocol — MCP), do Anthropic công bố cuối năm 2024, cung cấp một chuẩn giao tiếp mở giữa AI và các nguồn dữ liệu/công cụ ngoại vi theo mô hình máy khách — máy chủ (client-server).
1.2 Vấn đề nghiên cứu
MCP giải quyết bài toán kết nối, nhưng lại tạo ra bài toán mới: Quá tải Công cụ. Khi các máy chủ MCP phơi bày toàn bộ bề mặt API (ví dụ: máy chủ MCP GitHub chính thức cung cấp hơn 50 công cụ bao phủ toàn bộ API GitHub), ba hệ quả tiêu cực xuất hiện:
- Tiêu hao ngữ cảnh: Mỗi định nghĩa công cụ chiếm 150-400 token. 50 công cụ tiêu tốn 7.500-20.000 token trước khi người dùng bắt đầu tương tác.
- Nhập nhằng lựa chọn: Các công cụ có chức năng gần nhau (như
search_repositoriesvàlist_repositories) khiến tác tử phải suy luận thêm để phân biệt. - Loãng suy luận: Tác tử với hơn 30 công cụ sinh ra chuỗi suy nghĩ (chain-of-thought) dài hơn đáng kể chỉ để quyết định dùng công cụ nào, làm giảm chất lượng suy luận cho nhiệm vụ chính.
1.3 Đóng góp của bài báo
Bài báo đóng góp 4 nội dung chính:
- Phân tích hệ thống vấn đề Quá tải Công cụ và ảnh hưởng của nó (Mục 3)
- Đề xuất mẫu thiết kế MCP Thu hẹp Phạm vi cùng heuristic chọn công cụ (Mục 4)
- Khung đánh giá bảo mật 5 bước cho triển khai MCP (Mục 5)
- Nghiên cứu tình huống triển khai thực tế trong doanh nghiệp (Mục 6)
2. Tổng quan Kiến trúc MCP
2.1 Ba thành phần nguyên thủy
MCP hoạt động theo mô hình máy chủ cung cấp khả năng, máy khách (IDE, nền tảng AI) tiêu thụ. Một máy chủ MCP cung cấp ba loại thành phần:
| Thành phần | Bản chất | Ví dụ |
|---|---|---|
| Tài nguyên (Resources) | Dữ liệu chỉ đọc | Nội dung file, bản ghi cơ sở dữ liệu |
| Công cụ (Tools) | Hàm thực thi có schema JSON | search_repositories, execute_sql |
| Mẫu lệnh (Prompts) | Khuôn mẫu prompt tái sử dụng | Mẫu “Phân tích BCTC” kèm dữ liệu |
2.2 Giao thức truyền tải
MCP hỗ trợ hai phương thức truyền tải chính thức:
- Stdio: Giao tiếp qua stdin/stdout giữa tiến trình cục bộ. Phù hợp cho máy chủ chạy trên cùng máy tính với tác tử.
- HTTP+SSE (Server-Sent Events): Giao tiếp qua mạng. Phù hợp cho máy chủ từ xa hoặc dùng chung nhiều nền tảng.
2.3 Giá trị cốt lõi
MCP mang lại ba giá trị then chốt:
Chuẩn hóa (Standardization): Trước MCP, mỗi kết nối AI-API yêu cầu viết mã tùy chỉnh riêng. Với MCP, cùng một máy chủ có thể phục vụ bất kỳ nền tảng AI nào hỗ trợ giao thức.
Bảo mật có kiểm soát: AI không truy cập trực tiếp vào toàn bộ hệ thống. Nó chỉ thấy những Tài nguyên và Công cụ mà máy chủ MCP chỉ định phơi bày, thông qua JSON Schema nghiêm ngặt.
Ngữ cảnh thời gian thực: AI không cần huấn luyện lại (fine-tune) khi dữ liệu thay đổi. Nó đọc dữ liệu “sống” qua giao thức truyền tải.
3. Vấn đề Quá tải Công cụ
3.1 Định nghĩa hình thức
Quá tải Công cụ (Tool Overload) là trạng thái trong đó số lượng công cụ khả dụng cho tác tử AI vượt qua ngưỡng mà từ đó độ chính xác lựa chọn công cụ, thời gian phản hồi và chất lượng suy luận bắt đầu suy giảm.
3.2 Cơ chế suy giảm
Ba cơ chế gây suy giảm được xác định:
Cơ chế 1: Tiêu hao ngữ cảnh. Định nghĩa công cụ MCP bao gồm tên, mô tả và schema JSON cho tham số đầu vào. Đo đạc thực tế cho thấy mỗi định nghĩa tiêu tốn trung bình 250 token. Với cửa sổ ngữ cảnh 200.000 token của các mô hình hiện đại, 50 công cụ chiếm khoảng 12.500 token (6,25%) — một tỷ lệ không nhỏ khi kết hợp với prompt hệ thống, lịch sử hội thoại và nội dung tác vụ.
Cơ chế 2: Nhập nhằng ngữ nghĩa. Khi tập công cụ lớn, xác suất xuất hiện các công cụ có mô tả tương tự nhau tăng lên. Tác tử buộc phải phân biệt dựa trên văn bản mô tả, một tác vụ trở nên không tin cậy khi quy mô lớn.
Cơ chế 3: Loãng suy luận. Quan sát thực tế trên hệ thống 6 phòng ban cho thấy tác tử với hơn 30 công cụ tạo ra chuỗi suy luận (chain-of-thought) dài gấp 2-4 lần về việc chọn công cụ nào, chiếm token lẽ ra dành cho việc sử dụng công cụ hiệu quả.
3.3 Bằng chứng quan sát
Dữ liệu quan sát từ hệ thống sản xuất qua hàng nghìn lượt gọi tác tử:
| Số lượng công cụ | Độ chính xác lựa chọn | Token suy luận trung bình | Tỷ lệ hoàn thành |
|---|---|---|---|
| 1-10 | >95% | 50-100 | >90% |
| 11-25 | khoảng 85% | 100-200 | khoảng 80% |
| 26-50 | khoảng 70% | 200-400 | khoảng 65% |
| 51-100 | <60% | 400+ | <50% |
Các con số này mang tính quan sát (observational) chứ không phải thực nghiệm có đối chứng. Tuy nhiên, xu hướng phù hợp với kết quả nghiên cứu từ ToolBench và ToolLLM trong cộng đồng quốc tế.
4. MCP Thu hẹp Phạm vi: Mẫu thiết kế đề xuất
4.1 Nguyên lý cốt lõi
MCP Thu hẹp Phạm vi (Micro-scoped MCP) là mẫu thiết kế trong đó máy chủ MCP được cấu hình để phơi bày tập công cụ tối thiểu khả dụng cho một trường hợp sử dụng cụ thể, thay vì toàn bộ bề mặt API. Nguyên lý này tương tự Nguyên tắc Đặc quyền Tối thiểu (Principle of Least Privilege) trong bảo mật thông tin: tác tử chỉ được tiếp cận đúng những công cụ nó cần, không hơn.
4.2 Ba chiến lược triển khai
Chiến lược 1: Lọc bằng tham số máy chủ. Một số máy chủ MCP hỗ trợ cờ dòng lệnh giới hạn công cụ phơi bày. Ví dụ, máy chủ MCP GitHub hỗ trợ --tools=X,Y,Z để chọn công cụ và --read-only để vô hiệu hóa mọi thao tác ghi. Đây là phương án ít tốn công sức nhất khi được hỗ trợ.
Chiến lược 2: Lọc tại máy khách. Một số nền tảng AI hỗ trợ lọc công cụ ở tầng cấu hình máy khách, ngăn các công cụ cụ thể tải vào ngữ cảnh bất kể máy chủ phơi bày gì.
Chiến lược 3: Xây dựng máy chủ tùy chỉnh. Khi cả máy chủ lẫn máy khách đều không hỗ trợ lọc, tổ chức có thể tự xây dựng máy chủ MCP bọc (wrap) API hiện có với tập công cụ được tuyển chọn. Phương án này cho quyền kiểm soát tối đa nhưng đòi hỏi chi phí bảo trì.
4.3 Heuristic chọn công cụ ba trục
Trục 1: Ánh xạ theo phương thức nghiên cứu. Xác định các phương thức nghiên cứu cơ bản mà tác tử cần hỗ trợ, sau đó chọn tập công cụ tối thiểu cho mỗi phương thức.
Trong nghiên cứu tình huống GitHub, chúng tôi xác định ba phương thức:
| Phương thức | Năng lực cần thiết | Công cụ được chọn |
|---|---|---|
| Bắt đầu từ người (Profile-first) | Tìm người dùng, xem starred repos | search_users, search_orgs, list_starred_repositories |
| Bắt đầu từ chủ đề (Topic-first) | Tìm repo, tìm mẫu mã nguồn | search_repositories, search_code |
| Bắt đầu từ công cụ (Tool-first) | Đọc file, xem lịch sử, kiểm tra phiên bản | get_file_contents, get_commit, get_latest_release |
Kết quả: 8 công cụ từ hơn 50 khả dụng (tỷ lệ phơi bày 16%) bao phủ 100% trường hợp sử dụng nghiên cứu.
Trục 2: Phân tách Đọc-Ghi. Với tác tử nghiên cứu và phân tích, thao tác ghi cần bị vô hiệu hóa mặc định. Cờ --read-only cung cấp cổng bảo mật ở tầng máy chủ, vô hiệu hóa rủi ro từ token xác thực (PAT) có phạm vi rộng.
Trục 3: Phân tích ngân sách token. Tính chi phí token ngữ cảnh của tập công cụ đã chọn, đảm bảo không vượt quá 5% tổng cửa sổ ngữ cảnh:
8 công cụ x 250 token/công cụ = 2.000 token
2.000 / 200.000 (ngữ cảnh Claude) = 1% — Nằm trong ngưỡng an toàn
4.4 Đánh đổi MCP và Script nhúng
Một quyết định kiến trúc then chốt là khi nào dùng máy chủ MCP, khi nào nhúng script Python gọi qua lệnh bash. Đây về bản chất là đánh đổi giữa chuẩn hóa và linh hoạt:
| Tiêu chí | MCP Server | Skill + Python Script |
|---|---|---|
| Xác thực tham số | JSON Schema tự động | Không có, dễ lỗi cú pháp |
| Tương thích đa nền tảng | Cao (Claude, Cursor, Windsurf…) | Thấp (chỉ nền tảng hiện tại) |
| Tiêu tốn slot MCP | Có (mỗi công cụ 1 slot) | Không (dùng run_command chung) |
| Xử lý dữ liệu trước | Không (trả JSON thô) | Có (lọc, chấm điểm, tóm tắt) |
| Bảo trì | Thấp (dùng binary chính thức) | Cao (phải duy trì mã Python) |
Heuristic phân bổ:
- Dùng MCP khi: cần tương thích đa nền tảng, cần kết nối liên tục, hoặc tính chất nguyên thủy (primitive connector)
- Dùng Script khi: luồng nhiều bước, cần xử lý/lọc dữ liệu nặng trước khi cho tác tử đọc, hoặc đang thử nghiệm nhanh
5. Khung Đánh giá Bảo mật
5.1 Quy trình 5 bước
Chúng tôi xây dựng quy trình đánh giá bảo mật 5 bước áp dụng trước khi cài đặt bất kỳ máy chủ MCP hoặc kho mã nguồn nào:
Bước 1: Sàng lọc định lượng. Đánh giá nhanh dựa trên chỉ số công khai: số sao (stars), cam kết gần nhất (last commit), số người đóng góp, tình trạng vấn đề/yêu cầu kéo (issues/PRs), lịch sử phát hành.
Bước 2: Đánh giá định tính. Kiểm tra thủ công: chất lượng README (có trả lời được cài gì, dùng thế nào, giải quyết vấn đề gì?), sự tồn tại của thư mục kiểm thử (tests/), văn hóa đánh giá mã (code review).
Bước 3: Xác minh danh tính tác giả. Tuổi tài khoản, lịch sử kho mã, liên kết tổ chức. Cờ đỏ: tài khoản dưới 3 tháng tuổi với kho mã duy nhất (sao có thể mua được).
Bước 4: Kiểm tra phụ thuộc. Đọc requirements.txt / package.json: tỷ lệ phụ thuộc so với quy mô dự án, phát hiện typosquatting (requets thay vì requests), xác minh chuỗi cung ứng.
Bước 5: Kiểm tra mã nguồn (với kho mã nhỏ dưới 1.000 dòng). Tập trung vào: lời gọi mạng trong script cài đặt, truy cập file nhạy cảm (.env, ~/.ssh), URL/IP cứng đáng ngờ.
5.2 Phân loại kết quả
| Phán quyết | Tiêu chí | Hành động |
|---|---|---|
| AN TOÀN | Mọi tín hiệu lành mạnh, tác giả xác minh được | Cài đặt bình thường |
| THẬN TRỌNG | Một số tín hiệu cảnh báo, tác giả chưa rõ | Cài trong sandbox, giám sát |
| KHÔNG AN TOÀN | Nhiều cờ đỏ, phụ thuộc đáng ngờ | Không cài đặt |
6. Nghiên cứu Tình huống: Tích hợp GitHub MCP
6.1 Bối cảnh
Hệ thống AI của tổ chức phục vụ 6 phòng ban thông qua các tác tử chuyên biệt. Phòng Nghiên cứu cần tích hợp GitHub cho 3 trường hợp sử dụng: khám phá theo hồ sơ người dùng (profile-first), tìm kiếm theo chủ đề (topic-first), và đánh giá công cụ (tool-first).
Trước đó, việc này được xử lý bởi github_researcher, một kỹ năng (skill) Python bọc API GitHub qua thư viện PyGithub. Dù hoạt động được, nó gặp vấn đề về chi phí bảo trì, thiếu xác thực schema, và không chạy được ngoài nền tảng nội bộ.
6.2 Quá trình triển khai
Giai đoạn 1: Hạ tầng. Biên dịch máy chủ MCP GitHub chính thức (Go) từ mã nguồn, tạo binary 24,4MB. Cấu hình với cờ --read-only (bảo mật tầng máy chủ) và --tools chọn 8 công cụ cốt lõi. Truyền tải qua Stdio (tiến trình cục bộ).
Giai đoạn 2: Kỹ năng phương pháp luận. Xây dựng kỹ năng đồng hành (github-research) dạy tác tử cách phối hợp 8 công cụ MCP theo 3 trục nghiên cứu + quy trình đánh giá bảo mật 5 bước.
Giai đoạn 3: Di chuyển hệ thống. Loại bỏ kỹ năng Python cũ, cập nhật 10 file trên 2 workspace (Phòng Nghiên cứu và Phòng IT): cấu hình tác tử, bảng đăng ký, quy tắc hệ thống, kỹ năng phụ thuộc.
6.3 Kết quả so sánh
| Chỉ số | Trước (Python Skill) | Sau (Micro-scoped MCP) |
|---|---|---|
| Slot MCP tiêu thụ | 1 (run_command) | 8 (chuyên dụng) |
| Token ngữ cảnh | khoảng 50 | khoảng 2.000 |
| Xác thực schema | Không | JSON Schema đầy đủ |
| Tương thích đa nền tảng | Chỉ Antigravity | Mọi MCP client |
| Bảo mật | Kiểm tra trong mã | Tầng giao thức (read-only) |
| Bao phủ nghiên cứu | 3 phương thức | 3 phương thức (giữ nguyên) |
| Chi phí bảo trì | Cao | Thấp (binary chính thức) |
Đánh đổi rõ ràng: tiêu thụ thêm 7 slot MCP để đổi lấy xác thực schema, tương thích đa nền tảng, và gần như không phải bảo trì. Với ngân sách 100 slot và tầm quan trọng chiến lược của nghiên cứu GitHub, đánh đổi này có lợi.
6.4 Mẫu thiết kế Kỹ năng Đồng hành
Một phát hiện quan trọng: việc ghép cặp máy chủ MCP thu hẹp phạm vi với một kỹ năng phương pháp luận (methodology skill) mang lại hiệu quả cao hơn hẳn so với chỉ dùng MCP đơn lẻ. Máy chủ MCP cho tác tử biết có thể làm gì (8 công cụ), trong khi kỹ năng dạy nó nên làm gì và theo trình tự nào (3 trục nghiên cứu, checklist bảo mật).
Mẫu thiết kế này, gọi là Companion Skill Pattern, có thể áp dụng cho mọi tích hợp MCP trong tổ chức.
7. Thảo luận và Kết luận
7.1 Quản trị công cụ như mối quan tâm kiến trúc hạng nhất
Kinh nghiệm triển khai cho thấy quản trị công cụ xứng đáng được coi là mối quan tâm kiến trúc hạng nhất (first-class architectural concern), ngang tầm với lựa chọn mô hình, kỹ thuật prompt và thiết kế đường ống RAG. Xu hướng hiện tại tập trung vào mở rộng tiếp cận công cụ: thêm API, thêm MCP server. Phát hiện của chúng tôi cho thấy giới hạn có chọn lọc có thể hiệu quả ngang hoặc hơn việc mở rộng.
7.2 Hạn chế
- Dữ liệu từ một tổ chức duy nhất; cần kiểm chứng tại các môi trường khác
- Số liệu hiệu suất mang tính quan sát, chưa qua thực nghiệm có đối chứng
- MCP đang tiến hóa nhanh; phiên bản tương lai có thể tích hợp cơ chế quản trị gốc
- Quan sát chủ yếu trên Claude Sonnet 4 và Gemini 2.5 Pro
7.3 Hướng nghiên cứu tiếp theo
- Chọn công cụ tự động dựa trên telemetry hiệu suất tác tử
- Thu hẹp phạm vi động (dynamic scoping) theo ý định truy vấn, thay vì cấu hình tĩnh
- Chuẩn đánh giá liên tổ chức đo lường hiệu quả quản trị công cụ
7.4 Kết luận
Bài báo trình bày MCP Thu hẹp Phạm vi, một khung quản trị thực tiễn cho hệ thống tác tử AI. Bốn phát hiện chính:
- Số lượng công cụ làm giảm chất lượng tác tử. Vượt ngưỡng 15-25 công cụ, tác tử suy giảm đo lường được về độ chính xác lựa chọn và chiều sâu suy luận.
- Thu hẹp phạm vi là hiệu quả. Giảm phơi bày từ hơn 50 xuống 8 công cụ (16%) vẫn giữ nguyên 100% năng lực nghiên cứu đồng thời cải thiện bảo mật.
- Khung quản trị là cần thiết. Quyết định MCP/Script, đánh giá bảo mật và chọn công cụ cần heuristic hệ thống thay vì phán đoán tùy tiện.
- Mẫu Kỹ năng Đồng hành (Companion Skill Pattern) tạo hiệu quả vượt trội khi kết hợp MCP thu hẹp phạm vi với kỹ năng phương pháp luận.
Tài liệu tham khảo
[1] Schick, T. và cộng sự. “Toolformer: Language Models Can Teach Themselves to Use Tools.” NeurIPS 2023.
[2] Anthropic. “Model Context Protocol Specification.” https://modelcontextprotocol.io, 2024.
[3] Lewis, P. và cộng sự. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” NeurIPS 2020.
[4] Qin, Y. và cộng sự. “ToolLLM: Facilitating Large Language Models to Master 16000+ Real-world APIs.” ICLR 2024.
[5] Xu, Q. và cộng sự. “On the Tool Manipulation Capability of Open-source Large Language Models.” arXiv:2305.16504, 2023.
[6] Qin, Y. và cộng sự. “Tool Learning with Large Language Models: A Survey.” arXiv:2405.17935, 2024.
[7] GitHub. “GitHub MCP Server.” https://github.com/github/github-mcp-server, 2025.
Ngày nộp: Tháng 5/2026
Tác giả liên hệ: twainkhux@gmail.com
TSI Research | The Successful Investor (Nhà Đầu Tư Thành Công)
Đọc thêm tài liệu chuyên đề: Claude Skills là gì? — Hướng dẫn toàn diện cho người mới bắt đầu để nắm rõ phương pháp tiếp cận của hệ thống.
