AI Agent hoạt động như thế nào? Làm rõ vai trò của Skill, Tool và MCP
Năm 2026, từ “AI agent” xuất hiện khắp nơi. Mỗi tuần có thêm framework mới, startup mới, demo mới. Ai cũng nói về agent - nhưng nếu hỏi cụ thể “một agent làm việc thực ra diễn ra như thế nào bên trong?”
Bài viết này là một nỗ lực mổ xẻ theo hướng: thay vì liệt kê khái niệm, chúng ta sẽ đi theo hành trình của một yêu cầu thực tế từ lúc người dùng gõ câu lệnh cho đến lúc agent trả kết quả. Qua đó, ba thành phần quan trọng nhất sẽ được đào sâu: MCP, Tool, và Skill. Mỗi cái đóng một vai trò khác nhau, và hiểu đúng vai trò từng cái là điều phân biệt giữa người dùng agent và người dùng agent thông minh.
Ở cuối bài, chúng ta tìm hiểu đến một yếu tố bí ẩn thứ tư thứ mà nhiều người bỏ qua, nhưng lại quyết định chất lượng thực tế của agent nhiều hơn ta tưởng.
Hãy bắt đầu bằng cách quan sát một agent khi nó làm việc.
Chúng ta mổ xẻ một yêu cầu cụ thể để tìm hiểu vai trò của Skill, Tools và MCP: “Tóm tắt cho tôi những email quan trọng sáng nay.”
Bạn gõ câu này vào một AI agent. Vài giây sau, bạn nhận được một bản tóm tắt gọn gàng: 3 email cần trả lời gấp, 2 email nội bộ có thể đọc sau, phần còn lại là tự động hoặc quảng cáo đã bỏ qua.
Nhìn bên ngoài có vẻ đơn giản. Nhưng thực tế, trong vài giây đó, đã có một chuỗi hành động phức tạp diễn ra. Và mỗi bước đều cần một thành phần khác nhau để thực hiện được. Các bước này có thể gồm:
Bước 1. Agent hiểu yêu cầu và nhận ra cần phải “lên kế hoạch” các công việc cần làm
Từ một câu lệnh, agent phải suy ra: cần lấy dữ liệu từ email, cần phân loại theo mức độ quan trọng, cần tóm tắt, và cần trả về dưới dạng đã được người dùng yêu cầu từ trước.
Vậy, agent biết phải làm theo quy trình đó từ đâu? Nó không tự nghĩ ra. Phải có ai đó đã định nghĩa sẵn “khi nhận yêu cầu kiểu này, làm các bước này”. Các định nghĩa này thường sẽ nằm trong Skill chúng ta sẽ đào sâu ở phần sau.
Sau khi đã có kế hoạch thì agent sẽ đi thực hiện các công việc này.
Bước 2. Agent cần truy cập vào Gmail của bạn
Đây là chỗ thú vị. LLM bản thân nó chỉ là một mô hình ngôn ngữ không thể tự mở inbox của bạn. Nó cần một CẦU NỐI đến Gmail, một thứ biết cách xác thực, biết cách gọi API của Google, biết cách trả dữ liệu về đúng định dạng.
Cầu nối đó chính là MCP. Không có MCP, agent không chạm được vào email thật của người dùng.
Bước 3. Agent thực hiện một hành động cụ thể
Có cầu nối rồi, agent phải chọn đúng hành động để làm. Nó không gọi “Gmail” chung chung nó phải gọi một thứ rất cụ thể, ví dụ như gmail_list_messages với các tham số như “từ 6h sáng hôm nay đến giờ”, “chưa đọc”, “không có label Promotions”.
Mỗi hành động cụ thể đó “được thực hiện bởi” một Tool. Agent có cả một danh sách Tool trong tay, và việc của nó là chọn đúng cái cần, với đúng tham số.
Bước 4. Agent xử lý dữ liệu nhận được
Sau khi Tool trả về danh sách email, agent đọc từng cái, phân loại, tóm tắt. Đây là lúc năng lực thuần tuý của LLM phát huy đọc hiểu, suy luận, viết lại. Không cần MCP, không cần Tool ở bước này. Chỉ cần bản thân model.
Bước 5. Agent định dạng kết quả và trả về cho bạn
Kết quả không nên là một đống text lộn xộn. Nó phải có cấu trúc: nhóm URGENT trước, IMPORTANT sau, FYI cuối. Mỗi nhóm đánh số, mỗi email có tóm tắt 1-2 câu. Quy tắc định dạng này cũng không phải tự nhiên mà có lại một lần nữa, nó được định nghĩa sẵn trong Skill.
: agent biết phải làm theo quy trình nào?
Với yêu cầu “Tóm tắt cho tôi những email quan trọng sáng nay.”. Agent cần biết làm theo quy trình nào? Thứ đảm bảo quy trình nhất quán chính là Skill.
Skill là gì
Skill là một thư mục chứa hướng dẫn và tài nguyên để agent xử lý một loại việc cụ thể. Cấu trúc tối thiểu gồm một file SKILL.md file markdown mô tả khi nào dùng skill, quy trình ra sao, quy tắc đầu ra thế nào.
Khi người dùng gõ yêu cầu, agent duyệt qua các Skill có sẵn, đọc phần mô tả, nhận ra skill nào phù hợp, và follow theo quy trình định nghĩa trong đó.
Tại sao Skill quan trọng
Không có Skill, agent vẫn làm việc được nhưng theo cách không nhất quán. Mỗi lần gọi có thể ra kết quả khác nhau, format khác nhau, bỏ sót bước khác nhau.
Có Skill, mỗi lần gọi ra kết quả giống nhau về cấu trúc, theo đúng quy tắc đã định nghĩa. Đây là yếu tố then chốt để đi từ “demo thú vị” đến “sản phẩm production”.
Skill còn một lợi thế nữa: có thể chia sẻ. Một skill viết tốt cho email_summarizer có thể đưa cho cả team dùng, ai cũng nhận được chất lượng tóm tắt tương đương nhau - miễn là máy họ có đủ MCP và Tool mà skill cần.
MCP là viết tắt của Model Context Protocol, một chuẩn mở do Anthropic đề xuất cuối năm 2024. Ý tưởng đằng sau rất đơn giản: chuẩn hoá cách AI kết nối với các hệ thống thực.
Trước khi có MCP, mỗi tích hợp là một cách riêng. Muốn AI đọc Gmail viết một đoạn code, muốn đọc Slack viết đoạn khác, không dùng lại được. MCP giải quyết bằng một giao thức chung: ai tạo cầu nối đến dịch vụ nào thì đóng gói thành một MCP Server tuân theo giao thức này. AI nào hỗ trợ MCP đều dùng được ngay.
MCP Server hoạt động thế nào
Quay lại ví dụ email. Agent không gọi trực tiếp vào Google, mà nói chuyện với Gmail MCP Server, một process đã được cấu hình sẵn để thay mặt người dùng làm việc với Gmail. Server lo xác thực, gọi API, chuẩn hoá dữ liệu trả về. Agent chỉ cần biết “server này cung cấp được những gì”, chi tiết thực thi được giấu hoàn toàn phía sau.
Điểm quan trọng cần nhớ
Tính đến đầu 2026, đã có hàng nghìn MCP Server cho hầu như mọi dịch vụ phổ biến. Nhưng điểm cốt lõi là: MCP Server là thứ cung cấp khả năng cho agent, chứ không phải agent tự có khả năng đó. Nếu máy bạn có Gmail MCP, agent đọc được email. Nếu máy đồng nghiệp chưa cài, agent của anh ấy dù giống y hệt về cấu hình không đọc được gì cả.
Nếu MCP là cầu nối, thì Tool là công cụ để làm những hành động cụ thể mà agent có thể thực hiện sau khi đã có cầu nối đó.
Một Gmail MCP Server sau khi kết nối sẽ expose ra một danh sách Tool mỗi Tool là một việc agent có thể làm, với tên rõ ràng và tham số được định nghĩa sẵn. Ví dụ:
- gmail_list_messages(query, limit) - liệt kê email theo điều kiện
- gmail_get_message(id) - lấy nội dung một email cụ thể
- gmail_search_messages(keyword) - tìm kiếm
- gmail_send_message(to, subject, body) - gửi email mới
Tương tự, Slack MCP expose các Tool như slack_send_message, slack_list_channels. GitHub MCP expose github_create_issue, github_list_pull_requests. Mỗi server mang đến một bộ Tool tương ứng với dịch vụ nó phụ trách.
Tool không chỉ đến từ MCP
Điểm nhiều người bỏ qua: Tool không phải lúc nào cũng đến từ MCP. Một số Tool là built-in của chính AI client. Ví dụ Claude Code có sẵn Read, Write, Edit, Bash, Grep - đọc file, sửa file, chạy lệnh terminal. Những Tool này không cần MCP Server nào cả, chúng là một phần của client.
Khi agent làm việc, nó có một danh sách tổng hợp: Tool built-in + Tool từ tất cả MCP Server đã kết nối. Việc của agent là chọn đúng Tool cho đúng việc, với đúng tham số.
Agent chọn Tool như thế nào
Mỗi Tool có một mô tả kèm theo: tên, tham số, công dụng, khi nào dùng. Agent đọc mô tả này, so với yêu cầu hiện tại, và chọn Tool phù hợp.
Ví dụ khi nhận yêu cầu “tóm tắt email sáng nay”, agent đọc qua danh sách Tool, thấy gmail_list_messages có mô tả “liệt kê email theo điều kiện ngày, nhãn, trạng thái đọc”. Đây đúng là việc cần. Agent gọi Tool này với tham số phù hợp và nhận lại kết quả.
Chất lượng mô tả Tool rất quan trọng. Mô tả mơ hồ hoặc thiếu, agent sẽ chọn sai - hoặc không chọn được Tool nào và bỏ cuộc. Đây là lý do các MCP Server tốt thường có documentation rõ ràng cho từng Tool.
Phân biệt Skill, Tool và MCP
Đây là chỗ nhiều người nhầm lẫn:
- MCP cho agent khả năng kết nối đến hệ thống thực
- Tool cho agent hành động cụ thể có thể thực hiện
- Skill cho agent quy trình và quy tắc về việc nào làm lúc nào, theo thứ tự gì, đầu ra trông ra sao
Ba thứ không thay thế cho nhau. Skill không chứa Tool, Skill chỉ tham chiếu Tool. Tool không chứa MCP Tool được expose bởi MCP hoặc được AI client cung cấp sẵn. Cả ba cùng làm việc: Skill chỉ đạo quy trình, Tool thực thi hành động, MCP cung cấp kết nối.
Đến đây có vẻ như công thức đã đủ: MCP + Tool + Skill. Cài đủ cả ba, agent sẽ chạy tốt.
Nhưng thực tế không đơn giản như vậy. Một hiện tượng ai đưa agent vào sử dụng nghiêm túc đều gặp: cùng một Skill, chạy trên hai model LLM khác nhau, kết quả có thể chênh lệch đáng kể.
Cùng một file SKILL.md. Cùng một MCP. Cùng một danh sách Tool. Nhưng đổi model - chất lượng đầu ra khác hẳn.
Đây là yếu tố thứ 4 mà hầu hết tài liệu AI agent không nhắc đến: khả năng đọc hiểu và tuân thủ Skill của từng model.
Tại sao có sự khác nhau này?
Bốn yếu tố chính:
- Độ sâu suy luận. Skill có bước “nếu A thì B, nếu C thì D”. Model yếu rẽ nhầm nhánh hoặc bỏ qua bước kiểm tra.
- Khả năng diễn giải. Câu “ALWAYS verify the data” model A hiểu là kiểm tra schema, model B chỉ in ra rồi tiếp tục, model C đi hỏi người dùng. Cùng một câu, ba hành vi.
- Cửa sổ ngữ cảnh. Skill dài cần model có context window đủ rộng, nếu không sẽ bỏ qua phần giữa hiện tượng lost in the middle.
Kết luận
Sau khi đi qua một agent từ đầu đến cuối, chúng ta đã có đủ các mảnh ghép:
- MCP cho agent khả năng kết nối đến hệ thống thực
- Tool cung cấp các hành động cụ thể agent có thể thực hiện
- Skill định nghĩa quy trình, quy tắc và định dạng đầu ra
- Model quyết định chất lượng thực thi, hiểu và tuân thủ Skill đến đâu
Ba thành phần đầu là những gì bạn có thể cài đặt và cấu hình. Thành phần thứ tư là những gì bạn phải lựa chọn có chủ đích không model nào tốt cho mọi Skill, và không Skill nào chạy như nhau trên mọi model.
Đây cũng là lý do xây một AI agent thực sự tốt không chỉ là vấn đề kỹ thuật. Đó là việc cân bằng giữa khả năng (MCP + Tool), kiến thức (Skill), và khả năng đọc hiểu của người thực thi (Model). Bỏ qua bất kỳ yếu tố nào, kết quả sẽ không ổn định.
Ba câu hỏi để tự đặt ra khi nhìn vào một AI agent bất kỳ:
- Agent này đang kết nối đến đâu, và kết nối bằng cách nào?
- Quy trình làm việc được định nghĩa ở đâu, hay đang được model tự “bịa” mỗi lần?
- Skill này đã được test trên những model nào, và kết quả có nhất quán không?
Ba câu hỏi đơn giản, nhưng trả lời được cả ba thường phân biệt một demo đẹp với một sản phẩm dùng được.