Từ đầu năm đến giờ mình đưa agent vào được cho 3 hệ thống, cả của mình, lẫn của khách hàng, có mấy món học được muốn chia sẻ kinh nghiệm để các bạn chuẩn bị làm agentic system có thể tham khảo, tránh mất thời gian mò đường như mình.
1. Khi nào thì cần agent? Khi nào thì chỉ cần workflow?
Workflow là luồng nghiệp vụ nào đó đi từ A -> B -> C, có thể có rẽ nhánh tùy điều kiện, nhưng cơ bản là nó luông đi về phía trước và đến 1 mốc nào đó thì sẽ hoàn thành. Với dạng workflow này, bạn có thể dùng AI cho các bước mà bạn cảm thấy cần. Ví dụ: workflow vẽ chart, thì AI chỉ cần sinh ra data đúng format yêu cầu của chart là xong, các phần còn lại như màu mè, kiểu chart... thì có thể cố định hoặc user được chọn. Loại workflow kiểu này có khá nhiều trong các tình huống sử dụng thông thường và trong các hệ thống vận hành của doanh nghiệp. Khi đó bạn chỉ cần bổ sung AI vào những điểm mà bạn thấy có thể giúp tiết kiệm được thời gian, thao tác của user. Xong, không cần agent gì cho phức tạp hết. Gọi model, lấy kết quả, parse kết quả (nên kêu model AI trả kết quả theo format hoặc schema cố định). Xong.
Còn với những luồng nghiệp vụ mà nó không phải là "luồng", nó là những bước khác nhau, cần phải làm nhiều việc tuần tự hoặc đồng thời mà không có bước cố định, hoặc các bước cố định quá rộng, thì bạn hãy nghĩ tới agent. Ví dụ: user hỏi "phân tích cho tui số lượng hợp đồng chưa tất toán". Yêu cầu này rộng quá, nó có thể phải đi lấy hợp đồng, lấy thông tin của khách hàng, lấy thông tin sản phẩm, rồi mới đưa kết quả, có khi là so sánh, có khi là nhận xét tùy điều kiện. Hoặc một thao tác là "Chèn các video B roll tương ứng vào A roll này", thì nó phải đọc từng đoạn của video, tìm video tương ứng, xem thử đoạn nào match tốt, chèn thử, xong xem xét, rồi có khi không hợp thì phải chèn lại B roll khác. Khi đó bạn hãy nghĩ tới agent.
Một ví dụ nữa mình cũng thấy agent phát huy tốt, là yêu cầu "dựng dashboard làm việc X cho đối tượng sử dụng Y", cái này mình triển khai cho Elton Data luôn, thì agent nó làm tốt hơn là workflow cố định (ban đầu làm workflow, sau không ổn mình chuyển thành agentic). Agent nó có sự tự do cao hơn, nên khi nó làm, nó sẽ thử được nhiều thứ hơn, chưa đúng thì nó quay lại để thử lại nữa.
Ý quan trọng nhất: chưa chắc bạn cần agent, cái nào đơn giản thì gắn model vô 1 vài khâu là ok. Còn bạn thấy nó vẫn chưa đủ tốt thì hãy thử tới agent.
2. Một vài tình huống trong các enterprise system mà agent giúp được
Mình lấy ví dụ với chính hệ thống CRM - Mua hàng - HRM mà công ty mình đang vận hành cho dễ hình dung với các use case dành cho enterprise nha. Mọi thứ về UI, nghiệp vụ, phân quyền... đều có và theo truyền thống, không có gì lạ cả. Có chia team, có role, có permissions cho từng tính năng, ai được làm gì, không được làm gì.
Có điều mỗi khi cần làm gì đó, user của mình đang phải thao tác quá nhiều bước, và đôi khi quên cái này, hụt cái kia, hoặc chỉ đơn giản là người ta chọn lộn item trong combo box thôi. Con người mà, chuyện này bình thường.
Thế nên vừa rồi mình thử làm 1 cái giao diện chat, tất cả mọi tính năng của hệ thống đều có thể dùng agent để làm được, chỉ là mình gõ prompt thay vì click qua chừng chục cái menu thôi. Và nó làm ngon nha, tiết kiệm được nhiều thời gian chọn chọn lắm. Ví dụ: attach file A, B, C vào hợp đồng số X, sau đó xuất hợp đồng đó thành hóa đơn, và xuất hóa đơn (đỏ) nháp để khách check. Nó làm rẹt rẹt nhanh gọn lẹ luôn.
Hoặc một use case khác mình học từ khách hàng của mình: làm knowledge base ở cấp công ty về cách tối ưu ads, tối ưu nhập hàng, cũng như các quy trình nội bộ. Nhân viên có thể hỏi đáp nhanh chóng.
Đây là ý tưởng thôi, bạn có thể adapt nó lại phù hợp với tình huống và hệ thống của bạn nhé.
3. Technical nè: agent nó chạy như thế nào?
Mọi chuyện sẽ bắt đầu khi user gõ câu prompt vô giao diện chat. Khi đó một worker sẽ tiếp nhận câu prompt này, nó dùng prompt + các thông tin nó có để xây dựng thành "context". Cả cục context bự này sẽ được gửi cho model, và bạn lấy kết quả mong muốn ra. Thường thì mình sẽ show cả phần thinking của model để user có cảm giác phản hồi tốt hơn, không có cảm giác hệ thống "chậm". Còn phần chạy chữ thì dùng SSE bắn từ server rồi render ra giao diện, này thì easy.
Các hệ thống mình thiết kế thường phải thay được model, nên mình hay làm dạng factory để chọn model nào cũng được, thích self host, OpenAI, Claude, Gemini đều chơi được hết. À, với các case này, Gemini tốt lắm nhé, đừng coi thường bạn :D vừa tốt vừa nhanh mà vừa rẻ.
Nhưng mà model thì nó như cái não thôi, agent nó cần tay chân, nó cần "tool" để thực hiện. Trong ví dụ với hệ thống CRM HRM của mình, tool này sẽ bao gồm những thứ như "contract_get, contract_edit", hay "convert_contract_to_invoice", hoặc "create_draft_einvoice", hay "sales_report". Còn trong Elton DataUtils, nó là "execute_sql", "metrics_search", hay "write_dashboard_specs". Các tool này là đặc thù hệ thống của bạn nhé, bạn sẽ làm người biết rõ nhất bạn cần tool gì.
Các tool được chứa trong 1 registry, cần cái nào thì model lấy tool đó ra mà xài. Mình thường hay để 1 số "Core tool" quan trọng lúc nào cũng nhét vào để agent nó biết mà xài cho đúng, giảm tình trạng chọn sai hoặc không chọn được tool.
Với những hệ thống vận hành, thường mình sẽ không để tool tự ghi ngay kết quả vào DB, mà nó sẽ hiển thị lên giao diện kiểu như "À đây là cái hóa đơn tao sẽ edit, thông tin edit là như này, mày check đi". User thấy đúng rồi thì nhấn approve, nó sẽ tự commit kết quả xuống (và có lưu change log, versioning để có gì cần thì revert lại được).
Agent nó sẽ gọi nhiều tool khác nhau để hoàn thành việc của nó, cho tới khi nào nó xong thì thôi chứ thường mình sẽ không có giới hạn gì thêm (ngoài việc mình giới hạn tầm 200 lượt mà chưa xong thì ngắt vì lúc đó chắc chắn có vấn đề, còn bạn tùy chỉnh cái này hoặc không có luôn cũng được). Phần gọi đi gọi lại các tool, cũng như các phần suy luận, mình thấy người ta hay gọi là agent loop, tool loop, agent trace... Mình thì thích chữ agent tool loop, dễ hiểu dễ hình dung.
Có một vấn đề hay gặp khi loop chạy lâu (gọi là long-horizon task), đó là context window của model sẽ đầy lên vì context của bạn càng lúc càng có nhiều thông tin. Đó là lúc bạn cần chạy memory compaction để "nén" context lại, giống như tính năng compact của Claude Code vậy đó. Mình bắt chước cách này, thấy cũng hiệu quả. Cơ bản nó là việc bạn quyết định khi nào thì bỏ bớt cái gì, hoặc chuyển các đoạn chi tiết thành các đoạn tóm tắt để model vẫn hiểu cái gì đã diễn ra. Phần này tùy task sẽ cần chỉnh tới chỉnh lui cho phù hợp.
4. Agent Memory
Cũng như người, agent nó cũng cần có bộ nhớ để lưu các thông tin như "Khi tao nói tìm thông tin khách X, thì khách đó có 2 pháp nhân trong hệ thống là A và B", hoặc "Tui muốn hệ thống hiển thị dạng bảng, vì tui quen coi bảng", hoặc ở cấp độ công ty cũng sẽ có những thứ cần lưu lại. Thì memory của agent cơ bản có mấy thứ sau:
+ Lịch sử chat: quá đơn giản, chắc chắn phải lưu rồi, khỏi giải thích nhiều
+ Long-term memory: các thông tin có thể inject vào prompt như các ví dụ mình để ở trên. Thường mình sẽ chia làm 2 cấp: memory của từng user (vì họ có thói quen khác nhau), và memory ở cấp tổ chức (ai cũng xài chung).
Nếu quy mô nhỏ, mấy cái long term memory nhét thẳng dô prompt / instruction là xong, còn nếu bạn có rất nhiều memory thì nên cho agent fetch cái nào tương ứng nha, chứ nhét hết cũng phiền.
Trong cái sơ đồ mình có mô tả sơ sơ mấy cái luồng gọi giữa các thành phần để các bạn dễ hiểu nha. Nhớ ra được gì thêm mình share tiếp nhé.