Xây lõi hay chạy theo công nghệ AI? Và chuyện tiết kiệm token ở tầm doanh nghiệp

Tại phiên panel talk bên sự kiện RESET 2026 của Sapo, có bạn hỏi tôi 2 câu mà chắc nhiều CEO cũng đang thắc mắc:

• Học ứng dụng AI hôm nay, mai nó lỗi thời rồi thì sao?
• Dùng AI Agent mà nó tốn token quá thì mình làm gì?

Ý bạn đó là: làm sao xài AI Agent cho tiết kiệm token, mà công nghệ nó lại đổi xoành xoạch, hôm nay học cái này mai đã ra cái khác rồi. Cảm giác vừa ứng dụng xong đã.. lỗi thời.

Câu hỏi này gồm 2 phần, mà càng nghĩ tôi càng thấy cần tách ra trả lời riêng mới rõ được.

PHẦN 1: ĐUỔI THEO CÔNG NGHỆ LÀ CUỘC ĐUA KHÔNG CÓ ĐÍCH

Hôm đó trả lời nhanh, tôi nối tiếp ví dụ từ Giáp Đức Thắng có trả lời trước đó. Bạn ấy có hệ thống data warehouse, BI dashboard được thiết kế bài bản. Khi đưa AI vào để phân tích, trả lời, gợi ý hành động từ dữ liệu đó thì hiệu quả rất rõ.

Nhưng đó chỉ là một góc thôi. Muốn trả lời trọn vẹn thì phải tách 2 việc ra: cập nhật công nghệ, và thiết kế hệ thống cho doanh nghiệp.

Ai làm nghề này cũng phải cập nhật liên tục, chuyện đó đương nhiên, không ai né được. Nhưng nếu doanh nghiệp có một khung ứng dụng đúng đắn thì mình không cần phải FOMO chạy theo từng tin tức. Vẫn có lộ trình cập nhật của riêng mình.

Cách tôi hay làm là tách ra 2 phần: lõi và bề mặt.

Lõi là đi từ nỗi đau thật của doanh nghiệp, xác định cái gì hiện tại giải quyết được, từ đó thiết kế ra khung và hướng đi. Cái này gần như có rất ít thay đổi theo thời gian, tại nếu đổi hoài thì.. thời gian đâu doanh nghiệp làm ăn.

Bề mặt là công cụ hay tính năng AI cụ thể. Cái này thì tháo ra lắp vô tùy thời điểm cũng được.

Giống xây nhà thôi. Lõi là cái móng, bề mặt là nội thất. Đổi bộ sofa thì cuối tuần làm xong, còn đụng tới móng là nguyên cái nhà nó rung.

Ví dụ dễ thấy nhất gần đây là mảng tạo ảnh bằng AI. Đầu năm Nano Banana 2 của Google ra mắt, ai cũng khen tốc độ với chất lượng. Rồi tới tháng 4 GPT Image 2 của OpenAI ra, vượt mặt luôn Nano Banana 2 ở mấy bảng xếp hạng benchmark. Rồi cuối tháng 6 Google lại ra thêm Nano Banana 2 Lite, rẻ hơn, nhanh hơn.

–> Cứ vậy đó, 4-5 tháng đổi ngôi liên tục.

Nếu doanh nghiệp cứ chăm chăm học “dùng Nano Banana” như một kỹ năng cố định thì y như rằng vài tháng sau phải học lại từ đầu.

Nhưng nếu lõi của mình là “quy trình tạo hình ảnh sản phẩm cho catalogue, cần tốc độ X, độ chính xác chữ Y” thì công cụ nào đang tốt nhất tại thời điểm đó mình cứ lắp vô xài. Không cần phải trung thành với một cái tên.

Làm tốt phần lõi rồi thì việc còn lại chỉ là thay công cụ.

Doanh nghiệp cần sự ổn định để vận hành, nhân sự cần quy trình rõ để follow, chứ không thể hôm nay một kiểu mai một kiểu được.

Còn phần con người thì sao? Nhân sự cần được huấn luyện, training để thích nghi và nâng năng lực. Đây là chuyện tất yếu của nghề, giống như bao năm nay vẫn phải học kỹ năng mới theo thời gian vậy thôi, không có gì mới mẻ cả.

Mà nói thiệt.. cái framework lõi/bề mặt này nói thì gọn, làm thì không dễ đâu. Ví dụ của Thắng ở trên là doanh nghiệp đã có sẵn năng lực data engineering để xây BI dashboard đàng hoàng. Chứ SME nhỏ, chưa có ai rành dữ liệu, thì “xây lõi trước” nghe hay nhưng thực thi cả năm chưa xong à.

Nên đừng nghe tôi nói xong.. rồi về gom hết team lại xây lõi nha. Tuỳ sức mà làm.

PHẦN 2: TIẾT KIỆM TOKEN Ở TẦM DOANH NGHIỆP KHÁC TẦM CÁ NHÂN

Trước đó tôi có viết một bài về 7 thói quen tiết kiệm token cho người mới, chủ yếu là mẹo cá nhân khi chat với AI: gõ rõ ràng ngay từ đầu, edit thay vì chat tiếp, giữ chat dưới 10 lượt. Bạn nào chưa đọc thì tìm lại nhé, phần đó vẫn đúng và vẫn nên áp dụng.

Nhưng ở tầm doanh nghiệp, câu chuyện tiết kiệm token nó rộng hơn một chút. Vì đây là chuyện thiết kế hệ thống chứ không còn là thói quen gõ chat nữa.

Có 3 điểm tôi hay thấy doanh nghiệp mắc phải.

Một, xử lý trực tiếp trên file gốc. Nhiều người kêu AI chỉnh sửa tới lui ngay trên file HTML hay file Word, cực kỳ tốn token vì mỗi lần AI phải đọc lại toàn bộ định dạng, không chỉ nội dung. Cách tôi hay làm là kêu AI ra dữ liệu thô trước, tự sửa tay hoặc nhờ AI sửa trên bản thô đó, tới khi ưng ý mới xuất ra file cuối (PDF, Docs, email). Vừa kiểm soát được token, vừa biết rõ token mình tạo ra là do đâu.

Hai, để chat chồng chất quá nhiều lượt. Mỗi lần AI xử lý là nó cộng dồn hết kết quả và lịch sử chat trước đó vào. Chat tới 10-20 lượt là tốn kém khủng khiếp, y như bài 7 thói quen tôi từng nói. Ở tầm doanh nghiệp thì đây là chuyện phải training cho cả team hiểu, chứ không phải một mình CEO biết là đủ.

Ba, và cái này quan trọng nhất với ai đang làm AI Agent cho doanh nghiệp: thiết kế MCP chưa tốt. (MCP là Model Context Protocol, tạm hiểu là cách AI kết nối với hệ thống dữ liệu bên thứ ba.)

Một MCP chung chung, mô tả từng function không rõ ràng, thì AI Agent phải tự dò đường. Đi hướng này không được thì.. quay ra thử hướng khác. MCP dùng chung cho tất cả mọi người thường chỉ dừng ở mức API cơ bản, kiểu lấy danh sách, filter khách hàng. Nhưng nghiệp vụ thực tế phức tạp hơn nhiều, chỉ công ty mình hoặc trường hợp cụ thể mới có đường đi riêng.

Đội Anthropic có mô tả một case thật: agent cần lấy transcript cuộc họp từ Google Drive rồi ghi vào Salesforce.

Cách làm cũ, để AI gọi từng tool một rồi tự dò, thì riêng phần định nghĩa tool cộng dữ liệu trung gian đi qua lại context đã tốn khoảng 150.000 token. Khi đổi qua cách để AI viết code gọi thẳng vào hệ thống, giống kiểu lập trình viên viết script thay vì bấm tay từng bước, số token đó giảm còn 2.000.

Tức là tiết kiệm gần 99%.

–> Đọc con số này tôi mới thấy cái mình hay nói “gọi vào đúng 3 bước ra kết quả thay vì để AI chạy gần 100 bước” không phải nói cho vui, mà có dữ liệu thật chứng minh.

Mấy vụ MCP Code Mode team tôi học từ Tony cũng ứng dụng thường xuyên để giải quyết vấn đề này trong nhà rồi. Đợt offline lần trước tôi cũng có kể cho anh em nghe hơn 2 tiếng.

Cái khó là thiết kế MCP tốt cho đúng use case thực tế là việc của dân thiết kế hệ thống. Nói mấy từ như MCP hay code execution ra thì người ngoài chuyên môn cũng khó mà hình dung được, nên phần này thường phải có đội kỹ thuật ngồi lại làm riêng cho từng nghiệp vụ. Không thể giao cho một con AI generic làm hết.

Mà chỗ này tôi cũng phải công tâm miếng: EGANY của tôi làm công nghệ mà cũng đâu phải chỗ nào cũng ngon. Có mấy nghiệp vụ bọn tôi cũng đang dò.. sửa tới sửa lui hoài. Nên nói ra để anh em biết đường, chứ không phải đứng ngoài phán ^^

TÓM LẠI

Cập nhật công nghệ, đừng đuổi theo. Xây lõi cho chắc, còn bề mặt để đó tháo ráp tùy thời điểm.

Tiết kiệm token cá nhân là một chuyện, đọc lại bài 7 thói quen cho dân không chuyên. Còn tiết kiệm token ở tầm hệ thống là chuyện khác, nó nằm ở cách thiết kế MCP và quy trình xử lý dữ liệu.

Hai chuyện này thật ra là một.

Doanh nghiệp nào xây lõi tốt thì cũng tự nhiên tiết kiệm token tốt. Vì không có chuyện chạy tới chạy lui, dò đường, sửa sai liên tục.

Bạn đang thiết kế hệ thống AI cho doanh nghiệp mình theo hướng nào? Xây lõi trước, hay đang mải chạy theo tính năng mới? Comment tôi nghe thử coi :3

Nguồn tham khảo: case Google Drive sang Salesforce và con số 150.000 xuống 2.000 token lấy từ bài viết của đội Anthropic Engineering về code execution với MCP.

#voquoccuong #aiautomation #mcp #agenticworking