Agent Skills và MCP Server: Đừng coi đó là hai lựa chọn thay thế nhau

Bất kỳ team nào đã dành vài tháng xây agent trên Claude sớm muộn cũng sẽ hỏi một biến thể của cùng một câu hỏi: cái này nên làm thành Agent Skill hay MCP server? Câu hỏi thường bị đóng khung như một ngã ba đường, và các team tốn không ít thời gian tranh luận như thể chọn sai là phải đập đi xây lại.

Cách đóng khung đó sai ngay từ đầu. MCP server và Skill không phải là hai câu trả lời cạnh tranh cho cùng một câu hỏi. Chúng là câu trả lời cho hai câu hỏi khác nhau, và sự nhầm lẫn này tốn kém thật sự, vì hai cơ chế này nạp vào context window theo hai điều khoản hoàn toàn khác nhau. Một cái bị tính phí ở mọi request, dùng hay không dùng cũng vẫn mất tiền. Cái còn lại thì không.

Bài này sẽ nói rõ: mỗi cơ chế thực sự mang lại điều gì, mô hình nạp dữ liệu nào phân biệt chúng, vì sao chỉ cần thêm một MCP server thôi cũng có thể làm hỏng toàn bộ prompt cache, tool search và deferred loading thay đổi bài toán đó ra sao, và một quy tắc quyết định thực tế đã chứng minh hiệu quả khi lên production. Nếu bạn đã đọc bài trước của chúng tôi về việc chọn giữa MCP và CLI, thì bài này là lớp tiếp theo phía trên đó.

MCP server thật sự mang lại điều gì

Model Context Protocol là một chuẩn mở để kết nối model với các công cụ và dữ liệu bên ngoài thông qua một giao diện chung. MCP server là một chương trình đang chạy, mở ra những khả năng mà model không thể tự chạm tới: workspace Linear của bạn, một database Postgres, một project trên Sentry, hay một dịch vụ nội bộ nằm sau VPC.

Từ khóa quan trọng ở đây là chạm tới. MCP giải quyết bài toán kết nối. Nó cho model những tool có schema rõ ràng, đầu vào đầu ra cụ thể, và cho bạn một chỗ để áp đặt chính sách phân quyền: một tool có thể ghi dữ liệu hay tiêu tiền thì được đánh dấu cần con người duyệt trước khi chạy, còn những tool rủi ro thấp thì chạy tự động.

Nhưng MCP không mang lại cho bạn sự phán đoán. Kết nối một MCP server cho Linear thì Claude biết là mình có thể tạo issue. Nhưng nó không nói gì về việc team bạn viết issue kiểu gì, field nào bắt buộc, quy ước triage của bạn ra sao, hay khi nào thì việc tạo issue là một nước đi sai.

Agent Skill thật sự mang lại điều gì

Agent Skill là một thư mục chứa file SKILL.md, và tùy chọn thêm các script cùng tài liệu tham khảo. Đó là kiến thức quy trình được đóng gói lại: cách làm một loại công việc cụ thể, theo đúng cách tổ chức của bạn vẫn làm.

Skill là nơi chứa sự phán đoán. Đó là khoảng cách giữa một model về mặt kỹ thuật có thể tạo issue, và một model tạo ra đúng cái issue mà team bạn sẽ tạo. Nó mang theo các quy ước, checklist, phong cách riêng của tổ chức, những trường hợp ngoại lệ bạn đã học được từ kinh nghiệm xương máu, và những script mã hóa lại một quy trình lặp lại được.

Vậy nên hai thứ này bổ trợ nhau theo đúng nghĩa đen. MCP là bàn tay. Skill là sự huấn luyện. Một team kết nối năm MCP server mà không viết Skill nào thì có một agent với khả năng chạm tới rất tốt nhưng lại chẳng có gu gì cả, nói cách khác đó là một agent làm sai việc một cách rất hiệu quả.

Khác biệt thật sự nằm ở thời điểm mỗi cái được nạp vào

Đây chính là phần quyết định hóa đơn của bạn, và cũng là chỗ hai cơ chế này thật sự tách biệt nhau.

Định nghĩa tool được nạp ngay lập tức. Mọi tool bạn khai báo, kể cả mọi tool được expose bởi từng MCP server đã kết nối, đều được render vào request trước khi bất cứ thứ gì khác diễn ra. Thứ tự luôn cố định: tool trước, rồi đến system prompt, rồi mới tới đoạn hội thoại. Những schema đó nằm trong context window ở mọi request, bất kể Claude có đụng tới chúng hay không.

Skill thì nạp dần theo nhu cầu. Phần mô tả của một Skill nằm sẵn trong context để Claude biết Skill đó tồn tại, nhưng nội dung đầy đủ của file SKILL.md chỉ được đọc khi tác vụ thật sự cần đến. Toàn bộ quy trình, checklist, tài liệu tham khảo, tất cả đều nằm ngoài context cho tới khi liên quan.

Sự bất đối xứng đó chính là cả câu chuyện. Mười MCP server, mỗi cái mười hai tool, nghĩa là một trăm hai mươi schema tool được render vào đầu mỗi request, suốt cả phiên làm việc. Mười Skill thì chỉ là mười dòng mô tả, phần nội dung chỉ được kéo vào khi cần. Đây là lý do vì sao những team theo dõi sát mức tiêu thụ token thường đi tới cùng một mô hình: một số ít MCP server được chọn lọc kỹ, và một thư viện Skill lớn hơn nhiều.

Vì sao chỉ thêm một MCP server mới cũng có thể làm hỏng cả cache

Thứ tự nạp dữ liệu còn kéo theo một hệ quả nữa, dễ bị bỏ qua nhưng lại rất tốn kém khi phải học ra bài học đó.

Prompt caching trên Claude API hoạt động theo kiểu khớp tiền tố nghiêm ngặt. Cache key được tính từ đúng từng byte của prompt đã render, và chỉ cần lệch một byte ở bất kỳ đâu trong đoạn tiền tố đó là toàn bộ token đã cache phía sau bị vô hiệu. Vì tool luôn được render trước tiên, ở ngay đầu tiền tố, nên chỉ cần thêm, bớt, hay đổi thứ tự một tool thôi là không chỉ phần định nghĩa tool bị vô hiệu, mà cả cache của system prompt và toàn bộ cache hội thoại phía sau nó cũng mất theo.

Bài toán kinh tế ở đây khá đau. Đọc từ cache tốn khoảng một phần mười so với một token input thông thường. Ghi vào cache tốn khoảng 1,25 lần một token thông thường với TTL mặc định năm phút, và khoảng gấp đôi với TTL một giờ. Vậy nên một bộ tool ổn định gần như miễn phí khi duy trì xuyên suốt một phiên dài, còn một bộ tool thay đổi liên tục giữa các request thì cứ phải trả phí ghi cache lặp đi lặp lại, trên toàn bộ tiền tố, mỗi lần nó thay đổi.

Cũng nên biết rõ thay đổi nào tốn cái gì. Thay đổi định nghĩa tool hoặc đổi model sẽ làm hỏng toàn bộ cache. Nhưng thay đổi tool_choice, hay bật tắt chế độ thinking, thì chỉ làm mất cache ở cấp độ message, còn tool và system prompt vẫn được giữ nguyên trong cache. Nhiều team lại hay tối ưu hóa quá đà cho nhóm thứ hai trong khi vô tư làm điều thứ nhất.

Quy tắc thực tế rút ra từ đây: đừng đổi bộ MCP server theo từng tác vụ hay từng người dùng nếu tránh được. Một bộ tool riêng cho từng người dùng nghĩa là không hai người dùng nào từng chia sẻ chung một tiền tố cache, và bạn sẽ phải trả giá đầy đủ ở đầu mỗi request, mãi mãi.

Tool Search và Deferred Loading giải quyết bài toán nạp sớm

Anthropic đã xử lý trực tiếp chi phí nạp sớm bằng công cụ tool search. Bạn đánh dấu tool bằng defer_loading, và schema đầy đủ của chúng sẽ không được render vào context cho tới khi Claude thật sự tìm kiếm và tìm thấy chúng.

Chi tiết khiến cách này thật sự hữu ích, chứ không chỉ là một cách trả phí khác, là các schema tool được tìm thấy sẽ được nối thêm vào request thay vì thay thế vào giữa. Việc nối thêm không làm xáo trộn tiền tố hiện có, nên cache vẫn sống sót. Đây là cách duy nhất được khuyến nghị để có một bộ tool lớn, thay đổi linh hoạt mà không phải đốt cache mỗi lần có thay đổi.

Có hai ràng buộc cần biết trước khi bật tính năng này. Bản thân công cụ search không được đánh dấu defer, và ít nhất một tool trong request của bạn phải luôn không bị defer. Nếu defer hết tất cả, API sẽ trả về lỗi 400 báo đúng lý do đó.

Còn có một cơ chế an toàn âm thầm đáng để biết: nếu một lệnh gọi tool MCP trả về hơn 100.000 token, kết quả sẽ tự động được đẩy ra một file thay vì đổ hết vào cuộc hội thoại, và Claude chỉ nhận một bản xem trước cùng đường dẫn file. Việc cần đến cơ chế an toàn này cũng cho thấy một tích hợp MCP không được quản lý tốt có thể làm tràn context window dễ dàng đến mức nào.

Code Execution lại thay đổi bài toán token một lần nữa

Có một lựa chọn thứ ba mà phần lớn team chưa dùng tới, và nó thay đổi cách tính toán còn nhiều hơn hai cách trên.

Với cách dùng tool tiêu chuẩn, mỗi lần gọi là một vòng round-trip. Claude gọi tool, toàn bộ kết quả đổ vào context của Claude, Claude suy luận về nó, rồi mới gọi tool tiếp theo. Ba lần tra cứu liên tiếp nghĩa là ba vòng round-trip, và phần dữ liệu trung gian, phần lớn không bao giờ cần dùng lại, vẫn nằm trong context window và tiếp tục ăn tiền thuê mãi mãi.

Programmatic tool calling đảo ngược cách này lại. Claude viết một script gọi các tool như những hàm bình thường. Script chạy trong container thực thi code, và khi nó gọi một tool, kết quả trả về cho script đang chạy, chứ không trả về context của Claude. Script sẽ lọc, lặp, rẽ nhánh trên dữ liệu đó bằng control flow thông thường, và chỉ có kết quả cuối cùng mới quay trở lại cho model.

Hệ quả là chi phí token tỷ lệ với kích thước câu trả lời cuối cùng, chứ không phải với kích thước của tất cả những gì phải đọc để tạo ra câu trả lời đó. Với bất kỳ workflow nào phân nhánh qua nhiều lệnh gọi hoặc kéo về những payload trung gian lớn, đây chính là ranh giới giữa một agent khả thi và một agent không khả thi. Đội ngũ kỹ thuật của Anthropic đã viết chi tiết về điều này trong bài code execution with MCP, và đây cũng là phần bức tranh mà phần lớn team vẫn còn thiếu.

Một quy tắc quyết định đã được chứng minh hiệu quả

• Dùng MCP server khi model cần chạm tới một hệ thống mà nó không thể tự tiếp cận, hoặc khi một hành động cần input có kiểu dữ liệu rõ ràng và cần cổng duyệt của con người trước khi chạy. Cố định một server cho mỗi hệ thống bên ngoài, và cưỡng lại ý muốn thêm nhiều hơn mức cần.
• Dùng Skill khi model đã có thể kỹ thuật làm được việc đó nhưng cứ làm sai cách. Skill mã hóa sự phán đoán, quy ước và quy trình, và gần như không tốn gì cho tới khi thật sự được dùng đến.
• Ưu tiên CLI trước khi khả năng đó đã tồn tại sẵn dưới dạng công cụ dòng lệnh và bộ công cụ sẽ ổn định suốt cả phiên. Lập luận này không đổi và đã được nói kỹ trong bài về MCP hay CLI của chúng tôi.
• Bật tool search với defer_loading trước khi số lượng tool đã kết nối vượt quá nhu cầu của bất kỳ tác vụ đơn lẻ nào, chứ đừng đợi tới khi hóa đơn nhắc bạn mới bật.
• Dùng code execution khi agent phải gọi rất nhiều lần hoặc xử lý những kết quả trung gian lớn mà Claude không thực sự cần nhìn thấy.

Kiểu thất bại gần như lúc nào cũng giống nhau

Trong thực tế, những team gặp khó khăn ở đây không phải là những team chọn sai giữa MCP và Skill. Đó là những team chưa bao giờ tách hai câu hỏi này ra riêng biệt ngay từ đầu. Họ kết nối server để giải quyết vấn đề hành vi, điều này không hiệu quả, vì không có lượng kết nối nào dạy được cho agent các quy ước của bạn. Rồi họ viết tài liệu để giải quyết vấn đề khả năng tiếp cận, điều này cũng không hiệu quả, vì không có lượng hướng dẫn nào cho agent quyền truy cập vào một hệ thống mà nó không thể gọi tới.

Hãy tự hỏi câu chẩn đoán này trước khi bắt tay xây dựng bất cứ thứ gì: agent đang thất bại vì nó không thể chạm tới thứ gì đó, hay vì nó không biết bạn muốn công việc được làm theo cách nào? Câu đầu là vấn đề của MCP. Câu sau là vấn đề của Skill. Chúng gần như không bao giờ là cùng một vấn đề, và cách sửa cho cái này sẽ không đụng chạm gì tới cái kia.

Cùng một nguyên tắc kỷ luật mà chúng tôi áp dụng cho hệ thống prompt cũng áp dụng ở đây, và đó là lý do chúng tôi luôn thúc team thiết kế workflow trước khi chọn công cụ, đúng như đã nói trong bài về xây dựng hệ thống AI thay vì chỉ viết prompt rời rạc.

Nếu team bạn đang loay hoay với kiến trúc agent, thiết kế bộ công cụ, hay bài toán kinh tế token của một hệ thống đang bắt đầu tốn kém, dịch vụ đào tạo và tư vấn AI của chúng tôi làm việc trực tiếp với đúng những đánh đổi này cùng các team đang xây dựng trên Claude. Bạn có thể xem cách chúng tôi tiếp cận công việc này tại Growthtrait, hoặc liên hệ nếu muốn có thêm một góc nhìn thứ hai cho hệ thống của mình.