Bạn đứng trước một task. Agent đang ngồi chờ.
Và bạn đang tự hỏi: để nó chạy thẳng, hay review từng bước? Cái nào tốt hơn?
Câu hỏi đó nghe có vẻ đúng. Nhưng cách bạn đang frame nó là nhị phân — thả hay không thả — trong khi thực tế là một gradient. Và gradient đó không được calibrate bằng "cảm giác agent dạo này ổn không." Mà bằng ba đặc tính của chính task đó.
01Vấn đề với câu hỏi nhị phân
✕ "Có tin agent được không?"
✓ "Task này cần gate ở đâu?"
Cùng một agent, cùng một mức năng lực — nhưng khung câu hỏi quyết định bạn dùng được bao nhiêu phần trăm lợi thế của nó.
Câu hỏi nhị phân có vẻ an toàn hơn. Nhưng nó thực ra kém an toàn, vì nó trả lời nhầm tầng: nó hỏi về agent, trong khi thứ cần hỏi là về task.
Agent cùng một lúc đủ tin để viết unit test không cần review, và chưa đủ tin để push thẳng lên database production. Không phải vì agent ở hai trạng thái khác nhau. Mà vì hai task đó khác nhau hoàn toàn về reversibility và consequences.
02Ba chiều để calibrate autonomy
Trước khi giao bất kỳ task nào cho agent chạy không kèm gate, trả lời ba câu:
1. Reversibility — nếu nó làm sai, khó sửa đến đâu?
Một task reversible: xóa sai dòng trong file code → git revert trong ba mươi giây. Một task ít reversible: gửi email cho một nghìn khách → không có undo. Một task không reversible: xóa production database → bạn đang trên bàn phím mà mồ hôi đổ.
Reversibility cao → bạn có thể cho autonomy cao hơn, vì chi phí của sai là thấp. Reversibility thấp → gate ở đầu, ở giữa, hoặc cả hai.
2. Stakes — hậu quả nếu sai là gì và ai chịu?
Một file test sai → bạn biết trong vài giây, tự sửa. Một report sai gửi cho khách → khách biết trước bạn, mất thêm chi phí phục hồi. Một quyết định kiến trúc sai được implement xong → bạn sống với nó ba tháng.
Stakes không chỉ là về thiệt hại — mà về ai phát hiện và khi nào. Task mà sai sẽ bị người khác phát hiện luôn cần gate hơn task mà bạn là người duy nhất chịu.
3. Chain length — output này có ai/thứ gì dùng tiếp không?
Khi agent chạy một task standalone, lỗi chỉ ảnh hưởng task đó. Khi agent là bước đầu trong một chuỗi — output của nó trở thành input của bước tiếp theo — một lỗi nhỏ ban đầu tăng trưởng theo chuỗi. Đến bước ba, bốn, bạn đang debug hệ quả của một giả định sai từ đầu.
Chain dài → gate ở điểm nối, không phải cuối chuỗi. Vì cuối chuỗi bạn đang xem kết quả sau khi lỗi đã nhân nhiều lần.
03Câu chữ thực thi — ba câu hỏi trước khi thả
"Nếu nó làm sai và tôi không phát hiện ngay — mất bao lâu để sửa? Cần ai tham gia? Có thể rollback không?" Nếu trả lời là "5 phút + tôi tự sửa" → autonomy cao được. Nếu là "không biết" → cần gate.
"Ai sẽ là người đầu tiên nhận hậu quả nếu task này sai? Khi nào họ biết?" Nếu đó là bạn và bạn biết ngay → rủi ro thấp. Nếu đó là người khác và họ biết trước bạn → gate bắt buộc.
"Output của task này có ai/hệ thống nào dùng tiếp không? Nếu nó sai từ đầu, lỗi nhân bao nhiêu lần qua chuỗi?" Chain đơn → gate cuối OK. Chain dài → gate ở điểm nối giữa các bước.
Ba câu, mỗi câu khoảng ba mươi giây để trả lời. Làm một lần trước khi giao task, bạn tiết kiệm được thứ tốn hơn rất nhiều sau đó.
04Khi autonomy tăng mà verification không tăng theo
Autonomy không có giới hạn tự nhiên — nó mở rộng theo mức bạn sẵn sàng thả, không phải theo mức an toàn thật sự. Những dấu hiệu trên là tín hiệu dây đang căng quá mức.
05Thả đúng là không phải thả ít hơn
Nếu sau bài này bạn có xu hướng gate nhiều hơn mọi thứ — thì bài này đã truyền đạt sai.
Mục tiêu không phải là giảm autonomy để an toàn hơn. Mục tiêu là tối ưu autonomy — cho task thấp rủi ro chạy nhanh nhất có thể, trong khi task cao rủi ro có đúng loại gate đúng chỗ.
Một người calibrated không phải người verify nhiều nhất. Là người biết chính xác cái gì cần verify, khi nào, và đến mức nào — rồi không tốn thêm một giây nào cho phần còn lại. Đó là điểm agent có thể mang lại lợi thế tốc độ thật sự: không phải vì bạn bỏ qua rủi ro, mà vì bạn đã biết chính xác rủi ro nằm ở đâu trước khi bắt đầu.