Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 26 — AI agents — autonomous task execution

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

Trong các bài trước, bạn đã làm quen với RPA (bot làm theo kịch bản cố định), với chatbot trả lời theo luồng được lập trình sẵn, và với LLM như GPT hay Claude có khả năng hiểu và sinh ngôn ngữ. Tất cả đều mạnh, nhưng đều có một giới hạn chung: chúng cần con người chỉ rõ từng bước phải làm gì. Bot RPA không tự nghĩ ra cách xử lý khi gặp tình huống mới. Chatbot không tự quyết định gọi hệ thống nào để hoàn thành yêu cầu phức tạp.

AI agent (tác tử AI) là bước nhảy tiếp theo, và là một trong những chủ đề nóng nhất của tự động hóa giai đoạn 2024–2026. Thay vì "làm theo kịch bản", một agent được giao một mục tiêu (goal) và tự nó suy nghĩ ra các bước để đạt mục tiêu đó, tự gọi công cụ (tools) khi cần, tự nhớ ngữ cảnh, và tự điều chỉnh khi gặp lỗi. Nói cách khác, agent biến LLM từ "bộ não chỉ biết nói" thành "nhân viên số biết hành động".

Tại sao điều này quan trọng với bạn — người làm về Process và Digital Transformation? Bởi vì agent là mảnh ghép cho phép tự động hóa những quy trình mà RPA truyền thống "bó tay": quy trình có nhiều ngoại lệ, cần phán đoán, cần kết hợp dữ liệu từ nhiều nguồn không cấu trúc. Một công ty ở Việt Nam hiện đang trả lương cho cả một đội nhân viên ngồi đọc email khách hàng, phân loại, tra cứu hệ thống và trả lời — chính xác là loại công việc mà agent đang dần đảm nhận. Hiểu agent là hiểu hình hài của tự động hóa thế hệ kế tiếp.

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

AI agent là gì?

Công thức ngắn gọn nhất để ghi nhớ:

> AI Agent = LLM + Tools + Memory + Planning, vận hành trong một vòng lặp (loop) cho đến khi đạt mục tiêu.

LLM đóng vai trò "bộ não" ra quyết định. Nhưng một mình LLM chỉ sinh ra văn bản. Để hành động trong thế giới thực — gửi email, truy vấn database, gọi API, đọc file — nó cần ba thứ bổ trợ: công cụ để tác động, bộ nhớ để không "quên", và khả năng lập kế hoạch để chia nhỏ vấn đề. Điểm khác biệt cốt tử so với một lời gọi LLM thông thường là vòng lặp: agent không trả lời một phát rồi dừng, mà liên tục "suy nghĩ → hành động → quan sát kết quả → suy nghĩ lại" cho đến khi hoàn thành.

Bốn thành phần xương sống

1. Planning (Lập kế hoạch). Agent nhận một mục tiêu lớn ("Lập báo cáo doanh thu tuần này và gửi cho sếp") và tự bẻ nó thành các bước nhỏ thực thi được: (a) truy vấn database doanh thu 7 ngày, (b) tổng hợp số liệu, (c) tạo file Excel, (d) viết email tóm tắt, (e) gửi đi. Có nhiều kỹ thuật planning, phổ biến nhất là ReAct (Reasoning + Acting — đan xen suy luận và hành động) và Plan-and-Execute (lập toàn bộ kế hoạch trước, rồi thực thi).

2. Tools (Công cụ). Đây là "tay chân" của agent. Mỗi tool là một hàm có mô tả rõ ràng: tên, công dụng, tham số đầu vào. Ví dụ một tool search_customer(email) tra cứu khách hàng theo email, hay send_email(to, subject, body) gửi thư. LLM đọc danh sách tools, tự quyết định khi nàovới tham số gì thì gọi tool nào. Đây chính là cơ chế function calling / tool use mà các model như Claude và GPT hỗ trợ sẵn. Tool có thể là API nội bộ công ty, công cụ tìm kiếm web, máy tính, trình thông dịch code, hay thậm chí một agent khác.

3. Memory (Bộ nhớ). Chia làm hai loại. Short-term memory (bộ nhớ ngắn hạn) là ngữ cảnh trong một phiên làm việc — agent nhớ nó vừa làm gì ở bước trước. Long-term memory (bộ nhớ dài hạn) lưu kiến thức qua nhiều phiên, thường dùng vector database để tra cứu lại khi cần (kỹ thuật này liên quan chặt tới RAG mà bạn sẽ học ở Bài 30). Không có memory, agent sẽ lặp lại cùng một sai lầm hoặc quên mất nó đang ở đâu trong nhiệm vụ.

4. The Loop (Vòng lặp agentic). Trái tim của agent. Một vòng tiêu biểu:

Mục tiêu → [Suy nghĩ: bước tiếp theo là gì?]
        → [Hành động: gọi tool]
        → [Quan sát: nhận kết quả từ tool]
        → [Suy nghĩ lại: đã xong chưa? Có lỗi không?]
        → ... lặp lại ...
        → [Đạt mục tiêu → trả kết quả cuối]

Chính vòng lặp này tạo nên tính autonomous (tự chủ): agent tự quyết định lặp bao nhiêu lần, tự xử lý lỗi giữa chừng mà không cần con người can thiệp từng bước.

Phân biệt: Agent vs Workflow vs RPA

Đây là điểm rất nhiều người nhầm lẫn, hãy ghi nhớ thật rõ:

  • Workflow / RPA: con người định nghĩa trước toàn bộ đường đi. Hệ thống chỉ chạy theo. Rất đáng tin cậy, dễ kiểm soát, nhưng cứng nhắc — gặp tình huống ngoài kịch bản là gãy.
  • AI Agent: con người chỉ định nghĩa mục tiêu và bộ công cụ. Agent tự quyết định đường đi. Linh hoạt, xử lý được ngoại lệ, nhưng kém tất định hơn (cùng input có thể ra cách làm khác nhau) và khó kiểm soát hơn.
Một nguyên tắc thực chiến từ Anthropic mà tôi rất tâm đắc: đừng dùng agent khi một workflow cố định là đủ. Agent đắt hơn (tốn nhiều lời gọi LLM), chậm hơn và khó dự đoán hơn. Chỉ dùng agent khi bài toán thực sự cần sự linh hoạt và phán đoán mà workflow cứng không kham nổi.

Các kiến trúc agent thường gặp

  • Single agent: một agent duy nhất với bộ tools. Đơn giản, dễ debug — nên là lựa chọn đầu tiên.
  • Multi-agent: nhiều agent chuyên trách phối hợp, thường có một "orchestrator" điều phối các "sub-agent" (ví dụ: agent nghiên cứu, agent viết, agent kiểm tra). Mạnh cho bài toán lớn nhưng phức tạp và tốn kém.
  • Human-in-the-loop: agent chạy tự động nhưng dừng lại xin con người phê duyệt ở các bước nhạy cảm (ví dụ: trước khi chuyển tiền, trước khi gửi email cho khách VIP). Đây là kiến trúc thực dụng nhất cho doanh nghiệp Việt Nam hiện nay.

Tình huống thực tế

Ví dụ 1 — Agent xử lý khiếu nại tại một sàn TMĐT Đông Nam Á

Một sàn thương mại điện tử (lấy bối cảnh kiểu Shopee/Tiki) nhận khoảng 8.000 email khiếu nại mỗi ngày: "đơn hàng chưa tới", "sản phẩm lỗi", "muốn hoàn tiền". Trước đây, đội chăm sóc khách hàng 40 người phải đọc từng email, tra cứu mã đơn trong hệ thống, kiểm tra trạng thái vận chuyển rồi soạn trả lời.

Họ triển khai một AI agent với mục tiêu: "Giải quyết khiếu nại của khách đúng chính sách công ty." Agent được trang bị các tool: get_order(order_id), check_shipping_status(tracking_code), lookup_refund_policy(reason), issue_refund(order_id, amount) (tool này có human-in-the-loop), và draft_reply(...).

Khi một email vào, agent lập kế hoạch: trích mã đơn từ nội dung email → gọi get_order → thấy đơn đang kẹt ở kho 5 ngày → gọi check_shipping_status xác nhận trễ → tra chính sách → soạn lời xin lỗi kèm mã giảm giá. Với các ca đơn giản, agent xử lý trọn vẹn. Với ca cần hoàn tiền trên 500.000đ, agent dừng lại đẩy cho nhân viên phê duyệt.

Kết quả giả định hợp lý: agent tự xử lý gọn 65% lượng email (các ca rõ ràng), thời gian phản hồi trung bình giảm từ 6 giờ xuống 4 phút, đội người tập trung vào 35% ca khó. Bài học: agent không thay thế cả đội, mà gánh phần việc lặp đi lặp lại để con người làm việc giá trị cao hơn — và human-in-the-loop ở khâu tiền bạc là bắt buộc.

Ví dụ 2 — Agent nghiên cứu thị trường cho một startup Việt

Một startup fintech ở TP.HCM cần báo cáo nhanh về đối thủ mỗi tuần. Một bạn growth marketer dựng agent đơn giản trên nền Claude với hai tool: web_search(query)read_webpage(url).

Mục tiêu giao cho agent: "Tổng hợp các thay đổi về sản phẩm và giá của 5 ví điện tử lớn tại VN trong 7 ngày qua." Agent tự lập kế hoạch tìm kiếm từng đối thủ, đọc trang tin, đối chiếu, rồi viết bản tóm tắt có trích nguồn. Việc trước đây tốn nửa ngày của một nhân viên, nay xong trong khoảng 10 phút với chi phí vài chục nghìn đồng tiền API.

Bài học: bạn không cần là kỹ sư để dùng agent. Sức mạnh nằm ở việc định nghĩa mục tiêu rõ ràng và cung cấp đúng công cụ. Nhưng cũng lộ ra rủi ro: agent đôi khi đọc nguồn không đáng tin và "tự tin" báo cáo sai — nên luôn yêu cầu agent trích dẫn nguồn để con người kiểm chứng.

Ví dụ 3 — Coding agent tăng tốc đội kỹ thuật ngân hàng

Một ngân hàng số tại Việt Nam giao cho đội backend nhiệm vụ viết hàng trăm test case cho hệ thống thanh toán. Họ dùng một coding agent (kiểu Claude Code, Cursor) được trang bị tool đọc/ghi file, chạy lệnh terminal và chạy test. Lập trình viên chỉ mô tả: "Viết unit test cho module xử lý giao dịch QR, đảm bảo coverage trên 80%."

Agent tự đọc code hiện có, lập kế hoạch các nhánh cần test, viết test, chạy thử, thấy lỗi thì tự sửa, chạy lại — đúng tinh thần vòng lặp suy nghĩ–hành động–quan sát. Kết quả: thời gian viết test giảm khoảng 50%, lập trình viên chuyển sang review thay vì gõ tay. Bài học: agent mạnh nhất khi có feedback loop rõ ràng (chạy test biết đúng/sai ngay), giúp nó tự sửa mà không cần người kèm.

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

Đây là quy trình thực dụng để bạn thiết kế một agent đầu tiên cho một quy trình trong tổ chức:

Bước 1 — Chọn đúng bài toán. Hỏi: việc này có cần phán đoán linh hoạt và nhiều ngoại lệ không? Nếu chỉ là luồng cố định, hãy dùng RPA/workflow (rẻ và đáng tin hơn). Agent dành cho việc "mỗi ca một khác".

Bước 2 — Định nghĩa mục tiêu rõ ràng. Viết mục tiêu như giao việc cho một nhân viên giỏi nhưng mới: nói rõ kết quả mong muốn, ràng buộc, và tiêu chí "thế nào là xong". Mục tiêu mơ hồ tạo ra agent đi lan man.

Bước 3 — Liệt kê và xây dựng tools. Với mỗi hành động agent cần làm, tạo một tool có mô tả rõ ràng, tham số chặt chẽ. Mô tả tool tốt quan trọng ngang code — vì LLM dựa vào mô tả để quyết định gọi tool. Bắt đầu với ít tool nhất có thể.

Bước 4 — Thiết kế memory. Quyết định agent cần nhớ gì trong phiên (short-term) và gì cần lưu lâu dài (long-term, thường qua vector DB). Đừng nhồi mọi thứ vào ngữ cảnh — tốn token và gây nhiễu.

Bước 5 — Cài đặt vòng lặp và giới hạn an toàn (guardrails). Đặt trần số bước lặp (ví dụ tối đa 15 bước) để tránh agent lặp vô hạn. Đặt trần chi phí. Xác định các tool "nguy hiểm" cần human-in-the-loop.

Bước 6 — Chạy thử trong môi trường an toàn (sandbox). Cho agent chạy trên dữ liệu giả, quan sát từng bước nó suy nghĩ (log lại trace). Đây là khâu bạn phát hiện agent hiểu sai tool hay đi lạc hướng.

Bước 7 — Quan sát, đo lường, lặp lại. Triển khai giới hạn (một phần nhỏ lưu lượng trước), theo dõi tỉ lệ thành công, chi phí mỗi tác vụ, số lần cần con người can thiệp. Tinh chỉnh mô tả tool và prompt mục tiêu dựa trên lỗi thực tế.

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

Lỗi 1 — Dùng agent khi không cần. Đây là sai lầm phổ biến nhất kể từ khi agent trở thành "từ khóa thời thượng". Nhiều đội nhồi LLM vào mọi chỗ trong khi một câu lệnh if-else hoặc workflow đơn giản là đủ. Mẹo: luôn bắt đầu bằng giải pháp đơn giản nhất; chỉ leo thang lên agent khi sự linh hoạt thực sự cần thiết.

Lỗi 2 — Mô tả tool sơ sài. Agent gọi nhầm tool hoặc truyền sai tham số thường không phải do model dở, mà do mô tả tool không rõ. Mẹo: viết mô tả tool như viết tài liệu cho một đồng nghiệp; nêu rõ khi nào dùng, khi nào không, ví dụ tham số.

Lỗi 3 — Không có guardrails, để agent "tự do tuyệt đối". Agent có thể lặp vô hạn đốt tiền API, hoặc thực hiện hành động không thể hoàn tác (xóa dữ liệu, gửi nhầm email cho 10.000 khách). Mẹo: luôn đặt trần số bước, trần chi phí, và human-in-the-loop cho mọi hành động có hậu quả lớn hoặc không thể đảo ngược.

Lỗi 4 — Tin tưởng mù quáng output của agent. Agent có thể "ảo giác" (hallucinate) — tự tin đưa ra thông tin sai. Mẹo: yêu cầu agent trích nguồn, ghi lại lý do từng quyết định (reasoning trace) để con người kiểm chứng; với quyết định quan trọng, luôn có người duyệt.

Lỗi 5 — Lỗi cộng dồn trong chuỗi dài. Nếu mỗi bước đúng 95%, qua 10 bước xác suất cả chuỗi đúng chỉ còn khoảng 60%. Mẹo: chia nhỏ nhiệm vụ, thêm bước tự kiểm tra (self-check), và thiết kế feedback loop để agent phát hiện và sửa lỗi sớm thay vì cộng dồn.

Mẹo vàng: hãy đối xử với agent như một nhân viên thực tập thông minh nhưng thiếu kinh nghiệm — bạn giao việc rõ ràng, cho công cụ phù hợp, đặt ranh giới an toàn, và kiểm tra kết quả ở những khâu quan trọng. Đừng kỳ vọng nó hoàn hảo tự thân.

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

Bài 1 — Phân loại (tư duy). Chọn 5 quy trình trong công ty hoặc bộ phận của bạn. Với mỗi quy trình, quyết định: nên dùng RPA/workflow cố định, hay AI agent, hay vẫn để con người? Ghi rõ lý do dựa trên mức độ ngoại lệ và nhu cầu phán đoán.

Bài 2 — Thiết kế trên giấy. Chọn một quy trình bạn cho là phù hợp với agent ở Bài 1. Hãy viết ra: (a) mục tiêu của agent, (b) danh sách 3–6 tools kèm mô tả ngắn, (c) cần memory gì, (d) tool nào cần human-in-the-loop và tại sao.

Bài 3 — Trải nghiệm thực tế. Dùng một công cụ agent sẵn có (Claude với chế độ tool use, hoặc một coding agent). Giao cho nó một mục tiêu nhiều bước có thật, ví dụ: "Tìm và tóm tắt 3 đối thủ của công ty tôi, lưu vào file." Quan sát và ghi lại: agent đã lập kế hoạch thế nào, gọi tool nào, có bước nào đi sai không, và bạn đã phải can thiệp ở đâu.

Bài 4 — Phân tích rủi ro. Với agent bạn thiết kế ở Bài 2, liệt kê 3 kịch bản "agent làm sai gây hậu quả" và đề xuất guardrail tương ứng cho từng kịch bản.

Tóm tắt

  • AI agent = LLM + Tools + Memory + Planning, vận hành trong một vòng lặp "suy nghĩ → hành động → quan sát" cho đến khi đạt mục tiêu. Đây là điều biến LLM từ "biết nói" thành "biết hành động".
  • Khác biệt cốt lõi với RPA/workflow: con người chỉ định mục tiêu và công cụ, còn agent tự quyết định cách làm — linh hoạt hơn nhưng kém tất định và khó kiểm soát hơn.
  • Bốn thành phần xương sống: Planning (chia nhỏ mục tiêu, dùng ReAct/Plan-and-Execute), Tools (function calling — tay chân của agent), Memory (ngắn hạn và dài hạn), và vòng lặp agentic.
  • Nguyên tắc thực chiến: đừng dùng agent khi workflow đơn giản là đủ; bắt đầu với single agent; đặt guardrails (trần bước, trần chi phí); dùng human-in-the-loop cho mọi hành động có hậu quả lớn.
  • Các ví dụ từ TMĐT, fintech và ngân hàng cho thấy agent mạnh nhất khi có mục tiêu rõ ràng, tool được mô tả tốt, và feedback loop để tự sửa lỗi — luôn cần con người kiểm chứng ở khâu trọng yếu.
Ở bài tiếp theo, chúng ta sẽ bước sang Process Mining kết hợp AI dự báo — cách dùng dữ liệu quy trình thực tế để phát hiện điểm nghẽn và tiên đoán vấn đề trước khi chúng xảy ra.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi