Mục tiêuSau ngày này, học viên viết được prompt rõ ràng theo bốn thành phần Role, Task, Context, Format; biết khi nào dùng few-shot và chain-of-thought, khi nào không cần; viết được system prompt đủ chuẩn production cho một agent; khai báo được tool schema và hiểu vòng lặp tool calling từ model đến tool rồi quay lại model; nhận diện được prompt injection và biết cách phòng cơ bản; và thực hành xây một agent hoàn chỉnh trong lab.
●●● sâu · ●●○ vừa · ●○○ nhẹ · Nhà · Lớp · Nhà → Lớp · bấm dòng để xem chi tiếtmở tất cả
Mở ngày
0Mở ngày●●○Lớp3′
Ý chínhGiảng viên đặt câu hỏi xuyên suốt ngày học — vì sao cùng một việc, một người nhận kết quả xuất sắc còn người kia nhận kết quả không dùng được, và vì sao cùng một agent lúc gọi đúng tool lúc gọi sai. Giảng viên giới thiệu các đầu ra học viên sẽ đạt được sau ngày học, từ viết prompt rõ ràng đến khai báo tool schema và nhận diện injection. Trọng tâm được nhấn mạnh ngay từ đầu: đây là ngày học về cơ chế, không phải danh sách mẹo cần nhớ.
Kỹ năngHọc viên biết được các đầu ra cụ thể của ngày học và vì sao ngày học tập trung vào cơ chế thay vì mẹo lẻ.
Hình thứcVideo giảng viên, 3 phút, giọng dẫn dắt.
Module 1 · Nền tảng viết prompt
Module này xây nền cho toàn bộ ngày học: cấu trúc của một prompt tốt, cách phân biệt ba loại prompt, và cơ chế thực sự đứng sau tham số temperature — khái niệm Ngày 1 đã giới thiệu nhưng thường chỉ được gọi là "độ sáng tạo". Phần lớn module có thể tự học ở nhà, riêng phần phân loại prompt có một hoạt động ngắn trên lớp để củng cố.
1.1Bốn thành phần của một prompt tốt (Role, Task, Context, Format)●●●Nhà6′
Ý chínhMột prompt tốt không phải prompt nghe hay, mà là prompt tạo ra hành vi ổn định và có thể lặp lại. Bốn thành phần Role, Task, Context, Format tạo thành khung viết prompt: Role xác định góc nhìn, Task nêu việc cần làm, Context cung cấp bối cảnh, Format quy định đầu ra. Nguyên tắc thực dụng là bắt đầu từ Task và Format, chỉ thêm Role hoặc Context khi chúng thực sự cải thiện chất lượng. Ví dụ đối chiếu một prompt mơ hồ với một prompt đủ bốn thành phần cho thấy khoảng cách giữa mơ hồ và dùng được ngay.
Kỹ năngHọc viên viết được một prompt đủ bốn thành phần cho một tình huống công việc cụ thể, và giải thích được vì sao mỗi thành phần cần thiết.
Hình thứcVideo 6 phút, ví dụ email xin lỗi khách hàng xây dần qua bốn thành phần, kèm bảng so sánh ví dụ tốt và ví dụ kém cho từng thành phần.
1.2Phân biệt instruction, conversation và system prompt●●●Nhà → Lớp7′
Ý chínhBa loại prompt phục vụ ba mục đích khác nhau: instruction prompt ra lệnh cho một tác vụ đơn lẻ, conversation prompt giữ mạch nhiều lượt hội thoại, còn system prompt đặt policy và ràng buộc hành vi cho cả phiên làm việc. Ranh giới ba loại dễ nhầm vì cả ba đều là văn bản gửi cho model và không hiện rõ trên giao diện. Negative prompting — chỉ nói "đừng làm gì" — thường kém hiệu quả hơn cách nói rõ nên làm gì thay thế, vì model cần một hành vi thay thế cụ thể, không chỉ một điều cấm.
Kỹ năngHọc viên phân biệt được ba loại prompt theo mục đích sử dụng, và viết lại được một câu "đừng" thành hướng dẫn có hành vi thay thế.
Hình thứcỞ nhà: video 5 phút, phân biệt ba loại prompt qua bảng ví dụ. Trên lớp: tương tác 2 phút, học viên xếp năm đoạn prompt mẫu vào đúng loại và nhận phản hồi ngay. Phương án thay thế: quiz 5 câu thay tương tác trên lớp.
1.3Mô phỏng: temperature và top-p thực ra đang chỉnh cái gì●●●Lớp5′
Ý chínhNgày 1 đã giới thiệu temperature khi giải phẫu một lần gọi API; item này đi vào cơ chế thay vì dừng ở chữ "độ sáng tạo". Model chọn từ tiếp theo từ một phân bố xác suất trên hàng chục nghìn token; temperature làm phân bố đó phẳng hơn hoặc nhọn hơn trước khi model chọn, còn top-p và top-k giới hạn tập ứng viên được chọn trong đó. Ở temperature bằng 0, model luôn chọn token xác suất cao nhất, nên lúc này top-p và top-k không còn tác dụng. Việc chọn tham số phụ thuộc vào việc cần làm: gần không cho tác vụ cần tính nhất quán, mức trung bình cho hội thoại tự nhiên, mức cao hơn cho brainstorm khi có người kiểm tra lại.
Kỹ năngHọc viên dự đoán được phân bố xác suất thay đổi thế nào khi chỉnh temperature, và chọn được mức tham số phù hợp cho một tác vụ cụ thể.
Hình thứcTương tác mô phỏng 5 phút trên dữ liệu cấu hình sẵn: học viên dự đoán token nào được chọn ở ba mức temperature trước khi xem kết quả, sau đó thử top-p và top-k trên cùng một câu. Phương án thay thế: video minh hoạ 5 phút.
1.4Thực hành: viết prompt cho một chatbot đăng ký môn học●●○Lớp5′
Ý chínhHọc viên áp dụng khung bốn thành phần vào một tình huống cụ thể: viết prompt cho chatbot trả lời câu hỏi đăng ký môn học của một trường đại học. Học viên dự đoán trước những gì prompt của mình có thể bỏ sót, sau đó so sánh với một prompt mẫu có xử lý các trường hợp như học viên vượt quá số tín chỉ tối đa hoặc cần xuất danh sách môn ra file. Hoạt động cho thấy khoảng cách giữa một prompt "đủ dùng" và một prompt đã tính đến các trường hợp biên.
Kỹ năngHọc viên tự viết được một prompt đủ bốn thành phần cho tình huống mới, và tự nhận ra được các trường hợp biên mình bỏ sót.
Hình thứcTương tác 5 phút: học viên viết prompt, dự đoán kết quả, rồi so sánh với prompt mẫu có xử lý trường hợp biên. Phương án thay thế: bài tập viết trên giấy, đối chiếu đáp án sau.
1.5Prompting đã thay đổi thế nào từ 2020 đến 2026●○○Nhà4′
Ý chínhBa giai đoạn nối tiếp nhau: từ prompt tĩnh những năm đầu, đến kỹ thuật lập luận theo bước, rồi đến giai đoạn hiện nay khi phần lớn công sức chuyển sang thiết kế lớp điều phối quanh model. Nhiều kỹ thuật từng quan trọng trở nên ít cần thiết khi model có khả năng suy luận sẵn có. Mốc thời gian này giúp học viên hiểu vì sao một số kỹ thuật ở phần sau của ngày học được trình bày như một lựa chọn có điều kiện, không phải quy tắc bắt buộc.
Kỹ năngHọc viên đặt được một kỹ thuật prompt bất kỳ vào đúng giai đoạn phát triển của nó.
Hình thứcVideo 4 phút, dòng thời gian ba giai đoạn hiện dần.
1.6Quiz Module 1●●○Nhà5′
Ý chính4 câu kiểm tra: thành phần nào nên thêm trước tiên trong một prompt, cách phân biệt system prompt với instruction prompt, tác dụng của temperature khi bằng 0, và ý nghĩa của một negative prompt tốt.
Kỹ năngHọc viên tự kiểm tra bốn ý chính của module.
Hình thứcQuiz 4 câu, chấm ngay, có giải thích khi sai.
Module 2 · Kỹ thuật prompt nâng cao
Module này đi vào ba kỹ thuật nâng cao: đưa ví dụ mẫu vào prompt, cho model lập luận theo bước, và dùng thẻ cấu trúc để phân vùng nội dung trong prompt. Việc chọn ví dụ mẫu là chỗ khó nhất của module, nên có một hoạt động cặp tương phản để làm rõ.
2.1Khi nào nên đưa ví dụ cho model — và ví dụ nào●●●Nhà6′
Ý chínhFew-shot prompting đưa một vài ví dụ mẫu vào prompt để model học theo khuôn mẫu đó, thay vì chỉ mô tả bằng lời. Hai chỗ dễ sai: nhầm lẫn giữa input và output của ví dụ, và không biết ví dụ có "đúng chỗ" với tình huống thực tế hay không — một ví dụ đúng cấu trúc nhưng khác ngữ cảnh vẫn có thể khiến model học sai khuôn mẫu. Ba đến năm ví dụ đa dạng thường đủ; đưa toàn ví dụ theo một chiều tạo ra thiên lệch trong kết quả.
Kỹ năngHọc viên phân biệt được input và output trong một ví dụ mẫu, và chọn được ví dụ phù hợp với ngữ cảnh của tác vụ.
Hình thứcVideo 6 phút, ví dụ tin nhắn chuyển khoản được chuyển thành dữ liệu có cấu trúc, đối chiếu với một ví dụ mẫu đúng định dạng nhưng sai ngữ cảnh để lộ ra sai lệch.
2.2Mô phỏng: ví dụ đúng chỗ và ví dụ sai chỗ●●○Lớp4′
Ý chínhHọc viên xem cùng một tác vụ được đưa hai bộ ví dụ mẫu khác nhau — một bộ đúng ngữ cảnh, một bộ đúng cấu trúc nhưng sai ngữ cảnh — và quan sát kết quả model tạo ra khác nhau thế nào. Hoạt động củng cố trực tiếp điểm khó của item trước: ví dụ mẫu không chỉ cần đúng định dạng, mà còn cần đúng loại tình huống.
Kỹ năngHọc viên tự nhận ra được hậu quả của việc chọn ví dụ sai ngữ cảnh, dù ví dụ đó đúng định dạng.
Hình thứcTương tác cặp tương phản 4 phút trên hai kịch bản cấu hình sẵn, hiển thị kết quả hai bên cạnh nhau. Phương án thay thế: video so sánh hai kịch bản.
2.3Chain-of-Thought còn cần khi model đã biết "suy luận"?●●○Nhà6′
Ý chínhChain-of-Thought yêu cầu model trình bày từng bước lập luận trước khi đưa ra câu trả lời cuối, giúp tăng độ chính xác cho các bài toán nhiều bước. Kỹ thuật này ra đời khi model chưa có khả năng suy luận sẵn có; các model suy luận hiện nay tự thực hiện một phần bước này, nên yêu cầu Chain-of-Thought tường minh có thể thừa với một số tác vụ đơn giản. Nguyên tắc chọn: mô tả đích đến muốn đạt, không mô tả lộ trình từng bước — mô tả lộ trình có thể khiến model đi theo một hướng giải quen thuộc thay vì hướng tốt nhất cho bài toán cụ thể. Thinking budget, tức số token dành cho suy luận nội bộ, không phải là bộ tham số của model.
Kỹ năngHọc viên nhận ra được tình huống nào cần yêu cầu model lập luận từng bước, và phân biệt được thinking budget với tham số model.
Hình thứcVideo 6 phút, ví dụ bài toán nhiều bước xây dần, kết bằng sơ đồ khi nào cần và khi nào không cần kỹ thuật nâng cao.
2.4Vì sao nên bọc prompt bằng thẻ cấu trúc●●○Nhà4′
Ý chínhBọc các phần khác nhau của prompt — hướng dẫn, dữ liệu người dùng, tài liệu tham khảo — trong các thẻ như XML giúp model phân biệt rõ phần nào là chỉ dẫn và phần nào là nội dung cần xử lý. Model được huấn luyện trên lượng lớn văn bản có định dạng thẻ nên nhận diện cấu trúc này tốt. Việc bọc dữ liệu người dùng trong một thẻ riêng còn có tác dụng bảo mật: nó giúp model không nhầm lẫn nội dung do người dùng nhập với chỉ dẫn hệ thống — nền tảng cho phần an toàn prompt ở module sau.
Kỹ năngHọc viên viết được một prompt có cấu trúc thẻ rõ ràng, tách được phần chỉ dẫn khỏi phần dữ liệu.
Hình thứcVideo 4 phút, một prompt văn xuôi được bọc lại bằng thẻ cấu trúc theo từng bước.
2.5Quiz Module 2●●○Nhà4′
Ý chính3 câu kiểm tra: dấu hiệu một ví dụ mẫu sai ngữ cảnh, khi nào nên yêu cầu model lập luận từng bước, và tác dụng của thẻ cấu trúc trong prompt.
Kỹ năngHọc viên tự kiểm tra ba ý chính của module.
Hình thứcQuiz 3 câu, chấm ngay.
Module 3 · System prompt production-grade
Module này trình bày cấu trúc một system prompt sẵn sàng cho production, các lỗi thường gặp, và cách xử lý khi agent gặp câu hỏi ngoài phạm vi hoặc không chắc câu trả lời. Hoạt động tìm lỗi trong system prompt được bố trí trên lớp.
3.1System prompt production-grade gồm những gì●●●Nhà6′
Ý chínhMột system prompt đầy đủ thường có năm phần: persona (vai trò), rules (quy tắc), capabilities (khả năng), constraints (giới hạn), và output contract (định dạng đầu ra cam kết). Ví dụ minh hoạ là một agent chăm sóc khách hàng thương mại điện tử, được viết lại qua nhiều phiên bản để thấy rõ khoảng cách giữa bản sơ khai và bản production. Một tình huống có thật — chatbot hứa hoàn tiền sai chính sách khiến công ty phải chịu trách nhiệm — cho thấy vì sao phần constraints không phải là chi tiết tuỳ chọn.
Kỹ năngHọc viên viết được một system prompt có đủ năm phần cho một agent cụ thể.
Hình thứcVideo 6 phút, năm phần hiện dần trên một ví dụ, kèm bản sơ khai và bản production đối chiếu.
3.2System prompt hay hỏng ở đâu — và test nó thế nào●●●Nhà5′
Ý chínhBa lỗi phổ biến: mơ hồ (yêu cầu "thông minh hơn" mà không nói rõ hành vi cụ thể), mâu thuẫn (vừa yêu cầu ngắn gọn vừa yêu cầu giải thích chi tiết từng bước), và quá tải (nhồi quá nhiều quy tắc khiến các quy tắc tự triệt tiêu lẫn nhau). Một system prompt sau khi viết cần được kiểm thử bằng nhiều lượt hỏi khác nhau, không chỉ một lần chạy thử — độ ổn định qua nhiều lần thử mới là thước đo đáng tin, không phải một kết quả đẹp duy nhất.
Kỹ năngHọc viên nhận diện được ba loại lỗi thường gặp trong system prompt và giải thích được vì sao cần test nhiều lượt.
Hình thứcVideo kể chuyện 5 phút quanh một system prompt mắc cả ba lỗi, từng lỗi được chỉ ra và sửa lại.
3.3Bài tập: tìm ít nhất ba lỗi trong system prompt này●●○Lớp5′
Ý chínhHọc viên nhận một system prompt có sẵn ba lỗi đã học ở item trước, tự đánh giá trước khi xem đáp án. Hoạt động củng cố kỹ năng đọc phê bình một system prompt — kỹ năng học viên sẽ cần khi tự viết và tự sửa system prompt của chính mình trong lab.
Kỹ năngHọc viên tự tìm được lỗi trong một system prompt cho sẵn mà không cần gợi ý.
Hình thứcTương tác dự đoán rồi quan sát, 5 phút: học viên viết ra lỗi mình tìm được trước, sau đó đối chiếu với đáp án đầy đủ. Phương án thay thế: thảo luận nhóm 3 phút rồi chia sẻ.
3.4Agent nên làm gì khi không biết, hoặc bị hỏi ngoài phạm vi●●○Nhà5′
Ý chínhMột agent tốt cần biết từ chối một cách có ích thay vì bịa câu trả lời hoặc im lặng: nói rõ mình không có thông tin, gợi ý bước tiếp theo, hoặc chuyển tiếp cho người phụ trách khi tình huống vượt quá phạm vi cho phép. Các tình huống cần chuyển tiếp cho con người thường là những quyết định có hậu quả thật — xác nhận giao dịch tài chính, hoặc chỉ định y tế — nơi một câu trả lời sai không thể sửa sau khi đã thực hiện. Phần này dừng ở mức nhận diện rủi ro cơ bản, chưa đi sâu vào thiết kế hệ thống an toàn đầy đủ.
Kỹ năngHọc viên viết được một điều khoản từ chối và một điều kiện leo thang cho system prompt của một agent cụ thể.
Hình thứcVideo 5 phút, ba tình huống — hỏi ngoài phạm vi, không chắc câu trả lời, cần xác nhận con người — mỗi tình huống một cách xử lý.
3.5Quiz Module 3●●○Nhà5′
Ý chính4 câu kiểm tra: năm thành phần của system prompt, ba loại lỗi thường gặp, cách test độ ổn định, và khi nào agent nên chuyển tiếp cho con người.
Kỹ năngHọc viên tự kiểm tra trước khi sang module tiếp theo.
Hình thứcQuiz 4 câu, chấm ngay.
Module 4 · Quản lý ngữ cảnh
Module này giải thích điều gì thực sự nằm trong context window của model, và vì sao thông tin đặt ở giữa một prompt dài dễ bị model bỏ sót hơn thông tin ở đầu hoặc cuối — hiện tượng Ngày 1 đã giới thiệu, ở đây đi vào hệ quả thực hành. Phần mô phỏng được bố trí trên lớp.
4.1Model "thấy" gì trong context window — và vì sao đoạn giữa hay bị bỏ sót●●●Nhà6′
Ý chínhTrong một lần gọi, phần duy nhất cố định là system prompt; lịch sử hội thoại, dữ liệu đưa vào, danh sách tool và đầu ra đều thay đổi theo từng lượt. Model có xu hướng chú ý tốt hơn đến thông tin ở đầu và cuối context, còn thông tin ở giữa dễ bị bỏ sót hơn — hiện tượng "lost in the middle" Ngày 1 đã giới thiệu, ở đây áp vào cách bố trí một prompt dài. Hiện tượng này ảnh hưởng trực tiếp đến việc nên đặt yêu cầu quan trọng ở đâu trong một prompt dài. Một hệ quả thực hành: khi một phiên làm việc kéo dài và model bắt đầu trả lời kém chính xác hơn, mở một phiên mới thường hiệu quả hơn cố giữ nguyên phiên cũ.
Kỹ năngHọc viên xác định được nên đặt yêu cầu quan trọng ở đâu trong một prompt dài, và giải thích được hiện tượng lost in the middle.
Hình thứcVideo 6 phút, hình ảnh minh hoạ mức độ chú ý giảm dần ở đoạn giữa một context dài.
4.2Mô phỏng: quan sát thông tin ở giữa bị bỏ sót●●●Lớp4′
Ý chínhHọc viên đưa vào model cùng một câu hỏi với thông tin cần thiết được đặt lần lượt ở đầu, giữa, và cuối một đoạn văn bản dài, rồi dự đoán trước lượt nào model trả lời đúng. Kết quả cho thấy trực tiếp hiện tượng vừa học ở item trước, thay vì chỉ nghe mô tả bằng lời.
Kỹ năngHọc viên tự quan sát được ảnh hưởng của vị trí thông tin đến độ chính xác của câu trả lời.
Hình thứcTương tác dự đoán rồi quan sát, 4 phút, trên ba vị trí thông tin cấu hình sẵn. Phương án thay thế: video so sánh ba kết quả.
4.3Chatbot "nhớ" bằng cách nào●●○Nhà5′
Ý chínhModel không tự lưu trạng thái giữa các lần gọi; cảm giác "model nhớ" đến từ việc ứng dụng gửi lại lịch sử hội thoại hoặc một bản tóm tắt của nó ở mỗi lượt. Khi hội thoại dài dần, giữ nguyên toàn bộ lịch sử làm context phình to và tốn chi phí xử lý, nên nhiều hệ thống nén hội thoại cũ thành một bản tóm tắt ngắn hơn — nén hiệu quả là bỏ đúng phần thừa, không phải cắt ngẫu nhiên. Một rủi ro đi kèm là memory injection: nếu hệ thống tự động lưu lại chi tiết cá nhân người dùng nói trong lúc trò chuyện, chi tiết đó có thể xuất hiện lại không đúng lúc ở một lượt hội thoại khác.
Kỹ năngHọc viên giải thích được vì sao model không tự nhớ giữa các lượt, và nhận diện được rủi ro memory injection.
Hình thứcVideo 5 phút, ví dụ một chi tiết cá nhân được lưu rồi xuất hiện lại không đúng ngữ cảnh.
4.4Quiz Module 4●●○Nhà4′
Ý chính3 câu kiểm tra: vì sao đoạn giữa dễ bị bỏ sót, cách nén hội thoại dài hiệu quả, và memory injection là gì.
Kỹ năngHọc viên tự kiểm tra ba ý chính của module.
Hình thứcQuiz 3 câu, chấm ngay.
Module 5 · An toàn và đánh giá prompt
Module này giúp học viên nhận ra prompt injection khi gặp phải, dựng được vài lớp phòng thủ cơ bản, và biết cách đánh giá xem một prompt hôm nay có thực sự tốt hơn hôm qua hay không. Phần này dừng ở mức nhận diện và phòng cơ bản; phần thiết kế hệ thống an toàn đầy đủ nằm ở giai đoạn học sau. Hoạt động thử phá một system prompt được bố trí trên lớp.
5.1Prompt injection đến từ đâu●●●Nhà5′
Ý chínhPrompt injection là khi một chỉ dẫn giả xuất hiện lẫn trong nội dung mà agent xử lý, khiến agent làm theo chỉ dẫn đó thay vì chỉ dẫn thật của hệ thống. Injection trực tiếp là khi người dùng cố tình yêu cầu model bỏ qua chỉ dẫn ban đầu; injection gián tiếp nguy hiểm hơn vì chỉ dẫn giả nằm ẩn trong một trang web, một tài liệu, hay một email mà agent đọc qua, chẳng hạn một đoạn văn bản ẩn trên trang web yêu cầu agent bỏ qua system prompt. Vì agent ngày càng đọc nội dung từ nhiều nguồn bên ngoài, mọi nội dung không do người vận hành hệ thống viết ra nên được xem là chưa đáng tin cho đến khi được kiểm tra.
Kỹ năngHọc viên phân biệt được injection trực tiếp và gián tiếp, và nhận diện được một chỉ dẫn giả khi đọc qua nội dung agent xử lý.
Hình thứcVideo kể chuyện 5 phút: một trang web có nội dung ẩn chứa chỉ dẫn giả, agent đọc trang và làm theo chỉ dẫn đó.
5.2Vài lớp phòng thủ cơ bản cho agent●●○Nhà4′
Ý chínhKhông một lớp phòng thủ nào chặn được toàn bộ injection, nên cách tiếp cận thực dụng là xếp chồng nhiều lớp: tách rõ nội dung tin cậy và nội dung chưa tin cậy bằng thẻ cấu trúc, giới hạn quyền của tool ở mức tối thiểu cần thiết, và không xem bất kỳ đầu vào nào là chắc chắn an toàn. Nguyên tắc chung là muốn hệ thống chạy nhanh và tự động hơn thì càng cần lớp kiểm soát tốt hơn đi kèm, giống như một chiếc xe muốn chạy nhanh thì cần một hệ thống phanh tốt hơn.
Kỹ năngHọc viên liệt kê được ít nhất hai lớp phòng thủ cơ bản có thể áp dụng cho một agent cụ thể.
Hình thứcVideo quy trình 4 phút, các lớp phòng thủ xếp chồng lên nhau.
5.3Làm sao biết prompt hôm nay tốt hơn hôm qua●●○Nhà4′
Ý chínhMột prompt hoạt động tốt hôm nay không đảm bảo hoạt động tốt mãi — thay đổi nhỏ ở model, ở dữ liệu đầu vào, hoặc ở chính prompt đều có thể làm kết quả lệch đi. Đánh giá prompt cần một bộ câu hỏi test cố định để so sánh qua các phiên bản, xét trên các tiêu chí như độ đúng, độ ổn định qua nhiều lần chạy, và mức độ an toàn. Việc lưu lại từng phiên bản prompt kèm kết quả test, tương tự cách quản lý phiên bản mã nguồn, giúp truy vết được khi nào và vì sao chất lượng thay đổi.
Kỹ năngHọc viên thiết kế được một bộ vài câu hỏi test để so sánh hai phiên bản của cùng một prompt.
Hình thứcVideo 4 phút, một prompt được test qua ba phiên bản với cùng bộ câu hỏi, kết quả đối chiếu trên bảng.
5.4Mô phỏng: một system prompt có thể bị vượt qua đến mức nào●●○Lớp9′
Ý chínhHọc viên xem một agent được giao quyền duyệt chi tiêu trong một hạn mức nhất định, cùng vài cách người dùng thử thuyết phục agent duyệt một khoản vượt hạn mức. Kết quả cho thấy khả năng vượt qua một system prompt phụ thuộc vào cách viết system prompt và vào chính model đang dùng — không có gì là tuyệt đối an toàn hay tuyệt đối bị phá. Sau demo, học viên tự thử đặt câu hỏi để tìm cách vượt qua giới hạn của một agent tương tự.
Kỹ năngHọc viên nhận diện được ít nhất một điểm yếu trong một system prompt cho trước và giải thích được vì sao kết quả injection không tuyệt đối.
Hình thứcDemo màn hình 4 phút, sau đó tương tác 5 phút: học viên tự thử với một model khác trên cùng kịch bản. Phương án thay thế: video demo, không có phần tự thử.
5.5Quiz Module 5●●○Nhà5′
Ý chính4 câu kiểm tra: khác biệt giữa injection trực tiếp và gián tiếp, một lớp phòng thủ cơ bản, tiêu chí đánh giá một prompt, và vì sao cần lưu phiên bản prompt.
Kỹ năngHọc viên tự kiểm tra bốn ý chính của module.
Hình thứcQuiz 4 câu, chấm ngay.
Module 6 · Tool calling và thiết kế tool
Module này là phần lõi gắn với tên ngày học: cách một agent thực sự gọi tool, cách viết schema và mô tả để model chọn đúng tool, cách xử lý khi tool báo lỗi, và các nguyên tắc thiết kế một tool tốt. Hoạt động viết tool schema được bố trí trên lớp.
6.1Tool calling thực sự chạy thế nào — ai làm gì●●●Nhà6′
Ý chínhModel không tự chạy tool; model chỉ trả về một yêu cầu có cấu trúc — tên tool và tham số — còn ứng dụng mới là nơi thực sự thực thi tool và gửi kết quả trở lại cho model tổng hợp câu trả lời cuối. Học viên đã gặp một vòng lặp tương tự ở Ngày 3 khi tìm hiểu về agent; ở đây trọng tâm chuyển sang riêng bước quyết định gọi tool nào và với tham số gì. Các nhà cung cấp model biểu diễn tool theo cấu trúc hơi khác nhau nhưng cùng khái niệm; tham số tool_choice cho phép bắt buộc, cho phép tuỳ chọn, hoặc tắt hẳn khả năng gọi tool — một câu chào hỏi đơn giản không cần đến việc gọi tool nào cả.
Kỹ năngHọc viên mô tả được đúng năm bước của vòng lặp tool calling và vai trò của model so với ứng dụng ở từng bước.
Hình thứcVideo quy trình 6 phút: một agent đặt taxi ra sân bay minh hoạ từng bước, từ yêu cầu đến kết quả trả về tài xế và giá.
6.2Vì sao mô tả của tool chính là một phần của prompt●●●Nhà6′
Ý chínhModel chọn tool dựa trên tên và phần mô tả (description) của tool, không dựa trên cách tool được lập trình bên trong — vì vậy description thực chất đóng vai trò như một đoạn prompt, và viết mô tả mơ hồ hay hai tool có phạm vi chồng lấn đều khiến model dễ chọn sai. Một mô tả tốt nên nêu rõ ba điều: tool làm gì, khi nào dùng, và khi nào không nên dùng — cách viết tương tự tài liệu hướng dẫn API. Tên tham số và việc đánh dấu tham số nào bắt buộc, tham số nào tuỳ chọn cũng ảnh hưởng đến việc model có gọi đúng tool hay không.
Kỹ năngHọc viên viết được một mô tả tool đủ ba phần, và phân biệt được tham số bắt buộc với tham số tuỳ chọn.
Hình thứcVideo 6 phút, cùng một tool với ba mô tả khác nhau dẫn đến ba hành vi chọn tool khác nhau.
6.3Khi tool lỗi, agent nên làm gì●●○Nhà5′
Ý chínhTool có thể lỗi vì nhiều lý do — dịch vụ bên ngoài không phản hồi, tham số sai định dạng, hoặc vượt giới hạn số lượt gọi — và cách agent phản ứng với lỗi quan trọng không kém việc gọi tool đúng lúc đầu. Một nguyên tắc hiệu quả là trả về thông báo lỗi rõ ràng để model tự sửa và gọi lại, thay vì một thông báo lỗi chung chung không giúp ích gì; ví dụ báo "không tìm thấy thành phố" thay vì chỉ báo "gặp lỗi" giúp model tự đoán và sửa tên thành phố viết sai. Một hệ thống nên có phương án dự phòng khi tool chính không phản hồi được, thay vì để toàn bộ agent dừng lại.
Kỹ năngHọc viên thiết kế được một thông báo lỗi giúp model tự sửa, và nêu được một phương án dự phòng khi tool không phản hồi.
Hình thứcVideo quy trình 5 phút, sơ đồ ba loại lỗi và cách xử lý tương ứng cho từng loại.
6.4Tool tốt là tool như thế nào●●○Nhà5′
Ý chínhMột tool tốt có kết quả có thể dự đoán được — cùng một tham số đầu vào luôn cho ra kết quả nhất quán về định dạng, không phải lúc đúng một cấu trúc rồi lúc khác lại đổi khác. Độ chi tiết (granularity) của tool cần vừa phải: tool quá nhỏ, tách riêng từng trường dữ liệu, khiến model phải gọi nhiều lần cho một việc; tool quá to, gộp nhiều chức năng khác nhau, khiến model khó chọn đúng thao tác. Tham số nên rõ ràng, có kiểu dữ liệu cụ thể, và kết quả trả về nên ở dạng gọn, có cấu trúc để model đọc lại dễ dàng, không cần trả về nguyên văn dữ liệu thô nếu chỉ vài trường thông tin thực sự cần thiết.
Kỹ năngHọc viên đánh giá được một tool có granularity phù hợp hay không, và thiết kế được tham số cùng kết quả trả về cho một tool đơn giản.
Hình thứcVideo 5 phút, ví dụ đối chiếu ba tool quá nhỏ với một tool gộp quá nhiều chức năng.
6.5Thực hành: viết hai tool schema cho một dự án cụ thể●●○Lớp5′
Ý chínhHọc viên chọn một dự án hoặc tình huống quen thuộc và viết schema cho hai tool phục vụ tình huống đó, áp dụng các nguyên tắc vừa học về mô tả, tham số, và độ chi tiết. Sau khi viết, học viên đối chiếu với một bộ tiêu chí ngắn — mô tả có nêu khi nào dùng và khi nào không, tham số có đủ rõ ràng — để tự đánh giá bài của mình trước khi xem góp ý.
Kỹ năngHọc viên tự viết được hai tool schema hoàn chỉnh và tự đánh giá được bài viết của mình theo tiêu chí đã học.
Hình thứcTương tác 5 phút: viết schema rồi đối chiếu với tiêu chí tự đánh giá. Phương án thay thế: bài tập viết, nộp để nhận góp ý sau.
6.6Quiz Module 6●●○Nhà5′
Ý chính4 câu kiểm tra: vai trò của model so với ứng dụng trong tool calling, vì sao description là một phần của prompt, cách viết một thông báo lỗi giúp model tự sửa, và dấu hiệu một tool có granularity chưa phù hợp.
Kỹ năngHọc viên tự kiểm tra bốn ý chính của module trước khi vào lab.
Hình thứcQuiz 4 câu, chấm ngay.
Tổng kết
TTổng kết ngày●●○Lớp3′
Ý chínhGiảng viên trả lời câu hỏi mở đầu ngày học bằng các điểm chính: một prompt tốt là prompt tạo hành vi ổn định chứ không phải prompt nghe hay; system prompt cần đủ năm phần và phải được test qua nhiều lượt; ngữ cảnh có giới hạn thực tế cả về dung lượng lẫn vị trí thông tin; và tool calling là một vòng lặp trong đó model quyết định còn ứng dụng thực thi. Giảng viên nhấn mạnh: phần lớn lỗi của một agent trong thực tế không nằm ở việc chọn model, mà nằm ở prompt chưa đủ rõ hoặc tool schema chưa đủ chặt.
Kỹ năngHọc viên tóm tắt được các điểm chính của ngày học bằng ngôn ngữ của mình.
Hình thứcVideo giảng viên, 3 phút.
Mở rộng
Bốn video dành cho học viên muốn đi sâu hơn. Không bắt buộc; có thể xem sau khi hoàn thành ngày học.
M.1System prompt có thể tự thay đổi theo ngữ cảnh không●○○Nhà4′
Ý chínhMột số phần trong system prompt có thể được sinh động theo thời điểm gọi, ví dụ chèn ngày hiện tại hoặc thông tin người dùng vào một chỗ trống định sẵn trong prompt, thay vì viết cố định. Kỹ thuật này thường tách phần tĩnh, ít thay đổi và có thể lưu đệm để giảm chi phí xử lý, khỏi phần động thay đổi mỗi lần gọi, giúp hệ thống vừa linh hoạt vừa hiệu quả. Mở rộng cho item 3.1.
Kỹ năngHọc viên phân biệt được phần tĩnh và phần động trong một system prompt, đủ nền để tự thiết kế một system prompt có chèn biến.
Hình thứcVideo 4 phút, một system prompt có chỗ trống được điền giá trị động qua từng lượt gọi.
M.2Tool đọc và tool ghi khác nhau ở rủi ro nào●○○Nhà4′
Ý chínhTool chỉ đọc dữ liệu và tool có thể ghi hoặc thay đổi dữ liệu mang mức rủi ro rất khác nhau nếu model gọi sai. Một cách phân loại thực dụng là xếp các tool theo bậc rủi ro tăng dần, từ đọc thông tin công khai đến hành động không thể hoàn tác, và chỉ cấp cho agent đúng quyền cần thiết cho công việc — nguyên tắc đặc quyền tối thiểu. Các hành động ở bậc rủi ro cao nên yêu cầu xác nhận của con người trước khi thực hiện. Mở rộng cho module 6.
Kỹ năngHọc viên xếp được một tool bất kỳ vào đúng bậc rủi ro và xác định được tool nào cần xác nhận của con người.
Hình thứcVideo 4 phút, bậc thang sáu mức rủi ro từ đọc đến hành động không thể hoàn tác.
M.3Sau prompt và tool, còn lớp nào phải kỹ thuật hoá●○○Nhà5′
Ý chínhMột agent hoàn chỉnh không chỉ có model và tool, mà còn có một lớp điều phối xung quanh — gọi là harness — quản lý cách nạp tool, cách nạp hướng dẫn theo tình huống, và cách agent truy cập tài nguyên bên ngoài. Xu hướng gần đây là chuẩn hoá các bề mặt này hơn, để một agent có thể dùng lại tool và hướng dẫn giữa nhiều dự án khác nhau. Mở rộng cho toàn bộ ngày học.
Kỹ năngHọc viên mô tả được harness là lớp gì so với model và tool, đủ nền để tìm hiểu sâu hơn ở giai đoạn sau.
Hình thứcVideo 5 phút, sơ đồ agent bằng model cộng harness.
M.4Gọi tool tuần tự hay song song — và vòng lặp tool tối thiểu trông ra sao●○○Nhà5′
Ý chínhKhi một tác vụ cần gọi nhiều tool độc lập với nhau, gọi song song nhanh hơn gọi tuần tự nhưng tốn tài nguyên hơn và cần logic gộp kết quả rõ ràng; ba cách tổ chức thường gặp là chạy tuần tự, chạy song song, và chạy song song có điều kiện tuỳ kết quả bước trước. Một vòng lặp tool calling tối thiểu chỉ cần vài dòng mã: gửi yêu cầu, nhận yêu cầu gọi tool nếu có, thực thi, gửi kết quả lại — bản chịu lỗi thêm phần bắt lỗi và giới hạn số lần lặp. Mở rộng cho module 6.
Kỹ năngHọc viên chọn được cách tổ chức tuần tự hoặc song song phù hợp cho một tác vụ nhiều tool cụ thể.
Hình thứcVideo quy trình 5 phút, ba cách tổ chức minh hoạ trên cùng một ví dụ, nối tiếp bằng đoạn ghi màn hình vòng lặp tool tối thiểu.
Lab
LLab 4: xây agent đầu tiên với system prompt, hai tool và 5 câu test●●●Lớp150′
Ý chínhHọc viên viết một system prompt production-grade, khai báo hai tool — một tool gọi API bên ngoài và một tool truy vấn dữ liệu có sẵn — rồi nối chúng vào một vòng lặp agent hoàn chỉnh. 5 câu hỏi test được thiết kế để chứng minh agent phân biệt đúng khi nào nên trả lời trực tiếp và khi nào nên gọi tool, bao gồm cả trường hợp từ chối một câu hỏi ngoài phạm vi. Lab chạy được ngay với một model giả lập không cần khoá API, và có thể chuyển sang chạy với model thật khi cần. Học viên nộp lại ghi chú phân loại lỗi theo ba nhóm: lỗi do prompt, lỗi do tool schema, hay lỗi do luồng điều khiển.
Kỹ năngHọc viên xây dựng được một agent chạy được có system prompt, hai tool, và 5 câu test, đồng thời tự chẩn đoán được nguồn gốc của một lỗi cụ thể trong ba nhóm đã học.
Hình thứcLab 150 phút tại lớp, theo repo có sẵn với vòng lặp agent, hai tool mẫu, và bộ 5 câu test. Kèm checklist tự rà 6 mục trước khi nộp.