Có một chia sẻ khá vui nhưng cũng rất đáng suy nghĩ trên r/openclaw: một anh em đã để OpenClaw lo đơn đi chợ hằng tuần suốt 3 tháng, mọi thứ chạy ổn, giỏ hàng đều đặn và đúng nhu cầu. Nhưng đến tuần này, hệ thống đặt nhầm 2 kg tỏi thay vì 2 củ vì trang sản phẩm đang để mặc định đơn vị theo kg.
Nghe thì buồn cười, nhưng đây là đúng kiểu lỗi mà nhiều workflow tự động hóa ngoài đời rất dễ dính: không phải mô hình “ngu” hẳn, mà là hệ thống vận hành trơn tru đủ lâu khiến người dùng bỏ qua bước kiểm tra cuối.
Vấn đề thật sự không nằm ở tỏi
Điểm đáng bàn không phải là một đơn hàng sai, mà là cách niềm tin vào tự động hóa được tích lũy theo thời gian.
Khi một agent làm đúng 10 lần, 20 lần, rồi 3 tháng liên tục, mình bắt đầu chuyển từ chế độ “giám sát” sang chế độ “mặc định tin tưởng”. Đó là lúc những lỗi nhỏ về ngữ cảnh, đơn vị đo, hoặc mapping dữ liệu bắt đầu trở nên đắt giá hơn.
Trong case này, có ít nhất 3 lớp rủi ro rất quen thuộc:
- Đơn vị không đồng nhất: cùng là một món hàng nhưng có nơi bán theo cái, nơi bán theo gram, nơi bán theo kg.
- Default trên giao diện không an toàn: hệ thống có thể đọc đúng sản phẩm nhưng không nhận ra lựa chọn mặc định đang là biến thể khác.
- Người dùng bỏ qua bước review: vì các lần trước đều đúng nên lần này không soi kỹ nữa.
Đây là lỗi UX hay lỗi agent?
Theo mình, đây là lỗi hệ thống tổng hợp hơn là lỗi của riêng model.
Nếu agent chỉ được giao mục tiêu kiểu “mua 2 đầu tỏi” và phải tự đi qua một giao diện ecommerce có biến thể phức tạp, thì chỉ cần một trong các thành phần sau làm chưa tốt là có thể vỡ:
- prompt hoặc instruction không bắt buộc xác minh đơn vị
- browser automation không trích xuất rõ quantity unit
- tool không chuẩn hóa dữ liệu sản phẩm trước khi bấm mua
- không có rule chặn các mức số lượng bất thường
Nói cách khác, agent có thể làm đúng quy trình nhưng sai ở điểm mà workflow chưa dựng hàng rào.
Bài học quan trọng cho anh em đang tự động hóa việc mua sắm
Nếu đang để OpenClaw hay bất kỳ agent nào xử lý mua hàng, mình nghĩ nên thêm ít nhất 5 lớp bảo vệ này:
1. Chuẩn hóa lại yêu cầu đầu vào
Đừng chỉ ghi kiểu:
- mua 2 tỏi
- mua 1 hành
- mua 3 chuối
Nên đổi thành:
- 2 củ tỏi
- 1 kg hành tây
- 1 nải chuối nhỏ hoặc 6 quả chuối
Càng rõ đơn vị, agent càng ít phải đoán.
2. Ép agent đọc lại đơn vị trước khi checkout
Trong flow mua hàng, nên có một bước bắt buộc agent tự đối chiếu:
- tên sản phẩm
- số lượng
- đơn vị
- giá theo đơn vị
- tổng tiền dự kiến
Nếu một trong các trường này thiếu, workflow nên dừng lại thay vì tiếp tục.
3. Đặt ngưỡng cảnh báo cho số lượng bất thường
Một số rule rất đơn giản nhưng cứu mạng:
- nếu rau củ vượt quá mức chi tiêu trung bình 2-3 lần thì cảnh báo
- nếu mặt hàng thường mua theo cái nhưng cart đang tính theo kg thì yêu cầu xác nhận
- nếu tổng tiền một item vượt ngưỡng quen thuộc thì chụp màn hình gửi lại cho người dùng
Những rule này không cần model quá thông minh, chỉ cần logic đủ chặt.
4. Tách bước “đề xuất giỏ hàng” và “chốt thanh toán”
Đây là cách mình thấy an toàn nhất.
Cho agent làm phần nặng:
- tìm đúng món
- gom giỏ hàng
- so sánh giá
- ước tính tổng chi phí
Nhưng bước bấm thanh toán cuối cùng vẫn nên để người dùng duyệt nhanh. Chỉ thêm 30 giây review nhưng giảm rất nhiều lỗi khó chịu.
5. Lưu memory cho các lỗi đã xảy ra
Những case như “tỏi bị đổi sang kg” nên được ghi thành memory hoặc guardrail rõ ràng để agent nhớ:
- với garlic, onion, ginger và nhóm nông sản tương tự, luôn kiểm tra unit
- nếu source site có nhiều biến thể đóng gói, ưu tiên hỏi lại
- nếu quantity parser không chắc chắn, không được tự suy luận
Một sự cố nhỏ nếu được ghi lại đúng cách sẽ trở thành dữ liệu vận hành rất có giá trị cho các lần sau.
Góc nhìn rộng hơn: tự động hóa đời sống không giống tự động hóa code
Trong coding workflow, sai một lệnh thì thường còn log, còn test, còn rollback. Nhưng với các tác vụ đời sống như mua hàng, đặt lịch, chuyển tiền, gửi tin nhắn, hậu quả của lỗi thường rất đời thường và không rollback đẹp được.
Vì vậy, các use case kiểu personal ops sẽ cần:
- guardrail chặt hơn
- xác nhận nhiều lớp hơn
- khả năng phát hiện ngoại lệ theo ngữ cảnh
- và quan trọng nhất là thiết kế workflow theo hướng “an toàn mặc định”
Agent càng được trao quyền tiêu tiền hoặc tác động ra ngoài đời, tiêu chuẩn vận hành càng phải giống một hệ thống production thật sự.
Tin tốt là đây là loại lỗi sửa được khá nhanh
Mình lại khá thích những câu chuyện như vậy vì nó chỉ ra chỗ yếu rất cụ thể. Đây không phải kiểu “AI không dùng được”, mà là một ví dụ rất thực tế cho thấy khi automation bắt đầu chạm vào việc đời sống, anh em phải nâng cấp từ tư duy prompt sang tư duy hệ thống.
Nếu đang build các flow shopping, booking, admin cá nhân bằng OpenClaw, case này đáng để xem như một checklist nhỏ:
- đầu vào có rõ đơn vị chưa
- agent có bắt buộc đọc lại cart không
- có rule phát hiện số lượng bất thường không
- có human review trước khi thanh toán không
- lỗi cũ đã được lưu thành guardrail chưa
Một lần nhận 40 củ tỏi có thể chỉ là chuyện hài. Nhưng nếu cùng pattern đó xảy ra với thuốc, thực phẩm đắt tiền hay các khoản thanh toán định kỳ, cái giá sẽ không còn vui nữa.
Tự động hóa vẫn rất đáng làm. Chỉ là khi mọi thứ bắt đầu chạy ổn, đó cũng là lúc mình cần cảnh giác nhất.
Top comments (0)