# Vài trăm đơn trên cả một nền tảng lớn: con agent thiếu năng lực, hay thiếu một lý do để tin?
Hôm nay mình đọc một con số mà đọc xong ngồi im một lúc.
Một nền tảng đặt đồ ăn rất lớn, hàng triệu người dùng mỗi ngày, đã mở đường cho AI agent bên ngoài đặt hộ. Kết quả sau một thời gian: vài trăm đơn.
Không phải vài trăm nghìn. Vài trăm.
Mình đọc comment bên dưới thì thấy số đông kết luận giống nhau: model chưa đủ giỏi. Đợi nó giỏi hơn là xong.
Mình không nghĩ vậy. Và mình nghĩ chỗ mình nghĩ khác chính là chỗ có tiền.
Đặt một bữa ăn là bài toán dễ nhất trong tất cả các bài toán
Thử bóc xem con agent đó phải làm gì.
Chọn món. Đọc thực đơn, đối chiếu khẩu vị, đối chiếu ngân sách, đối chiếu mấy món người ta đã ăn lần trước. Cái này khó thật, nhưng khó theo kiểu "cần ngữ cảnh", mà ngữ cảnh thì ngày càng rẻ.
Hiểu địa chỉ. Cũng không khó. Cùng lắm là một lần hỏi lại cho chắc.
Bấm trả tiền. Đây — đây là chỗ mình dừng lại.
Một bữa ăn là bài toán dễ nhất trong tất cả các bài toán mà mình có thể đưa cho máy: hậu quả nhỏ, giá trị nhỏ, sai thì cùng lắm ăn nhầm bữa tối. Nếu hệ nào cũng làm được thì đây phải là chỗ agent bùng nổ đầu tiên.
Nó không bùng nổ. Vậy cái thiếu không phải năng lực.
Cái thiếu là quyền. Cụ thể hơn: là lý do để chuyển quyền.
Ba câu người ta hỏi ngầm trước khi giao tiền cho một cái máy
Mình để ý một chuyện: khi nói "để agent làm hộ", người ta hay hình dung việc đó là một việc kỹ thuật. Nhưng thật ra nó là một việc xã hội. Người dùng không hỏi "nó làm được không". Họ hỏi ba câu khác, và thường không nói ra:
Một, nếu nó sai thì ai trả tiền? Không phải câu hỏi pháp lý. Là câu hỏi về cảm giác: khi tôi ngồi ngoài, để một hệ thay tôi quyết, và nó quyết sai, tôi có phải tự đi xin lỗi một mình không.
Hai, nó có làm hai lần không? Đặt một bữa ăn mà bị tính tiền hai lần thì không phải lỗi kỹ thuật, là một buổi tối đi đòi tiền. Không ai muốn rủi ro đó đổi lấy vài phút tiết kiệm.
Ba, tôi có biết nó vừa làm gì không? Đây là câu mình nghĩ quan trọng nhất và cũng ít được nói tới nhất. Người ta không cần xem log. Người ta cần một thứ đọc được trong ba giây: nó đã đặt gì, ở đâu, bao nhiêu, khi nào.
Ba câu đó nghe như ba tính năng. Nhưng mình nghĩ chúng là một thứ khác: một nghi thức. Cái nghi thức mà mọi giao dịch giữa người với người đều có — xác nhận, biên lai, đường lùi — và mình vô tình bỏ qua khi thiết kế cho máy, vì mình nghĩ máy không cần nghi thức, máy chỉ cần API đúng.
Và đây là chỗ mình muốn nói một điều mà mình tin khá chắc:
Năng lực tăng theo đường cong. Niềm tin tăng theo số lần không có gì xấu xảy ra.
Hai đường đó không cùng dạng. Năng lực có thể nhảy bậc sau một bản cập nhật. Niềm tin thì không nhảy — nó tích luỹ theo từng lần chạy êm, và nó bị xoá sạch bởi một lần chạy không êm. Nên "model giỏi gấp đôi" không mua được "niềm tin gấp đôi". Nó chỉ làm cho lần chạy êm tiếp theo có xác suất cao hơn một chút.
Nếu anh em đang chờ một bản model mạnh hơn để sản phẩm agent của mình bùng nổ, thì theo logic này, anh em đang chờ đúng thứ nhưng sai bậc thang.
Chỗ mình thấy điều này trong công việc của mình
Mình có một chuỗi tự động hoá chạy nền làm được phần lớn việc trong một quy trình. Không phải 60%. Phần lớn.
Nhưng khâu cuối mình vẫn tự làm. Suốt một thời gian dài mình tự nhủ là vì máy chưa làm nổi khâu đó.
Rồi một hôm mình ngồi bóc thật, và câu trả lời khác hẳn: máy làm nổi. Cái mình thiếu là cách biết nó đã làm hay chưa.
Khi mình tự làm khâu cuối, mình biết chắc nó xong vì chính tay mình làm. Khi để máy làm, mình phải mở ra xem, mà mở ra xem thì cũng bằng công làm. Nên mình chọn làm — không phải vì máy dở, mà vì đường đi xác nhận còn đắt hơn đường đi làm.
Mình gọi đây là thiếu biên lai. Và mình nghĩ nó chính là lý do vài trăm đơn kia không thành vài trăm nghìn: người ta không thiếu một con agent giỏi hơn, người ta thiếu một tờ biên lai đọc trong ba giây, cộng một nút hoàn tác.
Nhưng trong doanh nghiệp, cùng con agent đó chết kiểu khác
Đây là phần mình nghĩ ít người để ý, và nó là phần liên quan trực tiếp tới tiền.
Cùng một con agent, mang vào doanh nghiệp. Ở đó không có rào cản niềm tin rõ rệt như người tiêu dùng — sếp vẫn cho chạy, vì nó chạy trong nội bộ, sai thì sửa. Nên nó sống. Nó chạy ba tháng. Nó tiết kiệm rất nhiều giờ.
Và rồi tới kỳ review ngân sách, có người hỏi: "Vậy tiền ở đâu?"
Im lặng.
Không phải vì nó không tạo ra giá trị. Mà vì "giờ tiết kiệm" là đơn vị của người làm, không phải đơn vị của người trả.
Người trả tiền không mua giờ. Họ mua một thứ đã xảy ra, nhìn thấy được: một việc giao xong, một khoản chi phí biến mất, một rủi ro không còn, một người không phải tuyển thêm, một khách không bỏ đi. "Tiết kiệm 40 giờ mỗi tháng" không nằm trong danh sách đó, vì 40 giờ đó không xuất hiện ở đâu trong bảng cân đối — nó chỉ xuất hiện dưới dạng "tháng này đội mình đỡ mệt hơn".
Và có một cái ác hơn: giờ tiết kiệm không chỉ vô hình, nó có thể phản tác dụng. Tiết kiệm càng nhiều, câu hỏi càng khó: "Tiết kiệm 40 giờ mà sao hoá đơn vẫn thế? Sao đội vẫn đông người? Sao tôi vẫn phải chờ?"
Không có câu trả lời thì cái tiết kiệm bị coi là ảo. Và khi bị coi là ảo một lần, lần sau người ta không tin con số nữa — kể cả khi nó thật.
Hai kiểu chết, một gốc
Đặt hai câu chuyện cạnh nhau thì mình thấy chúng là một.
Người tiêu dùng: giá trị đã sinh ra (đỡ phải làm), nhưng chỗ sinh ra giá trị dính tới quyền — tiền, địa chỉ, thứ không hoàn tác được — nên phải có nghi thức tin cậy mới đi qua được. Không có nghi thức thì giá trị nằm lại phía bên kia hàng rào.
Doanh nghiệp: quyền thì có sẵn, nhưng thiếu thước đo. Giá trị chảy ra ngoài và không ai bắt được, nên cuối năm nó bốc hơi khỏi cuộc họp.
Cả hai đều là: giá trị sinh ra ở chỗ không có ai đứng đo. Người dùng không đứng đo được (không có biên lai). Người trả tiền không đứng đo được (không có đơn vị). Cùng một khoảng trống, hai hình dạng.
Nên có hai thứ mình nghĩ phải thiết kế trước dòng code đầu tiên, không phải sau khi hệ chạy được. Mình đã làm ngược thứ tự này và trả giá bằng mấy tháng.
Một: đơn vị việc
Không phải "lượt gọi". Không phải "giờ". Không phải "số bài đã đăng". Mà là một việc có đủ ba thứ:
- ▹chủ — ai là người nhận kết quả, có tên;
- ▹định nghĩa xong — cái gì phải đúng thì mới gọi là xong;
- ▹điều kiện thoát — khi nào thì bỏ, khi nào thì trả về người.
Phép thử mình dùng: nếu mình không trả lời được trong một câu "hôm qua hệ giao xong bao nhiêu việc", thì mình không có đơn vị việc. Mình có một cái máy đang chạy.
Và đơn vị việc tốt có một tính chất rất cụ thể: nó là thứ khách đã đếm từ trước khi có mình. Số đơn xử lý. Số hồ sơ hoàn tất. Số ticket đóng. Không phải thứ mình nghĩ ra cho đẹp dashboard.
Hai: điểm ghi công
Đây là con số mà người trả tiền đã dùng trước khi có mình, và vẫn dùng sau khi có mình. Nếu mình phải giải thích lại baseline, đó không phải ghi công — đó là kể chuyện, và kể chuyện thì ai cũng kể được, kể cả người không làm gì.
Ba con số mình thấy bền, đều là số của khách chứ không phải số của máy:
- ▹số lần khách phải sửa tay trên 1000 lần chạy — thấp là tốt, và nó nói thật hơn mọi tỷ lệ đúng;
- ▹thời gian từ "yêu cầu vào" đến "xong thật" — chú ý chữ "thật", vì "xong theo log" là một con số khác và nó luôn đẹp hơn;
- ▹số lần phải làm lại vì lỗi không hoàn tác — con số đau nhất và cũng là con số mình hay giấu nhất.
Để ý: "99% đúng", "tiết kiệm 40 giờ", "log xanh toàn bộ" không có mặt trong danh sách. Không phải vì chúng sai. Vì chúng là sức khoẻ của hệ, không phải giá trị của khách.
Hình dạng của hai thứ đó, viết bằng pseudo-code
Đây là hình dạng ý tưởng, không phải nguồn triển khai:
# pseudo-code minh hoạ, không phải code thật
def giao_viec(viec):
# 1. có đơn vị đếm được chưa?
if not viec.don_vi or not viec.dinh_nghia_xong:
return KHONG_GIAO("chưa định nghĩa được thế nào là xong")
# 2. chạm tiền / danh tính / thứ không hoàn tác?
if viec.cham_tien or viec.khong_the_hoan_tac:
return CHO_NGUOI(viec, ly_do="vượt ngưỡng chuyển quyền")
# 3. chạy, và ghi Ý ĐỊNH trước khi làm, không phải ghi kết quả sau khi làm
bien_lai = chay_va_ghi_y_dinh(viec)
# 4. đo bằng thước của khách
ghi_cong(viec.chu, {
"sua_tay": dem_sua_tay(viec),
"thoi_gian_den_xong_that": do_that(viec),
"lam_lai_khong_hoan_tac": dem_lam_lai(viec),
})
return GIAO_XONG(viec, bien_lai)Hai chỗ đáng nói.
Chỗ thứ nhất: CHO_NGUOI không phải TU_CHOI. Đây là chỗ mình từng làm sai suốt một thời gian. Mình coi mọi thứ chạm tiền là "không cho agent đụng", và kết quả là agent thành một công cụ nửa vời — vẫn phải làm tay khâu cuối, khách không thấy giá trị, và mình tự hào về một hệ "an toàn" mà không ai dùng. Cái đúng không phải chặn, mà là chia việc thành hai nửa: nửa được phép làm trọn, và nửa cần một chữ ký. Nhưng nửa thứ hai phải được chuẩn bị tới mức chữ ký là một cái bấm — không phải một buổi làm lại.
Chỗ thứ hai: ghi ý định trước khi làm, không phải kết quả sau khi làm. Ghi sau thì mình chỉ có lời khai của chính cái máy đang được kiểm. Ghi trước thì mình có thứ để đối chiếu — và cái lệch giữa "định làm" và "đã làm" chính là chỗ mình tìm ra phần lớn lỗi thật.
Ba cái bẫy, mình sập cả ba
Bẫy một: đo phần dễ đo. Số lần chạy, số token, số bản ghi xử lý, số bài đã đăng. Đo được hết, đẹp hết, và không trả lời được câu duy nhất khách hỏi. Mình từng dựng một dashboard rất gọn, rất đẹp, và trong cuộc họp có người hỏi một câu mà mình không có cột nào để trả lời. Từ đó mình mới hiểu: dashboard không phải để chứng minh hệ chạy, mà để chứng minh có chuyện gì đã xảy ra với khách.
Bẫy hai: đợi "đủ giỏi rồi mới bán". Niềm tin không đến từ độ giỏi. Nó đến từ số lần chạy mà không có gì xấu xảy ra, cộng một đường lùi có thật. Nên cách mua niềm tin rẻ nhất là bán một phiên bản hẹp và chỉ đọc trước: nó chỉ đề xuất, không ghi; giá phẳng; khách chạy song song với cách cũ một thời gian. Người ta tin cái gì đã chạy cạnh mình ba tuần mà không làm mình phải xin lỗi ai. Đó là mua niềm tin bằng thời gian của khách, thay vì bằng lời hứa của mình.
Bẫy ba: bán giờ tiết kiệm. Hôm nay cùng việc đó tiết kiệm 10 giờ. Sáu tháng sau model tốt hơn, tự động hoá tốt hơn, cùng việc đó tiết kiệm 30 giờ. Giờ mình phải giải thích tại sao hoá đơn không tăng ba lần — hoặc tệ hơn, tại sao khách nên trả nhiều hơn cho cùng một kết quả. Đơn vị "giờ" biến chính sự tiến bộ của mình thành vấn đề về giá. Còn đơn vị "việc giao xong có định nghĩa" thì không: hệ giỏi hơn nghĩa là mình giao được nhiều việc hơn, và giá đi theo việc.
Kết
Con số vài trăm đơn không nói agent dở. Nó nói một điều khó chịu hơn: thứ người ta thiếu không phải một hệ giỏi hơn, mà một lý do để chuyển quyền. Và lý do đó là thứ phải thiết kế, không phải thứ tự đến khi model mạnh lên.
Mình rút ra hai câu để tự soi, và mình hỏi mình mỗi lần định thêm một mắt xích tự động hoá:
Một — nếu ngày mai con agent của mình giỏi gấp đôi, doanh thu có tăng gấp đôi không? Nếu không, mình đang bán sai đơn vị. Mình đang bán một thứ co giãn theo chất lượng, mà chất lượng thì thị trường đang cho không.
Hai — nếu khách hỏi "hôm qua hệ làm xong việc gì", mình trả lời trong bao nhiêu giây? Nếu không trả lời được ngay, thì mình chưa có sổ ghi công, và mọi con số tiết kiệm mình đưa ra đều là lời kể. Lời kể thì chỉ trụ được tới cuộc họp ngân sách tiếp theo.
Còn phần khó nhất, mình vẫn chưa giải xong: làm sao để một tờ biên lai đủ ngắn cho người ta đọc, mà vẫn đủ dài để người ta tin. Hiện tại mình nghiêng về ba dòng — nó làm gì, giá bao nhiêu, sai thì lùi bằng cách nào — nhưng chưa dám chắc.
Anh em đang bán automation theo đơn vị gì? Mình tò mò nhất cái đơn vị mà khách không cãi được, vì mỗi lần tìm ra một cái như vậy thì cả phần định giá phía sau tự sáng ra.