# Chip canh agent đang thành hàng thật: thứ bán được không phải con bot, mà là bằng chứng nó đã làm gì
Tuần này có một tin mình đọc xong rồi ngồi im một lúc: một hãng làm chip lớn công bố con chip giám sát để đặt cạnh mỗi AI agent — như một cái đồng hồ công tơ gắn vào con bot, để bên ngoài biết nó đang ăn bao nhiêu và làm gì. Cùng ngày đó còn hai tin khác: một công ty hạ tầng cloud ra mắt công cụ dòng lệnh cho agent, tức là cấp cho con bot quyền điều khiển hạ tầng thật bằng câu lệnh tiếng người. Và một hệ xác minh danh tính, làm ra để dùng được cho cả người, khách sạn, lẫn AI agent — xác minh mà không cần lấy giấy tờ của ai.
Ba tin, ba hướng khác nhau, nghe chẳng liên quan gì. Nhưng mình thấy chúng đang nói đúng một câu:
Agent đang được giao quyền thật. Và cả ngành đang loay hoay tìm cách biết nó đã làm gì.
Cái thứ hai mới là chỗ đáng nói. Vì giao quyền thì dễ, tin được thì khó.
Cái làm mình mất ngủ không phải con bot sai
Mình có một chuỗi tự động hoá chạy nền, chia tầng rõ ràng: thu dữ liệu vào, lọc thô ở tầng rẻ, đẩy phần thật sự cần cho model, rồi ghi kết quả ra nơi lưu. Chạy đều, nhiều tháng nay.
Có một buổi sáng mình mở dashboard ra, xanh hết. Không một dòng đỏ. Nhưng khi mở nơi lưu thì thấy ba ngày không có gì mới.
Hoá ra một mắt xích ở giữa đã chết lặng lẽ. Nó không sập. Nó không ném lỗi. Nó chỉ trả về danh sách rỗng — và với hệ thống, danh sách rỗng là một câu trả lời hợp lệ: "hôm nay không có gì mới". Đúng câu mình vẫn mong đợi vào những ngày yên ắng.
Rồi có lần ngược lại, cũng đau không kém: log ghi "đã gửi xong", trong khi phía bên kia chưa nhận được gì — vì bên ghi log ghi ngay lúc gọi đi, không chờ biết bên nhận có nhận hay không. Mình có kể kỹ vụ đó trong một bài trước, chuyện thử lại mà không nghĩ tới "làm hai lần".
Điểm chung của hai lần: mình không sai ở thiết kế luồng. Mình sai ở chỗ ghi lại.
Cái làm mình mất ngủ không phải con bot làm sai. Mà là mình không có cách nào kiểm chứng nó đã làm gì. Dashboard xanh không phải bằng chứng — nó chỉ là ý kiến của chính con bot về bản thân nó.
Và khi mình bắt đầu nghĩ tới chuyện bán mấy thứ này cho người khác, câu hỏi đó thành câu hỏi sống còn. Khách không hỏi "nó có chạy không". Khách hỏi: "Làm sao tôi biết nó đã làm đúng?"
Nếu câu trả lời của mình là "em mở cái màn hình này anh xem, xanh hết" — thì mình chưa có gì cả.
Log không phải bằng chứng
Đây là chỗ mình nghĩ nhiều người làm automation (trong đó có mình) đi lệch, và lệch rất tự nhiên:
Log do chính kẻ bị kiểm viết ra.
Nó là lời khai, không phải biên lai. Và một lời khai thì có đủ kiểu sai, phần lớn là sai vô tình — không ai cố tình gian lận:
- ▹Hỏng im lặng. Không có dòng nào không phải vì mọi thứ ổn, mà vì đường chạy không đi tới chỗ ghi log. Phần "không bao giờ chạy tới" là phần không có log.
- ▹Ghi đúng chữ, sai thời điểm. Ghi "đã gửi" ngay sau khi gọi đi. Giữa "gọi đi" và "xong ở đầu bên kia" là một khoảng mù — và mọi lần chờ quá lâu, mọi lần timeout, đều rơi vào khoảng mù đó. Trạng thái đúng ở đây không phải hai, mà là ba: xong, hỏng chắc, và chưa biết. Mình từng coi "chưa biết" là "hỏng", rồi thử lại, và tạo ra hai bản ghi thật cho cùng một việc.
- ▹Lớp model tóm tắt lại quá khứ của chính nó. Đây là kiểu mình sợ nhất, vì nó trông đẹp nhất. Cho model đọc lại log thô rồi viết bản tóm tắt cho người, thì mình được một đoạn văn gọn gàng, sạch sẽ, bóng loáng — và sạch đến mức không còn dấu vết của chỗ toang. Báo cáo càng mượt, mình càng nên soi lại.
Nói gọn một câu cho dễ nhớ: log trả lời "chương trình nghĩ gì". Biên lai trả lời "thế giới đã đổi thế nào".
Tin về con chip giám sát kia thật ra là cùng một câu chuyện, chỉ khác là ở tầng phần cứng. Khi thứ tự khai báo của chính con bot không còn đủ tin, ngành bắt đầu đẩy chuyện kiểm chứng ra chỗ khác — ra con chip, ra nằm ngoài tầm với của con bot. Đó là một tín hiệu rất rõ: cái này là vấn đề thật, không phải lo xa.
Nhưng mình không cần chờ tới con chip. Mình cần sửa chỗ ghi.
Ba lớp để có cái mà đưa ra
Mình rút về ba lớp, đủ nhỏ để làm trong một buổi chiều, và đủ chắc để đưa cho khách xem.
Lớp 1 — Ghi ý định TRƯỚC khi hành động. Không ghi sau, ghi trước. Một mã định danh cho việc sắp làm, kèm ý định và tham số, sinh ra trước khi gọi ra ngoài. Cái hay của việc ghi trước không chỉ là lịch sử: nó thành cái bẫy. Nếu một hành động xảy ra ngoài đời mà không có dòng ý định tương ứng đi trước, mình biết ngay có gì đó chạy không qua đường chính. Ghi sau thì không bao giờ bắt được kiểu lỗi này, vì lúc nào chẳng có dòng để ghi.
Lớp 2 — Luôn phải có một "con dấu" từ bên ngoài. Đây là phần mình thấy khó nhất về mặt ý tưởng, và đơn giản nhất khi đã nghĩ ra. Bằng chứng phải là thứ mà con bot, trong tình huống xấu nhất, không tự tạo ra được: phản hồi thô của bên nhận kèm mã tham chiếu, ảnh trạng thái trước và sau khi sửa, hay con số đọc ra từ một nguồn độc lập — cái sổ mà mình không kiểm soát.
Một phép thử mình dùng: nếu chỉ có con bot muốn nói dối (hoặc chỉ bị hỏng theo cách tự tin), nó có bịa được dòng này không? Bịa được thì đừng gọi là bằng chứng. Tự đối chiếu màn hình của mình thì không tính.
Lớp 3 — Đối chiếu định kỳ, và một cổng người ở chỗ đắt giá. Hàng tuần, lấy đúng cái nguồn độc lập kia so với sổ của mình. Lệch thì có người xem. Mỗi tuần một lần, không phải mỗi giây — vì mục tiêu không phải bắt lỗi tức thời, mà là không để cái sai sống sót qua tuần. Dưới đây là hình dạng tối thiểu:
# PSEUDO-CODE minh hoạ — không phải nguồn triển khai
bien_lai = {
"ma_viec": ..., # sinh TRƯỚC khi gọi ra ngoài
"y_dinh": ..., # định làm gì, tham số nào
"dau_ben_ngoai": ..., # thứ mình không tự tạo được
"trang_thai": "xong" | "hong_chac" | "chua_biet",
}
moi tuan:
lech = doi_chieu(so_cua_minh, nguon_doc_lap)
if lech: mo_cong_nguoi(lech) # người xem, không phải model tự xemMột chi tiết nhỏ nhưng quan trọng: biên lai không phải bản sao dữ liệu. Nó là mã việc + con dấu + trạng thái. Không nhét dữ liệu khách vào đó. Mình sẽ nói vì sao ở dưới.
Tiền nằm ở đâu trong chuyện này
Đây là chỗ chuyện kỹ thuật đụng vào chuyện bán hàng, và mình nghĩ nó là điểm ăn tiền thật của cả bài.
Khi một người làm automation đưa sản phẩm cho khách, thứ khách mua không phải con bot chạy. Con bot chạy là điều kiện cần, không phải thứ khiến ai đó móc ví. Thứ khách mua là cảm giác kiểm chứng được: làm xong, tôi biết nó làm gì; hỏng, tôi biết hỏng ở đâu; và tôi có cái để đưa cho sếp tôi khi sếp hỏi.
Ba cách gói cái đó vào sản phẩm, từ dễ tới khó:
- 1.Báo cáo định kỳ có số thật. Không phải bảng đếm "số lần chạy", mà là số việc đã giao thật và số lần phải chữa tay. Mình đã nói ở bài trước: mẫu số mới là thứ quyết định con số có thật hay không. Cái này dễ làm nhất và bán được ngay từ hợp đồng đầu.
- 2.Cam kết sự cố. Không hứa "không bao giờ hỏng" — hứa "khi hỏng, anh biết trong bao lâu". Nghe nhỏ, nhưng nó chuyển khách từ trạng thái đoán sang trạng thái biết, và trạng thái biết là thứ người ta trả tiền để có.
- 3.Cho khách quyền tra bằng chứng. Một chỗ để khách tự xem lại lịch sử việc đã làm, không cần gọi mình. Cái này nặng nhất về công, nhưng là thứ biến mình từ "cậu dev dựng con bot" thành "bên vận hành có trách nhiệm".
Nói theo ngôn ngữ cái thang định giá mình mổ xẻ hôm trước: muốn bán theo kết quả (nấc 4, nấc 5), thì tầng bằng chứng không phải tính năng phụ — nó là điều kiện. Bán theo outcome mà không có gì để đối chiếu thì hai bên không cãi nhau về sản phẩm, mà cãi nhau về sự thật. Cuộc cãi đó mình luôn thua, vì mình là bên cầm máy.
Và có một thứ mình phải tự nhắc: đừng để báo cáo thành nghi lễ. Bằng chứng mà không ai đọc thì chỉ là một tệp đính kèm nữa trong hộp thư khách. Nghi lễ thì tháng sau bị cắt, kèm theo cả niềm tin.
Nhưng bằng chứng cũng là một khoản nợ
Mình đã viết một bài về chuyện mỗi mắt xích tự động hoá là một khoản nợ. Tầng bằng chứng cũng không nằm ngoài quy luật đó, và nó có ba cái bẫy riêng.
Thứ nhất, log phình. Ghi tất cả mọi thứ nghe như an toàn, nhưng tới lúc cần tra thì không ai tra nổi, và cái mình cần lại nằm lẫn trong đống rác. Ít mà đúng chỗ hơn là nhiều.
Thứ hai, bí mật lẫn vào bằng chứng. Đây là cái nguy hiểm nhất, và cũng là cái ít ai nghĩ tới: log thô hay chứa token, nội dung riêng của khách, thông tin đăng nhập. Mình ghi log để bảo vệ khách, rồi tự tay tạo ra một bản sao dữ liệu khách ở chỗ kém bảo vệ nhất. Nên nguyên tắc của mình là: giữ con trỏ, không giữ bản sao. Biên lai trỏ về bản gốc, để bản gốc ở đúng chỗ có phân quyền.
Thứ ba, lưu lâu thành rủi ro. Giữ bằng chứng mãi mãi là một quyết định, không phải mặc định. Mình cần một hạn xoá, và cần biết trước là xoá gì. Ba thứ mình giữ lâu: mã việc, con dấu bên ngoài, và trạng thái "chưa biết" — vì ba thứ đó là thứ sinh ra tranh chấp; phần còn lại xoá được.
Cái mình giữ lại
Mình không nghĩ con chip giám sát kia, hay mấy cái CLI cho agent, hay hệ xác minh danh tính, là ba tin rời rạc. Mình nghĩ chúng là ba mảnh của một mảng đang hình thành: hạ tầng cho việc tin một con bot.
Mà mình không cần chờ nó chín. Phần mình tự làm được, ngay tối nay, chỉ là sửa chỗ ghi: mỗi việc một biên lai bốn dòng, một con dấu lấy từ bên ngoài, và một lần đối chiếu mỗi tuần. Ba việc đó không làm con bot thông minh hơn chút nào. Nhưng nó làm mình dám ký — và dám ký chính là ranh giới giữa người chạy tool cho vui và người bán được automation.
Nên câu mình để lại cho anh em, cũng là câu mình tự hỏi hôm nay: nếu ngày mai khách hỏi "làm sao tôi biết nó đã làm đúng?", anh em có sẵn thứ gì để đưa ra không?
Nếu câu trả lời vẫn là một màn hình xanh — thì cứ nhớ giúp mình một điều: màn hình xanh nào cũng có ngày đỏ. Câu hỏi chỉ là ngày đó, mình có đang đứng cạnh khách hay không.
Một phần của chuỗi mổ xẻ kỹ thuật tại zeodavu.com/blog. Nếu thấy hữu ích, theo dõi [zeodavu.com](/blog) — mỗi bài là một thứ mình thật sự dùng, vấp, và sửa lại.