Bài 2 — Tool Use: cho agent "tay chân" để hành động thật

Tại sao tool use là trái tim của agent

Một LLM đơn thuần chỉ biết sinh ra chữ. Nó không thể tự đọc email của bạn, không tự truy vấn database, không tự trừ tiền tài khoản. Tool use (còn gọi function calling) là cơ chế cho phép model gọi hàm/API để tác động vào thế giới thật rồi đọc kết quả trả về. Không có tool use, agent chỉ là người nói giỏi mà không làm được gì.

Cách hoạt động (đơn giản hóa): bạn khai báo cho model một danh sách tool kèm mô tả và schema tham số. Model đọc yêu cầu người dùng, quyết định gọi tool nào với tham số gì (trả về JSON có cấu trúc), hệ thống của bạn thực thi tool đó, rồi trả kết quả lại cho model để nó suy luận bước tiếp theo.

Ba loại tool theo góc nhìn PM

• Read tools (đọc) — lấy thông tin: tìm kiếm, truy vấn DB, đọc lịch. Rủi ro thấp.
• Write tools (ghi/hành động) — thay đổi trạng thái thế giới: gửi email, tạo đơn, hoàn tiền. Rủi ro cao.
• Compute tools (tính toán/logic) — chạy code, gọi mô hình khác, tính số. Rủi ro trung bình.

Quy tắc PM: read tools có thể tự do, write tools phải có rào chắn. Một agent đọc nhầm thì tốn thời gian; một agent hoàn tiền nhầm 10.000 đơn thì mất tiền thật và mất niềm tin.

Thiết kế tool tốt là việc của PM, không chỉ của kỹ sư

Chất lượng agent phụ thuộc rất nhiều vào mô tả tool. Đây là ví dụ tư duy sản phẩm:

• Tên và mô tả rõ ràng: refund_order(order_id, amount, reason) với mô tả "Chỉ dùng khi đơn đã xác nhận lỗi từ phía cửa hàng". Mô tả mơ hồ → agent gọi sai lúc.
• Schema chặt: giới hạn amount không vượt giá đơn; bắt buộc reason. Ràng buộc ở tầng tool là hàng rào an toàn cuối cùng.
• Thông báo lỗi hữu ích: khi tool fail, trả về thông điệp mà model hiểu và tự sửa được ("order_id không tồn tại, hãy hỏi lại khách mã đơn") thay vì chỉ Error 500.
• Idempotency (bất biến khi lặp): nếu agent gọi lại create_ticket hai lần vì timeout, đừng tạo 2 ticket. Đây là chi tiết cứu bạn khỏi sự cố production.

Ví dụ thực tế: agent hỗ trợ khách hàng

Khách nhắn: "Đơn của tôi giao trễ, tôi muốn được xử lý." Agent cần chuỗi tool:

• lookup_order(email) — đọc trạng thái đơn (read).
• check_policy(order) — đối chiếu chính sách bồi thường (read).
• Nếu đủ điều kiện → issue_voucher(order_id, value) (write, nhưng giới hạn giá trị).
• Nếu vượt ngưỡng → chuyển người (escalate) thay vì tự quyết.

Ranh giới ở bước 3–4 chính là nơi PM tạo ra giá trị và giảm rủi ro.

Khung "4 câu hỏi cho mỗi tool"

• Tool này đọc hay ghi? (quyết định mức rào chắn)
• Hậu quả tệ nhất khi gọi sai là gì?
• Có giới hạn/ngưỡng nào cần đặt cứng trong schema không?
• Khi tool fail, model có đủ thông tin để tự phục hồi không?

Sai lầm thường gặp

• Cho agent quá nhiều tool (20+): model bối rối, chọn nhầm. Bắt đầu ít, thêm dần.
• Mô tả tool mơ hồ, khiến agent gọi write tool sai thời điểm.
• Không giới hạn quyền write — bug nhỏ thành thảm họa tài chính.
• Thông báo lỗi vô nghĩa khiến agent lặp lại lỗi mãi (loop).
• Quên idempotency, tạo trùng đơn/ticket khi retry.

Checklist kết bài

• [ ] Tôi phân loại được tool thành read / write / compute.
• [ ] Mỗi write tool của tôi có ngưỡng giới hạn và điều kiện escalate.
• [ ] Mô tả tool đủ rõ để agent gọi đúng lúc.
• [ ] Tool fail trả về thông điệp giúp agent tự sửa.