# Khi nào dùng Skills, khi nào dùng Tools trong Agent Framework

[Rasmus Wulff Jensen](https://homus.dev/speakers/rasmus-wulff-jensen) · [AI in C# (Rasmus Wulff Jensen)](https://homus.dev/orgs/ai-in-c-rasmus-wulff-jensen)

> Đo input token của cùng ba capability dưới dạng skills và tools trong Microsoft Agent Framework (C#), từ 3 tới 300 capability, để biết khi nào chọn bên nào.

Topics: Skills, Agents, Context Engineering

Canonical: https://homus.dev/talks/when-to-use-skills-and-when-to-use-tools-in-agent-framework

## 1. Vì sao có video này: skills, tools và MCP gần như là một

Rasmus mở đầu video trên kênh AI in C# (đăng ngày 14/10/2026) bằng câu hỏi khi nào nên dùng skills và khi nào nên dùng tools trong Microsoft Agent Framework. Lý do anh làm video này là một video trước đó của chính anh, nơi anh định nghĩa các khái niệm này và cách chúng hoạt động. Trong video đó anh có nói rằng ở phía sau, hai thứ này thực ra ít nhiều là một. Anh cũng tạm xếp MCP vào nhóm tools, vì theo anh về bản chất MCP chính là tools, chỉ là một cách khác để định nghĩa chúng. Và anh đã nói, hơi chung chung, rằng trong phần lớn trường hợp thì tools là lựa chọn tốt nhất.

![Ảnh bìa: chữ WHEN TO USE? SKILLS TOOLS, một robot đứng giữa, dòng AGENT FRAMEWORK IN C#](https://homus.dev/photos/Y2EAsbeyolw-0003.jpg)

Ảnh mở đầu video: "When to use? Skills / Tools", bên trái là biểu tượng tài liệu cho skills, bên phải là biểu tượng code, cờ lê và API cho tools, dưới góc ghi "Agent Framework in C#" (video đăng ngày 14/10/2026).

Nhưng theo Rasmus (video đăng ngày 14/10/2026), nhiều người vẫn không nghĩ vậy. Họ cho rằng skills tốt hơn và rẻ hơn tools và MCP. Trên slide anh dựng đúng câu đó thành một "Claim": "Skills are better and cheaper than Tools/MCP!!!". Vì vậy anh muốn đi vào giải thích kỹ hơn một chút, và cách anh chọn là đo thật.

## 2. Đo thật: ba capability về thời tiết, đếm input token

Thí nghiệm của Rasmus (video đăng ngày 14/10/2026): đưa cho AI ba capability về thời tiết, một lần dưới dạng skills và một lần dưới dạng tools, rồi xem mỗi cách tốn bao nhiêu input token. Anh chỉ đo input token, vì theo anh output token sẽ như nhau ở cả hai cách, nó phụ thuộc vào AI chứ không phụ thuộc vào cách ta đưa capability. Và nếu đó là một tool lớn với rất nhiều dữ liệu bên trong thì cũng không quan trọng, vì đằng nào AI cũng phải đọc chúng ở cả hai cách.

![Slide Let's Actually measure it! giving an AI 3 capabilities about the weather as Skills and as Tools](https://homus.dev/photos/Y2EAsbeyolw-0103.jpg)

Slide đặt ra thí nghiệm: "Let's Actually measure it!", tức đưa cho AI ba capability về thời tiết, một lần dưới dạng Skills và một lần dưới dạng Tools (video đăng ngày 14/10/2026).

Nói cách khác, theo Rasmus (video đăng ngày 14/10/2026), thứ tạo ra khác biệt về chi phí là cách ta đưa capability cho AI. Chuyện này không liên quan gì tới chất lượng hay độ lớn của tool, ít nhất là theo nghĩa tool trả về cả một cuốn sách hay chỉ trả về một chữ "hello": phần đó sẽ giống hệt nhau ở cả hai phía. Rồi anh đi vào phần implementation bằng skills trước.

Logic của phép đo theo Rasmus: nội dung một tool hay một resource trả về thì AI đọc như nhau ở cả hai cách, nên phần còn lại để so là chi phí giới thiệu capability cho model (video đăng ngày 14/10/2026).

## 3. Bản skills: một AgentInlineSkill tên weather-skills

Ở bản skills, Rasmus dùng `AgentInlineSkill` do team Agent Framework làm (theo video đăng ngày 14/10/2026). Anh nói mình cũng có thể dùng implementation skills của riêng anh, hoặc tự viết lấy, nhưng ở đây anh chỉ tạo một skill tên `weather-skills`, với description đơn giản là dùng cho các việc liên quan tới thời tiết ("Use for weather-related stuff").

![Code C#: AgentInlineSkill weather-skills với AddScript, hai AddResource, AgentSkillsProvider và CreateAgent](https://homus.dev/photos/Y2EAsbeyolw-0151.jpg)

Slide "Skills Implementation of 1 Action and 2 pieces of information": một `AgentInlineSkill` với một script và hai resource, một `AgentSkillsProvider` tắt cả ba loại approval, và agent nhận provider qua `AIContextProviders`. Góc dưới là hàm `GetWeatherForCity` luôn trả về "It is sunny and 19 Degrees" (video đăng ngày 14/10/2026).

Trong demo (video đăng ngày 14/10/2026), instructions bên trong skill nói rằng: có `get-weather-for-city` để lấy thời tiết; có resource `how-we-predict-weather` để nói cho user biết thời tiết được dự đoán thế nào; và có resource `who-is-in-charge-of-the-weather` để nói ai phụ trách thời tiết. Sau đó anh thêm script vào skill, và script ở đây chỉ là một delegate bình thường trong C#.

Rasmus giải thích (video đăng ngày 14/10/2026): nếu đây là một skill dựa trên folder và file thì script có lẽ sẽ là, ví dụ, một script Python. Nhưng ở đây anh làm theo cách in-memory để mô phỏng một tool càng sát càng tốt. Tiếp đó anh thêm hai resource. Resource "how we predict the weather" nói rằng ta chỉ việc nhìn ra cửa sổ xem trời mưa hay nắng. Resource "who is in charge of the weather" thì anh nói là một ông nào đó mặc áo len; trên màn hình chuỗi này ghi "Some odd guy in an orange sweater". Anh nói không có gì quan trọng ở đây cả, anh chỉ đang tạo vài tool cho có.

Đoạn code trên slide (video đăng ngày 14/10/2026), chép nguyên văn:

```
AgentInlineSkill skill = new(
name: "weather-skills",
description: "Use for weather-related stuff",
instructions: """
Use 'get-weather-for-city' to get the weather
Use resource 'how-we-predict-weather' to tell user how weather is predicted
Use resource 'who-is-in-charge-of-the-weather' to tell who is in charge
""");
skill.AddScript("get-weather-for-city", WeatherStuff.GetWeatherForCity);
skill.AddResource("how-we-predict-weather", "We look out the window and see it it rain or is sunny");
skill.AddResource("who-is-in-charge-of-the-weather", "Some odd guy in an orange sweater");

AgentSkillsProvider provider = new([skill], options: new AgentSkillsProviderOptions
{
DisableLoadSkillApproval = true,
DisableReadSkillResourceApproval = true,
DisableRunSkillScriptApproval = true
});

AIAgent agent = agentFactory.CreateAgent(new AgentOptions
{
Model = "gpt-6-luna",
AIContextProviders = [provider],
RawHttpCallDetails = details => { Console.WriteLine(details.RequestData); },
RawToolCallDetails = Console.WriteLine
});
```

Hàm script ở góc slide:

```
public static string GetWeatherForCity(string city)
{
return "It is sunny and 19 Degrees";
}
```

## 4. Skill provider, tắt approval và gắn vào agent

Rasmus nhấn mạnh lại (video đăng ngày 14/10/2026): dù resource chỉ là một dòng như ở đây hay là 10.000 dòng chữ, thì theo anh một tool và một skill sẽ đưa nội dung đó cho AI theo đúng cùng một cách, và số token cho phần đó sẽ như nhau.

Có skill rồi, trong demo (video đăng ngày 14/10/2026) anh biến nó thành một agent skill provider (`AgentSkillsProvider`), đồng thời tắt auto approval (trên slide là ba option `DisableLoadSkillApproval`, `DisableReadSkillResourceApproval`, `DisableRunSkillScriptApproval` đặt bằng `true`) để không mất thời gian vào chuyện duyệt. Rồi anh đưa provider đó cho agent; agent nhận nó dưới dạng một AI context provider, tức dòng `AIContextProviders = [provider]` trên slide.

Trong cùng demo (video đăng ngày 14/10/2026), anh cũng cho in ra raw HTTP call và raw tool call (hai dòng `RawHttpCallDetails` và `RawToolCallDetails`) để xem thật sự chuyện gì xảy ra. Lý do, theo Rasmus: khi ta gọi agent này, ví dụ hỏi thời tiết, thì nó phải làm nhiều hơn là biết ngay câu trả lời. Skill chỉ nằm đó; ta vẫn phải kích hoạt việc dùng skill, đọc xem bên trong có gì, gọi script của nó, và cứ thế tiếp.

Cách Rasmus nối bản skills trong video (đăng ngày 14/10/2026): skill vào provider, provider vào agent, và mọi request gửi tới model được in ra console để đếm token.

## 5. Skill gửi gì cho model: instructions và ba tool đọc skill

Khi gọi agent và xem request, Rasmus chỉ ra rằng dù anh không hề thêm instructions nào, request vẫn có một khối instructions. Theo anh (video đăng ngày 14/10/2026), đây là cách Agent Framework trình bày instructions cho skills. Anh thấy nó hơi dài dòng (verbose); có thể viết gọn hơn, nhưng anh dùng đúng bản mặc định (out of the box), và theo anh phần lớn người xem có lẽ cũng sẽ làm vậy. Anh nói có những cách để rút gọn phần này một chút.

![Slide hai khung: Instructions với available_skills và Tools với load_skill, read_skill_resource, run_skill_script](https://homus.dev/photos/Y2EAsbeyolw-0543.jpg)

Slide "Skills have the token-cost of announcing names and description + Tools to Read Skill, [Resources] and [Execture Scripts]": bên trái là instructions mặc định liệt kê skill `weather-skills`, bên phải là ba tool `load_skill`, `read_skill_resource` và `run_skill_script` được gửi kèm (video đăng ngày 14/10/2026).

Khối instructions trên slide, chép nguyên văn:

```
You have access to skills containing domain-specific knowledge and capabilities.
Each skill provides specialized instructions, reference documents, and assets for specific tasks.

weather-skills
Use for weather-related stuff

When a task aligns with a skill's domain, follow these steps in exact order:
- Use `load_skill` to retrieve the skill's instructions.
- Follow the provided guidance.
- Use `read_skill_resource` to read any referenced resources, using the name exactly as listed
(e.g. `"style-guide"` not `"style-guide.md"`, `"references/FAQ.md"` not `"FAQ.md"`).
- Use `run_skill_script` to run referenced scripts, using the name exactly as listed.

Only load what is needed, when it is needed.
```

Về bản chất, theo Rasmus (video đăng ngày 14/10/2026), khối này chỉ nói: ta có những skill này, và để nạp chúng thì có một tool load skill, một tool read skill resource và một tool run skill script. Và đây là điều anh cho rằng phần đông mọi người hiểu sai: chỉ vì nó là skill không có nghĩa là không cần tool. Ta vẫn cần vài tool để đọc được skill đó.

Ba tool này đi kèm sẵn (theo video đăng ngày 14/10/2026). Rasmus không định nghĩa tool nào cả; chúng xuất hiện chỉ vì anh đưa skills provider vào. Sẽ có một tool để nạp skill, một tool để đọc resource của skill, và một tool để chạy script. Trong trường hợp của anh, mọi thứ nằm trong memory. Nếu là skill dựa trên file thì load skill sẽ xuống ổ cứng đọc một file, read resource sẽ đọc một file con nào đó, và run script sẽ đọc rồi thực thi một script trong folder đó. Dù làm theo cách nào thì chuyện cũng sẽ diễn ra như vậy.

## 6. Ba câu hỏi và số token của bản skills

Trong demo (video đăng ngày 14/10/2026), Rasmus hỏi agent ba câu. Câu đầu chỉ là "Hi", để xem chuyện gì xảy ra khi có skill nhưng không cần dùng tới. Câu thứ hai là thời tiết được dự đoán thế nào. Câu thứ ba là thời tiết ở Paris ra sao.

![Khung Result: ba câu hỏi Hi, How is the Weather Predicted, What is the Weather like in Paris với tool call và Input Tokens 310, 1471, 1442](https://homus.dev/photos/Y2EAsbeyolw-0703.jpg)

Khung "Result" của bản skills trong demo (video đăng ngày 14/10/2026): "Hi" tốn 310 input token; câu về cách dự đoán thời tiết gọi `load_skill` rồi `read_skill_resource`, tốn 1471; câu về Paris gọi `load_skill` rồi `run_skill_script`, tốn 1442.

Kết quả theo số đo của Rasmus trong setup của anh (video đăng ngày 14/10/2026): nói "Hi" thì agent trả lời lại và dùng 310 token. Hỏi thời tiết được dự đoán thế nào thì agent gọi tool `load_skill` để đọc skill, tức đọc phần instructions của skill. Rồi nó gọi `read_skill_resource` để đọc đúng resource "how we predict the weather". Có đủ context rồi, AI trả lời rằng có thể "dự đoán" thời tiết bằng cách nhìn ra ngoài xem trời mưa hay nắng. Lượt này dùng 1.471 token trong trường hợp của anh.

Cuối cùng, hỏi thời tiết ở Paris thì agent lại nạp skill, rồi chạy script, và script của anh luôn trả về trời nắng 19 độ bất kể thế nào; trên màn hình agent trả lời "It's sunny in Paris and 19°C" (demo trong video đăng ngày 14/10/2026). Theo Rasmus, đây chính là những gì gửi lên LLM cùng với các tin nhắn của anh: phần metadata cần để có và dùng được skill. Đó là thứ ta đang trả token cho nó, và cũng là thứ mà lời khẳng định kia cho là rẻ hơn và nhanh hơn.

Rasmus dặn người xem nhớ ba con số này vì anh sẽ đưa chúng vào một slide riêng ở phía sau. Anh đọc to là 310, 1471 và 1472; con số thứ ba trên màn hình và trên slide tổng kết là 1442 (theo số đo trong video đăng ngày 14/10/2026).

## 7. Bản tools: ba tool thường, cùng tên, cùng mô tả

Tiếp theo, trong video (đăng ngày 14/10/2026), Rasmus làm đúng việc đó bằng tools: giả sử ta không biết skills là gì và chỉ muốn làm việc này. Vẫn cần một action và hai mẩu thông tin, và theo anh có thể làm theo cách đơn giản hơn một chút, vì chỉ cần tạo các tool bình thường.

![Code C#: CreateAgent với Tools gồm ba AIFunctionFactory.Create và ba hàm GetWeatherForCity, HowToPredictWeather, WhoIsInCharge](https://homus.dev/photos/Y2EAsbeyolw-0817.jpg)

Slide "Tools Implementation of 1 Action and 2 pieces of information": agent nhận thẳng ba tool qua `AIFunctionFactory.Create`, và ba hàm C# nhỏ bên dưới trả về cùng nội dung như script và hai resource ở bản skills (video đăng ngày 14/10/2026).

Trong demo (video đăng ngày 14/10/2026), tool đầu tiên là get weather for city, đúng y code cũ. "How to predict the weather" không thể là resource nữa, nên anh tạo một tool trả về cùng thông tin đó. Còn "who's in charge" thì không được gọi tới ở bất kỳ lúc nào, nhưng vẫn phải đưa vào để agent có nó. Tóm lại, thay vì skill provider đưa ra các tool đọc skill, anh tự tạo ba tool ở đây với cùng tên và mô tả gần như giống hệt.

Code trên slide (video đăng ngày 14/10/2026), chép nguyên văn:

```
AIAgent agent = agentFactory.CreateAgent(new AgentOptions
{
Model = "gpt-6-luna",
Tools = [
AIFunctionFactory.Create(WeatherStuff.GetWeatherForCity, "get-weather-for-city", "Get the weather for a given city"),
AIFunctionFactory.Create(HowToPredictWeather, "how-we-predict-weather", "How we predict the Weather"),
AIFunctionFactory.Create(WhoIsInCharge, "who-is-in-charge-of-the-weather", "Who is in charge of the weather"),
],
RawHttpCallDetails = details => { Console.WriteLine(details.RequestData); },
RawToolCallDetails = Console.WriteLine
});
```

```
public static string HowToPredictWeather()
{
return "We look out the window and see it it rain or is sunny";
}

public static string WhoIsInCharge()
{
return "Some odd guy in an orange sweater";
}
```

Rasmus nhận xét (video đăng ngày 14/10/2026) cách này rõ ràng trông dễ viết hơn bản trước, nhưng điều đó không thật sự quan trọng; câu hỏi là ta có nhận được thông tin tốt hơn hay tốn token vô ích hay không.

## 8. Kết quả bản tools và so sánh đầu tiên

Với bản tools, thứ gửi lên model là ba tool này thay cho ba tool đọc skill. Theo Rasmus (video đăng ngày 14/10/2026), chúng trông gần giống các tool ta đã thấy ở phía skills: cũng là ba tool. Chỉ khác là bên kia ba tool dùng để nạp và đọc skill, còn bên này ba tool trực tiếp lấy thời tiết cho một thành phố, cho biết cách dự đoán thời tiết và cho biết ai phụ trách thời tiết. Ta gửi chúng dưới dạng tool, thay vì gửi các tool để đọc skill.

![Slide Tools have the token-cost of announcing the tools: khung Tools JSON với ba function và khung Result với Input Tokens 85, 229, 223](https://homus.dev/photos/Y2EAsbeyolw-1023.jpg)

Slide "Tools have the token-cost of announcing the tools (+ optionally some instructions if hard to know when to use)": ba định nghĩa tool trong JSON, và khung Result cho thấy "Hi" tốn 85 input token, câu về cách dự đoán gọi thẳng `how-we-predict-weather` và tốn 229, câu về Paris gọi `get-weather-for-city` và tốn 223 (demo trong video đăng ngày 14/10/2026).

Kết quả theo số đo của Rasmus (video đăng ngày 14/10/2026): chỉ nói "Hi" thì dùng 85 token. Hỏi cách dự đoán thời tiết thì dùng 229. Hỏi thời tiết Paris, gọi một tool, thì dùng 223.

![Hai khung cạnh nhau: Skill Cost với 310, 1471, 1442 và Tool Cost với 85, 229, 223](https://homus.dev/photos/Y2EAsbeyolw-1043.jpg)

Slide tổng kết "Skill Cost" và "Tool Cost" đặt cạnh nhau cho cùng ba câu hỏi: 310 so với 85, 1471 so với 229, 1442 so với 223 input token (số đo trong video đăng ngày 14/10/2026).

Đặt hai bên cạnh nhau, theo Rasmus, trong trường hợp cụ thể này bên skills tốn khoảng gấp ba lần token, rồi anh tự hỏi lại "gì nhỉ?": gấp năm, gấp sáu lần, và cứ thế. Vì vậy, theo anh (video đăng ngày 14/10/2026), những người đưa ra lời khẳng định kia chắc chắn đã sai trong kịch bản này.

## 9. Mô phỏng nhiều hơn: 10 skill, 30 capability, 30 tool

Trong video (đăng ngày 14/10/2026), trên slide câu "Claim: Skills are better and cheaper than Tools/MCP!!!" hiện lại kèm ba dấu hỏi lớn. Rasmus đặt câu hỏi: vậy chuyện gì đang diễn ra, và vì sao ta thấy skills thực ra đắt hơn tools, trong khi mọi người đều nói skills rẻ hơn nhiều và dễ dùng? Câu trả lời của anh: đó là chuyện số lượng.

![Slide Lets Simulate having more Skills and Tools: hai vòng for với multiplier = 10, một cho AgentInlineSkill, một cho AIFunctionFactory](https://homus.dev/photos/Y2EAsbeyolw-1114.jpg)

Slide "Lets Simulate having more Skills and Tools": cùng code cũ được đặt trong vòng `for` với `multiplier = 10`, mỗi skill và mỗi tool được gắn thêm hậu tố `{i}` để thành tên riêng (video đăng ngày 14/10/2026).

Trong demo (video đăng ngày 14/10/2026), anh sửa code một chút để mô phỏng việc có nhiều skill và nhiều tool hơn. Trước đó bên skills chỉ có ba tool để đọc skill, đọc resource và chạy script, còn bên tools cũng có ba tool. Giờ anh đặt chúng vào một vòng for, giả như mình cần nhiều weather skill và nhiều tool get weather for city. Anh nói rõ: ngoài đời, các tool tất nhiên làm những việc khác nhau, nhưng để đơn giản anh chỉ lặp lại cùng một tool mười lần. Kết quả là 10 skill khác nhau với tổng cộng 30 capability, đặt cạnh 30 tool, để xem khác biệt.

```
List agentSkills = [];

int multiplier = 10;
for (int i = 0; i

Lý do anh đưa ra: khi tăng số skill, ta chỉ tăng phần instructions, tức chỉ nói thêm "này, ta có skill này, có skill này, có skill này", nghĩa là có 10 skill khác nhau ở đây. Nhưng số tool cần dùng không tăng: vẫn chỉ cần ba tool. Có một skill hay 100 skill thì vẫn chỉ cần một tool để đọc skill, và chỉ cần một tool để chạy script trong các skill đó (theo Rasmus, video đăng ngày 14/10/2026).

Vì vậy, theo số đo của anh (video đăng ngày 14/10/2026), khi đã lên tới 10 skill, tức 30 capability khác nhau, thì câu "Hi" (không dùng gì cả, vì user chỉ chào) trở nên rẻ hơn ở phía skills. Câu tra một resource thì vẫn đắt hơn một chút, và câu gọi lấy thời tiết cũng vẫn đắt hơn chút ít.

Rasmus nói ở mức 10 skill, chuyện này chắc chắn có thể cải thiện được phần nào nếu tối ưu phần instructions. Anh nhắc lại rằng Agent Framework hơi dài dòng trong cách trình bày instructions đó (theo anh, video đăng ngày 14/10/2026). Nhưng nhìn chung, quanh mức 30 tool thì hai bên gần như hòa.

## 10. 100 skill, 300 tool và điểm hòa vốn

Đẩy lên cao hơn nữa, 100 skill, tức 300 capability, so với 300 tool, thì theo số đo của Rasmus (video đăng ngày 14/10/2026) câu "Hi" còn có lợi hơn nữa cho skills. Nạp 100 skill mà không dùng cái nào thì vẫn tốn 3.680 input token, vì vẫn phải gửi metadata. Nhưng phía skills vẫn chỉ có ba tool, trong khi phía bên kia có 300 tool, cộng thêm một loạt metadata trong instructions. Và lúc này skills bắt đầu tốt hơn ở mọi kịch bản.

![Slide Breaking Even: bảng input token cho 1, 10, 100 skill và 3, 30, 300 tool](https://homus.dev/photos/Y2EAsbeyolw-1503.jpg)

Slide "Breaking Even" với toàn bộ số đo của Rasmus trong setup của anh (video đăng ngày 14/10/2026). 1 skill (3 capability): 310, 1471, 1442 so với 3 tool: 85, 229, 223. 10 skill (30 capability): 620, 2537, 2562 so với 30 tool: 703, 1469, 1463. 100 skill (300 capability): 3680, 11685, 11672 so với 300 tool: 6823, 13709, 13703.

Như trên slide, theo Rasmus (video đăng ngày 14/10/2026), đại khái cần tới 300 tool thì mới hòa vốn và skills mới tốt hơn. Liệu có tối ưu được phần instructions như anh đã nhắc không? Có, chắc chắn là được. Và khi đó có lẽ điểm hòa vốn bắt đầu ở quanh 30, 40, 50, tùy vào việc tối ưu bao nhiêu. Anh lưu ý rằng càng cắt bớt instructions thì khả năng AI hiểu sai các skill khác nhau là gì càng cao.

Vậy nếu mọi tool đều giống nhau như trong ví dụ, theo Rasmus (video đăng ngày 14/10/2026), bạn sẽ nhìn vào code của mình và nói: tôi có ít hơn 30 tool, hay nói đúng hơn là ít hơn 30 capability, nên tốt nhất là dùng tools. Khi vượt quá 30 thì nên chuyển sang skills.

Riêng câu "Hi" (không dùng capability nào), theo số đo trên slide "Breaking Even" của Rasmus (video đăng ngày 14/10/2026): skills đắt hơn ở mức 3 capability, rẻ hơn từ mức 30, và rẻ hơn rõ ở mức 300.

## 11. Agent C# thường có ít mục đích, nên hiếm khi tới 30 tool

Rồi Rasmus nói về trải nghiệm của chính anh: ngoài cái sample giả này ra, anh không nghĩ mình từng có một agent nào được giao tới 30 tool, vì anh muốn agent của mình có chủ đích hơn (deliberate). Và theo anh (video đăng ngày 14/10/2026), đó cũng là một trong những lý do skills phổ biến trong các công cụ như Claude Code, Cowork và Codex: ở đó ta giao cho agent rất nhiều capability khác nhau. Anh dùng của mình cho cả video YouTube, cho coding và đủ thứ việc khác.

Ở những công cụ đó, theo Rasmus, đằng nào chúng cũng cần ba tool đọc skill, nên có skills không tạo thêm overhead; nó cứ thế chạy. Nhưng nếu bạn đang viết code C# được tuyển chọn kỹ (curated) và dùng một agent, thì đó thường là thứ chỉ có một hai mục đích. Đúng là bạn có thể làm một chatbot, nhưng kể cả chatbot thì có lẽ bạn cũng sẽ không bao giờ có tới 30 tool. Và như số đo của anh cho thấy (video đăng ngày 14/10/2026), có khi phải lên tới 300 tool thì chuyển sang skills mới đáng.

Hai bối cảnh Rasmus đặt cạnh nhau (video đăng ngày 14/10/2026): skills hợp với công cụ agent đa năng có rất nhiều capability, còn một agent C# tập trung thường có ít tool tới mức tools là lựa chọn rẻ hơn.

## 12. Tool phức tạp tốn hơn: ví dụ GitHub MCP

Rasmus nêu một điểm cần lưu ý (caveat, video đăng ngày 14/10/2026): các tool trong ví dụ của anh khá đơn giản, chỉ có input là một string và output là một string. Input là tên thành phố, output chỉ là một đoạn chữ nói trời nắng 19 độ. Nhưng không phải tool nào cũng như nhau. Vì vậy, theo anh, ta cũng phải để ý xem tool của mình phức tạp tới mức nào.

Ví dụ anh đưa ra cho một bộ tool viết rất tệ, hoặc lẽ ra không nên là tool, là GitHub MCP (theo Rasmus, video đăng ngày 14/10/2026). Anh nói rõ ở đây anh đang dùng MCP, nhưng đó cũng có thể là những tool do chính anh viết, chỉ là phức tạp hơn nhiều.

![Code C# tạo McpClient tới api.githubcopilot.com/mcp với ListToolsAsync, cửa sổ debug hiện Count = 49 và danh sách tool add_comment_to_pending_review, create_branch...](https://homus.dev/photos/Y2EAsbeyolw-1923.jpg)

Slide "Extra Note: Tools can be more expensive if complex input/output schema": code C# kết nối `McpClient` tới endpoint `https://api.githubcopilot.com/mcp/` rồi gọi `ListToolsAsync()`; cửa sổ debug cho thấy `Count = 49` và đầu danh sách tool như `add_comment_to_pending_review`, `add_issue_comment`, `create_branch`, `create_pull_request` (video đăng ngày 14/10/2026).

Bên trong GitHub MCP có 49 tool (trên màn hình, `Count = 49`, video đăng ngày 14/10/2026). Theo những gì vừa thấy, ta sẽ nghĩ: vậy nên dùng skills, vì đã vượt 30 tool, mà 30 tool của anh chỉ tốn khoảng 700 token khi nói "Hi". Nhưng các tool này phức tạp hơn rất nhiều. Có 49 tool thì cũng không sao, ta có thể chỉ lấy 30 tool đầu để so cho công bằng. Nhưng như trên màn hình, chúng có tên dài hơn, phần chữ dài hơn, và input, output phức tạp hơn nhiều.

Lấy tool đầu tiên làm ví dụ (như trên màn hình trong video đăng ngày 14/10/2026): nó có một cái tên, một description dài hơn description của anh một chút, rồi một loạt parameter: owner, repo, pull number, path, body, subject type, và cứ thế. Theo Rasmus, chỉ riêng một tool đó trong số 49 tool đã lớn gần gấp đôi cả ba tool của anh cộng lại.

![Định nghĩa JSON của tool add_comment_to_pending_review với nhiều parameter; khung dưới: Hi, Hello! How can I help you with GitHub today?, Input Tokens 9449, chú thích This tool alone is 269 tokens](https://homus.dev/photos/Y2EAsbeyolw-2123.jpg)

Cùng slide, thêm định nghĩa JSON của tool `add_comment_to_pending_review` với các parameter `body`, `line`, `owner`, `path`, `pullNumber`, `repo`, `side`, `startLine`, `startSide`, `subjectType`. Khung dưới: chỉ gõ "Hi" đã tốn 9449 input token, và chú thích "This tool alone is 269 tokens" (số đo trong video đăng ngày 14/10/2026).

Vì thế, theo số đo của Rasmus (video đăng ngày 14/10/2026), khi chỉ nói "Hi" với agent này mà không dùng tool nào, vì phải gửi nhiều metadata như vậy, anh đã tốn khoảng 9.000 token. Đây là rất nhiều tool rất phức tạp. Nếu chúng rất đơn giản thì chỉ tốn vài trăm token. Nhưng chúng rất phức tạp, và cái anh vừa cho xem mới chỉ là một trong số đó. Hãy hình dung có 49 cái như vậy và phải gửi toàn bộ metadata đó chỉ để nói "Hi": trong trường hợp này tốn 9.449 token.

Anh còn đo riêng tool đó: nếu chỉ thêm đúng một tool này thì đã mất 269 token, chỉ để giới thiệu với AI rằng ta có tool, chưa hề gọi nó. Anh so sánh: ở phía trước ta thấy khoảng 700 token cho cả loạt tool đơn giản (anh nói "40 tool", còn slide "Breaking Even" ghi 703 token cho 30 tool), trong khi ở đây chỉ một tool đã tốn chừng ấy (anh nói "200", chú thích trên slide ghi 269 token), theo số đo trong video đăng ngày 14/10/2026.

Vậy theo Rasmus, độ phức tạp của tool cũng ảnh hưởng tới chuyện này, như ta vừa thấy. Không có câu trả lời rạch ròi bên này hay bên kia. Nếu tool của bạn rất phức tạp, bạn có thể bắt đầu cân nhắc chuyển sang skills. Hoặc nếu bạn có rất, rất nhiều tool, bạn cũng có thể cân nhắc chuyển sang skills. Nhưng nếu không rơi vào hai trường hợp đó, mà theo ý anh là 90%, 99% trường hợp không rơi vào, thì trong tất cả những trường hợp ấy tools hợp lý hơn (theo Rasmus, video đăng ngày 14/10/2026).

## 13. Kết luận: khi nào chọn skills, khi nào chọn tools

Tóm lại, theo Rasmus (video đăng ngày 14/10/2026): nếu còn phân vân, chắc chắn hãy chọn tools. Có lẽ bạn sẽ tiết kiệm được phần lớn token. Bạn cũng sẽ viết chúng dễ hơn, vì tools viết gọn hơn so với skills. Nhưng nếu bạn có rất nhiều tool, hoặc tool rất, rất phức tạp, thì skills có thể là hướng nên đi. Chuyện đó tùy từng trường hợp cụ thể. Nhưng giờ ít nhất bạn đã biết các tham số để ra quyết định, điều mà có thể trước đây bạn chưa có.

Cách chọn Rasmus tóm lại ở cuối video (đăng ngày 14/10/2026): số lượng và độ phức tạp của tool quyết định; còn phân vân thì chọn tools. Mốc 30 là từ phép đo của anh với các tool rất đơn giản và instructions mặc định.

Một lần nữa, theo Rasmus: số lượng và độ phức tạp của tool quyết định việc chuyển sang skills có hợp lý hay không. Và trong 99% trường hợp thì không phải vậy. Đó là lý do chính khiến anh cho rằng trong phần lớn trường hợp, và ở trường hợp mặc định, tools có lẽ là hướng nên đi, thay vì chạy theo thứ mới và hào nhoáng, trừ khi mọi thứ rất phức tạp (theo Rasmus, video đăng ngày 14/10/2026).

Phần mô tả của video (đăng ngày 14/10/2026) cũng ghi chú rằng các số đo này chỉ đúng với setup được trình bày; riêng số lượng tool không phải là một ngưỡng chung cho mọi trường hợp, vì độ phức tạp của schema và instructions của skill cũng ảnh hưởng tới sự đánh đổi. Rasmus kết thúc video tại đó.

## Nguồn và liên kết

- Tên gốc: When to use Skills and when to use Tools in Agent Framework?
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=Y2EAsbeyolw](https://www.youtube.com/watch?v=Y2EAsbeyolw)

- Kênh YouTube AI in C# (Rasmus Wulff Jensen): [youtube.com/channel/UClmT_VztthYxP4MaD2fpHLw](https://www.youtube.com/channel/UClmT_VztthYxP4MaD2fpHLw)

- Code của video, folder WhenToUseSkillsAndWhenToUseTools trong repo agent-framework-samples, gồm Program.cs, SkillsImplementation.cs và ToolsImplementation.cs (đọc ngày 26/10/2026): [github.com/rwjdk/agent-framework-samples/.../WhenToUseSkillsAndWhenToUseTools](https://github.com/rwjdk/agent-framework-samples/tree/main/src/WhenToUseSkillsAndWhenToUseTools)

- Trang Agent Skills trong tài liệu Microsoft Agent Framework, có AgentInlineSkill và các tool load_skill, read_skill_resource, run_skill_script (đọc ngày 26/10/2026): [learn.microsoft.com/en-us/agent-framework/agents/skills](https://learn.microsoft.com/en-us/agent-framework/agents/skills)

- Repo Microsoft Agent Framework (đọc ngày 26/10/2026): [github.com/microsoft/agent-framework](https://github.com/microsoft/agent-framework)

- Repo GitHub MCP Server, README có endpoint remote [api.githubcopilot.com/mcp/](https://api.githubcopilot.com/mcp/) (đọc ngày 26/10/2026): [github.com/github/github-mcp-server](https://github.com/github/github-mcp-server)

Nguồn: https://homus.dev/talks/when-to-use-skills-and-when-to-use-tools-in-agent-framework · cập nhật 2026-10-26