Quy trình 3 bước tôi đang chạy thật ở công ty mình, và đang lắp cho khách hàng của tôi. Anh em copy được.
Bài này tôi viết lại nguyên cái hệ thống AI Agent đang vận hành doanh nghiệp của tôi, đúng như tôi demo trong video ngay dưới đây, bổ sung thêm phần kỹ thuật mà video không kịp nói hết. Anh em đọc xong là lắp được, không phải đoán.
Video gốc dài một tiếng, tôi demo trực tiếp trung tâm điều hành và đi hết cả ba bước. Anh em xem video hay đọc bài trước đều được. Bài này có thêm phần số liệu và phần giới hạn mà video không kịp nói.
Tôi sẽ đi đúng thứ tự này:
- Kết quả cuối trông như thế nào. Anh em thấy đích trước, rồi mới đi.
- Bước 1: bóc nghiệp vụ. Chưa đụng đến AI.
- Bước 2: AI-native hoá. Nối dữ liệu, đóng gói skill, chia việc cho nhiều agent, dựng giao diện.
- Bước 3: vòng lặp nâng cấp.
- Giới hạn thật của cách làm này. Chỗ này quan trọng, tôi không giấu.
- Việc cụ thể anh em làm được trong 7 ngày tới.
Vì sao đưa AI vào doanh nghiệp hay thất bại?
Tôi đi cố vấn cho các doanh nghiệp, có cả tập đoàn. Câu hỏi lặp đi lặp lại là: làm sao chuyển một công ty đang làm kiểu truyền thống thành một công ty dùng AI mà ra được giá trị thật.
Và tôi thấy hai cái sai lặp lại y hệt nhau.
Sai thứ nhất: trong công ty ai cũng có dùng AI, nhưng không có nguyên tắc chung nào cả. Anh chị em khi nào bí mới bật AI chat lên hỏi một câu. Xong. Hôm sau lại bắt đầu lại từ đầu. Phối hợp với nhau thì rất khó, vì mỗi người một kiểu. Cái đó không phải là công ty dùng AI. Cái đó là mấy chục người dùng AI riêng lẻ trong cùng một toà nhà.
Sai thứ hai, và cái này tốn tiền hơn nhiều: bắt đầu từ tool, từ agent của người khác. Anh em lên mạng, thấy người ta rao "tôi có hàng trăm skill, hàng nghìn prompt", "bộ 20 agent dựng sẵn". Tải về. Rồi để đó chơi thôi, không áp dụng được vào công việc. Vì sao? Vì cái agent đó nó khít với nghiệp vụ của người viết ra nó, không khít với nghiệp vụ của anh em. Muốn dùng thì phải tinh chỉnh. Mà để tinh chỉnh được thì anh em phải hiểu nó trước. Công sức bỏ ra để hiểu cái của người khác nhiều khi lớn hơn công sức tự viết cái của mình.
Cái này không phải cảm nhận của riêng tôi. Báo cáo The GenAI Divide: State of AI in Business 2025 của MIT NANDA đo trên các doanh nghiệp và ra một con số khá phũ: doanh nghiệp đã đổ vào GenAI khoảng 30 tới 40 tỷ đô, và 95% tổ chức không thu về được gì đo đếm được trên P&L. Chỉ 5% công cụ AI tuỳ biến đi được tới production. Lý do họ ghi ra là: quy trình dễ gãy, không học được ngữ cảnh của doanh nghiệp, và lệch với việc hàng ngày (MIT NANDA, 2025, bản tin Fortune).
Anh em đọc lại ba cái lý do đó đi. Cả ba đều là bệnh của việc bắt đầu từ công cụ thay vì bắt đầu từ việc mình đang làm.
Nên nguyên tắc số một của tôi, và tôi sẽ nhắc lại ở cuối bài:
Bắt đầu từ nghiệp vụ. Đừng bắt đầu từ agent hay từ tool.
Nghiệp vụ của anh em thì anh em hiểu sẵn rồi. Không phải học ai cả.
Đội ngũ AI Agent vận hành doanh nghiệp trông như thế nào?
Tôi cho anh em xem đích trước.

Trung tâm điều hành AI là gì?
Ý tưởng này tôi lấy từ mấy bộ phim Mỹ. Trong lúc chiến đấu thì họ có một cái Bộ Chỉ huy. Mọi radar, mọi dữ liệu đổ về đó, và người ta ra lệnh dựa trên cái phòng đó. Không ai vừa đánh vừa chạy đi mở từng cái màn hình rời rạc.
Ở đây cũng vậy thôi. Tôi đưa toàn bộ công việc của mình lên một giao diện duy nhất. Tôi gọi nó là trung tâm điều hành AI.
Trên đó có gì?
Một ô chat ở trên cùng. Đây là ông CEO. Tôi ra lệnh vào đây. Ông này không tự làm, ông ấy đọc yêu cầu rồi phân việc xuống dưới.
Bên dưới là các phòng ban. Đúng nghĩa phòng ban như trong công ty:
| Phòng | Có những ai | Ông này chọc vào đâu để lấy dữ liệu |
|---|---|---|
| Marketing | Chuyển video YouTube thành bài LinkedIn · Ban biên tập đa nền tảng · Thiết kế hình ảnh | YouTube, kho nội dung cũ của tôi |
| Vận hành | Kiểm tra và phân tích database · Đề xuất tạo skill và agent mới | Data warehouse của công ty |
| Cộng đồng | Kiểm tra cộng đồng học viên · Chia timeline buổi coaching | Nền tảng cộng đồng, các buổi Zoom đã ghi |
Cái ông "đề xuất tạo skill và agent mới" ở phòng Vận hành, tôi sẽ nói kỹ ở Bước 3. Ông này giống trưởng ban nhân sự. Ông ấy đi soi xem công ty có việc gì đang lặp đi lặp lại mà chưa ai đóng gói lại không, rồi đề xuất "anh nên tuyển thêm vị trí này".
Giao một lúc ba việc, chúng nó tự bàn giao cho nhau thế nào?
Đây là chỗ tôi thích nhất. Tôi kể lại đúng cái tôi làm trong video.
Tôi gõ vào ô CEO: chuyển nội dung video này thành một bài viết trên LinkedIn, và tôi cũng muốn có một ảnh thể hiện nội dung này. Kèm một link YouTube.
Ông CEO đọc, hiểu ý, rồi tự chia:
- Bước 1/2: giao cho ông viết LinkedIn.
- Bước 2/2: sau khi ông LinkedIn xong thì chuyển cho ông thiết kế hình ảnh.
Tôi không phải nói với ông thiết kế là "nội dung đã viết xong rồi, đây là kết quả, mày làm ảnh đi". Hai ông tự bàn giao cho nhau.
Trong lúc chờ, mấy ông còn lại đang ngồi chơi. Nên tôi giao tiếp:
- Kiểm tra tải database trong hai ngày gần nhất. Ông vận hành nhận việc, chạy song song.
- Kiểm tra cộng đồng học viên xem có gì mới, có ai cần tôi hỗ trợ không.
- Buổi Zoom này cắt giúp tôi timeline, xem đoạn nào tách ra làm video ngắn được.
Bốn luồng chạy cùng lúc. Giống hệt anh em có bốn nhân sự và giao việc liên tục. Không ai chờ ai.

Kết quả về: bài LinkedIn xong trước, và cái tôi để ý nhất là nó dùng đúng từ ngữ của tôi. Nó xưng "tôi", gọi người đọc là "anh em". Nó không viết cái giọng AI trơn tuột. Vì sao được như thế, tôi nói ở phần Skill bên dưới. Ngay sau đó ông thiết kế nhận bàn giao và chạy tiếp. Ông check database thì lâu hơn, vì hệ thống của tôi check phức tạp, nhưng kệ ông ấy, ông ấy vẫn đang chạy.
Trung tâm này còn theo dõi được những gì?
Kéo xuống dưới trung tâm điều hành là phần theo dõi. Tôi đưa tất cả thứ tôi cần nhìn hàng ngày lên cùng một chỗ:
- Lịch Google Calendar của hôm qua, hôm nay, ngày mai. Nhìn một phát là biết hôm nay có gì phải chú ý.
- Danh sách lead. Là những doanh nghiệp, cá nhân đã điền form quan tâm đến dịch vụ của tôi. Bao nhiêu người, mấy ngày gần đây.
- Tin tức Agentic AI mới nhất. Tôi không muốn mất thời gian đọc trên quá nhiều diễn đàn, nên tôi cho nó đi lấy về từ kênh chính chủ: Anthropic, OpenAI, Google.
- Dữ liệu quảng cáo Facebook, gồm cả quảng cáo của đối thủ. Cái này tôi nói kỹ ở phần Artifact.
Thay vì mở YouTube một cửa sổ, lịch một cửa sổ, form một cửa sổ, hệ thống quản lý khách hàng một cửa sổ, thì tất cả nằm ở đây. Hiệu suất của anh em bị ăn mòn nhiều nhất là ở chỗ nhảy qua nhảy lại giữa các cửa sổ, chứ không phải ở chỗ làm việc.
Vậy đằng sau cái demo đó là gì?
Bóc tách ra thì chỉ có bốn thứ:
- Một nơi ra lệnh tập trung. Ông CEO. Ra lệnh ở đây, hoặc ra lệnh thẳng cho từng nhân viên cũng được. Ra lệnh đồng thời nhiều ông cũng được. Ra lệnh nối tiếp nhau cũng được.
- Mỗi ông chọc vào một nguồn dữ liệu khác nhau. Ông cộng đồng chọc vào dữ liệu cộng đồng. Ông timeline chọc vào các buổi Zoom. Ông YouTube-to-LinkedIn chọc vào YouTube. Đây chính là phần MCP.
- Mỗi ông có một quy trình cố định để làm. Đây chính là phần Skill.
- Tất cả điều phối trên một giao diện.
Và một điều tôi nói rõ: AI cộng với con người. Con người ở đây là chính chúng ta. Chúng ta chịu trách nhiệm thiết kế ra từng ông nhân sự AI nhỏ này, từng skill nhỏ này. Và chúng ta chịu trách nhiệm xác nhận lại kết quả nó làm có ổn hay không. Không có chuyện thả ra rồi đi ngủ.
Bước 1: Bóc nghiệp vụ ra thành từng bước, chưa đụng đến AI
Bước này không có AI trong đó. Không một chữ nào.
Lúc mới bắt đầu, anh em sẽ có cảm giác công việc của mình lằng nhằng lắm. "Việc của em nhiều đặc thù lắm, nhiều ngoại lệ lắm, em cũng không biết lúc nào thì kết thúc". Tôi nghe câu này nhiều rồi.
Cách xử lý đơn giản nhất: thay vì nhìn mọi thứ rối bòng bong, hãy ghi lại quá trình mình làm việc thành các bước.
Anh em chỉ cần làm lại đúng cái việc đó một lần nữa, và vừa làm vừa ghi. Nó chắc chắn phải có điểm khởi đầu. Rồi nó đi qua từng bước một, từng bước một, cho tới lúc ra kết quả. Bước nào to quá thì tách thành bước 1.1, bước 1.2. Không sao hết.
Mỗi bước ghi ba thứ:
- Đầu vào: bước này nhận thông tin từ đâu, lấy dữ liệu ở chỗ nào.
- Việc làm: làm gì với cái đầu vào đó.
- Ngoại lệ: chỗ này có trường hợp nào bất thường không, ví dụ dữ liệu bị sai thì xử lý thế nào.
Viết hết ra. Toàn bộ cái đó chính là một system, một hệ thống. Nó đảm bảo rằng đưa một thứ vào thì ra được một kết quả dùng được trong thực tế.
Và anh em làm chủ được nó rồi, vì nó là việc anh em vẫn làm hàng ngày.
Ví dụ thật: quy trình chuyển video YouTube thành bài LinkedIn của tôi
Tôi làm video YouTube để chia sẻ. Rồi để đỡ tốn công, tôi chuyển nội dung đó thành bài LinkedIn. Trước khi có AI, tôi làm bằng cơm như thế này:
| Bước | Đầu vào | Việc làm | Đầu ra |
|---|---|---|---|
| 1 | Link video | Lấy nội dung, lấy transcript | Text đầy đủ của video |
| 2 | Text đầy đủ | Bóc tách ra các chủ đề chính có trong video | Danh sách chủ đề |
| 3 | Danh sách chủ đề | Chọn ra một chủ đề để viết. Không cần sáng tạo gì, chỉ chọn | Một chủ đề |
| 4 | Một chủ đề | Lên dàn ý, rồi viết lại ý đó thành bài | Bản nháp |
| 5 | Bản nháp | Kiểm tra tính tuân thủ. Hai loại: cách dùng từ ngữ của tôi, và luật của LinkedIn (độ dài, phải có call to action ở cuối) | Đạt hoặc không đạt |
| 6 | Bản đạt | Chốt bài | Bài LinkedIn hoàn chỉnh |
Sáu bước. Không có gì cao siêu. Nhưng anh em để ý bước 5. Đó là bước kiểm tra tiêu chuẩn. Nếu không đạt thì quay lại sửa. Đây là bước mà hầu hết mọi người quên ghi ra, và cũng chính là bước làm cho AI chạy ổn định về sau.
Mẫu bóc nghiệp vụ để anh em copy
Anh em mở một file text, chép cái khung này vào, rồi điền:
QUY TRÌNH: [tên việc]
KHI NÀO CHẠY: [tình huống nào thì tôi làm việc này]
BƯỚC 1: [tên bước]
Đầu vào: [lấy từ đâu]
Việc làm: [làm gì]
Đầu ra: [ra cái gì]
Tiêu chuẩn: [thế nào là xong, thế nào là đạt]
Ngoại lệ: [nếu ... thì ...]
BƯỚC 2: ...
Làm xong bước này, anh em có trong tay một tài liệu text. Nghe thì tầm thường. Nhưng đây chính là nguyên liệu để tạo skill ở bước sau. Bởi vì bản chất skill cũng chỉ là tập các bước viết ra thành text.
Bước 2: AI-native hoá, đưa nghiệp vụ đó cho AI làm
Bây giờ mới đến AI.
Nhìn lại cái hệ thống các bước vừa viết, tôi đặt hai câu hỏi cho từng bước:
- Bước này cần nguồn dữ liệu gì?
- Bước này có tiêu chí đánh giá gì?
Ví dụ bước 1 của tôi cần transcript YouTube. Vậy tôi phải làm sao cho con AI của tôi vào được YouTube. Nếu nó không vào được thì tôi phải vứt transcript vào cho nó. Đơn giản vậy thôi. Con AI làm việc thì nó cũng cần nguồn thông tin giống mình.
Ví dụ bước 5 của tôi có tiêu chuẩn "bài không quá 2000 từ". Vậy sau khi máy viết xong, nó phải tự đếm số từ và so lại. Không đạt thì xử lý lại.
Mục tiêu của bước 2 gói lại trong một câu: đưa toàn bộ nguyên liệu mình đang dùng để làm việc cho ông AI làm.
Cụ thể là bốn việc. Tôi đi từng cái.
MCP là gì và nối AI vào dữ liệu công ty thế nào?
Anh em hình dung thế này. Dữ liệu của anh em nó giống một ngôi nhà. Trong nhà có đồ. Facebook thì trong đó có quảng cáo. Hệ thống CRM thì trong đó có thông tin khách hàng. Muốn vào lấy đồ thì phải đi qua cánh cổng.
Trước đây, muốn qua cánh cổng đó thì anh em phải có đội kỹ thuật. Phải đối mặt với API, với kết nối database, với một đống thuật ngữ mà người không làm công nghệ nghe xong là ngại.
Bây giờ nó có một cái chuẩn tên là MCP. Bản chất là gì? Bản chất nó là một quy chuẩn chung để nối bất kỳ con AI nào vào bất kỳ ứng dụng nào. Và các hãng đã làm sẵn con đường đó rồi, anh em chỉ việc dùng.
Vài dữ kiện để anh em yên tâm chọn:
- MCP do Anthropic công bố mã nguồn mở ngày 25/11/2024 (Anthropic). Nó sinh ra để giải cái bài toán mà chính họ gọi là "N nhân M": có N con AI, M nguồn dữ liệu, ngày xưa phải viết N nhân M cái kết nối riêng.
- Tháng 3/2025 OpenAI adopt chính thức. Google, Microsoft, GitHub, Cursor lần lượt theo (Wikipedia).
- Tháng 12/2025 Anthropic chuyển giao MCP cho Linux Foundation, cùng OpenAI, Google, Microsoft, AWS lập Agentic AI Foundation (The Verge).
Nói cách khác, đây không còn là chuẩn riêng của một hãng nữa. Nó là chuẩn chung của ngành. Đây chính là lý do tôi luôn khuyến cáo anh em đi theo các hãng lớn, đừng chạy theo mấy cái tool nhỏ lẻ. Tool giống như đi thuê phòng, chủ đuổi lúc nào cũng được. Hãng thì như mảnh đất. Hãng càng lớn thì mọi thứ càng dễ cho anh em.
Trường hợp 1: hãng đã làm sẵn đường. Trong Claude, anh em vào Customize, kéo xuống phần Connector. Trong đó có sẵn Gmail, Google Calendar, Office 365 và rất nhiều thứ khác. Ấn Connect là xong. Nối Gmail một phát là nó đọc được toàn bộ email, phân tích email gửi đến cho mình. Nối Calendar thì nó biết hết lịch làm việc và tư vấn được cho tôi sắp xếp.
Trường hợp 2: chưa có sẵn. Ví dụ Facebook. Anh em search trong danh sách sẽ không thấy. Thì làm thế này:
- Ấn Add, chọn Custom connector.
- Điền đường dẫn tới MCP server của bên đó. Với Facebook Ads là
mcp.facebook.com. - Đặt tên tuỳ ý, ví dụ "Facebook Ad".
- Ấn Add, rồi Connect. Nó hỏi "có muốn Claude kết nối với MCP Server quảng cáo Facebook không". Đồng ý.
Xong. Sau đó anh em nói chuyện với AI bình thường. Tôi gõ thống kê các quảng cáo liên quan tới từ khoá AI. Tôi không cần nói "hãy kết nối vào Facebook Ads MCP". Tôi chỉ nói về mặt ngữ nghĩa. Nó tự phân tích ý tôi, tự đi tìm trong đống kết nối của nó xem có con đường nào tới Facebook không, rồi tự dùng.
Và đây là câu hỏi anh em nào cũng nên hỏi: cho nó chọc vào hệ thống thì nó được quyền làm những gì?
Câu hỏi này hoàn toàn chính đáng. Anh em vào phần Connector, bấm vào cái kết nối của mình, bên dưới là toàn bộ danh sách những gì nó làm được, chia theo nhóm:
- Nhóm chỉ đọc. Ví dụ lấy chi tiết catalog. Ví dụ
ads_library_search, cái này cho phép đi tìm trong thư viện quảng cáo đang public của người khác. - Nhóm tương tác, tạo mới. Ví dụ tạo quảng cáo.
- Nhóm ghi và xoá.
Mỗi tool anh em chỉnh được quyền: luôn luôn đồng ý, hoặc phải duyệt. Cách tôi làm và tôi khuyên anh em làm y hệt:
Tool chỉ đọc thì để chạy thẳng. Tool có quyền ghi hoặc xoá thì bắt buộc để chế độ duyệt. Tôi phải bấm đồng ý thì nó mới được chạy.

Đây là chỗ nhiều người bỏ qua rồi sau đó gặp chuyện. Đừng bỏ qua.
Skill là gì và viết file SKILL.md ra sao?
Skill là gì? Bản chất nó là cái quy trình làm việc của mình, viết ra thành text để AI đọc được.
Vì sao phải là text? Vì tất cả các con AI của anh em nó chỉ làm việc thông qua việc đọc text, đọc thông tin đầu vào, hiểu ngữ nghĩa rồi làm. Nó như người vậy.
Về mặt file thì một skill là một thư mục, trong đó có một file mô tả và có thể có thêm mấy file tham chiếu. Trong thư mục cài đặt Claude có sẵn một folder tên skills. Skill nằm ở đó thì áp dụng cho toàn bộ các dự án.
Đây là cấu trúc thư mục thật của cái skill chuyển YouTube thành LinkedIn của tôi:
skills/
└── youtube-to-linkedin/
├── SKILL.md ← file mô tả, đây là cái chính
└── references/
├── voice-profile.md ← cách dùng từ ngữ của tôi
└── linkedin-rules.md ← luật định dạng của LinkedIn

references và file SKILL.md nặng 6 KB.File SKILL.md chỉ là file text thôi, đuôi .md. Anh em mở bằng Notepad cũng đọc được.
Nó gồm nhiều phần, nhưng hai phần quan trọng nhất là name và description.
Tại sao hai cái đó quan trọng? Vì nó liên quan tới cách AI quyết định có gọi skill của anh em hay không.
Cơ chế nó chạy như sau, và tài liệu chính thức của Anthropic gọi cái này là progressive disclosure (Anthropic Engineering):
| Tầng | Lúc nào nạp vào bộ nhớ | Tốn bao nhiêu | Nội dung |
|---|---|---|---|
| Tầng 1 | Ngay khi khởi động, luôn luôn | ~100 token mỗi skill | Chỉ name và description |
| Tầng 2 | Khi skill được gọi | dưới 5.000 token | Toàn bộ phần thân SKILL.md |
| Tầng 3 | Chỉ khi cần đọc tới | 0 cho tới lúc đọc | Các file trong references/ |
Đọc bảng này rồi thì anh em hiểu ngay hai chuyện.
Chuyện thứ nhất. Nếu anh em có 50 skill, thì lúc khởi động nó đọc 50 cái tên và 50 cái mô tả. Chỉ thế thôi. Nên anh em cài nhiều skill cũng không sao, nó không ăn hết bộ nhớ. Nhưng cái description mà viết mập mờ thì nó sẽ không biết khi nào phải gọi skill của anh em, và skill đó coi như vứt đi.
Chuyện thứ hai. Khi tôi yêu cầu "chuyển nội dung từ YouTube này thành bài LinkedIn", nó so cái yêu cầu của tôi với đống mô tả nó đã đọc. Khớp cái nào thì gọi cái đó. Gọi rồi nó mới chạy xuống đọc phần thân bên dưới.
Nên description phải trả lời được hai câu, không phải một: skill này làm gì và khi nào thì dùng nó.

name và dòng description nằm trên cùng. Kéo xuống là hai file tham chiếu voice-profile.md và linkedin-rules.md.Đây là file SKILL.md thật của tôi, anh em copy về sửa lại theo việc của mình:
---
name: youtube-to-linkedin
description: Chuyển nội dung một video YouTube thành một bài viết LinkedIn
đúng giọng của tôi. Dùng khi tôi đưa link YouTube kèm ý muốn có bài
LinkedIn, hoặc khi tôi nói "viết bài LinkedIn từ video này", "chuyển
video sang bài viết", "làm post LinkedIn từ YouTube".
---
# Chuyển video YouTube thành bài LinkedIn
## Nguyên tắc
Không sáng tạo thêm nội dung mới. Chỉ chọn và diễn đạt lại ý đã có
trong video. Nếu video không nói thì không được viết ra.
## Quy trình 6 bước
### Bước 1. Lấy nội dung
Lấy transcript của video. Nếu không lấy được, dừng lại và hỏi tôi.
Đầu ra: text đầy đủ của video.
### Bước 2. Bóc tách chủ đề
Đọc transcript, liệt kê các chủ đề chính có trong video.
Đầu ra: danh sách chủ đề, mỗi chủ đề một dòng.
### Bước 3. Chọn một chủ đề
Chọn ra một chủ đề đứng độc lập được, không cần xem video vẫn hiểu.
Báo cho tôi biết đã chọn cái nào và vì sao.
### Bước 4. Viết bài
Đọc references/voice-profile.md TRƯỚC KHI viết một chữ nào.
Lên dàn ý, rồi viết thành bài hoàn chỉnh.
### Bước 5. Kiểm tra tuân thủ
Đọc references/linkedin-rules.md.
Kiểm tra đủ 3 mục, ghi rõ đạt hay không đạt từng mục:
1. Đếm số ký tự. Vượt trần thì cắt bớt rồi đếm lại.
2. Có call to action ở cuối bài chưa.
3. Có từ nào nằm trong danh sách cấm ở voice-profile.md không.
Không đạt bất kỳ mục nào thì quay lại Bước 4. Không được bỏ qua.
### Bước 6. Chốt bài
Trả về bài hoàn chỉnh, kèm kết quả kiểm tra ở Bước 5.
Hai file tham chiếu trong references/ chứa gì?
voice-profile.md: cách dùng từ ngữ của tôi. Tôi xưng hô thế nào, tôi ngắt câu ra sao, những từ tôi không bao giờ dùng. Đây chính là lý do bài LinkedIn nó viết ra nghe được ra giọng tôi chứ không phải giọng AI.linkedin-rules.md: luật định dạng của LinkedIn. Trần cứng bao nhiêu ký tự, điểm cắt "xem thêm" ở đâu, vùng tối ưu bao nhiêu, cảnh báo thế nào.
Cả hai đều chỉ là file text. Và nhờ tầng 3 của progressive disclosure, chúng nó chỉ được đọc vào khi thật sự cần, nên có viết dài cũng không sao.
Từ lúc có skill, cách tôi làm việc đổi hẳn. Tôi không cần mô tả lại quy trình nữa. Tôi vứt cái link YouTube vào, ấn chạy. Nó tự biết phải chạy bước 1 tới bước 6, tự biết tiêu chuẩn ở bước 5 là gì.
Anh em thử nghĩ xem, nếu mỗi lần lại phải gõ lại toàn bộ quy tắc thì vừa tốn công, vừa rủi ro. Lần này gõ thiếu một dòng, lần sau gõ thiếu dòng khác, kết quả chạy không ổn định. Đóng thành skill là để nó ổn định.
Subagent khác Agent Team ở chỗ nào?
Phần này nhiều người hay băn khoăn vì thuật ngữ. Tôi nói cho đơn giản.
Khi anh em bật Claude lên, bản thân nó đã là một agent rồi. Anh em chat với nó, nó nối vào dữ liệu của anh em, nó chạy. Giống một công ty khởi nghiệp bé tí tẹo, có mỗi ông giám đốc làm tất.
Nhưng để một ông làm hết thì có một nhược điểm. Bộ nhớ của nó hữu hạn.
Nó phải nhớ những gì? Nhớ tất cả text anh em trao đổi với nó. Nhớ tất cả câu trả lời của nó. Nhớ nó đang nối vào những hệ thống nào. Nhớ nó có những skill gì. Cứ đưa vào thì nó cứ đầy dần. Đơn vị đo cái đó gọi là token. Token bản chất là tách cái đoạn text ra, text dài thì nhiều token. Giới hạn thường là khoảng 1 triệu token.
Tất nhiên đầy thì nó có cơ chế tự nén thông tin lại rồi chạy tiếp. Nhưng chúng ta hiểu rằng một ông làm quá nhiều thứ thì chất lượng không cao. Vấn đề nằm ở chất lượng.
Vì vậy mới đẻ ra hai kiểu gọi thêm người:
Kiểu 1: thuê thời vụ. Cái này gọi là subagent.
Tôi giao một nhiệm vụ, ví dụ "chuyển video YouTube này thành bài LinkedIn". Ông subagent nhận, tự lọ mọ chạy hết 6 bước. Ông CEO không quan tâm ông ấy làm thế nào ở giữa. Chạy xong, ông ấy trả về đúng cái bài LinkedIn hoàn chỉnh. Rồi biến mất. Toàn bộ bộ nhớ ông ấy dùng trong lúc chạy là bộ nhớ tạm, dùng xong xoá.
Đây chính là ý nghĩa của subagent. Anthropic mô tả đúng cơ chế này trong bài về hệ thống nghiên cứu đa agent của họ: mỗi subagent có thể dùng hết hàng chục nghìn token để làm việc của nó, nhưng chỉ trả về một bản rút gọn cỡ 1.000 tới 2.000 token cho ông chủ (Anthropic Engineering). Rác nằm lại trong đầu ông thời vụ. Ông sếp chỉ nhận kết quả sạch.
Kiểu 2: thuê nhân sự cố định. Cái này gọi là agent team.
Đẻ ra nhiều con agent khác, và chạy xong chúng nó vẫn còn nguyên trên hệ thống. Không biến mất. Lúc nào cũng còn một lượng bộ nhớ ở đấy. Chúng nó còn nhắn tin trực tiếp cho nhau được, chứ không phải cái gì cũng phải qua ông sếp.
Bảng chọn cho nhanh:
| Subagent (thời vụ) | Agent team (cố định) | |
|---|---|---|
| Xong việc rồi | Biến mất | Còn nguyên đó |
| Bộ nhớ | Riêng, xong thì xoá | Riêng, giữ lại |
| Nói chuyện với ai | Chỉ báo cáo cho ông gọi nó | Nhắn thẳng cho nhau được |
| Tốn token | Ít hơn | Nhiều hơn, mỗi ông là một bản Claude riêng |
| Hợp với việc gì | Việc rõ ràng, chỉ cần lấy kết quả cuối | Việc phải bàn bạc, phản biện, phối hợp |
Cả hai, khai báo đều chỉ là file text. Cái file mô tả agent nhìn khá giống cách viết skill: quan trọng vẫn là tên và mô tả ở trên, rồi quy trình ở dưới.
Ví dụ con agent kiểm tra cộng đồng học viên của tôi. Phần mô tả của nó ghi rõ: gọi con này khi tôi muốn kiểm tra cộng đồng có bài viết mới không, có câu hỏi nào chưa trả lời không, có ai nhắc tên tôi mà tôi cần phản hồi không. Nên tôi chỉ cần nói "kiểm tra cộng đồng học viên của tôi" là nó tự đi.
Và một con agent thì bên trong nó khai báo được nhiều skill. Con trợ lý cộng đồng của tôi có skill viết bài, có skill trả lời theo văn phong của tôi. Một trợ lý, nhiều kỹ năng. Giống hệt một nhân sự.
Vậy khi nào thì cần tách ra nhiều ông?
Tôi nói thẳng: việc nhỏ nhẹ thì một con là đủ. Không cần bày vẽ. Tôi tách ra nhiều con là vì cùng một lúc tôi phải điều phối nhiều việc: vừa kiểm tra dự án công nghệ thông tin, vừa kiểm tra database, vừa làm nội dung, vừa làm media, vừa chăm sóc khách hàng. Lúc đó mới cần thiết kế ra mấy ông này.
Còn nếu anh em chỉ có một luồng việc, dựng agent team vào chỉ tốn tiền.
Cái giá của việc gọi nhiều ông, tôi để số thật ở mục giới hạn.
Đưa dữ liệu lên giao diện bằng Artifact thế nào?
Phần cuối của bước 2. Làm sao đưa dữ liệu lên một cái giao diện tương tác được.
Cách đơn giản nhất là dùng Artifact. Tôi kể lại đúng cái tôi làm trong video.
Tôi đã nối Facebook Ad rồi. Bây giờ tôi tạo một artifact và bảo nó dựng cho tôi một giao diện theo dõi quảng cáo của đối thủ.
Và đây là điều tôi muốn anh em nhớ, vì nó đúng với mọi việc làm với AI chứ không riêng gì artifact:
Đưa cho nó ví dụ. Nếu không nó sẽ tự tạo theo ý của nó.
Tôi có sẵn hình dung trong đầu giao diện phải trông như thế nào, nên tôi gửi luôn cái mẫu đó cho nó.
Nó hỏi lại tôi mấy câu: theo dõi đối thủ theo danh sách page cụ thể, hay theo bộ từ khoá ngành, hay cả hai. Bố cục chính nên là gì. Có muốn phân tích thêm không. Tôi bảo chia hai tab cho cả hai kiểu, bố cục thì bảng cộng biểu đồ, thị trường Việt Nam, chỉ lấy quảng cáo đang active.
Kết quả ra một giao diện: gõ từ khoá vào, ví dụ "agentic AI", ấn tải dữ liệu. Nó ra danh sách quảng cáo đang chạy, tiêu đề quảng cáo, ngày bắt đầu chạy, số ngày đã chạy, và link để bấm vào xem chi tiết. Có nút pin để ghim một đối thủ lại mà theo dõi riêng.
Từ đó tôi biết ngoài kia người ta chạy thông điệp gì. Ví dụ đợt tôi quét thì thấy khoảng 1.886 quảng cáo liên quan tới chủ đề AI. Trong 50 mẫu lấy về: một nhóm chạy ưu đãi mà không nêu nỗi đau cụ thể, một nhóm chạy chủ đề nhân bản năng lực và hệ thống bộ não thứ hai, còn lại là chưa phân loại được. Tiêu đề thì kiểu "sự kiện dành cho CEO doanh nghiệp", "xây dựng hệ thống kinh doanh bằng AI".

Cái quan trọng không phải là con số. Cái quan trọng là tôi nhìn được thị trường đang nói gì mà không phải ngồi lướt tay.
Về sau anh em muốn đổi kiểu dashboard thì vứt cho nó cái mẫu khác. Muốn đơn giản hơn thì bảo nó làm đơn giản hơn. Nó sửa.
Bước 3: Vòng lặp nâng cấp, cho agent giỏi dần lên
Cái hay nhất của làm việc với AI là nâng cấp được.
Nghiệp vụ của anh em hôm nay mô tả thế này, mai phát hiện thiếu một trường hợp. Không sao. Cập nhật lại.
Cập nhật cái gì?
- Cập nhật quy trình. Luồng cũ có 4 bước, giờ đẻ thêm bước 4.1 rồi mới ra kết quả. Anh em chỉ việc mở file skill ra thêm một đoạn text vào. Vì skill thuần tuý là file text.
- Cập nhật nguồn dữ liệu. Lúc đầu bước 1 chỉ lấy từ YouTube. Giờ tôi muốn lấy thêm từ Google Drive, vì trong đó có rất nhiều transcript cũ tôi từng nói. Hoặc lấy thêm từ Facebook. Để làm gì? Để nó có nhiều nguồn tôi từng viết, từng nói hơn, thì nó nắm được giọng văn của tôi chi tiết hơn. Cắm thêm kết nối vào là xong.
- Cập nhật chính con agent. Agent học được, skill nâng cấp được.
Và đây là thứ tôi thấy thú vị nhất trong dashboard của tôi.
Tôi có một con agent trong phòng Vận hành chuyên đi tìm xem trong quá trình tôi làm việc, có việc gì đáng đóng gói thành agent hoặc skill mới không.
Nó chủ động soi: việc nào đang lặp đi lặp lại? Việc nào anh nên đóng thành agent? Việc nào anh nên đóng thành skill?
Giống trưởng ban nhân sự không ạ? Chủ động đi tìm rồi báo "anh nên thuê thêm người đi", và tất cả việc đó lại đóng cho agent làm. Nó liên tục tối ưu công việc của tôi.
Còn tôi làm nhiệm vụ gì? Tôi là người đánh giá kết quả. Con nào làm chưa ổn thì tôi biết mà cải tiến, mà nâng cấp nó.
Anh em có thể tạo ra các phòng ban bằng agent, và có một vòng lặp liên tục để cải tiến cái phòng ban đó. Giống công ty thôi. Thuê nhân sự về thì phải có vòng lặp để dạy nhân sự giỏi lên.
Một câu tôi luôn nói với khách hàng doanh nghiệp của tôi:
Nếu để hoàn hảo mới bắt đầu thì bắt đầu lâu lắm. Hãy bắt đầu đi. Chuyển một nghiệp vụ thành skill đi. Cho nó làm việc đi. Lúc đầu chuyển được ba cái cũng được, không sao cả. Lúc đầu nó sai một chút cũng không sao hết. Vì con người vẫn làm cùng và sửa cùng nó mà.
Nếu anh em có 0 điểm thì không nâng cấp được cái gì. Nhưng có 2 điểm, 3 điểm, 5 điểm thì nâng cấp được. Lúc đầu nó làm chậm thì cho nó nhanh lên. Chất lượng lúc đầu 80% thì cải thiện lên 90, lên 95%. Giống một người mới vào, mình dạy được.
Cứ làm đi. Sai lại sửa.
Ba bước gói lại trong một bức tranh
Gói lại toàn bộ vào một chỗ cho anh em dễ nhớ:
| Bước 1 · Nghiệp vụ | Bước 2 · AI-native hoá | Bước 3 · Loop | |
|---|---|---|---|
| Làm gì | Bóc việc đang làm thành từng bước, ghi ra text | Nối dữ liệu, đóng skill, chia agent, dựng giao diện | Cập nhật, dạy thêm, nâng cấp |
| Có AI chưa | Chưa. Thuần tuý việc của mình | Rồi | Rồi |
| Sản phẩm ra | Một tài liệu text mô tả quy trình | Skill, connector, agent, dashboard | Phiên bản tốt hơn của cả ba |
| Ai chịu trách nhiệm | Anh em | Anh em thiết kế, AI làm | Anh em chấm, AI học |
Ba bước này nối thành một vòng tròn. Đi hết một vòng là anh em chuyển được một mảng việc từ làm bằng cơm sang máy cộng người. Rồi nhân bản lên cho mảng tiếp theo.
Và nhớ cái này: sau bước 2, con AI nào cũng dùng được. Claude, Codex của OpenAI, Antigravity, hay bất kỳ con nào sau này ra. Vì tất cả chúng nó đều đọc text mà làm việc. Anh em không bị khoá vào một hãng nào cả. Cái tài sản anh em xây được nằm ở đống file text mô tả nghiệp vụ, không nằm ở cái tool.
Về chỗ ngồi điều hành: lúc đầu hệ thống còn bé thì một con CEO là đủ. Điều hành qua một dashboard, đừng để lẻ tẻ. Hiệu suất của anh em bị giảm chính vì phải vào nhiều nơi quá, lúc thì Excel, lúc thì Word, lúc thì hệ thống ERP, lúc thì trình duyệt. Tập trung một nơi thì làm việc nhanh hơn nhiều.
Bản thân tôi còn chuyển con agent điều hành tập trung của tôi thành một con trên Telegram, chạy trên điện thoại. Để làm gì? Để tôi đi cà phê cũng được, bật điện thoại lên và ra lệnh cho nó điều hành công việc công ty. Hoàn toàn làm được.
Cách làm này có giới hạn gì?
Phần này tôi không giấu, vì anh em cần biết trước khi lắp chứ không phải sau khi lắp.
1. Gọi nhiều agent thì tốn token thật, và tốn nhiều.
Theo số đo của chính Anthropic: một agent tiêu khoảng 4 lần lượng token so với chat thường. Hệ thống nhiều agent tiêu khoảng 15 lần so với chat thường (Anthropic Engineering). Ở phép so khác thì multi-agent tốn gấp 3 tới 10 lần single-agent cho cùng một việc.
Bù lại thì được gì? Trên bài đánh giá nội bộ của họ, hệ thống nhiều agent vượt một con Opus 4 chạy đơn khoảng 90,2%. Nên nó chỉ đáng khi việc đó đủ giá trị. Việc nhỏ mà gọi cả đội vào thì lỗ.
2. Nhiều agent không phải lúc nào cũng nhanh hơn.
Cái được của chạy song song là bao phủ được nhiều hướng hơn, không phải là xong sớm hơn. Tổng thời gian nhiều khi còn lâu hơn, vì tổng khối lượng tính toán tăng lên (Anthropic).
3. Việc nào chia được, việc nào không.
Chia theo ngữ cảnh, đừng chia theo loại việc. Nghiên cứu thị trường châu Á và thị trường châu Âu thì tách hai ông được, vì chúng nó không cần biết nhau. Còn lập kế hoạch, thực thi rồi kiểm thử của cùng một việc thì đừng tách, vì chúng nó dùng chung quá nhiều ngữ cảnh, tách ra chỉ mất công truyền qua truyền lại.
4. Facebook Ads MCP có giới hạn cứng.
Mặc định một lần quét chỉ lấy về tối đa 50 mẫu. Người ta có 500 quảng cáo thì cũng chỉ được 50. Nó không craw hết về cho anh em. Và nó không lấy được nội dung hình ảnh của quảng cáo. Muốn nghiên cứu ảnh thì vẫn phải bấm vào xem. Ít nhất nó cho biết sơ bộ.
5. Agent team hiện vẫn là tính năng thử nghiệm.
Trong Claude Code, agent team mặc định tắt, phải bật cờ CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1. Nó còn hạn chế quanh chuyện khôi phục phiên làm việc và điều phối task (tài liệu Claude Code). Anh em cứ dùng, nhưng đừng đặt việc sống còn lên nó lúc này.
6. Description viết mập mờ là skill vứt đi.
Cái này tôi nhắc lại vì nó là lỗi phổ biến nhất. Skill viết hay tới đâu mà mô tả không nói rõ khi nào dùng thì AI không bao giờ gọi tới nó. Anh em cứ tưởng nó không chạy được. Không phải. Nó không biết là phải chạy.
7. Phân quyền là việc của anh em, không phải của AI.
Tool ghi và xoá mà để chế độ tự động đồng ý thì sớm muộn cũng có chuyện. Để chế độ duyệt.
Bắt đầu từ đâu? Việc làm được trong 7 ngày tới
Đừng làm cả công ty một lúc. Làm một mảng thôi.
Ngày 1 tới 2. Chọn một việc và bóc nó ra. Chọn việc thoả ba điều kiện: anh em làm hàng tuần, mất trên 30 phút mỗi lần, và kết quả kiểm tra được là đúng hay sai. Mở file text ra, làm lại việc đó một lần và vừa làm vừa ghi theo mẫu ở Phần 2. Xong bước này anh em chưa cần biết AI là gì.
Ngày 3. Nối một nguồn dữ liệu. Vào Customize, phần Connector, nối đúng một nguồn mà bước 1 của quy trình cần. Gmail, Calendar, Drive, cái nào cũng được. Vào xem danh sách tool của nó, để tool ghi và xoá ở chế độ duyệt.
Ngày 4. Viết cái skill đầu tiên. Tạo thư mục, tạo file SKILL.md, chép mẫu SKILL.md ở mục Skill vào rồi thay bằng quy trình của anh em. Dành thời gian nhiều nhất cho description. Nhớ trả lời hai câu: làm gì, và khi nào dùng.
Ngày 5. Chạy thử 3 lần với 3 đầu vào khác nhau. Ghi lại chỗ nó làm sai. Không sửa vội. Cứ ghi ra đã.
Ngày 6. Sửa skill dựa trên 3 lần chạy đó. Chỗ nào nó làm sai thì nghĩa là bước đó tôi mô tả chưa đủ rõ, hoặc thiếu tiêu chuẩn. Bổ sung vào. Đây chính là vòng lặp ở Bước 3, chỉ là làm ở quy mô bé.
Ngày 7. Quyết định. Việc này đã chạy đủ ổn để tôi giao hẳn chưa? Nếu rồi thì chọn việc tiếp theo. Nếu chưa thì quay lại ngày 6.
Đến khi anh em có 4 tới 5 skill rồi thì lúc đó mới tính chuyện dựng agent, dựng dashboard. Đừng làm ngược.
Câu hỏi hay gặp
AI Agent khác gì con AI chat bình thường?
Khác ở chỗ agent tự chạy nhiều bước rồi mới trả kết quả, còn chat thì đáp từng câu một. Bản chất con chat là anh em hỏi một câu, nó đáp một câu. Còn agent là anh em giao một việc, nó tự đi lấy dữ liệu, tự chạy qua từng bước trong quy trình, tự kiểm tra rồi mới báo cáo. Giống giao việc cho nhân sự, chứ không phải hỏi một người quen.
Không biết code thì có làm được không?
Làm được. Skill và agent đều thuần tuý là file text, anh em mở Notepad ra gõ cũng xong. Phần nối dữ liệu thì bấm nút Connect trong mục Connector, không phải viết dòng code nào. Việc khó nhất trong cả quy trình này không nằm ở kỹ thuật. Nó nằm ở bước 1: ngồi viết cho rõ mình đang làm việc gì, đi qua mấy bước.
Chạy đội ngũ AI Agent tốn bao nhiêu tiền?
Tốn theo lượng token, và gọi càng nhiều agent thì càng tốn. Theo số đo của Anthropic, một agent tiêu khoảng 4 lần lượng token so với chat thường, còn hệ thống nhiều agent tiêu khoảng 15 lần. Nên việc nhỏ thì đừng gọi cả đội vào, lỗ. Tôi chỉ tách ra nhiều agent khi cùng lúc phải chạy nhiều mảng việc khác nhau.
Nên dùng một agent hay nhiều agent?
Việc nhỏ nhẹ thì một con là đủ, không cần bày vẽ. Chỉ tách ra nhiều con khi cùng lúc anh em phải điều phối nhiều mảng: vừa kiểm tra database, vừa làm nội dung, vừa chăm sóc khách hàng. Và chia theo ngữ cảnh, đừng chia theo loại việc. Hai hướng nghiên cứu độc lập thì tách được. Lập kế hoạch với thực thi của cùng một việc thì đừng tách, vì chúng nó dùng chung quá nhiều ngữ cảnh.
Skill khác prompt ở chỗ nào?
Prompt sống trong một cuộc hội thoại rồi mất, còn skill là file nằm trên ổ đĩa, lần nào chạy cũng theo đúng quy trình đó. Bản chất skill là quy trình làm việc của anh em viết ra thành text, có tên, có mô tả, có từng bước, có tiêu chuẩn kiểm tra. Anh em không phải gõ lại luật mỗi lần nữa.
Bao lâu thì thấy kết quả?
Một tuần cho mảng việc đầu tiên, nếu chọn đúng việc. Việc đáng chọn là việc làm hàng tuần, mất trên 30 phút mỗi lần, và kết quả kiểm tra được đúng hay sai. Đừng chờ hoàn hảo mới bắt đầu. Lúc đầu nó làm đúng 80% cũng được, vì có 80% thì mới nâng lên 95% được. Có 0 điểm thì không nâng được gì.
Đúc kết
Đúc kết ở đây là gì?
Toàn bộ bài này gói lại trong ba câu:
- Bắt đầu từ nghiệp vụ của mình. Đừng bắt đầu từ agent, đừng bắt đầu từ tool của người khác. Nghiệp vụ anh em hiểu sẵn rồi, không phải học ai.
- Đóng gói cái nghiệp vụ đó thành text. Nối nguồn dữ liệu bằng MCP, đóng quy trình thành skill, chia việc cho agent khi khối lượng đủ lớn. Sau bước này con AI nào cũng dùng được.
- Đừng chờ hoàn hảo mới bắt đầu. Có 2 điểm mới nâng lên 9 điểm được. Có 0 điểm thì không nâng được gì.
Và thứ tôi muốn anh em nhớ nhất: cái tài sản anh em xây được không nằm ở cái tool nào cả. Nó nằm ở đống file text mô tả cách công ty anh em làm việc. Tool thì như phòng đi thuê, chủ đuổi lúc nào cũng được. Đống text đó là của anh em.
Đây là những thứ tôi đã áp dụng, và đang đồng hành cùng nhiều doanh nghiệp khác, kể cả tập đoàn, họ đang áp dụng và có hiệu quả. Anh em cũng mang cách này vào công việc của mình được.
Anh em có câu hỏi nào, hoặc muốn tôi chia sẻ kỹ hơn phần nào, để lại bình luận dưới video nhá. Tuỳ anh em.
Nguồn tham khảo
- Introducing the Model Context Protocol · Anthropic, 25/11/2024
- Model Context Protocol · Wikipedia, mốc thời gian các hãng adopt
- AI companies want a new internet · The Verge, 12/2025, MCP chuyển về Linux Foundation
- Equipping agents for the real world with Agent Skills · Anthropic Engineering, cơ chế progressive disclosure
- Agent Skills overview · Claude Platform Docs, bảng 3 tầng nạp context
- Effective context engineering for AI agents · Anthropic Engineering, cơ chế subagent
- How we built our multi-agent research system · Anthropic Engineering, số liệu token và hiệu năng
- When to use multi-agent systems (and when not to) · Anthropic
- Orchestrate teams of Claude Code sessions · Claude Code Docs, so sánh subagent và agent team
- The GenAI Divide: State of AI in Business 2025 · MIT NANDA
- MIT report: 95% of generative AI pilots at companies are failing · Fortune, 18/08/2025



