Mở đầu — vì sao bài này quan trọng
Trong những bài trước, bạn đã làm chủ cách viết prompt, gọi function, quản lý context window và stream phản hồi cho người dùng. Tất cả những kỹ năng đó đều xoay quanh một mô hình tương tác cơ bản: người dùng gửi một yêu cầu, hệ thống AI trả về một câu trả lời. Đó là thế giới của chatbot. Nhưng thị trường sản phẩm AI năm 2026 đang dịch chuyển mạnh sang một thứ khác, mạnh mẽ hơn và cũng khó kiểm soát hơn nhiều: AI Agents.
Sự khác biệt không chỉ là kỹ thuật, mà là sự thay đổi căn bản về giá trị mà sản phẩm mang lại. Một chatbot trả lời câu hỏi "Doanh thu quý này của tôi là bao nhiêu?". Một agent thì nhận yêu cầu "Phân tích doanh thu quý này, so sánh với quý trước, tìm ra ba nguyên nhân chính khiến đơn hàng giảm và soạn email báo cáo gửi cho ban giám đốc" — rồi tự nó lên kế hoạch, gọi nhiều công cụ, đọc dữ liệu, suy luận qua nhiều bước và hoàn thành toàn bộ tác vụ. Người dùng không còn trả tiền cho câu trả lời, họ trả tiền cho kết quả công việc.
Với vai trò AI Product Manager, bạn cần hiểu agent ở mức đủ sâu để quyết định: khi nào sản phẩm của bạn nên là agent thay vì chatbot, các thành phần nào cấu thành một agent, đâu là điểm dễ vỡ về độ tin cậy và chi phí, và làm sao thiết kế trải nghiệm để người dùng vừa được trao quyền tự động hóa vừa cảm thấy kiểm soát được. Bài này tập trung riêng vào kiến trúc multi-step workflow của agent — bộ não điều phối. Phần trí nhớ dài hạn của agent sẽ được đào sâu ở Bài 44, nên ở đây chúng ta chỉ chạm tới ở mức cần thiết.
Khái niệm cốt lõi
Chatbot vs Agent — ranh giới thực sự nằm ở đâu
Nhiều người nhầm rằng cứ gắn thêm vài function call vào chatbot là thành agent. Không phải. Ranh giới nằm ở tính tự chủ trong việc quyết định chuỗi hành động.
- Chatbot: nhận một message, có thể gọi một vài tool, rồi trả lời. Luồng xử lý gần như tuyến tính và do lập trình viên định trước. Nó phản ứng (react).
- Agent: nhận một mục tiêu (goal), tự chia mục tiêu thành các bước, tự quyết định bước tiếp theo dựa trên kết quả của bước trước, lặp lại cho đến khi hoàn thành hoặc bỏ cuộc. Nó hành động (act) qua nhiều vòng lặp.
Bốn thành phần của một AI Agent
Một agent hoàn chỉnh thường được lắp ráp từ bốn khối:
1. Planner (Bộ lập kế hoạch). Đây là phần nhận mục tiêu lớn và phân rã thành các bước nhỏ khả thi. Có hai phong cách lập kế hoạch:
- Plan-and-execute: lập toàn bộ kế hoạch trước (ví dụ: bước 1 truy vấn database, bước 2 tính toán, bước 3 soạn email), rồi thực thi tuần tự. Dễ kiểm soát, dễ hiển thị cho người dùng, nhưng kém linh hoạt khi gặp tình huống bất ngờ.
- ReAct (suy luận từng bước): agent chỉ quyết định một hành động tiếp theo tại mỗi vòng, dựa trên kết quả vừa quan sát. Linh hoạt hơn, xử lý tốt tác vụ mơ hồ, nhưng khó dự đoán và dễ đi lạc.
2. Tools (Công cụ). Là tay chân của agent — những function nó được phép gọi để tương tác với thế giới: truy vấn database, gọi API, tìm kiếm web, gửi email, đọc file, chạy code. Chất lượng agent phụ thuộc rất nhiều vào việc mô tả tool rõ ràng (tên, mô tả, tham số) để model biết khi nào nên dùng cái nào. Đây chính là nơi kỹ năng function calling ở Bài 16 phát huy tác dụng.
3. Memory (Trí nhớ). Agent cần nhớ những gì đã làm trong phiên hiện tại (kết quả các bước trước) để không lặp lại và để suy luận có ngữ cảnh. Trí nhớ ngắn hạn nằm trong context window; trí nhớ dài hạn (qua nhiều phiên) là chủ đề riêng của Bài 44.
4. Orchestrator (Bộ điều phối / vòng lặp điều khiển). Là phần "keo dán" chạy vòng lặp: gọi planner để lấy hành động, thực thi tool, đưa kết quả ngược lại cho model, kiểm tra điều kiện dừng. Orchestrator cũng giữ các "phanh an toàn": giới hạn số bước tối đa, giới hạn chi phí, timeout, và các điểm cần con người phê duyệt.
Điều kiện dừng và phanh an toàn
Đây là phần PM hay bỏ quên nhưng cực kỳ quan trọng. Vì số bước không cố định, một agent thiết kế tồi có thể rơi vào vòng lặp vô tận, gọi đi gọi lại cùng một tool, hoặc đốt hàng triệu token mà không ra kết quả. Mọi agent sản xuất đều phải có: giới hạn số vòng lặp (ví dụ tối đa 10 bước), giới hạn ngân sách token/chi phí cho mỗi tác vụ, và cơ chế phát hiện khi agent "bí" để dừng lại và xin trợ giúp con người thay vì cố gắng vô vọng.
Tình huống thực tế
Tình huống 1 — Agent xử lý hoàn tiền tại một sàn TMĐT Việt Nam
Một sàn thương mại điện tử giả định tên ShopMart (quy mô tương tự Tiki/Sendo) nhận khoảng 4.000 yêu cầu hoàn tiền mỗi ngày qua chatbot CSKH. Chatbot cũ chỉ trả lời "Yêu cầu của bạn đã được ghi nhận", sau đó nhân viên xử lý thủ công, trung bình mất 26 giờ mỗi ca.
Đội sản phẩm xây một refund agent với mục tiêu: "Xử lý yêu cầu hoàn tiền của khách đến khi hoàn tất hoặc cần con người duyệt." Các bước agent tự thực hiện: (1) tra cứu đơn hàng qua API, (2) kiểm tra chính sách hoàn tiền có áp dụng không, (3) đọc ảnh sản phẩm lỗi khách gửi, (4) tính số tiền hoàn, (5) nếu dưới 500.000đ thì tự duyệt và gọi API hoàn tiền, nếu trên mức đó thì chuyển cho nhân viên kèm tóm tắt.
Kết quả sau ba tháng: 71% yêu cầu được agent xử lý trọn vẹn không cần người, thời gian xử lý trung bình giảm còn 4 phút, chi phí AI khoảng 1.800đ mỗi yêu cầu.
Bài học: Sức mạnh của agent đến từ việc giao cho nó mục tiêu chứ không phải câu trả lời. Nhưng điểm chốt thành công là phanh an toàn — ngưỡng 500.000đ và bước "human-in-the-loop" giữ rủi ro tài chính trong tầm kiểm soát. Không có phanh này, một agent sai sót có thể hoàn nhầm hàng tỷ đồng.
Tình huống 2 — Research agent của Perplexity và cái giá của multi-step
Perplexity (sản phẩm AI search, sẽ học kỹ ở Bài 57) có tính năng "Deep Research" hoạt động như một agent đa bước: nhận một câu hỏi nghiên cứu, nó tự lên kế hoạch tìm kiếm, thực hiện hàng chục lượt search web, đọc nguồn, tổng hợp, rồi viết báo cáo có trích dẫn. Một truy vấn deep research có thể chạy 30–40 bước và tốn chi phí gấp 20–50 lần một câu trả lời thông thường.
Đây là điểm PM phải cân nhắc: agent đa bước rất tốn kém. Mỗi vòng lặp đều nạp lại context và gọi model. Perplexity giải quyết bằng cách tách thành gói trả phí riêng và giới hạn số lượt deep research mỗi tháng theo tier.
Bài học: Khi chuyển từ chatbot sang agent, đường cong chi phí thay đổi hoàn toàn. Một câu trả lời tốn vài cent; một tác vụ agent có thể tốn vài đô. PM phải mô hình hóa chi phí theo tác vụ hoàn chỉnh chứ không theo lượt gọi model, và thiết kế gói giá phù hợp (chủ đề Token Economics ở Bài 40 bổ trợ trực tiếp ở đây).
Tình huống 3 — Agent đặt lịch nội bộ ở một startup logistics Đông Nam Á
Một startup logistics tại TP.HCM xây agent nội bộ giúp điều phối viên đặt chuyến xe. Yêu cầu mẫu: "Sắp 3 chuyến giao hàng khu vực Bình Dương ngày mai, ưu tiên tài xế đang rảnh và gần kho nhất." Agent gọi tool tra danh sách tài xế, tool kiểm tra lịch, tool tính khoảng cách, rồi đề xuất phân công.
Ở phiên bản đầu, agent đôi khi "ảo tưởng" rằng đã đặt chuyến thành công trong khi tool gọi API thực ra trả về lỗi. Đội sản phẩm khắc phục bằng cách buộc agent phải đọc và xác nhận kết quả trả về của mỗi tool trước khi sang bước tiếp, và thêm một bước tổng kết cuối cùng liệt kê rõ những hành động đã thực sự thực hiện thành công.
Bài học: Agent không tự biết hành động của nó có thực sự thành công hay không trừ khi bạn ép nó quan sát kết quả. Bước "observe" trong vòng lặp ReAct không phải tùy chọn — nó là tuyến phòng thủ chống lại việc agent báo cáo sai sự thật.
Hướng dẫn từng bước
Đây là quy trình để PM định hình một tính năng agent từ ý tưởng đến bản thử nghiệm:
- Xác định tác vụ phù hợp với agent. Chọn tác vụ đa bước, có quy trình rõ, lặp đi lặp lại và tốn thời gian con người. Tránh tác vụ một bước (chatbot làm tốt hơn, rẻ hơn) và tránh tác vụ rủi ro cao không thể đảo ngược ở giai đoạn đầu.
- Liệt kê và mô tả bộ tool. Viết ra mọi hành động agent cần thực hiện, ánh xạ thành các tool với mô tả rõ ràng. Mỗi tool nên làm một việc, có tham số tường minh và trả về kết quả dễ đọc kèm trạng thái thành công/thất bại.
- Chọn phong cách lập kế hoạch. Tác vụ có quy trình cố định thì dùng plan-and-execute để dễ kiểm soát và hiển thị. Tác vụ mơ hồ, cần thích nghi thì dùng ReAct. Bắt đầu đơn giản, đừng vội xây multi-agent phức tạp.
- Định nghĩa điều kiện dừng và ngân sách. Đặt số bước tối đa, ngân sách token/chi phí mỗi tác vụ, timeout, và điều kiện thành công rõ ràng. Quyết định ngưỡng nào thì agent tự làm, ngưỡng nào phải chuyển con người duyệt.
- Thiết kế các điểm human-in-the-loop. Xác định những hành động không thể đảo ngược (chuyển tiền, gửi email ra ngoài, xóa dữ liệu) và bắt buộc có bước xác nhận của con người trước khi thực thi.
- Thiết kế trải nghiệm hiển thị tiến trình. Người dùng phải thấy agent đang làm gì ở từng bước ("Đang tra cứu đơn hàng…", "Đang kiểm tra chính sách…"). Tính minh bạch này xây dựng niềm tin và giúp người dùng can thiệp khi thấy sai.
- Đo lường và lặp. Theo dõi tỷ lệ hoàn thành tác vụ, số bước trung bình, chi phí mỗi tác vụ, tỷ lệ phải chuyển con người. Đây là các chỉ số sống còn để biết agent có thực sự tạo giá trị hay chỉ đốt tiền.
Lỗi thường gặp & mẹo
Lỗi: Biến mọi thứ thành agent. Không phải tác vụ nào cũng cần agent. Nếu yêu cầu chỉ một bước, agent vừa chậm vừa đắt vừa kém tin cậy hơn một chatbot có function calling. Hãy hỏi: "Tác vụ này có thực sự cần suy luận nhiều bước không?"
Lỗi: Quên đặt giới hạn vòng lặp. Agent không có phanh sẽ chạy vô tận khi gặp tình huống nó không giải được, đốt token và làm hỏng trải nghiệm. Luôn đặt số bước tối đa ngay từ ngày đầu.
Lỗi: Tin rằng agent biết hành động của nó đã thành công. Như tình huống logistics cho thấy, agent có thể tưởng nó đã làm xong trong khi tool báo lỗi. Luôn ép agent đọc và xác nhận kết quả mỗi bước.
Lỗi: Cho agent quyền hành động không thể đảo ngược mà không có cửa chặn. Đừng bao giờ để agent tự gửi tiền, xóa dữ liệu hay gửi thư ra ngoài ở phiên bản đầu. Thêm human-in-the-loop cho mọi hành động rủi ro cao.
Mẹo: Bắt đầu ở chế độ "đề xuất, không thực thi". Cho agent chạy toàn bộ quy trình nhưng chỉ đề xuất hành động cuối để con người bấm duyệt. Khi đã đủ tin cậy qua dữ liệu thực, mới dần nới quyền tự động.
Mẹo: Ghi log toàn bộ chuỗi suy luận và tool call. Khi agent làm sai, bạn cần xem lại từng bước để hiểu nó "nghĩ" gì. Không có log chi tiết, việc debug agent gần như bất khả thi.
Mẹo: Giữ bộ tool nhỏ và rõ. Càng nhiều tool, model càng dễ chọn nhầm. Bắt đầu với 3–5 tool thiết yếu rồi mở rộng dần.
Bài tập thực hành
- Phân loại chatbot vs agent. Lấy ba tính năng AI bạn dùng gần đây (ví dụ trợ lý đặt vé, công cụ viết email, tìm kiếm AI). Với mỗi cái, xác định nó là chatbot hay agent và giải thích dựa trên tiêu chí "tự chủ chuỗi hành động".
- Thiết kế một agent trên giấy. Chọn một tác vụ đa bước trong công việc của bạn (ví dụ: tổng hợp báo cáo tuần từ nhiều nguồn). Viết ra: mục tiêu, danh sách 4–6 tool kèm mô tả, phong cách lập kế hoạch bạn chọn và lý do, điều kiện dừng, và các điểm cần human-in-the-loop.
- Mô hình hóa chi phí và rủi ro. Cho agent ở bài tập 2, ước lượng số bước trung bình mỗi tác vụ và chi phí token tương ứng. Liệt kê hai hành động không thể đảo ngược và đề xuất cửa chặn an toàn cho mỗi cái.
- Viết kịch bản hiển thị tiến trình. Soạn nội dung thông báo từng bước mà người dùng sẽ thấy khi agent của bạn chạy, sao cho minh bạch và tạo niềm tin.
Tóm tắt
AI Agent là bước nhảy từ "trả lời câu hỏi" sang "hoàn thành công việc". Khác biệt cốt lõi so với chatbot là tính tự chủ trong việc lập và thực thi chuỗi hành động nhiều bước qua vòng lặp suy nghĩ → hành động → quan sát. Một agent gồm bốn khối: planner (lập kế hoạch), tools (công cụ hành động), memory (trí nhớ), và orchestrator (vòng lặp điều khiển kèm phanh an toàn).
Với PM, ba điều quan trọng nhất cần ghi nhớ: thứ nhất, chỉ dùng agent cho tác vụ đa bước thực sự cần suy luận, đừng lạm dụng; thứ hai, chi phí và rủi ro của agent cao hơn chatbot nhiều lần, phải mô hình hóa theo tác vụ hoàn chỉnh và đặt phanh an toàn (giới hạn bước, ngân sách, human-in-the-loop); thứ ba, niềm tin của người dùng đến từ sự minh bạch về tiến trình và việc ép agent xác nhận kết quả thật của mỗi hành động. Nắm vững kiến trúc multi-step này là nền tảng để bước sang Bài 44 về trí nhớ dài hạn của agent.