Bài 17 — Building AI agents — Beyond chat — Building AI-Powered Products

Mở đầu — vì sao bài này quan trọng

Trong những bài trước, bạn đã học cách xây dựng chatbot (Bài 15) và copilot (Bài 16). Cả hai đều mạnh, nhưng chúng có một điểm chung: người dùng vẫn phải cầm tay dẫn dắt từng bước. Chatbot chờ bạn hỏi rồi trả lời. Copilot gợi ý ngay bên cạnh công việc bạn đang làm, nhưng bạn vẫn là người bấm nút, là người ra quyết định cuối cùng.

Agent là một bước nhảy về chất. Thay vì "trả lời một câu hỏi", agent theo đuổi một mục tiêu (goal), tự lập kế hoạch, tự gọi công cụ (tools), tự quan sát kết quả và lặp lại vòng lặp đó cho đến khi hoàn thành — hoặc đến khi biết mình cần dừng lại hỏi con người. Đây chính là ranh giới giữa "AI trả lời" và "AI làm việc".

Vì sao bài này quan trọng với người làm sản phẩm? Bởi vì 2025-2026 là giai đoạn thị trường dịch chuyển mạnh từ chatbot sang agent. Những sản phẩm tạo ra giá trị lớn nhất không còn là "hộp chat biết trả lời" mà là "nhân viên số biết hoàn thành công việc": tự đặt lịch, tự xử lý đơn hàng, tự viết và chạy code, tự nghiên cứu rồi tổng hợp báo cáo. Nếu bạn hiểu sai bản chất agent, bạn sẽ xây một chatbot phức tạp và gọi nó là "agent" — vừa tốn tiền, vừa khó kiểm soát, vừa không tạo ra giá trị thật. Bài này giúp bạn phân biệt rõ và biết cách xây agent đúng cách, an toàn, có kiểm soát.

Khái niệm cốt lõi

Chatbot vs Agent — khác biệt bản chất

Hãy nhìn thẳng vào sự khác nhau:

Chatbot: nhận một message → sinh một câu trả lời → kết thúc. Một lượt vào, một lượt ra. Không có hành động ngoài việc "nói".
Agent: nhận một mục tiêu → lặp qua vòng lặp Suy nghĩ → Hành động → Quan sát cho đến khi đạt mục tiêu.

Ví dụ minh họa:

Chatbot: User: "Vé máy bay Hà Nội - Đà Nẵng ngày 5/7 giá bao nhiêu?" Bot: "Bạn có thể kiểm tra trên các trang bán vé như..." (kết thúc — chỉ nói, không làm)

Agent: User: "Đặt cho tôi vé Hà Nội - Đà Nẵng ngày 5/7, dưới 2 triệu, bay sáng." Agent → gọi tool search_flights(HAN, DAD, 2026-07-05) → quan sát: 8 chuyến, lọc còn 3 chuyến bay sáng dưới 2 triệu → gọi tool check_seat_availability(chuyến VN123) → quan sát: còn chỗ → gọi tool create_booking(...) nhưng DỪNG lại xin xác nhận thanh toán → "Tôi tìm được chuyến VN123 lúc 7h30, giá 1.85tr. Xác nhận đặt?"

Agent không chỉ trả lời — nó hành động trong thế giới thật qua các công cụ, và tự điều chỉnh dựa trên kết quả nó quan sát được.

Vòng lặp Agent (Agent Loop)

Trái tim của mọi agent là một vòng lặp. Kiến trúc phổ biến nhất hiện nay là ReAct (Reasoning + Acting):

Reason (Suy nghĩ): LLM nhìn vào mục tiêu và trạng thái hiện tại, quyết định bước tiếp theo.
Act (Hành động): LLM chọn một tool và tham số để gọi (ví dụ search_web("giá cà phê Robusta 2026")).
Observe (Quan sát): hệ thống thực thi tool, trả kết quả về cho LLM.
Lặp lại: LLM đưa kết quả vào ngữ cảnh, suy nghĩ tiếp — cho đến khi nó quyết định "xong" và trả lời cuối cùng.

Điểm mấu chốt: LLM không tự chạy tool. Nó chỉ đề nghị gọi tool (thường qua cơ chế function calling / tool use của model). Code phía bạn — thường gọi là agent runtime hoặc orchestrator — mới là nơi thực sự thực thi, kiểm soát và đưa kết quả quay lại.

Bốn thành phần bắt buộc

Một agent nghiêm túc cần đủ bốn thứ:

Model có khả năng tool use / function calling (Claude, GPT-4o, Gemini... — xem lại Bài 6). Model là "bộ não" ra quyết định.
Tools — các hàm agent được phép gọi: tìm kiếm, đọc/ghi database, gọi API, gửi email, chạy code. Mỗi tool cần mô tả rõ khi nào dùng và tham số gì.
Memory / State — ngữ cảnh về những gì đã làm. Ngắn hạn (trong một phiên: lịch sử vòng lặp) và dài hạn (qua nhiều phiên: dùng vector store, xem Bài 14).
Control loop + Guardrails — cơ chế dừng, giới hạn số vòng lặp, ngân sách chi phí, và các điểm cần con người phê duyệt (human-in-the-loop).

Ba mức tự chủ (autonomy levels)

Đừng nhảy thẳng lên mức cao nhất. Hãy nghĩ theo bậc thang:

Mức 1 — Tool-augmented: model chỉ gọi một vài tool trong một lượt (ví dụ RAG có gọi search). Gần với chatbot.
Mức 2 — Agent có giám sát: agent lập kế hoạch nhiều bước nhưng dừng lại xin con người phê duyệt ở các hành động rủi ro (thanh toán, gửi email cho khách, xóa dữ liệu).
Mức 3 — Agent tự chủ: agent chạy nhiều bước không cần con người, chỉ báo cáo kết quả. Rủi ro cao nhất, chỉ nên dùng khi tác vụ đã được chuẩn hóa và guardrails đã vững.

Nguyên tắc vàng cho người làm sản phẩm: bắt đầu từ mức thấp, tăng dần khi đã đo được độ tin cậy.

Tình huống thực tế

Ví dụ 1 — Tiki: Agent xử lý yêu cầu hoàn tiền (giả định hợp lý)

Bối cảnh: Một sàn thương mại điện tử lớn tại Việt Nam (giả định theo mô hình Tiki) nhận khoảng 12.000 yêu cầu hoàn tiền/tháng. Trước đây, đội chăm sóc khách hàng phải: đọc yêu cầu → tra đơn hàng trong hệ thống → kiểm tra chính sách hoàn tiền → quyết định → gửi mail. Trung bình 8 phút/ca.

Họ xây một agent (mức 2 — có giám sát):

Tools: get_order(order_id), check_refund_policy(order, reason), issue_refund(order_id, amount), send_email(customer).
Vòng lặp: agent đọc yêu cầu khách → tra đơn → đối chiếu chính sách → nếu số tiền dưới 500.000đ và đúng chính sách thì tự duyệt; nếu trên 500.000đ hoặc trường hợp mập mờ thì đẩy sang nhân viên.

Diễn giải: Điểm hay không nằm ở chỗ agent "thông minh", mà ở chỗ họ đặt ngưỡng kiểm soát rõ ràng. Agent tự xử 70% ca đơn giản, thời gian giảm còn dưới 1 phút; 30% ca khó vẫn có người quyết.

Bài học: Agent tốt nhất không phải agent tự chủ 100%, mà là agent biết ranh giới quyền hạn của mình và biết khi nào chuyển cho người.

Ví dụ 2 — Cursor: Coding agent chạy vòng lặp thật (công ty thật)

Bối cảnh: Cursor (bạn sẽ mổ xẻ kỹ ở Bài 34) là IDE tích hợp AI. Tính năng "Agent mode" của nó là một agent điển hình: bạn giao mục tiêu "thêm chức năng đăng nhập bằng Google", agent sẽ tự đọc codebase, sửa nhiều file, chạy terminal, đọc lỗi, sửa tiếp — lặp cho đến khi build chạy được.

Diễn giải: Tools của Cursor gồm read_file, edit_file, run_terminal, grep_search. Vòng lặp Observe cực kỳ quan trọng: sau khi chạy test, nếu thất bại, agent đọc thông báo lỗi và tự sửa. Đây là điều chatbot không làm được — nó học từ kết quả hành động của chính mình trong thời gian thực.

Bài học: Giá trị của agent bùng nổ khi môi trường có feedback loop nhanh và rõ ràng (test pass/fail, API trả lỗi cụ thể). Ở những lĩnh vực mà kết quả mơ hồ, khó chấm đúng/sai, agent sẽ chật vật hơn nhiều.

Ví dụ 3 — Agent nghiên cứu thị trường cho một startup SEA (giả định)

Bối cảnh: Một startup fintech ở Singapore muốn theo dõi đối thủ. Họ xây một agent chạy hằng đêm: "Tổng hợp thay đổi giá và tính năng mới của 5 đối thủ trong 24h qua."

Agent (mức 3 — tự chủ, nhưng chỉ đọc, không ghi): dùng tools search_web, fetch_page, summarize, save_to_notion. Nó lặp qua từng đối thủ, tìm, đọc, so sánh với dữ liệu hôm trước, rồi ghi báo cáo vào Notion.

Diễn giải: Vì agent này chỉ đọc và ghi vào một nơi nội bộ, rủi ro thấp, nên để tự chủ hoàn toàn là hợp lý. Chi phí kiểm soát chủ yếu là ngân sách token và giới hạn số trang fetch.

Bài học: Mức tự chủ nên tỉ lệ nghịch với mức rủi ro của hành động. Hành động chỉ-đọc → tự chủ thoải mái. Hành động ghi/xóa/tiêu tiền → cần giám sát.

Hướng dẫn từng bước

Đây là quy trình xây một agent sản phẩm từ con số 0:

Định nghĩa mục tiêu và ranh giới. Viết ra một câu: "Agent này hoàn thành X, được phép làm A, B, C, và KHÔNG được làm D, E." Càng hẹp càng dễ thành công. Đừng xây "agent làm mọi thứ".

Liệt kê và thiết kế tools. Với mỗi tool, định nghĩa: tên, mô tả rõ ràng (LLM đọc mô tả này để quyết định gọi), tham số, và giá trị trả về. Mô tả kém là nguyên nhân số 1 khiến agent gọi sai tool.

Chọn model và cơ chế tool use. Dùng model hỗ trợ function calling tốt. Với tác vụ nhiều bước, phức tạp, ưu tiên model mạnh về reasoning; với tác vụ đơn giản lặp lại, có thể dùng model rẻ hơn để tiết kiệm.

Viết vòng lặp orchestration. Bạn có thể tự viết (một vòng while gọi model → thực thi tool → đưa kết quả về) hoặc dùng framework như LangChain, LlamaIndex (Bài 23). Với sản phẩm production, tự viết vòng lặp lõi thường dễ kiểm soát và debug hơn.

Đặt giới hạn cứng (guardrails): số vòng lặp tối đa (ví dụ 15), ngân sách token/chi phí mỗi phiên, timeout, và danh sách hành động cần phê duyệt của con người.

Thêm human-in-the-loop cho hành động rủi ro. Trước khi issue_refund hay send_email, agent phải dừng và xin xác nhận. Đây là điểm khác biệt giữa sản phẩm dùng được và tai họa.

Xây observability. Log lại từng bước: agent nghĩ gì, gọi tool nào, tham số gì, kết quả ra sao. Không có log này, bạn sẽ không bao giờ debug được khi agent "đi lạc".

Đánh giá (eval) và lặp. Xây bộ test tình huống thật (xem Bài 9), đo tỉ lệ hoàn thành đúng, số vòng lặp trung bình, chi phí/tác vụ. Chỉ tăng mức tự chủ khi các chỉ số này đủ tốt.

Lỗi thường gặp & mẹo

Lỗi 1 — Xây agent khi chỉ cần chatbot. Nếu tác vụ chỉ là "trả lời một câu hỏi từ tài liệu", đó là RAG/chatbot, không phải agent. Agent thêm độ phức tạp, chi phí và rủi ro. Chỉ dùng agent khi thật sự cần nhiều bước và hành động.

Lỗi 2 — Vòng lặp vô tận. Agent kẹt trong vòng lặp, gọi đi gọi lại một tool, đốt token. Mẹo: luôn đặt giới hạn số vòng lặp cứng và ngân sách chi phí. Khi chạm giới hạn, dừng và báo cáo trạng thái, đừng để chạy tự do.

Lỗi 3 — Tool có mô tả mơ hồ. LLM chọn tool dựa trên mô tả. "Tool tìm kiếm" quá chung chung khiến nó gọi sai lúc. Mẹo: viết mô tả như đang hướng dẫn một nhân viên mới — nêu rõ khi nào dùng và khi nào KHÔNG dùng.

Lỗi 4 — Cho agent quá nhiều tool. 20 tool khiến model bối rối và chọn sai. Mẹo: giữ dưới 8-10 tool cho mỗi agent. Nếu cần nhiều hơn, chia thành nhiều agent chuyên biệt (multi-agent) hoặc gom tool theo nhóm.

Lỗi 5 — Bỏ qua trường hợp tool thất bại. API trả lỗi, mạng timeout — agent phải biết xử lý. Mẹo: trả lỗi có cấu trúc, rõ ràng cho agent ("API hết hạn, thử lại sau") để nó có thể tự điều chỉnh thay vì đứng hình.

Lỗi 6 — Không có con người ở khâu rủi ro. Để agent tự gửi mail cho khách hàng hay tự thanh toán ngay từ đầu là công thức của thảm họa. Mẹo: mặc định human-in-the-loop cho mọi hành động không thể hoàn tác, chỉ gỡ dần khi đã tin.

Mẹo tối ưu chi phí: agent tốn gấp nhiều lần chatbot vì mỗi tác vụ chạy nhiều lượt gọi LLM. Đo chi phí trung bình mỗi tác vụ hoàn thành, không phải mỗi lượt gọi. Cân nhắc dùng model rẻ cho các bước đơn giản trong vòng lặp (xem lại Bài 12 về latency và chi phí).

Bài tập thực hành

Phân loại: Lấy 5 sản phẩm AI bạn từng dùng. Với mỗi cái, xác định: đó là chatbot, copilot, hay agent? Dựa vào tiêu chí "có vòng lặp hành động và tự đạt mục tiêu không?" để phán đoán.

Thiết kế agent trên giấy: Chọn một quy trình lặp đi lặp lại trong công việc của bạn (ví dụ: sắp xếp lịch họp, tổng hợp email hằng ngày). Viết ra: mục tiêu, danh sách 4-6 tools (kèm mô tả), và các điểm cần con người phê duyệt.

Vẽ vòng lặp: Với agent ở bài 2, viết ra một kịch bản chạy mẫu theo dạng Reason → Act → Observe qua ít nhất 3 vòng lặp, giống ví dụ đặt vé ở phần đầu.

Xác định mức tự chủ: Với mỗi tool trong agent của bạn, gán mức rủi ro (đọc / ghi / không thể hoàn tác) và quyết định tool nào cần human-in-the-loop.

(Nâng cao) Nếu bạn biết code: dựng một agent tối giản với một vòng while, dùng function calling của một model bất kỳ, cho nó 2 tool (ví dụ search_web và calculator), đặt giới hạn 8 vòng lặp, và log lại từng bước.

Tóm tắt

Chatbot trả lời, agent hoàn thành mục tiêu. Khác biệt cốt lõi là agent chạy vòng lặp Suy nghĩ → Hành động → Quan sát và tự điều chỉnh.
Mọi agent cần đủ bốn thành phần: model có tool use, tools, memory/state, và control loop + guardrails.
Kiến trúc phổ biến là ReAct; LLM chỉ đề nghị gọi tool, còn code orchestration của bạn mới thực thi và kiểm soát.
Nghĩ theo ba mức tự chủ và luôn để mức tự chủ tỉ lệ nghịch với rủi ro của hành động. Bắt đầu thấp, tăng dần khi đo được độ tin cậy.
Những cạm bẫy chết người: xây agent khi chỉ cần chatbot, vòng lặp vô tận, tool mô tả mơ hồ, quá nhiều tool, và thiếu con người ở khâu rủi ro.
Giá trị agent bùng nổ khi môi trường có feedback loop nhanh và rõ ràng — như coding, xử lý đơn hàng, nghiên cứu tự động.

Ở các bài tiếp theo, bạn sẽ đi sâu vào chiến lược sản phẩm cho AI (Bài 18), quyết định build vs buy (Bài 19), và các framework hạ tầng như LangChain, LlamaIndex (Bài 23) — những công cụ giúp bạn hiện thực hóa agent nhanh và vững hơn.