Máy nhân bản được, sự chú ý của người thì không
Hàng chục phiên agent chạy song song, mỗi phiên vài câu hỏi nhỏ — đến chiều người trả lời không còn sức cho câu quan trọng nhất. Năm bậc chúng tôi đang dùng, từ một dòng prompt đến một hộp thư quyết định, để người đó quyết ít hơn, nhanh hơn, và không câu trả lời nào bị thất lạc.


Nút thắt dời chỗ
Khi chỉ có một khung chat, AI hỏi gì thì mình trả lời nấy. Không ai thấy mệt.
Khi có vài phiên agent chạy song song, vẫn xoay xở được. Mỗi phiên thỉnh thoảng dừng lại hỏi một câu: chọn phương án nào, có được xoá cái này không, đã duyệt bản thiết kế chưa. Câu nào cũng nhỏ, liếc qua là trả lời xong.
Nhưng quy mô không dừng ở vài phiên. Khi lên tới hàng chục phiên, những câu hỏi nhỏ ấy rải đều suốt ngày, ở hàng chục cửa sổ khác nhau. Trong đội của chúng tôi, có người mỗi ngày điều hành tới hàng trăm phiên. Đến chiều, người trả lời không còn đủ sức nghĩ cho câu quan trọng nhất.
Đó là decision fatigue: mệt mỏi vì phải quyết định. Nó không đến từ một quyết định khó, mà từ rất nhiều quyết định dễ, đến không đúng lúc, ở không đúng chỗ.
Với chúng tôi, đây là nút thắt thật của cả cách làm việc với nhiều agent. Máy thì nhân bản được. Sự chú ý của người đặt việc cho máy thì không. Nếu người đó cạn sức trước buổi trưa, thêm agent chỉ làm hàng đợi dài thêm.
Dưới đây là năm bậc chúng tôi đang dùng, từ rẻ nhất đến tốn công nhất. Bậc nào cũng dùng được riêng; leo đến đâu tuỳ quy mô.


Bậc 1 — Một chỗ để nhìn
Cách đơn giản nhất, không cần cài gì: bảo mọi phiên báo cáo về một phiên duy nhất, rồi chỉ canh phiên đó.
Chỉ cần một dòng trong lời giao việc: "Xong việc hoặc cần hỏi thì báo về phiên tên là …". Nếu đã có một lớp điều khiển phiên (chúng tôi dùng Muster, lớp điều khiển phiên của mình), thì "báo về link này".
Lợi ích không nằm ở chỗ bớt câu hỏi, mà ở chỗ bớt chỗ phải nhìn. Hàng chục cửa sổ thành một. Không còn cảm giác lo lắng thường trực "có phiên nào đang đứng chờ mình không".
Bậc 2 — Luật cho câu hỏi
Phần lớn sự mệt không đến từ việc quyết định, mà từ việc phải dựng lại bối cảnh trước khi quyết. Một câu hỏi kiểu "anh muốn làm thế nào?" buộc người trả lời mở phiên ra, đọc lại từ đầu, tự nghĩ ra các phương án.
Nên chúng tôi đặt luật cho chính câu hỏi. Mỗi câu agent gửi lên phải:
- Tự đứng được — đọc xong trong khoảng 30 giây, không cần mở phiên ra xem.
- Có sẵn lựa chọn — A, B, C, D, bấm là xong.
- Có đề xuất của agent, kèm lý do. Đây là điểm quan trọng nhất: phần lớn trường hợp người trả lời chỉ cần bấm "đồng ý với đề xuất".
- Nói hậu quả và cách hoàn tác của từng lựa chọn.


Agent không được phép đẩy phần nghĩ lên trên. Nó nghĩ xong, đề xuất; người chỉ duyệt hoặc sửa hướng.
Bậc 3 — Không phải câu nào cũng cần đến người
Đây là bậc đỡ mệt nhiều nhất, và cũng là bậc dễ bị bỏ qua nhất.
Khi chúng tôi đếm lại hàng đợi "chờ chủ quyết định" của mình, kết quả khá bất ngờ: trong 20 mục, chỉ khoảng 5 là quyết định thật. Số còn lại là việc lặt vặt bị chặn chờ ai đó gật đầu, việc đóng sổ, việc dọn dẹp. Người trả lời phải lội qua 15 mục vô nghĩa để tìm 5 mục có nghĩa.
Cách sửa là phân loại câu hỏi ngay từ lúc hỏi, và giao mỗi loại cho đúng người:
- Câu hỏi kỹ thuật → agent điều phối trả lời.
- Câu hỏi nghiệp vụ thường ngày → trợ lý nghiệp vụ trả lời.
- Chỉ một nhóm hẹp mới lên tới chủ: định hướng, bảo mật, tiền, production, và những thay đổi không đảo ngược được.
Đi kèm là một câu hỏi phân loại thứ hai: việc này có đảo ngược được không? Việc làm lại được thì agent tự làm, rồi báo lại một dòng. Chỉ việc một chiều mới phải hỏi trước.
Và ủy quyền trước theo phạm vi. Ví dụ: "Trong dự án này, khi mọi bài kiểm tra đều xanh, được tự gộp code vào nhánh chính." Ủy quyền một lần xoá được hàng trăm câu hỏi về sau.
Mệt vì quyết định, nhiều khi thật ra là mệt vì phải phân loại — việc mà một hệ thống làm tốt hơn người.
Bậc 4 — Vẽ ra để nghĩ nhanh
Có những vấn đề mà dù câu hỏi viết gọn đến đâu, người đọc vẫn phải tự dựng sơ đồ trong đầu: luồng dữ liệu đi qua ba hệ thống, năm bên liên quan, hai phương án kiến trúc đánh đổi nhau.
Với loại này, chúng tôi bảo agent — kết hợp với một agent chuyên thiết kế — vẽ mọi thứ ra sơ đồ trước khi hỏi. Nhìn tổng thể một lần, quyết định thường đến trong vài phút thay vì vài buổi.
Cách này tốn token hơn. Nhưng so với chi phí của một quyết định kiến trúc sai, hoặc một buổi chiều bị chặn vì người quyết chưa hình dung ra vấn đề, thì rẻ. Nếu agent thiết kế có sẵn công cụ vẽ theo đúng bộ nhận diện, chi phí còn thấp hơn nữa.
Bậc 5 — Hộp thư quyết định, và câu trả lời phải quay về
Bậc cuối là hạ tầng: một hộp thư quyết định duy nhất cho mọi câu hỏi cần người, từ mọi phiên, mọi máy. Trả lời xong, câu trả lời tự quay về đúng phiên đang chờ để nó làm tiếp.
Phần khó nằm ở vế sau. Chúng tôi từng có hai lần duyệt bị thất lạc: nút duyệt ghi một chỗ, quy trình đọc một chỗ khác, hộp thư hiện trống. Câu trả lời không quay về được nơi đang làm việc thì cũng như chưa trả lời.


Vài nguyên tắc cứng:
- Một bản ghi duy nhất cho mỗi câu hỏi và câu trả lời.
- Hai tốc độ: agent đang chờ thì báo đẩy ngay (có trần); việc không gấp thì gom theo đợt, mỗi đợt không quá 5 câu.
- Im lặng không bao giờ là đồng ý.
- Trả lời một lần, dùng mãi. Câu bị hỏi hai lần là lỗi của hệ thống; câu lặp lại đủ nhiều thì thành luật viết ra.
Đo để biết có đỡ mệt thật không
Cảm giác "đỡ mệt" khó tin được. Chúng tôi theo dõi vài con số:
- Số câu hỏi tới tay chủ mỗi ngày — con số này phải giảm khi leo bậc 3.
- Thời gian từ lúc hỏi đến lúc có câu trả lời.
- Tỷ lệ câu được trả lời bằng tiền lệ thay vì hỏi lại.
- Tỷ lệ chủ bác đề xuất của agent. Con số này cao nghĩa là agent đang hiểu sai ý — cần sửa luật, chứ không phải sửa cách hỏi.
Thứ đắt nhất
Mọi bậc ở trên quy về một điều: trong một tổ chức có nhiều agent, thứ đắt không phải cỗ máy, mà là sự chú ý của người biết đặt việc cho nó. Bảo vệ sự chú ý đó là một việc thiết kế, không phải một việc kỷ luật cá nhân.
Bắt đầu từ bậc 1 chỉ tốn một câu prompt. Hãy thử ngay hôm nay.