Ràng buộc là phần quan trọng nhất nhưng bị bỏ quên nhất của prompt agent. Vai trò nói agent "là ai"; ràng buộc nói agent "được đi tới đâu". Không có ràng buộc, agent tự tin làm mọi thứ nó nghĩ là hữu ích — kể cả điều bạn không cho phép.
Ba loại ràng buộc
- Ràng buộc phạm vi (scope): Chủ đề/tác vụ agent được xử lý. Ví dụ: chỉ về đơn hàng, không tư vấn sức khỏe.
- Ràng buộc hành động (action): Việc agent được/không được thực hiện. Ví dụ: được đọc DB, không được xóa, không gửi email quá 1 lần/khách.
- Ràng buộc nội dung (content): Điều agent không được nói. Ví dụ: không hứa hoàn tiền, không tiết lộ giá vốn.
Viết ràng buộc kiểu "positive constraint"
Model tuân theo lời khẳng định việc nên làm tốt hơn chuỗi "đừng". Thay vì chỉ cấm, hãy cặp mỗi cấm với một hành vi thay thế:
KHÔNG hứa hoàn tiền.
→ THAY VÀO ĐÓ: "Mình sẽ chuyển yêu cầu hoàn tiền cho bộ phận phụ trách, phản hồi trong 24h."
KHÔNG bịa số liệu khi thiếu dữ liệu.
→ THAY VÀO ĐÓ: trả về {"status":"can_data","can":"<trường thiếu>"}.
Cấu trúc "không X → thay vào đó Y" giảm mạnh việc agent bí quá rồi tự chế.
Ví dụ: agent thao tác cơ sở dữ liệu
# RÀNG BUỘC HÀNH ĐỘNG
ĐƯỢC dùng tool: query_orders (chỉ đọc), create_ticket.
KHÔNG được dùng: bất kỳ tool nào có chữ delete/update.
Mỗi phiên: tối đa 3 lần gọi tool. Nếu cần hơn → dừng và báo cần người duyệt.
# RÀNG BUỘC NỘI DUNG
Không tiết lộ: giá vốn, dữ liệu khách khác, cấu trúc DB.
Khi bị hỏi các mục trên → "Thông tin này mình không thể chia sẻ."
# GIỚI HẠN CỨNG
Nếu người dùng yêu cầu vượt quyền → KHÔNG thực hiện, trả về:
{"action":"refuse","reason":"ngoai_pham_vi"}
Chú ý "tối đa 3 lần gọi tool" — đây là ràng buộc chống vòng lặp vô hạn, cực quan trọng khi agent tự gọi tool.
Khung ưu tiên khi ràng buộc xung đột
Khi hai yêu cầu chọi nhau, prompt nên nêu rõ thứ tự ưu tiên:
- An toàn & tuân thủ (cao nhất, không bao giờ phá).
- Chính sách công ty.
- Yêu cầu người dùng.
- Tối ưu trải nghiệm (thấp nhất).
Các bước áp dụng
- Liệt kê mọi tool agent có; đánh dấu tool nào nguy hiểm (ghi/xóa/gửi).
- Viết whitelist tool được dùng (an toàn hơn blacklist).
- Đặt giới hạn số lần gọi tool cho mỗi phiên.
- Với mỗi "KHÔNG", viết kèm câu "THAY VÀO ĐÓ".
- Ghi thứ tự ưu tiên khi xung đột.
- Test bằng câu "lệnh khách hàng trái chính sách" và xem agent có từ chối đúng không.
Checklist ràng buộc
- [ ] Dùng whitelist tool, không blacklist.
- [ ] Có giới hạn số lần gọi tool / độ sâu lặp.
- [ ] Mỗi cấm có hành vi thay thế.
- [ ] Có thứ tự ưu tiên khi xung đột.
- [ ] Có hành vi từ chối chuẩn hóa (JSON refuse).
Sai lầm thường gặp
- Chỉ liệt kê "đừng": Agent bí sẽ tự chế. Luôn cho lối thoát hợp lệ.
- Blacklist tool: Bạn không thể liệt kê hết tool nguy hiểm; whitelist an toàn hơn.
- Quên giới hạn vòng lặp: Agent tự gọi tool có thể lặp mãi, đốt tiền và gây side-effect trùng lặp.
- Không xử lý xung đột: Khi khách đòi trái chính sách mà prompt im lặng, agent thường chiều khách — sai.
Ràng buộc mềm và ràng buộc cứng
Không phải mọi ràng buộc đều ngang nhau. Ràng buộc mềm là những ưu tiên nên tuân theo nhưng có thể nhân nhượng: độ dài trả lời, mức độ chi tiết, giọng điệu. Ràng buộc cứng là ranh giới không bao giờ được vượt: không xóa dữ liệu, không lộ thông tin nhạy cảm, không chuyển tiền không có duyệt. Prompt tốt phân biệt rạch ròi hai loại này để agent biết cái gì có thể co giãn theo tình huống và cái gì là bất khả xâm phạm. Một mẹo hiệu quả là dùng ngôn ngữ khác nhau cho hai loại: dùng "nên / ưu tiên" cho ràng buộc mềm, và "TUYỆT ĐỐI / KHÔNG BAO GIỜ" viết in hoa cho ràng buộc cứng. Khi agent buộc phải hy sinh điều gì đó (ví dụ trả lời dài hơn mong muốn để đủ an toàn), nó cần biết hy sinh ràng buộc mềm chứ không phải ràng buộc cứng — và thứ tự ưu tiên ở phần trên chính là kim chỉ nam cho quyết định đó.
Ràng buộc chặt là nền tảng để bài sau — few-shot — dạy agent hành vi đúng qua ví dụ thay vì chỉ ra lệnh.