Cổng duyệt cuối cùng của agent: bỏ hay giữ là câu hỏi FDE phải trả lời

Jeremy Canale nộp lên arXiv hôm 24/09 một bài với cái tựa gây tò mò: “The Last Human Gate”. Nội dung thì rất kỹ thuật: một khung thay thế từng tác vụ ở các gate quản trị bằng agent, rule engine và evidence service, và người được giao nối tất cả lại với nhau là FDE.

Câu hỏi bài đặt ra cũng là câu hỏi khách hàng sẽ hỏi bạn ngay buổi làm việc đầu tiên: bước nào vẫn cần người ký, bước nào máy làm được. Trả lời sai một chiều, agent bị treo trong hàng đợi phê duyệt. Sai chiều kia, một hành động rủi ro chạy mà không ai hay biết.

Vì thế giá trị của bài không nằm ở khung, mà ở cách nó tách hai thứ thường bị gộp làm một.

Phần đánh giá dùng DGF-Bench với 300 dự án tổng hợp và 899 lượt chạy đủ điều kiện chấm điểm, mỗi lượt là một model trên một dự án; kèm theo là kiểm toán bằng chứng và 135 lần chạy lặp để phân biệt quyết định đúng với việc thực thi đáng tin cậy.

Một agent trả lời đúng một lần chưa đủ; nó phải trả lời đúng ở lần thứ 135.

Có gate chưa thể bỏ, và đó là tin tốt

Chi tiết đáng chú ý nhất là giới hạn bài tự nêu: một phản ví dụ dựa trên tài liệu cho thấy có gate không thể quyết định được từ thông tin sẵn có. Với gate như vậy, vấn đề không nằm ở agent hay rule engine, mà ở chỗ dữ liệu đầu vào chưa đủ để tự động hóa bước đó.

Những gate như vậy chưa thể bỏ, và FDE là người chỉ ra chúng trước khi ai đó hứa với khách hàng về “tự động hóa toàn bộ”.

Người vận hành thực tế nhìn cùng vấn đề bằng con mắt đơn giản hơn. Alejandro Rioja, một practitioner viết trên blog cá nhân, kiểm tra hàng đợi phê duyệt mỗi tháng và gỡ bất kỳ gate nào cho thấy 95% duyệt trong ngày với 0% sửa đổi.

Rioja cũng gỡ gate khi không ai duyệt kịp SLA, thay bằng audit trail: gate mà người duyệt chỉ bấm cho qua không bảo vệ ai cả, nó chỉ làm chậm agent.

Ngược lại, tiêu chí giữ gate của Rioja cũng đơn giản: nếu không muốn một nhân viên mới tự làm việc đó mà không hỏi lại, agent cần gate. Airia, một vendor trong mảng này nên lời khuyên cần đọc với chút dè dặt, diễn đạt cùng ý ở dạng chính sách: quyền phê duyệt phải tương xứng với mức rủi ro của hành động.

Việc của FDE là biến tiêu chí thành code

Điểm Airia nói đúng nhất, và cũng là nơi công việc FDE bắt đầu, là điều kiện kích hoạt gate phải đọc được bằng máy và được thực thi ở tầng execution, không chỉ nằm trong prompt. Thử hình dung một dòng “hãy hỏi người trước khi xóa dữ liệu” trong system prompt: đó không phải gate.

Gate là đoạn code chặn hành động cho tới khi có chữ ký, kèm log ai ký lúc nào.

Bài của Canale giao cho FDE đúng phần việc nối agent, rule engine và evidence service lại với nhau.

Đọc khung đó bằng con mắt của người đi triển khai, việc nối ấy khó tránh hai câu hỏi: thế nào là bằng chứng đủ cho từng gate, và agent có lặp lại cùng một quyết định ổn định hay không; đó cũng chính là hai thứ phần đánh giá của bài đem ra đo.

Case study của Factory trên ZenML mô tả cùng sự dịch chuyển: FDE ở đó không làm professional services, mà chuyển từ trực tiếp thao tác phần mềm sang duy trì và quản lý hệ thống tạo ra phần mềm.

Với một developer Việt Nam muốn vào vai này, kỹ năng đáng luyện không phải prompt. Hãy lấy một workflow nội bộ có bước phê duyệt, đo tỷ lệ duyệt trong ngày và tỷ lệ sửa đổi trong một tháng, rồi viết điều kiện kích hoạt thành policy code thay vì câu lệnh.

Trong CV, một dòng kiểu “đã gỡ ba gate hình thức và giữ hai gate rủi ro cao, kèm số liệu” nói nhiều hơn mọi chứng chỉ về agent.

Cổng cuối cùng sẽ không biến mất. Nó chỉ đổi người gác: từ người bấm duyệt sang người quyết định cổng nào đáng có người bấm.