Các đội ngũ kỹ thuật khi đánh giá các agent lập trình thường bắt đầu bằng một câu hỏi sai lầm. Họ muốn biết agent đó có thể tự chủ đến mức nào. Nó có thể nắm giữ bao nhiêu phần của pipeline? Liệu nó có thể viết đặc tả, chỉnh sửa repository và đẩy lên production mà không cần làm phiền bất kỳ ai không? Các bản demo khiến sự ám ảnh này trở nên dễ hiểu. Bạn thấy một quy trình mượt mà, nơi chỉ một câu lệnh (prompt) duy nhất có thể kích hoạt một chuỗi các chỉnh sửa và triển khai, và bản năng của chúng ta là muốn theo đuổi khả năng tương tự trong chính tổ chức của mình. Nhưng sự hào nhoáng là một nguyên tắc thiết kế tồi tệ. Những câu hỏi hay hơn thì ít thú vị hơn nhiều: ai đã trao cho thứ này quyền hạn, nó thực sự có thể chạm vào những hệ thống nào, và điều gì sẽ xảy ra khi nó chắc chắn mắc sai lầm?

Cái bẫy Tự chủ

Sự tự chủ đầy phấn khích là một cái bẫy. Nó rèn luyện chúng ta ăn mừng những con bot có thể tạo ra các bản đặc tả, sửa đổi repository và triển khai mã nguồn trong khi vẫn bình thản tuyên bố rằng nhiệm vụ đã hoàn thành. Đó không phải là kỹ thuật. Đó là một cú "ngã lòng tin" (trust fall) với quyền truy cập shell. Bản thân công việc trở nên quá dễ dàng để tạo ra. Bất kỳ mô hình nào cũng có thể tạo ra mã nguồn, tài liệu hoặc các kế hoạch kiến trúc chỉ trong vài giây. Nhưng chi phí thực sự trong phát triển phần mềm chưa bao giờ nằm ở tốc độ gõ phím. Nó luôn nằm ở khâu xác thực, đánh giá và quyết định cẩn trọng rằng: vâng, điều này là chính xác và an toàn để triển khai. Sản phẩm được tạo ra thì rẻ. Sự phê duyệt mới đắt đỏ. Những công ty tìm ra cách xử lý việc phê duyệt một cách rõ ràng và nhất quán sẽ là những công ty thực sự triển khai được các hệ thống đáng tin cậy.

Tại sao việc Tự đánh giá lại Thất bại

Các rủi ro xuất hiện theo những mô thức có thể dự đoán được. Một mô hình phác thảo một kế hoạch và sau đó tự đánh giá xem kế hoạch đó có tốt hay không. Một agent chỉnh sửa codebase của bạn và giải thích cho bạn tại sao những thay đổi của nó là an toàn. Một công cụ thực thi một lệnh và xin lỗi thay vì xin phép. Mỗi trường hợp này đều đại diện cho cùng một thất bại cốt lõi. Nếu một agent tạo ra một bản đặc tả, một thứ gì đó nằm ngoài agent đó phải phê duyệt nó trước khi nó trở thành sự thật. Nếu một agent sửa đổi mã nguồn, một quy trình riêng biệt phải kiểm tra phần diff. Để bộ phận tạo ra đóng vai trò là bộ phận xác thực của chính nó không phải là một lối tắt. Đó là một lỗi cấu trúc được ngụy trang dưới danh nghĩa sự tiện lợi.

Prompt không phải là Hệ thống Phân quyền

Bạn không thể bảo mật một agent bằng những cách diễn đạt khéo léo. Bảo một mô hình hãy cẩn thận hoặc hãy hỏi trước khi xóa thứ gì đó không tạo ra một ranh giới. Prompt không phải là hệ thống phân quyền. Trước khi bạn cho phép một agent tiếp cận gần môi trường production, bạn cần một danh mục trung thực về các khả năng của nó. Nó có thể đọc toàn bộ repository không? Nó có thể thực thi các lệnh shell không? Nó có thể mở trình duyệt không? Nó có thể kéo dữ liệu khách hàng vào context window của nó không? Hầu hết các đội ngũ đều không biết câu trả lời đầy đủ. Họ giả định rằng công cụ được giới hạn trong một sandbox trong khi thực tế nó nắm giữ quyền ghi vào các luồng quan trọng (critical paths). Hãy lập bản đồ phạm vi tiếp xúc trước. Sau đó mới xây dựng các bức tường ngăn cách.

Xây dựng Hệ thống Kiểm soát Phân tầng

Một khi bạn hiểu agent có thể làm gì, hãy thiết kế một hệ thống kiểm soát sao cho mức độ rủi ro tương xứng với sự cản trở (friction). Các hành động rủi ro thấp, như cập nhật tài liệu nội bộ hoặc định dạng mã nguồn nhất quán, có thể chạy tự động. Các hành động rủi ro trung bình, chẳng hạn như tái cấu trúc (refactoring) một module hoặc thêm một dependency mới, nên đi qua một điểm kiểm soát (checkpoint) nơi con người hoặc một bộ kiểm thử (test suite) đã được xác minh sẽ xác nhận bước đi đó. Các hành động rủi ro cao, như triển khai lên production, sửa đổi hạ tầng hoặc truy cập dữ liệu nhạy cảm, cần một người phê duyệt riêng biệt, người không tham gia vào quá trình tạo ra nội dung đó. Mọi hành động đơn lẻ đều phải để lại dấu vết kiểm toán (audit trail). Bạn phải có khả năng phát lại chính xác những tệp nào đã được đọc, những công cụ nào đã được gọi và những quyết định nào đã được đưa ra. Phát triển theo hướng agent (agentic development) không phải là một giấy phép để bỏ qua việc đánh giá. Sự cản trở nhàm chán chính là một tính năng. Một cổng phê duyệt đúng mực sẽ hoạt động như một cầu dao (circuit breaker) khi mọi thứ bắt đầu đi chệch hướng.

Điều chỉnh Ranh giới tương ứng với Rủi ro

Hãy hiệu chỉnh các ranh giới của bạn theo mối nguy hiểm thực tế. Biến mọi thay đổi nhỏ về định dạng Markdown thành một nghi thức tuân thủ sẽ khiến đội ngũ của bạn đình trệ. Nhưng coi các hành động quan trọng là vô hại chỉ vì agent có vẻ tự tin thì cũng ngu ngốc không kém. Mục tiêu là sự kiểm soát tương xứng, chứ không phải là sự hạn chế mang tính trình diễn.

Giữ các Artifact nhỏ và có thể quan sát được

Các hệ thống agent hữu ích nhất không cố gắng gây ấn tượng với bạn bằng những lượt chạy tự trị khổng lồ. Chúng tạo ra các sản phẩm nhỏ, có thể kiểm tra được. Một kế hoạch chặt chẽ. Một bản diff tập trung. Một bản log dễ đọc. Những lần thực thi tự trị khổng lồ là cơn ác mộng khi cần debug. Khi có lỗi xảy ra sau một phiên làm việc của agent với năm mươi tệp tin, bạn phải gỡ rối ý định, quá trình thực thi và các tác dụng phụ cùng một lúc. Hãy giữ phạm vi ảnh hưởng nhỏ. Hãy yêu cầu biết rõ agent đã đọc những tệp nào và đã gọi những công cụ nào. Các hệ thống có thể quan sát được là các hệ thống có thể bảo trì được. Sự tự trị kiểu "hộp đen" chỉ là nợ kỹ thuật được gắn mác marketing tốt hơn mà thôi.

Sáu câu hỏi trước khi bạn cấp quyền truy cập

Trước khi giao bất kỳ trách nhiệm thực sự nào cho một agent, hãy kiểm tra áp lực thiết lập của bạn bằng sáu câu hỏi hóc búa.

  • Hệ thống thực sự có những khả năng gì?
  • Những hành động nào bị từ chối theo mặc định, được chặn ở cấp độ hạ tầng thay vì chỉ được khuyến cáo bằng một câu lịch sự trong system prompt?
  • Những hành động nào yêu cầu sự phê duyệt rõ ràng?
  • Những sản phẩm nào được đóng băng trước khi agent sử dụng chúng, để nó không thể âm thầm thao túng đầu vào của chính mình?
  • Trình xác thực (validator) nào, hoàn toàn tách biệt với trình tạo (generator), sẽ đánh giá kết quả cuối cùng?
  • Nhật ký (log) nào chứng minh một cách rõ ràng, không gây mơ hồ, về những gì đã thực sự xảy ra?

Đây là những nguyên tắc vệ sinh kỹ thuật cơ bản. Hãy tách biệt trình tạo khỏi trình xác thực. Giữ quyền kiểm soát của con người tại ranh giới.

Bài kiểm tra thực sự

Có