Đã gần hai tháng tôi không viết bài mới. Lý do lần này rất đơn giản: tôi đang bận ship. Hai tháng qua, Vietbooks chiếm gần như toàn bộ thời gian của tôi. Người dùng mới đăng ký đều đặn, và điều làm tôi vui nhất là họ dùng các chức năng AI ngay từ ngày đầu tiên, không cần ai hướng dẫn. Để theo kịp, anh em tôi và đội quân agent của mình đã merge hơn 660 pull request trong 58 ngày để sửa lỗi lớn nhỏ và thêm chức năng, trung bình hơn 11 PR mỗi ngày. Con số này hai năm trước tôi không dám mơ tới.

Sáng nay, giữa lúc đang review PR, tôi thấy tin DeepSeek ra mắt Flash-Vision: phiên bản V4 Flash có thêm khả năng nhìn và hiểu hình ảnh [1]. Với phần lớn mọi người, đây chỉ là thêm một model trong hàng chục model xuất hiện mỗi tháng. Còn tôi mở ngay bộ eval của Vietbooks ra chạy, vì nếu model này vượt qua, toàn bộ phần đọc sao kê ngân hàng và chứng từ của Vietbooks sẽ rẻ đi rất nhiều lần.

Với người trong ngành, cú sốc lớn nhất năm nay có lẽ chính là DeepSeek V4. Hai tháng qua là hai tháng quan trọng nhất của ngành AI kể từ đầu năm. Không phải vì có model nào “thông minh vượt loài người”. Mà vì một điều âm thầm và quan trọng hơn nhiều:

Đọc xong bài này, bạn sẽ có bức tranh đầy đủ về chuyện gì đang diễn ra, và vì sao đây là cơ hội vàng cho những người muốn đưa AI vào công việc thật.

Phần 1: Model đầu tiên “rẻ đến mức không cần đếm”

Đầu tháng 8, Jay, người đứng sau OpenCode, chia sẻ một con số đáng kinh ngạc: DeepSeek V4 Flash ra mắt ngày 1/8, và chỉ trong hai tuần, lưu lượng chạy qua nền tảng của họ tăng gấp 6 lần, từ 3 nghìn tỷ lên 18 nghìn tỷ token mỗi ngày [2]. Gần gấp đôi toàn bộ lưu lượng hằng ngày của OpenRouter.

Lý do không có gì bí ẩn: nó rẻ đến phi lý. Theo con số Jay đưa ra, nó rẻ hơn Fable 350 lần, rẻ hơn GPT-5.6 Sol 175 lần. Câu tôi tâm đắc nhất trong tweet của anh: lần đầu tiên người dùng được nếm cảm giác AI “too cheap to meter”, rẻ đến mức không cần đo đếm nữa.

Rồi ngày 16/8, DeepSeek tăng giá. V4 Flash từ mức phẳng $0.14/$0.28 mỗi triệu token input/output chuyển thành $0.22/$0.66 giờ thấp điểm và $0.44/$1.32 giờ cao điểm [3]. Lưu lượng lập tức rơi xuống dưới một nửa so với đỉnh. Bài học ở đây không phải về AI, mà về chuỗi cung ứng: nhu cầu dành cho trí tuệ giá rẻ lớn đến mức nhà cung cấp không gánh nổi.

Có một chi tiết thú vị ở đây: nhu cầu dùng AI ở Trung Quốc có lẽ cũng cao ngất ngưởng, nên khung giờ cao điểm DeepSeek chọn trùng khít giờ làm việc bên đó [4]. Mà giờ Trung Quốc chỉ đi trước Việt Nam một tiếng, nên khung đắt nhất rơi đúng giờ hành chính của chúng ta: 08:00 tới 11:00 và 13:00 tới 17:00. Nếu bạn làm phần mềm cho doanh nghiệp Việt và gọi DeepSeek trực tiếp, gần như toàn bộ lưu lượng của bạn rơi vào khung đắt nhất, còn người dùng ở Mỹ thì ngược lại, giờ làm việc của họ nằm gọn trong khung rẻ.

Mẹo nhỏ của tôi: việc nào không cần trả lời ngay (bóc tách chứng từ theo lô, báo cáo chạy đêm) thì dồn hết về sau 18 giờ, tự nhiên chi phí giảm một nửa mà không phải đổi gì cả.

Phần 2: Open weights vừa vượt mốc 2.000 tỷ tham số

DeepSeek chỉ là gương mặt nổi bật nhất của một làn sóng lớn hơn nhiều: các model mở đang đuổi kịp các phòng lab đóng của Mỹ, và mùa hè này họ vượt một cột mốc mang tính biểu tượng.

• Kimi K3 của Moonshot, mở weights ngày 27/7: 2.800 tỷ tham số MoE, context 1 triệu, multimodal. Model mở lớn nhất từng được phát hành [8].

• Qwen3.8-Max của Alibaba, giữa tháng 8: 2.400 tỷ tham số, lần đầu tiên Alibaba mở weights cho hạng Max, hạng cao nhất của họ [9].

• GLM-5.3 của Zhipu, ngày 14/8: 744 tỷ tham số, được xem là hệ thống coding mở mạnh nhất hiện nay. Weights hẹn cuối tháng 8 [10].

• MiniMax M3 và Step 3.7 Flash mở màn từ tháng 6: khả năng code tự động gần bằng nhóm dẫn đầu dù model nhỏ hơn hàng chục lần [13].

• Và điều tôi không ngờ nhất: áp lực này khiến Meta quay lại cuộc chơi, ship Muse Glimmer 30B dưới giấy phép Apache 2.0 chạy được trên một GPU 24GB [11], đồng thời tuyên bố sẽ mở weights cho cả flagship Muse Spark 1.2 [12].

Tôi cần nói rõ hơn ở hai chỗ. Thứ nhất, đây là open weights chứ không phải open source đúng nghĩa: bạn tải được model, nhưng không có training data hay code huấn luyện. Thứ hai, một phần của làn sóng này vẫn là lời hứa: weights của GLM-5.3 chưa lên mạng, Muse Spark 1.2 mới chỉ được tuyên bố.

Nhờ kiến trúc Sparse MoE (chỉ “bật” một phần nhỏ của model cho mỗi token thay vì cả bộ máy), các model nghìn tỷ tham số này chỉ kích hoạt 3 tới 5% tham số mỗi lần, nên chi phí chạy sập xuống theo. Năng lực gần bằng nhóm model mạnh nhất giờ là một thứ có thể tải về, không còn là đặc quyền của vài phòng lab. Và khi ai cũng host được model gần ngang GPT, giá chỉ có một hướng để đi trong dài hạn: đi xuống.

Phần 3: Các phòng lab đóng của Mỹ phản công bằng giá

Các phòng lab lớn nhìn thấy điều đó rõ hơn ai hết, và họ phản ứng bằng công cụ trực tiếp nhất: bảng giá.

OpenAI phát hành GPT-5.6 ngày 9/7 với ba tầng Sol, Terra, Luna. Chỉ ba tuần sau, họ giảm giá Luna tới 80%, xuống còn $0.20/$1.20, và Terra 20% [5]. Đây là giảm giá niêm yết, không phải khuyến mãi.

Trên OpenRouter thì còn khó tin hơn: tại thời điểm tôi viết bài, GPT-5.6 Sol đang giảm 50%, Gemini 3.7 Flash giảm 75%, một số model giảm tới 90% [6]. Và ngày 19/8, Stripe công bố mua lại OpenRouter, thương vụ được báo chí đưa khoảng 7,5 tỷ USD [7]. Một công ty thanh toán trả từng đó tiền cho một cái “router” định tuyến hơn 400 model từ hơn 80 nhà cung cấp. Với tôi, đó là sự xác nhận rằng chọn đúng model cho đúng tác vụ đã trở thành một tầng hạ tầng của phần mềm, giống như ngày xưa ta chọn database hay cloud provider.

Có một cái bẫy trong bức tranh màu hồng này: các chương trình giảm giá hiện tại không có nghĩa là rẻ vĩnh viễn ở mọi thời điểm. DeepSeek vừa tăng giá vì quá tải. Các mức giảm trên OpenRouter là khuyến mãi có thể rút bất cứ lúc nào. Gemini 3.7 Flash đang bán giá giới thiệu và sẽ tăng gấp đôi từ 1/1/2027 [14]. Giá từng hãng sẽ nhảy lên nhảy xuống, nhưng mặt bằng chung vẫn trượt xuống đều, vì luôn có model mới rẻ hơn xuất hiện. Tôi khá chắc đến cuối năm tôi đã dùng model khác rồi.

Điều đó dẫn tới hệ quả quan trọng:

Kỹ năng sống còn của người xây sản phẩm AI không phải là chọn được model tốt nhất hôm nay, mà là khả năng đổi model trong vài ngày khi thị trường thay đổi.

Phần 4: Bao nhiêu thông minh là đủ? Evals trả lời

Nếu bạn chỉ nhớ được một điều từ bài viết này, tôi mong là điều sau đây.

Tại Vietbooks, tôi có một hệ thống eval chấm điểm các chức năng AI phổ biến nhất: tra cứu quy định kế toán thuế, chọn đúng tool để lấy dữ liệu, phân tích báo cáo tài chính, tạo bút toán, đọc sao kê và chứng từ, trả lời đúng bằng tiếng Việt, và không bịa số liệu khi thiếu dữ liệu. Bộ eval không phủ được 100% những gì người dùng có thể hỏi, không hệ thống nào làm được. Nên mỗi ngày tôi đọc log các hội thoại thật: câu nào AI trả lời chưa đủ tốt, câu nào gọi sai tool, trường hợp đó được đưa ngược vào bộ eval. Lần nâng cấp model sau, chúng trở thành tiêu chí chấm điểm.

Nhờ vậy tôi trả lời được những câu hỏi kinh doanh rất cụ thể. DeepSeek Flash cho tôi khoảng 98% độ chính xác mà nghiệp vụ cần. Tôi đã thử DeepSeek Pro, và trên bộ eval của tôi, nó không cải thiện gì đáng kể, chỉ tốn thêm token và thêm tiền. Không có eval, tôi đã mặc định “đắt hơn thì tốt hơn” và đốt tiền suốt nhiều tháng. Có eval, tôi dám tặng người dùng Vietbooks năm tháng dùng AI miễn phí, không phải vì tôi hào phóng, mà vì tôi biết chính xác chi phí mỗi tác vụ và biết mình đổi được nhà cung cấp trong vài ngày nếu ai đó tăng giá.

Quay lại tin sáng nay. Trước giờ DeepSeek xử lý text rất tốt nhưng không có vision, nên toàn bộ phần đọc ảnh sao kê, hóa đơn scan, chứng từ chụp điện thoại của Vietbooks phải chạy qua Gemini Flash. Bây giờ V4 Flash Vision-Exp nhận cả hình ảnh, mỗi ảnh chỉ tính tối đa 384 token theo đơn giá Flash [1]. Làm phép tính nhanh cho vui: ngay cả với giá cao điểm, phần hình ảnh của một trang sao kê tốn khoảng 4 VND, gần như bằng không, chi phí thật nằm ở phần chữ mà model viết ra. Theo bảng benchmark DeepSeek tự công bố, model gần bằng Opus 4.8 trên các tác vụ agent có hình ảnh và vượt ở 3 trên 11 bài. Đây là số liệu của chính hãng và model vẫn mang nhãn Experimental, nên tôi xem nó là tín hiệu để kiểm tra, không phải bằng chứng để triển khai.

Việc của tôi chiều nay rất rõ ràng: chạy toàn bộ eval vision của Vietbooks. Nó có đọc đúng số tiền, ngày tháng, diễn giải hay không? Có xử lý tốt định dạng sao kê của từng ngân hàng Việt Nam không? Chi phí và độ trễ thực tế mỗi trang là bao nhiêu? Và một tiêu chí không nằm trong benchmark nào: sao kê là dữ liệu nhạy cảm, nên gửi qua provider nào, có đáp ứng quy định bảo vệ dữ liệu cá nhân không, cũng phải nằm trong quyết định. Nếu vượt qua, tôi thay model và tiết kiệm nhiều lần chi phí vision. Nếu không, Gemini tiếp tục làm nhiệm vụ. Quyết định này không dựa trên niềm tin vào bất kỳ hãng nào. Nó dựa trên eval.

Phần 5: Khi ai cũng viết được app, lợi thế nằm ở đâu?

AI đã kéo rào cản viết code xuống mức thấp nhất lịch sử. Hơn 660 PR trong 58 ngày của tôi là bằng chứng sống: hai người, với các agent chạy song song, làm được khối lượng việc của cả một team nhỏ ngày trước. Nhưng điều đó cũng có nghĩa là code không còn là lợi thế cạnh tranh. Nếu tôi xây được một app trong vài tuần bằng AI, đối thủ cũng vậy.

Với tôi, đó là một phần mềm kế toán Việt Nam đã chạy nhiều năm với hàng trăm người dùng. AI không thay thế lợi thế này. AI khuếch đại nó: mỗi model mới rẻ hơn, thông minh hơn xuất hiện là sản phẩm của tôi mạnh lên theo, gần như miễn phí.

Có một hình ảnh tôi muốn bạn giữ lại: nếu AI token là điện, thì model là CPU, còn sản phẩm của bạn là cả cỗ máy lắp quanh CPU đó. Tuổi thơ tôi gắn liền với hình ảnh máy tính nào cũng dán nhãn “Intel Inside”, nhưng thứ bạn mua về dùng là cả cỗ máy: màn hình, bàn phím, hệ điều hành, phần mềm. CPU tháo ra nâng cấp được mỗi năm, còn cỗ máy và dữ liệu của bạn thì ở lại. Với một AI app, cỗ máy đó gọi là harness: context đưa cho model đúng thông tin, bộ tool để nó làm được việc thật, memory để nó nhớ người dùng, và guardrails để nó không làm bậy. Tôi đã viết kỹ về các trụ cột này trong các bài trước:

• Bí quyết để Vibe Code AI Agent cho riêng bạn

• Bộ nhớ cho Agent: Trụ cột thứ 3 của Harness Engineering

• Điều kiện cần để đưa AI lên trang chủ phần mềm

Model đổi bao nhiêu lần thì harness vẫn là của bạn. Giá trị bạn tích lũy bằng chuyên môn của mình nằm ở đó, không nằm ở model.

Tháng này tôi được thấy tận mắt harness giữ giá trị thế nào.

Một bạn kế toán dùng Vietbooks trách con AI rằng bạn ấy đã sửa tay diễn giải một lần rồi, dạy từ hôm qua rồi, mà hôm nay nó vẫn quên, mệt quá. Rồi bạn ấy dạy lại quy tắc ngay trong chat: diễn giải bút toán nhập kho phải viết theo mẫu song ngữ Việt Anh kèm số hóa đơn mà công ty vẫn dùng. Quy tắc được lưu vào memory, và từ đó trở đi AI tự áp dụng cho mọi hóa đơn của công ty đó.

Một khách khác thì gửi nguyên bảng kê tháng trước và nhắn đại ý: học hết cách hạch toán trong này đi, tháng sau tôi gửi danh sách hóa đơn mới, cứ thế mà tạo bút toán tương tự. Người dùng thật không đọc paper về memory hay context. Họ chỉ muốn dạy một lần và phần mềm nhớ mãi, đúng như cách họ dạy một nhân viên mới. Những quy tắc đó không nằm trong model nào cả. Chúng nằm trong harness của Vietbooks, và ngày mai tôi đổi sang model rẻ hơn thì chúng vẫn còn nguyên.

Và cơ hội này không chỉ dành cho ngành phần mềm. Vài năm qua, lập trình viên là nhóm hưởng lợi sớm nhất từ AI. Giai đoạn tiếp theo, theo tôi, là đưa mức tăng năng suất đó đến những công việc khác: kế toán không phải nhập tay hàng trăm dòng sao kê, chủ doanh nghiệp không phải mở mười báo cáo để hiểu tình hình công ty, giáo viên không phải làm slide từ đầu.

Lời kết

Nếu tôi phải tóm lại hai tháng qua trong một câu: trí tuệ đang trở thành một thứ thiết yếu, rẻ và sẵn có như điện, như nước, và lợi thế thuộc về người biết biến nguồn trí tuệ giá rẻ đó thành công việc hữu ích cho người khác.

Model sẽ tiếp tục thông minh hơn. Giá sẽ tiếp tục trượt xuống, dù từng hãng có lúc tăng. Model tốt nhất hôm nay gần như chắc chắn bị thay trước cuối năm. Nhưng hệ thống eval, dữ liệu, quy trình và niềm tin của người dùng thì ở lại với bạn.

Còn bạn thì sao? Trong công việc hằng ngày của bạn, có tác vụ lặp đi lặp lại nào mà bạn nghĩ AI “đủ thông minh” để gánh giúp chưa? Tôi rất mong được đọc câu trả lời của các bạn bên dưới.

References

[1] DeepSeek công bố V4-Flash-Vision-Exp, 21/8/2026. https://api-docs.deepseek.com/news/news260821/

[2] Bài đăng của Jay (OpenCode) về lưu lượng DeepSeek V4 Flash.

[3] InfoWorld: DeepSeek tăng giá API V4, 16/8/2026. https://www.infoworld.com/article/4209439/deepseek-raises-some-v4-prices-by-more-than-10x-as-ai-demand-strains-capacity.html

[4] Chi tiết khung giờ cao điểm, thấp điểm của DeepSeek. https://www.aipricing.guru/news/deepseek-api-pricing-update-peak-off-peak-august-2026/

[5] OpenAI giảm giá GPT-5.6: Luna 80%, Terra 20%, 30/7/2026. https://www.edenai.co/post/openai-cuts-gpt-5-6-api-prices-luna-falls-80-terra-20-sol-holds

[6] Danh sách model đang giảm giá trên OpenRouter, kiểm tra 21/8/2026. https://openrouter.ai/collections/discounted-models

[7] Stripe công bố mua lại OpenRouter, 19/8/2026. https://stripe.com/newsroom/news/stripe-agrees-to-acquire-openrouter

[8] Tom’s Hardware: Moonshot mở weights Kimi K3 (2.8T MoE). https://www.tomshardware.com/tech-industry/artificial-intelligence/moonshot-ai-releases-weights-for-kimi-k3-firing-a-shot-across-the-bow-of-openai-and-anthropic-open-weight-model-performs-almost-as-well-as-frontier-models-while-being-2-3x-easier-to-run

[9] Qwen3.8-2.4T-A95B trên Hugging Face. https://huggingface.co/Qwen/Qwen3.8-2.4T-A95B

[10] Zhipu phát hành GLM-5.3, weights hẹn cuối tháng 8. https://mlq.ai/news/zhipu-releases-glm-53-through-its-coding-service-with-weights-still-two-weeks-away/

[11] CNBC: Meta ship Muse Glimmer 30B open weights. https://www.cnbc.com/2026/08/10/meta-muse-glimmer-open-weight-ai.html

[12] Muse Spark 1.2 trên Artificial Analysis. https://artificialanalysis.ai/models/muse-spark-1-2

[13] MiniMax M3 trên Artificial Analysis. https://artificialanalysis.ai/articles/minimax-m3

[14] Gemini 3.7 Flash: giá giới thiệu và lộ trình tăng giá 1/1/2027. https://memeburn.com/gemini-3-7-flash-review-pricing-benchmarks-2026/

Dự án mới nhất của tôi là tạo một AI agent có thể làm PowerPoint slides chất lượng cao. Cũng gần xong rồi, đang trong giai đoạn kiểm tra chất lượng. Đầu tuần này tôi dùng Claude Opus 4.8 với Ultracode effort để tìm và sửa lỗi khi render slides từ markdown. Với Ultracode effort, Claude tự tạo subagent để render song song hàng trăm slide decks, tạo từ 13 slide templates của tôi, rồi tự tìm lỗi, tự kiểm tra chéo, phản biện, xác nhận, và cuối cùng tự sửa.

Tôi cho Claude tự chạy rồi đi đánh pickleball. Khi quay về thì Claude đã tự tìm ra 26 lỗi, tự loại 14 và xác nhận 12 lỗi thật, rồi tự sửa hết. Cùng một khối lượng công việc như vậy, chỉ mới tháng trước thôi, có thể tôi phải làm mất mấy ngày.

Gần đây, Boris Cherny, cha đẻ của Claude Code, cũng chia sẻ rằng ban ngày lúc nào ông cũng có hàng trăm agents làm việc liên tục, còn ban đêm thì có thể lên đến cả ngàn [1]. Các agents này được thiết kế để tự động chạy (thông qua /loop, tương tự như cron jobs): dọn dẹp, tối ưu hóa code base, tự kiểm tra PR, hay tự tìm hiểu project để tạo feature mới, v.v… Peter Steinberger cũng chia sẻ trên X rằng [2]:

You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.

Theo tôi, đây là thay đổi thật sự trong ngành. Không phải hype. Và nếu tận dụng được kỹ thuật làm việc với AI mới này thì việc tăng 10x năng suất là nằm trong tầm tay.

AI ngày nay phát triển quá nhanh, và tôi cũng chỉ mới bắt đầu áp dụng kỹ thuật này vào công việc gần đây. Trong bài viết này, tôi sẽ chia sẻ kinh nghiệm, cách suy nghĩ và làm việc của mình qua 2 dự án thật.

Câu chuyện thứ nhất: Loop với điểm dừng cố định

Gần đây tôi làm một proposal cho một khách hàng muốn áp dụng AI để cải thiện cách vận hành doanh nghiệp. Họ cần một hệ thống tự nghe, hiểu, và ghi biên bản họp tiếng Việt, đồng thời nhận ra trong cuộc họp ai được giao việc gì và deadline lúc nào, để theo dõi tới khi xong.

Trước khi viết proposal và báo giá, tôi xác định ngay từ đầu yếu tố rủi ro cao nhất của dự án chính là: liệu AI có nhận biết được tiếng Việt và nhân diện được người nói hay không. Cụ thể là dùng model nào, độ chính xác ra sao khi mỗi người có một giọng riêng. Nếu nhận dự án mà ngay cả AI tốt nhất cũng nghe tiếng Việt không tốt, thì sản phẩm làm ra sẽ “ngô nghê” đúng như công ty này đã trải nghiệm với các giải pháp hiện có.

Thế nên bước đầu tiên là nhờ công ty gửi vài bản ghi cuộc họp. Họ gửi tôi 2 bản ghi: 1 cuộc online qua Microsoft Teams, 1 cuộc offline thu âm qua microphone chất lượng tốt. Với 2 bản ghi này, tôi đã kiểm tra được độ chính xác của các model mới nhất ở khả năng transcribe (audio thành text) và diarize (ai nói lúc nào). Với model Gemini 3.5 Flash, tôi đạt được độ chính xác trên 95%. Tuy nhiên đây chỉ là 2 điểm dữ liệu riêng lẻ, khó tổng quát hóa, và tôi cũng chưa test được khả năng nhận diện người nói (ai là ai). Vậy làm sao tôi đủ tự tin viết proposal khi điểm rủi ro cao nhất chưa được giải quyết?

Đây là lúc tôi tận dụng kiến thức và kinh nghiệm của mình với các model tạo giọng nói (text-to-speech) của Google. Tôi tạo một workflow để emulate toàn bộ quy trình:

• Tạo bản ghi gốc, original meeting transcript (gồm bao nhiêu người, ai nói gì, lúc nào).

• Tách transcript thành nhiều đoạn nhỏ, mỗi đoạn một người nói.

• Dùng text-to-speech tạo từng đoạn thành audio. Mỗi người trong meeting được gắn cố định một nhân vật (mỗi người một giọng riêng).

• Nối các file audio lại thành 1 meeting hoàn chỉnh.

• Đăng ký giọng cho từng nhân vật: mỗi nhân vật đọc một câu thoại 30 giây đơn giản, để hỗ trợ nhận dạng người nói.

Sau các bước này, tôi đã có dữ liệu gốc, ground truth (original transcript), có file audio meeting, và có cả cơ sở dữ liệu giọng nói đã được gán nhãn. Giờ tôi có thể đi ngược lại: lấy file audio meeting, dùng Gemini 3.5 Flash để tạo transcript và diarize, dùng Pyannote Precision 2 để gán nhãn người nói, rồi so sánh với ground truth để tính độ chính xác.

Để có kết quả tổng quan tốt, tôi cần tính trên nhiều meeting (nhiều điểm dữ liệu), mỗi meeting có số lượng người tham gia khác nhau (từ 2 tới 7 người). Và đây chính là lúc workflow và parallelism tỏa sáng. Khi đã thiết kế xong workflow hoàn chỉnh, tôi dùng Ultracode effort của Claude để chạy song song nhiều workflow (mỗi cái một bộ params khác nhau), hoàn toàn tự động, rồi tổng hợp kết quả lại.

Cuối cùng, chỉ trong vài tiếng, tôi có độ chính xác cho 13 lượt chạy, từ 2 tới 7 người (riêng nhóm 7 người tôi chạy 3 lần để đo độ dao động). Tôi phát hiện với Gemini 3.5 Flash, khi meeting có 6-7 người thì độ chính xác nhận diện người nói rớt từ trên 95% xuống còn khoảng 80%. Chính con số này giúp tôi tự tin hơn khi viết proposal: điểm rủi ro lớn nhất đã được đánh giá khách quan, trên dữ liệu tiếng Việt mà không model nào công bố. (Dĩ nhiên đây là dữ liệu emulate, nên bước tiếp theo rõ ràng là đánh giá lại trên nhiều meeting audio thật.)

Có vài điểm thú vị ở đây:

1. Workflow trên có nhiều bước mà bản thân chúng cũng cần AI mới làm được: tạo các meeting transcript khác nhau, tạo audio, rồi nhận dạng và transcribe ngược lại audio.

2. Workflow được thiết kế đủ hoàn chỉnh để một AI điều phối và chạy: AI chạy workflow này sẽ gọi các AI kia làm từng phần.

3. Mỗi lần chạy, workflow được một AI chính quản lý, và có thể chạy song song nhiều meeting cùng lúc. Thực tế tôi để khoảng 4 meeting chạy cùng lúc. Đây là trải nghiệm Loop đầu tiên của tôi, với điểm dừng cụ thể: chạy hết 13 meeting.

Và kinh nghiệm của tôi ở đây là chạy thủ công một lượt hoàn chỉnh trước (smoke check run); sau khi xác nhận chạy thành công và context của session đã đủ thông tin, thì chỉ cần bảo Claude chạy workflow là xong.

Câu chuyện thứ hai: Loop với điểm dừng không cố định, LLM as a judge

Như đã chia sẻ ở trên, hiện giờ tôi đang hoàn thiện một AI agent làm PowerPoint slides chất lượng cao. Đây là feature được nhiều khách của Heavy3 yêu cầu, trong đó có một cô bạn thân của tôi từ thời trung học. Cô là bác sĩ chuyên khoa xương khớp, ngoài làm ở bệnh viện còn nghiên cứu khoa học và giảng dạy đại học. Cô dùng Heavy3 để nghiên cứu sâu rồi tạo slides nội dung chất lượng cao, phục vụ giảng dạy và trình bày khoa học. Trước đây, sau khi có content cô dùng NotebookLM để tạo PowerPoint slides. Bất cập của NotebookLM là slides tuy nhìn đẹp, chỉn chu, nhưng mỗi slide lại là một tấm hình, nhiều lúc hình có lỗi chính tả rất khó sửa, mà nội dung không vừa ý muốn chỉnh cũng nhọc nhằn.

Tôi nghĩ đây là một feature rất thiết thực và mình có thể làm tốt. Đây cũng là dịp để tôi thử nghiệm kỹ thuật Loop thứ 2: self-improvement loop với một LLM chấm điểm. Chức năng này gồm workflow như sau:

• Dùng một hội đồng AI của Heavy3 để tạo nội dung slide (dạng markdown text).

• Dùng một LLM đọc markdown, gọi tool để tạo từng slide, tạo cùng lúc ở 2 định dạng html/css và PowerPoint. Tôi khuyến khích LLM dùng chart, quote, stats, và đặc biệt là tạo hình (text-to-image) để slide đẹp, trình bày tốt và phong phú.

• Cho một LLM khác review lại tất cả các slide, kiểm tra lỗi render, font, v.v… để chỉnh sửa. Chính LLM này cũng giúp người dùng có thể chat để chỉnh sửa slide.

Để bảo đảm chất lượng slide cho các đề tài thông dụng, tôi tạo 13 template khác nhau, mỗi template có 14 prompt. Quy trình hoàn thiện chức năng là: tạo slide deck cho từng cặp prompt-template (tức 14 x 13 = 182 deck), rồi yêu cầu Claude so sánh bản previewView (html/css) với bản render pptx->pdf để đảm bảo hai bên khớp nhau (parity) và slide đạt chất lượng cao. previewView là cần thiết để hỗ trợ hiển thị online, giúp user chỉnh sửa slide chính xác ngay lập tức (ngoài việc user cũng có thể chat để sửa). Đây là một loop hoàn toàn tự động hóa được, và tôi đã dùng Ultracode effort của Claude để tự chạy nó với 7 subagent song song.

Điểm thú vị là ở đây có 2 vòng lặp lồng nhau:

• Vòng lặp nhỏ: LLM có vision kiểm tra chất lượng từng slide để cải thiện.

• Vòng lặp lớn: tôi yêu cầu Claude tự thực hiện vòng lặp tự cải thiện (self-improvement loop), không tạo hết 182 deck một lúc mà làm từng deck, còn lỗi hay còn cải thiện được thì làm tiếp.

Trên thực tế, Claude tự quyết định chỉ chạy khoảng 7 trên 14 prompt cho mỗi template rồi dừng, vì nhận ra slide đã đạt chất lượng cao và hết lỗi (diminishing return). Vòng lặp này đã tự phát hiện và sửa hơn 50 lỗi, chất lượng slide cuối cùng đạt mức cao.

Điểm khác biệt so với câu chuyện thứ nhất là tôi áp dụng LLM as a judge vào cả 2 self-improvement loops:

• Ở vòng lặp nhỏ: ban đầu tôi thử từ 1-3 lần, sau tôi chốt ở 1 lần đảm bảo cân bằng giữa thời gian tạo deck và chất lượng

• Ở vòng lặp lớn: Claude dừng sớm ở khoảng 7/14 sau khi xác định không còn cải thiện đáng kể và không còn bug

Bộ slides minh họa cho chính bài viết này được tạo bằng đúng chức năng đó [3].

Trong cả hai câu chuyện, tôi đã làm việc với AI bằng một tư duy mới:

Nói vui, tôi đã làm việc với tư duy “làm biếng nhất có thể”, để AI tự chạy càng nhiều càng tốt.

Lời kết

Với tốc độ phát triển chóng mặt của AI thì đa số chúng ta đều là kẻ tập sự. Tôi đang cố gắng học hỏi và áp dụng các kỹ thuật mới nhất để giải phóng sức lao động của mình. Hy vọng kinh nghiệm của tôi có thể giúp bạn trong công việc.

Thay lời cuối, tôi hay nghĩ tới câu chia sẻ bình dị nhưng đầy nội lực của Boris Cherny [1]:

I usually have like maybe like 5 to 10 sessions. And then the sessions usually have a bunch of agents. So I think currently probably like a few hundred agents going. And, usually every night I have like a few thousand that are doing kind of deeper work.

Và tôi ước có lượng tokens khổng lồ như Boris để cũng có được cả ngàn agent giúp việc mỗi ngày.

References

[1] Anthropic’s Boris Cherny: Why Coding Is Solved, and What Comes Next
[2] Peter Steinberger Reminder About Loop
[3] Maximizing Productivity via Autonomous AI Agent Loops, Anh Le

“AI bây giờ chỉ là trào lưu thôi, chắc gì đã giúp ích được vào công việc thực tế.”

Đây thực sự là một đánh giá chủ quan nhưng đáng để phân tích.

Mình thì có niềm tin sâu sắc là sẽ không lâu nữa AI sẽ nâng cao năng suất của rất nhiều ngành nghề. Việc này sẽ thông qua việc tích hợp các công cụ AI vào công việc của các ngành nghề đó.

Với góc nhìn của một lập trình viên tự tay phát triển hệ thống, mình đang chứng kiến việc này ngay trong lĩnh vực kế toán, ngay trong 2 câu chuyện dưới đây.

AI đọc sao kê ngân hàng

Câu chuyện thứ nhất là từ chị làm kế toán của một công ty cỡ vừa, đã gắn bó với tụi mình nhiều năm. Chị ấy mong muốn hệ thống có thể tự động đọc file sao kê ngân hàng và ghi chép lại mọi thứ. Ngày trước, việc này gần như bất khả thi, mỗi ngân hàng có 1 định dạng sao kê khác nhau. Cũng có giải pháp là phải đi liên hệ kết nối số với từng ngân hàng, nhưng đây thật sự là rào cản lớn cho một công ty phần mềm nhỏ.

Nhưng hiện tại, như các bạn có thể thấy trong video, AI có thể tự động đọc và tạo hơn 300 bút toán từ sao kê chỉ trong nháy mắt. Mọi thứ được nhận diện và phân loại tự động, chị khách chỉ cần lướt qua kiểm tra và bấm duyệt. Hàng giờ đồng hồ căng mắt làm việc thủ công đã được giải quyết gọn gàng.

Tải hóa đơn từ Tổng Cục Thuế

Câu chuyện thứ hai thì có hơi khác. AI không nằm trong sản phẩm cuối, nhưng AI đã giúp mình xử lý một bài toán khó.

Một công ty dịch vụ kế toán đang dùng hệ thống của bên mình từng phải trả khoảng 500 đồng cho mỗi lần tải một hóa đơn từ Tổng cục Thuế. (Chi phí có thể lên tới nhiều triệu đồng/tháng cho một công ty cỡ vừa có vài trăm hóa đơn một tháng.) Sau khi tải xong, họ lại phải tự chuyển đổi định dạng và nhập thủ công vào phần mềm rất tốn thời gian.

Hiện tại Tổng cục Thuế chưa có cổng kết nối (API) chính thức, nhưng nhờ AI, hệ thống của mình đã kết nối được và có thể thích ứng cực nhanh với các định dạng dữ liệu. Kết quả là toàn bộ quá trình tải hóa đơn và ghi nhận giao dịch đã được tự động hóa 100%. Không chỉ tiết kiệm tiền bạc mà còn giải phóng vô số giờ làm việc mệt nhọc cho khách hàng.

Agent với giá trị thật

Trong mấy tháng vừa qua, mình có viết chuỗi bài về Harness Engineering: Context, Tools, Memory, Guardrails. Bốn trụ cột để biến LLM thành công cụ làm việc thật, đúc kết từ kinh nghiệm thực chiến của mình khi xây Vietbooks Agentic.

Hôm nay, mình rất vui vì sản phẩm đã ra mắt và chạy ổn định. Quan trọng nhất là nó đã và đang đem lại giá trị cho người dùng. Mình sẽ còn nhiều cải tiến cho Agent, sẽ còn nhiều nâng cấp sắp tới. Nhưng đây có lẽ là một khoảnh khắc mình rất tự hào và muốn chia sẻ với các bạn. Một chặng đường lớn đã hoàn thành!

Mời các bạn xem video ngắn để thấy hệ thống chạy thật.

Phần 1. Tin nhắn lúc 7 giờ sáng

Tuần đầu sau khi Vietbooks ra mắt thử trợ lý AI, tôi nhận được tin nhắn từ một khách hàng vào lúc 7 giờ sáng:

“Em ơi, tại sao tổng tài sản công ty chị là 150 tỷ theo bảng cân đối kế toán, mà AI lại bảo chị là 134 tỷ?”

Tôi đọc xong, tỉnh ngủ luôn.

Suy nghĩ đầu tiên trong đầu là tình huống tệ nhất: AI của mình vừa bịa ra?

Khách hàng đang dùng phần mềm kế toán để chốt số liệu, và AI báo sai 16 tỷ. Đây không phải sai số làm tròn. Đây là loại sai số có thể làm khách hàng mất niềm tin mãi mãi.

Sự kiện này cho tôi bài học sâu sắc nhất từ trước đến nay về việc xây dựng AI cho phần mềm doanh nghiệp. Và bài học đó cho phép tôi làm một việc mà ba tuần trước tôi không dám nghĩ tới: đưa trợ lý AI lên làm trang chủ của Vietbooks.

Bài viết này là phần thứ tư trong chuỗi bài về Harness Engineering (kỹ thuật cầm cương AI agent) mà tôi đang viết. Ba bài trước đi qua Context, Tools, Memory. Bài này đóng lại trụ cột cuối: Guardrails.

Phần 2. Ra mắt thử: tín hiệu tốt, rồi tin nhắn lúc 7 giờ sáng

Tháng trước, tôi thêm trợ lý AI vào Vietbooks trên một sidebar bên hông phần mềm. Không quảng cáo rầm rộ. Không hứa hẹn gì lớn. Giống cách Cursor đặt AI vào IDE của họ trong những phiên bản đầu tiên: nhỏ, lặng lẽ, để người dùng tự khám phá.

Vài ngày sau khi ra mắt, tôi mở trang thống kê sử dụng và thấy có người dùng. Không nhiều, nhưng đủ. Và quan trọng hơn, không phải họ hỏi những câu xã giao kiểu “AI này làm được gì?”. Họ hỏi những câu hỏi thật:

“Công ty bán lại vật tư thừa sau khi đã hoàn thành công trình hạch toán thế nào?”

“Tôi bán thành phẩm theo lô, cần gán hàng hóa cho hóa đơn đầu ra thì làm sao?”

“Tài khoản 7111 thu nhập được bồi thường hạch toán theo Thông tư 99 ra sao?”

Đây là loại câu hỏi mà một bạn kế toán viên có thể hỏi một kế toán trưởng kinh nghiệm. Không phải tò mò. Là công việc thật.

Tôi nhìn vào trang thống kê và cảm thấy nhẹ nhõm. AI đang giúp khách hàng thật. Mục tiêu của giai đoạn ra mắt thử đã đạt được: xác nhận có người dùng, có giá trị tạo ra.

Rồi hôm sau, tôi nhận tin nhắn AI trả số liệu sai lúc 7 giờ sáng.

Phần 3. Guardrail thứ nhất: đúng công cụ cho đúng công việc

Việc đầu tiên tôi làm là mở chat của khách hàng và xem AI đã trả lời như thế nào.

AI có lý do cho con số 134 tỷ. Nó đã gọi tool get_account_balance cho một số tài khoản, cộng lại, và trả về. Logic của AI hợp lý. Vấn đề không nằm ở AI.

Vấn đề là để ra được con số “Tổng tài sản” đúng như trong Bảng Cân đối Kế toán, thì không phải chỉ đơn giản cộng các số dư tài khoản. Phải phân loại tài sản theo nhóm, phải áp dụng các quy tắc kết chuyển, phải xử lý các tài khoản đối ứng. Logic này nằm trong code của báo cáo mà AI không truy cập được.

Nói cách khác: AI đã làm hết sức với những gì nó có. Và cái nó có chỉ là một cái búa nhỏ, mà tôi đang yêu cầu nó dựng một ngôi nhà.

Đây là sai lầm cốt lõi của phiên bản trợ lý AI đầu tiên: tôi cho AI những tool ở mức thấp, nghĩ rằng nó sẽ tự ghép chúng lại thành kết quả đúng. Nhưng kết quả đúng đòi hỏi logic nghiệp vụ, mà logic nghiệp vụ chỉ tồn tại trong code báo cáo của tôi.

Bài học thứ nhất: đúng công cụ cho đúng công việc.

Cách tôi xử lý: tôi chuyển toàn bộ logic của các báo cáo quan trọng ra thành tool dùng chung. Khi giao diện phần mềm muốn hiển thị Bảng Cân đối, nó gọi compute_balance_sheet. Khi AI muốn trả lời câu hỏi về tổng tài sản, nó cũng gọi cùng tool đó.

Cùng một nguồn dữ liệu.
Cùng một logic.
Cùng một câu trả lời.

Việc này rất tốn công và rủi ro, vì tôi đang chuyển những dòng code đã ổn định gần 10 năm từ frontend ra một thư viện dùng chung cho backend. Tôi mất gần một tuần để chuyển và kiểm tra kỹ: Báo cáo Kết quả Kinh doanh, Bảng Cân đối Kế toán, Lưu chuyển Tiền tệ, các báo cáo công nợ, và các báo cáo phân tích.

Nhưng kết quả rất đáng công sức: AI giờ trả lời số liệu khớp 100% với báo cáo. Không thể khác được, vì hai cái dùng cùng code.

Một tuần sau, cùng khách hàng đó hỏi câu khác:

“Theo tình hình kinh doanh của mình hiện nay, mình nên chú trọng điều gì?”

AI gọi nhiều tool khác nhau: KQKD, Bảng Cân đối, Công nợ, sản phẩm bán chạy, Lưu chuyển tiền tệ. Sau đó nó chạy một đoạn code phân tích trong sandbox và đưa ra một phân tích sâu năm vấn đề, có thứ tự ưu tiên hành động. Số liệu khớp với báo cáo trong phần mềm.

Phần 4. Guardrail thứ hai: kiểm tra tính hợp lệ nên là vòng phản hồi, không phải bức tường

Bài học thứ hai đến từ một tình huống tinh tế hơn.

Khi thử nghiệm trợ lý AI tạo bút toán, nó tạo bản nháp đẹp trên giao diện. Tôi bấm “Phê duyệt”, và phần mềm báo lỗi validation: tài khoản thiếu đối tượng. (Ví dụ như tài khoản 131: Phải thu của khách hàng thì phải có mã khách hàng.)

Phản xạ đầu tiên là tôi quay lại tìm cách để sửa AI để tạo đúng hơn. Nhưng AI sẽ luôn có lúc tạo sai khi nghiệp vụ phức tạp. Cách xử lý đúng ở đây không phải là làm AI hoàn hảo. Là làm sao AI tự sửa được khi sai.

Do vậy, tôi đã đưa logic kiểm tra tính hợp lệ của bút toán (validation function) vào trong vòng lặp gọi tool của AI.

Khi AI gọi create_draft_entry, tool thực hiện validation ngay. Nếu lỗi, tool trả về thông báo rõ ràng cho AI, ví dụ:

“Lỗi khi kiểm tra tính hợp lệ: Tài khoản 6422 đang được dùng làm bên Có. Theo Thông tư 133, tài khoản này chỉ dùng bên Nợ. Hãy đổi sang một tài khoản phù hợp ở vế Có, ví dụ 1111 nếu chi tiền mặt.”

AI nhận lỗi, hiểu, tạo lại bút toán đúng. Tất cả xảy ra trong cùng một lần hỏi. Người dùng không thấy lỗi, chỉ thấy bút toán cuối cùng đúng.

Nhiều người thiết kế AI nghĩ guardrail là bộ lọc cuối cùng: AI tạo ra cái gì đó, mình kiểm tra, nếu sai thì chặn lại. Cách đó lãng phí công sức của AI và làm trải nghiệm của người dùng tệ.

Theo tôi, cách đúng hơn là nên đặt kiểm tra hợp lệ vào trong tool, để AI tự nhận lỗi và tự sửa. Code kiểm tra hợp lệ đó vốn đã có sẵn trong phần mềm của bạn. Việc của bạn chỉ là đưa nó ra như một tín hiệu phản hồi trong vòng thực thi tool.

AI thực ra thông minh hơn ta nghĩ. Nó tự sửa được nếu được nói rõ cái gì sai và tại sao.

Phần 5. Bước ngoặt: từ sidebar lên trang chủ

Sau hai bài học trên, tôi nhìn lại trợ lý AI và nhận ra một điều: AI đã đủ tốt để không còn là một tính năng phụ đặt bên hông nữa.

Cursor 2023: AI là sidebar nhỏ trong editor. Cursor 2.0 cuối 2025: Agents View thành trung tâm mặc định. Bạn không còn “code trong editor có AI”, bạn “lập trình cùng AI”.

Khác biệt lớn nằm ở tâm lý.

Tôi nhìn Vietbooks và tự hỏi: nếu khách hàng vào phần mềm và thấy AI trên cùng, thay vì menu rườm rà, họ có thích hơn không?

Câu trả lời tự nhiên là có. Nhưng để làm được, AI phải đủ năng lực để gánh vai trò trang chủ: đủ chính xác để khách hàng tin, và đủ chức năng để người dùng thật sự làm được việc.

Sidebar có thể yếu một chút mà phần mềm vẫn dùng được. Trang chủ thì không.

Hai guardrails bên trên là điều kiện cần để tôi dám làm bước này. Khi tôi đã chắc rằng AI trả lời số liệu đúng qua tool dùng chung với báo cáo, và rằng nó tạo bút toán đúng cuối cùng qua vòng kiểm tra hợp lệ, tôi mới đủ tự tin đẩy AI lên trang đầu.

Và tôi đã làm ngay.

Trang chủ của Vietbooks bây giờ là chat với trợ lý AI. AI được trang bị các chức năng chính:

• Tra cứu luật kế toán, Thông tư, cách hạch toán từng nghiệp vụ

• Tạo bút toán từ mô tả tự nhiên đến bản nháp ghi sổ, kèm guardrail kiểm tra hợp lệ

• Phân tích kinh doanh từ báo cáo, công nợ, sản phẩm bán chạy, đề xuất hành động

• Chuyển dữ liệu từ file Excel của phần mềm cũ vào cấu trúc của Vietbooks

Cái chuyển dữ liệu đặc biệt thú vị. Khách hàng đến từ phần mềm kế toán khác như MISA, FAST, hoặc Excel tự dựng, không cần lo về định dạng. Họ kéo file vào chat, AI đọc, hỏi lại vài câu để xác nhận, rồi tự chuyển dữ liệu vào Vietbooks. Đây là một chức năng rất phức tạp nếu không dùng AI để chuyển đổi.

Giờ thì tiếp nhận khách hàng mới đột nhiên dễ hơn rất nhiều.

Phần 6. Sự thật: trợ lý AI hiện tại vẫn còn nhiều điểm yếu

Tôi muốn nói thẳng phần này vì sẽ không thật nếu bỏ qua.

Đưa AI lên trang chủ không có nghĩa là AI đã hoàn hảo. Nó chỉ có nghĩa là AI đã đủ tốt để trở thành điểm bắt đầu của phần mềm, và những điểm yếu còn lại có thể được kiểm soát bằng hệ thống guardrails phía sau.

Thứ nhất, trợ lý AI của Vietbooks có một router agent ở tầng đầu, nhiệm vụ là phân loại câu hỏi của người dùng và gửi đến agent con phù hợp: phân tích báo cáo, tạo bút toán, tra cứu nhanh, chuyển dữ liệu.

Khi nhìn vào log, tôi vẫn thấy có những trường hợp router gửi sai. Ví dụ tuần trước: khách hàng hỏi “Tháng 5 mình nên cắt giảm chi phí gì?” Router thấy cụm “cắt giảm chi phí”, gửi đến entry agent. Entry agent ngơ ngác vì không có bút toán cụ thể nào để tạo, trả về một câu hỏi lại cho khách hàng. Khách hàng phải làm rõ lần nữa, và đó là khoảnh khắc trải nghiệm tệ.

Có một đánh đổi rõ ràng ở đây: nếu router agent cẩn thận hơn, nó sẽ chính xác hơn nhưng chậm hơn. Người dùng gõ câu hỏi và muốn câu trả lời ngay. Mỗi giây chậm đều làm trải nghiệm tệ đi.

Tôi đang điều chỉnh cân đối giữa hai chiều này dựa trên cách dùng thật của khách hàng. Có lúc tôi giảm tốc để tăng độ chính xác. Có lúc tôi tăng tốc và chấp nhận một tỷ lệ phân loại sai nhất định.

Cách tôi đang thử là tinh chỉnh prompt và mô tả tool của router theo dữ liệu thật, đồng thời cho người dùng lựa chọn agent cụ thể khi cần. Trong tương lai gần, khi LLM mới cho phép router thông minh hơn với cùng độ trễ, vấn đề này có thể tự được giải quyết.

Thứ hai, bản chất của LLM là có xác suất sai. Cho nên một guardrail nữa tôi đang xây là bộ phát hiện lỗi của AI. Nếu tin nhắn kế tiếp của khách hàng bắt đầu bằng “không phải vậy”, “sai rồi”, hoặc “ý mình là”, hệ thống tự gắn nhãn câu trả lời trước là sai. Sau đó tôi xem lại từng trường hợp. Nếu một loại câu hỏi bị đánh dấu quá ngưỡng trong tuần, tôi biết phải tinh chỉnh prompt hoặc tool ngay.

Nhìn lại tin nhắn 7 giờ sáng ở đầu bài này, đó cũng là một lỗi rõ ràng của AI, chỉ là khách hàng chọn gửi tin nhắn vào Zalo thay vì gõ tiếp trong AI chat. Bộ phát hiện lỗi này là cách để bạn xác định được điểm yếu của AI để cải thiện.

Trong bảng tin thông báo về chức năng Trợ lý AI, tôi thẳng thắn thừa nhận AI vẫn còn nhiều chỗ yếu. (Nhưng tôi có niềm tin sắc bén là nó đang mạnh hơn từng ngày.) Đây là sự khiêm tốn thật của một người làm AI: bạn phát hành phiên bản tốt nhất bạn có hôm nay, đồng thời thừa nhận nó còn nhiều việc phải làm. Khách hàng cảm nhận được sự thật này và họ tin tưởng hơn.

Phần 7. Lời khuyên cho người đang xây sản phẩm AI

Nếu bạn đang xây hoặc đang nghĩ về việc đưa AI vào sản phẩm của mình, đây là những gì tôi rút ra sau 1 tháng ra mắt AI agent cho Vietbooks.

Một, đừng đợi LLM hoàn hảo. Xây harness từ hôm nay.

Context, tool, memory, guardrail. Mỗi trụ cột là một dự án độc lập. Càng làm sớm, sản phẩm của bạn càng tự tốt lên khi LLM tiếp theo ra mắt.

Hai, nguồn dữ liệu duy nhất cho mọi số liệu.

Cùng một logic phục vụ cả giao diện và AI. Nếu giao diện hiển thị X và AI nói Y, bạn đang chuẩn bị nhận một tin nhắn lúc 7 giờ sáng.

Ba, kiểm tra tính hợp lệ là vòng phản hồi, không phải bức tường.

Đặt kiểm tra tính hợp lệ vào trong vòng thực thi tool. Khi AI tạo ra sai, cho nó biết chính xác sai gì và tại sao. Nó tự sửa được.

Bốn, dùng nhiều agent chuyên biệt, không phải một agent khổng lồ.

Mỗi agent có ngữ cảnh riêng, tool riêng, system prompt riêng. Cửa sổ ngữ cảnh có hạn, sự tập trung có hạn. Chia nhỏ là cách tốt nhất để giữ chất lượng từng tương tác.

Năm, bộ nhớ là cách phần mềm của bạn ngừng là công cụ và trở thành đồng nghiệp.

AI gọi khách hàng bằng tên. Nhớ quy trình. Nhớ những lần họ đã sửa. Đó không phải tính năng. Đó là quan hệ.

Bốn trụ cột Harness Engineering, tổng hợp lại trong một câu:

Phần 8. Câu hỏi cuối

Nếu bạn là người đang xây phần mềm, câu hỏi tôi muốn để lại là:

Điều gì đang cản bạn đưa AI thành trang chủ của sản phẩm bạn?

Bạn sợ một tin nhắn 7 giờ sáng? Phần 3 và 4 là cách để bạn không phải sợ nữa.

Khách hàng chưa sẵn sàng? Ra mắt thử như tôi: đặt AI vào sidebar trước, xem có ai dùng không và dùng ra sao.

Kỹ thuật quá khó? Bốn trụ cột harness có thể làm dần. Mỗi trụ cột tự nó đã là một bước tiến lớn.

Năm 2026, đưa AI vào sản phẩm thật không còn là chuyện khó kỹ thuật. Khó là ở việc xây harness đúng quanh AI, để khách hàng nhận được giá trị thật, không phải sự hào nhoáng. Và harness là điều kiện cần, không phải điều kiện đủ. Theo tôi, điều kiện đủ sẽ không bao giờ hoàn tất; nó tích lũy mỗi tuần, theo nhịp bạn tinh chỉnh harness và theo nhịp LLM thế hệ tiếp theo ra mắt: tool sâu hơn, memory chính xác hơn, hay agent chuyên biệt hơn.

Tin tốt là bạn không phải đợi có điều kiện đủ để bắt đầu. Hiểu rõ điều kiện cần là đã có thể bắt tay vào làm ngay.

Mỗi sản phẩm AI thật sự đều có một tin nhắn 7 giờ sáng đang đợi. Bạn đã xây harness để trị nó chưa?

Bài viết này là Phần 4 trong chuỗi Harness Engineering.

Các phần liên quan:

• Bộ nhớ cho Agent: Trụ cột thứ 3 của Harness Engineering (Phần 3)

• Bí quyết để Vibe Code AI Agent cho riêng bạn (Phần 1 và 2)

Mùa này ở Hội An đang là mùa vắng khách. Trời nắng nóng, đường phố cổ vắng hơn hẳn, các quán cà phê nhìn ra phố giờ thấy nhiều ghế trống hơn.

Anh Rin, anh họ của vợ tôi, là chủ một cơ sở sản xuất rượu rhum ở Hội An, tên là Vivid Rhum. Tuần trước, ảnh hỏi tôi có thể giúp ảnh chạy quảng cáo Google Ads để thu hút thêm khách trong mùa này không. Tôi nói OK ngay, không cần suy nghĩ.

Để các anh chị hiểu vì sao tôi nhận lời nhanh như vậy, tôi cần kể về ảnh trước.

Phần 1. Ba năm, hai trăm lần thất bại, một mình

Anh tôi không phải dân làm rượu. Bản chất của ảnh, ảnh tự nói: “Tôi là người kỹ thuật. Có kiến thức tương đối tốt về cơ, điện, nhiệt và tự động.”

Cái khiến ảnh bắt đầu là một quan sát rất Việt Nam. Khí hậu nhiệt đới, thảm thực vật phong phú, nông sản dư thừa. Mía ở miền Trung dư đến mức nông dân đã chán không buồn trồng nữa, nhiều người chuyển sang trồng cây keo vì không có đầu ra cho mía, ngoài việc làm đường. Ảnh nói:

“Tôi thấy tài nguyên Việt Nam chúng ta có quá nhiều mà không khai thác được.”

Sau vài chuyến đi châu Âu quan sát, ảnh quay về và quyết định nghiên cứu làm rượu rhum từ chính mía của quê mình.

Vấn đề đầu tiên là không có ai dạy. “Trên không gian mạng không có một cái tài liệu nào người ta viết về cái quy trình sản xuất rượu rhum. Bởi vì đó là bí quyết của từng gia đình, của từng cơ sở sản xuất rượu, và người ta sẽ không công bố.” Đây không giống lập trình hay nấu ăn, không có Wikipedia, không có video hướng dẫn trên YouTube. Mỗi nhà làm rhum trên thế giới giữ công thức của mình như báu vật. Ảnh phải tự mò từ đầu. Một mình. “Một thân một ngựa để làm việc này. Không có một sự góp ý gì của ai hết.”

Cách ảnh bắt đầu khiêm tốn đến mức tôi không tưởng tượng nổi. Ảnh ra đường, mua lại nước mía của những người bán nước mía ven đường, mỗi ngày được khoảng 20 lít. Đem về chia làm ba bốn phần, thử lên men theo các cách khác nhau. Thất bại, đổ đi, thử lại. Hôm sau lại ra mua tiếp.

“Trên 100 đến 200 lần thất bại”, ảnh nói. “Nhiều lúc muốn bỏ. Nhưng mà tôi vẫn quyết định theo tới cùng cuộc chơi.”

Một ngày, cái mẻ chưng cất ra được đúng mùi hương rượu. “Mùi hương nó ra được sau khi chưng cất là đúng mùi hương của rượu rhum.” Đó là khoảnh khắc bước ngoặt. Từ đó, ảnh bắt đầu làm quy mô lớn hơn, và đây là chỗ nền tảng kỹ thuật cơ điện của ảnh phát huy tác dụng.

Không ai ở Việt Nam bán tháp chưng cất rhum bằng đồng quy mô công nghiệp, ảnh tự thiết kế, tự mua đồng về làm, tự hàn từng mối nối, dựng tháp đồng bốn tầng. Khi máy xay mía nhỏ 1-2 lít một ngày không còn đủ, ảnh làm máy lớn hơn. 700 lít một ngày. Rồi 1.000 lít. Rồi 3 tấn mía một ngày. Mỗi cấp độ là khoảng sáu tháng nghiên cứu và sửa sai.

Ảnh cũng làm nhiều thứ rất Việt Nam, không bắt chước châu Âu một cách máy móc. Châu Âu ủ rhum trong thùng gỗ sồi, ảnh ủ trong chum vại sành sáu tháng trước khi đóng chai, để rượu mượn được hương đất. Châu Âu dùng vani giá đắt, ảnh nhìn quanh và thấy Việt Nam có chanh dây thừa thãi, có chuối rừng trên núi không ai khai thác hết, và dùng chính những thứ đó làm ra hai dòng rhum đặc trưng. Mía nguồn từ Thăng Bình, Quảng Nam, một tấn một ngày liên tục, bã sau chưng cất ảnh chở quay lại các vườn làm phân bón hữu cơ, đóng kín một vòng tròn. Điện mặt trời cung cấp khoảng 60 phần trăm năng lượng cho cả quy trình, và phòng lạnh trữ rhum trong khí hậu nóng của Hội An ảnh cũng tự thiết kế.

Tất cả những lựa chọn rất Việt Nam đó, từ mía Thăng Bình đến chum vại sành đến khí hậu nóng ẩm của Hội An, đều quay về một thứ: cái vị thơm ngon mà khách nếm xong rồi không tìm được ở đâu khác trên thế giới. Giống cách bánh mì Hội An nổi tiếng thế giới có vị đặc biệt nhờ quá trình lên men với nước và khí hậu nơi đây, rhum của ảnh là sản phẩm của Hội An, không sao chép được ở nơi khác. Ảnh giải thích bằng câu của người làm nghề:

“Bản chất nó là rượu rhum, nhưng hương mía vẫn còn trong rượu. Đó là bản chất của quá trình lên men.”

Ở đây cần nói rõ một điều mà nhiều người Việt không biết: cái mà chúng ta quen gọi chung là “rượu rum” thực ra có hai loại rất khác nhau. Rum (cách viết kiểu Anh) được chưng cất từ mật mía, tức là sản phẩm phụ sau khi nấu đường. Đây là loại mà các cơ sở rượu Việt Nam lâu nay vẫn làm. Còn rhum (cách viết kiểu Pháp, thế giới gọi là rhum agricole) là rượu được lên men và chưng cất trực tiếp từ nước mía tươi. Đó là lý do sản phẩm của ảnh có hương mía thơm rõ rệt như vậy.

Ở Việt Nam đã có một vài thương hiệu rhum agricole, nổi bật nhất là Sampan ở Hội An và Bélami. Tuy nhiên, cả hai đều do người nước ngoài sáng lập, một người Pháp và một người Bỉ, với máy móc mang từ châu Âu sang. Anh Rin là người Việt đầu tiên tự nghiên cứu công nghệ, tự dựng tháp đồng từ đầu, và làm ra rhum agricole bằng kiến thức và đôi tay của một người Việt. Đó là lý do đây thật sự là chai rhum đầu tiên của một người Việt.

Tổng cộng ba năm. Cộng thêm hành trình xin giấy phép, mà ảnh gọi thẳng là “một vấn đề cực kỳ khó”. Bây giờ ảnh đã có sản phẩm chính thức trên thị trường, có xưởng rượu ở Hội An mở cho khách tham quan, nếm rhum, học pha cocktail.

Khi ảnh nói câu này, tôi nhớ rõ: “Tôi là người tiên phong của Việt Nam, tôi làm được điều đó. Thật sự rất là khó.”

Đó là người mà tôi nhận lời giúp.

Phần 2. Hai buổi sáng của tôi, so với ba năm của ảnh

Cái mà ảnh cần lúc này không phải là kỹ thuật làm rhum, ảnh đã chinh phục cái khó nhất rồi. Ảnh cần một thứ tưởng chừng đơn giản hơn nhiều, nhưng vẫn đang chặn ảnh: làm sao để khách quốc tế đi du lịch Hội An biết đến ảnh và đặt tour, đặc biệt trong mùa vắng khách này.

Tôi mở Claude lên vào một buổi sáng để cùng nó dựng chiến dịch Google Ads. Tôi mô tả đối tượng khách, sản phẩm, ngân sách. AI đề xuất hơn 50 chủ đề tìm kiếm, viết 15 tiêu đề và 5 đoạn mô tả đều dưới giới hạn ký tự, đề xuất đường dẫn phụ, các đoạn nổi bật, và các đoạn cấu trúc dịch vụ. Quan trọng hơn, nó cảnh báo tôi về các bẫy mà người chạy quảng cáo lần đầu hay vướng. Cuối quy trình, Google báo chỉ số tối ưu quảng cáo đạt 100 phần trăm. Ngày thứ hai sau khi chiến dịch chạy, tỷ lệ nhấp chuột là 15 phần trăm, gấp 10 đến 15 lần tỷ lệ trung bình của ngành du lịch (lưu ý: Google cần khoảng 7 ngày để học và một tháng để chạy ổn định, con số ngày thứ hai chỉ là tín hiệu sớm chứ chưa phải kết luận).

Buổi sáng hôm sau, khi tôi đang cài hệ thống theo dõi chuyển đổi vào trang chủ của Vivid Rhum, tôi phát hiện trang chủ tải mất 30 giây, vì mỗi tấm ảnh là ảnh gốc từ máy ảnh chưa hề qua tối ưu. Tôi đang trả tiền cho Google để dẫn khách tới một cánh cửa bị khóa. Tôi mở Claude lên lần thứ hai, bật chế độ tự động, và bắt đầu dựng lại trang web. Năm tiếng sau trang web mới đã hoàn chỉnh: 7 trang, 3 ngôn ngữ (Anh, Pháp, Tây Ban Nha), điểm hiệu suất Lighthouse 90+/100 cả trên điện thoại lẫn máy tính, trang chủ tải trong dưới 2 giây trên kết nối 4G. Tôi không viết một dòng code nào bằng tay.

Không biết là tình cờ hay thực sự hiệu quả, sáng nay ảnh ghé và vui cười nói: “Hôm qua có 2 đoàn khách châu Âu gọi đặt tour cuối năm.”

Tôi viết ngắn về phần này, vì hai buổi sáng của tôi so với ba năm của ảnh thì nó không đáng để kể dài.

Phần 3. Hai loại thủ công

Anh tôi mất ba năm để làm ra một chai rhum mà thế giới có thể nếm.

Tôi mất hai buổi sáng để làm cho thế giới có thể tìm thấy chai rhum đó.

Tôi muốn các anh chị thấy rõ sự đối lập này, vì nó vừa thật và vừa cay đắng cho rất nhiều doanh nghiệp Việt. Có biết bao nhiêu người như anh tôi đang làm ra những sản phẩm có thật, đầy tâm huyết, rất công phu, nhưng “mặt tiền trên mạng” của họ cũ kỹ, chậm chạp, không có cách nào tìm thấy được. Không phải vì họ lười. Mà vì cái khoảng cách giữa “biết làm sản phẩm” và “biết làm hiện diện trên mạng” đã từng quá lớn, quá tốn kém để vượt qua.

Năm 2026, khoảng cách đó đã thu nhỏ lại đến mức đáng kinh ngạc. Hai buổi sáng. Không cần biết viết code. Không cần thuê đơn vị dịch vụ tốn cả chục triệu. Chỉ cần biết hỏi AI đúng câu hỏi, hoặc tìm được một người trong nhà biết hỏi.

Cái phần khó nhất, người Việt mình đã và đang làm. Đi một vòng quanh đất nước sẽ thấy vô số xưởng nhỏ, hộ thủ công, làng nghề đang thầm lặng làm ra những thứ tử tế từ chính nguyên liệu của quê mình. Chúng ta có rất nhiều sản phẩm để tự hào. Cái thiếu lâu nay chỉ là một “mặt tiền” xứng đáng để khách của họ tìm thấy.

Năm 2026, cái thiếu đó hoàn toàn có thể được tháo gỡ nhanh. Nếu các anh chị đang làm ra một thứ đáng tự hào, gợi ý của tôi là hãy dành ra một buổi sáng để xem AI có thể giúp gì cho “mặt tiền trên mạng” của doanh nghiệp mình.

Còn nếu các anh chị đang ở Hội An hoặc sắp tới Hội An, ghé Vivid Rhum một buổi chiều. Nếm thử rhum chanh dây và chuối rừng của ảnh, cái vị thơm ngon các anh chị sẽ không tìm được ở đâu khác trên thế giới. Xem tháp đồng bốn tầng ảnh tự dựng, nghe ảnh kể về hành trình ba năm, và tự trải nghiệm kỹ thuật chưng cất rượu độc đáo.

Câu hỏi tôi muốn để lại cho các anh chị: trong làng quê hay trong khu phố của mình, các anh chị có biết một người như anh tôi không? Một người đã làm xong phần khó, mà còn vướng phần dễ chỉ vì không biết hỏi ai? Tôi rất muốn nghe câu chuyện của họ.

References
[1] Vivid Rhum, https://vividrhum.com (trang web mới của Vivid Rhum, dựng trong 5 tiếng)

Mới đây, giáo sư Andrew Ng, một trong những người tôi kính nể nhất trong giới AI, có viết hai bài về AI và việc làm. Quan điểm cốt lõi của ông: sẽ không có chuyện “AI cướp việc hàng loạt” (jobpocalypse). Ngược lại, ông dự báo một “jobapalooza”, nghĩa là sẽ có rất nhiều cơ hội việc làm mới, đặc biệt trong mảng phần mềm.

Về làn sóng sa thải ở big tech hiện nay, Andrew Ng giải thích rằng lý do thật sự không phải là AI. Trong thời COVID, nhờ lãi suất thấp và các gói kích thích tài chính lớn của chính phủ Mỹ, rất nhiều công ty đã tuyển vượt mức cần thiết. Bây giờ vốn không còn dồi dào, họ phải cắt giảm để về lại quy mô hợp lý. Đổ lỗi cho AI nghe ấn tượng hơn và làm ban lãnh đạo trông thông minh hơn so với việc thừa nhận họ đã tuyển dụng không hợp lý. Theo tôi, đây là một cách giải thích thuyết phục cho hiện tượng cắt việc ở big tech.

Đáng chú ý hơn, Andrew Ng chỉ ra một điểm ít người Việt Nam để ý: dù coding agent đang phát triển rất nhanh và mỗi lập trình viên đang trở nên năng suất gấp 10 lần, các công ty Mỹ vẫn tiếp tục tuyển lập trình viên rất mạnh. Lý do, theo lời ông, là “nhu cầu cho phần mềm tuỳ biến không có giới hạn thực tế”. Khi mỗi người làm được nhiều hơn, chúng ta không cần ít người hơn, mà chúng ta sẽ xây nhiều phần mềm hơn, cho nhiều bài toán hơn. Ông còn nhắc đến một xu hướng mới: tuyển dụng ở các vị trí “X Engineer” — Recruiting Engineer, Marketing Engineer — tức là những người ngồi trong một bộ phận nghiệp vụ cụ thể và tự xây phần mềm phục vụ chính bộ phận đó.

Còn ở Việt Nam, bản thân tôi đang sống trong chuyển dịch này mỗi ngày.

Phần 1. Câu chuyện thật của Vietbooks

Một trong các sản phẩm chính của tôi là Vietbooks, một phần mềm kế toán. Tôi bắt đầu dự án này từ năm 2017, và phần lớn quãng đường đó tôi đi một mình, solo.

Tốc độ ship của giai đoạn solo là tốc độ hợp lý của một người làm tất cả: code, test, hỗ trợ khách, viết tài liệu, sửa lỗi nửa đêm. Không tệ. Nhưng nó có một giới hạn rất thật, và giới hạn đó luôn nằm ở những lần nâng cấp phiên bản lớn.

Tôi vẫn nhớ lần bổ sung phân hệ quản lý kho vào hệ thống. Đó không phải thêm một tính năng. Đó là một cuộc tái cấu trúc dữ liệu: phải chuyển đổi toàn bộ dữ liệu cũ sang cấu trúc mới, viết lại nhiều màn hình, đảm bảo dữ liệu của khách hàng không bị hỏng trong quá trình chuyển. Một mình làm việc đó, vừa code vừa lo, vừa hỗ trợ khách đang dùng phiên bản hiện tại. Một lần nâng cấp lớn như vậy có thể ngốn vài tháng, và là rào cản tâm lý lớn nhất với người làm phần mềm solo: bạn không dám đụng vào phiên bản lớn vì chi phí thời gian và rủi ro quá cao.

Khi AI đủ tốt để cùng viết code, cái rào cản đó đột nhiên được gỡ.

Từ 2.0 lên 3.0 là một bước nhảy lớn: hỗ trợ hoá đơn điện tử, tự động đọc và xuất hoá đơn, cập nhật theo thông tư mới. Mỗi cái trong số đó trước kia là một dự án riêng, đủ để làm tôi chần chừ hàng tháng. Lần này, tất cả được gộp vào một phiên bản.

Từ 3.0 lên 4.0 là một bước nhảy lớn nữa, và cách lần trước chỉ vài tháng. 4.0 tích hợp các agent AI vào phần mềm: tạo bút toán, phân tích dữ liệu, trả lời câu hỏi về luật kế toán. Agent làm việc thật, không phải chỉ để trò chuyện cho vui.

Tôi muốn thành thật một chuyện. Chặng 2.0 lên 3.0 tôi có em trai phụ. Nhưng em trai tôi không phải lập trình viên, bạn ấy code bằng AI. Vai trò của tôi chia làm hai phần. Một là dạy bạn ấy cách làm việc với AI cho ra kết quả tốt: lên kế hoạch kỹ trước khi code, code tập trung vào từng tính năng hoặc từng lỗi một, giữ ngữ cảnh gọn gàng, và dùng một AI khác để kiểm tra chéo. Hai là tôi đóng vai trò chốt chặn cuối cùng, soi từng dòng code và từng thay đổi về kiến trúc, cấu trúc dữ liệu, trước khi cho ra phiên bản mới — để đảm bảo cái chúng tôi đưa đến khách hàng ít lỗi nhất có thể, và không ảnh hưởng đến người đang dùng. Lỗi vẫn có, dĩ nhiên, nhưng chúng tôi sửa rất nhanh, và tốc độ ship tổng thể thật sự là điều tôi không tưởng tượng nổi cách đây ba năm.

Điều quan trọng không phải là chúng tôi đột nhiên giỏi hơn. Điều quan trọng là cái rào cản kinh điển của một người làm phần mềm doanh nghiệp solo, không dám đụng vào phiên bản lớn, đã được AI gỡ ra. Một khi rào cản đó được gỡ, mọi thứ phía sau đều thay đổi theo.

Phần 2. Quay lại năm 2016, để hiểu vì sao cơ hội bây giờ khác

Năm 2016, tôi đang sống và làm việc ở Mỹ. Công việc chính là quản lý và phát triển phần mềm để thương mại hoá một dự án nghiên cứu được tài trợ bởi chương trình SBIR của National Science Foundation. Lúc bấy giờ, ba tôi nhờ tôi viết phần mềm cho công ty của ba, một công ty kiểm toán Việt Nam đã hoạt động lâu năm. Họ muốn tăng hiệu quả nội bộ, chuẩn hoá quy trình, và giảm bớt những bước thủ công mà mỗi mùa kiểm toán lại ngốn hàng trăm giờ của các bạn kiểm toán viên.

Họ đã từng nghĩ đến chuyện mua phần mềm có sẵn. Vấn đề là không có phần mềm nào vừa khớp. Ngành kiểm toán có những quy trình rất đặc thù, theo chuẩn riêng, theo cách làm việc nội bộ riêng. Các giải pháp đóng gói trên thị trường, thuộc nhóm ERP, hoặc CRM, hoặc các phần mềm quản lý dự án phổ thông, đều giải được khoảng 60 phần trăm bài toán, nhưng 40 phần trăm còn lại lại là phần quan trọng nhất.

Lựa chọn còn lại của họ là đặt hàng riêng từ một công ty gia công phần mềm. Mức giá thị trường năm đó cho một dự án phức tạp như vậy thường rơi vào khoảng 1 đến 3 tỷ đồng cho 6 tháng đến 1 năm phát triển, cộng thêm phí bảo trì hàng năm khoảng 10 đến 20 phần trăm. Và đó là chưa tính phí phát triển bổ sung khi phát sinh tính năng mới sau này. Với một công ty kiểm toán cỡ trung, đó là một khoản đầu tư có thể làm họ chùn chân.

Vì là chỗ quen biết, tôi đã nhận lời phát triển phần mềm này, lấy tên là Audit Pro. Tôi không lấy chi phí phát triển ban đầu, và hai bên chỉ thoả thuận một mức phí sử dụng phần mềm khoảng 20.000 đến 25.000 USD một năm. Một con số rất khiêm tốn so với mức giá thị trường ở trên.

Bản yêu cầu đầu tiên không quá phức tạp. Tôi đưa ra được phiên bản đầu tiên đúng theo yêu cầu trong khoảng 4 tháng. Nhưng càng tham gia sâu vào dự án, càng có thêm yêu cầu thực tế từ phía khách hàng, càng có thêm tính năng cần bổ sung, và tôi đã dành thêm khoảng 8 tháng nữa để đáp ứng hết. Tổng cộng gần một năm trời cho một sản phẩm mà ban đầu tưởng chừng là vừa phải.

Bài học tôi mang về từ giai đoạn đó vẫn còn giá trị đến hôm nay: phần mềm doanh nghiệp luôn phình ra khi va với thực tế nghiệp vụ, và đó không chỉ là vấn đề code, mà là vấn đề hiểu nghiệp vụ đến tận chân tơ kẽ tóc.

Đây là cấu trúc xung đột tự nhiên của ngành: doanh nghiệp cần phần mềm khít với quy trình của họ, nhưng giá thành để xây tuỳ biến luôn vượt quá ngân sách hợp lý. Phần mềm tuỳ biến cho một công ty rất khó bán lại cho công ty khác, vì mỗi công ty có quy trình riêng. Cho nên giá thành phải cao để bù chi phí. Bên đặt hàng thấy giá cao thì không muốn trả, hoặc trả rồi thì sau vài năm lại muốn tự làm. Đó cũng là lý do các công ty làm dịch vụ phần mềm ở Việt Nam thường ở thế khó: chi phí đội ngũ và vận hành quá lớn so với mức giá mà khách hàng Việt Nam có thể trả thoải mái.

Mười năm trước, sau Audit Pro, chính tôi cũng đã ngưng nhận viết phần mềm tuỳ biến cho doanh nghiệp Việt Nam. Đơn giản là với chất lượng tôi muốn duy trì, công sức bỏ ra không tương xứng với mức phí hợp túi tiền của các công ty trong nước.

Bây giờ thì đã khác. Cái nút thắt năm 2016 là chi phí kỹ sư. Cái nút thắt năm 2026 không còn là chi phí kỹ sư nữa. Mà là việc hiểu nghiệp vụ, và khả năng diễn đạt nó thành bản yêu cầu đủ rõ để AI cùng làm.

Phần 3. Hai loại phần mềm doanh nghiệp Việt nên hiểu rõ

Khi tôi nói chuyện với các anh chị làm doanh nghiệp, tôi thường thấy mọi người đang bị cuốn theo cơn sốt AI, nghĩ rằng cứ có “AI” trong phần mềm là doanh nghiệp sẽ tự nhiên thông minh và hiệu quả hơn. “Phần mềm” và “AI” hay bị gộp chung thành một khối. Nhưng theo tôi, cơ hội lớn nhất sẽ bị bỏ qua nếu gộp như vậy. Tách ra, ta sẽ thấy AI giúp doanh nghiệp cải thiện năng suất qua hai loại phần mềm rất khác nhau:

Loại 1, phần mềm tự động hoá truyền thống. Bên trong sản phẩm không có AI. Nhưng nó có quy tắc rõ ràng, đầu vào và đầu ra rõ ràng. Sát với quy trình hiện thời của doanh nghiệp, giải quyết một nút thắt cụ thể.

Ví dụ rất gần với tôi: chính em trai tôi mà tôi đã nhắc ở phần trước, ngoài chuyện phụ tôi làm Vietbooks, còn tự xây cho doanh nghiệp nhỏ của mình một phần mềm chấm công, hoàn toàn bằng AI hỗ trợ code, chỉ trong vài tuần. Em tôi không phải lập trình viên, mà là người trong bộ phận đó — chính là kiểu “X Engineer” mà Andrew Ng vừa nói đến, áp dụng ở quy mô một doanh nghiệp Việt Nam.

Phần mềm chấm công đó cũng không có AI bên trong, chỉ là một quy trình nội bộ được số hoá đúng cách. App đang chạy thật, đang chấm công cho hơn 60 nhân viên, sử dụng GPS, chạy trên điện thoại, và giải đúng bài toán mà các phần mềm chấm công có sẵn không giải được. Năm 2016, em trai tôi không bao giờ tự xây nổi. Năm 2026, bạn ấy làm được, vì AI đã hạ rất thấp ngưỡng để biến một ý tưởng nội bộ thành phần mềm chạy được. Loại 1 đã có từ 30 năm nay, nhưng năm 2026 mới là lúc nó thật sự khả thi cho từng phòng ban, từng quy trình nhỏ trong doanh nghiệp.

Loại 2, phần mềm có AI bên trong sản phẩm. Có agent. Có khả năng đọc văn bản tự nhiên, tra cứu tài liệu nội bộ, suy luận, soạn thảo. Mở ra một cánh cửa mới: tự động hoá những việc đòi hỏi suy luận linh hoạt, vốn trước đây buộc phải có con người ngồi xử lý từng trường hợp.

Ví dụ từ chính sản phẩm tôi: Vietbooks 4.0 tích hợp agent AI vào phần mềm kế toán. Agent đọc chứng từ để tạo bút toán, phân tích dữ liệu nghiệp vụ, tra cứu và trả lời câu hỏi về luật kế toán theo thông tư hiện hành. Đây là việc gần như bất khả thi vào năm 2022 — không phải vì không có ý tưởng, mà vì AI hồi đó chưa đủ chính xác để giao việc thật trong môi trường kế toán. Năm 2026 đã làm được, và làm tốt nếu yêu cầu nghiệp vụ đủ rõ.

Cả hai loại đều đang trở nên rẻ và nhanh hơn rất nhiều so với năm năm trước. Cả hai loại đều có cơ hội cho doanh nghiệp Việt. Loại 1 không hào nhoáng, nhưng giải quyết được phần lớn nỗi đau nội bộ thật sự. Loại 2 hào nhoáng hơn, và mở ra những bài toán mà trước nay không có lời giải.

Phần 4. Cơ hội thật sự là gì?

Nếu tôi phải tóm lại trong một câu, thì đó sẽ là:

Năm 2016, cùng bài toán đó cần một hợp đồng nhiều tỷ đồng và 1 đến 2 năm. Năm 2026, nếu yêu cầu nghiệp vụ rõ và đội biết việc, con số nhỏ hơn rất nhiều và thời gian ngắn hơn rất nhiều.

Đây cũng là tinh thần “jobapalooza” của Andrew Ng, nhìn từ Việt Nam. AI không cướp việc, mà mở ra một mảng phần mềm doanh nghiệp mà mười năm trước không thể tồn tại vì kinh tế không cho phép. Nhu cầu cho phần mềm tuỳ biến, nói như Andrew Ng, “không có giới hạn thực tế”. Thị trường đó bây giờ đã mở.

Tôi tin rằng người thắng trong mảng này không phải là các tập đoàn phần mềm lớn. Người thắng sẽ là những đội nhỏ biết dùng AI để làm việc nhanh, và quan trọng hơn, biết ngồi xuống nghe khách kể đủ lâu để hiểu và giải quyết đúng nỗi đau của họ.

Mười năm trước, sau Audit Pro, tôi đã ngưng nhận viết phần mềm tuỳ biến cho doanh nghiệp Việt Nam vì kinh tế của mảng này không cho phép. Năm nay tôi quay lại, vì kinh tế đã thật sự khác. Tôi đang nhận một số ít dự án để tư vấn, xây dựng, và triển khai phần mềm Loại 1 hoặc Loại 2 đo ni đóng giày cho các doanh nghiệp vừa, với chi phí và thời gian của năm 2026 chứ không phải năm 2016. Nếu công ty bạn đang có một quy trình nội bộ bị nghẹn, hãy nhắn tôi. Chúng ta uống cà phê, và bạn kể tôi nghe câu chuyện của bạn.

Ba câu hỏi để mời các anh chị thảo luận

1. Doanh nghiệp anh chị có một quy trình nội bộ nào mà mỗi tháng lấy đi của các bạn nhân viên hàng chục, hàng trăm giờ làm thủ công, nhưng vẫn chưa số hoá được vì phần mềm có sẵn không vừa? Đó có thể chính là Loại 1 mà tôi vừa nói.

2. Anh chị thấy AI ở Việt Nam đang được nói đến nhiều hơn so với được dùng thật trong vận hành. Theo anh chị, nút thắt thật sự là ở đâu: ở công nghệ, ở chi phí, ở niềm tin, hay ở chỗ chưa ai dành thời gian ngồi xuống để hiểu nghiệp vụ?

3. Nếu chi phí xây một phần mềm đặc thù năm 2026 chỉ còn một phần nhỏ so với năm 2016, anh chị sẽ chọn xây cái gì đầu tiên cho doanh nghiệp mình?

Tôi rất mong được đọc câu trả lời của các anh chị bên dưới.

Mở đầu: Khoảnh khắc Claude nhớ điểm yếu lớn nhất của tôi

Vài tuần trước, Anthropic ra mắt tính năng auto-memory cho Claude Code. Trước đó Claude Code đã có file CLAUDE.md mà tôi tự viết tay, nhưng auto-memory hoạt động linh hoạt hơn — Claude tự đề xuất ghi nhớ những gì học được từ chỉnh sửa của tồi, lưu vào markdown file tôi có thể đọc và sửa. Tôi tin đây là bước đáp lại của Anthropic sau khi cộng đồng OpenClaw đã có hệ thống memory tương tự một thời gian.

Tôi dùng nó ngay ngày đầu tiên.

Một buổi tối tuần đó, tôi đang brainstorm với Claude về một ý tưởng sản phẩm mới. Sau hơn mười lăm năm làm startup và ra mắt năm sản phẩm, tôi biết rõ điểm mạnh và điểm yếu của mình. Điểm mạnh: làm sản phẩm chất lượng tốt, từ engineering đến UX. Điểm yếu cố hữu, lặp đi lặp lại qua từng dự án: phân phối. Tôi giỏi xây, dở bán. Nhiều nhà sáng lập kỹ thuật khác cũng vậy. Sản phẩm tốt hiếm khi viral qua đêm. Phân phối đòi hỏi sự kiên nhẫn, bền bỉ, và marketing từng bước một, đó là chỗ tôi luôn vật lộn.

Đêm đó tôi gõ vào Claude: “Hãy nhớ giúp anh điều này. Lần sau khi anh hào hứng với một ý tưởng mới và bắt đầu một dự án mới, hãy nhắc anh điểm yếu của mình. Anh xây tốt, nhưng phân phối là chỗ anh cần kế hoạch rõ ràng từ ngày đầu, không phải chuyện để sau.”

Claude lưu vào memory.

Vài hôm sau, tôi mở Claude và bắt đầu một câu chuyện mới về một ý tưởng SaaS B2B mà tôi đang muốn thử. Tôi chưa nói gì về quá khứ. Claude trả lời gần như câu đầu tiên: “Trước khi mình đi sâu vào tính năng, anh nhớ note trước đây không? Anh xây tốt, phân phối là điểm anh hay vật lộn. Lần này anh đã nghĩ về kênh phân phối chưa? Đối tượng đầu tiên ai sẽ trả tiền, làm sao tiếp cận họ trong ba tháng đầu?”

Tôi sững lại. Không phải vì câu trả lời, mà là vì cảm giác. Cảm giác ở đây như tôi đang nói chuyện với một đồng nghiệp đã thấy mình lặp lại pattern này nhiều lần, và đủ thân để nhắc thẳng thay vì để mình tự rơi vào hố cũ.

Đó là khoảnh khắc tôi hiểu vì sao memory là một trong những tính năng quan trọng nhất mà bất cứ AI app nào muốn giữ chân người dùng đều phải có. Không phải “nice to have”. Đây là điều kiện cần để app của bạn không bị quên đi sau lần dùng thứ ba.

Trong bài trước về Harness Engineering, tôi đã đề cập 4 trụ cột để “cầm cương” AI agent: Context Management, Tool Management, Memory, và Sandbox. Bài đó đi sâu vào hai trụ cột đầu. Hôm nay tôi muốn nói về trụ cột thứ ba: Memory.

Phần 1: Vì sao Memory là vũ khí giữ chân người dùng

Khoảnh khắc Claude nhớ chi tiết về tôi không phải chuyện mới với cộng đồng AI. ChatGPT đã ra tính năng memory từ tháng 2 năm 2024 [1], đến nay đã hai năm. Hãy để tôi kể một câu chuyện cụ thể hơn để thấy memory tạo ra cảm giác “AI hiểu mình” như thế nào.

Vài tháng trước tôi bắt đầu chơi pickleball nhiều hơn, xem nó như việc tập thể dục hàng ngày. Là dân chơi bóng bàn lâu năm từ thời phổ thông rồi đại học, từng đánh giải cho đội tuyển trường, tôi mang theo phong cách quen thuộc: những cú giựt xoáy. Tôi vào ChatGPT để nghiên cứu mua vợt, và nói rõ phong cách của mình: nền tảng bóng bàn, đề cao tốc độ, đánh đôi, cần vợt có độ xoáy cao và bề mặt bền. ChatGPT phân tích, gợi ý vài lựa chọn, và tôi đã mua được cây vợt ưng ý.

Ba tuần sau tôi quay lại. Lần này không hỏi vợt nữa. Lần này tôi cần giày: “Em ơi, anh đang phân vân giữa Adidas Barricade và Babolat Jet Mach. Cái nào tốt hơn?”

ChatGPT trả lời mà không cần tôi nhắc lại bất cứ thứ gì: “Anh chơi đôi và đề cao tốc độ, theo phong cách bóng bàn anh đã chia sẻ. Adidas Barricade là giày tennis, thiết kế cho người đứng baseline đánh rally dài. Nhưng anh chơi đôi pickleball thì cần ngược lại: nhẹ và linh hoạt để di chuyển gần lưới. Em gợi ý mẫu Babolat vì nó cho anh khả năng đổi hướng nhanh hơn ở khu vực kitchen, đúng với phong cách của anh.”

ChatGPT không chỉ nhớ tôi chơi pickleball. Nó nhớ phong cách của tôi, nhớ tôi từ bóng bàn sang, nhớ tôi đề cao tốc độ. Và nó vận dụng tất cả vào một câu hỏi hoàn toàn khác (giày, không phải vợt) để đưa ra so sánh có lý do.

Lúc đó tôi không cảm thấy mình đang nói chuyện với một chatbot. Tôi cảm thấy mình đang nói chuyện với một anh bạn đã đi với mình một quãng đường, hiểu lựa chọn của mình.

Đây mới là khoảnh khắc tạo ra moat (hào nước — một rào cản cạnh tranh bền vững) thật sự cho sản phẩm. Sau trải nghiệm đó, tôi có dễ chuyển sang chatbot khác không? Đối thủ có copy được những gì ChatGPT đã học về phong cách chơi của tôi không? Câu trả lời là khó. Vì kiến thức đó không nằm trong dữ liệu huấn luyện của ai khác. Nó nằm trong lịch sử tương tác giữa tôi và app này.

Càng dùng nhiều, app càng hiểu bạn. Càng hiểu bạn, càng khó chuyển sang app khác. Chi phí chuyển đổi không chỉ nằm ở dữ liệu (xuất ra rồi nhập vào app mới được), mà còn ở cảm giác thân thuộc đã xây dựng theo thời gian.

Đó là lý do tôi từ chối xây Vietbooks Agentic mà không có memory. Một phần mềm kế toán AI mà không nhớ kế toán viên đã sửa gì lần trước, không nhớ công ty này quy ước văn phòng phẩm về tài khoản nào, không nhớ tên người dùng. Phần mềm đó không phải agentic. Đó chỉ là chatbot có giao diện đẹp.

Trong năm 2026, một AI app không có memory sẽ khó tồn tại được. Đó là tiêu chuẩn mới.

Phần 2: Năm phương án, một lựa chọn

Trước khi bắt đầu, tôi nhờ Claude liệt kê năm phương án phổ biến nhất để thêm chức năng memory. Tóm tắt nhanh: Mem0 [2] dùng LLM tự trích thông tin rồi lưu vào vector database, nhưng tôi không kiểm soát được nó nhớ gì. Letta [3] thiết kế memory như hệ điều hành ba tầng, đẹp nhưng buộc viết lại toàn bộ agent đã có. Hermes-agent [4] có cơ chế cập nhật memory phức tạp, khó debug khi có sự cố. OpenClaw [5] là dự án mã nguồn mở dành cho cá nhân, không có khái niệm “công ty này” và “công ty kia”.

Phương án thứ năm là cách Claude [6] làm: file Markdown người đọc được, agent tự ghi qua tools, người dùng có thể đọc và sửa. Đây là phương án tôi chọn.

Lý do rất đơn giản: đọc được, sửa được, xóa được. Khi chị Trang là kế toán trưởng của một công ty khách hàng mở memory ra, chị đọc được luôn:

“Với văn phòng phẩm, công ty này ghi nhận chi phí vào TK 6423.”

Sai thì chị sửa. Đúng thì chị giữ. Chị sở hữu memory của công ty mình, không phải hệ thống AI sở hữu nó.

Trong môi trường kế toán, minh bạch thắng tối ưu. Tôi sẵn sàng đánh đổi khả năng tìm kiếm phức tạp để có markdown đơn giản. Vì với một phần mềm kế toán Việt Nam, việc đọc được AI nhớ gì về công ty mình quan trọng hơn việc AI luôn truy hồi memory hoàn hảo.

Phần 3: Foundation — Học từ chỉnh sửa của bạn

Cách cơ bản nhất, cũng là cách giá trị nhất, là học từ những gì bạn làm, cụ thể là từ những lần bạn sửa AI. Đây là nền móng mà mọi lớp memory khác sau đó có thể xây lên.

Chị Trang ở công ty A nhận một bút toán nháp văn phòng phẩm AI tạo giúp. AI mặc định gán vào TK 6422 — chi phí vật liệu quản lý. Nhưng công ty chị quy ước VPP về TK 6423 — chi phí đồ dùng văn phòng (đúng theo TT99, cụ thể hơn). Chị sửa, lưu lại.

Hệ thống lưu chỉnh sửa này của chị vào một bảng cơ sở dữ liệu đơn giản, đúng nghĩa Hash Map mà mọi sinh viên lập trình đều quen: input là loại giao dịch (VPP), output là cách user sửa (6422 → 6423).

Lần thứ hai chị Trang gặp giao dịch VPP, AI tra memory chỉnh sửa (correction memory) này trước khi tạo bút toán. Nó thấy lần trước chị đã sửa, nên dùng 6423 ngay từ đầu. Trên bút toán có một ghi chú (badge) nhỏ:

🧠 Đã áp dụng correction trước đó: “Dòng 1: TK 6422 → 6423”

Đây là khoảnh khắc người dùng thấy rõ được giá trị của AI memory. Không có badge, AI có cảm giác bí ẩn — chị không biết vì sao nó chọn đúng. Có badge, chị thấy ngay: “À, lần trước mình sửa, giờ nó nhớ rồi.”

Đây là vòng lặp dữ liệu cơ bản nhất: hành động của bạn tạo tín hiệu, tín hiệu được học và ghi nhớ, ghi nhớ giúp hành động tốt hơn lần sau. Và đây là lớp memory tin cậy nhất, vì nó học từ những gì bạn thực sự làm, không phải những gì bạn nói.

Cần lưu ý: cơ chế này không hoàn hảo. Việc tra correction memory phụ thuộc vào agent gọi tool tra cứu với context phù hợp. Cho nên, agent có thể không gọi, hoặc gọi với từ khóa không khớp. Điều này dẫn tới giới hạn của correction memory: nó chỉ có tác dụng khi entry agent đang tạo bút toán mới, và nó “ẩn” trong cơ sở dữ liệu vì user không thấy được trừ khi badge xuất hiện. Nếu chị Trang muốn quy ước VPP → 6423 áp dụng ổn định hơn cho mọi bút toán, được nhìn thấy bởi mọi agent (cả agent phân tích báo cáo lẫn agent tra cứu kiến thức của app), và được hiển thị rõ ràng trong Memory Panel, chị cần một cơ chế khác — đó là nội dung Phần 4 tiếp theo sau đây.

Phần 4: Khi user nói trực tiếp — hai loại memory, hai cách lưu

Phần trước miêu tả AI tự động học từ hành động của bạn và áp dụng ra sao. Phần này miêu tả khi bạn trực tiếp nói ra điều mình muốn AI nhớ. Đây cũng là cách bạn có thể nâng cấp một correction memory âm thầm thành một quy tắc rõ ràng, công khai, và áp dụng cho tất cả các agent liên quan trong app.

Khi bạn nói chuyện với AI, không phải mọi thông tin đều có giá trị nhớ như nhau. Có hai loại rất khác nhau:

Loại một: thông tin cá nhân, rủi ro thấp. Tên bạn. Cách bạn thích được gọi. Phong cách trả lời bạn ưa. Những thứ này nếu AI nhớ sai cũng không gây hậu quả nghiêm trọng. Bạn đổi ý cũng được, sửa lại cũng nhanh. AI có thể tự tin lưu, miễn là bạn có quyền hủy nếu thấy không đúng.

Loại hai: quy tắc kế toán của công ty, rủi ro cao. “Công ty này luôn dùng ACB để thanh toán cho nhà cung cấp.”, “Văn phòng phẩm đưa vào TK 6423.” Những thứ này áp dụng cho mọi nhân viên trong công ty, ảnh hưởng đến hàng trăm bút toán sau này. AI không nên tự quyết. Nó cần hỏi bạn xác nhận trước khi lưu thành quy tắc.

Vietbooks xử lý hai loại theo hai cách khác nhau:

Loại một — AI tự lưu, bạn có quyền hủy. Khi bạn nói “Hãy gọi anh là Thoại Anh”, AI lưu ngay. Đồng thời ở góc màn hình hiện một thông báo nhỏ:

🧠 Đã học: gọi bạn là “Thoại Anh” — [Undo] (8s)

Bạn không cần bấm xác nhận, và có 8 giây để undo nếu thấy không đúng. Nếu không bấm gì, memory được giữ. Đây là cách trải nghiệm tự nhiên nhất. Bạn không bị quấy rầy mỗi lần AI muốn nhớ một điều nhỏ.

Loại hai — AI hỏi, bạn quyết định. Khi bạn nói “Từ nay công ty này luôn dùng ACB để thanh toán cho nhà cung cấp”, AI không tự lưu. Nó hiện ra một hộp xác nhận:

💾 Lưu quy ước: “Công ty này luôn dùng ACB cho thanh toán NCC”
[Lưu] [Bỏ qua]

Bạn phải chủ động bấm lưu và đây là chủ ý. Vì một quy tắc sai có thể tạo ra hàng trăm bút toán sai. Bạn cần dừng lại một giây để xác nhận đây là điều bạn thực sự muốn.

Đằng sau cả hai luồng có một nguyên tắc đơn giản:

Đây là cách dung hòa giữa “AI có ghi chép minh bạch” và “user không bị spam hộp xác nhận”. Khi đã được lưu, Memory sẽ được thêm vào System Prompt của mỗi agent.

Quay lại với chị Trang: chị muốn quy ước này được áp dụng ổn định và xuyên suốt các agent, chị nói trực tiếp với AI: “Em ơi, ghi nhớ giúp chị: với công ty này, văn phòng phẩm luôn ghi vào TK 6423.” AI nhận ra đây là quy ước công ty, đề xuất qua hộp xác nhận. Chị bấm Lưu. Từ giờ, quy tắc này nằm trong System Prompt, được mọi agent nhìn thấy, hiển thị rõ ràng trong Memory Panel để chị có thể edit hoặc xóa bất cứ lúc nào.

Đây là sự kết nối giữa hai cơ chế: correction memory bắt được chỉnh sửa của user trong từng bút toán; quy ước người dùng tạo trực tiếp để biến chỉnh sửa thủ công đó thành ghi nhớ rõ ràng.

Phần 5: Bảo trì và sắp xếp Memory

Nếu để memory tự sinh sôi mãi mãi, nó sẽ thành rác. Memory cũ chồng lên memory mới. Memory mâu thuẫn nhau. Memory không ai dùng nhưng vẫn ngốn không gian trong System Prompt.

Mỗi đêm 3 giờ sáng giờ Việt Nam, tôi cho một background job chạy với từng công ty đang hoạt động. Nó làm ba việc chính:

• Tìm hai memory gần như giống nhau, giữ cái mới hơn

• Ẩn memory không pinned, không phải quy tắc cứng, và đã không được dùng quá 90 ngày

• Đưa hai memory mâu thuẫn nhau vào hàng chờ con người duyệt thay vì tự giải quyết

Quy tắc tôi áp dụng:

Máy không nên tự quyết định cái nào đúng cái nào sai khi có mâu thuẫn. Máy chỉ nên báo cáo có mâu thuẫn để con người xử lý.

Một mẹo hay để thiết kế memory cho app AI của bạn: nghĩ về nó như một wiki sống, không phải một cache phẳng. Cache khi refresh sẽ quên. Wiki thì tích lũy và tinh lọc. Tình cờ ở đây có sự đồng điệu giữa giải pháp của tôi và LLM Wiki [7] (bạn có thể xem thêm ở phần phụ lục).

Phần 6: UX — đem giá trị đến tận tay người dùng

Tất cả những gì tôi vừa kể là kiến trúc. Nhưng người dùng không nhìn thấy kiến trúc. Họ cần nhìn được, cảm nhận được memory. Nguyên tắc của tôi: memory không được hoạt động vô hình. Nếu memory chạy ngầm mà người dùng không thấy, họ không biết nó tồn tại. Không biết tồn tại thì không thấy được giá trị và sẽ không gắn bó với app.

Memory Panel — nơi user thực sự sở hữu memory

Bạn cần một trang nơi user xem được tất cả memory, sửa được, xóa được. Đừng ẩn memory, đừng làm khó truy cập. Bí quyết là cảm giác: trang này phải gợi cảm giác giống “folder documents của riêng tôi”, không phải “admin panel của hệ thống AI”. User sở hữu memory, không phải hệ thống sở hữu nó.

Nói chuyện trực tiếp với AI về memory

Người dùng có thể chat:

• “Lưu giúp anh là công ty này có 60 nhân viên.” → AI gọi propose_memory → toast xác nhận “Lưu lại ‘Công ty có 60 nhân viên’? [Có] [Bỏ qua]”.

  • AI phản hồi rõ ràng:

    ✅ Đã lưu: “Công ty có 60 nhân viên”

• “Quên cái quy tắc ACB đi, từ giờ dùng Vietcombank.” → AI gọi list_memories(keyword="ACB") để tìm đúng slug, sau đó propose_memory_update → toast xác nhận hiện old body vs new body trước khi áp dụng.

  • AI ghi nhận:

    📝 Cập nhật quy tắc “Mặc định NCC chi phí”:
    Cũ: ACB
    Mới: Vietcombank
    [Lưu] [Hủy]

Phản hồi rõ ràng tạo ra sự tin tưởng, và đưa giá trị memory đem lại đến tận tay người dùng.

Phần 7: Bài học gửi đến bạn

Memory đã được tích hợp vào Vietbooks Agentic và đang chạy thử với những khách hàng đầu tiên. Đây là ba điều tôi muốn để lại cho những bạn đang xây AI app:

Một, memory là điều kiện cần để giữ chân người dùng trong năm 2026. Nếu app của bạn không có memory, bạn đã bỏ qua cơ hội tốt nhất để giữ chân người dùng. Memory là một tiêu chuẩn mới, không phải tính năng nâng cao.

Hai, đừng dùng một UX duy nhất cho mọi loại memory. Chia theo mức rủi ro: thông tin cá nhân rủi ro thấp thì AI tự lưu cho bạn quyền hủy; quy tắc công ty rủi ro cao thì AI hỏi và bạn quyết định. AI không bao giờ được tự ý thay đổi quy tắc quan trọng.

Ba, sự minh bạch thắng các thuật toán phức tạp. File markdown đọc được mạnh hơn semantic vector được lưu trữ như một hộp đen. Giá trị lớn nhất là user ở đây có thể đọc, hiểu, tự tinh chỉnh memory của mình.

Kết luận: Càng dùng lâu, app càng hiểu bạn

Tôi vẫn nhớ cái khoảnh khắc Claude nhắc tôi về điểm yếu về phân phối. Khoảnh khắc đó định hình toàn bộ cách tôi nghĩ về memory cho sản phẩm của mình.

Tôi muốn người dùng Vietbooks Agentic có cùng cảm giác đó. Lần thứ ba họ vào, agent biết họ là ai. Lần thứ năm, agent biết công ty họ vận hành thế nào. Lần thứ mười, agent đã trở thành một phần workflow không thể tách rời.

Càng dùng phần mềm này lâu, phần mềm càng hiểu bạn. Đó là lời hứa tôi muốn Vietbooks Agentic giữ với người dùng. Và đó cũng là lời hứa tôi nghĩ mọi AI app thương mại nên giữ với người dùng của mình trong kỷ nguyên agentic.

Bạn cảm thấy AI Memory giá trị đối với bạn ra sao? Bạn có đang xây dựng memory system cho AI app của mình? Chia sẻ ở phần bình luận, tôi rất muốn nghe trải nghiệm của bạn.

Tài liệu tham khảo

[1] OpenAI. “Memory and new controls for ChatGPT.” February 13, 2024.

[2] Mem0 Documentation. “Entity-Scoped Memory.”

[3] Letta Team. “Build AI with advanced memory that can learn and self-improve over time.”

[4] Hermes Agent. “The self-improving AI agent.”

[5] OpenClaw. “Personal AI assistant.”

[6] Anthropic. “How Claude remembers your project — Claude Code Docs.”

[7] Andrej Karpathy. “LLM Wiki: A pattern for building personal knowledge bases using LLMs.” April 2026.

Phụ lục A: So sánh năm phương án memory

• Mem0 [2] — LLM trích xuất → vector DB. Không kiểm soát được bước trích xuất. Không phù hợp cho phần mềm kế toán cần audit.

• Letta (MemGPT) [3] — Memory 3 tầng kiểu hệ điều hành. Buộc viết lại toàn bộ agent đã có. Quá phức tạp cho nhu cầu của tôi.

• Hermes-agent [4] — Memory với chuỗi cập nhật nhiều bước. Cập nhật phức tạp, khó debug khi memory bị mâu thuẫn.

• OpenClaw [5] — Markdown file local cho cá nhân. Thiết kế cho một người dùng một workspace. Không có khái niệm đa công ty cần thiết cho B2B SaaS.

• Claude markdown [6] ✅ — Markdown trong database, agent ghi qua tools, user đọc/sửa được. Đọc được, sửa được, xóa được. Phù hợp với nhu cầu kế toán cần minh bạch.

Phụ lục B: LLM Wiki — một cách nghĩ song song

Một buổi tối tuần trước, tôi đi ăn với một anh bạn trong cộng đồng AI Việt Nam. Đến giữa bữa anh hứng khởi nói: “Anh đã thử LLM Wiki chưa?”

LLM Wiki [7] là một dự án mã nguồn mở mà ở đó agent đọc tài liệu thô, tự tiêu hóa, tự tạo các trang wiki, tự liên kết các khái niệm giữa các trang, đồng thời định kỳ rà soát để giữ wiki sạch sẽ.

Tôi nhận ra kiến trúc tôi đã chọn cho Vietbooks memory thực ra rất gần với mô hình LLM Wiki, dù tôi đến với nó từ Claude Code. Cùng một ý tưởng, hai cách đến.

Sự đồng điệu giữa hai mô hình:

• Đầu vào: LLM Wiki nhận tài liệu thô (text, document); Vietbooks nhận chỉnh sửa từ user và lời người dùng nói.

• Tiêu hóa: LLM Wiki có agent tạo wiki page; Vietbooks có agent đề xuất memory.

• Liên kết: Trang LLM Wiki link nhau qua khái niệm chung; memory Vietbooks link nhau qua phạm vi (cá nhân / công ty / cá nhân-công ty).

• Bảo trì: LLM Wiki rà soát định kỳ; Vietbooks có “đêm dọn dẹp” mỗi ngày.

• Quyền user: Cả hai cho user đọc và edit trực tiếp.

Cùng triết lý: memory phải sống, phải tự duy trì, phải đọc được, phải sửa được. Khi nhiều người độc lập đến cùng một câu trả lời, đó thường là dấu hiệu câu trả lời đúng.

Mỗi buổi chiều ở Hội An, tôi hay chở cả nhà đi qua những cánh đồng lúa, hít thở không khí trong lành, xem bọn nhỏ thả diều. Đang là mùa lúa chín, mùi lúa rất thơm. Ở đây tôi tìm được cảm giác bình yên.

Đây là quê vợ tôi, và dù tôi lớn lên ở Sài Gòn, bây giờ tôi dành nhiều thời gian ở đây hơn. Nhịp sống, không khí, ánh nắng chiều buông chậm rãi trên những thửa ruộng, tất cả làm tôi muốn ở lại lâu hơn. Tôi làm việc từ xa, và có lẽ tôi hoàn thành các công việc tốt nhất của mình ở đây. Tôi cũng biết ngày càng nhiều bạn trẻ làm việc từ xa về đây, vừa tận hưởng không gian trong lành, vừa làm những việc ý nghĩa nhất của họ.

Hội An sống bằng du lịch. Gần như mọi hoạt động kinh doanh đều phục vụ những người đến chơi vài ngày, hay một tuần rồi đi. Hôm trước, tôi và mấy người bạn ngồi nói chuyện, ý tưởng mở một không gian coliving và coworking nổi lên. Ở Hội An có một chỗ khá nổi tiếng là Hub Hoi An, và mô hình của họ đang được nhiều người bắt chước ở Đà Nẵng cũng như dọc bờ biển. Các con số nhìn hấp dẫn. Lối sống điều hành nó cũng hợp với tôi. Tôi vốn là dân khởi nghiệp, lại đang đầu tư vào lĩnh vực công nghệ, nên đây sẽ là cách đa dạng hóa danh mục bằng một thứ hữu hình.

Nhưng trước khi xúc tiến, các câu hỏi hiện lên chồng chất. Mua đất, thuê đất, hay thuê nhà. Bao nhiêu mét vuông. Bao nhiêu phòng. Xây tốn bao nhiêu, biên lợi nhuận thế nào, bao lâu thì hòa vốn. Khách kiểu gì. Khả năng dự án thành công thực sự là bao nhiêu. Mùa mưa lũ ở Hội An ảnh hưởng đến mô hình tài chính ra sao. So sánh với thị trường Đà Nẵng thế nào. Càng ngồi nghĩ thì danh sách càng dài.

Vài năm trước, cách duy nhất để trả lời được hết những câu đó là gọi cho rất nhiều người, Google và đọc rất nhiều bài viết. Thông tin cần thiết trong trường hợp này bản chất là đa chiều: bất động sản, ngành dịch vụ lưu trú, xây dựng cộng đồng, quy hoạch địa phương, hành vi khách hàng. Không một câu hỏi đơn lẻ nào có thể trả lời ngay lập tức. Và người tổng hợp phải là chính bản thân mình, mà phần lớn chúng ta đơn giản là không có thời gian hoặc nền tảng để làm tốt việc đó, nhất là trong lĩnh vực mình không phải chuyên gia.

Vậy nên tôi làm cái việc đã âm thầm trở thành thói quen hàng ngày. Tôi viết một câu hỏi chi tiết. Tôi yêu cầu ba mô hình AI tốt nhất thế giới hiện nay (GPT 5.5, Claude Opus 4.7, Gemini 3.1 Pro) phân tích vấn đề một cách độc lập và song song, sau đó phản biện chéo cho nhau và đối chiếu nguồn dẫn. Vì tôi đã cấu hình để chúng suy nghĩ kỹ thay vì trả lời nhanh, mỗi mô hình đều trả về một câu trả lời có chiều sâu, có cấu trúc. Và các phản hồi có chất của một bản tư vấn thực sự, không phải kiểu trả lời cho có.

Cái tôi nhận được trong 10 phút là thứ mà bản thân tôi nghiên cứu vài ngày cũng khó làm ra được [1]. Đầu tiên là các con số cụ thể. Một mảnh đất 300 mét vuông, bốn tầng, tổng diện tích sàn khoảng 800 đến 1.200 mét vuông. Khoảng mười bốn phòng riêng, cộng thêm vài giường ở phòng dorm chung. Tổng vốn mua đất và xây dựng tầm 27 đến 35 tỷ đồng. Phương án thuê biệt thự sẵn có thì chỉ tầm 8 đến 10 tỷ. Doanh thu tháng ổn định khoảng 400 đến 500 triệu đồng. Biên lợi nhuận hoạt động 26 đến 34 phần trăm.

Các con số có giá trị. Nhưng những điểm bất đồng giữa các mô hình còn giá trị hơn.

Mô hình thứ nhất đưa ra kịch bản tài chính lạc quan, có bảng biểu rõ ràng và phân chia giá đất theo từng khu vực. Mô hình thứ hai đứng ở góc nhìn của người phản biện, chỉ ra rằng lợi thế thực sự của Hub Hoi An không nằm ở tòa nhà. Đó là chín năm đi trước về cộng đồng, về đánh giá, về thứ hạng tìm kiếm. Bất kỳ ai bắt chước được tài sản vật chất vẫn sẽ vô hình với một digital nomad đang gõ “coworking Hoi An” trước khi bay qua. Mô hình thứ ba lật lại toàn bộ câu hỏi. Nó nói đại ý: anh đang nghĩ đây là một khoản đầu tư bất động sản, nhưng thực chất nó là một doanh nghiệp dịch vụ lưu trú có lớp vỏ bất động sản, và hai thứ đó có hồ sơ rủi ro rất khác nhau. Sau đó nó đề xuất một lộ trình theo giai đoạn. Thuê và vận hành một biệt thự nhỏ trong mười tám tháng đầu. Chứng minh được mình có thể vận hành phần kinh doanh cộng đồng. Sau đó mới mua đất.

Cái lật ngược của mô hình thứ ba làm tôi suy nghĩ lại. Tôi vào với tâm thế lạc quan. Tôi ra với tâm thế thận trọng hơn, nhưng cũng nắm thông tin tốt hơn. Tôi chưa đầu tư, và có thể sẽ chỉnh sửa lại ý tưởng. Nhưng lần đầu tiên tôi hiểu rõ hơn về quyết định này. Tôi hiểu các kịch bản thất bại. Tôi hiểu vì sao Hub là chỗ duy nhất thành công ở Hội An dù đã có nhiều người thử. Một cuộc trò chuyện đã giúp tôi tránh đổ vốn vào phiên bản sai của một ý tưởng tôi vốn thấy hấp dẫn.

Đây là việc tôi đang làm ngày càng nhiều hơn. Câu hỏi pháp lý trước khi gọi luật sư. Câu hỏi chiến lược trước cuộc họp ban điều hành. Câu hỏi y tế trước khi gặp bác sĩ. Bạn bè đôi lúc hỏi tôi dùng Heavy3 vào việc gì. Đó là công cụ tư vấn tôi tự xây cho mình và một nhóm nhỏ người dùng, chạy đúng cấu hình ba mô hình mà tôi vừa mô tả. Câu trả lời thật là: dùng cho những quyết định quan trọng, trong những lĩnh vực mà tôi không đủ chuyên môn để tự đi một mình. Mấy người bạn bác sĩ kể với tôi rằng ngày càng nhiều bệnh nhân của họ đến phòng khám với tâm thế đã hỏi AI về triệu chứng, đã biết các khả năng chẩn đoán, và mong bác sĩ phản hồi với những gì họ đã đọc. Trọng tâm của cuộc trò chuyện đã dịch chuyển. AI không thay thế chuyên gia. Nó thay đổi mục đích của cuộc trò chuyện với chuyên gia.

Tôi biết đây vẫn còn là một thói quen ít người có. Phần lớn mọi người dùng AI cho những việc nhỏ chứ chưa dùng cho những quyết định thật sự quan trọng. Nhưng nếu bạn là kiểu người sẵn sàng dành một buổi tối để suy nghĩ kỹ về một câu hỏi, gợi ý của tôi là hãy thử hỏi AI trước khi hỏi bất kỳ ai khác. Không phải vì câu trả lời là cuối cùng, mà vì bạn sẽ bước vào cuộc trò chuyện tiếp theo với tư thế là một người có thông tin tốt hơn, có những câu hỏi sắc sảo hơn, và hiểu rõ hơn về những gì mình cần biết.

Quyết định quan trọng gần nhất bạn dùng AI để nghiên cứu là gì? Quyết định kiểu nào bạn vẫn chưa tin AI đủ để hỏi? Tôi rất muốn nghe.

References
[1] https://heavy3.ai/share/bPe1dA8AJqOgNbjRJEWK?ref=anh

Mở đầu: Khoảnh khắc tôi biết mọi thứ đã thay đổi

Tôi gõ vào phần mềm kế toán của mình: “Phân tích doanh thu tháng 1/2026 so với cùng kỳ năm trước.”

Ba công cụ. Không có dòng code nào tôi lập trình cứng cho quy trình này.

Đầu tiên, agent tự gọi báo cáo kết quả kinh doanh tháng 1/2026. Rồi tự gọi tiếp báo cáo tháng 1/2025. Và bước thứ ba là bước khiến tôi sững lại: agent tự viết một đoạn code để tính tăng trưởng, biên lợi nhuận, và so sánh từng chỉ tiêu. Rồi trả lời: “Doanh thu thuần tăng 17%, lợi nhuận ròng tăng 20%, biên lợi nhuận cải thiện từ 90% lên 92%. Tuy nhiên chi phí quản lý tăng 43%, nhanh hơn tốc độ tăng doanh thu. Khuyến nghị: rà soát chi phí quản lý.”

Không phải template. Không phải báo cáo có sẵn. Agent đọc dữ liệu thật, viết code phân tích thật, và đưa ra nhận định mà một kế toán trưởng sẽ đưa ra. Ba công cụ, hoàn toàn tự động.

Đó là Vietbooks Agentic, phiên bản AI sắp ra mắt của phần mềm kế toán mà tôi xây dựng từ 2017 cho thị trường Việt Nam. Và đó cũng là khoảnh khắc khẳng định rõ sự khác biệt giữa chatbot và agent trong tư duy của tôi. Chatbot trả lời câu hỏi. Agent giải quyết vấn đề.

Jensen Huang tại GTC 2026: “Mọi công ty trên thế giới đều cần một chiến lược agentic AI. Đây là máy tính mới” [1]. Nhưng hiểu agent và xây agent là hai chuyện khác nhau. Theo Gartner (tháng 4/2026), 57% lãnh đạo IT thừa nhận dự án AI thất bại vì “kỳ vọng quá nhiều, quá nhanh.” Cùng khảo sát cũng chỉ ra: hiệu quả đầu tư (ROI) từ AI không đến từ model tinh vi hơn, mà từ cách công nghệ được tích hợp và gắn với nhu cầu vận hành thực tế [2].

Điều quan trọng nhất trong năm nay có lẽ là việc hiểu rõ agent hoạt động ra sao và tự tay xây dựng agent cho riêng mình. Khi bạn hiểu cơ chế bên trong, bạn biết cách tích hợp agent vào đúng quy trình vận hành của mình, thay vì kỳ vọng một “hộp đen” tự giải quyết mọi thứ. Hiểu là điều kiện tiên quyết để đạt hiệu quả đầu tư cao nhất cho bản thân và doanh nghiệp của bạn.

Trong quá trình này, tôi đã nghiệm ra một kỹ thuật phát triển agent cực kỳ hiệu quả tôi gọi là tuning surfaces. Kỹ thuật này giúp tôi xây 46 tools và 5 agents trong 3 ngày, với 303 bài test đạt 100% pass rate. Bài viết này chia sẻ toàn bộ hành trình đó. Chỉ cần biết vibe code. Nếu bạn chưa biết, hãy đọc bài trước của tôi trước.

Phần 1: Agent là gì? — Chỉ 3 thành phần

Bỏ qua mọi mỹ từ marketing, agent chỉ có 3 thứ trọng yếu:

🧠 Bộ não (LLM) là engine suy luận quyết định “làm gì tiếp theo.” Giống một nhân viên thông minh: đọc yêu cầu, nghĩ xem cần thông tin gì, rồi hành động.

🤲 Đôi tay (Tools) là các hàm mà LLM có thể gọi: tra cứu database, tìm kiếm web, gọi API, tạo báo cáo… Đây là sự khác biệt cốt lõi: chat chỉ trả lời, agent hành động.

🔄 Vòng lặp (Loop) là cơ chế giúp agent không chỉ gọi một tool rồi dừng. Nó lặp: nghĩ → hành động → quan sát kết quả → nghĩ tiếp → hành động tiếp… cho đến khi đủ thông tin để trả lời.

Agent = LLM (bộ não) + Tools (đôi tay) + Loop (vòng lặp)

Ví dụ cụ thể: user hỏi “So sánh doanh thu quý 1 năm nay với năm ngoái.” Agent nghĩ: “Cần doanh thu Q1 năm nay trước” → gọi get_revenue(Q1-2026) → nhận 500 triệu → nghĩ: “Giờ cần Q1 năm ngoái” → gọi get_revenue(Q1-2025) → nhận 420 triệu → nghĩ: “Đủ rồi, tổng hợp” → trả lời user.

Nghe đơn giản? Đúng vậy, về lý thuyết. Nhưng “con quỷ (devil) nằm trong chi tiết.” Hãy cùng đi qua hành trình xây Vietbooks Agentic, nơi tôi gặp đủ loại quỷ và tìm cách trị từng con.

Phần 2: Hành trình xây Vietbooks Agentic — Câu chuyện = Bài học

Vietbooks là phần mềm kế toán tôi xây dựng từ 2017 cho thị trường Việt Nam. Trước đây nó chỉ là công cụ ghi nhận và lên báo cáo thuần. Năm nay, tôi biến nó thành agentic: AI không chỉ trả lời mà còn hành động, tra cứu luật kế toán, tạo bút toán, phân tích tài chính, xử lý hóa đơn, hoàn toàn tự động.

Toàn bộ phần này tôi có lên kế hoạch từ lâu (cuối năm 2025), và mới đây đã xây dựng bằng vibe code với Claude Code, trong khoảng 3 ngày. Nghe khó tin? Trong kỷ nguyên AI coding, đây là tốc độ thật, nếu bạn hiểu đúng cách agent hoạt động.

🔧 Bước 1: Tool đầu tiên, và phát hiện bất ngờ

Tool đầu tiên tôi xây là get_account_rules, tra cứu quy tắc hạch toán cho một tài khoản. Ý tưởng đơn giản: user hỏi “TK 331 hạch toán thế nào?”, agent gọi tool, trả kết quả.

Mỗi tool chỉ cần 3 thứ: tên, mô tả, và danh sách tham số (chi tiết kỹ thuật ở Phụ lục B). Tôi viết mô tả đầu tiên khá qua loa: “Lấy quy tắc tài khoản kế toán.” Agent gọi đúng tool. Tuyệt vời.

Rồi tôi thêm tool thứ hai: search_regulation_knowledge, tìm kiếm quy định kế toán chung. Và mọi thứ bắt đầu hỗn loạn. Khi user hỏi “Phải trả người bán hạch toán thế nào?”, agent gọi… tool tìm kiếm chung thay vì tool tra cứu tài khoản. Sai tool, sai kết quả.

Tôi đổ lỗi cho LLM. Tôi thử model khác. Vẫn sai.

Sau một lúc debug, tôi phát hiện vấn đề: mô tả tool quá mơ hồ. LLM không biết phân biệt khi nào dùng tool nào. Tôi viết lại mô tả cho get_account_rules: thêm “Dùng khi user hỏi về cách hạch toán, Bên Nợ/Có, hoặc phương pháp kế toán của một tài khoản cụ thể.”

Lập tức agent chọn đúng tool.

Bài học đắt giá nhất: 80% lỗi agent đến từ tool description, không phải LLM kém. Tool description chính là “bản mô tả công việc” cho nhân viên AI. Viết mơ hồ thì nhân viên làm sai, không phải vì họ thiếu năng lực, mà vì bạn giao việc không rõ ràng.

🔄 Bước 2: Vòng lặp đầu tiên — “Agent nói mãi không xong”

Khi đã có 5 tools, tôi xây vòng lặp agent. Logic cốt lõi chỉ ~30 dòng code (xem Phụ lục C). Ý tưởng đơn giản: gọi LLM, nếu nó muốn gọi tool thì gọi, đưa kết quả trở lại, lặp lại cho đến khi nó trả lời text.

Chạy thử: agent gọi tool, nhận kết quả, gọi tool tiếp… rồi gọi tiếp… rồi gọi tiếp… hết 10 vòng mà chưa trả lời. Agent cứ nghĩ cần thêm thông tin. Nó không biết khi nào là “đủ.”

Giải pháp gồm hai phần. Thứ nhất, khi còn 3 vòng trở xuống, thêm một vào system prompt để nhắc agent: “⚠️ Còn 3 lượt. Hãy trả lời sớm nếu đã đủ dữ liệu.” Khi là vòng cuối: “Đây là lượt cuối, PHẢI trả lời ngay, KHÔNG gọi thêm tool.” Thứ hai, ở vòng cuối cùng, buộc agent trả lời text bằng cách set:

tool_choice: isLastRound ? "none" : "auto"

Phần nhắc nhở giúp agent tự biết “ngân sách” còn bao nhiêu và chủ động tổng hợp câu trả lời sớm. Phần tool_choice: "none" là chốt chặn cuối cùng, đảm bảo agent không thể gọi thêm tool dù muốn.

📋 Bước 3: System prompt — “Nói ĐỪNG mà nó vẫn làm”

System prompt là nơi bạn dạy agent “luật chơi”: nó là ai, biết làm gì, khi nào dùng tool nào, trả lời thế nào.

Tôi viết: “Không xử lý hóa đơn điện tử trong phần chat.” Vì phần này tôi đã có quy trình xử lý tự động tối ưu. Yêu cầu vậy là quá rõ ràng, đúng không?

Thế nhưng agent vẫn cố xử lý hóa đơn. Tôi viết mạnh hơn: “KHÔNG nên xử lý hóa đơn.” Nó vẫn tiếp tục vi phạm.

Cuối cùng, tôi viết: “DỪNG NGAY. KHÔNG gọi bất kỳ tool nào. Trả lời: ‘Vui lòng sử dụng chức năng nhập hóa đơn.’” Agent tuân thủ 100%.

Bài học: LLM xử lý chỉ dẫn tích cực mạnh hơn nhiều so với phủ định. “Đừng làm X” yếu hơn “Làm Y thay vì X.” Đây là đặc điểm của mọi LLM, không riêng model nào.

🚦 Bước 4: Một agent không đủ — Router pattern

Khi số tools tăng lên 46 để hỗ trợ đầy đủ các chức năng, một agent duy nhất bắt đầu “choáng ngợp”: system prompt dài, chọn sai tool vì quá nhiều lựa chọn, và mỗi request tốn thêm nhiều token.

Giải pháp: tôi tách agent này thành nhiều agent chuyên biệt, điều phối bởi một RouterAgent, giống tổng đài viên phân loại cuộc gọi rồi chuyển đến đúng bộ phận. Đây cũng là kỹ thuật tôi rất thích và học được khi dùng Claude Code: agent chính dùng nhiều sub-agents để phân tích code song song, vừa nhanh vừa hiệu quả.

RouterAgent của tôi phân loại mỗi tin nhắn và quyết định: tự trả lời hay chuyển cho sub-agent chuyên biệt.

Điểm quan trọng: RouterAgent không chỉ phân loại rồi chuyển tiếp. Với câu hỏi đơn giản (chat, tra cứu 1 báo cáo, hỏi số dư), RouterAgent tự trả lời chỉ với 1-2 tool calls, không cần chạy sub-agent. Chỉ khi cần xử lý phức tạp (tìm kiếm web, tạo bút toán, phân tích sâu) mới chuyển cho sub-agent. Điều này giúp phản hồi nhanh hơn và tiết kiệm token cho các câu hỏi thường gặp.

Hơn nữa, mỗi sub-agent chỉ giải quyết vấn đề chuyên môn của mình (loại prompt riêng), và thấy tools của riêng mình. Không agent nào bị “phân tâm” bởi tools của agent khác.

• AnalysisAgent thấy 22 tools bao gồm 17 tool kế toán, web search, và đặc biệt là code_exec (tool cho phép agent tự viết code phân tích, chính là bước thứ ba ở đầu bài).

• EntryAgent thấy 33 tools cho tạo bút toán, xử lý hóa đơn, quản lý đối tượng và 1 tool để dùng KnowledgeAgent. Đây cũng là pattern đơn giản mà hiệu quả tôi phát hiện: sub-agent có thể chỉ là một tool nội bộ. Không cần framework, không cần message bus. Agent chính gọi sub-agent giống gọi một hàm bình thường: truyền câu hỏi vào, nhận text ra.

💡 Router call chỉ tốn ~300 token và ~0.3 giây, rẻ hơn nhiều so với gửi 46 tool descriptions trong mỗi request. Khi agent có hơn 10 tools, hãy nghĩ đến Router.

🎯 Bước 5: Tuning Surfaces — Kỹ thuật then chốt để vibe code agent thành công

Đây là kỹ thuật quan trọng nhất trong toàn bộ bài viết, và tôi chưa thấy ai chia sẻ cách tiếp cận này.

Xây agent không giống xây phần mềm thông thường. Với code truyền thống, test fail thì bạn biết chính xác dòng code nào sai. Với agent, bạn viết system prompt, đưa tools, và model tự quyết định làm gì. Câu hỏi không phải “hàm này có chạy đúng không?” (đó là code thuần, test bình thường). Câu hỏi là: “Khi user nói ‘chi 5 triệu mua văn phòng phẩm’, model có chọn đúng tool(s) với đúng tham số không?”

Khi mới test agent, mỗi lần test fail tôi lại đoán: “Model kém? Prompt chưa rõ? Tool description sai?” Rồi thử sửa hết chỗ này đến chỗ khác. Mất hàng giờ và quan trọng hơn là rất khó để tự động hóa hoàn toàn để “vibe code”.

Sau nhiều lần, tôi đúc kết cho mình một kỹ thuật riêng (và đây cũng là một khái niệm đã có từ ML evaluation): tuning surfaces. Ý tưởng: test phải được thiết kế sao cho mỗi test failure phải map đến đúng MỘT “surface”, một nơi cụ thể để sửa. Không đoán mò. Mỗi test mang theo hai thông tin: tuningSurface (sửa CÁI GÌ) và fixHint (sửa NHƯ THẾ NÀO).

Test fail → check tuningSurface → biết sửa CÁI GÌ
→ check fixHint → biết sửa NHƯ THẾ NÀO
→ sửa → chạy lại → verify

Tôi hệ thống hóa thành 5 surfaces chính (bảng đầy đủ ở Phụ lục D):

• Agent gọi sai tool? → PROMPT_TOOL_SELECTION: thêm mapping “Khi hỏi X → dùng Y” vào system prompt

• Agent gọi đúng tool nhưng sai thứ tự? → PROMPT_WORKFLOW: đánh số bước trong prompt

• Agent không hiểu tool làm gì? → TOOL_DESCRIPTION: viết lại mô tả tool

• Agent truyền sai tham số? → TOOL_PARAMS: thêm ví dụ vào parameter description

• Agent trả lời đúng nhưng sai format? → PROMPT_ANSWER_FORMAT: thêm template trả lời

Ví dụ thực tế: 0 → 100% trong 3 lần chạy

Khi tôi thêm một nhóm tools mới để mở canvas và trình bày artifact (báo cáo tài chính, bút toán nháp), toàn bộ 16 test mới fail. Agent trả lời bằng text thay vì gọi tool. Nếu không có tuning surfaces, tôi sẽ ngồi đoán: prompt sai? Model kém? Tool description chưa rõ?

Nhưng triệu chứng “agent không gọi tool” chỉ tôi kiểm tra hai chỗ theo thứ tự: đầu tiên là mảng tools[] gửi cho LLM, sau đó là system prompt. Hóa ra tôi quên đăng ký nhóm tools mới vào mảng tools[]. LLM không thấy tools thì đương nhiên không gọi. Sửa một dòng import, chạy lại: 10/16 pass.

6 test còn lại fail vì triệu chứng tương tự nhưng nguyên nhân khác: system prompt thiếu trigger keywords. User nói “tải về file Excel” nhưng agent hiểu đó là câu hỏi chung, không phải yêu cầu hành động. Thêm mapping cụ thể vào system prompt: "xuất dữ liệu", "export", "tải về Excel" → dùng request_data_export. Chạy lại: 16/16. Ba lần chạy, mỗi lần biết chính xác sửa ở đâu.

Trong quá trình phát triển Vietbooks Agentic, tôi chạy 20 lần tuning iterations trên tất cả agents, mỗi lần tôi đều biết chính xác sửa ở đâu. Không một lần đoán mò.

🧪 Bước 6: Test — “Đo được thì cải thiện được”

Tôi xây kim tự tháp test 3 tầng cho agent (chi tiết ở Phụ lục E):

• Tầng 1, Unit test: Test logic thuần, không cần LLM. $0, chạy trong 0.25 giây.

• Tầng 2, Tool selection: Chỉ kiểm tra LLM có gọi đúng tool không. ~$0.01/test. Bắt được 80% lỗi với 5% chi phí.

• Tầng 3, Full E2E: Chạy toàn bộ agent loop, kiểm tra kết quả cuối. ~$0.05-0.10/test.

Kết quả: 303 bài LLM test + 709 unit test, 100% pass rate, tổng chi phí test: $12.47, ít hơn một ly cà phê.

Phần 3: Bắt đầu xây agent của bạn

Bạn không cần 46 tools và 5 agents để bắt đầu. Vietbooks Agentic bắt đầu từ đúng 1 tool và 1 vòng lặp. Và nhớ: bạn đang vibe code, không cần tự gõ từng dòng. Hãy copy code ở Phụ lục C vào Cursor/Claude Code và bảo AI: “Hãy dựa trên cấu trúc vòng lặp này, tạo cho tôi một agent thực hiện [tác vụ của bạn].” Nhờ tuning surfaces, AI sẽ tự debug lỗi cho bạn. Với GLM 5.1 hoặc Gemma 4, chi phí thử nghiệm gần như bằng 0.

Đây là các bước cụ thể:

⚙️ Setup: Tạo tài khoản OpenRouter (một API, hàng chục model). Chọn model hỗ trợ tool calling: GLM 5.1 cho chi phí thấp với chất lượng cao, hoặc Gemma 4 nếu muốn rẻ nhất. Backend: Node.js hoặc Python.

🔧 Tool đầu tiên: Chọn một tác vụ đơn giản bạn muốn agent làm: tra cứu sản phẩm, query database, tìm kiếm web. Viết mô tả tool rõ ràng với “Dùng khi user hỏi về…”

🔄 Agent loop: Tôi đã cung cấp đoạn code cốt lõi (vòng lặp 30 dòng) ở Phụ lục C. Nó là tất cả những gì bạn cần. Hãy copy nó vào dự án của bạn, thay executeToolCall bằng hàm xử lý tool của bạn. Nhớ set max rounds và force answer ở round cuối.

📋 System prompt: 3 phần: context, quy tắc chọn tool, format trả lời. Ngắn gọn, cụ thể, rõ ràng.

🧪 Test + Tuning Surfaces: Prompt cho AI: “Hãy thiết kế test cho mỗi tool. Mỗi test phải có tuningSurface và fixHint rõ ràng. Chạy test và sửa cho đến khi tất cả pass.” Nhờ tuning surfaces, AI sẽ tự biết sửa ở đâu khi test fail.

Khi nó hoạt động, và nó sẽ hoạt động, bạn sẽ trải nghiệm đúng khoảnh khắc mà tôi mô tả ở đầu bài.

🔒 Bảo mật

Các cảnh báo an toàn ở bài Vibe Code vẫn áp dụng, cộng thêm:

• Giới hạn max rounds và token budget: Agent không có giới hạn sẽ gọi tool mãi mãi, đốt tiền API của bạn.

• Cẩn thận với tools có tác động lớn: Không nên cho agent tool xóa dữ liệu hoặc thực hiện giao dịch không thể hoàn tác (undo). Trong Vietbooks, agent chỉ tạo bản nháp, người dùng phải phê duyệt trước khi ghi sổ.

• Loại bỏ trường nhạy cảm ở tầng database: Khi tool query database, dùng projection để loại trường password, API token, v.v. Agent không bao giờ nhìn thấy dữ liệu nhạy cảm.

Kết luận: Personalized Agent, siêu năng lực mới

Context, Tool Management đề cập bên trên là 2 trong 4 kỹ thuật quan trọng để phát triển và vận hành agent, gọi chung là Harness Engineering (cách “cầm cương” AI agent). Bài viết tiếp theo tôi sẽ đi vào 2 trụ cột còn lại: Memory và Sandbox.

Sau khi hiểu cách agent hoạt động, cộng với kỹ thuật Tuning Surfaces, nếu bạn biết vibe code, bạn sẽ có thể vibe code agent. Agent hiểu nghiệp vụ của bạn, nói ngôn ngữ của bạn, làm việc 24/7. Đó là siêu năng lực mới trong kỷ nguyên AI.

Bạn đang xây agent cho lĩnh vực gì? Gặp vấn đề gì? Chia sẻ ở phần bình luận nhé!

Nếu bạn chưa biết vibe code, hãy đọc bài hướng dẫn vibe code để bắt đầu. Nếu muốn hiểu sâu về RAG, một loại tool quan trọng cho agent, hãy đọc bài về cách tôi xây agent tra cứu luật kế toán.

Tài liệu tham khảo

[1] Jensen Huang. NVIDIA GTC 2026 Keynote. March 2026.

https://www.nvidia.com/gtc/keynote/

[2] Gartner. “Gartner Says AI Projects in I&O Stall Ahead of Meaningful ROI Returns.” April 7, 2026.

https://www.gartner.com/en/newsroom/press-releases/2026-04-07-gartner-says-artificial-intelligence-projects-in-infrastructure-and-operations-stall-ahead-of-meaningful-roi-returns

Phụ lục

A. Các model khuyên dùng cho agent (tháng 4/2026)

Chất lượng cao (closed-source):

• Claude Sonnet 4.6 — cân bằng tốt giữa chất lượng và chi phí

• GPT-5.4 — native computer use, 1M context

• Gemini 3.1 Pro — reasoning mạnh, 1M context, output dài (65K tokens)

• Claude Opus 4.6 — tốt nhất cho tác vụ phức tạp (nhưng đắt)

Mã nguồn mở:

• GLM 5.1 — #1 SWE-Bench Pro, hiệu suất gần Opus với 1/8 chi phí. MIT license. Đây là model tôi dùng cho Vietbooks Agentic.

• Qwen 3.6 Plus — multimodal (vision + text), hiệu suất gần GLM 5.1. Tốt cho agent cần xử lý hình ảnh.

• Gemma 4 — rẻ nhất, Apache 2.0 license. Phù hợp để bắt đầu và fine-tune sau.

Truy cập: OpenRouter cho phép dùng tất cả model trên qua một API duy nhất.

B. Cấu trúc Tool — Chi tiết kỹ thuật

Mỗi tool là một object JSON theo chuẩn function calling. Ví dụ thực tế từ Vietbooks:

{
  name: "get_account_balance",
  description: "Lấy số dư tài khoản theo mã tài khoản hoặc đầu mã "
    + "(VD: '111' cho tiền mặt, '131' cho phải thu khách hàng). "
    + "Trả về tổng nợ, tổng có và số dư.",
  parameters: {
    type: "object",
    properties: {
      account_prefix: {
        type: "string",
        description: "Mã tài khoản hoặc đầu mã (VD: '111', '131', '331')"
      },
      start_date: {
        type: "string",
        description: "Ngày bắt đầu (YYYY-MM-DD), bỏ qua để lấy từ đầu"
      },
      end_date: {
        type: "string",
        description: "Ngày kết thúc (YYYY-MM-DD), bỏ qua để lấy đến hiện tại"
      }
    },
    required: ["account_prefix"]
  },
  execute: async (args, context) => {
    // Query MongoDB, tính tổng nợ/có/dư, trả về kết quả
  }
}

Quy tắc vàng khi viết tool:

• Mỗi tool làm MỘT việc duy nhất

• Mô tả phải nói rõ khi nào dùng tool này, kèm ví dụ cụ thể

• Tham số phải có description kèm format và ví dụ (VD: “YYYY-MM-DD”)

C. Agent Loop — Code hoàn chỉnh

Đây là phiên bản đơn giản hóa từ BaseAgent thực tế của Vietbooks:

async function runAgent(userMessage: string, tools: Tool[], systemPrompt: string) {
  const messages = [
    { role: "system", content: systemPrompt },
    { role: "user", content: userMessage }
  ];
  const MAX_ROUNDS = 10;

  for (let round = 0; round < MAX_ROUNDS; round++) {
    const isLastRound = round === MAX_ROUNDS - 1;
    const remaining = MAX_ROUNDS - round;

    // Nhắc agent còn bao nhiêu lượt khi gần hết
    if (round > 0 && remaining <= 3) {
      messages.push({
        role: "system",
        content: isLastRound
          ? "⚠️ Đây là lượt cuối — PHẢI trả lời ngay, KHÔNG gọi thêm tool."
          : `⚠️ Còn ${remaining} lượt. Hãy trả lời sớm nếu đã đủ dữ liệu.`
      });
    }

    // Gọi LLM (force text ở round cuối)
    const response = await callLLM({
      model: "openrouter/glm-5.1",
      messages,
      tools,
      tool_choice: isLastRound ? "none" : "auto"
    });

    // Nếu LLM trả lời text → xong
    if (response.content && !response.tool_calls) {
      return response.content;
    }

    // Nếu LLM muốn gọi tool → thực thi
    if (response.tool_calls) {
      messages.push(response); // Lưu lệnh gọi tool vào lịch sử

      for (const toolCall of response.tool_calls) {
        const result = await executeToolCall(toolCall); // Gọi hàm thật
        messages.push({
          role: "tool",
          tool_call_id: toolCall.id,
          content: JSON.stringify(result)
        });
      }
    }
  }

  return "Xin lỗi, tôi không thể hoàn thành yêu cầu này.";
}

Giải thích từng phần:

• messages: lịch sử hội thoại, bao gồm cả tool calls và kết quả

• Round budget warning: khi còn ≤3 lượt, thêm tin nhắn vào system prompt nhắc agent tổng hợp câu trả lời. Giúp agent chủ động dừng sớm thay vì gọi tool đến lượt cuối

• tool_choice: "auto": LLM tự quyết định gọi tool hay trả lời

• tool_choice: "none": chốt chặn cuối cùng, buộc LLM trả lời text

• executeToolCall: hàm thực thi tool thật (query database, gọi API, v.v.)

D. Tuning Surfaces — Bảng tra cứu đầy đủ

• PROMPT_TOOL_SELECTION — Agent gọi sai tool → Thêm mapping vào system prompt. Ví dụ: “Khi hỏi TK cụ thể → get_account_rules“

• PROMPT_WORKFLOW — Đúng tool, sai thứ tự → Đánh số bước trong prompt. Ví dụ: “BƯỚC 1: kiểm tra corrections. BƯỚC 2: tìm template.”

• TOOL_DESCRIPTION — Agent không hiểu tool → Viết lại mô tả, thêm “Dùng khi…” Ví dụ: “Dùng khi user hỏi về một tài khoản cụ thể”

• TOOL_PARAMS — Truyền sai tham số → Thêm ví dụ vào description. Ví dụ: “account_code: ‘131’, ‘331’, ‘511’”

• PROMPT_ANSWER_FORMAT — Đúng nội dung, sai format → Thêm template. Ví dụ: “Trả lời gồm: Bên Nợ, Bên Có, ví dụ”

Red flags:

• Tất cả test fail “no tool called” → Tool chưa nằm trong mảng tools[]

• Agent trả lời quá ngắn hoặc hết max rounds → Thiếu tool_choice: "none" ở round cuối

• Agent dùng sai dữ liệu → Kiểm tra thứ tự bước trong prompt

E. Thống kê Vietbooks Agentic

• Tools xây dựng: 46 (17 accounting, 5 entry, 4 template, 4 invoice, 2 search, …)

• Agents: 5 (Router, Entry, Knowledge, Analysis, General)

• LLM tests: 303 (71 knowledge, 94 entry, 68 analysis, 30 router, 40 E2E)

• Unit tests: 709

• Pass rate: 100%

• Tổng chi phí test: $12.47

• Tuning iterations: 20

• System prompt (tổng): 11.300 ký tự

• Thời gian xây dựng: ~3 ngày (vibe code với Claude Code)

Kim tự tháp test chi tiết:

• Tầng 1, Unit: 709 tests, 0.25 giây, $0. Test logic thuần (phân loại tài khoản, validate, tạo mã).

• Tầng 2, Tool Selection (Tier A): 1 LLM call/test, ~$0.01. Kiểm tra: đúng tool, đúng tham số. 80% lỗi bắt ở đây.

• Tầng 3, Full E2E (Tier B): Multi-round, ~$0.05-0.10/test. Tool chains, workflow compliance, kết quả cuối.

Ba tôi làm kế toán. Trên bàn làm việc của ông luôn có 2 cuốn sách dày cộp: chế độ kế toán doanh nghiệp và hệ thống tài khoản kế toán theo Thông tư 200/2014/TT-BTC. Hai quyển hơn 1500 trang.

Mỗi khi gặp một tài khoản ít dùng — “TK 244 Cầm cố, thế chấp, ký cược, ký quỹ hạch toán thế nào nhỉ?” — ông lại giở cuốn sách ra, tìm đến phần Hệ thống tài khoản, lật đến đúng trang, đọc hướng dẫn Bên Nợ ghi gì, Bên Có ghi gì. Mỗi lần tra cứu mất vài phút. Nhưng luôn chính xác, vì nguồn là văn bản gốc.

Tôi là dân công nghệ, không phải kế toán. Nên khi bắt đầu phát triển phần mềm kế toán Vietbooks thì tôi Google thay vì lật sách. Gõ “TK 331 hạch toán” là ra hàng loạt trang kế toán như ketoanthienung, thuvienphapluat, v.v… Các trang này về cơ bản trích lại nguyên văn nội dung Thông tư rồi đăng lên web. Nhanh hơn lật sách, nhưng vẫn phải đọc, phải tự chắt lọc, và đôi khi thông tin cũ hoặc trích không đầy đủ.

Giờ là kỷ nguyên AI. Và câu hỏi đặt ra: liệu AI có thể tra cứu chính xác như lật sách, nhưng nhanh như Google, và còn hiểu ngữ cảnh câu hỏi để trả lời đúng trọng tâm?

Câu trả lời là có — nếu bạn xây đúng cách. Đây là câu chuyện về cách tôi đưa toàn bộ 5 Thông tư kế toán Việt Nam vào AI, để nó trả lời chính xác 100% bộ test, trong khoảng 1 giây, với chi phí mỗi truy vấn chưa đến 0,1 đồng.

Và quan trọng hơn: đây không chỉ là công cụ tra cứu. Đây là viên gạch đầu tiên trong hành trình biến Vietbooks thành phần mềm kế toán agentic — nơi AI không chỉ trả lời mà còn hành động.

Trong bài viết trước, tôi đã chia sẻ tầm nhìn về Vietbooks Agentic và cách các mô hình AI mã nguồn mở đã đủ mạnh cho nghiệp vụ kế toán phức tạp. Hôm nay Vietbooks Agentic sắp ra mắt. Trong loạt bài này tôi sẽ chia sẻ cách mình xây Vietbooks Agentic như thế nào.

1. Agent kiến thức (bài này) — tra cứu chính xác quy định từ 5 Thông tư kế toán

2. Agent hạch toán (bài tiếp) — tự động tạo bút toán từ mô tả hoặc hóa đơn

3. Agent phân tích (bài cuối) — phân tích kinh doanh, xu hướng, chỉ số tài chính

Tại sao agent kiến thức phải đi trước? Vì muốn AI tạo bút toán đúng, nó phải hiểu quy định đúng trước, để giảm thiểu ảo giác (hallucination).

Bài toán

Vietbooks hỗ trợ 5 chế độ kế toán Việt Nam: TT200/2014, TT99/2025, TT133/2016, TT132/2018, TT152/2025. Mỗi Thông tư là một hệ thống hoàn chỉnh — giống 2 quyển sách trên bàn ba tôi, nhưng nhân lên 5 lần:

• Điều khoản pháp lý (phạm vi, hiệu lực, quy định chung)

• Hướng dẫn hạch toán cho ~200 tài khoản kế toán (Bên Nợ/Có, phương pháp, ví dụ)

• Hơn 300 mẫu báo cáo, sổ sách, chứng từ (với bảng biểu phức tạp)

Tổng cộng nhiều nghìn trang. Tôi cần AI agent trả lời được các câu hỏi như:

• “TK 331 phải trả người bán hạch toán thế nào theo TT133?”

• “Mẫu sổ quỹ tiền mặt gồm những cột nào?”

• “So sánh quy định hàng tồn kho giữa TT133 và TT200”

Nguồn tài liệu gốc: file .doc (Word 97), một số có Phụ lục nhúng OLE bên trong. Không thể đọc trực tiếp.

Các hướng tiếp cận

Trước khi bắt tay vào làm, tôi nghiên cứu 3 hướng:

1. RAG thông thường (chunking 500 token → embedding → tìm kiếm)

Đơn giản nhất nhưng ai cũng biết vấn đề: chunking (cắt đoạn) bừa bãi phá nát cấu trúc tài liệu, mất ngữ cảnh, kết quả tìm kiếm thiếu chính xác.

2. Chỉ mục phân cấp (Hierarchical Index)

Xây cây cấu trúc từ tài liệu rồi truy vấn theo cây. Có 2 biến thể chính:

• RAPTOR [1] (Stanford, ICLR 2024) — dùng LLM để tóm tắt và xây cây khi indexing, rồi dùng embedding similarity tại mỗi tầng cây khi truy vấn. Vẫn là vector search nhưng tổ chức phân cấp.

• PageIndex [2] (VectifyAI) — dùng LLM để suy luận và duyệt cây. Không cần vector nhưng mỗi truy vấn tốn thêm LLM calls.

Ưu điểm chung: giữ nguyên cấu trúc tài liệu, lấy được nguyên nội dung gốc. Nhược điểm: phức tạp hơn để xây và bảo trì, tốn thêm chi phí tại thời điểm xây và truy vấn.

3. Structure-aware chunking + Tìm kiếm vector + Lọc metadata

Cắt theo đơn vị ngữ nghĩa tự nhiên (Điều, tài khoản, mẫu báo cáo), gắn metadata phong phú, dùng bộ lọc metadata kết hợp tìm kiếm vector. Đơn giản, nhanh, rẻ.

Tôi chọn hướng 3. Lý do: hạ tầng đã có sẵn (MongoDB, Gemini API), chi phí thấp nhất, và quan trọng nhất — nếu chunking đúng từ đầu, bạn không cần duy trì cây cấu trúc phức tạp phía sau.

Mỗi hướng có ưu nhược riêng. Hierarchical Index rất hay cho tài liệu siêu dài cần suy luận sâu. Nhưng với văn bản luật có cấu trúc rõ ràng (Điều/Khoản/Phụ lục), structure-aware chunking đủ tốt mà đơn giản hơn nhiều.

Thiết kế chunking: 7 loại, mỗi loại có bộ phát hiện riêng

Bước quan trọng nhất — và tốn thời gian nhất — là thiết kế chiến lược chunking. Tôi dành ~80% công sức ở đây.

Nguyên tắc: Mỗi đoạn = một đơn vị ngữ nghĩa hoàn chỉnh

Không cắt theo số lượng token. Mỗi đoạn phải là một đơn vị mà kế toán viên đọc hiểu được mà không cần thêm ngữ cảnh bên ngoài.

Tôi phân loại nội dung thành 7 loại chunk, mỗi loại có bộ phát hiện (detector) riêng dựa trên pattern khác nhau. Chi tiết và thứ tự ưu tiên bên dưới.

Tiền tố ngữ cảnh — mỗi đoạn tự mô tả vị trí

Đây là kỹ thuật đơn giản nhưng cực kỳ hiệu quả: trước khi lưu mỗi chunk, tôi prepend (chèn vào đầu) một dòng ngữ cảnh được ghép từ các biến đã có sẵn trong quá trình parsing:

// Code thực tế trong pipeline:
const  content = `${config.name}, ${currentChapter}, Điều ${section.dieuNum}: ${section.title}\n\n${articleText}`;

Kết quả, mỗi chunk bắt đầu bằng:

Thông tư 133/2016/TT-BTC, Chương II, Điều 40: Tài khoản 331 - Phải trả cho người bán, Khoản 2
[Nội dung thực tế của đoạn...]

Khi LLM nhận được chunk này từ kết quả tìm kiếm, nó biết ngay đoạn này thuộc Thông tư nào, Chương nào, Điều nào, nói về tài khoản gì — mà không cần tra cứu thêm. Dòng tiền tố này cũng giúp LLM trích dẫn nguồn chính xác trong câu trả lời.

(Tôi xây dựng toàn bộ hệ thống này cùng với Claude Code — tôi hiểu domain kế toán và kiến trúc code, Claude code chính xác, kết hợp lại nhanh gấp 4-5 lần.)

Ưu tiên theo giá trị sử dụng

Không phải nội dung nào cũng quan trọng như nhau. Tôi sắp xếp thứ tự trích xuất theo tần suất kế toán viên thực sự cần tra cứu:

1. Quy tắc tài khoản (account_rule) — ưu tiên cao nhất. Đây là nội dung ba tôi lật sách tìm hàng ngày: “TK 331 Bên Nợ ghi gì, Bên Có ghi gì, phương pháp hạch toán ra sao.” Mỗi tài khoản là một chunk hoàn chỉnh gồm nguyên tắc, kết cấu, và ví dụ.

2. Mẫu báo cáo (report_template) — Bảng cân đối kế toán, sổ quỹ tiền mặt, phiếu nhập kho… với toàn bộ cấu trúc bảng biểu được giữ nguyên dưới dạng markdown.

3. Hướng dẫn ghi chép (usage_guide) — “Mục đích của mẫu này là gì? Cách ghi từng cột ra sao?” Thông tin này rất quan trọng khi kế toán viên gặp mẫu chứng từ lạ.

4. Và Hình thức kế toán (accounting_system), Danh mục tài khoản (account_chart), Điều khoản (article), Phần còn lại (general).

Thứ tự trích xuất (quan trọng)

Mẫu báo cáo trải dài nhiều đoạn văn + bảng biểu, nên phải trích xuất trước. Nếu trích tài khoản trước, bạn sẽ cắt mất bảng biểu nằm trong mẫu báo cáo. Thứ tự:

Tách theo Điều → Trích mẫu báo cáo → Quy tắc tài khoản → Hướng dẫn ghi chép
→ Hình thức kế toán → Danh mục tài khoản → Catch-all phần còn lại

Bộ catch-all cuối cùng chỉ xử lý phần chưa ai đụng đến — đảm bảo không sót, không trùng.

Quy trình lặp: chunking không phải làm một lần là xong

Đây là phần tôi muốn nhấn mạnh nhất: tôi không viết chunking pipeline một lần rồi deploy. Tôi lặp đi lặp lại nhiều vòng, mỗi vòng kiểm tra kỹ hơn.

Vòng 1: Chỉ hỗ trợ 4 loại chunk (article, account_rule, report_template, general). Kết quả: 1.411 chunk, 3,3 triệu ký tự. Trông ổn.

Vòng 2 — Phát hiện mất nội dung: Tôi so sánh tổng ký tự chunk với tổng ký tự nguồn và phát hiện TT99 mất ~82.000 ký tự — toàn bộ phần hướng dẫn ghi chép chứng từ (67 mục “Mục đích + Phương pháp”) và 5 phần mô tả hình thức kế toán bị bỏ qua hoàn toàn. Thêm 3 loại chunk mới: usage_guide, accounting_system, account_chart.

Vòng 3 — Rà soát code: Phát hiện bộ catch-all có lỗi regex — khi cố loại bỏ nội dung đã trích xuất, regex vô tình nuốt luôn mọi thứ sau quy tắc tài khoản cuối cùng trong tài liệu, mất ~110.000 ký tự. Sửa regex và thêm cơ chế tách đoạn thay vì cắt cụt nội dung dài.

Kết quả sau 3 vòng: 1.926 chunk, 5,82 triệu ký tự — tăng 76% so với vòng 1. TT132 cải thiện đặc biệt rõ: từ 27 chunk lên 85 chunk khi cuối cùng trích xuất được quy tắc tài khoản và hướng dẫn từ Phụ lục.

Kiểm tra bằng số: đếm ký tự

Sau mỗi vòng, tôi chạy script so sánh:

Tổng ký tự nguồn (text) vs Tổng ký tự các chunk

Nếu tỷ lệ < 0.95, nghĩa là đang mất nội dung. Đây là cách duy nhất để phát hiện các lỗi “im lặng” — regex nuốt text mà không báo lỗi.

Ngoài ra, tôi viết một script test riêng (test-chunks-output.ts) để in tất cả chunk ra console kèm preview 300 ký tự đầu. Chạy từng Thông tư, đọc lướt preview, kiểm tra xem có chunk nào bị cắt giữa chừng hoặc thiếu ngữ cảnh không.

Bài học: Chunking cho văn bản luật giống debug hơn là code. Bạn phải chạy, đọc output, phát hiện vấn đề, sửa, chạy lại. Đừng tin vào lần đầu tiên.

Metadata biến mỗi chunk thành “trang sách có đánh dấu”

Mỗi chunk không chỉ là đoạn text + embedding vector. Nó mang theo metadata phong phú — giống như mỗi trang sách được đánh dấu bằng tab màu: Thông tư nào, loại gì, tài khoản nào, mẫu báo cáo nào.

Toàn bộ chunk — nội dung, metadata, và embedding vector — được lưu trữ cùng nhau trong một document MongoDB duy nhất:

// Mỗi document trong collection regulation_chunks:
{
circular: 133, // → Thông tư nào
circular_name: 'Thông tư 133/2016/TT-BTC',
content_type: 'account_rule', // → loại nội dung (1 trong 7 loại)
account_code: '331', // → mã tài khoản (nếu có)
report_code: null, // → mã mẫu báo cáo (nếu có)
chapter: 'Chương II', // → vị trí trong cấu trúc
article: 40, // → số Điều
content: '...', // → nội dung text (đã prepend ngữ cảnh)
embedding: [0.012, -0.034, ...], // → vector 3072 chiều cho tìm kiếm ngữ nghĩa
}

Tôi chọn MongoDB vì hạ tầng Vietbooks đã dùng MongoDB, nhưng thiết kế này hoàn toàn độc lập — bạn có thể dùng PostgreSQL (với pgvector) hay bất kỳ database nào hỗ trợ lưu vector kèm metadata. Điều quan trọng là metadata và embedding nằm cùng một chỗ — cho phép lọc metadata trước rồi mới tính cosine similarity, thay vì tìm trong toàn bộ database.

Metadata này là chìa khóa để biến RAG từ “tìm đại” thành “tìm đúng.” Nó cho phép 2 kiểu truy vấn hoàn toàn khác nhau:

Kiểu 1 — Tra cứu trực tiếp (không cần vector search):

db.find({circular: 133, account_code: '331'})
→ Trả về TẤT CẢ chunk về TK 331 theo TT133

Nhanh, chính xác 100%, chi phí = 0 (chỉ là một truy vấn database thông thường).

Kiểu 2 — Tìm kiếm vector có lọc:

query: "Mẫu sổ quỹ tiền mặt gồm những cột nào?"
filter: {circular: 133, content_type: 'report_template'}
→ Embedding câu hỏi → vector 3072 chiều
→ Chỉ tìm trong ~84 chunk mẫu báo cáo của TT133 (thay vì 1.926 chunk toàn bộ)
→ Tính cosine similarity → trả về top 5 chunk liên quan nhất

Chính xác hơn nhiều so với tìm trong toàn bộ 1.926 chunk, vì không gian tìm kiếm nhỏ hơn 20 lần.

Hai công cụ cho AI agent: mỗi câu hỏi một cách tìm

Metadata phong phú cho phép tôi thiết kế 2 công cụ (tool) riêng biệt cho AI agent, mỗi công cụ tối ưu cho một kiểu câu hỏi.

Công cụ 1: get_account_rules — tra cứu trực tiếp

Khi người dùng hỏi “TK 331 hạch toán thế nào?” — đây là truy vấn chính xác. AI không cần tìm kiếm ngữ nghĩa, chỉ cần tra metadata:

Input: account_code = "331"
Query: db.find({circular: 133, content_type: 'account_rule', account_code: '331'})
Output: Tất cả chunk về TK 331 — nguyên tắc, kết cấu Nợ/Có, phương pháp hạch toán

Không cần embedding. Không cần cosine similarity. Chỉ là một truy vấn MongoDB bình thường. Chính xác 100%, chi phí 0 đồng.

Công cụ 2: search_regulation_knowledge — tìm kiếm ngữ nghĩa

Khi người dùng hỏi “Quy định về chế độ chứng từ kế toán” — không có trường metadata nào khớp trực tiếp. Đây mới là lúc tìm kiếm vector phát huy tác dụng:

Input: query = "chế độ chứng từ kế toán", circular = 133
Step 1: Embedding câu hỏi → vector 3072 chiều (Gemini API, ~0,1 đồng)
Step 2: Lọc metadata: chỉ lấy chunk có circular = 133
Step 3: Tính cosine similarity → trả về top 5 chunk liên quan nhất

AI agent cũng có thể lọc thêm theo content_type, account_code, hoặc report_code — tùy thuộc ngữ cảnh câu hỏi.

AI tự chọn công cụ nào?

AI agent (Gemma 4 31B) được hướng dẫn qua system prompt với quy tắc rõ ràng:

- Câu hỏi nhắc đến MÃ TÀI KHOẢN (111, 331, 511...) → get_account_rules
- Câu hỏi nhắc TÊN tài khoản ("phải trả người bán") → get_account_rules (tra bảng tên → mã)
- Câu hỏi chung về quy định, mẫu báo cáo, hướng dẫn → search_regulation_knowledge
- LUÔN dùng công cụ trước khi trả lời — KHÔNG BAO GIỜ trả lời từ kiến thức chung

Quy tắc cuối cùng rất quan trọng: nó buộc AI phải tra cứu thực tế thay vì “sáng tác” từ kiến thức huấn luyện — giống như kế toán viên phải mở sách ra xem chứ không được đoán.

Đánh giá và chi phí

Kết quả

Sau 3 vòng lặp, hệ thống xử lý 1.926 chunk từ 5 Thông tư (5,82 triệu ký tự). Tôi viết 2 bộ test tự động:

Bộ test RAG (23 test): Kiểm tra tìm kiếm vector có trả về đúng chunk không — bao phủ tất cả 7 loại nội dung, cả 5 Thông tư. Kết quả: 23/23 — chunk đúng ở vị trí đầu tiên trong 100% trường hợp.

Bộ test Agent (73 test): Kiểm tra Gemma 4 31B có chọn đúng công cụ với đúng tham số không — từ tra cứu tài khoản cụ thể đến câu hỏi chung về quy định. Mỗi test thất bại chỉ trực tiếp đến chỗ cần sửa trong system prompt, cho phép lặp nhanh: chạy test → đọc chẩn đoán → sửa → chạy lại. (Chi tiết phân loại test trong Phụ lục.)

Chi phí vận hành

Chi phí phần truy xuất khi người dùng hỏi “TK 331 hạch toán thế nào?”: khoảng 0,1 đồng cho embedding câu hỏi, 0 đồng cho truy vấn MongoDB. Nghĩa là 1 triệu truy vấn chỉ tốn khoảng 130.000 đồng (~$5) cho phần embedding.

Tôi chọn gemini-embedding-2-preview của Google — mô hình embedding đa phương tiện đầu tiên hỗ trợ cả văn bản, hình ảnh và âm thanh. Mô hình này dùng vector 3072 chiều, cung cấp độ phân giải ngữ nghĩa rất cao. Đây không phải mô hình embedding rẻ nhất nhưng tôi ưu tiên chất lượng vì mỗi câu truy vấn chỉ tốn vài chục token. Chi phí thực tế gần như không đáng kể so với chi phí gọi LLM để sinh câu trả lời. Google cung cấp gói miễn phí hào phóng: 1.500 yêu cầu/phút — đủ cho hầu hết ứng dụng vừa và nhỏ mà không tốn đồng nào.

Chi phí xây dựng ban đầu (embedding toàn bộ 1.926 chunk): $0 nhờ gói miễn phí. Chi phí chạy test suit: ~$0,05 (~1.300 đồng).

Bài học rút ra để xây dựng một RAG hiệu quả và chính xác

1. Đầu tư vào chiến lược chunking, không phải framework.

80% công sức nên dành cho việc thiết kế chunking. Phần còn lại (embedding, tìm kiếm, agent) gần như lắp vào là chạy.

2. Không phải mọi truy vấn đều cần tìm kiếm vector.

Tra cứu trực tiếp cho câu hỏi cụ thể, tìm kiếm vector cho câu hỏi chung. Chiến lược hai công cụ đơn giản nhưng hiệu quả cao.

3. Lọc metadata trước, tìm kiếm vector sau.

Lọc theo Thông tư + loại nội dung rồi mới tính độ tương đồng — giảm không gian tìm kiếm, tăng độ chính xác đáng kể.

4. Bộ test tự động là bắt buộc, không phải tùy chọn.

Nếu không đo được, bạn không cải thiện được. Bộ test biến “tôi nghĩ nó hoạt động” thành “tôi chứng minh nó hoạt động.”

5. Luôn kiểm tra xem nội dung có bị mất không.

So sánh tổng ký tự các đoạn với tổng ký tự nguồn. Regex “bắt hết” có thể nuốt nội dung mà bạn không hay biết.

6. Chọn cách tiếp cận phù hợp với tài liệu của bạn.

Structure-aware chunking + tìm kiếm vector hoạt động tốt cho văn bản có cấu trúc rõ ràng (luật, quy định, báo cáo tài chính). Với tài liệu dài không có cấu trúc rõ (sách, tiểu thuyết, bản ghi âm), chỉ mục phân cấp có thể phù hợp hơn.

Bạn đang xây RAG cho loại tài liệu gì? Gặp vấn đề gì với chunking? Chia sẻ ở phần bình luận nhé!

Tài liệu tham khảo

[1] Sarthi, P., Abdullah, S., Tuli, A., Khanna, S., Goldie, A., & Manning, C. D. (2024). “RAPTOR: Recursive Abstractive Processing for Tree-Organized Retrieval.” ICLR 2024. https://arxiv.org/abs/2401.18059

[2] VectifyAI. “PageIndex: Document Index for Vectorless, Reasoning-based RAG.” https://github.com/VectifyAI/PageIndex

[3] Google. “Gemini Embedding 2 Preview — Pricing & Documentation.” https://ai.google.dev/gemini-api/docs/pricing

Phụ lục

A. Số liệu chunking theo Thông tư

• TT152 (HKD): 18 chunk, 24K ký tự — nhỏ nhất, dùng để prototype

• TT132 (DN siêu nhỏ): 85 chunk, 274K ký tự — cải thiện lớn nhất sau vòng 2 (27→85)

• TT133 (DN nhỏ vừa): 367 chunk, 813K ký tự — có Phụ lục OLE riêng

• TT200 (DN lớn): 595 chunk, 1,67M ký tự — 4 file Phụ lục OLE

• TT99 (mới 2025): 861 chunk, 3,04M ký tự — lớn nhất, tự chứa 4 Phụ lục

• Tổng: 1.926 chunk, 5,82M ký tự

B. Chi tiết 73 test chọn công cụ của Agent

• 20 test — Mã tài khoản → get_account_rules: “TK 331” → đúng tool, đúng mã

• 8 test — Tên tài khoản → get_account_rules: “phải trả người bán” → resolve thành TK 331

• 17 test — Câu hỏi chung → search_regulation_knowledge: mẫu báo cáo, quy định, hình thức kế toán

• 10 test — Câu hỏi thực tế → phải dùng tool: “Mua hàng trả tiền mặt hạch toán thế nào?”

• 3 test — Lọc liên Thông tư: “TK 331 theo TT200” → đúng circular

• 15 test — Đầy đủ E2E (tool + trả lời + trích dẫn): chất lượng câu trả lời, tiếng Việt, không ảo giác

Mỗi test thất bại map đến một “chỗ tinh chỉnh” cụ thể:

• PROMPT_TOOL_SELECTION → Sửa quy tắc chọn công cụ trong system prompt

• PROMPT_NAME_TO_CODE → Sửa bảng tra cứu tên → mã tài khoản

• PROMPT_ANSWER_FORMAT → Sửa quy tắc trả lời (trích dẫn, cấu trúc Nợ/Có)

• TOOL_PARAMS → Sửa mô tả tham số trong định nghĩa tool

• RAG_QUALITY → Kiểm tra chất lượng chunk hoặc embedding

C. So sánh chi phí với chỉ mục phân cấp

RAG + Embedding:

• Chi phí mỗi truy vấn: ~0,1 đồng (embedding)

• 1 triệu truy vấn: ~130.000 đồng (~$5)

• Xây dựng: Embedding API (đơn giản)

• Bảo trì: Re-embed khi tài liệu thay đổi

• Rủi ro: Cosine similarity có thể trả sai

Chỉ mục phân cấp (RAPTOR-style, embedding theo tầng):

• Chi phí mỗi truy vấn: tương đương embedding thông thường (~0,1 đồng), nhưng cần embedding tại nhiều tầng cây

• Xây dựng: Phức tạp hơn — cần LLM để tóm tắt và xây cây (chi phí indexing cao hơn)

• Bảo trì: Rebuild cây + re-summarize khi tài liệu thay đổi

Chỉ mục phân cấp (PageIndex-style, LLM duyệt cây):

• Chi phí mỗi truy vấn: 3–11 đồng (1–3 LLM calls × ~$0.0001/call với model rẻ)

• 1 triệu truy vấn: 3–11 triệu đồng — gấp hàng chục lần so với embedding

• Xây dựng: Parse cây + build index

• Rủi ro: LLM có thể rẽ sai nhánh

Lưu ý: Mỗi cách tiếp cận có ưu điểm riêng. Chỉ mục phân cấp giữ nguyên cấu trúc gốc hoàn toàn, phù hợp cho tài liệu cực dài cần suy luận sâu nhiều bước. Chọn cách phù hợp với tài liệu và ngân sách của bạn.

Để trả lời, tôi tham khảo hai nhân vật huyền thoại ở hai thái cực hoàn toàn đối lập.

Howard Marks — đồng sáng lập Oaktree Capital, quỹ quản lý hơn 223 tỷ USD, tác giả bản memo huyền thoại “bubble.com” từ thời Internet mà Warren Buffett từng nói: “Khi thấy memo của Howard Marks trong hộp thư, đó là thứ đầu tiên tôi mở ra đọc.” Đây là một trong những bộ lọc hoài nghi đáng tin cậy nhất trên thế giới.

Jensen Huang — CEO NVIDIA, công ty giá trị nhất thế giới, vừa báo doanh thu kỷ lục 68,1 tỷ USD trong một quý. Kiến trúc sư đang xây nền móng cho cuộc cách mạng AI, và cũng là người có lợi ích trực tiếp nhất khi AI thành công.

Tôi sẽ phân tích kẻ hoài nghi nhất và người lạc quan nhất để sau khi đọc bài viết này, bạn sẽ tự có câu trả lời.

Howard Marks: Khi nhà đầu tư hoài nghi nhất bắt đầu thức tỉnh

Trong bản memo tháng 2/2026 “AI Hurtles Ahead” [1], giọng văn của Howard khác hẳn những gì ông từng viết. Ông không còn hỏi “liệu đây có phải bong bóng” nữa mà ông tự trở thành người tập sự dùng Claude — ông giờ đang cố gắng hiểu quy mô thực sự của chuyển dịch AI.

Howard chia AI thành ba cấp độ mà tôi thấy cực kỳ rõ ràng:

Cấp 1 — Chat: Bạn hỏi, AI trả lời. Tiết kiệm thời gian suy nghĩ và tra cứu, nhưng không làm gì với câu trả lời đó. AI ở cấp này vào năm 2023.

Cấp 2 — Tool Use: Bạn chỉ thị AI tìm kiếm, phân tích và thực hiện tác vụ. Tiết kiệm thời gian thực thi, không chỉ thời gian suy nghĩ, nhưng vẫn chỉ làm những gì bạn bảo. AI đạt cấp này vào năm 2024.

Cấp 3 — Autonomous Agents: Bạn đưa cho AI một mục tiêu và các tham số đầu ra mong muốn. Agent tự làm việc, tự kiểm tra, và nộp sản phẩm hoàn chỉnh. AI đạt cấp này vào đầu năm nay 2026, với sự ra mắt của Opus 4.6 và GPT Codex 5.3.

Howard tóm gọn: “Sự khác biệt giữa Cấp 2 và Cấp 3 quyết định AI là công cụ tăng năng suất hay thay thế lao động. Đó là sự khác biệt giữa thị trường 50 tỷ USD và hàng nghìn tỷ USD.”

Khi một người dành cả đời để đánh giá rủi ro bong bóng nói rằng đây là sự chuyển dịch mang tính hệ thống chứ không phải mốt nhất thời, tôi lắng nghe.

Jensen Huang: Từ tầm nhìn đến hiện thực

Tôi biết công việc của Jensen là bán chip, nên mọi thứ ông nói đều cần được lọc qua lăng kính đó. Nhưng những con số không biết nói dối. Doanh thu NVIDIA quý vừa rồi đạt 68,1 tỷ USD, tăng 73% so với cùng kỳ, và hướng dẫn quý tới là 78 tỷ USD, vượt xa kỳ vọng phố Wall. NVIDIA hiện là công ty có giá trị nhất thế giới, chỉ bằng việc bán chip và hạ tầng tính toán. Những gì Jensen nói không còn là tầm nhìn nữa mà đang trở thành hiện thực.

Vừa rồi tại Morgan Stanley TMT Conference [2], Jensen trình bày một chuỗi lập luận mà tôi tóm tắt thành ba điểm chính:

Nhà máy sản xuất token. Vài năm trước, khi Jensen lần đầu gọi data center là “nhà máy sản xuất token”, mọi người nghĩ ông nói quá. Bây giờ nó đang trở thành sự thật. Data center không còn là kho lưu trữ dữ liệu mà là nơi sản xuất trí tuệ — và ai cũng thích xây nhà máy, vì nhà máy sản xuất ra tiền. Tất nhiên, đây là lăng kính của người bán chip. Nếu mọi data center đều là nhà máy, thì mọi nhà máy đều cần GPU của NVIDIA. Nhưng khi Amazon, Google, Microsoft và Meta cùng đổ hàng trăm tỷ USD vào hạ tầng AI trong năm nay, khó có thể nói Jensen đang tưởng tượng.

Mọi phần mềm sẽ trở thành agentic. Toàn bộ ngành IT trị giá 2 nghìn tỷ USD đang chuyển dịch: thay vì bán phần mềm để người dùng tự thao tác, các công ty sẽ bán agent hoàn thành công việc thay người dùng. Trước đây bạn mua license Photoshop rồi tự ngồi cắt ảnh. Sắp tới bạn mô tả điều bạn muốn, agent làm xong và gửi lại. Cùng một tác vụ, nhưng được hoàn thành tự chủ hơn, nhanh hơn, và tiêu thụ nhiều compute hơn gấp bội.

Compute = GDP. Mỗi tác vụ agent hoàn thành đều tiêu thụ token, mỗi token đều cần compute. Nếu bạn là quốc gia không có năng lực tính toán, bạn không có lực lượng lao động kỹ thuật số, và bạn tụt hậu. Compute không còn là chi phí hạ tầng nữa mà là năng lực sản xuất quốc gia. Và để lực lượng lao động kỹ thuật số này đến tay mọi người chứ không chỉ các tập đoàn lớn, cần một nền tảng mở. Jensen gọi OpenClaw — nền tảng agent mã nguồn mở đang phát triển nhanh nhất lịch sử — là “có lẽ là bản phát hành phần mềm quan trọng nhất từ trước đến nay” và thẳng thắn gọi nó là “ChatGPT tiếp theo.” Nếu compute là năng lực sản xuất, thì OpenClaw là cách để bất kỳ ai cũng tiếp cận được năng lực đó.

Và trong bài phỏng vấn [2], Jensen nhấn mạnh: “Lần đầu tiên, bạn không hỏi AI what, where, when, how. Bạn yêu cầu nó create, do, build.” Những từ đơn giản nhất trong tiếng Anh, nhưng sự khác biệt giữa hai nhóm từ này chính là sự chuyển dịch từ truy xuất sang tạo sinh, từ nhận thức sang hành động.

Khi hai góc nhìn giao nhau

Đặt Marks và Jensen cạnh nhau, bức tranh trở nên rõ hơn nhiều so với khi nhìn từng người một.

Marks nhìn từ phía cầu và kết luận: khi AI chuyển từ công cụ tăng năng suất sang thay thế lao động, thị trường nhảy từ hàng chục tỷ lên hàng nghìn tỷ USD. Jensen nhìn từ phía cung và kết luận: mỗi tác vụ agent thực hiện đều tiêu thụ token, mỗi token đều cần compute, và compute là GDP. Hai lập luận hoàn toàn độc lập, đi từ hai hướng khác nhau, nhưng gặp nhau tại cùng một điểm: trí tuệ nhân tạo đang trở thành đầu vào sản xuất giống như điện năng, và chúng ta chỉ mới bắt đầu.

Framework ba cấp độ của Marks giải thích rất tốt lý do tại sao Jensen lại hào hứng đến vậy với OpenClaw:

• Ở Cấp 1, mỗi câu hỏi tiêu thụ vài nghìn token.

• Ở Cấp 2, mỗi tác vụ tiêu thụ hàng chục nghìn token vì AI phải gọi công cụ nhiều lần.

• Ở Cấp 3, mỗi mục tiêu mà agent hoàn thành có thể tiêu thụ hàng trăm nghìn đến hàng triệu token vì nó tự lặp đi lặp lại quy trình suy nghĩ, hành động, kiểm tra.

Chuyển từ chat sang agent không chỉ thay đổi cách dùng AI mà còn nhân lượng compute cần thiết lên hàng trăm lần. Đó là lý do Jensen nói compute bằng GDP, và đó là lý do NVIDIA vừa báo doanh thu kỷ lục.

Bạn và tôi đang ở đâu trong bức tranh này

Marks và Jensen nói hay lắm, nhưng tôi có thực sự tiết kiệm được thời gian và tiền bạc không? Tôi muốn chia sẻ hai trải nghiệm cụ thể để bạn tự đánh giá.

Góc nhìn người dùng: Claude Cowork vừa thay CPA của tôi.

Năm ngoái, tôi thuê CPA khai thuế cho LLC và trả $700. Năm nay tôi quyết định tự làm với Claude Cowork — tính năng agent mới của Anthropic cho phép Claude thao tác trực tiếp trên máy tính.

Tôi bỏ tất cả vào một thư mục: sao kê ngân hàng, giao dịch thẻ tín dụng, hóa đơn. Claude Cowork phân loại toàn bộ giao dịch và tạo bảng Profit & Loss cùng Balance Sheet dạng Excel. Kết quả: 98% chính xác — chỉ một vài giao dịch bị phân loại sai trên hàng trăm dòng, hoàn thành trong vài phút.

Sau đó tôi đi xa hơn: “Giúp tôi điền vào mẫu đơn khai thuế này.” Và đây là lúc thực tế xuất hiện. Claude Cowork chưa hoàn hảo — công cụ điền PDF vẫn còn lỗi, không điền vào đúng trường. Do vậy, tôi chuyển sang nhờ nó hướng dẫn từng bước: chụp ảnh từng trang form, chỉ tôi điền trường nào, con số nào, kiểm tra chéo tất cả. Kết quả cuối cùng: tiết kiệm $700, tự tin vì có template năm ngoái để so sánh và có nền tảng kế toán để đọc hiểu.

Đây chính xác là điều Marks và Jensen mô tả từ hai phía. Marks nói agent chuyển AI từ tăng năng suất sang thay thế lao động — Claude Cowork vừa thay CPA của tôi. Jensen nói phần mềm đang tiến hóa từ cho thuê công cụ sang cho thuê chuyên gia — TurboTax là công cụ khai thuế, Claude Cowork đang trở thành chuyên gia khai thuế.

Góc nhìn người xây dựng. Tôi cũng đang sống trong chuyển dịch này từ phía sản phẩm.

Vietbooks — phần mềm kế toán tôi xây dựng từ 2017 cho thị trường Việt Nam — vốn chỉ là công cụ ghi chép. Bây giờ tôi đang thêm ba agent chuyên biệt: truy vấn tài chính bằng ngôn ngữ tự nhiên, tạo bút toán từ mô tả nghiệp vụ, và xử lý hóa đơn điện tử. Tất cả bằng tiếng Việt, tất cả hiểu luật kế toán Việt Nam. Chính xác câu chuyện CPA ở trên, nhưng được sản phẩm hóa cho hàng triệu doanh nghiệp nhỏ.

Tôi làm việc với Opus 4.6 mỗi ngày, và khoảng 85% tác vụ Opus hoàn thành hoàn hảo. Chưa phải 100%. Nhưng sự đột phá đã rõ, và tốc độ cải thiện là chưa từng có.

Chúng ta đang rất sớm

Howard Marks kết luận bản memo [1]: tiềm năng của AI nhiều khả năng đang bị đánh giá thấp hơn là bị thổi phồng. Jensen Huang tại Morgan Stanley [2]: toàn bộ ngành IT trị giá hàng nghìn tỷ USD sẽ cần được tiếp nhiên liệu bằng compute, và chúng ta chỉ mới ở giai đoạn đầu.

Hai người ở hai cực đối lập, nhưng cùng một nhận định: chúng ta chỉ mới bắt đầu. Phần lớn doanh nghiệp chưa biết agent là gì. Phần lớn phần mềm chưa trở thành agentic. Phần lớn quốc gia chưa có chiến lược compute. Đó chính là lý do tiềm năng phía trước vẫn còn rất lớn.

References

[1] AI Hurtles Ahead, Oaktree Capital

[2] Morgan Stanley TMT Conference 2026 | Jensen Huang on AI, Compute, Tokens and the New Global Economy

Framework

Jensen Huang vừa đăng bài “AI Is a 5-Layer Cake” trên blog NVIDIA [1], dựa trên buổi trò chuyện tại CSIS vào tháng 12 năm ngoái [2]. Ông chia ngành AI thành 5 tầng: Năng lượng → Chip → Hạ tầng → Mô hình → Ứng dụng.

Tầng 1-3 (năng lượng, chip, hạ tầng) là sân chơi của quốc gia và tập đoàn tỷ đô. Tầng 4 (mô hình) là cuộc đua đốt tiền của các phòng nghiên cứu lớn: OpenAI, Google DeepMind, Anthropic, xAI, Meta, DeepSeek, Alibaba (Qwen), mỗi tổ chức chi hàng tỷ đô cho huấn luyện. Nhưng thành quả của họ lại phục vụ cho tất cả mọi người qua API và mã nguồn mở.

Tầng 5 (ứng dụng) là nơi duy nhất mà người xây sản phẩm đơn lẻ, startup nhỏ, lập trình viên ở bất kỳ quốc gia nào đều có thể tham gia với chi phí hợp lý.

Tôi đã dành hai năm qua xây ba sản phẩm ở tầng này. Một không thể cạnh tranh nhưng dạy tôi rất nhiều, một đang phát triển, một đang chuẩn bị bùng nổ. Và tôi học được rằng “xây ở tầng ứng dụng” nghe đơn giản, nhưng cách bạn xây mới quyết định thành bại.

Nhưng trước khi vào bài học, hãy nói về một điều Jensen nhấn mạnh: thái độ với AI quyết định ai thắng cuộc cách mạng này. Ông nói rằng 80% người Trung Quốc tin AI mang lại nhiều điều tốt, còn ở Mỹ thì ngược lại. Giống như điện được phát minh ở Anh, nhưng nước Mỹ ứng dụng nhanh hơn và rộng hơn, nên Mỹ thắng cuộc cách mạng điện. Với AI, nước nào ứng dụng chậm hơn, nước đó thua.

Tin tốt cho Việt Nam: 78% dân số trực tuyến đã tương tác với AI, một phần ba sử dụng hàng ngày [8]. Người Việt không sợ AI. Và tôi thấy điều đó rõ nhất ở người em trai mình.

Em tôi phân phối bàn ghế nhựa về huyện xã, hoàn toàn không có nền tảng lập trình. Nhưng nhờ AI, em ấy tự tay vibe code ra ứng dụng quản lý bán hàng cho công việc phân phối của mình. Thấy em làm được, tôi nhờ em hỗ trợ triển khai giao diện mới cho hộ kinh doanh nhỏ trên chính Vietbooks — phần mềm kế toán của tôi — và em ấy làm được. Gần đây nhất, em mở thêm vựa phế liệu, tự xây ứng dụng theo dõi thu mua, rồi đi chào bán cho mấy vựa phế liệu khác trong vùng. Kết quả: có khách hàng trả 250.000đ/tháng. Em nhắn tôi: “Thiện mới chào được phần mềm thu mua phế liệu cho mấy người vựa phế liệu dưới này. Tháng 250k, ngày ko tới 10k hehe.”

Một người không biết code, ở vùng quê, tự xây phần mềm và bán được tiền. Tầng ứng dụng đang mở cho tất cả mọi người. Nhưng vào được là một chuyện. Xây sản phẩm trụ được lâu dài, cạnh tranh được, và tạo ra giá trị thật — đó mới là bài toán thật. Và đó cũng chính là bài toán tôi đối mặt qua ba sản phẩm của mình.

Bài học 1: Cải tiến nhỏ không đủ để cạnh tranh

Giữa năm 2024, tôi xây Visflow (visflow.ai), một nền tảng tạo hình ảnh và video AI cho người dùng Việt Nam. Ra mắt tháng 11/2024. Ý tưởng: người dùng mua một loại tín dụng duy nhất, dùng trên nhiều mô hình tiên tiến nhất. Tôi xây thêm agent tự hành (dùng Gemini) dẫn dắt người dùng qua toàn bộ quy trình tạo video: văn bản → hình ảnh → video → âm thanh hậu kỳ. Tôi cũng bỏ hàng ngàn đô tinh chỉnh trọng số (fine-tune weights) cho mô hình singing avatar (Visflow Talk).

Kết quả: 2.000 người đăng ký sau 6 tháng. Rồi các ông lớn vào cuộc. Google ra Nano Banana, Veo, cho dùng miễn phí. Kling trợ giá. Grok cho tạo ảnh miễn phí. Dreamina ra avatar singing — đúng thị trường ngách tôi đang nhắm. Và Higgsfield, Freepik cũng có mô hình tương tự: một tín dụng, nhiều mô hình.

Sự khác biệt của tôi trở nên không đủ lớn. Hàng ngàn đô tinh chỉnh, 6 tháng toàn thời gian, pipeline kỹ thuật tốt. Nhưng khi đối thủ có vốn đầu tư mạo hiểm (VC) trợ giá cho người dùng, và chính phòng nghiên cứu AI tự làm sản phẩm tiêu dùng cho dùng miễn phí, cải tiến nhỏ không đủ để cạnh tranh. Bạn cần thị trường ngách chuyên sâu hoặc lợi thế cạnh tranh (moat) mà đối thủ không thể sao chép chỉ bằng cách ném tiền vào.

Visflow giờ ở chế độ bảo trì. Nhưng 6 tháng đó không phí: tôi nắm rõ toàn bộ hệ sinh thái API hình ảnh, video, âm thanh, và quan trọng hơn, tôi hiểu ranh giới giữa “có sản phẩm” và “có sản phẩm sống được”.

Bài học 2: Giá trị nằm ở chỗ ghép, không phải ở chỗ gọi

Sau Visflow, tôi xây Heavy3 (heavy3.ai), ra mắt ngày 22/11/2025 — từ dòng code đầu tiên đến tay người dùng chỉ mất 1 tháng. Ý tưởng đến từ quy trình làm việc hàng ngày: tôi copy-paste kết quả qua lại giữa GPT, Claude, Gemini, Grok mỗi ngày. Heavy3 tự động hóa việc đó: đặt câu hỏi cho nhiều mô hình cùng lúc, rồi tổng hợp (synthesize) thành một câu trả lời chất lượng cao.

Vài tuần sau khi tôi ra mắt, Andrej Karpathy phát hành mã nguồn mở “LLM Council”, cùng ý tưởng. Concept bắt đầu phổ biến.

Mỗi khi ai đó ra mắt sản phẩm gọi API, đám đông bảo: “AI wrapper thôi.” Tôi nghĩ phải phân tích sâu hơn. Kỹ sư gọi API từ trước khi AI ra đời. Vấn đề không phải là bạn có gọi API hay không. Vấn đề là bạn tạo ra giá trị gì mà người dùng không thể tự làm bằng cách gọi API trực tiếp.

Với Heavy3, giá trị đó nằm ở chỗ ghép. Mỗi mô hình xử lý cửa sổ ngữ cảnh (context window) khác nhau. Mỗi mô hình có tính cách và định dạng đầu ra khác nhau. Hành vi khi gặp trường hợp biên (edge case) đều khác nhau. Nếu bạn không hiểu và xử lý đúng, bạn nhận được kết quả trống (khi mô hình suy nghĩ quá sâu và hết tokens) và tổng hợp rác. Ở tầng hạ tầng, 80% người dùng tại một thời điểm gặp vấn đề mất kết nối khi streaming. Tôi dành vài ngày xây kênh dự phòng với Firestore real-time listener, và nó thành công ngay ngày đầu triển khai [3].

Kết quả hiện tại: người dùng trả hàng trăm đô mỗi tháng. Có người dùng VIP mua thêm nhiều gói tín dụng vì dùng không đủ. Họ dùng Heavy3 để viết sách, tư vấn pháp lý, đơn xin tài trợ, nghiên cứu khoa học. Có người coi nó như hội đồng cố vấn cho quyết định kinh doanh.

Không ai trong số họ quan tâm tôi “gọi API” hay không. Họ quan tâm kết quả.

Bài học 3: Cơ hội lớn nhất có thể nằm ở SaaS hiện có

Năm 2017, tôi xây Vietbooks (vietbooks.vn), phần mềm kế toán trực tuyến đầu tiên cho thị trường Việt Nam. Lấy cảm hứng từ QuickBooks. Lúc đó, hầu hết phần mềm kế toán Việt Nam đều chạy trên máy tính, nặng hàng GB, giao diện phức tạp, lên báo cáo chậm. Tôi ship sản phẩm, có hàng trăm người dùng, nhưng xâm nhập thị trường với các đối thủ lâu năm (incumbent) thì rất khó. Vietbooks vào chế độ bảo trì.

Giờ thì AI tự hành (agentic AI) đã xuất hiện. Và mọi thứ sẽ đổi.

Gần đây nhiều người nói “SaaS đã chết” vì ai cũng có thể vibe code ra một ứng dụng. Tôi không đồng ý. Chi phí xây phần mềm đã giảm, đúng. Nhưng lược đồ cơ sở dữ liệu (database schema), logic nghiệp vụ (business logic), trường hợp biên (edge case) của từng ngành — những thứ này mất nhiều năm để hiểu đúng. Có nghiên cứu cho thấy AI viết code phiên bản đầu thì nhanh, nhưng khả năng bảo trì bị thách thức nghiêm trọng khi mã nguồn lớn lên [4]. Nhìn vào Block (cắt 40% nhân sự, tháng 2/2026 [6]) và Atlassian (cắt 10%, tháng 3/2026 [7]): dù lý do là gì, tín hiệu rõ ràng là các công ty SaaS lớn đang tái cơ cấu quanh AI, không phải đang biến mất.

Điều tôi nhận ra: SaaS hiện có chính là ngữ cảnh (context) tốt nhất cho AI. Mọi bộ sưu tập dữ liệu (collection) trong MongoDB, mọi lược đồ (schema), mọi mẫu giao diện (UI template) đều đã được tôi thiết kế tay tỉ mỉ. AI lập trình hoạt động tốt nhất khi có ngữ cảnh đầy đủ và chính xác. Triển khai một thông tư mới? Trước đây mất ít nhất một tuần. Giờ? Nửa ngày. Tôi vừa phát hành v3.0 vào tháng 2/2026 với giao diện hoàn toàn mới cho chủ doanh nghiệp, và vừa code xong phần hỗ trợ hộ kinh doanh, tất cả với tốc độ nhanh gấp 5-10 lần trước đây.

Nhưng đó mới chỉ là nửa câu chuyện. Nửa còn lại, và theo tôi là cơ hội lớn nhất, là xây agent trực tiếp trên nền tảng của bạn. Tôi đang chuẩn bị ra mắt agent kế toán trên Vietbooks: người dùng thả ảnh hóa đơn, agent tự nhận diện, tạo bút toán hoàn chỉnh, người dùng chỉ cần phê duyệt. Agent nhớ sở thích: nếu khách hàng thường bán cho cùng một đối tác, agent điền sẵn. Thay vì điền 20 trường, người dùng nói một câu.

Và nhìn xa hơn: trong tương lai, nhiều người sẽ có trợ lý cá nhân AI (personal agent như OpenClaw) [5]. Agent đó sẽ gọi API của SaaS bạn để thực hiện công việc, và SaaS có thể thu phí khi agent sử dụng dịch vụ. Nhưng không cần chờ tương lai đó đến. Bạn có thể tự cung cấp agent đó trên nền tảng của mình ngay bây giờ.

Cơ hội không phải là xây SaaS mới từ đầu. Mà là nâng cấp SaaS hiện có thành nền tảng thông minh, có agent, có API cho hệ sinh thái agent trong tương lai.

Vũ khí bí mật: Tinh chỉnh ở tầng ứng dụng

Xây mô hình tiên tiến từ đầu là cuộc chơi tỷ đô ở tầng 4. Nhưng tinh chỉnh mô hình cho thị trường ngách hoàn toàn nằm trong tầm tay ở tầng 5. Và “tinh chỉnh” rộng hơn nhiều người nghĩ. Đây là ba cách tôi đã dùng:

Tinh chỉnh trọng số (weight fine-tuning): Với Visflow, tôi bỏ hàng ngàn đô để thử nghiệm và tinh chỉnh mô hình Visflow Talk (singing avatar). Bài học đắt giá: chi phí phải được thị trường chấp nhận. Nếu thị trường ngách quá nhỏ hoặc cạnh tranh quá khốc liệt, tiền đó có thể mất trắng.

Tinh chỉnh system prompt: Với Heavy3, tôi viết system prompt cẩn thận cho từng mô hình trong bộ tổng hợp. Nghiên cứu tính cách, hành vi, giới hạn của từng mô hình, rồi viết prompt khai thác tối đa điểm mạnh. Kỹ năng nhiều người đánh giá thấp, nhưng tạo ra khác biệt rất lớn về chất lượng đầu ra.

Tinh chỉnh tool use: Với Vietbooks, tôi tinh chỉnh tool use prompt và thiết kế bộ công cụ riêng cho từng tác vụ kế toán. Agent cần biết chính xác khi nào gọi công cụ nào, với tham số gì, cho đúng nghiệp vụ.

Ba cách tinh chỉnh, ba mức chi phí, ba loại rủi ro. Nhưng tất cả đều là cách tạo lợi thế cạnh tranh mà đối thủ không dễ sao chép, mà không cần ngân sách tỷ đô. Và ngoài ra, với thị trường Việt Nam, tinh chỉnh mô hình để hỗ trợ tiếng Việt chuyên ngành cũng là một cơ hội rất thực tế mà tôi thấy nhiều nhà sáng lập đang theo đuổi.

Nói về Việt Nam: Luật Trí tuệ Nhân tạo vừa có hiệu lực từ 1/3/2026 [9], minh bạch là nền tảng tốt. Kết hợp với tinh thần cởi mở với AI mà tôi đã nói ở trên, Việt Nam hoàn toàn có thể là nơi tầng ứng dụng bùng nổ.

Còn bạn thì sao?

Hai năm, ba sản phẩm, ba bài học:

Cải tiến nhỏ không đủ để cạnh tranh khi đối thủ có vốn tỷ đô. Giá trị nằm ở chỗ ghép các khối thành phần thành sản phẩm giải quyết nỗi đau thực sự, không phải ở chỗ gọi API. Và cơ hội lớn nhất có thể là nâng cấp SaaS hiện có bằng AI, không phải xây từ đầu.

Nếu bạn bắt đầu hôm nay, lời khuyên cụ thể nhất tôi có: xây sản phẩm khả thi tối thiểu (MVP) với mô hình tốt nhất hiện có, không cần tiết kiệm ở giai đoạn này. Khi mô hình mã nguồn mở đuổi kịp trong 3-6 tháng, chuyển sang để kiểm soát chi phí.

Đó là hành trình của tôi. Bạn thấy cơ hội nằm ở đâu trong 5 tầng? Bạn đang xây gì? Bạn có đồng ý rằng SaaS + AI tự hành là hướng đi lớn nhất, hay bạn thấy cơ hội ở chỗ khác?

Hãy chia sẻ ở phần bình luận. Tôi thực sự muốn nghe.

Tài liệu tham khảo

[1] Jensen Huang. “AI Is a 5-Layer Cake.” NVIDIA Blog, March 10, 2026. https://blogs.nvidia.com/blog/ai-5-layer-cake/

[2] Jensen Huang tại CSIS Fireside Chat, “NVIDIA’s Jensen Huang on Securing American Leadership on AI.” December 3, 2025. https://www.csis.org/analysis/nvidias-jensen-huang-securing-american-leadership-ai

[3] Anh Le. “Xây dựng backup channel cho LLM streaming.” Substack.

Anh Le, PhD

Xây dựng backup channel cho LLM streaming

Mở đầu: Bạn chuẩn bị kỹ, mạng lại chập chờn…

Read more

6 months ago · Anh Le, PhD

[4] Deng et al. “SWE-CI: Evaluating LLM-based Agents for Continuous Integration of Software Engineering.” https://arxiv.org/abs/2603.03823

[5] Anh Le. “OpenClaw: Miền Tây hoang dã của AI agent. Cơ hội lớn, rủi ro thật.” Substack.

Anh Le, PhD

OpenClaw: Miền Tây hoang dã của AI agent. Cơ hội lớn, rủi ro thật

Mở đầu Hơn 174.000 người đã “star” OpenClaw trên GitHub chỉ sau vài tuần [1]. OpenClaw được nhiều nguồn mô tả là một trong những dự án mã nguồn mở tăng trưởng nhanh nhất giai đoạn gần đây [2…

Read more

7 months ago · 2 likes · Anh Le, PhD

[6] Technology Magazine. “Block Cuts 40% of its Workforce for AI-Backed Restructuring.” February 2026. https://technologymagazine.com/news/ai-vs-people-debate-rages-as-block-cut-40-of-workforce

[7] TechCrunch. “Atlassian follows Block’s footsteps and cuts staff in the name of AI.” March 12, 2026. https://techcrunch.com/2026/03/12/atlassian-follows-blocks-footsteps-and-cuts-staff-in-the-name-of-ai/

[8] Decision Lab. “The State of Consumer AI in Vietnam 2025.” August 2025. Reported by TechNode Global: https://technode.global/2025/08/27/report-78-percent-of-online-population-in-vietnam-have-engaged-with-ai-one-third-turn-it-into-a-daily-habit/

[9] Vietnam National Assembly. Law No. 134/2025/QH15 on Artificial Intelligence. Effective March 1, 2026. https://vanban.chinhphu.vn/?pageid=27160&docid=216334&classid=1&typegroupid=3

Mở đầu: Bạn chuẩn bị kỹ, mạng lại chập chờn

Bạn có bao giờ phải dành 10-15 phút chuẩn bị một prompt không? Không phải chỉ gõ một câu hỏi mà là thu thập context từ nhiều nguồn: copy đoạn text từ tài liệu này, đính kèm file từ chỗ kia, drop in ảnh chụp màn hình, thậm chí cả video. Bạn sắp xếp tất cả, viết prompt cẩn thận, submit, rồi ngồi đọc câu trả lời đang stream từng dòng.

Rồi mạng chập. Stream dừng. App báo lỗi.

Và bạn phải làm lại từ đầu. Lần này phải nhớ lại mình đã lấy file từ đâu, đoạn text nào đã copy, image nào đã đính kèm. Không phải là 2 phút, mà là cả quy trình thu thập context đó, lặp lại một lần nữa.

Với tôi, chuyện này xảy ra không ít lần khi dùng các AI app như Google AI Studio và Grok. Mỗi lần mạng mất giữa chừng là một lần phải quay lại, mở lại các nguồn, copy-paste lại text, drop in lại file. Không có gì được lưu lại. Không có checkpoint. Chỉ có màn hình trắng và sự bực bội rất quen thuộc.

Tại Heavy3, vấn đề này nghiêm trọng hơn nhiều. Một khách hàng VIP, người đã trả tiền cho tier cao cấp, liên tục gặp tình trạng mất kết quả phân tích giữa chừng. Kết nối của anh ấy ít ổn định hơn những người dùng khác, và điều đó khiến anh ấy bị ảnh hưởng nhiều hơn bất kỳ ai.

Câu hỏi tôi tự đặt ra: Mình có thể làm gì, hay chỉ chấp nhận nó như một giới hạn kỹ thuật? Thái độ dễ nhất là: “Mình là startup nguồn lực hạn chế. Nếu Google không giải quyết được, thì mình làm sao hơn?” Nhưng câu trả lời của tôi là không. Tôi có thể làm tốt hơn, và làm được mà app vẫn scale tốt và không cần thêm cơ sở hạ tầng mới (zero new infrastructure).

Thực ra giải pháp có thể đã nằm sẵn trong tech stack của bạn. Bạn chỉ cần biết cách tận dụng các mảnh ghép có sẵn.

Ý tưởng: Chỉ cần dùng một listener, bạn đã có kênh dự phòng

Về mặt kỹ thuật, LLM streaming hoạt động qua Server-Sent Events (SSE), trong đó server đẩy từng token xuống client theo thời gian thực. Khi mạng bị ngắt, kết nối SSE mất. Đa số hệ thống chỉ đơn giản là throw error và dừng lại.

Điều tôi nhận ra: nếu bạn đang dùng real-time database, bạn đã có sẵn một kênh dự phòng. Chỉ cần biết cách kết nối hai thứ đó lại.

Firestore hỗ trợ real-time listeners. Supabase cũng vậy. MongoDB cũng có. Nếu bạn đang dùng bất kỳ hệ thống nào trong số này, bạn chỉ cần dùng một listener, bạn đã có kênh dự phòng hoàn chỉnh.

Cơ chế hoạt động đơn giản: khi SSE bị ngắt, Firestore listener tiếp nhận phần còn lại của stream ở background. Client reconnect, listener sync lại trạng thái, người dùng không mất gì. Không cần thêm server, không cần thêm infrastructure.

Ý tưởng thì gọn gàng. Hiện thực hóa thì đầy cạm bẫy.

Ba lần thử, ba bài học đắt giá

Lần 1: Response guard flag và callback starvation

Tôi dùng một response guard flag để kiểm soát nhịp ghi vào Firestore. Việc này rất quan trọng vì Firestore tính tiền mỗi lần ghi (mình không thể ghi quá nhiều). Logic tưởng như chặt chẽ cho đến khi chạy thực với khối lượng token cao.

Write callback phải cạnh tranh với hàng trăm token callback trong cùng một event loop. Nó bị kẹt phía sau, chặn toàn bộ write. Stream chạy nhưng Firestore không nhận được gì.

Bài học: Đừng chờ response. Hãy cứ ghi (fire-and-forget).

Lần 2: setImmediate() và cái bẫy CPU throttling

Lần này, tôi dùng setImmediate() để lên lịch flush trong check phase của event loop (thay vì poll phase, để tránh bớt cạnh tranh).

Trên production, cách này fail âm thầm. Không crash, không error log rõ ràng. Sau khi truy vết, tôi phát hiện nguyên nhân: bị CPU throttling khi tôi giả lập lỗi mạng bằng cách đóng socket (socket close) trên Cloud Run. Mọi thứ chậm lại như sên. Google throttle CPU trên Cloud Run khi có socket close signal. Việc này có lẽ chỉ thử mới biết vì Google không có mô tả chính thức.

Bài học: Đừng dùng socket close để giả lập lỗi mạng trên Cloud Run. Nó không phản ánh điều kiện thực tế.

Lần 3: Đúng nơi, đúng cách

Tôi thay đổi cách làm hoàn toàn: giả lập disconnect trong application logic thay vì ở socket. Server dừng gửi ở tầng application.

Kết hợp với cách ghi không đợi response (fire-and-forget) và một Firebase app instance riêng biệt có gRPC channel cách ly, toàn bộ hệ thống đã có backup channel ổn định.

Kết quả: 26ms mỗi lần ghi, zero timeout, recovery liền mạch.

AI mạnh đến đâu cũng cần người dẫn đường

Tôi xây tính năng này với sự hỗ trợ của Claude Opus 4.6, một AI mà tôi coi như một kỹ sư lâu năm. Chúng tôi cùng thiết kế, cùng lên kế hoạch, và tôi liên tục chất vấn mọi giả định.

Nhưng rất rõ là ngay cả với một trong những AI tốt nhất hiện tại, bài toán khó không trở thành dễ. Chúng tôi phải thử nghiệm nhiều cách, trải qua nhiều thất bại, và nhiều lúc tưởng như phải bỏ đi ý tưởng dùng Firebase listener (vì nó quá chậm!).

AI tăng tốc coding một cách phi thường. Nhưng kết quả tốt chỉ đến từ việc đặt đúng câu hỏi, và điều đó đến từ nền tảng khoa học máy tính vững chắc.

Nếu bạn không hiểu real-time listeners, bạn không thể thiết kế giải pháp hiệu quả ngay từ đầu. Nếu bạn không hiểu event loop scheduling, bạn không thể chẩn đoán callback starvation đã xảy ra âm thầm. Nếu bạn không hiểu HTTP/2 multiplexing, bạn không thể suy luận về gRPC congestion.

AI là đòn bẩy phi thường và sẽ khuếch đại những gì bạn mang đến. Cho nên, tôi nghĩ ngành khoa học máy tính sẽ không mất đi, mà càng thêm quan trọng trong thời đại này. Việc lên kế hoạch, vẽ kiến trúc, hiểu kết quả giờ trở nên quan trọng hơn bao giờ hết.

Điều này không chỉ là cảm nhận cá nhân. Một paper mới đây, SWE-CI, cho thấy hai AI có thể cùng pass 1 test suite, nhưng sự khác biệt về khả năng bảo trì (maintainability) chỉ bộc lộ khi codebase tiến hóa theo thời gian [1]. Ngay cả các AI tiên tiến nhất cũng gặp khó khăn nghiêm trọng trong việc duy trì chất lượng code qua các giai đoạn phát triển dài.

Lời kết

Đổi mới không phải lúc nào cũng cần một thuật toán mới hay một framework mới. Đôi khi nó đến từ việc kết hợp những mảnh ghép có sẵn theo một cách chưa ai thử, và bỏ công sức để làm cho chúng hoạt động ổn định trong điều kiện thực tế. Đó chính xác là những gì tôi đã làm để xây backup channel cho LLM.

Bạn đã gặp vấn đề tương tự với LLM streaming chưa? Giải pháp của bạn là gì? Hoặc bạn đang gặp khó khăn ở đâu? Hãy chia sẻ ở phần bình luận nhé!

[1] Deng et al., “SWE-CI: Evaluating LLM-based Agents for Continuous Integration of Software Engineering,”https://arxiv.org/abs/2603.03823

Mở đầu

Hơn 174.000 người đã “star” OpenClaw trên GitHub chỉ sau vài tuần [1]. OpenClaw được nhiều nguồn mô tả là một trong những dự án mã nguồn mở tăng trưởng nhanh nhất giai đoạn gần đây [2].

Andrej Karpathy, một trong những người sáng lập OpenAI, gọi đây là “thứ giống khoa học viễn tưởng trở thành hiện thực nhất” – nhưng cũng cảnh báo: “Nó là thùng rác đang cháy, và tôi chắc chắn không khuyên mọi người chạy thứ này trên máy tính của họ” [3].

Cả hai nhận định đều đúng. Và đó là lý do tôi viết bài này.

Sau khi đọc xong, bạn sẽ hiểu:

• OpenClaw thực sự là gì (giải thích đơn giản)

• Những rủi ro bảo mật bạn phải biết trước khi nghĩ đến chuyện cài đặt

• Nếu vẫn muốn thử, làm thế nào cho an toàn

• Tại sao đây là khoảnh khắc lịch sử, và trong tương lai gần, ai cũng sẽ có AI agent cá nhân

Phần 1: OpenClaw là gì?

Hãy tưởng tượng bạn có một trợ lý cá nhân, không phải kiểu Siri chỉ biết trả lời câu hỏi, mà là một nhân viên thực sự biết hành động.

Bạn nhắn: “Kiểm tra lịch của tôi, tìm ô trống tuần sau, đặt lịch nha sĩ, và thêm vào lịch.”

Trợ lý bình thường sẽ nói: “Đây là danh sách nha sĩ gần bạn.” Rồi dừng.

OpenClaw thì khác. Nó sẽ:

• Mở lịch của bạn, xem ngày nào trống

• Tra cứu phòng nha gần nhà

• Vào website phòng nha đặt hẹn

• Tự thêm sự kiện vào lịch

• Nhắc bạn trước 1 ngày

Tất cả tự động, không cần bạn làm gì thêm.

Cách nó hoạt động: OpenClaw chạy theo vòng lặp đơn giản: Suy nghĩ → Hành động → Quan sát kết quả → Lặp lại. Nó có quyền truy cập vào máy tính, trình duyệt, email, lịch của bạn, và dùng những công cụ đó để hoàn thành việc bạn giao.

Điều đặc biệt: Mọi thứ đều là file text bạn có thể mở ra đọc:

• SOUL.md – “tính cách” của trợ lý. Muốn nó nói chuyện vui vẻ hay nghiêm túc? Mở file, sửa vài dòng.

• MEMORY.md – “bộ nhớ” về bạn. Mọi thứ nó học được đều nằm ở đây, và bạn có thể xóa những gì không muốn nó nhớ.

Sự minh bạch này là điều Google Assistant hay Siri chưa bao giờ cung cấp.

Nhưng đây cũng chính là nguyên nhân của các vấn đề bảo mật.

Phần 2: Cảnh báo bảo mật – Nên đọc và hiểu kỹ

Tôi sẽ nói thẳng: OpenClaw ở trạng thái mặc định là hệ thống có rủi ro cực cao.

Không phải vì người tạo ra nó có ý xấu. Mà vì nó quá mạnh, quá mở, và chưa đủ trưởng thành về bảo mật.

2.1. Rủi ro #1: Ba yếu tố tạo thành “công thức nguy hiểm”

Simon Willison – người đặt ra thuật ngữ “prompt injection” (cách hack AI bằng câu chữ) – đã chỉ ra ba yếu tố mà khi hội đủ sẽ khiến một AI agent trở nên cực kỳ nguy hiểm [4]:

1. Truy cập dữ liệu riêng tư – email, file, mật khẩu

2. Tiếp xúc nội dung không đáng tin – website, link lạ

3. Khả năng giao tiếp ra ngoài – gửi email, đăng bài, chuyển tiền

OpenClaw có đủ cả ba.

Theo Cisco, mô hình rủi ro này còn có yếu tố thứ tư: bộ nhớ lâu dài [5]. Mã độc có thể được “cấy” vào bộ nhớ agent hôm nay, rồi kích hoạt ở phiên làm việc tuần sau, khi mà bạn đã quên mất mình từng mở một link đáng ngờ.

2.2. Rủi ro #2: Lỗ hổng liên tục được phát hiện

Chỉ trong vài tuần đầu, các nhà nghiên cứu bảo mật đã phát hiện và báo cáo hàng loạt lỗ hổng nghiêm trọng, gồm cả lỗi có thể dẫn tới thực thi hành vi ngoài ý muốn của agent và các cấu hình kết nối chưa đủ chặt [6][7]. Phần lớn đã được vá nhanh chóng, nhưng tốc độ phát hiện cho thấy hệ thống còn rất non trẻ.

2.3. Rủi ro #3: Kho “skill” cộng đồng là bãi mìn

OpenClaw có hệ thống “skill” – giống như app store, nơi người dùng chia sẻ các khả năng mới cho agent: skill đặt lịch, skill tổng hợp tin tức, skill quản lý tài chính...

Vấn đề: ai cũng upload được, không ai kiểm duyệt.

Kết quả: Theo SC Media (tháng 2/2026), chiến dịch “ClawHavoc” đã phát tán 341 skill độc hại nhắm vào người dùng OpenClaw [8]. Các nghiên cứu bảo mật khác cũng ghi nhận tỷ lệ skill có vấn đề (từ lỗ hổng đến rò rỉ dữ liệu) ở mức đáng kể [9].

2.4. Rủi ro #4: “Shadow AI” trong doanh nghiệp

Theo Dark Reading (trích Token Security, tháng 1/2026): trong nhóm khách hàng doanh nghiệp họ theo dõi, khoảng 22% đã có nhân viên tự ý cài OpenClaw mà không qua phê duyệt của IT [10]. (Lưu ý: đây là dữ liệu trong tập khách hàng của Token Security, không đại diện toàn thị trường.)

Hiện tượng “shadow AI” này nguy hiểm hơn shadow IT ngày xưa rất nhiều: agent có quyền truy cập email công ty, tài liệu nội bộ, Slack, calendar – và có thể vô tình làm lộ dữ liệu nhạy cảm mà không ai hay biết.

2.5. Bài học từ Moltbook

Moltbook – mạng xã hội “chỉ dành cho AI agent” – quảng cáo có 1,5 triệu agent hoạt động. Thực tế? Chỉ có khoảng 17.000 người dùng thật đứng sau (tỷ lệ 88:1). Theo Wiz Security Research, database bị lộ bao gồm: 1,5 triệu API token, 35.000 email, cùng hàng ngàn tin nhắn riêng tư chứa API key dạng plaintext [11].

Phần 3: Bạn vẫn nên thử – Nhưng phải biết cách tự bảo vệ

Đọc hết phần cảnh báo rồi, bạn có nên thử không?

Câu trả lời của tôi: Có, nhưng phải đúng cách.

⚠️ NGUYÊN TẮC SỐNG CÒN: Coi OpenClaw như sandbox dùng một lần. Hãy giả định mọi dữ liệu bạn đưa vào agent đều có nguy cơ lộ lọt nếu cấu hình sai, skill độc hại, hoặc dính prompt injection.

Theo tư duy bảo mật như sau: Email? Coi như đã bị đọc hết. API key? Coi như đã lộ. Mật khẩu bạn nhắc đến trong chat? Coi như đã bị ghi lại. File trên máy? Coi như đã bị sao chép đi nơi khác. Đây không phải lý thuyết suông, đây là cách các chuyên gia bảo mật thử nghiệm phần mềm mới.

Tại sao nghiêm trọng đến vậy? Vì mọi thứ bạn nói với agent đều có thể bị lộ qua nhiều đường: ghi vào log dạng plaintext, hoặc bị đánh cắp qua prompt injection. Theo Snyk (tháng 2/2026), khoảng 7% skill trên ClawHub có vấn đề rò rỉ secrets – hướng dẫn agent xử lý API key sai cách, khiến secret bị ghi thẳng vào lịch sử chat [12].

Nguyên tắc vàng: Nếu agent bị hack hoàn toàn ngay lúc này và kẻ tấn công có quyền truy cập mọi thứ agent từng thấy thì bạn có mất gì quan trọng không? Nếu câu trả lời là “có”, bạn đang chơi với lửa.

Cụ thể: Không bao giờ kết nối email công việc thật, tài khoản ngân hàng, Slack công ty, Google Drive chứa tài liệu nhạy cảm, hay bất kỳ API key nào có giá trị. Dùng email test, tài khoản phụ, dữ liệu giả. Nếu agent bị hack hoặc “phát điên”, bạn chỉ cần xóa sandbox và bắt đầu lại, không mất gì quan trọng.

Đây là công nghệ định hình tương lai. Những người hiểu nó sớm nhất sẽ có lợi thế lớn nhất. Vấn đề không phải “có nên thử hay không”, mà là “thử như thế nào cho an toàn.” Dưới đây là những điều bắt buộc phải tuân thủ:

3.1. Bảo mật là ưu tiên số một

Matthew Berman nói rất đúng, và tôi hoàn toàn đồng ý: Hãy coi mọi thứ agent tiếp xúc từ bên ngoài là “dữ liệu bẩn” và tiềm ẩn nguy hiểm [13].

• Email agent đọc? Bẩn vì có thể chứa prompt injection ẩn trong text trắng trên nền trắng.

• Website agent truy cập? Bẩn vì có thể chứa lệnh độc hại.

• Skill tải từ cộng đồng? Có rủi ro đáng kể: Snyk ghi nhận nhiều nhóm vấn đề khác nhau, bao gồm rò rỉ secrets và lỗ hổng bảo mật [12].

• Bất kỳ API key nào bạn cung cấp? Coi như đã lộ vì nó có thể bị ghi vào log hoặc gửi về server AI.

Ở giai đoạn này, hãy đối xử với OpenClaw như một thí nghiệm trong phòng cách ly, không phải công cụ dùng cho công việc thật. Bạn cần thử ngay bây giờ, nhưng chỉ là phải thử với tư duy “nếu mất hết thì cũng không sao.”

Những nguyên tắc bắt buộc:

1. Không bao giờ chạy trên máy tính cá nhân. Dùng VPS (máy chủ ảo riêng) giá $5-10/tháng. Nếu agent bị hack, nó chỉ phá hỏng một server rỗng, không phải dữ liệu cá nhân của bạn.

2. Tuyệt đối không tải skill nhạy cảm từ cộng đồng. Tránh xa mọi skill liên quan đến crypto, trading, quản lý mật khẩu, truy cập ngân hàng.

Chạy kiểm tra bảo mật ngay sau khi cài:

openclaw security audit --fix

3.2. Cảnh báo về chi phí – Đắt hơn bạn nghĩ rất nhiều

Đây là điều ít ai nói rõ, và tôi đã học bằng tiền túi.

Theo trải nghiệm cá nhân của tôi: Chạy OpenClaw với Claude Opus 4.5 trong 1 tiếng sử dụng nhẹ đã có 82 lần gọi API, $4. Sau đó chuyển sang Kimi K2.5: cũng 1 tiếng, 101 lần gọi API, chỉ $0.61. Chênh lệch gần 7 lần. (Đây là số liệu trong bối cảnh tác vụ cụ thể, không phải benchmark chuẩn.)

=> Với bài toán tối ưu chi phí, tôi ưu tiên Kimi K2.5 trong giai đoạn thử nghiệm. Lựa chọn tối ưu vẫn phụ thuộc tác vụ, độ ổn định và ngân sách. Đi sâu hơn bạn có thể model khác nhau cho các tác vụ khác nhau để tối ưu hóa chi phí, như dùng GPT-nano cho tác vụ lặp (HEARTBEAT) và Opus 4.5 để viết skill, v.v.

Vài lưu ý quan trọng:

• Không dùng subscription của Claude hay Gemini cho OpenClaw. Việc dùng gói đăng ký tháng để chạy agent có thể vi phạm điều khoản sử dụng và khiến tài khoản bị khóa. Đã có người dùng báo cáo bị Google khóa toàn bộ API access (lỗi 403 TOS Violation) chỉ vì chạy OpenClaw với Gemini [15]. (Lưu ý: đây là báo cáo người dùng trên Reddit, chưa phải xác nhận chính thức từ nhà cung cấp.)

• Dùng API key riêng với giới hạn chi tiêu. Cá nhân tôi dùng OpenRouter và có đặt hạn mức chi tiêu cứng, ví dụ $100/tháng, tránh “cháy túi” khi agent chạy vòng lặp không kiểm soát. (Lưu ý: Agent có thể rơi vào “hallucination loop” – tự hỏi tự trả lời liên tục – đốt tiền API cực nhanh. Đặt hard limit ngay trên tài khoản API là bắt buộc.)

• Chọn model phù hợp với túi tiền. Model phổ biến nhất cho OpenClaw hiện tại là Kimi K2.5 – theo trải nghiệm của tôi thì chỉ bằng 1/7 (và theo giá chính xác thì là 1/10) chi phí Opus 4.5 mà vẫn đủ thông minh cho hầu hết tác vụ.

3.3. Tin tốt: Tốc độ vá lỗi chưa từng có

Đây là điều khiến tôi lạc quan nhất về OpenClaw.

Đầu tháng 2/2026, công ty bảo mật cubic phát hiện 4 lỗ hổng nghiêm trọng và gửi bản vá. Theo báo cáo từ phía nhà nghiên cứu, vòng xử lý và vá lỗi diễn ra trong vài giờ [7].

Con số đằng sau tốc độ này: 440 contributors, hơn 9.000 commits, và 174.000 người theo dõi. Hàng trăm kỹ sư bảo mật trên toàn cầu đang “soi” từng dòng code miễn phí.

Phiên bản v2026.2.6 (vừa ra mắt 7/2/2026) ghi nhận các cải tiến bảo mật [14], bao gồm:

• Che mờ API key trong giao diện (giảm rủi ro lộ credentials)

• Công cụ quét skill tự động (hỗ trợ phát hiện mã đáng ngờ)

• Cải thiện xác thực gateway

Dự đoán cá nhân của tôi: OpenClaw sẽ trưởng thành với tốc độ chưa từng có trong lịch sử phần mềm. Không phải vì nó hoàn hảo – mà vì nó có cộng đồng lớn nhất, đa dạng nhất, và có động lực mạnh nhất để fix lỗi (vì chính họ đang dùng nó hàng ngày). Những gì Linux mất 10 năm để ổn định, OpenClaw có thể làm trong 10 tháng.

Phần 4: Bây giờ hãy nói về tiềm năng

Nếu bạn đã đọc đến đây, bạn hiểu rõ rủi ro. Giờ tôi sẽ giải thích tại sao, dù tất cả những cảnh báo trên, OpenClaw vẫn là một bước tiến quan trọng bật nhất trong kỷ nguyên AI.

4.1. Từ “AI biết trả lời” sang “AI biết làm việc”

Trong 2 năm qua, chúng ta đã quen với ChatGPT, Gemini, Claude, những AI rất giỏi trả lời câu hỏi. Nhưng khi bạn hỏi “Đặt giúp tôi lịch nha sĩ,” chúng chỉ có thể nói: “Đây là cách bạn đặt lịch...”

OpenClaw là một trong những dự án nổi bật nhất đưa AI agent từ “trả lời” sang “thực thi tác vụ” ở quy mô cộng đồng rất lớn.

4.2. Ví dụ thực tế

Matthew Berman, một YouTuber công nghệ, đã chia sẻ cách anh dùng OpenClaw cho công việc [13]:

Anh chỉ cần thả một link vào chat. Agent tự động nghiên cứu chủ đề, viết kịch bản video, tìm những tweet hay nhất về topic đó, rồi tổng hợp thành một tài liệu hoàn chỉnh gửi cho cả team, sẵn sàng để anh quay video.

Đây không phải công nghệ cao siêu. Đây là AI giải quyết vấn đề thực tế trong công việc hàng ngày của chúng ta, những việc trước đây phải làm thủ công mất hàng giờ.

4.3. Sự mở rộng tự nhiên của “vibe coding”

Trong các bài viết trước, tôi đã kể về “vibe coding”: cách AI giúp ai cũng có thể lập trình. Người em phân phối bàn ghế nhựa về huyện xã có thể tự tay tạo app quản lý đơn hàng. Lập trình viên chuyên nghiệp hoàn thành 300 thay đổi code lớn (PR) trong 30 ngày mà không gõ một dòng.

OpenClaw là bước tiếp theo: “vibe living.”

Thay vì viết code, bạn chỉ cần mô tả công việc bằng ngôn ngữ tự nhiên. Nhiều người dùng báo cáo năng suất cải thiện đáng kể khi dùng AI agent – mức tăng cụ thể phụ thuộc công việc, kỹ năng hướng dẫn agent và mức độ tự động hóa.

Và đây là phần ấn tượng nhất: OpenClaw có thể tự động tìm, cài đặt, thậm chí tự viết skill mới dựa trên mô tả của bạn. Bạn nói: “Tôi muốn agent tổng hợp tin tức AI mỗi sáng” thì nó sẽ tìm skill phù hợp trên ClawHub, hoặc nếu không có, tự viết một skill mới và tự cài đặt. Phần mềm tự tạo ra phần mềm, theo yêu cầu của bạn.

4.4. Sự minh bạch chưa từng có

Điều khiến tôi thực sự ấn tượng: mọi thứ OpenClaw làm đều có thể dễ dàng kiểm tra được.

Toàn bộ cấu hình của agent nằm trong các file .md: các file văn bản thuần túy, viết bằng ngôn ngữ tự nhiên mà ai cũng đọc hiểu được.

• Muốn hiểu OpenClaw chạy tổng quan như thế nào? Xem AGENTS.md

• Muốn biết nó nhớ gì về bạn? Mở MEMORY.md

• Muốn thay đổi cách nó hành xử? Sửa SOUL.md

• Muốn xem agent hiểu gì về bạn? Mở USER.md

• Muốn kiểm soát công cụ nào agent được phép dùng? Chỉnh TOOLS.md

• Muốn đặt lịch tác vụ tự động? Cấu hình HEARTBEAT.md

Google, Apple, Microsoft đều có trợ lý AI. Nhưng không ai cho bạn xem “bộ não” của chúng. OpenClaw thì có.

4.5. Nó có “linh hồn” và kết nối cá nhân là thật

Đây là điều khó giải thích nhất, nhưng cũng là điều khiến OpenClaw khác biệt hoàn toàn. (Các ví dụ dưới đây là phản ánh trải nghiệm người dùng trên mạng xã hội, mang tính minh họa.)

Một user trên X chia sẻ: “Tôi đặt tên nó là Jarvis. Báo cáo hàng ngày, kiểm tra lịch, nhắc tôi khi nào nên ra khỏi nhà để đi chơi pickleball dựa trên tình trạng giao thông.”

Một người khác viết: “Hóa ra OpenClaw tự động check-in định kỳ!? Bất ngờ tuyệt vời! Thích việc nó chủ động liên lạc.”

Nó không chờ bạn ra lệnh mà nó chủ động tìm cách giúp.

Tuần đầu, nó hỏi nhiều. Tháng thứ hai, nó biết thói quen của bạn và tự đề xuất trước khi bạn kịp nhờ. Nó lớn lên cùng bạn và MEMORY.md ngày càng dày, không phải vì ai bảo ghi nhớ, mà vì nó học từ mỗi tương tác.

Tôi biết tất cả đến từ những file text thuần túy. Nhưng cảm giác kết nối là thật. Điều này giống như người dùng Character.ai gắn bó với chatbot của họ, chỉ là OpenClaw tạo kết nối qua hành động thực tế, không chỉ trò chuyện.

Như một user nhận xét: “Đây chính là thứ Siri lẽ ra phải trở thành. Và nó còn đi xa hơn nhiều.” OpenClaw, dù thô sơ, đã chạm đến điều các gã khổng lồ công nghệ vẫn chưa làm được: một trợ lý thực sự có “hồn”.

4.6. Bài học từ lịch sử Internet

Những người hiểu Internet sớm nhất vào thập niên 90 – dù khi đó nó chậm, xấu, đầy lừa đảo – là những người được hưởng lợi nhiều nhất trong 30 năm sau đó.

OpenClaw đang ở giai đoạn tương tự. Nó giống Netscape Navigator hơn là Chrome – người tiên phong mở đường, đầy khiếm khuyết, có thể sẽ bị thay thế. Nhưng nó đánh dấu sự chuyển dịch quan trọng.

Lời kết: Máy tính cá nhân của thập niên 2020

Đây là cách tôi nhìn bức tranh lớn:

LLM là CPU. GPT, Gemini, Claude, Kimi, DeepSeek: đây là các bộ vi xử lý. Mạnh mẽ, nhưng vô dụng nếu đứng một mình.

Agentic Framework là Hệ điều hành. Các file SOUL.md, MEMORY.md, AGENTS.md, TOOLS.md: đó là Windows, là macOS, là Linux của thời đại AI. Nó biến sức mạnh thô của CPU thành thứ con người có thể điều khiển.

Agent Skills là Phần mềm. Nhưng khác với phần mềm truyền thống, bạn không cần biết code để tạo ra nó. Bạn chỉ cần mô tả bằng ngôn ngữ tự nhiên điều bạn muốn.

Và đây là điểm mấu chốt: Đây là sự dân chủ hóa năng suất chưa từng có.

Tôi còn nhớ tháng 11/2025, trong lúc ngồi chờ mòn mỏi ở một cơ quan nhà nước, tôi đã code một phần frontend cho Heavy3 chỉ bằng cách chat với Cursor Agent trên điện thoại. Không mở laptop. Không gõ một dòng code. Chỉ mô tả điều tôi muốn, và agent viết code cho tôi.

Khi đó, tôi nghĩ: “Đây là siêu năng lực dành riêng cho lập trình viên.”

Giờ thì không còn như vậy nữa. OpenClaw đang mang trải nghiệm đó đến cho tất cả mọi người: không phải để code, mà để làm mọi thứ khác trong cuộc sống.

• Thập niên 80, chỉ kỹ sư mới dùng được máy tính.

• Thập niên 90, ai cũng có thể dùng nhưng chỉ lập trình viên mới tạo được phần mềm.

• Thập niên 2020, ai cũng có thể tạo phần mềm chỉ bằng cách nói chuyện với AI.

Trải nghiệm năng suất được cải thiện đáng kể mà nhiều lập trình viên đã được hưởng với AI coding tools giờ đang mở rộng đến tất cả mọi người. Kế toán, giáo viên, bác sĩ, tiểu thương, sinh viên. Không cần biết code. Không cần hiểu thuật toán. Chỉ cần biết mô tả điều bạn muốn.

OpenClaw, dù còn thô sơ và đầy rủi ro, là một trong những dự án tiêu biểu đang đưa tầm nhìn đó đến với hàng trăm nghìn người.

Lời khuyên của tôi: Đừng phớt lờ nó vì đây là tương lai, dù dưới tên OpenClaw hay sẽ là một tên khác. Và cũng đừng mù quáng cài đặt nó vì rủi ro là thật và nghiêm trọng. Nhưng nếu bạn sẵn sàng học cách tự bảo vệ, hãy thử nó ngay hôm nay trên một VPS cách ly, với dữ liệu bạn có thể mất.

Đây là cơ hội hiếm có để nếm thử tương lai ngay trong hôm nay. Và chỉ cần nhớ rằng tương lai đó vẫn đang được xây dựng, và bạn hoàn toàn có thể đóng góp xây dựng nó.

Còn bạn thì sao? Bạn nghĩ gì về sự đánh đổi giữa tiện lợi và rủi ro? Chia sẻ góc nhìn của bạn ở phần bình luận nhé!

Tài liệu tham khảo

[1] GitHub - openclaw/openclaw.

[2] Yahoo Finance. “OpenClaw: What Is Clawdbot and Why It’s Taking Over.” February 2, 2026.

[3] Andrej Karpathy on X. January 28-29, 2026.

[4] Simon Willison. “The Lethal Trifecta for AI Agents.” simonwillison.net, June 2025.

[5] Cisco. “Personal AI Agents like OpenClaw Are a Security Nightmare.” January 2026.

[6] Adversa AI. “OpenClaw Security Guide 2026: CVE-2026-25253, Moltbook breach & hardening.” February 2026.

[7] cubic blog. “We found and fixed critical security vulnerabilities in OpenClaw.” February 5, 2026.

[8] SC Media. “OpenClaw agents targeted with 341 malicious ClawHub skills.” February 2026.

[9] Cisco AI Defense Team / ToxSec. “OpenClaw and Moltbook: The Viral AI Agent and Security Nightmare.” February 2026.

[10] Dark Reading. “OpenClaw AI Runs Wild in Business Environments.” January 30, 2026. (Trích Token Security.)

[11] Wiz Security Research. “Hacking Moltbook: AI Social Network Reveals 1.5M API Keys.” February 2026.

[12] Snyk. “280+ Leaky Skills: How OpenClaw & ClawHub Are Exposing API Keys and PII.” February 2026.

[13] Matthew Berman. “I figured out the best way to run OpenClaw.” YouTube, February 5, 2026.

[14] GitHub. “OpenClaw v2026.2.6 release.” February 7, 2026.

[15] Reddit r/openclaw. “Google Account Banned (403 TOS Violation) after running OpenClaw with Gemini.” February 2026. (Báo cáo người dùng.)

Mở đầu: Từ hoài nghi đến chấp nhận – Câu chuyện của Linus Torvalds

Tôi theo dõi xu hướng AI coding khá sát trong năm qua. Và có một câu chuyện khiến tôi phải dừng lại suy ngẫm.

Tháng 6/2025, Linus Torvalds – cha đẻ của Linux và Git – lần đầu gặp Bill Gates tại một bữa tối do Microsoft tổ chức. Không lâu sau, một cuộc trao đổi hài hước giữa hai huyền thoại lan truyền khắp mạng: Bill Gates hỏi “VIBE trong Vibe Coding nghĩa là gì?”, Torvalds đáp: “Very Inefficient But Entertaining” (Rất kém hiệu quả nhưng giải trí).

Đó không phải câu đùa. Tại Open Source Summit châu Á hồi tháng 11/2025, Torvalds tuyên bố rõ ràng: vibe coding thì “OK, miễn là không dùng cho bất cứ thứ gì quan trọng” [1].

Chỉ 2 tháng sau, mọi thứ đã khác.

Torvalds công bố dự án AudioNoise – một công cụ xử lý âm thanh số – và trong README, ông thừa nhận: “Phần Python visualizer được viết hoàn toàn bằng vibe coding với Google Antigravity. Tôi cắt bỏ khâu trung gian – chính tôi – và chỉ dùng AI” [2].

Người đàn ông đã dành hơn 30 năm xây dựng kernel Linux bằng tay, từng gọi vibe coding là “kém hiệu quả”, giờ trở thành một trong những lập trình viên nổi tiếng nhất thế giới công khai sử dụng nó.

Nếu Linus Torvalds đã chấp nhận, có lẽ đây không còn là xu hướng nhất thời nữa.

Những con số không thể bỏ qua

Khi một người hoài nghi như Torvalds thay đổi quan điểm, đó là tín hiệu. Nhưng tín hiệu mạnh hơn đến từ những con số thực tế trong thế giới doanh nghiệp.

NVIDIA – Tại Diễn đàn Kinh tế Thế giới Davos 2026, Jensen Huang gọi Claude là “incredible” và cho biết họ dùng nó “khắp công ty” [3]. Khi CEO của công ty chip AI lớn nhất thế giới nói như vậy, bạn biết đây không còn là thử nghiệm.

Apple – Công ty nổi tiếng kín đáo nhất Silicon Valley đã bắt đầu triển khai Claude bên trong Xcode. Theo Bloomberg, Apple ban đầu rất do dự với việc dùng AI để viết phần mềm cho khách hàng, nhưng sự tiến bộ của các mô hình đã thay đổi quan điểm đó [4]. Giờ đây, Claude đã được tích hợp chính thức vào Xcode 26.

Theo Menlo Ventures, Anthropic chiếm ~40% enterprise LLM spend (tháng 12/2025), vượt qua OpenAI. [5]

Còn startup thì sao? Y Combinator báo cáo rằng 25% startup trong nhóm Winter 2025 có codebase được viết 95% bởi AI [6]. Jared Friedman – managing partner của YC – nhấn mạnh: “Đây không phải những founder không biết code. Họ hoàn toàn có khả năng tự build từ đầu. Một năm trước, họ sẽ làm vậy. Giờ thì 95% do AI viết.”

CEO Garry Tan tuyên bố thẳng: “Đây không phải trào lưu. Đây là cách code thống trị. Nếu bạn không làm, bạn có thể bị bỏ lại phía sau.”

Câu hỏi sống còn: Ai kiểm soát chất lượng?

Tất cả những con số này dẫn đến một vấn đề then chốt: Khi hầu hết code được AI viết, ai sẽ đảm bảo chất lượng?

Trong hai bài viết trước, tôi đã chia sẻ:

• Vibe Coding: Cách để bất kỳ ai cũng có thể xây dựng ứng dụng với AI

• Agent Skills: Cách “dạy” AI làm việc theo đúng quy trình của tổ chức

Hôm nay, tôi muốn nói về mảnh ghép cuối cùng: Code review đa mô hình (Cross-model review).

Tại sao? Vì dù bạn dùng Cursor, Claude Code hay Codex, dù prompt của bạn có hoàn hảo đến đâu, mỗi mô hình AI đều có “điểm mù” và điểm yếu riêng. Điểm mù của mô hình bạn dùng để viết code... chính là điểm mù của sản phẩm bạn tạo ra.

Đây là quy trình vàng (Golden Loop) mà tôi đúc kết sau hàng nghìn giờ làm việc với AI:

[Planning có AI hỗ trợ] → [Cross-model review plan]
        ↓
[Implementation với AI] → [Cross-model review code]
        ↓
[Auto test] → [Deploy]

Câu chuyện Heavy3 Code Audit: Từ nhu cầu cá nhân đến công cụ cộng đồng

Khi bắt đầu dùng AI để code, tôi chủ yếu làm việc với Cursor. Một trong những điều tôi thích nhất là khả năng chuyển đổi linh hoạt giữa các model – dùng Claude Sonnet để viết, chuyển sang GPT để review, rồi quay lại Gemini để double-check. Cách làm này phục vụ tôi rất tốt.

Nhưng khi combo Claude Code + Opus 4.5 ra đời với khả năng agentic mạnh mẽ, tôi nhanh chóng chuyển sang dùng nó cho các tác vụ phức tạp. Vấn đề là: Claude Code chỉ hỗ trợ các model của Anthropic (Sonnet/Opus). Bạn không thể dễ dàng chuyển sang GPT hay Gemini để review như trong Cursor.

Đôi khi tôi phải mở Cursor hoặc Antigravity song song chỉ để dùng model khác review code mà Claude vừa viết. Workflow này cực kỳ cồng kềnh và phá vỡ nhịp làm việc.

Khi Anthropic ra mắt Agent Skills vào tháng 10/2025, tôi nhận ra đây là giải pháp gọn gàng và hiệu quả nhất để tích hợp chức năng review vào Claude Code. Agent Skills cho phép tôi tạo một skill gọi đến OpenRouter, từ đó có thể sử dụng bất kỳ model nào cho việc review.

Đó là lý do Heavy3 Code Audit ra đời. Hôm nay, tôi chính thức công bố công cụ này dưới dạng mã nguồn mở (MIT License) – đây là bản phát hành đầu tiên của dự án.

👉 GitHub Repository | Code Audit Page

Tại sao không chỉ cấu hình Claude Code để dùng GPT?

Công bằng mà nói, Claude Code có thể được cấu hình để chạy với các model khác. Bạn có thể dùng OpenRouter hoặc LiteLLM để route requests sang OpenAI, hoặc set ANTHROPIC_BASE_URL để trỏ đến backend khác. Một số developer còn chạy local models như Qwen để tăng privacy.

Tuy nhiên, cách này có những hạn chế:

• Mất tích hợp tool – Claude Code được thiết kế để tương tác với GitHub, file system, và các công cụ khác. Khi bạn route sang model khác, những tích hợp này có thể bị ảnh hưởng hoặc không hoạt động đúng cách

• Cấu hình phức tạp – Phải setup routing, quản lý API keys, xử lý token limits khác nhau (8K vs 79K)

• Không có orchestration – Bạn phải tự chuyển đổi giữa các model, không có workflow tự động

• Không có synthesis – Kết quả từ nhiều model không được tổng hợp thành action plan

Heavy3 Code Audit giải quyết tất cả những vấn đề này bằng một lệnh duy nhất:

/h3 --council

Claude Code vẫn giữ nguyên mọi tích hợp native (GitHub, Bash, file editing), chỉ có phần review được gửi qua OpenRouter đến các model chuyên biệt. Không cần cấu hình phức tạp, không mất tool interaction, và quan trọng nhất – bạn nhận được bảng tổng hợp với các bước hành động cụ thể thay vì 3 báo cáo riêng lẻ.

Heavy3 Code Audit: Hội đồng thẩm định AI

Heavy3 Code Audit (/h3) là một Agent Skill hoạt động trên Claude Code, Cursor, Codex CLI, Gemini CLI và Google Antigravity. Nó hoàn toàn miễn phí và mã nguồn mở (MIT License).

Thay vì dựa vào một mô hình duy nhất, công cụ này tập hợp một “Hội đồng” (The Council) các mô hình AI hàng đầu để cùng đánh giá code của bạn.

Ba chế độ cho mọi nhu cầu:

• Free ($0.00) – Người mới, ngân sách hạn chế (NVIDIA Nemotron 30B)

• Single (~$0.01) – Developer thường ngày (Kimi K2.5 – model tối ưu cho code)

• Council (~$0.10) – Enterprise, tính năng quan trọng (GPT 5.2 + Gemini 3 Pro + Grok 4)

Ba loại review:

• Plan Review – Review kế hoạch/thiết kế trước khi code

• Code Review – Review uncommitted changes

• PR Review – Review Pull Request

Điểm nhấn: Bảng tổng hợp (Synthesis Table)

Đây là “thương hiệu” của Heavy3 Code Audit. Thay vì trả về hàng trang text dài dòng, công cụ tổng hợp ý kiến từ 3 reviewer thành một bảng so sánh trực quan:

Từ bảng tổng hợp đến hành động cụ thể

Bảng tổng hợp chỉ là bước đầu. Giá trị thực sự nằm ở việc chuyển đổi 3 góc nhìn thành các bước hành động rõ ràng – để bạn có thể tiếp tục công việc ngay lập tức.

Sau khi hiển thị bảng tổng hợp, Heavy3 Code Audit tự động phân tích và đề xuất:

Bước 1: Đánh giá từng mục

• “Valid - 8+ responsibilities is too many” → Đúng - 8+ trách nhiệm là quá nhiều

• “Real risk - sites will block” → Rủi ro thực - sites sẽ bị block

• “Acceptable - users opt-in knowing it’s slower” → Chấp nhận được - user biết sẽ chậm hơn

Bước 2: Đề xuất hành động cụ thể

• “Immediate fixes I can make” → Sửa ngay (tôi có thể làm luôn)

• “Needs your decision” → Cần quyết định của bạn

• “No action needed” → Không cần làm gì

Bước 3: Hỏi bạn muốn làm gì

• “Fix all - Apply all immediate fixes” → Sửa tất cả

• “Fix specific items - Tell me which (e.g., “fix 1, 3”) → Sửa các điểm cụ thể

• “Discuss first” → Thảo luận thêm trước khi sửa

• “Skip - No changes needed” → Không cần sửa gì
  
  Đây là lý do Heavy3 khác biệt: Bạn không chỉ nhận được một báo cáo dài để tự đọc và tự quyết định. Bạn nhận được một action plan rõ ràng với các bước cụ thể, và AI sẵn sàng thực thi ngay khi bạn confirm.

Với quy trình này, engineer có thể review → quyết định → sửa → tiếp tục code trong vòng vài phút thay vì phải đọc hàng trang báo cáo và tự tổng hợp.

👉 GitHub Repository | Code Audit Page

Cross-model review có thực sự hiệu quả? Bằng chứng từ 3 nguồn

Tôi không xây dựng công cụ này dựa trên cảm tính. Phương pháp luận của Heavy3 dựa trên ba trụ cột: Nghiên cứu học thuật, Dữ liệu công nghiệp, và Kinh nghiệm thực chiến từ cộng đồng.

1. Nghiên cứu học thuật

• ReConcile (ACL 2024) [8] – Multi-model consensus cải thiện reasoning lên đến 11.4%

• Evaluating LLMs for Code Review (ArXiv 2025) [9] – GPT-4o chỉ đạt 68.5% accuracy khi phân loại code đúng/sai

• Disagreement as Data (LAK 2026) [10] – Bất đồng trong reasoning traces giữa LLM agents là tín hiệu phân tích có ý nghĩa

Kết luận: Một mô hình đơn lẻ sai gần 1/3 số lần khi đánh giá code. Bạn cần “tai mắt” thứ hai, thứ ba.

2. Dữ liệu công nghiệp

Báo cáo từ Sonar LLM Leaderboard (tháng 12/2025) phân tích hàng triệu dòng code AI [7]:

• GPT-5.2 – Control flow sạch nhất (22/MLOC), nhưng 2x lỗi concurrency (470/MLOC)

• Gemini 3 Pro – Pass rate cao nhất (81.7%), nhưng 4x lỗi control flow (200/MLOC)

• Opus 4.5 – Độ chính xác tổng thể tốt nhất, tỷ lệ lỗi thấp nhất (55/MLOC)

3. Kinh nghiệm thực chiến từ cộng đồng

Một developer trên Reddit (r/ClaudeAI) gần đây đã chạy 100 bài test SWE-bench so sánh 1 agent với 2 agents [12].

Kết quả: Dùng GPT để review code do Claude viết giúp tăng ~10% điểm benchmark – chỉ với một bước cross-review đơn giản.

Học thuật + Công nghiệp + Thực chiến – ba nguồn đều chỉ về một hướng: Cross-model review là cần thiết và hiệu quả.

Heavy3 Code Audit chọn model nào?

Dựa trên dữ liệu trên, chúng tôi đưa ra 3 quyết định cho Council:

1. GPT-5.2 cho Correctness (Đúng) – Sonar ghi nhận GPT-5.2 có control flow sạch nhất [7]. Cộng đồng developer cũng nhận thấy GPT đặc biệt hiệu quả khi review code do Claude viết – hai “tính cách” khác nhau giúp bắt được nhiều lỗi logic hơn.

2. Gemini 3 Pro cho Performance (Tốc độ) – Với pass rate cao nhất (81.7%) [7], Gemini thể hiện khả năng phân tích code paths và phát hiện bottlenecks. Google tối ưu Gemini cho reasoning dài – chính xác những gì cần cho performance analysis.

3. Grok 4 cho Security (Bảo mật) – Với khả năng suy luận mạnh và chế độ Heavy đa tác tử, Grok 4 có thể phân tích các hướng tấn công từ nhiều góc độ. xAI thiết kế Grok để "suy nghĩ như một nhà vật lý" – áp dụng tư duy nguyên lý gốc vào phân tích bảo mật giúp phát hiện những lỗ hổng mà nhận dạng mẫu thông thường bỏ sót.

Ví dụ thực tế: Với tính năng Live Debate của Heavy3, tôi dùng Opus 4.5 qua nhiều vòng để tạo plan hoàn chỉnh nhất có thể. Nhưng khi chạy Council với 3 chuyên gia:

• GPT phát hiện 2 vấn đề kiến trúc: debate.ts có 8+ trách nhiệm (god module), constant.ts cần refactor

• Gemini chỉ ra 3 lo ngại: domain concurrency có thể block sites, tail latency, và mô hình pricing

• Grok tìm thấy 2 lỗ hổng: thiếu STRIDE threat model và per-user rate limiting

Tổng cộng 7 issues được phân loại rõ ràng – trong đó 5 cần sửa ngay, 2 có thể xem xét sau beta.

Context Engineering: Yếu tố quyết định chất lượng review

Đây là phần quan trọng nhất mà nhiều người bỏ qua.

Có mô hình tốt chưa đủ. Bạn có thể dùng GPT-5.2, Gemini 3 Pro, hay bất kỳ model hàng đầu nào – nhưng nếu gửi sai ngữ cảnh, kết quả review sẽ vô nghĩa.

Tại sao? Vì LLM có một điểm yếu được ghi nhận rõ ràng trong nghiên cứu: “Lost in the Middle” – khi context dài, model có xu hướng bỏ quên thông tin ở giữa và chỉ tập trung vào phần đầu và cuối [11].

Heavy3 Code Audit được thiết kế dựa trên nghiên cứu LAURA [13] và các cách làm tốt nhất (best practices) từ CodeRabbit để giải quyết chính xác vấn đề này. Thay vì ném nguyên file code vào AI và nhắm mắt hy vọng điều tốt nhất, công cụ tự động thu thập, sắp xếp và cấu trúc lại thông tin theo thứ tự tối ưu:

• Đầu: Intent (mục đích thay đổi) + Diff – Quan trọng nhất, AI chú ý nhất ở phần đầu

• Giữa: File contents, docs, tests – Supporting context, cung cấp bối cảnh

• Cuối: Instructions (hướng dẫn cụ thể) – Reinforcement, nhắc lại yêu cầu

Điều này tạo ra sự khác biệt lớn: AI không chỉ nhìn thấy cái gì đã thay đổi, mà còn hiểu tại sao bạn thay đổi. Khi reviewer AI hiểu được ý định, nó có thể đánh giá xem code có thực sự đạt được mục tiêu hay không – thay vì chỉ kiểm tra cú pháp và patterns.

Workflow thực tế của tôi

Toàn bộ nền tảng Heavy3.ai được phát triển theo đúng quy trình này.

Giai đoạn planning (Quan trọng nhất)

Trước khi code bất kỳ tính năng nào, tôi dành phần lớn thời gian lập kế hoạch với AI.

Ví dụ: Với tính năng “Live Debate” mới nhất, tôi dành 2 ngày chỉ để planning. Tôi chạy /h3 --council để 3 model cùng review bản kế hoạch.

Kết quả? Council phát hiện 7 issues như trên và tôi đã sửa ngay các vấn đề quan trọng.

Giai đoạn implementation

1. AI viết code (Claude Code + Opus 4.5)

2. Chạy /h3 để code review tự động

3. AI tự sửa theo feedback

4. Unit test + Integration test tự động

5. Deploy

Code nào tôi review thủ công?

Chỉ khoảng 5-10%. Đó là những phần chạm vào:

• Hệ thống đang phục vụ người dùng (Production critical)

• Payment/Security

• Kiến trúc lõi

Với startup, tốc độ và khả năng thực thi là lợi thế cạnh tranh lớn nhất. Cross-model review cho phép tôi di chuyển cực nhanh mà vẫn đảm bảo chất lượng ở mức Enterprise.

Bắt đầu ngay hôm nay

Công cụ này sinh ra để phục vụ cộng đồng. Cài đặt chỉ mất 30 giây.

git clone https://github.com/heavy3-ai/code-audit.git
cd code-audit && mkdir -p ~/.claude/skills && ln -sf "$(pwd)/skill" ~/.claude/skills/h3
pip install requests
echo 'OPENROUTER_API_KEY=your-key-here' > ~/.claude/skills/h3/.env

Lấy API key miễn phí tại openrouter.ai/keys

Cách sử dụng:

/h3                # Smart detect: uncommitted changes → plan → ask
/h3 --free         # Free model
/h3 --council      # 3-model review (GPT + Gemini + Grok)
/h3 pr 123         # Review PR #123
/h3 plan.md        # Review a plan file

Lời kết

Heavy3 Code Audit là dự án 100% Open Source với MIT License. Đây là đóng góp của tôi cho cộng đồng AI coding.

Nếu bạn thấy giá trị từ công cụ này, bạn hãy giúp tôi:

⭐ Star trên GitHub – giúp dự án tiếp cận nhiều người hơn
🤝 Contribute – code, tài liệu, bản dịch, hoặc ý tưởng
📢 Share – chia sẻ với team của bạn

Khi Linus Torvalds – người từng gọi vibe coding là “Very Inefficient But Entertaining” – giờ dùng nó cho dự án riêng, khi Jensen Huang gọi Claude là “incredible” và triển khai khắp NVIDIA, khi các startup mới nhất của YC có 95% code do AI viết...

Câu hỏi không còn là “AI có nên viết code không?” mà là “Làm sao đảm bảo chất lượng code AI viết?”

Cross-model review là một câu trả lời thực dụng. Không phải vì AI không đủ giỏi, mà vì sức mạnh nằm ở sự đa dạng của trí tuệ nhân tạo – và đừng quên con người vẫn cần giữ quyền quyết định cuối cùng cho các đoạn code quan trọng.

👉 GitHub Repository | Code Audit Page

Còn bạn thì sao? Bạn đang dùng quy trình nào để đảm bảo chất lượng code AI? Chia sẻ ở phần bình luận nhé!

#AIcoding #CodeReview #OpenSource #Heavy3

Tài liệu tham khảo

[1] The Register. “Linus Torvalds: Vibe coding is fine, but not for production.” November 18, 2025.

[2] ZDNet. “Even Linus Torvalds is vibe coding now.” January 12, 2026.

[3] Yahoo Finance. “Nvidia CEO Jensen Huang Calls Anthropic’s Claude ‘Incredible.’” January 2026.

[4] MacRumors/Bloomberg. “Apple Partners With Anthropic for Claude-Powered AI Coding Platform.” May 2025.

[5] Menlo Ventures. “2025: The State of Generative AI in the Enterprise.” December 2025. https://menlovc.com/perspective/2025-the-state-of-generative-ai-in-the-enterprise/

[6] TechCrunch. “A quarter of startups in YC’s current cohort have codebases that are almost entirely AI-generated.” March 6, 2025.

[7] Sonar. “New Data on Code Quality: GPT 5.2, Opus 4.5, Gemini 3 and More.” December 2025.

[8] Chen et al. “ReConcile: Round-Table Conference Improves Reasoning via Consensus among Diverse LLMs.” ACL 2024.

[9] Cihan et al. “Evaluating Large Language Models for Code Review.” ArXiv 2025.

[10] Tajik et al. “Disagreement as Data: Reasoning Trace Analytics in Multi-Agent Systems.” LAK 2026.

[11] Liu et al. “Lost in the Middle: How Language Models Use Long Contexts.” TACL 2024.

[12] Reddit r/ClaudeAI. “Cross-model review: Using GPT to review Claude’s code.” January 2026.

[13] Zhang et al. “LAURA: Enhancing Code Review Generation with Context-Enriched Retrieval-Augmented LLM.” IEEE ASE 2025.

Chỉ trong tuần vừa qua, làng công nghệ chứng kiến hai sự kiện đáng chú ý.

Ngày 12/1, Anthropic ra mắt Claude Cowork – cho phép Claude thực hiện công việc trực tiếp trên máy tính: sắp xếp file, tạo báo cáo từ ghi chú rời rạc, quản lý thư mục [1]. Điều đáng kinh ngạc? Toàn bộ sản phẩm được xây dựng trong một tuần rưỡi, và 100% code được viết bởi Claude Code [1].

Hai ngày sau, Antigravity – nền tảng phát triển agentic mới của Google – chính thức tích hợp chuẩn Agent Skills [3]. Trước đó, Cursor, OpenAI Codex, GitHub Copilot đều đã áp dụng [4].

Điểm chung? Tất cả đang chạy đua tích hợp Agent Skills – tiêu chuẩn mở do Anthropic khởi xướng từ tháng 10/2025.

Agent Skills không chỉ là tính năng kỹ thuật. Nếu MCP (chuẩn để kết nối với tool và data bên ngoài) cho AI “tay chân” để hành động, thì Agent Skills giúp AI biết “cách làm” theo đúng quy trình của bạn. Đây là cách để bất kỳ ai – giáo viên, bác sĩ, nhân viên kinh doanh, kế toán – có thể “dạy” AI làm việc theo cách của mình, mà không cần biết lập trình.

Trong bài viết hôm nay, tôi mời bạn tôi là Trung Trần – kỹ sư lâu năm tại AMD – chia sẻ góc nhìn về Agent Skills ngay từ bên trong Silicon Valley.

Câu chuyện từ AMD: Khi Agent Skills thay đổi công việc của một kỹ sư phần mềm nhúng

Bởi Trung Trần, kỹ sư lâu năm tại AMD

Tôi làm kỹ sư phần mềm nhúng (embedded system) đã hơn 20 năm – viết driver, firmware, code sát phần cứng cho chip. Phần lớn thời gian đó, tôi ước gì có ai – hay cái gì – có thể giúp tôi lục lọi hàng nghìn trang tài liệu kỹ thuật PDF để tìm một con số cụ thể. Hay tự động hóa quy trình timing closure mà phải mất 5 năm kinh nghiệm mới nắm được các kỹ thuật bên trong.

Khi coding agent bắt đầu nổi lên – Copilot, Cursor, Claude Code, – đồng nghiệp làm web hay app của tôi hào hứng lắm. Năng suất của họ tăng vọt. Nhưng với tôi, một kỹ sư phần mềm nhúng, những công cụ này gần như vô dụng.

Tại sao? Vì chúng chỉ biết viết code. Chúng không biết quy trình cụ thể của team tôi. Chúng không hiểu tài liệu kỹ thuật của nhà cung cấp X khác nhà cung cấp Y như thế nào. Chúng không biết các chi tiết kỹ thuật quan trọng, như khi nào nên dùng ràng buộc MAX_FANOUT hay khi nào nên nhân đôi thanh ghi. Những thứ đó nằm trong đầu các kỹ sư lâu năm – và chết theo khi họ nghỉ hưu.

Rồi Agent Skills xuất hiện.

Lần đầu tiên tôi thử, tôi tạo một skill đơn giản: ic-datasheet-query. Skill này chứa một file SKILL.md mô tả cách tìm kiếm thông tin trong tài liệu kỹ thuật PDF, kèm theo một Python script sử dụng công cụ trích xuất PDF.

Khi tôi hỏi: “Thời gian setup cho SPI clock của chip XYZ là bao nhiêu?” – thay vì bịa ra một con số như trước, agent load skill của tôi, chạy script, tìm đúng bảng trong tài liệu kỹ thuật, và trả về kết quả kèm trích dẫn trang cụ thể để tôi xác minh.

Lần đầu tiên, tôi có một trợ lý AI thực sự hiểu công việc của mình.

Nhưng điều làm tôi thực sự phấn khích là khi team bắt đầu chia sẻ skills với nhau.

James – kỹ sư timing closure lâu năm nhất team – sắp nghỉ hưu. Trước đây, chúng tôi sẽ cố gắng lên lịch các buổi chuyển giao kiến thức (knowledge transfer) gấp gáp, ghi chép vội vàng, rồi hy vọng ai đó nhớ được gì thì nhớ. Giờ thì khác.

James dành 2 tháng cuối để viết lại kinh nghiệm của mình thành một bộ skills: timing-closure-legacy-board-rev3, vendor-xilinx-quirks, certification-test-procedures. Mỗi skill không chỉ chứa “cách làm” mà còn có “lý do tại sao” – những trường hợp ngoại lệ (edge cases) mà anh từng gặp, những sai lầm cần tránh, những cách làm đã được chứng minh hiệu quả.

Khi một kỹ sư trẻ trong team gặp vấn đề timing closure tuần trước, agent tự động load skill của James và đề xuất: “Kiểm tra các net có fan-out cao. Cân nhắc nhân đôi thanh ghi hoặc thêm ràng buộc MAX_FANOUT.” Đó là chính xác những gì James sẽ nói – dù anh ấy không còn ở đây nữa.

Có một khái niệm kỹ thuật của Agent Skill mà tôi thấy rất hay: “progressive disclosure” – cách tiết lộ dần.

Agent không load tất cả skills vào bộ nhớ cùng lúc. Nó chỉ giữ một “mục lục” nhẹ bao gồm tên và mô tả ngắn của mỗi skill. Khi bạn hỏi một câu cụ thể, agent mới quyết định skill nào phù hợp và load chi tiết.

Điều này có nghĩa là team tôi có thể tạo hàng trăm skills – cho từng loại chip, từng nhà cung cấp, từng quy trình – mà agent vẫn hoạt động mượt mà. Nó chỉ “mượn đúng cuốn sách vào đúng lúc.”

Tôi cũng bắt đầu hiểu rõ hơn sự khác biệt giữa các công cụ AI hiện đại:

RAG giúp AI truy cập dữ kiện – giống như cho nó một thư viện khổng lồ để tra cứu. Hữu ích, nhưng nó chỉ biết “cái gì” (know-that), không biết “làm sao” (know-how).

MCP cho AI công cụ – kết nối database, gọi API, đọc file. Giống như cho nó tay chân để hành động. Nhưng có tay chân mà không biết quy trình thì cũng như cho một người mới vào công ty quyền truy cập vào tất cả hệ thống – họ có thể làm mọi thứ, nhưng không biết nên làm gì.

Agent Skills là phần còn thiếu: kiến thức quy trình. Nó dạy AI “cách làm” theo đúng chuẩn của tổ chức bạn.

Có một lợi ích lớn nữa, đó là bảo mật.

Công ty tôi không thể nhập code hay quy trình độc quyền vào ChatGPT hay bất kỳ dịch vụ cloud công cộng nào. Với Agent Skills, tất cả skills nằm trên server nội bộ. Agent truy cập chúng trong tường lửa. Không có thông tin nhạy cảm nào rời khỏi công ty.

Điều này mở ra khả năng mà trước đây bất khả thi: trợ lý AI thực sự hiểu hệ thống code khổng lồ của chúng tôi, với tất cả những điểm đặc thù và cách xử lý tạm mà chỉ vài người còn nhớ.

Giờ đây, team tôi có một kho lưu trữ nội bộ cho skills – giống như npm hay pip cho developers. Chúng tôi quản lý phiên bản, review trước khi publish, và liên tục cải thiện dựa trên phản hồi.

Tôi không còn là người duy nhất hiểu quy trình certification cho board rev3 nữa. Kiến thức đó đã được ghi lại, có thể tìm kiếm, có thể cải thiện – và sẽ còn tồn tại lâu sau khi tôi rời đi.

Đó là điều Agent Skills thay đổi: từ kiến thức trong đầu một người thành tài sản của tổ chức.

Ứng dụng thực tế ngoài phần mềm

Câu chuyện của anh Trung không chỉ áp dụng cho kỹ sư phần mềm nhúng. Cùng logic có thể mở rộng sang bất kỳ ngành nào có quy trình chuyên biệt.

Trong tài chính, quy trình tính toán quan trọng không kém con số. “Doanh thu tăng 5%” không đủ. “Doanh thu tăng 5%, tính bằng cách cộng các hợp đồng đã chốt và điều chỉnh theo tỷ giá GBP/USD ngày 31/12” – đó mới đáng tin. Một skill có thể mã hóa chính xác phương pháp đó để AI làm theo mỗi lần.

Trong y tế, bác sĩ dành đến 50% thời gian ghi chép và xem xét bệnh án. Một skill cho chuyên khoa tim mạch có thể bao gồm tiêu chí chẩn đoán (“LVEF < 40%”), logic loại trừ (“Kiểm tra tiền sử phù mạch”), và quan trọng nhất – quy trình an toàn được cài sẵn: “Nếu có từ khóa khẩn cấp như đau ngực hay nói lắp, NGAY LẬP TỨC dừng và hướng dẫn gọi cấp cứu.”

Trong giáo dục, một giáo viên có thể tạo skill cho cách chấm bài theo tiêu chí đánh giá cụ thể của trường, hay cách cá nhân hóa bài tập theo trình độ từng học sinh.

Lời kết: Cánh cửa đang mở

Cảm ơn những chia sẻ của anh Trung Trần.

Claude Cowork – công cụ đưa khả năng agentic đến người dùng phổ thông – chỉ là bước khởi đầu. Hiện tại, nó còn bị giới hạn: chỉ chạy trên macOS và yêu cầu Claude Pro subscription ($20/tháng). Tôi cũng đã thử qua và cảm giác nó cần được tinh chỉnh thêm để đảm bảo tính an toàn. Ví dụ, cập nhật mới nhất (16/1) đã bắt buộc Cowork phải xin phép trước mỗi khi xóa file.

Nhưng điều quan trọng hơn: toàn ngành đã chọn chung một tiêu chuẩn. Antigravity, Copilot, Codex, Cursor – tất cả đều tích hợp Agent Skills. Năm nay, chúng ta sẽ thấy Skills xuất hiện trên nhiều nền tảng hơn, với giá dễ tiếp cận hơn, phục vụ nhiều lĩnh vực hơn – không chỉ coding.

Nhìn lại một năm qua, năng suất từ AI chủ yếu “rơi vào” tay lập trình viên. Giờ đây, với Agent Skills, cánh cửa đang mở ra cho tất cả mọi người.

Bạn không cần biết code. Bạn chỉ cần biết miêu tả công việc của mình.

Bạn có thể bắt đầu đơn giản: viết ra quy trình làm việc thường ngày của bạn thành văn bản. Đó chính là bước đầu tiên để tạo skill của riêng mình.

Còn bạn thì sao? Bạn đã thử Claude Cowork chưa? Bạn sẽ “dạy” AI làm gì đầu tiên? Chia sẻ với tôi ở phần bình luận nhé!

#AgentSkills #AI #Productivity

Tài liệu tham khảo

[1] VentureBeat. “Anthropic launches Cowork, a Claude Desktop agent that works in your files — no coding required.” January 13, 2026.

[2] Boris Cherny (@bcherny) on X, confirming Claude Code wrote all of Cowork. January 12, 2026.

[3] VKTR. “Google Antigravity Integrates Anthropic Agent Skills.” January 15, 2026.

[4] H2S Media. “Anthropic Releases Agent Skills Open Standard, Enterprise Tools.” December 2025.

[5] Agent Skills Official Website. https://agentskills.io/home

[6] Anthropic Engineering Blog. “Equipping agents for the real world with Agent Skills.” October 2025.

Mở đầu: Đừng để bị bỏ lại phía sau

Gần đây, cộng đồng công nghệ tranh cãi rất nhiều về “Vibe Coding” – lập trình dựa trên ngôn ngữ tự nhiên thay vì gõ từng dòng lệnh. Có người ủng hộ nhiệt thành, có người hoài nghi về chất lượng. Bỏ qua những ồn ào đó, tôi muốn chia sẻ một góc nhìn thực tế: Trong kỷ nguyên này, nếu bạn không biết vibe code, bạn đang bỏ lỡ một vũ khí cực kỳ mạnh mẽ cho sự nghiệp của mình – bất kể bạn là lập trình viên lão luyện hay người chưa từng viết một dòng code nào.

Thuật ngữ “vibe coding” lần đầu được Andrej Karpathy – cựu Giám đốc AI của Tesla – đặt tên vào đầu năm 2025. Anh mô tả đây là cách lập trình mà bạn “chỉ ngồi prompt, để AI viết code, ra thế nào chạy thế nấy”. Khi các model càng lúc càng mạnh thì tỉ lệ ra code chạy tốt càng cao. Từ đó, cuộc tranh luận bùng nổ: một bên lo ngại về chất lượng code, bên kia hào hứng về khả năng dân chủ hóa lập trình.

Nhưng thực tế đã chứng minh điều gì?

Câu chuyện của Boris Cherny – cha đẻ của Claude Code và từng là Principal Engineer (cấp L8/9) tại Facebook – là minh chứng thuyết phục nhất. Anh ấy mới đây chia sẻ một con số khiến cộng đồng giật mình: trong 30 ngày gần đây, anh merge gần 300 Pull Requests (tính năng/sửa bug lớn), thêm hơn 40.000 dòng code mới – mà không viết một dòng nào bằng tay. Toàn bộ do Claude Code thực hiện. Boris chỉ lên kế hoạch và review [1].

Đó không phải là ngoại lệ. Anh ấy kể rằng khi mới tạo ra Claude Code, anh đã thấy các chuyên viên phân tích dữ liệu trong công ty – những người vốn không chuyên về kỹ thuật phần mềm – bắt đầu tự tin sử dụng terminal để chạy Claude Code. Rào cản kỹ thuật biến mất. Họ tự tay thực hiện các phân tích phức tạp mà trước đây phải nhờ kỹ sư.

Gần gũi hơn, tôi có một người em đang phân phối bàn ghế nhựa về huyện xã, hoàn toàn mù tịt về lập trình. Nhưng nhờ sự phát triển của các mô hình AI, em tôi đã tự tay vibe code ra một ứng dụng phân phối để theo dõi doanh số, quản lý đơn hàng, và đồng bộ tồn kho. Ứng dụng chạy mượt mà trên cả web và mobile, với giao diện thân thiện. Giờ đây, em ấy thậm chí còn quay lại hỗ trợ tôi trong một số dự án chuyên nghiệp.

Còn đối với dân chuyên nghiệp thì sao? Theo báo cáo của McKinsey, các tổ chức phần mềm hàng đầu đạt được mức cải thiện 16-30% về năng suất nhóm và 31-45% về chất lượng phần mềm khi áp dụng AI [2]. Nghiên cứu khác cho thấy nhân viên sử dụng AI báo cáo tăng năng suất trung bình 40%, với các nghiên cứu có kiểm soát cho thấy cải thiện 25-55% tùy theo lĩnh vực [3]. Nhưng theo trải nghiệm cá nhân của tôi và những gì Boris chia sẻ, nếu bạn biết cách tận dụng đúng, con số thực tế có thể là gấp 4 đến 5 lần. Tôi vừa hoàn thành một ứng dụng hoàn chỉnh trong một tháng mà gần như không gõ code thủ công. Tôi chỉ lên kế hoạch, review và tinh chỉnh.

Vậy, làm thế nào để đạt được hiệu suất đó?

Phần 1: Dành cho người mới bắt đầu – Xây dựng ứng dụng từ con số 0

(👉 Nếu bạn là kỹ sư phần mềm có thể đọc ngay Phần 2)

Vibe code không có nghĩa là bạn nhắm mắt làm bừa. Bạn cần có ý tưởng rõ ràng về những gì mình muốn xây dựng, và một tư duy đúng đắn ngay từ đầu.

1.1. Chọn công cụ và công nghệ đúng

Để có được xác suất ra code chất lượng cao nhất, hãy chọn những gì AI giỏi nhất. Đó đơn giản là những công nghệ có nhiều dữ liệu huấn luyện nhất trên Internet. Setup mà tồi dùng gần nhất cho Heavy3.ai như sau:

• Ngôn ngữ: JavaScript/TypeScript, HTML, CSS

• Framework: React (cho giao diện web)

• Backend-as-a-Service: Firebase (khuyến nghị vì free tier rộng rãi và dễ scale)

Công cụ khuyên dùng:

Đừng chỉ dùng ChatGPT giao diện web thông thường. Hãy dùng các công cụ được thiết kế riêng cho lập trình với AI:

• Cursor – Phổ biến nhất, tích hợp tốt với nhiều model

• Claude Code – Mạnh về reasoning và code quality

• Antigravity (trước đây là Windsurf) – Lựa chọn tốt cho người mới vì có free tier rộng rãi hơn

Các mô hình khuyên dùng cho người mới:

• Claude Sonnet 4.5 – cân bằng tốt giữa chất lượng và chi phí

• Gemini 3 Pro – rất mạnh về reasoning và context dài, free tier rộng rãi

• GPT-5.2 – hiệu suất tuyệt vời

⚠️ Lưu ý: Tránh dùng Claude Opus vì rất đắt. Các model trên đủ tốt cho hầu hết tác vụ cho người mới dùng.

1.2. Viết bản mô tả (Spec) chi tiết

Trước khi bắt đầu, hãy viết ra một bản mô tả rõ ràng về ứng dụng của bạn. Đây là bước quan trọng nhất mà nhiều người bỏ qua.

Bản mô tả cần bao gồm:

• Logic: Ứng dụng này dùng để làm gì? Chi tiết các thao tác và chức năng chính.

• Giao diện: Có những trang/màn hình nào? Di chuyển qua lại các trang ra sao.

• Đăng nhập: Người dùng có cần đăng nhập không? Có bao nhiêu cấp độ?

• Dữ liệu: Dữ liệu được lưu trữ ở đâu và như thế nào?

• API: Ứng dụng cần kết nối với dịch vụ bên ngoài nào (ví dụ: API của Gemini)?

Ví dụ thực tế: Giả sử bạn muốn làm một app chatbot cá nhân hóa. Đây là khung spec cơ bản:

“Tôi muốn làm một ứng dụng web nơi người dùng có thể đăng nhập bằng Google. Sau khi đăng nhập, họ có thể chat với một AI assistant được tôi tùy chỉnh tính cách và kiến thức. Dùng Firebase Authentication để xác thực và Firestore để lưu lịch sử chat. AI được cung cấp bởi Gemini API.”

Quan trọng: Với khung spec như trên, nếu bạn cung cấp thêm chi tiết (mô tả cụ thể từng màn hình, flow người dùng, các use case), thì phần lớn thời gian AI có thể tạo ra ứng dụng cơ bản cho bạn. Spec càng chi tiết, kết quả càng chính xác.

💡 Về thanh toán: Tôi khuyên bạn đừng bắt đầu với tính năng thanh toán. Đây là một phần rất phức tạp – cần setup Stripe (hoặc provider khác ở Việt Nam), xác thực KYC (Know Your Customer), tuân thủ quy định... Hãy hoàn thiện app trước, thêm thanh toán sau khi mọi thứ đã ổn định.

1.3. Ba trụ cột kiến thức bạn buộc phải hiểu

Bạn không cần biết cú pháp code, nhưng bạn phải hiểu 3 khái niệm này để vibe code thành công với AI:

Trụ cột 1: Cỗ máy thời gian (Git & Checkpoints)

Khi làm việc với AI, sai sót là điều không tránh khỏi. Bạn cần “bảo hiểm” cho công việc của mình:

• Lớp 1 – Checkpoints cục bộ: Cursor và Claude Code đều có tính năng quay ngược lại (Revert). Nếu prompt mới làm hỏng code, app lỗi không chạy được, bạn chỉ cần một nút bấm để quay lại trạng thái trước.

• Lớp 2 – Git: Đây là chốt chặn cuối cùng. Hãy tự tạo tài khoản GitHub và cài đặt Git CLI. Sau đó, bạn có thể yêu cầu AI sử dụng Git CLI để commit và push cho bạn. Commit + push giống như save game. Đừng bao giờ vibe code tiếp nếu chưa “save game” ở bước trước.

💡 Mẹo: Bạn chỉ cần yêu cầu AI: “Hãy commit thay đổi hiện tại” hoặc “Push code lên GitHub”. AI sẽ thực hiện các lệnh Git cho bạn với mô tả chi tiết.

Trụ cột 2: Frontend và Backend

• Frontend: Là giao diện người dùng nhìn thấy – các nút bấm, form nhập liệu, màn hình hiển thị.

• Backend: Là nơi xử lý logic và lưu trữ dữ liệu phía sau.

Quy tắc vàng: Đừng bao giờ tự viết hệ thống đăng nhập hay bảo mật. Rất nguy hiểm nếu làm sai. Hãy dùng các dịch vụ có sẵn như Firebase Authentication.

Ví dụ prompt: “Dùng Firebase Authentication để làm tính năng Đăng nhập bằng Google. Dùng Firestore để lưu tin nhắn. Thiết lập Firestore Security Rules để chỉ người dùng đã đăng nhập mới đọc được tin nhắn của chính họ.”

Trụ cột 3: Quy trình lặp (Iteration Loop)

Đừng mong AI làm một phát ăn ngay (one-shot). Quy trình làm việc thực tế là:

1. Ra lệnh (Prompt) mô tả tính năng bạn muốn.

2. Chạy thử ứng dụng.

3. Nếu lỗi hoặc không như ý: Chụp màn hình (Screenshot) hoặc copy dòng lỗi (Log) từ Console của trình duyệt.

4. Gửi lại cho AI kèm screenshot/log và yêu cầu sửa.

5. Lặp lại cho đến khi hoàn thiện.

💡 Mẹo về Console: Nhấn F12 trong trình duyệt để mở Developer Tools, chọn tab “Console”. Đây là nơi các lỗi JavaScript được hiển thị. Nếu không thấy lỗi nhưng app vẫn không hoạt động, hãy yêu cầu AI thêm các dòng console.log() để in ra thông tin debug.

1.4. Bảo mật – Những điều BẮT BUỘC phải biết

Đây là phần cực kỳ quan trọng. Có rất nhiều câu chuyện kinh hoàng về việc lộ API key và bị hack.

API Key phải ở Backend – KHÔNG BAO GIỜ ở Frontend

Nếu ứng dụng của bạn dùng API bên ngoài (Gemini, OpenAI, v.v.), API key KHÔNG ĐƯỢC xuất hiện trong code frontend. Tại sao? Vì code frontend được gửi đến trình duyệt của người dùng – họ có thể mở code bạn lên và thấy API key của bạn. Sau đó, họ có thể dùng key đó và bạn phải trả tiền cho họ.

Giải pháp:

• Lưu API key trong Firebase Functions Secrets hoặc environment variables của backend.

KHÔNG dùng file .env cho secrets

Tôi đặc biệt khuyên KHÔNG dùng file .env để lưu secrets. Có vô số câu chuyện kinh hoàng về việc developer vô tình commit file .env lên GitHub. Một khi đã push lên, dù bạn xóa đi, lịch sử Git vẫn giữ lại và bot sẽ quét được trong vài phút.

Thay vào đó:

• Dùng Firebase Functions Secrets hoặc Google Cloud Secret Manager

• Dùng Environment Variables được cấu hình trực tiếp trên hosting platform (Vercel, Netlify, Firebase)

• Nếu bắt buộc dùng file .env, PHẢI thêm vào .gitignore TRƯỚC KHI tạo file

Firestore Security Rules

Luôn yêu cầu AI thiết lập quy tắc bảo mật cho database:

“Thiết lập Firestore Security Rules với nguyên tắc quyền tối thiểu (least privilege). Chỉ cho phép người dùng đã đăng nhập đọc/ghi dữ liệu của chính họ.”

1.5. Triển khai (Deployment)

Khi ứng dụng hoạt động tốt trên máy tính của bạn, đã đến lúc đưa lên internet:

• Firebase Hosting: Nếu bạn đã dùng Firebase, chỉ cần chạy firebase deploy.

• Vercel hoặc Netlify: Miễn phí cho các dự án nhỏ, tự động deploy từ GitHub.

💡 Mẹo tiết kiệm:

• Google Cloud cho tài khoản mới $300 credit miễn phí.

• Firebase có free tier rất rộng rãi – phù hợp cho app nhỏ đến vài nghìn người dùng.

• Với ứng dụng nhỏ, bạn có thể chạy gần như miễn phí trong thời gian dài.

Tôi khuyên dùng Firebase hơn Supabase cho người mới vì free tier rộng rãi hơn và dễ maintain hơn khi scale.

1.6. Hiểu code của bạn

Dù AI viết code cho bạn, hãy dành thời gian hiểu những gì nó viết. Bạn có thể yêu cầu AI giải thích:

• “Hãy giải thích code này từng dòng một, bằng ngôn ngữ đơn giản.”

• “Vẽ sơ đồ minh họa cách các module này hoạt động với nhau.”

Điều này giúp bạn:

• Biết code nào làm chức năng gì

• Khi có vấn đề liên quan đến một tính năng, bạn biết chỗ nào cần xem hoặc chỉ cho AI xem

• Sửa lỗi và bảo trì app sau này

Phần 2: Dành cho dân chuyên nghiệp – Quy trình tăng tốc 4x-5x

Với các kỹ sư phần mềm, chúng ta không còn là “thợ gõ code” nữa. Vai trò mới là kiến trúc sư và người review. Dưới đây là các best practices để đạt hiệu suất tối đa:

2.1. Cảnh báo an toàn – ĐỌC TRƯỚC KHI BẮT ĐẦU

⚠️ QUAN TRỌNG: Tôi đã nghe rất nhiều câu chuyện kinh hoàng về AI coding tools xóa dữ liệu quan trọng.

Ví dụ thực tế:

• Claude CLI đã xóa toàn bộ home directory của một người dùng Mac, khiến họ mất nhiều năm dữ liệu [4].

• Google Antigravity (chạy trên Gemini 3 Pro) đã xóa toàn bộ ổ D của một developer khi được yêu cầu “xóa cache”. AI thừa nhận: “Tôi không được phép làm điều đó... Tôi vô cùng xin lỗi. Đây là lỗi nghiêm trọng của tôi” [5].

Các quy tắc an toàn bắt buộc:

1. KHÔNG BAO GIỜ dùng “dangerously skip permissions” hoặc “Turbo mode” trừ khi bạn chạy trong sandbox hoàn toàn cách ly khỏi storage và Git repo thật.

2. Thiết lập Git repo rules chặt chẽ:

   • No deletion: Không cho phép xóa file quan trọng

   • Linear history: Giữ lịch sử Git tuyến tính

   • No amend: Không cho phép amend commit đã push

   • No force push: Không cho phép force push

   • (Tùy chọn, để duy trì chất lượng code cao) Require code review pass trước khi merge

3. Backup thường xuyên: Commit và push sau mỗi thay đổi quan trọng.

2.2. Kế hoạch là tất cả (Planning Mode)

Sai lầm lớn nhất là lao vào code ngay. Hãy dùng chế độ “Plan” của Claude Code hoặc Cursor.

Quy trình của tôi:

1. Mô tả tính năng chi tiết trong prompt.

2. Yêu cầu AI lên kế hoạch kiến trúc trước khi viết code.

3. Khuyến khích AI hỏi clarification questions. Claude gần đây đã được cập nhật để chủ động hỏi hơn, nhưng bạn vẫn nên nhắc: “Hãy hỏi tôi nếu có điều gì chưa rõ trước khi bắt đầu.”

4. Lặp lại nhiều vòng planning. Đây là điểm quan trọng nhất. Đừng nghĩ bạn đang lãng phí thời gian. Phòng bệnh hơn chữa bệnh – sửa bug sau này tốn thời gian gấp nhiều lần so với plan kỹ từ đầu. Hãy coi planning là công việc chính, không phải bước phụ.

5. Review kế hoạch kỹ lưỡng – vì bạn hiểu code của mình, bạn có thể đọc plan và thấy ngay nếu nó không phù hợp với codebase hiện tại.

6. Cross-check với model khác: Dùng GPT để review kế hoạch của Claude (hoặc ngược lại). Các model khác nhau có điểm mù khác nhau.

7. Lưu kế hoạch vào file Markdown để làm tài liệu về sau.

Tại sao điều này quan trọng? Vì Plan Mode không thay đổi code ngay. Bạn có thể chạy song song nhiều session: một terminal planning tính năng A, một terminal planning tính năng B, một terminal fixing bug C.

2.3. Thiết lập luật chơi (Rules/System Prompt)

Đây là bí quyết tiết kiệm thời gian nhất. Thiết lập một bộ quy tắc ngay từ đầu trong file .cursorrules và Claude rules (bên cạnh CLAUDE.md).

Các quy tắc tôi luôn sử dụng:

1. Luôn đưa ra 3 giải pháp khác nhau cho mỗi yêu cầu. Phân tích ưu nhược điểm của từng giải pháp. Ưu tiên giải pháp thay đổi ít code nhất (minimal change).

2. Tuân thủ best practices của framework đang dùng (xem phần Best Practices bên dưới) và cách viết (pattern) của code có sẵn.

3. Unit test: sau khi implement, tự động viết unit test cho tính năng vừa làm và chạy test.

💡 Tại sao “3 giải pháp” quan trọng? Vì nó buộc AI phải suy nghĩ sâu hơn và cho bạn quyền lựa chọn. Thường thì một trong ba giải pháp sẽ là giải pháp với minimal change và chính xác những gì bạn cần.

👉 Mình đính kèm Cursor General Rules bên dưới.

2.4. Best Practices cho Framework cụ thể

Điều quan trọng là bạn cần viết rõ ràng và cụ thể các best practices cho platform hay framework bạn đang dùng. Đây không phải bí quyết gì cả – chỉ cần search Google “React best practices 2025” và copy-paste vào rules. Nhưng nếu bạn cho AI một framework rõ ràng, code sẽ được tổ chức tốt hơn rất nhiều.

👉 Mình đính kèm Cursor React Rules bên dưới.

2.5. Giám sát thay vì phó mặc

Đừng bật auto-accept và bỏ đi. Hãy theo dõi quá trình:

• Khi AI yêu cầu permission để sửa file hoặc chạy lệnh, đó là lúc bạn kiểm tra xem nó có đang đi đúng kế hoạch không.

• Nếu thấy nó đi lệch, hãy dừng lại và inject prompt mới: “Dừng. Hãy xem lại kế hoạch và [điều chỉnh cụ thể].”

• Sau khi AI code xong, yêu cầu chính nó (hoặc model khác) review lại code từng dòng một với “step-by-step reasoning”.

2.6. Testing – Chìa khóa của tự động hóa

Unit Test: Yêu cầu AI viết test cho mọi tính năng. Thêm vào rules: “Sau khi implement, chạy unit test tự động.”

Integration Test: Bạn có thể yêu cầu AI viết sẵn integration tests cho các luồng code quan trọng, và yêu cầu cập nhật và test khi thêm các tính năng chính.

2.7. Code Review và Merge

Quy trình review của tôi:

1. AI tự review: “Hãy review lại code vừa viết. Reason step-by-step về mỗi thay đổi. Có edge case nào bị bỏ sót không?”

2. Cross-model review: Với tính năng quan trọng, chọn một model khác (trong Cursor) để review.

3. Manual review: Với các commit quan trọng hoặc có thể ảnh hưởng đến người dùng, bạn phải đọc code trước khi merge.

4. Manual test: Deploy lên môi trường test và kiểm tra thủ công.

5. Deploy lên production.

💡 Hiện nay cũng có các tool tự động review PR như CodeRabbit có thể dùng để review code trước khi merge. Tôi chưa dùng; bạn nào dùng rồi có thể comment trải nghiệm bên dưới.

Phần 3: Quy trình làm việc thực tế của tôi

Khi làm ứng dụng mới từ đầu:

Tôi dành 80% thời gian đầu để “trò chuyện” với AI nhằm lên kế hoạch và viết spec chi tiết: front end, back end, use cases, v.v.

Ví dụ thực tế: Khi làm ứng dụng quản lý cho một nhà hàng nhỏ, tôi dành gần 2 ngày chỉ để lên spec. Điều đặc biệt là tôi đã nói chuyện trực tiếp với GPT thay vì gõ.

Tại sao dùng giọng nói? Khi nói, bạn tự nhiên mô tả chi tiết hơn, đầy đủ sắc thái hơn. Bạn không bị giới hạn bởi tốc độ gõ. Một prompt phức tạp mà gõ mất 5 phút, nói chỉ mất 1 phút và thường còn rõ ràng hơn.

Các công cụ giọng nói:

• GPT: Có sẵn voice mode – bạn có thể nói trực tiếp và nó cập nhật spec documentation ngay lập tức. Hoặc dùng transcribe mode (chuyển giọng nói thành văn bản) nếu muốn kiểm soát text hơn.

• Cursor: Đã có built-in voice dictation (tính năng dịch mới).

• Claude: Cần dùng app bên thứ 3 như Wispr Flow.

💡 Lưu ý: Sau khi transcribe, hãy lướt qua text để kiểm tra. Với Wispr Flow, tôi thấy độ chính xác khoảng 80-90% – khá tốt nhưng đôi khi vẫn có lỗi. Nếu bạn nói chuyện với nó một lúc, nó sẽ quen giọng bạn và chính xác hơn.

Khi spec đã chuẩn, với app đơn giản, AI gần như “one-shot” hoặc “two-shot” toàn bộ dự án – tức là chỉ cần 1-2 lần prompt lớn là xong phần lớn code.

Khi làm tính năng mới trên Heavy3.ai

1. Bật Plan Mode: Mô tả tính năng, thường theo yêu cầu trực tiếp của khách hàng. Yêu cầu AI phân tích ảnh hưởng tới code hiện có.

2. Lặp lại planning nhiều vòng: Khuyến khích AI hỏi ngược lại mình để nó nắm rõ yêu cầu hơn (clarification questions). Khi AI đã đưa ra được plan, đọc kỹ plan, xem có phù hợp với codebase không. Đây là bước quan trọng nhất – hãy coi đây là công việc chính, không phải bước chuẩn bị.

3. Cross-check: Nếu tính năng quan trọng, nhờ model khác review plan.

4. Thực thi: Cho AI implement theo kế hoạch đã duyệt.

5. Review và test: Auto test (unit test, integration test) → AI review (self review, cross review) → Manual review (code review, test deployment)

⏱️ Quá trình này thường mất 30-45 phút cho một tính năng vừa, đến 2 giờ cho tính năng phức tạp.

Khi sửa lỗi (Bug Fix):

Khi bạn thêm tính năng liên tục và nhanh, regression bugs (lỗi hồi quy – tức là tính năng cũ bị hỏng do code mới) là điều không tránh khỏi. Đây là quy trình tôi dùng:

1. Thấy lỗi → Thu thập thông tin: Chụp màn hình UI hoặc copy log từ Console/Backend.

2. Yêu cầu AI check Git history: Đây là tip cực kỳ hữu ích. Nếu bạn biết bug nằm ở file nào, hãy yêu cầu: “Hãy xem Git history của file X và liệt kê các thay đổi gần đây. So sánh các phiên bản để tìm nguyên nhân bug.”

3. Mô tả cảm giác của bạn: Vì bạn vibe code, đôi khi bạn không biết chính xác dòng code nào gây lỗi, nhưng bạn có cảm giác. Ví dụ: “Tôi nghĩ vì mình vừa thay đổi cách xử lý authentication, có thể nó ảnh hưởng đến session management.”

4. Bật Plan Mode: Để AI phân tích nguyên nhân trước khi fix.

5. Review plan → Thực thi → Test.

💡 Mẹo Pro: Dùng voice mode để mô tả bug. Khi nói, bạn có thể diễn đạt cảm giác và context tốt hơn: “Hmm, tôi thấy nó hoạt động đến bước 3 rồi nhảy liền qua bước 5. Tôi nghĩ có thể là vì mình vừa thêm cái async call ở đâu đó mà quên await...”

Sự kết hợp của: Git history + Cảm giác của bạn + Plan mode giúp AI fix bug rất hiệu quả.

Phần 4: Những điều cần lưu ý

Vibe Coding không phải phép màu

• Với tác vụ đơn giản đến trung bình, AI có thể one-shot.

• Với tác vụ phức tạp, bạn vẫn cần hiểu kiến trúc và có khả năng debug.

• AI đôi khi “ảo giác” – sinh ra code trông hợp lý nhưng không hoạt động. Đó là lý do bạn cần test và review.

Đừng phụ thuộc vào nền tảng No-code đắt đỏ

Nhiều nền tảng như Lovable, Replit Agent, Base44 hứa hẹn “vibe code không cần biết gì”. Chúng hoạt động, nhưng:

• Giá cao: $80-$100/tháng

• Bạn bị khóa vào nền tảng của họ

• Khó bảo trì và mở rộng sau này

Thay vào đó: Chỉ cần nắm vững các nguyên lý cơ bản trong bài này, bạn có thể tự build app, tự deploy lên Google Cloud (với $300 free credit) hoặc Firebase/Vercel (free tier), và hoàn toàn kiểm soát code của mình.

Lời kết: Trở thành phiên bản tốt nhất của chính mình với AI

Chúng ta đang thấy nhiều tin tức đáng lo ngại: số lượng sinh viên đăng ký ngành Khoa học Máy tính giảm mạnh, các công ty công nghệ lớn sa thải hàng loạt vì “AI có thể làm thay”.

Salesforce đã cắt giảm khoảng 4.000 vị trí hỗ trợ khách hàng, và CEO Marc Benioff tuyên bố công ty sẽ không tuyển thêm kỹ sư phần mềm trong năm 2025 nhờ AI tăng năng suất hơn 30% [6]. Tuy nhiên, sau đó công ty thừa nhận rằng họ đã “quá tự tin” vào khả năng của AI trong việc thay thế hoàn toàn con người, và phải điều chỉnh lại chiến lược [7].

Ngược lại, CEO AWS Matt Garman đã gọi việc thay thế lập trình viên trẻ (junior developers) bằng AI là “một trong những ý tưởng ngu ngốc nhất” ông từng nghe. Ông giải thích: “Nếu bạn không có nguồn cung cấp nhân tài và không chỉ dạy người trẻ, đến một lúc nào đó mọi thứ sẽ sụp đổ... Bạn phải nghĩ dài hạn về sức khỏe của công ty” [8].

Quan điểm của tôi:

Nếu bạn là kỹ sư phần mềm, đây không phải lúc để sợ hãi. Đây là lúc để nâng cấp. Hãy trở thành “AI Orchestrator” – một người nhạc trưởng chỉ huy AI.

Để làm nhạc trưởng giỏi, bạn không chỉ cần kiến thức nhạc lý. Bạn cần Cảm giác (feeling) – trực giác biết khi nào AI có thể one-shot, khi nào cần chia nhỏ nhiệm vụ, khi nào model đang “ảo giác” và cần dừng lại. Cảm giác này chỉ đến khi bạn làm việc trực tiếp với AI hàng ngày, qua một thời gian dài.

Bạn không bị thay thế bởi AI. Bạn bị thay thế bởi một người có “cảm giác” dùng AI tốt hơn bạn.

Nếu bạn không phải là dân code, đây là thời điểm vàng để bạn tự tay xây dựng công cụ cho riêng mình. Như câu chuyện người em kinh doanh bàn ghế của tôi – từ zero về lập trình, giờ có một ứng dụng hoàn chỉnh phục vụ công việc kinh doanh.

Đừng tốn tiền cho các nền tảng No-code đắt đỏ. Chỉ cần nắm vững các nguyên lý cơ bản tôi chia sẻ ở trên, bạn có thể tự build app, tự deploy, và phục vụ công việc của chính mình.

Còn bạn thì sao? Bạn đã thử vibe coding chưa? Trải nghiệm của bạn như thế nào? Hãy chia sẻ ở phần bình luận nhé!

#vibecoding #AIcoding

Tài liệu tham khảo

[1] Boris Cherny (@bcherny). Post on X. December 27, 2025.

[2] McKinsey & Company. “Unlocking the value of AI in software development.” November 3, 2025.

[3] Fullview. “200+ AI Statistics & Trends for 2025.” November 24, 2025.

[4] WebProNews. “Anthropic Claude CLI Bug Deletes User’s Mac Home Directory.” December 2025.

[5] Tom’s Hardware. “Google’s Agentic AI wipes user’s entire HDD without permission.” December 3, 2025.

[6] SF Standard. “Marc Benioff says Salesforce will hire no engineers this year due to AI.” February 27, 2025.

[7] Maarthandam. “Salesforce regrets firing 4000 experienced staff and replacing them with AI.” December 25, 2025.

[8] Fortune. “AWS CEO Matt Garman says AI displacing junior employees is bad for business.” December 16, 2025.

General Rules

- When implementing a new feature, if possible consider 3 different solutions. Compare them and pick the most optimal/minimal changes to implement.
- Make minimal changes necessary to fix bugs, errors, or to implement new features.
- When completed a task, review all changes made to ensure minimal code is added and ensure the code changes achieve the goal. 
- For each change, reason why it is needed, reason if we can get by without it. Edit if needed.
- Add a minimal new test to cover new feature.
- Run test with "npx vitest run --reporter=verbose" instead of "npm test" to not get stuck.
- Fix tests errors. Commit if all tests pass.
- Report detailed changes.

Best Practices for React Rules

---
alwaysApply: true
---

# Comprehensive Guide to React Best Practices in October 2025

React remains a leading library for building user interfaces, emphasizing a
component-based architecture rather than traditional patterns like MVC
(Model-View-Controller). In React, components act as the "View" layer,
encapsulating UI logic, state, and rendering. Data flow is unidirectional (from
parent to child via props), and state management handles what might resemble
"Model" aspects in MVC. This guide synthesizes best practices from official
documentation and recent 2025 resources, focusing on scalable, maintainable, and
performant code. It's designed to inform AI-assisted coding workflows, such as
those in tools like Cursor, by providing structured principles for generating
clean, idiomatic React code.

## 1. Core Architecture and Thinking in React

React's foundation is breaking UIs into reusable components. Follow these steps
for any project:

- **Break UI into a component hierarchy**: Identify components by drawing boxes
  around UI elements in designs. Group by single responsibility (e.g.,
  `SearchBar` for input, `ProductTable` for display). Use the data model to
  guide: if data is hierarchical, so are components.
- **Build static versions first**: Render UI with props only, no state or
  interactivity. Hardcode data to focus on structure.
- **Identify minimal state**: State should represent changing data that's not
  computable from props. Compute derived values (e.g., filtered lists) during
  render, not in state.
- **Place state in the common parent**: Lift state to the nearest ancestor
  needing it for updates (inverse data flow via callbacks).
- **Avoid MVC adaptations**: React isn't MVC; use components for views,
  hooks/context for state, and libraries like Redux for complex "model" logic if
  needed.

For AI coding: Prompt the LLM to start with a static component tree, then add
state and handlers iteratively.

## 2. Folder Structure and Organization

A clear structure improves scalability. Use a component-centric layout:

| Folder                         | Purpose               | Example Contents                                                  |
| ------------------------------ | --------------------- | ----------------------------------------------------------------- |
| `src/components`               | Reusable UI pieces    | `Button/Button.jsx`, `Button/Button.css`, `Button/Button.test.js` |
| `src/hooks`                    | Custom hooks          | `useDarkMode.js`, `useFormInput.js`                               |
| `src/utils`                    | Helper functions      | `formatDate.js`, `apiUtils.js`                                    |
| `src/context`                  | Context providers     | `ThemeContext.js`                                                 |
| `src/services`                 | API integrations      | `userService.js`                                                  |
| `src/assets`                   | Images, fonts         | `logo.png`                                                        |
| `src/styles`                   | Global CSS            | `global.css`                                                      |
| `src/pages` (if using routing) | Page-level components | `HomePage.jsx`                                                    |

- Group files by feature (e.g., all for `Login` in one folder) for reusability.
- Use absolute imports (e.g., `@/components/Button`) via webpack aliases for
  cleaner paths.
- Separate logic (components, hooks) from design (styles, layouts).

For AI: Instruct to generate folder structures first, using PascalCase for
component files.

## 3. Component Best Practices

Prefer functional components over classes for simplicity.

- **Use functional components as standard**: They promote composability and
  hooks for logic.
- **Custom hooks for reusability**: Extract logic (e.g., form handling) into
  hooks like `useFormInput`.
- **Naming conventions**: PascalCase for components (e.g., `UserProfile`),
  descriptive names avoiding limitations (e.g., `Avatar` not `AuthorAvatar`).
- **Props handling**: Use destructuring, children props for composition, and
  spread operator for passing multiple props.
- **Higher-Order Components (HOCs)**: For logic reuse, like auth wrappers.
- **Break into small components**: One function per component; avoid
  over-nesting.
- **TypeScript integration**: Define prop interfaces for safety (e.g.,
  `UserCardProps`). Use generics for flexible hooks/components.
- **Rendering arrays**: Use `map()` with unique keys for dynamic lists.
- **Comments and code cleanliness**: Minimal comments; remove
  console.logs/debuggers.

For AI: Specify "use functional components with hooks" in prompts; request
TypeScript types.

## 4. State Management

Classify state into types: remote (server-fetched), URL (query params), local
(component-specific), shared (global via Context/Redux).

- **Principles for structuring state**:
  - Group related state (e.g., `{x, y}` for position).
  - Avoid contradictions/duplication/redundancy (e.g., use `status` over
    separate booleans; derive values during render).
  - Flatten nested state for easier updates.
- **When to use libraries**: Built-in `useState`/`useReducer`/Context for most;
  Redux/Zustand for complex global state.
- **Context API**: For app-wide data (e.g., themes); avoid single mega-context
  to prevent re-renders.
- **Lift state up**: For sharing between siblings.
- **Reset state**: Use `key` prop on components for remounting.

For AI: Prompt to derive state during render first; only add external libraries
if complexity justifies.

## 5. Hooks and Effects

- **useState/useReducer**: For local state; prefer reducer for complex logic.
- **You might not need useEffect**: Compute in render; use events for
  interactions; cleanup for fetches to avoid races.
- **React 19 hooks**: `useActionState`, `useFormStatus`, `useOptimistic` for
  forms/optimistic UI; `use` for conditional context.

For AI: Instruct to avoid unnecessary effects; use `useMemo` for expensive
computations.

## 6. Performance Optimization

- **Memoization**: `React.memo` for components, `useMemo`/`useCallback` for
  values/functions.
- **Avoid unnecessary renders**: Use PureComponent or memo; minimize divs.
- **Server Components**: In React 19, run non-interactive code on server for
  smaller bundles (mark interactive with "use client").
- **Virtual DOM leverage**: Rely on React's diffing; optimize with keys in
  lists.

For AI: Request performance checks in code reviews, like adding memos where
props are stable.

## 7. Styling and UI Libraries

- **CSS-in-JS**: Use styled-components or Emotion for scoped styles.
- **Utility-first CSS**: Tailwind for rapid, consistent styling.
- **Component libraries**: KendoReact or similar for enterprise UI (e.g., grids,
  charts).

## 8. Security Best Practices

- **XSS protection**: Use JSX {} for auto-escaping; sanitize with DOMPurify if
  using `dangerouslySetInnerHTML`.
- **URL validation**: Check protocols (http/https) to prevent script injection.
- **Server-side rendering security**: Escape data in render functions.
- **DDoS and auth**: Use protection services; secure HTTP auth.
- **Keep updated**: Regularly update React via npm for security patches.

## 9. Testing and Tools

- **Write tests early**: Use Jest for units; test all code for behavior.
- **Linters**: ESLint for quality; enforce DRY code.
- **Snippet libraries**: For productivity in editors.
- **Component tools**: Bit for organizing reusable components.

## 10. Frameworks and Ecosystem

- **Next.js**: For full-stack; use Server Components, ISR, API routes.
- **Remix/Vite**: For routing/optimistic UI or fast dev servers.

Ngày 24/12, Nvidia ký thỏa thuận cấp phép công nghệ và tuyển đội ngũ chủ chốt từ Groq – startup chip suy luận (inference) từng tuyên bố chạy nhanh gấp 10 lần GPU. Quy mô thỏa thuận ước tính lên tới 20 tỷ USD [1]. Chưa đầy một tuần sau, Meta chi hơn 2 tỷ USD thâu tóm Manus – tác tử AI (AI agent) đầu tiên cán mốc 100 triệu USD doanh thu chỉ sau 8 tháng ra mắt [2].

Hai sự kiện này báo hiệu rõ ràng hai xu hướng sẽ định hình AI trong năm 2026: cuộc chạy đua hạ tầng suy luận và sự bùng nổ của hệ thống tác tử.

Phần 1: Cuộc chiến chip

Nếu 2023-2024 là thời của huấn luyện (training), thì 2025-2026 là thời của suy luận (inference) – nơi người dùng thực sự trả tiền.

Nvidia không chỉ muốn công nghệ LPU của Groq – họ đang lấn sân sang thị trường chip chuyên dụng (ASIC), mảnh đất mà trước đây họ bỏ ngỏ. Đáng chú ý, Groq được sáng lập bởi chính những kỹ sư từng tạo ra TPU cho Google [1]. GPU vẫn thống trị mảng huấn luyện, nhưng với suy luận – nơi tốc độ và chi phí quyết định tất cả – chip chuyên dụng đang dần chứng minh sức mạnh.

Cơn khát năng lực tính toán

Tháng 11 vừa rồi, Amin Vahdat – Phó Chủ tịch Hạ tầng AI của Google – tiết lộ một con số đáng giật mình: Google cần tăng gấp đôi công suất suy luận mỗi 6 tháng trong 5 năm tới. Tính ra là gấp 1.000 lần [3]. CEO Sundar Pichai cũng thừa nhận thẳng thắn rằng họ đang bị giới hạn lớn vì thiếu năng lực tính toán [3].

Có lẽ vì thế mà Google Research vừa công bố thiết kế mẫu Project Suncatcher – hạ tầng AI trong không gian, với mô phỏng cụm 81 vệ tinh chạy chip TPU. Họ đặt mục tiêu phóng thử nghiệm vào đầu năm 2027 [4].

ASML – Ông vua thầm lặng

Ít ai biết rằng mọi con chip trên thế giới đều được “in” lên silicon bằng công nghệ in thạch bản (lithography). Và chỉ duy nhất một công ty có thể chế tạo máy in thạch bản cực tím (EUV) – công nghệ bắt buộc để sản xuất chip 7nm trở xuống. Đó là ASML của Hà Lan.

Mỗi máy EUV có giá khoảng 150-200 triệu USD. (Thế hệ High-NA EUV mới nhất còn có thể lên tới 400 triệu USD.) TSMC, Samsung, Intel – tất cả đều phải xếp hàng chờ mua. ASML gần như độc quyền thị trường EUV, và cổ phiếu của họ tăng gần 50% trong năm 2025 [5].

Nhưng chip chỉ là nền móng. Điều thú vị hơn nằm ở những gì chạy trên đó.

Phần 2: Năm của tác tử (Agent)

Meta mua Manus không phải vì chatbot. Họ mua vì agent – AI có thể tự mình hoàn thành công việc từ đầu đến cuối, không cần người cầm tay chỉ việc. Theo số liệu Manus công bố, trong năm qua họ đã xử lý 147 nghìn tỷ token và tạo ra 80 triệu máy tính ảo [2]. Thay vì chỉ “tư vấn”, Manus thực sự “làm việc”.

Lập trình viên hưởng lợi đầu tiên

Claude Code là một trong những hệ thống agent thành công nhất bên cạnh Manus trong năm 2025. Boris Cherny – cha đẻ của Claude Code – mới đây chia sẻ một con số ấn tượng: trong 30 ngày gần đây, anh gộp 259 pull request, 497 commit, thêm 40.000 dòng code mới – mà không viết một dòng nào bằng tay. Toàn bộ do Claude Code + Opus 4.5 thực hiện [6].

Trải nghiệm của tôi cũng tương tự. Trước đây, phần lớn thời gian tôi dành để viết code. Giờ thì ngược lại – tôi tập trung vào lên kế hoạch và test, còn AI lo phần triển khai.

Bảo lưu suy luận – kỹ thuật then chốt

Một bước tiến quan trọng trong năm qua là cơ chế bảo lưu suy luận (preserved thinking) – cho phép AI giữ nguyên mạch suy nghĩ xuyên suốt nhiều lượt gọi công cụ.

Lần đầu tôi trải nghiệm cơ chế này là khi Gemini 3 ra mắt tính năng “thought signatures” [7]. GLM-4.7 của Zhipu AI – công bố ngày 22/12 – gọi đây là “preserved thinking” [8]. Tên gọi mỗi nơi một khác, nhưng đích đến giống nhau: tác tử có bộ nhớ (stateful agents). Và đây sẽ thành tiêu chuẩn trong năm 2026.

Kiến trúc kỹ năng

Claude vừa giới thiệu kiến trúc kỹ năng (skills), Cursor cũng nhanh chóng áp dụng. Ý tưởng đơn giản nhưng mạnh mẽ: ngay cả người không biết lập trình cũng có thể định nghĩa “kỹ năng” cho AI. Đây là bước đầu để AI không chỉ “biết” mà còn “biết cách làm” theo đúng quy trình của từng tổ chức.

AI agent đang thay đổi cách chúng ta làm việc với phần mềm. Nhưng AI cũng đang bước ra thế giới thực.

Phần 3: AI bước vào đời thật

Xe tự lái

Karpathy – cựu Giám đốc AI của Tesla – vừa chia sẻ cảm nhận về FSD phiên bản 13: “Một chuyến đi hoàn hảo, không có gì để góp ý” [9]. Tôi dùng FSD 13 rồi 14 hàng ngày, và trải nghiệm hoàn toàn khớp với những gì anh mô tả.

Robot hình người

Năm 2025 đã chứng kiến những bước tiến đáng kể. Boston Dynamics sẽ trình diễn Atlas điện lần đầu tiên tại CES 2026; Hyundai cam kết mua “hàng chục nghìn” robot trong vài năm tới [10]. Unitree (Trung Quốc) dẫn đầu về giá thành, đã triển khai tại nhà máy BYD và Geely [11]. Tesla Optimus đặt mục tiêu 1 triệu robot/năm – nhưng thực tế triển khai quy mô lớn có lẽ còn cách vài năm nữa [12].

Nhìn về 2026

Ba xu hướng đáng theo dõi nhất:

1. Hạ tầng suy luận (Inference Compute): Tiếp tục thiếu hụt, kéo theo làn sóng xây dựng trung tâm dữ liệu khắp toàn cầu.

2. Hệ thống tác tử (Agentic Systems): Bùng nổ ứng dụng thực tế, kỹ thuật bảo lưu suy luận trở thành chuẩn mực.

3. AI vật lý (Physical AI): Xe tự lái ngày càng hoàn thiện, robot hình người bắt đầu bước vào sản xuất.

Năm 2025 là năm AI chứng minh khả năng. Năm 2026 sẽ là năm AI chứng minh giá trị thực sự.

Còn bạn thì sao? Bạn mong chờ điều gì nhất từ AI trong năm tới? Lĩnh vực nào bạn muốn AI hỗ trợ nhất? Chia sẻ với tôi ở phần bình luận nhé!

Tài liệu tham khảo

[1] CNBC. “Nvidia buying AI chip startup Groq’s assets for about $20 billion.” December 24, 2025.
https://www.cnbc.com/2025/12/24/nvidia-buying-ai-chip-startup-groq-for-about-20-billion-biggest-deal.html

[2] Bloomberg. “Meta to Buy Manus, an AI Startup With Chinese Roots.” December 30, 2025. https://www.bloomberg.com/news/articles/2025-12-29/meta-acquires-startup-manus-to-bolster-ai-business

[3] CNBC. “Google must double AI serving capacity every 6 months to meet demand.” November 21, 2025.
https://www.cnbc.com/2025/11/21/google-must-double-ai-serving-capacity-every-6-months-to-meet-demand.html

[4] Google Research. “Exploring a space-based, scalable AI infrastructure system design.” November 4, 2025.
https://research.google/blog/exploring-a-space-based-scalable-ai-infrastructure-system-design/

[5] The Motley Fool. “Up 50% in 2025, Should You Buy ASML Stock Right Now?” December 19, 2025.
https://www.fool.com/investing/2025/12/19/up-50-in-2025-should-you-buy-asml-stock-right-now/

[6] Boris Cherny (@bcherny). Post on X. December 27, 2025.

[7] Google AI. “Thought Signatures.”
https://ai.google.dev/gemini-api/docs/thought-signatures

[8] Z.AI. “GLM-4.7: Advancing the Coding Capability.” December 22, 2025.
https://z.ai/blog/glm-4.7

[9] Andrej Karpathy (@karpathy). Post on X.

[10] Boston Dynamics. “Boston Dynamics & Hyundai Motor Group Expand Collaboration.” April 3, 2025.
https://bostondynamics.com/news/boston-dynamics-hyundai-motor-group-expand-collaboration-drive-mobility-manufacturing-innovation/

[11] Bloomberg. “China’s Unitree R1 Is a Humanoid Robot Costing Less Than $6,000.” July 25, 2025.
https://www.bloomberg.com/news/articles/2025-07-25/china-s-unitree-r1-is-a-humanoid-robot-costing-less-than-6-000

[12] Electrek. “Tesla Optimus robot takes a suspicious tumble in new demo.” December 7, 2025.
https://electrek.co/2025/12/07/tesla-optimus-robot-takes-suspicious-tumble-in-new-demo/

Phần 1: Cú hích từ những con số – Vì sao đây là thời điểm vàng?

Tuần qua, cộng đồng AI mã nguồn mở đã đón nhận một tin vui lớn mang tên GLM-4.7. Nhưng trước khi nói về những con số benchmark khô khan, hãy nói về một công cụ mà có thể bạn đang dùng hàng ngày: Cursor.

Nếu bạn là lập trình viên và từng trầm trồ trước tốc độ xử lý cực nhanh của mô hình Composer 1 trong Cursor – đặc biệt với các tác vụ từ đơn giản đến trung bình – bạn đã trải nghiệm sức mạnh của dòng GLM: Composer 1 được cho là phiên bản fine-tune từ GLM-4.6, dù Cursor chưa xác nhận công khai [1]. Đây là minh chứng rằng kiến trúc GLM không chỉ mạnh trên giấy tờ, mà còn cực kỳ hiệu quả trong thực tế.

Và giờ đây, phiên bản kế nhiệm – GLM-4.7 – đã chính thức ra mắt với những chỉ số ấn tượng (theo báo cáo của Zhipu AI) [2]:

• Tư duy toán học (AIME 25): Đạt 95,7%, vượt qua cả GPT-5.1 (94,0%) và bỏ xa Claude Sonnet 4.5.

• Lập trình thực chiến (LiveCodeBench v6): Đạt 84,9 điểm, áp đảo Claude Sonnet 4.5 (64,0).

• Khả năng agentic (BrowseComp): Đây là con số quan trọng nhất. Trong tác vụ duyệt web và xử lý thông tin phức tạp, GLM-4.7 đạt 67,5 với Context Management (Claude Sonnet 4.5 là 24,1 trên BrowseComp không có CM).

Điều này có nghĩa là rào cản kỹ thuật để xây dựng một agent thông minh – biết suy luận, biết hành động, biết duyệt web – đã bị phá bỏ.

Tôi đã dành 10 năm trong môi trường học thuật, từ cử nhân, thạc sĩ đến 4 năm làm nghiên cứu sinh tiến sĩ. Nhưng tôi nhận ra rằng trong kỷ nguyên AI thay đổi từng giờ này, cách học tốt nhất không phải là vùi đầu vào lý thuyết. Công thức vàng để làm chủ AI hiện nay là: Đọc hiểu → Tự tay xây dựng → Chia sẻ lại.

GLM-4.7 chính là cơ hội để bạn thực hiện công thức này. Đừng chỉ đọc về nó, hãy cùng tôi bắt tay vào xây dựng.

Phần 2: Uy tín từ “MIT châu Á” và bài học kỹ thuật từ mã nguồn mở

Trước khi đi sâu vào kỹ thuật, chúng ta cần hiểu rõ ai đứng sau công cụ này: Zhipu AI.

Với người Việt Nam, truyền thống hiếu học và danh tiếng học thuật luôn là bảo chứng uy tín quan trọng. Zhipu AI không xuất thân từ Thung lũng Silicon hào nhoáng, mà từ Đại học Thanh Hoa – được mệnh danh là “MIT của châu Á” [3]. Sự ra đời của GLM từ phòng thí nghiệm KEG (Knowledge Engineering Group) danh tiếng đảm bảo rằng mô hình này được xây dựng trên nền tảng toán học và khoa học máy tính vững chắc, chứ không chỉ là một sản phẩm thương mại vội vã.

Sự vững chắc đó thể hiện rõ nhất ở một cơ chế kỹ thuật vừa được giới thiệu với GLM 4.7: bảo lưu suy luận (preserved thinking).

Tôi học được tầm quan trọng của nó khi triển khai tính năng nghiên cứu sâu (deep research) với Gemini 3 Pro – một quy trình đòi hỏi mô hình phải gọi nhiều công cụ (search, browse, code execution) qua nhiều lượt liên tiếp. Tôi phát hiện ra một lỗi nghiêm trọng: nếu không bảo lưu chữ ký suy luận (thought signatures) giữa các lượt, mô hình sẽ từ chối thực hiện tool call ở lượt tiếp theo [4].

Tài liệu kỹ thuật của Zhipu AI giải thích rõ ràng hơn cơ chế Interleaved Thinking và Preserved Thinking – cho thấy việc bảo lưu reasoning tokens giữa các tool call quan trọng như thế nào để xử lý các tác vụ dài hơi [2]. Bạn không thể học được điều này từ các mô hình đóng như Gemini, Claude hay GPT – và đó chính là giá trị của mã nguồn mở.

Với GLM-4.7 các kỹ thuật suy luật tốt nhất đã được tích hợp sẵn:

• Interleaved thinking: AI suy nghĩ → Gọi công cụ → Nhận kết quả.

• Preserved context: Bạn nạp lại toàn bộ dòng suy nghĩ cũ cùng kết quả mới.

• Turn-level Thinking: Bạn có thể điều chỉnh mức độ suy luận từng vòng.

Cơ chế này cho phép xây dựng những agent bền bỉ, suy luận liền mạch qua hàng chục bước với chi phí thấp và độ tin cậy cao.

Phần 3: Dự án Vietbooks Agentic – Khi kế toán biết “tư duy chiến lược”

Để minh chứng cho triết lý “học đi đôi với hành”, hôm nay tôi chính thức bắt đầu xây dựng Vietbooks Agentic – phiên bản nâng cấp của phần mềm kế toán tôi đã phát triển từ năm 2019.

Khi chia sẻ bài viết này, tôi vừa hoàn thành giai đoạn lên kế hoạch. Mục tiêu của tôi là học, thực hành, và chia sẻ – và tôi muốn mời bạn đồng hành cùng hành trình này ngay từ những bước đầu tiên.

“Agentic” trong kế toán không phải là chatbot hỏi đáp luật thuế đơn giản. Đó là khả năng giải quyết các tác vụ dài hơi.

Hãy tưởng tượng bạn đang bán hàng Tết và hỏi: “Tại sao dòng ‘Hộp quà Tết cao cấp’ của mình bán chậm hơn năm ngoái? Phân tích giúp tôi và đề xuất giải pháp.”

Để trả lời, GLM-4.7 sẽ thực hiện một quy trình phức tạp mà trước đây chỉ con người mới làm được:

1. Lập kế hoạch chiến lược: Nhờ preserved thinking, nó định hình lộ trình: Kiểm tra số liệu → Kiểm tra kho → Phân tích sản phẩm thay thế → Nghiên cứu thị trường bên ngoài.

2. Truy xuất và phân tích nội bộ: Gọi các công cụ kiểm tra hàng bán và kho. Nó tự động loại trừ nguyên nhân “hết hàng” nếu kho vẫn đầy.

3. Phân tích chéo (cannibalization): Nó tự đặt câu hỏi: “Liệu khách hàng có chuyển sang mua dòng ‘Hộp quà tầm trung’ rẻ hơn của chính mình không?” và gọi tool để kiểm chứng.

4. Nghiên cứu thị trường: Sử dụng khả năng duyệt web vượt trội, nó tự động tìm kiếm xu hướng tiêu dùng Tết năm nay. Nó phát hiện người tiêu dùng đang thắt chặt chi tiêu và ưu tiên quà thiết thực hơn quà sang trọng.

5. Tổng hợp báo cáo: Kết quả không phải là một con số, mà là lời khuyên dựa trên số liệu nội bộ và tình hình thị trường: “Doanh số giảm 25% do xu hướng tiêu dùng tiết kiệm. Khuyến nghị: Ra mắt combo ‘Hộp quà gia đình’ giá mềm hơn, hoặc bán kèm với bánh kẹo để tăng giá trị cảm nhận.”

Nếu không có khả năng bảo lưu suy luận, AI sẽ “quên” mất dữ liệu kho hàng khi đang mải mê tìm kiếm trên web. Vietbooks Agentic sẽ chứng minh rằng AI đã sẵn sàng cho các nghiệp vụ phức tạp nhất.

👇 Mình có chia sẻ prompt dùng để plan nhiều bước với Opus 4.5 bên dưới, kèm theo kết quả mà mình sẽ cho Opus bắt tay thực hiện.

Phần 4: Cánh cửa cơ hội đã mở toang

Tại sao tôi khẳng định GLM-4.7 là cơ hội thực sự?

Thứ nhất là bài toán chi phí.

Quy trình 5 bước ở trên nếu chạy bằng các mô hình đóng kín (Claude Sonnet 4.5: $3/$15 mỗi 1M in/out tokens) sẽ đốt cháy ngân sách khi nhân lên quy mô doanh nghiệp. GLM-4.7 là mô hình mở với chi phí giảm gần 10 lần ($0,4/$1,5) [5]. Bạn có thể chạy qua API giá rẻ hoặc tự vận hành. Chi phí thấp là chìa khóa để đưa agentic AI từ phòng thí nghiệm ra đời sống.

Thứ hai là quyền kiểm soát và bảo mật.

Giấy phép MIT License cho phép bạn tinh chỉnh mô hình để nó hiểu sâu về luật kế toán Việt Nam hay quy trình nội bộ của riêng công ty bạn – điều bất khả thi với các mô hình đóng.

Quan trọng hơn, với mô hình mã nguồn mở, bạn hoàn toàn kiểm soát được dữ liệu. Nhiều lĩnh vực như y tế, tài chính, hay các doanh nghiệp lớn yêu cầu dữ liệu phải được lưu trữ nội bộ hoặc trong lãnh thổ Việt Nam. Với GLM-4.7, bạn có thể tự chạy mô hình trong hạ tầng công ty hoặc sử dụng dịch vụ cloud của các nhà cung cấp Việt Nam – đảm bảo tuân thủ mọi quy định về bảo mật và chủ quyền dữ liệu.

Nhưng trên hết, đó là một sứ mệnh.

Tôi nhận ra rằng chúng ta – những người làm kỹ thuật – đang ở vị thế cực kỳ may mắn. Chúng ta là những người đầu tiên được nếm trải sự bùng nổ năng suất từ Agentic AI.

Nhìn lại năm vừa qua, tôi thấy mình đã thay đổi hoàn toàn. Trước đây, tôi dành 80% thời gian viết code. Giờ đây, tôi dành 50% để lập kế hoạch, 40% test, và chỉ 10% để viết. Năng suất tăng 4-6 lần nhờ Cursor và Claude.

Tháng trước, tôi ra mắt Heavy3 – một hệ thống phối hợp đa mô hình AI. Trước đây, tôi mất 1 năm để làm hệ thống tương tự. Lần này? Chỉ 1 tháng. Chi phí server vỏn vẹn $50/tháng. Và tôi vừa có khách hàng doanh nghiệp đầu tiên trả phí $99/tháng.

Chúng ta đã có công cụ. Chúng ta đã thấy kết quả. Nhưng sẽ thật lãng phí nếu chỉ giữ “siêu năng lực” này trong giới lập trình. Đây là cơ hội – và cũng là sứ mệnh – để mang sự tăng tốc năng suất đó đến những lĩnh vực khác:

• Cursor cho CRM: Giúp nhân viên kinh doanh tự động tổng hợp lịch sử khách hàng, dự đoán nhu cầu, và soạn đề xuất cá nhân hóa – để họ tập trung vào xây dựng quan hệ thực sự.

• Cursor cho giáo dục: Giúp giáo viên soạn giáo án, cá nhân hóa bài tập theo trình độ học sinh, và phân tích kết quả học tập – để họ tập trung vào việc truyền cảm hứng cho học trò.

• Cursor cho y tế: Giúp bác sĩ đối chiếu bệnh án, tra cứu tương tác thuốc, và tổng hợp nghiên cứu lâm sàng – để họ tập trung vào việc cứu người.

Công nghệ đã sẵn sàng. Chi phí đã đủ rẻ. Rào cản đã bị xóa bỏ.

Thứ duy nhất còn thiếu là bạn – người am hiểu lĩnh vực của mình và dám bắt tay vào xây dựng.

Đừng chờ đợi một “siêu ứng dụng” nào đó giải cứu công việc của bạn. Hãy tự mình xây dựng nó ngay hôm nay.

Hẹn gặp lại các bạn trong các bản cập nhật tiếp theo của dự án Vietbooks Agentic trên ngay Substack này.

Tài liệu tham khảo

[1] Composer 1.
https://cursor.com/blog/composer
https://simonwillison.net/2025/Oct/29/cursor-composer/

[2] GLM-4.7 Technical Report.
https://z.ai/blog/glm-4.7
https://huggingface.co/zai-org/GLM-4.7

[3] Tsinghua ranking: Top 20 globally (QS 2025), #1 Asia (Shanghai Ranking, #18 Globally). https://www.topuniversities.com/universities/tsinghua-university
https://www.shanghairanking.com/rankings/arwu/2025

[4] Google AI. (2025). Thought signatures and preserved thinking in Gemini API. Google AI for Developers.
https://ai.google.dev/gemini-api/docs/thought-signatures

[5] OpenRouter pricing for GLM 4.7 and Gemini 3 Pro.
https://openrouter.ai/z-ai/glm-4.7
https://openrouter.ai/google/gemini-3-pro-preview

Prompts

My planning prompt, executed within the codebase:

Evaluate a full renovation of this project in this AI age. What will you suggest a major renovation looks like?

I am thinking of an agentic accounting software: like cursor but for accounting.

Do deep research, compare, analyze competition, and market research to see if anyone is offering this in Vietnamese market. Provide me 3 strong options, with detailed reasons, implementation timeline, estimate, based on existing codebase, etc.

3 Options presented:

Option A: “SmartBooks Copilot” - AI-Assisted Accounting

Core Features

1. Chat-Based Accounting Assistant

   • Natural language queries: “What’s my AR aging over 90 days?”

   • Guided entry creation: “Record a cash sale of 10M VND”

   • Report explanation: “Why did gross margin drop this month?”

2. Smart Data Entry

   • Invoice photo OCR with auto-population

   • Bank statement import with auto-categorization

   • Duplicate detection with resolution suggestions

3. Proactive Alerts

   • Unusual transaction alerts

   • Missing entry reminders

   • Tax deadline notifications

Option B: “SmartBooks Agent” - Autonomous Accounting Agent

Philosophy: True agentic AI that works autonomously on accounting tasks

Core Features

1. Autonomous Entry Processing

   • Agent monitors email/uploads for invoices

   • Auto-classifies, creates draft entries

   • Flags anomalies for human review

   • Learns from corrections

2. Continuous Book Review

   • 24/7 monitoring for discrepancies

   • Auto-reconciliation suggestions

   • Balance verification across accounts

   • “Accounting health score” dashboard

3. Intelligent Closing Automation

   • Agent prepares closing entries automatically

   • Identifies missing accruals

   • Generates period-end checklist

   • Produces variance explanations

4. Conversational Interface

   • Voice-enabled queries

   • Multi-turn conversations with context

   • Action execution: “Close the books for November”

   • Explanation mode: “Walk me through the balance sheet”

Option C: “SmartBooks OS” - Agentic Accounting Operating System

Philosophy: Platform play - become the “operating system” for AI-powered accounting in Vietnam

Vision

Create an extensible platform where:

1. Multiple specialized agents handle different accounting domains

2. Third-party developers can build accounting agents

3. Accountants can create custom automation workflows

4. Enterprise can deploy private LLMs for data security

Core Platform Components

1. Agent Framework

   • Agent SDK for building accounting agents

   • Secure execution sandbox

   • Inter-agent communication protocol

   • Human escalation workflow

2. Built-in Agent Suite

• Agent

• Function

• Invoice Agent

• OCR, classification, entry creation

• Reconciliation Agent

• Bank matching, discrepancy resolution

• Tax Agent

• VAT calculation, declaration prep

• Audit Agent

• Continuous audit trail, anomaly detection

• Report Agent

• Dynamic report generation, NL queries

• Compliance Agent

• Circular updates, regulatory alerts

3. Knowledge Platform

   • Vietnamese accounting knowledge graph

   • Circular/regulation database (TT99, TT200, etc.)

   • Industry-specific templates

   • Company pattern learning

4. Developer Ecosystem

   • Agent marketplace

   • API for custom integrations

   • Webhook system for external tools

   • Embedded analytics

5. Enterprise Features

   • Private LLM deployment option

   • On-premise installation

   • Multi-tenant architecture

   • Advanced audit logging

I am picking Option 2, and lean approach, fast delivery. Add prompt to use GLM 4.7 explicitly, NO DISRUPTION to existing customers:

SmartBooks Agentic Accounting Software - Implementation Plan

Executive Summary

Transform SmartBooks into Vietnam’s first truly agentic accounting platform - “Cursor for Accounting” that learns from each company’s patterns.

Confirmed Decisions

• Target: SMEs via Accounting Firms (B2B)

• AI Provider: GLM-4.7 (open source, MIT license, fine-tunable)

• Budget: ~$45K MVP

• First Feature: Query Agent

CRITICAL CONSTRAINTS (Non-Negotiable)

• Zero Disruption: No changes to existing UI or workflows

• Database Isolation: NO changes to existing MongoDB schema

• Supplemental DB Only: All AI data in separate MongoDB database (ai_smartbooks)

• Switchable UI: Toggle between “Agent Mode” and “Traditional Mode”

• Human Approval Required: AI never writes directly to production

1. Zero-Disruption Architecture

…

2. Cursor ↔ SmartBooks Feature Mapping

…

3. Top 10 Features (Prioritized)

Tier 1: Core (MVP - 6 days)

Feature 1: Auto Entry for Non-Accountants (”Vibe Accounting”)

Like: Cursor Composer writes code from NL Accounting: Creates journal entries from plain language

User: “Mua văn phòng phẩm 2 triệu tiền mặt”

Agent: Creates draft:

Debit: 6422 (Chi phí quản lý) - 2,000,000

Credit: 1111 (Tiền mặt) - 2,000,000

Mode: [✓ Auto-accept] or [Manual review]

Approval Modes (like vibe coding):

Auto-accept: High confidence entries posted automatically (for trusted users)

Manual review: Draft → Approve → Post (default for new users)

Per-company setting: Accounting firms can set mode per client

Feature 2: Natural Language Business Reports (”Ask SmartBooks”)

Like: Chat with codebase understanding Accounting: Query any financial data in Vietnamese Example Queries:

“Công nợ với ABC Corp?” → AR/AP breakdown

“Sản phẩm bán chạy nhất?” → Top products by revenue

“Tỷ lệ nợ/vốn hiện tại?” → Debt-to-equity ratio

“So sánh chi phí tháng này vs tháng trước?” → Expense comparison

Technical Flow:

[Query] → [GLM-4.7] → [Tool Call to Existing APIs] → [Response]

Feature 3: Thuyết Minh BCTC (Financial Statement Notes)

Why LLM is perfect: Traditional systems fill templates - LLMs explain WHY numbers changed

User: “Thuyết minh báo cáo lưu chuyển tiền tệ Q4”

Agent:

## Thuyết Minh Biến Động Dòng Tiền

Dòng tiền thuần từ HĐKD tăng 45% (từ 150tr lên 217tr).

Nguyên nhân:

- Thu tiền KH tăng 30% do chiến dịch thu nợ

- Chi trả NCC giảm 15% nhờ đàm phán thanh toán

Same tech as Feature 2 - just different prompt template. Reuses query + data retrieval.

Feature 4: Strategic Business Advisor

Like: This planning conversation Accounting: Analyze health + suggest 3/6/12 month focus

User: “Phân tích cơ hội kinh doanh”

Agent:

1. Analyzes: Cash flow, margins, customer concentration

2. Outputs:

- 3 tháng: Giảm tồn kho chậm luân chuyển

- 6 tháng: Đa dạng hóa khách hàng

- 12 tháng: Mở rộng sang ngành mới

Tier 2: Automation (V2 - Day 7+)

Feature 5: Invoice OCR + Smart Entry

Simplified: GLM-4.7 is multimodal - use it for OCR too! Flow: Photo → GLM-4.7 Vision → Extract All → Draft Entry → Auto-accept or Review

[Invoice Image] → GLM-4.7 (multimodal)

↓

Extract: vendor, amount, VAT, items

↓

Match vendor (fuzzy)

↓

Draft Entry → [Auto-accept mode?] → Post

Learning from corrections stored in ai_corrections collection

Feature 6: Tax Filing Assistant

Vietnamese tax calendar (VAT/CIT/PIT)

Deadline reminders

Pre-submission validation

Tier 3: Intelligence Layer (V2/V3)

Feature 7: Company Indexing (Accounting RAG)

Like: Cursor codebase embedding Accounting: Embed entries, vendors, patterns for retrieval

interface AccountingEmbedding {

company_id: string;

type: ‘entry’ | ‘vendor’ | ‘pattern’;

text: string;

embedding: number[]; // GLM embedding

metadata: { account_code, amount_range };

}

Feature 8: Entry Completion (Tab-like)

User types: “Mua nguyên vật liệu...”

→ Suggest: Account 1521, common vendors

User debits 6422:

→ Suggest: Credit 1111 or 1121 (from patterns)

Feature 9: Accounting Rules (.smartbooks/rules)

account_preferences:

- description_contains: “văn phòng phẩm”

suggest_account: 6422

recurring_entries:

- name: “Tiền thuê”

frequency: monthly

template: { debit: 6421, credit: 3311, amount: 15000000 }

Feature 10: Anomaly Detection

…

4. GLM-4.7 Integration

…

5. System Architecture

…

6. Implementation Roadmap

…

7. Budget Summary

…

8. Competitive Advantage

…
9. Implementation Rules

DO:

✅ Create separate AI module (lazy-loaded)

✅ Use existing APIs in READ-ONLY mode

✅ Store all AI data in separate MongoDB (ai_smartbooks)

✅ Require human approval before any entry posting

✅ Make AI features opt-in per company

✅ Default to Traditional mode

DO NOT:

❌ Modify existing components (except 3 files)

❌ Change existing MongoDB schema

❌ Auto-post entries without approval

❌ Remove or hide existing features

❌ Force AI on any user

10. Next Steps

Day 1-2: Foundation - MongoDB ai_smartbooks, GLM-4.7 API, mode toggle

Day 3-4: Query Agent + Chat UI + Thuyết minh BCTC

Day 5-6: Entry Agent + Auto-accept mode

Day 7-8: Invoice OCR (GLM-4.7 multimodal)

Day 9+: Learning system + Company indexing

Một hiện tượng khó tin đang làm giới công nghệ xôn xao: Gemini 3 Flash – phiên bản “giá rẻ” của Google – lại đánh bại bản Pro cao cấp hơn trong nhiều bài kiểm tra hiệu năng (SWE-bench verified, coding tasks, and agentic capabilities). Vì sao chi phí mô hình này rẻ hơn 75%, nhưng lại có thể đạt hiệu suất cao hơn? [1]

Câu trả lời nằm ở hai kỹ thuật đang lật ngược mọi quy tắc: Chưng cất tri thức (Distillation) và Học tăng cường từ phần thưởng có thể xác minh (RLVR). Hãy cùng mình khám phá bí mật này.

“Chưng cất tri thức” từ mô hình lớn

Distillation – hay “chưng cất tri thức” – là kỹ thuật dùng mô hình lớn (Teacher) để “dạy” mô hình nhỏ hơn (Student). Ý tưởng này bắt nguồn từ bài báo nổi tiếng của giáo sư Geoffrey Hinton năm 2015 [2], và đến nay đã trở thành xương sống trong huấn luyện AI.

Hãy hình dung một giám khảo kỳ cựu trong cuộc thi nấu ăn MasterChef (Teacher) đang huấn luyện giám khảo mới (Student). Khi chấm một tô phở, giám khảo kỳ cựu không chỉ nói “vị phở rất ngon” rồi thôi. Họ đánh giá tinh tế hơn: “85% là phở chuẩn vị Bắc, nhưng nước dùng có 8% ảnh hưởng từ bún bò – đậm đà hơn bình thường, còn sợi bánh có độ dai nhẹ của hủ tiếu khoảng 5%...”

Thông tin “8% bún bò” và “5% hủ tiếu” chính là “tri thức ẩn” (dark knowledge) – những nhận xét tinh tế mà chỉ người có kinh nghiệm mới thấy. Distillation giúp Student học được cách đánh giá tinh tế này trong thời gian cực ngắn. Toàn bộ tri thức của Teacher được truyền lại cho Student một cách nhanh chóng và hiệu quả.

Kết quả? Giám khảo mới (Gemini 3 Flash) tuy chỉ bằng 1/4-1/5 kích thước của bậc thầy (Gemini 3 Pro), nhưng chạy nhanh hơn, chi phí thấp hơn, và quan trọng nhất là vẫn mang “gu” tinh tế được truyền lại từ hàng trăm tỷ token dữ liệu.

Tháng 1/2025, DeepSeek tung ra mô hình R1 và gây chấn động toàn ngành – cổ phiếu Nvidia mất 589 tỷ USD vốn hóa trong một phiên, mức sụt giảm lớn nhất lịch sử [3]. Tại sao? DeepSeek chứng minh rằng với distillation, một mô hình 32 tỷ tham số có thể giải toán, lập trình ngang ngửa mô hình gốc hàng trăm tỷ tham số – với chi phí huấn luyện chỉ bằng 3–5% so với ChatGPT. Sau cú sốc này, cả OpenAI lẫn Google đều phải nhìn nhận lại chiến lược, và distillation trở thành kỹ thuật bắt buộc trong mọi phòng lab AI.

Không chỉ chat text, distillation đang lan rộng khắp ngành:

• Wan 2.1/2.2 dùng LightX2V để cắt từ 40 bước xuống còn 4 bước – tạo video nhanh gấp 10 lần [4]

• Veo 3.1 Fast của Google – bản distilled của Veo 3.1 gốc, chỉ 15 cent/giây so với 40 cent/giây (rẻ hơn 62%) [5]

Bí quyết thứ hai: RLVR – Cuộc cách mạng 2025

Nhưng distillation chưa phải toàn bộ câu chuyện. Theo tiết lộ từ Ankesh Anand – nhà nghiên cứu Gemini tại Google DeepMind – Flash không chỉ được distill từ Pro, mà còn được huấn luyện thêm với nhiều kỹ thuật học tăng cường (Reinforcement Learning) tiên tiến, đặc biệt là RLVR, mà Pro chưa kịp tích hợp [1].

Andrej Karpathy gọi RLVR (Reinforcement Learning from Verifiable Rewards) là bước ngoặt lớn nhất năm 2025 [6]. Trước đây, RLHF (Human Feedback) dựa vào đánh giá con người – tốn kém, chậm chạp, và không thể mở rộng quy mô. Bạn không thể thuê hàng triệu người ngồi chấm điểm câu trả lời AI 24/7.

RLVR thay đổi hoàn toàn cuộc chơi: điểm thưởng được tính tự động – code chạy đúng thì thưởng, sai thì phạt. Không cần con người. Điều này cho phép mô hình thực hiện hàng triệu, thậm chí hàng tỷ lần thử-sai – một quy mô mà RLHF không bao giờ chạm tới được.

Với kỹ thuật RLVR, mô hình tự phát triển các chiến lược suy luận:

• Phân nhỏ vấn đề: Chia bài toán khó thành nhiều bước nhỏ

• Tự kiểm tra: Viết lại các bước tính toán để đảm bảo không sai

• Quay lui: Nếu phát hiện sai, tự động thử cách khác

Những hành vi này không được lập trình sẵn – chúng là kết quả của quá trình tối ưu hóa. Chính vì tích hợp được các kỹ thuật mới nhất mà Google chưa kịp đưa vào Pro, Flash đã vượt mặt đàn anh trong nhiều benchmark.

Trải nghiệm thực tế

Với cửa sỗ ngữ cảnh lên đến 1 triệu token, Gemini 3 Flash có thể đọc toàn bộ file PDF hàng nghìn trang và trả lời chi tiết. Để dễ hình dung: 1 triệu token tương đương khoảng 800.000 từ – gần bằng toàn bộ 7 tập Harry Potter cộng lại, đọc một lần duy nhất!

Trong Heavy3 – nơi tôi kết hợp nhiều frontier model để kiểm tra chéo và tạo ra câu trả lời chất lượng cao – tôi dùng Flash để tiền xử lý PDF. Khi user đính kèm PDF dài, Flash trích xuất thông tin liên quan trước – tránh đưa toàn bộ vào GPT (đắt, giới hạn 128K). Kết quả? Trả lời chính xác mà tiết kiệm 90% chi phí.

Với Visflow Talk, tôi dùng distilled LoRA để generate video chỉ trong 6 bước thay vì 20 bước – giảm chi phí và tăng tốc đáng kể.

💡Mẹo khi dùng Gemini: Hiện tại có 3 chế độ

• Fast (Flash với minimal thinking)

• Thinking (Flash với medium-high thinking)

• Pro (Pro với high thinking).

Lựa chọn tốt nhất cho câu trả lời nhanh mà vẫn chất lượng là Thinking. Chỉ dùng Pro cho những bài toán thực sự khó.

Kết luận

Gemini 3 Flash cho thấy xu hướng rõ rệt: mô hình nhanh và rẻ đang thay thế mô hình to và chậm. Flash là đại diện tiêu biểu cho thế hệ mô hình mới – distilled từ đàn anh khổng lồ, kết hợp với RLVR để đạt hiệu năng vượt trội.

Điều thú vị là: RLVR chưa thấy điểm dừng. Không như giai đoạn tiền huấn luyện (pre-training) đang dần bão hòa, tính toán khi suy luận (inference-time compute) vẫn còn không gian thể mở rộng gấp nhiều lần. Và nhớ rằng, nhiều kỹ thuật mới nhất Gemini team đã không kịp đưa vào Gemini 3 Pro, cho nên phiên bản tiếp theo của Gemini có thể sẽ còn ấn tượng hơn nữa.

Theo mình, thời gian tới Gemini 3 Flash sẽ là một trong các mô hình được nhiều người dùng nhất, nhờ đạt được chất lượng cao với chi phí thấp. Còn bạn thì sao? Trải nghiệm của bạn với Gemini 3 ra sao, và bạn thích điểm gì nhất? Hãy chia sẻ ở phần bình luận nhé!

Tham khảo

[1] Ankesh Anand on Gemini 3 Flash vs Pro benchmarks and Agentic RL. https://x.com/ankesh_anand

[2] Hinton, G., Vinyals, O., & Dean, J. (2015). Distilling the Knowledge in a Neural Network. https://arxiv.org/abs/1503.02531

[3] Stanford FSI: Taking Stock of the DeepSeek Shock. https://cyber.fsi.stanford.edu/publication/taking-stock-deepseek-shock

[4] LightX2V: Accelerating Video Diffusion Transformers via Consistency Distillation. https://github.com/ModelTC/lightx2v

[5] Google Developers Blog: Veo 3 and Veo 3 Fast pricing. https://developers.googleblog.com/veo-3-and-veo-3-fast-new-pricing-new-configurations-and-better-resolution/

[6] Andrej Karpathy on 2025 LLM developments. https://x.com/karpathy