Mở đầu — vì sao bài này quan trọng
Trong các bài trước, bạn đã học cách viết một prompt tốt, cách xâu chuỗi nhiều prompt lại với nhau (prompt chaining ở Bài 10), và cách cho AI gọi công cụ bên ngoài qua function calling (Bài 24). Nhưng tất cả những kỹ thuật đó vẫn chia sẻ một điểm chung: con người là người điều phối. Bạn quyết định bước nào chạy trước, bước nào chạy sau, khi nào dừng lại.
Agent prompting lật ngược điều đó. Với agent, bạn giao cho AI một mục tiêu (goal) thay vì một chuỗi lệnh cố định, đưa cho nó một bộ công cụ, rồi để nó tự quyết định: làm gì trước, quan sát kết quả ra sao, điều chỉnh thế nào, và khi nào coi như xong việc. Nói cách khác, thay vì viết kịch bản từng dòng, bạn viết ra "luật chơi" và để AI tự chơi.
Đây là bước nhảy quan trọng nhất trong toàn bộ khóa học về mặt tư duy. Một nhân viên chăm sóc khách hàng bằng AI theo kiểu prompt thường chỉ trả lời một câu hỏi. Nhưng một agent chăm sóc khách hàng có thể: đọc email khách gửi, tra cứu đơn hàng trong hệ thống, kiểm tra chính sách hoàn tiền, soạn phản hồi, và nếu vượt thẩm quyền thì chuyển cho người thật — tất cả trong một vòng lặp tự động. Sự khác biệt giữa "trả lời" và "hoàn thành công việc" chính là thứ mà bài này dạy bạn.
Trọng tâm của bài này là vòng lặp Plan – Act – Observe (Lập kế hoạch – Hành động – Quan sát), trái tim của mọi agent hiện đại, từ AutoGPT cho tới các agent doanh nghiệp mà bạn có thể tự xây.
Khái niệm cốt lõi
Giải phẫu một agent — 3 thành phần bắt buộc
Một agent, dù đơn giản hay phức tạp, luôn được cấu thành từ ba phần. Nếu thiếu bất kỳ phần nào, nó không còn là agent nữa mà chỉ là một prompt thông thường.
1. Goal (Mục tiêu) — trạng thái đích cần đạt được. Đây phải là một trạng thái kết thúc rõ ràng, không phải một hành động. So sánh: "tìm giá vé máy bay Hà Nội – Đà Nẵng" là hành động; còn "tìm được 3 vé rẻ nhất Hà Nội – Đà Nẵng ngày 15/7, dưới 1.5 triệu, và trình bày dạng bảng" là một goal. Goal tốt phải kèm tiêu chí hoàn thành (success criteria) để agent biết khi nào được phép dừng.
2. Tools (Công cụ) — tập hợp các hành động agent được phép thực hiện: tìm kiếm web, chạy code, gọi API nội bộ, đọc file, gửi email. Mỗi tool cần được mô tả rõ: nó làm gì, cần input gì, trả về gì. Đây chính là function calling ở Bài 24, nhưng nay agent tự chọn tool nào để dùng thay vì bạn ép nó.
3. Memory (Bộ nhớ) — lịch sử của những gì đã làm và những gì đã quan sát được. Không có memory, agent sẽ lặp lại chính hành động vừa làm hoặc quên mất mình đang ở đâu trong nhiệm vụ. Memory gồm hai loại: short-term (ngữ cảnh của phiên làm việc hiện tại, nằm trong context window — xem lại Bài 12) và long-term (kiến thức lưu ngoài, thường qua RAG ở Bài 25).
Vòng lặp Plan – Act – Observe
Trái tim của agent là một vòng lặp lặp đi lặp lại cho tới khi đạt goal:
Plan (Lập kế hoạch) — Dựa trên goal và memory hiện có, agent suy nghĩ: "Bước tiếp theo tôi nên làm gì?" Đây thực chất là Chain-of-Thought (Bài 7) áp dụng vào việc chọn hành động. Agent lý luận ra một ý định và chọn một tool phù hợp cùng tham số đầu vào.
Act (Hành động) — Agent thực thi tool đã chọn. Ví dụ gọi API search_orders(customer_id=123). Đây là điểm agent chạm vào thế giới thực, tạo ra tác động thật.
Observe (Quan sát) — Kết quả của hành động được đưa ngược lại vào memory. API trả về "đơn hàng #4521, trạng thái: đang giao". Agent đọc kết quả này, cập nhật hiểu biết, rồi quay lại bước Plan để quyết định bước kế tiếp.
Vòng lặp chạy: Plan → Act → Observe → Plan → Act → Observe... cho tới khi agent tự đánh giá rằng goal đã đạt (theo success criteria) hoặc chạm giới hạn (hết số vòng cho phép, hết token, hoặc gặp lỗi không xử lý được).
Cách phổ biến nhất để hiện thực hóa vòng lặp này trong prompt là mẫu ReAct (Reasoning + Acting), yêu cầu agent xuất ra theo định dạng lặp lại:
Thought: (agent lý luận về bước tiếp theo)
Action: (tên tool + tham số)
Observation: (kết quả trả về từ tool — do hệ thống điền vào)
... lặp lại ...
Thought: Tôi đã có đủ thông tin để trả lời.
Final Answer: (kết quả cuối cùng)
Vì sao cần cấu trúc này thay vì một prompt dài?
Bạn có thể hỏi: sao không viết một prompt cực dài liệt kê hết mọi tình huống? Vì thực tế không thể đoán trước mọi nhánh. Khi tra đơn hàng, kết quả có thể là "đang giao", "đã hủy", "không tồn tại" — mỗi kết quả dẫn tới một hành động khác nhau. Vòng lặp Plan-Act-Observe cho phép agent phản ứng với thực tế thay vì đi theo kịch bản cứng. Đó là lý do agent mạnh hơn prompt chaining tĩnh khi nhiệm vụ có tính bất định.
Tình huống thực tế
Ví dụ 1 — Tiki: Agent xử lý khiếu nại giao hàng chậm
Giả định một đội vận hành của một sàn thương mại điện tử lớn như Tiki xây agent xử lý khiếu nại "đơn giao chậm". Trước đây mỗi ticket mất trung bình 8 phút của nhân viên: đọc khiếu nại, mở hệ thống tra đơn, tra chính sách bồi thường, soạn mail xin lỗi kèm voucher.
Họ định nghĩa agent như sau:
- Goal: "Giải quyết ticket khiếu nại giao chậm sao cho khách hài lòng, đúng chính sách công ty. Hoàn thành khi đã gửi phản hồi hoặc chuyển cấp trên."
- Tools:
tra_don_hang(ma_don),tra_chinh_sach(loai_khieu_nai),cap_voucher(khach_id, gia_tri),soan_mail(noi_dung),chuyen_cap_tren(ly_do). - Memory: nội dung ticket + lịch sử các bước đã làm.
- Thought: Cần biết đơn giao chậm bao nhiêu ngày. → Action:
tra_don_hang("TK4521")→ Observation: "Dự kiến 3 ngày, thực tế 8 ngày, chậm 5 ngày." - Thought: Chậm 5 ngày, cần tra mức bồi thường. → Action:
tra_chinh_sach("giao_cham")→ Observation: "Chậm >3 ngày: voucher 50k." - Thought: Đủ điều kiện voucher. → Action:
cap_voucher("KH889", 50000)→ Observation: "Đã cấp voucher V-2231." - Thought: Soạn mail xin lỗi kèm voucher. → Action:
soan_mail(...)→ Final Answer: Gửi xong.
chuyen_cap_tren." Agent tự động biết đâu là giới hạn thẩm quyền của mình. Kết quả giả định: 70% ticket được giải quyết tự động, thời gian trung bình còn dưới 30 giây; 30% còn lại (ca phức tạp) được agent chuyển đúng người.Ví dụ 2 — Startup fintech ở Singapore: Agent nghiên cứu đối thủ
Một startup fintech nhỏ ở Singapore cần cập nhật bảng so sánh phí của 5 đối thủ mỗi tuần. Công việc này lặp đi lặp lại nhưng phải "lục" nhiều nguồn nên khó viết prompt tĩnh.
Họ dựng một research agent:
- Goal: "Lập bảng so sánh phí chuyển tiền quốc tế của 5 công ty [danh sách], cột: phí cố định, phí %, thời gian nhận. Chỉ dùng dữ liệu từ trang chính thức."
- Tools:
web_search(query),fetch_page(url),extract_table(html).
Bài học rút ra: Họ giới hạn max_iterations = 15 vòng lặp. Có lần agent rơi vào vòng lặp vô tận vì một trang chặn bot: nó cứ fetch_page → lỗi → thử lại → lỗi. Giới hạn số vòng lặp và yêu cầu agent "nếu một tool thất bại 2 lần liên tiếp, hãy bỏ qua và ghi chú" đã cứu họ khỏi việc đốt token vô ích.
Ví dụ 3 — Phòng marketing nội bộ: Agent soạn báo cáo tuần
Một phòng marketing của công ty SaaS Việt Nam giao cho agent nhiệm vụ tổng hợp báo cáo hiệu suất quảng cáo hàng tuần.
- Goal: "Tạo báo cáo tuần gồm: tổng chi tiêu, CPL (chi phí mỗi lead), kênh hiệu quả nhất, và 2 đề xuất hành động."
- Tools:
query_ads_api(platform, date_range),tinh_toan(bieu_thuc),viet_bao_cao(du_lieu).
tinh_toan là mấu chốt: nó tránh lỗi "ảo giác số liệu" mà LLM thường mắc.Bài học rút ra: Đừng để agent tự làm những việc mà một tool chuyên dụng làm chính xác hơn. Giao phép tính cho máy tính, giao truy vấn dữ liệu cho API — agent chỉ nên điều phối và lý luận, không nên tính toán thủ công.
Hướng dẫn từng bước
Đây là quy trình để bạn tự xây một agent prompt từ đầu:
Bước 1 — Định nghĩa goal kèm success criteria. Viết một câu trạng thái đích rõ ràng và một danh sách điều kiện "coi như xong". Ví dụ: "Đã gửi phản hồi cho khách" HOẶC "đã chuyển ticket cho quản lý". Không có tiêu chí dừng, agent sẽ chạy mãi.
Bước 2 — Liệt kê tools và viết mô tả chuẩn. Với mỗi tool ghi rõ: tên, chức năng một dòng, tham số đầu vào, kiểu dữ liệu trả về. Mô tả càng rõ, agent càng chọn tool đúng. Đây là phần quan trọng nhất — agent chọn sai tool thường vì mô tả tool mơ hồ.
Bước 3 — Viết system prompt định hình hành vi. Trong system prompt (nhớ lại Bài 8), quy định: agent là ai, phải suy nghĩ theo mẫu Thought/Action/Observation, các ràng buộc an toàn (guardrail), và khi nào thì dừng. Ví dụ: "Luôn tra chính sách trước khi cấp voucher. Không bao giờ cấp quá 200k mà chưa hỏi cấp trên."
Bước 4 — Thiết lập vòng lặp và giới hạn. Trong code điều phối, đặt max_iterations (thường 10–20), timeout, và cơ chế xử lý lỗi tool. Sau mỗi Action, nhét Observation trở lại vào ngữ cảnh rồi gọi lại model.
Bước 5 — Yêu cầu định dạng đầu ra có cấu trúc. Buộc agent trả Action dưới dạng JSON (Bài 9) để code parse được chính xác: {"tool": "tra_don_hang", "args": {"ma_don": "TK4521"}}. Đừng để agent trả text tự do — sẽ rất khó bóc tách.
Bước 6 — Test với các ca biên. Chạy thử với đầu vào bình thường, đầu vào lỗi, và đầu vào cố tình gài (đơn không tồn tại, khách đòi vô lý). Quan sát agent phản ứng và tinh chỉnh guardrail.
Lỗi thường gặp & mẹo
Lỗi 1 — Goal quá mơ hồ, không có tiêu chí dừng. Agent không biết khi nào xong nên hoặc dừng quá sớm (chưa đủ thông tin) hoặc chạy lê thê. Mẹo: Luôn viết success criteria dạng checklist ngay trong prompt.
Lỗi 2 — Không đặt max_iterations. Đây là lỗi tốn tiền nhất. Agent kẹt trong vòng lặp gọi tool thất bại rồi thử lại vô tận, đốt sạch token budget. Mẹo: Luôn đặt giới hạn cứng số vòng lặp và quy tắc "thất bại N lần thì bỏ qua".
Lỗi 3 — Mô tả tool sơ sài. Agent chọn nhầm tool hoặc truyền sai tham số. Mẹo: Viết mô tả tool như viết tài liệu API cho người mới — kèm ví dụ input/output.
Lỗi 4 — Cho agent quá nhiều tool cùng lúc. Với 20+ tool, agent bị "ngợp" và chọn sai. Mẹo: Bắt đầu với 3–5 tool cốt lõi, thêm dần khi cần. Ít tool nhưng rõ ràng luôn tốt hơn nhiều tool mơ hồ.
Lỗi 5 — Thiếu guardrail cho hành động không thể hoàn tác. Agent lỡ gửi email sai, hoàn tiền nhầm, xóa dữ liệu. Mẹo: Với mọi hành động "một chiều" (gửi mail, chuyển tiền, xóa), thêm bước xác nhận hoặc yêu cầu quyền con người — human-in-the-loop.
Mẹo vàng — Bắt agent "nói ra suy nghĩ" (Thought) trước mỗi Action. Việc buộc lý luận trước hành động (theo mẫu ReAct) giúp agent chọn đúng hơn và giúp bạn debug: khi agent làm sai, bạn đọc Thought là biết ngay nó hiểu sai chỗ nào.
Bài tập thực hành
Bài 1 — 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ụ: lọc CV ứng viên, tổng hợp phản hồi khách hàng). Viết ra đầy đủ: Goal + success criteria, danh sách 3–5 Tools kèm mô tả, và 2 guardrail. Đây là bước quan trọng nhất trước khi động vào code.
Bài 2 — Viết vết vòng lặp thủ công. Với agent bạn vừa thiết kế, viết tay một chuỗi Thought → Action → Observation cho một tình huống cụ thể (ít nhất 4 vòng lặp), bao gồm một vòng mà kết quả Observation bất ngờ buộc agent đổi kế hoạch. Điều này giúp bạn thấy vòng lặp "sống" ra sao.
Bài 3 — Tìm điểm dừng và điểm chuyển người. Liệt kê 3 tình huống agent của bạn KHÔNG nên tự xử lý mà phải chuyển cho con người. Viết quy tắc guardrail tương ứng cho từng tình huống.
Bài 4 (nâng cao) — Nếu bạn dùng được công cụ như OpenAI Playground, LangChain, hoặc một framework agent bất kỳ, hãy hiện thực hóa agent ở Bài 1 với 2 tool giả (mock) và chạy thử 3 đầu vào khác nhau. Quan sát agent chọn tool nào và ghi lại một lần nó chọn sai.
Tóm tắt
- Agent = Goal + Tools + Memory, khác biệt cốt lõi so với prompt thường: bạn giao mục tiêu thay vì kịch bản, và để AI tự điều phối.
- Trái tim của agent là vòng lặp Plan – Act – Observe: lập kế hoạch bước kế tiếp, thực thi tool, quan sát kết quả, rồi lặp lại cho tới khi đạt goal hoặc chạm giới hạn.
- Mẫu ReAct (Thought → Action → Observation → Final Answer) là cách phổ biến để hiện thực vòng lặp này trong prompt.
- Sức mạnh của agent nằm ở khả năng phản ứng với thực tế bất định — điều mà prompt chaining tĩnh không làm được.
- Ba nguyên tắc sống còn khi triển khai: goal có tiêu chí dừng rõ ràng, luôn đặt max_iterations, và guardrail cho mọi hành động không thể hoàn tác.
- Giao việc tính toán/truy vấn cho tool chuyên dụng; agent chỉ nên lý luận và điều phối.