# Skills are the New SDKs

Elvin Aghammadzada · DataRobot · AI Engineer World's Fair 2026: Online Track

> Vì sao skill là lớp experience mới cho agent: context rot, progressive disclosure, skill vs MCP, cấu trúc SKILL.md và rủi ro của hệ sinh thái skill.

Topics: Context Engineering, Agents, Dev Tools, Security

Canonical: https://homus.dev/talks/skills-are-the-new-sdks

## 1. Lộ trình talk và ba "ứng dụng" trong mỗi AI app

Elvin Aghammadzada làm ở DataRobot, trên Agent Workforce Platform, nơi đội của anh đưa agentic AI vào môi trường enterprise. Anh mở đầu bằng lời hứa của buổi nói chuyện: hôm nay sẽ nói về skill. Trước hết là những thách thức hiện tại quanh context, sau đó là vì sao skill quan trọng, rồi so sánh MCP với skill, và cuối cùng là hệ sinh thái đang được dựng lên quanh skill dạo gần đây, nhất là khi OpenClaw và những thứ tương tự đang thu hút rất nhiều sự chú ý trong ngành.

![Slide Promise liệt kê bốn phần của talk](https://homus.dev/photos/LC3-P7v3yoI-0008.jpg)

Slide "Promise": cuối buổi sẽ đi qua bốn phần, gồm các thách thức của context (engineering), vì sao skill quan trọng, MCP vs. Skills, và hệ sinh thái skill.

Điểm xuất phát của anh là một quan sát về cấu trúc: mọi AI app hay agentic app thường có ba layer, giống như ba ứng dụng chồng lên nhau.

- **Thứ người dùng nhìn thấy**: thường là UI, giao diện người dùng.

- **Thứ model nhìn thấy**: system prompt, cùng với phần mô tả của các tool (tool description).

- **Thứ dữ liệu nhìn thấy**: schema của dữ liệu, hay input và output của các tool call.

Theo Elvin, những con bug nhỏ thường sống ở layer thứ hai và thứ ba, tức là phần hơi bị giấu khỏi mắt người dùng. Người dùng thấy UI vẫn chạy bình thường, nhưng thứ thật sự hỏng là những gì model đọc và những gì dữ liệu đi qua. Phần đầu của talk là để nói về chính những vấn đề nằm ở đó.

![Slide Every AI app is actually THREE applications](https://homus.dev/photos/LC3-P7v3yoI-0024.jpg)

Mỗi AI app thật ra là ba ứng dụng: cái người dùng thấy, cái model thấy, cái dữ liệu thấy. Chú thích nhỏ ở góc slide nói bug sống ở hai cái mà ta không render ra màn hình.

## 2. Problem 1: nghịch lý của context window

Vấn đề đầu tiên Elvin gọi là "lời nói dối đẹp đẽ" mà chúng ta được kể: rằng các frontier model mới nhất có context window gần như vô hạn. Mỗi model mới thường được hứa hẹn có một triệu, năm triệu token, thậm chí có những model mới nhất được quảng bá là infinite context window. Lời hứa đó định hình sai cách chúng ta nghĩ về RAG và về MCP.

Nếu coi context window là vô hạn, ta sẽ nghĩ đơn giản rằng cứ đổ toàn bộ danh sách tài liệu vào context là mọi thứ sẽ tự chạy một cách thần kỳ, và RAG trông như không còn cần thiết (tìm đúng tài liệu làm gì khi có thể nhét tất cả vào?). Với MCP cũng vậy: ta nghĩ có thể viết một trăm tool rồi trông chờ LLM tự chọn đúng tool vào đúng lúc. Thực tế thường không phải thế.

Trong thực tế, context dài hơn thường **không** đồng nghĩa với hiệu năng tốt hơn. Mỗi lần ta đưa thêm context vào LLM là thêm một chỗ LLM có thể bị dẫn sai, hoặc context của nó có thể bị "đầu độc" (poisoned). Elvin dẫn một nghiên cứu có tên [Context Rot](https://www.trychroma.com/research/context-rot), và theo cách anh tóm lại, nó cho thấy sau khi dùng khoảng 25% context window thì hiệu năng bắt đầu giảm. Ví dụ với context một triệu token, khi đã dùng tới 256K thì chất lượng bắt đầu đi xuống.

![Slide Problem 1: Context Window Paradox](https://homus.dev/photos/LC3-P7v3yoI-0056.jpg)

"Context Window Paradox": ta được hứa 1M, 5M, thậm chí infinite context window, khiến RAG tưởng như lỗi thời và MCP tưởng như vô hạn. Thực tế, context dài hơn không cho câu trả lời tốt hơn; context quá tải làm agent hỏng theo những cách bất ngờ, bị poisoned, bị phân tâm bởi thông tin không liên quan, bị rối, và xuống cấp vì các tín hiệu mâu thuẫn.

Anh mô tả nó như một "day in the life": mọi thứ bắt đầu rất tốt, nhưng thời gian trôi đi và cuộc hội thoại dài ra. Giả sử có một trăm lượt prompt vào và response ra trong một chat, nhân lên với một trăm chat, và trong mỗi chat lại có những lần gọi MCP hay tool bị fail ở giữa chừng. Đến cuối ngày, context gần như đang tự ăn chính nó, tới mức một frontier model mới nhất cũng có thể hoạt động như một model rất kém.

Slide kể lại hành trình đó theo từng mốc: ngày 1, "Wow, mình nhét được mọi thứ!"; ngày 7, "Sao nó chậm thế?"; ngày 14, "Sao nó trả lời sai?"; ngày 21, "Context đang tự ăn chính nó". Bên cạnh là meme chú chó ngồi giữa căn phòng đang cháy với câu "This is fine".

Elvin chắc rằng ai cũng từng thấy câu "You are absolutely right" từ Claude Code. Nghe thì rất trấn an, được bảo là mình hoàn toàn đúng. Nhưng tới một lúc nào đó nó làm bạn thấy khó chịu, vì Claude Code đang lặp lại đúng cái lỗi nó vừa mắc năm phút trước.

![Slide Day in the life với meme This is fine và chiếc cốc You are absolutely right](https://homus.dev/photos/LC3-P7v3yoI-0248.jpg)

"Day in the life" của một context bị nhồi: ngày 1 hào hứng, ngày 7 chậm, ngày 14 sai, ngày 21 context tự ăn chính nó. Góc dưới là chiếc cốc in câu quen thuộc "You are absolutely right".

## 3. Problem 2: docs có một audience mới

Vấn đề thứ hai chủ yếu liên quan tới các trang documentation. Elvin đưa ra một con số anh thấy thú vị: chỉ từ năm ngoái tới năm nay, phần traffic vào các trang documentation đến từ coding agent đã tăng từ 10% lên 50%. (Về đo đạc traffic agent trên các trang docs, có thể đọc thêm [phân tích agent traffic của Mintlify](https://www.mintlify.com/blog/state-of-ai).)

Thách thức nằm ở chỗ docs được viết cho con người, trong khi model cần một định dạng khác. Docs thường đòi hỏi một chút trực giác, đòi hỏi người đọc biết hỏi lại một câu follow-up, hoặc nếu chưa hiểu thì nhanh chóng Google để tìm câu trả lời. Model thường không có những khả năng đó, cho tới khi ta thật sự xây một lớp context engineering quanh nó.

![Slide Problem 2: Docs have a new audience](https://homus.dev/photos/LC3-P7v3yoI-0304.jpg)

"Docs have a new audience": traffic vào trang docs giờ là 50% coding agent, từ 10% một năm trước. Docs truyền thống giả định người đọc là người, biết suy luận, biết hỏi lại, biết Google chỗ khó hiểu. Model không làm được những việc đó; cái tên tham số "hợp lý" mà developer nào cũng hiểu thì model sẽ bịa ra giá trị của nó với sự tự tin tuyệt đối.

## 4. Moat thời SaaS: friction

Elvin muốn thêm một điểm mang tính chiến lược về tương lai của enterprise AI, và vì sao anh cho rằng skill có thể đóng góp rất lớn vào hướng đi của enterprise agent nói riêng và enterprise AI nói chung. Để làm vậy, anh nói một chút về moat (con hào phòng thủ của một doanh nghiệp).

Muốn hiểu moat hôm nay hay ngày mai, có thể quay lại lịch sử phần mềm để xem trước đây nó trông thế nào. Thường thì những thứ khó sao chép nhất chính là moat của các công ty phần mềm, thậm chí cả công ty phần cứng. Ví dụ, ai kiểm soát phần cứng, dữ liệu, hay đặc biệt là các integration trong thời SaaS, thì thường là người kiểm soát thị trường.

Vậy moat thật sự ở đây là **friction**: làm cho việc rời khỏi nền tảng của bạn trở nên thật sự khó. Ý cốt lõi là switching cost quá lớn, đến mức khách hàng thấy chuyển đi là quá khó.

Nhưng dạo này ta nghe những tin như Claude Code viết lại một trăm nghìn hay một triệu dòng code từ Python sang Rust. Nói cách khác, chúng ta đang rất, rất giỏi trong việc giảm switching cost. Giờ ta có tool tốt hơn, API tốt hơn, ngôn ngữ tốt hơn, và có thể chuyển đổi trong vài ngày.

![Slide Hardware, data, integrations](https://homus.dev/photos/LC3-P7v3yoI-0400.jpg)

"Hardware, data, integrations": cả ba có chung một điểm, chúng là friction moat và hoạt động bằng cách làm cho việc rời đi trở nên khó. Mỗi năm ta lại giỏi hơn trong việc giảm switching cost nhờ tool, API và open standard tốt hơn. Khách hàng từng bị switching cost giữ chân rồi sẽ thấy friction đủ thấp để rời đi, và khi họ rời đi, họ đi trong sự bực bội.

## 5. Fluency moat và định nghĩa experience

Theo Elvin, skill đang tạo ra một hệ sinh thái hoàn toàn khác: thay vì tạo friction moat, chúng tạo ra **fluency moat**. Ý cốt lõi là mỗi lần dùng, skill của bạn lại làm trải nghiệm tốt hơn cho người đang dùng nền tảng của bạn. Và sự trôi chảy (fluency) đó cộng dồn theo trải nghiệm.

Kết quả thật sự mà người dùng nền tảng của bạn nhận được ở đây chính là experience. Nếu nhìn vào định nghĩa của experience, ta thấy đó là sự hài lòng, hay lượng friction tối thiểu giữa ý định (intent) và kết quả (outcome). Tức là bất cứ điều gì người dùng đang muốn đạt được qua nền tảng của bạn, họ đạt được nó trong thời gian ngắn nhất có thể, hoặc bạn tối ưu toàn bộ lớp hài lòng, toàn bộ lớp trải nghiệm của việc đó.

![Slide Experience với định nghĩa và so sánh friction moat, fluency moat](https://homus.dev/photos/LC3-P7v3yoI-0536.jpg)

Định nghĩa trên slide: experience là mức độ việc dùng nền tảng tạo ra đúng kết quả bạn mong đợi, với friction tối thiểu giữa ý định và kết quả. Friction moat mang tính phòng thủ (bạn làm cho việc rời đi trở nên khó); fluency moat mang tính tấn công (bạn làm cho việc ở lại thật sự tốt hơn).

Nhìn vào "phương trình" này, Elvin chỉ ra rằng friction moat và fluency moat là hai thứ ngược nhau. Friction moat thường là phòng thủ: bạn thiết kế trải nghiệm sao cho người ta không chuyển đi được. Fluency moat là tấn công: bạn làm toàn bộ trải nghiệm thật tốt, tốt tới mức người ta thấy thật sự khó chuyển đi, đơn giản vì họ thích nền tảng đó.

Anh cho rằng cảm giác của sản phẩm (the feel of the thing), hay độ tin cậy của kết quả đi từ điểm xuất phát là ý định của bạn tới kết quả cuối cùng, chính là toàn bộ lớp trải nghiệm. Và skill là một trong những công cụ tốt nhất để, trong ngoặc kép, "commoditize" lớp trải nghiệm đó cho agent. Vì vậy moat thật sự của thời SaaS có thể chính là ý tưởng cốt lõi của skill: bạn đóng gói được cảm giác của nền tảng mình, hay nói cách khác, mức độ đáng tin và ổn định của bạn trong phương trình intent và outcome.

![Slide Skills are the experience layer for agents](https://homus.dev/photos/LC3-P7v3yoI-0632.jpg)

"Skills are the experience layer for agents": cảm giác của sản phẩm và độ tin cậy của kết quả. Moat SaaS rồi sẽ bị commoditize; thứ không bị commoditize là cảm giác trôi chảy và sự tin tưởng khi một nền tảng làm đúng điều bạn mong đợi, và đó là thứ skill mã hoá lại cho agent.

## 6. Teachability, mục mới trong checklist enterprise

Khi ai đó đánh giá một nền tảng, họ thường có một checklist những thứ cần xem, đúng không? Elvin liệt kê:

- Nền tảng của bạn an toàn tới đâu?

- Bạn có tuân thủ đủ loại standard mới đang xuất hiện mỗi tuần không?

- Lớp data governance của tôi thế nào? Dữ liệu của tôi được lưu ở đâu?

- SLA của bạn cam kết những gì?

- Tôi có xem được log của agent không? Còn tracing thì sao?

- Lớp integration thế nào? Bạn có tích hợp được với lớp auth của tôi, thứ đang nối vào các hệ thống on-prem nội bộ không?

Giờ đây, theo Elvin, checklist đó có thêm một mục mới, "một nhân vật mới trong phòng": **teachability**, khả năng dạy được. Lại quay về lớp trải nghiệm cho agent. Ý cốt lõi là: nếu một người mới, hay agent harness của tôi mới đến với một nền tảng, thì harness đó có dễ dàng tiếp nhận phần kiến thức vận hành (operational knowledge) mà bạn đã mã hoá vào skill, áp dụng nó trực tiếp và đi tới kết quả trong chưa đầy vài giây hay không?

Teachability, như vậy, là làm cho trải nghiệm đó dễ nhất có thể, mỗi khi ai đó muốn dùng nền tảng của bạn lần đầu, hay những lần sau đó.

![Slide Teachability is the new enterprise item](https://homus.dev/photos/LC3-P7v3yoI-0704.jpg)

"Teachability is the new enterprise item": khi đánh giá nền tảng, enterprise có sẵn danh sách security, compliance, governance, SLA, audit logging và tracing, integration. Trong thời agentic, danh sách đó thêm một mục: nền tảng có mã hoá được kiến thức vận hành của mình thành dạng agent hành động được không, và dạng đó có govern, version và audit được không.

Gói lại phần này, Elvin cho rằng skill có thể đóng vai trò rất lớn trong thế giới enterprise AI và enterprise agent, theo nghĩa nó có thể định nghĩa moat là gì. Nếu moat ngày nay là về fluency, skill sẽ giúp ở chỗ giá trị bạn mang lại được cộng dồn với mỗi skill bạn thêm vào nền tảng của mình.

## 7. Vì sao cần standard: agent ecosystem đang chờ "React moment"

Đến phần standard, Elvin đùa rằng anh có cảm giác nên bỏ qua slide này với khán giả hôm nay, vì standard là thứ tốt, ai cũng biết rồi.

Anh lấy React làm ví dụ. Nếu quay ngược lại khoảng hai mươi năm, mọi thứ trông gần giống hệ sinh thái LLM và agent bây giờ. Hai mươi năm trước ta chưa có React. React mang đến một triết lý về reactivity và modularity cho cách chúng ta xây app. Với LLM và agent ecosystem cũng vậy: ta chưa có "React moment" đó. Cách phát triển những hệ agent chạy rất dài một cách có hệ thống vẫn còn bỏ ngỏ.

![Slide Why think about standards với HTML 1993 và React](https://homus.dev/photos/LC3-P7v3yoI-0840.jpg)

"Why think about standards?": trên slide ghi HTML ra đời năm 1993, và 20 năm sau React đến với web không chỉ như một framework mà như một triết lý về reactivity và modularity. Hệ sinh thái LLM và agent giờ giống như năm 1993: ghép tool lại với nhau, tìm pattern bằng thử và sai như developer từng vật lộn với HTML và CSS thô, và vẫn chưa tìm được "React moment" của mình.

Như anh đã nói, context engineering, theo một nghĩa nào đó, là một nỗ lực để giải bài toán ấy một cách có tổ chức.

## 8. Context engineering: smart zone và dumb zone

Nếu tóm tắt context engineering là gì, Elvin nói nó gần như là ý tưởng giảm thiểu lượng thông tin chảy vào LLM, đưa vào đúng lúc, để ta có thể lọc, để ta lấp context bằng đúng thông tin, theo đúng dòng chảy, vào đúng thời điểm. (Slide trước đó trích định nghĩa context engineering là "nghệ thuật và khoa học tinh tế của việc lấp context window bằng đúng thông tin cần cho bước tiếp theo", và nhắc rằng vài năm trước nhiều nhà nghiên cứu AI hàng đầu từng dự đoán prompt engineering sẽ lỗi thời, nhưng thực tế nó đã biến thành context engineering.)

Anh đưa ra ví dụ trong hình bên phải slide. Một agent điển hình, dù là Claude Code hay một agent đội anh xây cho khách hàng, thường có system instructions, file CLAUDE.md, vài built-in tool, có thể thêm kết nối tới MCP. Bên trên tất cả là người dùng hay khách hàng đang prompt LLM.

Thường thì khoảng 40% đầu của context là **smart zone**, vùng LLM có khả năng làm tốt. Nhưng khi vượt qua mốc 40% context đã dùng, nó thường rơi vào một vùng (Elvin bật cười) gọi là **dumb zone**. Ý cốt lõi là dù bạn có tới một trăm phần trăm context khả dụng, cứ vượt quá 40% là bạn bắt đầu nhận về những câu trả lời rất ngớ ngẩn.

![Slide Context Engineering với biểu đồ smart zone, dumb zone ở mốc 40 phần trăm](https://homus.dev/photos/LC3-P7v3yoI-0944.jpg)

Cột context của một agent: system instructions, CLAUDE.md, built-in tools, MCP tools và tin nhắn người dùng nằm ở đỉnh. Đường kẻ ngang ở mốc "40% context used" (168k token trên hình) chia "the smart zone" bên trên và "the dumb zone" bên dưới; đáy cột còn 23k token dành cho auto-compact và 32k token dành cho output. Chữ bên trái: model ngày nay rất thông minh nhưng thông minh mà thiếu context thì tê liệt; context engineering là xây hệ thống tự động chọn lọc, lọc và bơm đúng context cho từng bước của agent.

Vậy nên ý chính là đảm bảo bạn không vượt quá 40%, kể cả trước khi bắt đầu làm việc với agent. Hãy tưởng tượng bạn có đủ loại instruction, rất nhiều MCP, rồi thêm một block cho một MCP khác. Thêm một block nữa cho một MCP khác nối ra internet. Thêm một block cho web search và những thứ tương tự. Thế là, dù bạn chưa từng chat với agent câu nào, bạn đã lấp đầy 40% context window. Và khi bạn bắt đầu chat lần đầu tiên, bạn khởi đầu ngay trong dumb zone từ lần gọi đầu tiên.

## 9. Các mảnh của một context tốt và bài toán n nhân n

Tạo một context tốt gồm nhiều mảnh. Elvin lướt qua từng mảnh:

- **Instructions**: thứ đi kèm mặc định, bạn đặt vào system prompt.

- **External data**: có thể người dùng upload vài file PDF, hoặc bất kỳ dạng RAG nào.

- **Execution history**: hiển nhiên LLM cần biết chuyện gì đã xảy ra trong session đó, kết quả của các tool call trước đó là gì, và ta đang ở đâu xét về state.

- **Memory**: các hệ agentic mới nhất có memory, theo nghĩa chúng nhớ được mọi thứ xuyên suốt các cuộc hội thoại.

- **Output schema**: cách đúng để đưa tất cả những thứ này ra cho người dùng.

![Slide Creating great context với sơ đồ Venn context engineering](https://homus.dev/photos/LC3-P7v3yoI-1120.jpg)

"Creating great context": instructions (prompt và hướng dẫn cho model), external data (tài liệu và RAG), execution history (tool call, kết quả, state trong quá khứ), memory systems (context và sự kiện xuyên hội thoại), output schemas (đặc tả response có cấu trúc). Dòng cuối nêu vấn đề ẩn: mỗi agent đều phải nối tới mọi nguồn. Sơ đồ Venn "Everything is Context Engineering!" đặt RAG, prompt engineering, state/history, memory và structured outputs đều nằm trong vòng tròn lớn context engineering.

Như ta thấy, mỗi mảnh lại thêm một mức phức tạp vào những thứ agent phải xử lý, và nó gần như tạo ra một bài toán n nhân n: một agent, hay một LLM, phải được nối với tất cả những thứ này cùng lúc, vào bất kỳ thời điểm nào trong cuộc hội thoại. Elvin nói nếu ta thử đặt mình vào vị trí của LLM thì đó thật sự là một nhiệm vụ khá khó.

Ý cốt lõi của skill là: thay vì hard-code mọi thứ vào một trong các mảnh trên rồi nạp hết vào LLM, ta nạp dần dần (progressively) mỗi khi những instruction đó thật sự cần. LLM được tiếp cận một phần của nó lúc runtime, và có thể nạp phần đó vào bộ nhớ làm việc của mình khi nào cần.

![Slide Skills Definition](https://homus.dev/photos/LC3-P7v3yoI-1232.jpg)

"Skills Definition": thay vì hard-code kiến thức quy trình vào system prompt của agent, hay xây cả một protocol server, bạn viết instruction một lần trong một file Markdown, và bất kỳ agent runtime tương thích nào cũng nạp được nó khi cần.

## 10. Skill giải bài toán context nhờ progressive disclosure

Bài toán mà skill giải là nó cho phép truy cập context phong phú (rich context access). Trong cách làm truyền thống, mọi thứ đi vào context, dẫn tới vấn đề context rot vừa nói. Với skill, các năng lực đó, dù là web search hay một năng lực nào đó không có sẵn trong agent chính, đều sống ở bên ngoài, và LLM hay agent có thể truy cập khi cần.

Elvin so sánh với MCP. Thường thì nếu một agent nối tới các MCP server, và anh nói con số này còn là nhỏ, giả sử 15 MCP server, anh khá chắc là nó tiêu tốn hơn 100.000 token mỗi session chỉ riêng cho tool definition, khi cuộc hội thoại còn chưa bắt đầu. (Slide ghi một khoảng là 50.000 tới 100.000 token mỗi session.) Cùng nỗi đau vận hành đó trở nên rất nhỏ với skill, có lẽ nhỏ đi ít nhất 10 lần, nhờ progressive disclosure.

![Slide Context problem (Skill solves)](https://homus.dev/photos/LC3-P7v3yoI-1256.jpg)

"Context problem (Skill solves)": cách truyền thống bắt mọi context phải nhét vừa prompt, dẫn tới cắt cụt nặng và mất context; với skill, context phong phú sống bên ngoài và được truy cập theo nhu cầu, đúng phần cần. Slide ghi một agent nối 15 MCP server có thể dễ dàng tốn 50.000 tới 100.000 token mỗi session chỉ cho tool definition, còn cùng lượng kiến thức đó đóng thành skill chỉ dùng một phần nhỏ ngân sách context, khiến skill thành phần bổ sung tiết kiệm token cho MCP.

Progressive disclosure nghĩa là chỉ phơi ra metadata của các skill cho agent hay LLM lúc runtime, để metadata đó đóng vai trò như một index trong database. Giống cách index hoạt động trong DB để ta tìm kiếm nhanh, metadata của skill cũng vậy. Dù skill có thể chứa hàng nghìn token, LLM chỉ được tiếp cận phần metadata, thường nằm ở đầu file, và phần còn lại được nạp vào context theo nhu cầu.

![Slide Progressive Disclosure](https://homus.dev/photos/LC3-P7v3yoI-1400.jpg)

"Progressive Disclosure": cơ chế làm skill tiết kiệm context. Agent giữ một index gọn của mọi skill có sẵn (chỉ name, description và path), bơm vào system prompt dưới dạng một đoạn XML nhỏ. Chỉ khi agent xác định một skill liên quan tới task hiện tại, nó mới nạp toàn bộ phần thân SKILL.md; các file tham chiếu bên trong skill chỉ được nạp nếu agent cần chúng trong lúc chạy.

## 11. Mental model shift: một engine, nhiều domain

Điều này tạo ra một sự dịch chuyển mental model cho developer cũng như cho cả ngành, vì skill đang dần trở thành gần như một framework xuyên các nền tảng như Claude Code, Codex, và tất cả đều hỗ trợ cách nhìn này.

Vì sao? Elvin trả lời: các agent chạy dài, kể cả coding agent, đang hoạt động như những general-purpose agent, đúng không? Khi một khách hàng nhờ đội anh xây một supply chain agent, hay một agent trong mảng sản xuất, đội anh không thật sự phải xây một agent riêng cho đúng use case đó. Họ vẫn có thể lấy general-purpose agent chính làm engine, rồi đặt skill lên trên.

![Slide The Mental Model Shift](https://homus.dev/photos/LC3-P7v3yoI-1440.jpg)

"The Mental Model Shift": vì định dạng SKILL.md trung lập về nền tảng, một skill xây cho môi trường agent của DataRobot chạy y hệt trong Claude Code, OpenAI Codex, GitHub Copilot, Cursor, VS Code, Gemini CLI và hơn 20 runtime khác. Tính di động đó là giá trị cốt lõi cho đội enterprise: xây kiến thức một lần, dùng ở mọi nơi agent chạy. Các coding agent chạy dài là general-purpose; muốn dùng chúng ở domain mới thì không cần đổi agent mà đổi skill bên dưới.

Bạn thấy skill tạo ra sự thay đổi góc nhìn về cách xây giải pháp: giờ bạn không thật sự phải xây chính agent, chính cái engine, mà là xây skill cho nó. Và đó là cách để chuyển agent giữa các ngành, giữa các domain khác nhau.

Slide tổng kết phần 1 gom lại ba ý: context engineering (như "prompt engineering 2.0"), giới thiệu skill (qua progressive disclosure), và domain (domain khác nhau, skill khác nhau).

## 12. Skills vs MCP: căn bếp và công thức

Sang phần hai, Elvin nói ngắn gọn về skill so với MCP. Chúng giải những bài toán hơi khác nhau, và anh muốn làm rõ điều đó. Cả MCP lẫn skill đều đến từ Anthropic, nên chúng không cạnh tranh nhau.

MCP giống như định nghĩa các hành động agent nên thực hiện, theo nghĩa nó không thay đổi định nghĩa của agent, không thay đổi agent là gì hay có những năng lực nào. Skill thì khác: nó giúp agent nghĩ về vấn đề và thay đổi. Về cơ bản, qua skill bạn có thể tuỳ biến cách agent hành động, cách nó suy nghĩ về một vấn đề. Skill còn mở ra một cách để tự sửa đổi (self-modify): agent có thể chỉnh hoặc cập nhật chính skill của nó dựa trên trải nghiệm nó đã có khi dùng skill đó.

Ngược lại, MCP là một dạng server nằm ở một môi trường riêng. Agent có quyền dùng tool đó, nhưng không có quyền truy cập vào code của MCP tool ấy.

![Slide Skills vs. MCP với phép so sánh căn bếp](https://homus.dev/photos/LC3-P7v3yoI-1600.jpg)

"Skills vs. MCP": chúng giải những bài toán hơi khác nhau, theo phép so sánh căn bếp. MCP cung cấp căn bếp chuyên nghiệp: quyền dùng tool, nguyên liệu và dụng cụ. Skill cung cấp công thức: hướng dẫn từng bước để làm ra thứ có giá trị.

Tới đây Elvin hỏi: "Carson và mọi người có muốn bổ sung gì không?"

## 13. Một skill có thể chứa luôn cả MCP server

Carson Gee, một người tham gia buổi nói chuyện, nhận lời và nói đây là dịp tốt để trả lời câu hỏi của Joji. Một việc skill làm được là phơi ra một MCP server ngay trong file SKILL.md của nó, kiểu như: "Đây là MCP server của bạn." Nó cũng có thể đơn giản là đổ thẳng các tool vốn nằm trong MCP server vào skill, và agent sẽ chạy chúng. Nghĩa là skill thật ra có thể phục vụ và tự tạo ra MCP server của riêng nó, như một phần của skill.

Carson nói đây là lý do anh rất hào hứng với độ "robust" của skill so với MCP. Không chỉ là chuyện self-modification, vì cái đó có thể tái tạo bằng MCP, đúng không? MCP cộng với memory, caching, tuỳ biến theo người dùng, và dùng những tool call mà bản thân chúng là agent. Những agent đó thậm chí có thể có skill riêng, mà bạn chỉ định như một phần của tool: hãy nạp những skill này rồi chạy việc này. Anh gọi đó là một kiểu quan hệ "loạn luân" giữa hai thứ.

Nhưng dù vậy, skill vẫn tồn tại như một thứ riêng biệt, có thể vận hành, template hoá code, chạy code, chạy MCP server, build, tạo và chạy, và nhờ đó thêm MCP mới vào context window gốc của chính nó, tất cả chỉ qua skill. Theo Carson, nó giống một gói hoàn chỉnh về những gì một agent có thể trở thành. Về bản chất, anh cười, "Copilot cũng có thể là một skill".

Quan hệ hai chiều mà Carson mô tả: một skill có thể chứa instruction, code, chính các tool của một MCP server, hay lời giới thiệu tới một MCP server; ngược lại, một MCP tool có thể là một agent tự nạp skill riêng của nó.

## 14. Khi nào vẫn cần MCP, và lý lẽ "agent không cần nhiều tool"

Elvin chốt lại nguyên tắc: hãy dùng skill khi phần khó chỉ nằm ở việc suy luận, hay suy nghĩ theo đúng cách. Còn MCP giải một bài toán khác cho chúng ta: authentication, quyền truy cập, hoặc "mã lực" tính toán. Nếu bạn muốn thật sự cô lập tiến trình cho một phần việc cần rất nhiều tài nguyên, thì để phần đó có server riêng là cách dễ.

Cuộc trao đổi tiếp tục: server riêng đó vẫn tương tác được với skill, đúng không? Skill chạy trên máy của agent. Nên có một chút "vòng vo" qua lại giữa hai thứ, nhưng chúng vẫn đủ khác nhau để MCP được sống trong thế giới riêng của nó và là một mẩu code production, còn skill thì được là thứ linh hoạt, khả thi. MCP là standard cũ hơn, và nó vẫn chưa theo kịp cho tới khi nó thích nghi, điều nó đang tích cực làm. Còn skill thì chẳng ai biết chúng mạnh tới mức nào cho tới khi đã có 85.000 skill ngoài kia.

Nhưng bạn vẫn cần năng lực hosting, đúng không? Máy tính cá nhân không có GPU đủ mạnh để làm những tác vụ đáng kể, hay để semantic search trên 400 terabyte tài liệu. Trong những trường hợp đó vẫn cần một MCP server được host một cách chắc chắn. Và cách để agent dùng MCP server đó là dùng skill để làm progressive disclosure cho chính MCP server ấy, server có ổ đĩa 500 terabyte, hay quyền dùng 75 GPU, hay bất cứ thứ gì tool đó cần. Vậy là hai thứ vẫn gắn với nhau theo cách cả hai đều có chỗ dùng và đều không thể thiếu.

Hai câu hỏi để quyết định: MCP server đó có cần truy cập dữ liệu trong một môi trường bị hạn chế, như hồ sơ y tế hay bất cứ thứ gì máy cá nhân của bạn không được truy cập không? Nó có cần những tài nguyên mà agent nơi bạn đang chạy không thể có không? Về bản chất, đó là cách chạy từ xa, và chạy từ xa thì lúc nào cũng có lợi ích riêng.

Nguyên tắc chọn giữa skill và MCP rút ra từ phần trao đổi: skill cho phần suy luận và quy trình; MCP server được host riêng cho auth, dữ liệu hạn chế và tài nguyên tính toán nặng, và skill có thể là cửa giới thiệu agent tới server đó.

Elvin đưa thêm một lý lẽ cuối cùng chống lại MCP, có thể sẽ thú vị: hoá ra các agent hiện tại không cần nhiều tool. Nếu xem cách Codex hay Claude Code được phát triển, bạn sẽ thấy chỉ có một nhúm tool đang được chạy. Không phải có hàng trăm tool chạy trong một MCP server riêng. Theo anh, điều đó cũng chứng minh rằng một thư mục skill hay thư mục năng lực thông thường, với các lựa chọn khác nhau, có thể thay thế MCP, miễn là bạn có một base reasoning model tốt.

## 15. Hai reader và ba level của một skill

Elvin nói skill có hai reader khác nhau. Phần đầu tiên là front matter, phần trên cùng của skill. Anh chỉ vào một ví dụ, một trong các skill của đội anh: front matter gần như là một phần của file MD, nhưng nó đóng vai trò index cho skill đó. Lúc runtime, đây là thứ duy nhất được nạp vào context của agent, vào system prompt của agent. Còn phần thân của skill thì được nạp vào context của agent sau đó.

Khi anh nói có hai reader, reader thứ nhất là runtime của agent, tức là system prompt. Reader của phần này không phải bản thân context: nó không đốt nhiều context, vì chỉ là một đoạn XML nhỏ, thường chưa tới 100 token, và agent có sẵn nó trước khi bắt đầu chạy. Reader thứ hai là phần thân Markdown, được LLM đọc nếu skill được kích hoạt. Nếu LLM nghĩ rằng ta cần skill đó, nó sẽ được nạp.

![Slide 2 Different Readers](https://homus.dev/photos/LC3-P7v3yoI-2048.jpg)

"2 Different Readers": YAML frontmatter do runtime đọc lúc khởi động, được parse bằng máy và bơm vào mọi session với khoảng 100 token; agent dùng nó để dựng index những gì có sẵn. Markdown body do LLM đọc khi kích hoạt: instruction bằng ngôn ngữ tự nhiên, workflow từng bước, ví dụ code để khớp pattern, chỉ nạp khi skill được kích hoạt. Dòng cuối: description là toàn bộ "bề mặt" để skill được tìm thấy, hãy viết nó như câu trả lời cho "khi nào nên dùng cái này?" chứ không phải "cái này làm gì?".

Như vậy level một chưa tới 100 token. Level hai, lúc kích hoạt, thường dưới 5K token. Level ba là script. Script có thể đi theo hai kiểu. Với Claude Code chẳng hạn, script là thứ chạy được: Claude SDK hay Claude Code có thể chạy file get_deployment_features.py, rồi chỉ đưa output của lần chạy đó trở lại context. Nhưng ở nhiều nền tảng khác, script vẫn là code nhưng không chạy được, nó chỉ đóng vai trò ví dụ cho agent.

Tóm lại, ba level để quản lý một skill đơn giản: thứ nhất là front matter, thứ hai là phần thân, thứ ba là script hoặc context bổ sung.

![Slide Anatomy of a Basic Skill với cấu trúc SKILL.md của skill datarobot-predictions](https://homus.dev/photos/LC3-P7v3yoI-2120.jpg)

"Anatomy of a Basic Skill": level 1 luôn được nạp (khoảng 100 token), level 2 nạp khi kích hoạt (dưới 5.000 token), level 3 nạp theo nhu cầu (gần như không giới hạn). Bên phải là cấu trúc SKILL.md của skill datarobot-predictions: name là khoá index lúc runtime và phải trùng tên thư mục; description là tín hiệu để agent khớp, viết như một câu truy vấn; "When to use" là tiêu chí kích hoạt (rõ ràng tốt hơn ngầm hiểu); "Quick Start" là đường chạy mặc định, đánh số từng bước; "Common patterns" là thứ agent chạy, vì pattern để khớp tốt hơn văn xuôi; thư mục scripts/ là context và tham chiếu ở hầu hết runtime, chỉ Claude Code chạy trực tiếp.

Khung skill trên slide, có thể dùng làm mẫu:

```
---
name: datarobot-predictions
description: Tools for making predictions...
---
# DataRobot Predictions Skill

## When to use this skill
- Make predictions from deployed models
- Generate prediction dataset templates
- Validate prediction data before scoring

## Quick Start
1. Get deployment features
2. Generate template
3. deployment.predict_batch(...)

## Common patterns
import datarobot as dr
deployment = dr.Deployment.get(id)
predictions = deployment.predict_batch(df)

See [references/patterns.md](...)

scripts/
get_deployment_features.py
generate_prediction_data_template.py
validate_prediction_data.py
```

Định dạng này theo [Agent Skills specification](https://agentskills.io/specification); bộ skill thật của DataRobot nằm ở [datarobot-oss/datarobot-agent-skills](https://github.com/datarobot-oss/datarobot-agent-skills).

## 16. Hệ sinh thái skill và trường hợp OpenClaw

Phần bốn nói một chút về hệ sinh thái và những gì đang diễn ra quanh nó. Hiện có hơn 26 nền tảng hỗ trợ skill, như Claude Code, Codex, Copilot, Gemini CLI và những cái khác. Theo Elvin, tới thời điểm này có lẽ đã có khoảng 100.000 skill ngoài kia, và đã có những marketplace nơi người ta bán skill lấy tiền. Anh nhắc rằng Devin Jensen đã nói về ClawHub, registry skill của OpenClaw. Và DataRobot cũng là một phần của hệ sinh thái: đội anh đã công bố repository agent skill mã nguồn mở của mình.

![Slide Skills Ecosystem](https://homus.dev/photos/LC3-P7v3yoI-2240.jpg)

"Skills Ecosystem": hơn 26 nền tảng, gồm Claude Code, OpenAI Codex, GitHub Copilot, Cursor, VS Code, Gemini CLI, Windsurf, Roo Code, Goose và các nền tảng khác; skills.sh và agensi.io là marketplace và leaderboard cho các skill phổ biến, cài bằng một lệnh (npx skills install <name>); ClawHub, registry skill của OpenClaw, tính tới tháng 3/2026 có hơn 22.400 skill do cộng đồng đóng góp; DataRobot công bố repository agent skill mã nguồn mở tại github.com/datarobot-oss/datarobot-agent-skills.

Theo Elvin, OpenClaw là minh hoạ rất tốt cho cả sức mạnh lẫn rủi ro của agent skill. OpenClaw giờ đã trở thành repository có nhiều star nhất, vượt cả Linux và React. Anh thấy họ làm context engineering theo nhiều cách tuyệt vời, chạy được xuyên các app và ứng dụng chat khác nhau. Nhưng có lẽ vài chi tiết trong sub-agent của họ, thứ phục vụ mục đích giữ context sạch, cùng với các skill tự tiến hoá (self-evolving), mới là điều khiến bất kỳ ai đọc code của nó đều thấy ấn tượng.

Việc nó có thể tự chữa lành (self-heal) dựa trên trải nghiệm với skill, và tự viết skill mới để mở rộng năng lực của mình, theo Elvin, có phần đáng sợ. Nhưng điều để lại ấn tượng tốt là: đây chỉ là một coding agent có quyền dùng khoảng 10 tool, vậy mà làm được mọi thứ cho bạn, miễn là bạn đặt skill lên trên nó.

![Slide Openclaw uses Skills](https://homus.dev/photos/LC3-P7v3yoI-2344.jpg)

"OpenClaw uses Skills": OpenClaw bơm một danh sách XML gọn của mọi skill hợp lệ theo đúng pattern progressive disclosure mà Agent Skills spec định nghĩa. Nó có năng lực mà cộng đồng gọi là self-healing hay self-extension: nếu chưa có skill cho một task người dùng yêu cầu, agent có thể soạn một skill mới từ cuộc hội thoại, đóng gói những gì nó học được vào một SKILL.md để dùng cho các session sau. (Slide trước đó gọi OpenClaw là một personal AI agent mã nguồn mở, một trong những dự án GitHub tăng trưởng nhanh nhất lịch sử vào đầu năm 2026.)

Điều đó thay đổi cách ta nghĩ về giải pháp cho khách hàng, cho enterprise: ta chỉ cần phát triển một agent tốt làm nền cho mọi thứ, rồi xây skill lên trên để giải các bài toán theo domain, hay bất cứ thứ gì khách hàng đang yêu cầu.

## 17. Có nên để LLM tự viết skill? Và các rủi ro

Vậy nếu OpenClaw tự viết được skill, thì cứ để nó viết, đúng không? Elvin nói điều này chạm tới một thực tế: thường ta vẫn cần con người viết skill. Có nhiều nghiên cứu về chủ đề này được công bố gần đây, và chúng cho thấy skill do LLM sinh ra thật ra làm giảm hiệu năng của LLM, theo nghĩa nó dùng nhiều token hơn. LLM tốn nhiều thời gian hơn để đi vòng và suy luận về vấn đề, thay vì được skill giúp làm nhanh hơn hay dùng ít context hơn.

![Slide Skills that don't suck](https://homus.dev/photos/LC3-P7v3yoI-2440.jpg)

"Skills that don't suck": nếu agent tự viết được skill, sao còn cần người viết? Không phải LLM viết dở; vấn đề là skill do LLM sinh ra mã hoá những pattern chung chung từ dữ liệu training, trong khi giá trị của một skill DataRobot nằm ở kiến thức nội bộ không có ở đâu khác. Slide dẫn một nghiên cứu của ETH Zurich thử 138 file agent và thấy skill do LLM sinh ra thực sự làm giảm hiệu năng, đồng thời tốn thêm hơn 20% token.

Cũng có rất nhiều rủi ro cần cân nhắc. Nếu LLM tự viết rồi tự chạy skill của nó, hiển nhiên có cả tấn rủi ro về prompt injection, vì ai bây giờ cũng viết skill rồi publish ra ngoài. Elvin khá chắc mọi người đã thấy trên tin tức những chuyện không hay xảy ra với OpenClaw.

Rủi ro tiếp theo là không có isolation. Một ưu điểm của MCP là bạn cô lập tiến trình của MCP khỏi agent, còn với skill thì mọi thứ xảy ra trên laptop của bạn, trên agent của bạn, trong môi trường của bạn.

Và cuối cùng, các marketplace vẫn thiếu kiểm soát xác minh. Giống như NPM từng đáng sợ mười năm trước: bạn vẫn phải xem số star hay ai là người phát triển trước khi tải một package. Skill cũng vậy.

![Slide Risks with Agent Skills](https://homus.dev/photos/LC3-P7v3yoI-2504.jpg)

"Risks with Agent Skills": prompt injection qua SKILL.md (một skill độc có thể nhúng instruction ghi đè hành vi dự kiến của agent); không có isolation giữa các skill (khác mô hình cô lập tiến trình của MCP, skill dùng chung môi trường chạy và credential của agent); các registry cộng đồng như ClawHub thiếu verification control của repository phần mềm enterprise, dù nay đã có giải pháp bảo mật quét từng skill và gắn điểm rủi ro; và scope creep từ hành động tự động, khi agent được cấp quyền rộng có thể làm những việc vượt ra ngoài ý định của người dùng.

Về các biện pháp an toàn hiện tại khi cài skill từ registry, xem [tài liệu skill và security của OpenClaw](https://docs.openclaw.ai/tools/skills).

## 18. Closing thoughts

Elvin khép lại bằng vài ý:

- **Context là một ngân sách.** Context gần như là một tài nguyên hữu hạn, ta cần lọc thông tin đưa vào một cách cẩn thận. Context dài hơn chắc chắn không có nghĩa là tốt hơn.

- **Mọi thứ không liên quan đều kéo sự chú ý.** Mỗi file không liên quan, mỗi lần web search không liên quan, hay mỗi error message đều kéo sự chú ý của agent đi, và bạn mất rất nhiều sức suy luận.

- **Skill bổ sung cho MCP**, ít nhất là ở thời điểm hiện tại.

- **Một skill chỉ tốt bằng người đã viết ra nó**, theo kinh nghiệm của đội anh.

- **Skill là phần mềm**, có thể mất nhiều tuần để xây. Vì vậy ta nên thật sự bắt đầu version skill, eval và test chúng, và đầu tư viết skill tốt.

![Slide Key Takeaways](https://homus.dev/photos/LC3-P7v3yoI-2600.jpg)

"Key Takeaways": context là ngân sách, không phải một container; dài hơn không có nghĩa là tốt hơn. Mỗi file đọc không liên quan đều cạnh tranh sự chú ý của agent. Skill bổ sung cho MCP. Một skill chỉ tốt bằng người viết ra nó. Skill là phần mềm, có thể mất nhiều tuần, nhiều tháng để xây. Hãy đối xử với skill như phần mềm: versioning, evaluation, composability.

Anh nhắc rằng có vài tài liệu đội anh đã dùng khi chuẩn bị talk (liệt kê ở phần nguồn bên dưới), và cảm ơn mọi người.

## Sources and links

- [Trang talk chính thức trên ai.engineer](https://ai.engineer/talks/LC3-P7v3yoI)

- [Video gốc của talk](https://www.youtube.com/watch?v=LC3-P7v3yoI)

- [DataRobot Agent Skills (datarobot-oss/datarobot-agent-skills)](https://github.com/datarobot-oss/datarobot-agent-skills)

- [Agent Skills specification](https://agentskills.io/specification)

- [Context Rot (Chroma Research)](https://www.trychroma.com/research/context-rot)

- [Mintlify: phân tích agent traffic trên các trang docs](https://www.mintlify.com/blog/state-of-ai)

- [The rise of "context engineering" (LangChain)](https://blog.langchain.com/the-rise-of-context-engineering/)

- [Context Engineering for Agents (Lance Martin)](https://rlancemartin.github.io/2025/06/23/context_engineering/)

- [How Long Contexts Fail (Drew Breunig)](https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-how-to-fix-them.html)

- [How to Fix Your Context (Drew Breunig)](https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.html)

- [Skill authoring best practices (Claude docs)](https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices)

- [Skill authoring end-to-end (Strapi)](https://strapi.io/blog/what-are-agent-skills-and-how-to-use-them)

- [Model Context Protocol](https://modelcontextprotocol.io/)

- [skills.sh](https://skills.sh/) và [agensi.io](https://agensi.io/), marketplace skill được nhắc trên slide

- [OpenClaw trên GitHub](https://github.com/openclaw/openclaw) và [tài liệu skill của OpenClaw](https://docs.openclaw.ai/tools/skills)

- [SkillsBench](https://arxiv.org/abs/2602.12670), benchmark đánh giá skill được trang talk dẫn làm đọc thêm