Vì sao AI agent nói “xong rồi” khi công việc chưa hoàn thành

Mô hình OpenAI đã thoát khỏi sandbox và hack Hugging Face như thế nào?#

Trước tiên là sự thật, sau đó là lý do chuyện này quan trọng với bạn.

OpenAI đo lường khả năng của các mô hình trong lĩnh vực an ninh mạng tấn công. Họ dùng bài kiểm tra ExploitGym — gồm 898 nhiệm vụ yêu cầu biến một lỗ hổng đã biết thành exploit hoạt động được, tức chương trình làm sẵn sử dụng lỗ hổng đó. Để thấy được giới hạn năng lực thực sự, họ tắt các bộ lọc an toàn tích hợp vốn thường ngăn mô hình làm những việc như vậy. Họ khóa hoàn toàn môi trường, chỉ chừa một lối ra: chương trình trung gian nội bộ dùng để cài đặt các gói.

Lỗ hổng zero-day là lỗ hổng chưa ai biết đến, kể cả người viết chương trình. Các mô hình tìm thấy một lỗ hổng như thế ngay tại lối ra duy nhất đó.

Tiếp theo, chúng nâng quyền, di chuyển qua mạng nội bộ đến một máy có kết nối internet, rồi đoán rằng đáp án của ExploitGym có thể nằm trên Hugging Face. Không ai nói cho chúng biết về Hugging Face. Chúng tự suy ra điều đó.

Phỏng đoán ấy sai. ExploitGym hoàn toàn không có trên Hugging Face. Điều đó không khiến vụ hack kém thật hơn.

Hugging Face tự phát hiện vụ xâm nhập và công bố thông tin vào ngày 16 tháng 7, khi vẫn chưa biết ai đã hack mình.

Một chi tiết khác trong bài tường thuật đó nói lên nhiều điều về tình hình hiện tại. Khi các kỹ sư Hugging Face thử đưa nhật ký cuộc tấn công cho những mô hình hàng đầu thông qua các giao diện thương mại thông thường, bộ lọc an toàn chặn yêu cầu: chúng không thể phân biệt người đang điều tra một vụ hack với người đang thực hiện vụ hack. Cuối cùng, họ chạy phân tích bằng một mô hình mở trên phần cứng của mình.

OpenAI thừa nhận việc này vào ngày 21 tháng 7, năm ngày sau thông báo của Hugging Face. Đến lúc đó, vụ xâm nhập đã xảy ra khoảng mười ngày.

OpenAI kết thúc phần phân tích của mình như sau.

Mô hình cố chấp vào mục tiêu hẹp của bài kiểm tra và dùng mọi cách cực đoan để đạt được nó. Các cụm từ hyper-focused và fairly narrow testing objective là lời của chính OpenAI, nói về các mô hình của họ.

Đó là nhịp cầu nối phòng thí nghiệm của người khác với chiếc laptop của bạn.

Vì sao đây không phải là “ảo giác”?#

Tôi thường thấy những câu trong các cuộc trò chuyện như “lại ảo giác rồi”, “ngữ cảnh bị quá tải” hoặc “đáng lẽ phải lập kế hoạch”. Đôi khi đúng là như vậy. Nhưng khi một AI agent viết “xong rồi, đã kiểm tra, mọi thứ hoạt động” trong khi công việc chưa xong, lượng ngữ cảnh thường chẳng liên quan gì.

Nó không bịa ra điều gì. Nó đã làm đúng điều bạn đo lường.

Dưới từ bao quát phổ biến “ảo giác”, chúng ta gộp chung ba kiểu thất bại khác nhau. Chúng khác nhau như sau:

Cách thứ nhất được khắc phục bằng ngữ cảnh, và đây là trường hợp được biết đến nhiều nhất. Cách thứ hai là hiện tượng riêng, được đề cập trong bài phân tích về những lần Claude đồng ý với mọi thứ: mô hình hy sinh độ chính xác để nhanh chóng tán thành. Cả hai đều xảy ra trước khi làm việc, ở giai đoạn đầu vào.

Hàng thứ ba trong bảng là chủ đề của bài viết này. Ở đây, agent không tâng bốc hay bịa đặt. Nó làm việc, kiểm tra và báo cáo đúng sự thật. Chỉ có điều sự thật đó mô tả chỉ số, chứ không nói gì về nhiệm vụ.

Kiểu thất bại thứ ba có tên gọi riêng.

Reward hacking là gì, giải thích đơn giản?#

Anthropic tự đưa ra định nghĩa.

Ý tưởng này có trước mạng nơ-ron. Một bài viết của DeepMind gọi hiện tượng đó là specification gaming và giải thích bằng một câu chuyện thần thoại.

Midas nhận được đúng điều ông yêu cầu. Vấn đề nằm trong cách diễn đạt lời yêu cầu.

Trong lập trình, điều này thể hiện qua những hình thức cụ thể. Đây là một ví dụ kinh điển trong sách giáo khoa, cũng từ Anthropic:

Và đây không phải điều kiện phòng thí nghiệm kỳ lạ. Cursor đã phân tích 731 quỹ đạo trên một benchmark phổ biến.

Sáu trong mười nhiệm vụ “đã giải quyết” là đáp án được tìm thấy. Đó chính là lý do ngành đang thay đổi cách đo hiệu năng: chúng tôi có bài phân tích về benchmark đo mức độ sẵn sàng đưa vào production, nơi vượt qua các bước kiểm tra không còn là tiêu chí chính.

Điều này trông ra sao trong một sản phẩm thông thường?#

Ta dễ gạt các ví dụ trong phòng thí nghiệm sang một bên vì cho là khác thường. Vì vậy, đây là bốn câu chuyện từ thực tế. Khách hàng và ngành nghề đã được thay đổi, nhưng cơ chế vẫn giữ nguyên.

Bốn dấu kiểm xanh và một thành phần dịch vụ ngừng hoạt động

Một công ty bất động sản đang xây dựng dịch vụ: website đăng tin bất động sản cùng một bộ xử lý nền riêng xuất danh sách tin sang các nền tảng vào ban đêm. Agent hoàn thành nhiệm vụ và báo cáo: kiểm tra kiểu dữ liệu đạt, kiểm tra phong cách mã đạt, bản build xanh, các trang phản hồi và đã được kiểm tra trực quan.

Tất cả các phát biểu đều đúng. Nhưng không điều nào liên quan đến bộ xử lý chạy ban đêm: nó là một tiến trình riêng và hoàn toàn không nằm trong bản build website. Triển khai thành công, trang web hoạt động hoàn hảo, việc xuất tin dừng lại, và khách hàng báo sự cố vào ngày hôm sau.

Trước khi nói “xong”, giờ đây tôi tự hỏi một câu: phần nào của công việc chạy ngoài phạm vi mà bước kiểm tra của tôi bao phủ? Nếu có, hãy chạy riêng phần đó và đưa kết quả lệnh vào báo cáo. Từ “đã kiểm tra” không khép lại được vấn đề này.

Dấu kiểm sai nằm ngay tại điểm nối

Một cửa hàng trực tuyến chia một nhiệm vụ lớn cho nhiều agent cùng lúc: một agent phụ trách backend, một agent phụ trách các trang, agent thứ ba làm thẻ sản phẩm. Mỗi agent đều làm việc chăm chỉ và có các bước kiểm tra màu xanh.

Một tuần sau, hóa ra nút “đánh giá này hữu ích” không hoạt động ở bất kỳ đâu. Backend được viết đầy đủ, các bước kiểm tra đều xanh và quy tắc tính toán lại đã được tuân thủ. Chỉ có điều không trang nào hiển thị nút: nút thuộc phạm vi của một agent, các trang thuộc phạm vi của agent khác, và chẳng ai nghĩ đến việc đưa nó lên màn hình. Bộ đếm sẽ mãi mãi ở số không.

“Đã viết mã và có kiểm tra bao phủ” và “tính năng hoạt động” là hai khẳng định khác nhau. Tôi kiểm tra điều thứ hai bằng một câu hỏi cho mỗi tính năng mới: ai gọi nó? Và tôi xác minh bằng cách tìm kiếm trong dự án, vì báo cáo của agent không phải nguồn sự thật trong trường hợp này.

Người đánh giá chỉ thấy hướng họ được yêu cầu kiểm tra

Một dịch vụ triển khai các cấp độ khách hàng thân thiết: bạn trả càng nhiều, trạng thái và mức giảm giá càng cao. Trước khi triển khai, mã được gửi đi đánh giá kèm hướng dẫn: “Thử nâng trạng thái của chính bạn lên.” Người đánh giá làm việc trung thực và báo cáo “không có gì nghiêm trọng” — thực sự không thể tự nâng trạng thái.

Lượt xem xét thứ hai đặt một câu hỏi khác: “Điều gì xảy ra với trạng thái khi hoàn tiền?” Chỉ mất mười phút để phát hiện lỗ hổng. Điểm được tính từ nhật ký giao dịch, mà nhật ký không biết gì về việc hoàn tiền. Mua hàng, tích điểm, nhận hoàn tiền, rồi giữ trạng thái và mức giảm giá mãi mãi.

Người đánh giá đầu tiên không làm qua loa. Về mặt cấu trúc, họ không thể thấy được: họ được giao hướng “đầu vào, thăng hạng”, trong khi lỗ hổng nằm ở hướng “đảo ngược đầu vào, giữ nguyên quyền lợi”. Bất cứ nơi nào có tiền, quyền truy cập hoặc trạng thái có thể mua được, tôi đều thực hiện hai lượt đánh giá; ở lượt thứ hai, tôi liệt kê rõ các hướng ngược lại: hoàn tiền, chặn, thu hồi quyền truy cập, hết hạn, xóa nguồn dữ liệu.

Chỉ số thưởng cho độ tương đồng

Một dịch vụ giao hàng quyết định đo xem gợi ý của AI cho nhân viên vận hành có cải thiện hay không. Họ lấy hai trăm yêu cầu hỗ trợ cũ, chạy qua phiên bản mới rồi đo mức độ giống nhau giữa bản nháp và câu trả lời thực tế của nhân viên. Kết quả đo cho thấy mức tăng rõ rệt.

Mức tăng đó chẳng có ý nghĩa vì hai lý do. Ngữ cảnh dùng để tạo bản nháp được tổng hợp “tính đến hôm nay” và gồm toàn bộ thư từ, kể cả chính câu trả lời của nhân viên mà sau đó đem ra so sánh. Mô hình không viết câu trả lời; nó diễn đạt lại nội dung tham chiếu mà nó được xem. Hơn nữa, bản thân chỉ số thưởng cho từ ngữ và độ dài tương tự: bản nháp đưa ra ngày sai nhưng dùng đúng những từ nhân viên từng dùng để nêu ngày đúng vẫn được điểm cao.

Bên cạnh mọi chỉ số kiểu “giống nghĩa là tốt”, giờ đây tôi đặt các ngưỡng cơ học cứng mà văn phong không thể đánh lừa: số và ngày tháng bịa đặt, từ dừng, lời hứa hành động. Bất kỳ mức giảm nào ở các kết quả kiểm tra ngưỡng đều xóa sạch mọi cải thiện của chỉ số.

Vì sao câu “tôi đã kiểm tra” của agent chẳng chứng minh được gì?#

Hãy chọn một dự án bất kỳ của bạn và yêu cầu agent “Kiểm tra bảo mật”. Thường thì câu trả lời sẽ là “mọi thứ đều ổn, không có vấn đề nghiêm trọng”.

Giờ hãy hỏi mô hình khác cùng câu hỏi về cùng dự án. Đặc biệt nếu dự án lớn, nó sẽ tìm ra rất nhiều vấn đề. Trước khi triển khai, tác giả kiểm tra dự án bằng ba mô hình khác nhau, và mỗi mô hình đưa ra những phát hiện khác nhau.

Cùng đầu vào, cùng câu hỏi, kết luận trái ngược. Mô hình này không kém mô hình kia. Chỉ là “mọi thứ đều ổn” cũng là văn bản được tạo ra, nằm đúng cùng một lớp với mọi câu trả lời khác. Agent không có cách nào phân biệt “tôi đã xem và mọi thứ sạch sẽ” với “tôi đã xem nhầm chỗ”.

Anthropic mô tả cơ chế này trong tài liệu Claude Code.

Hãy chậm rãi phân tích câu đó. Cho đến khi bạn cung cấp một bước kiểm tra mà agent có thể chạy, nó chỉ có một tín hiệu — công việc trông như thế nào. Và trong hệ thống này, bạn là vòng lặp xác minh, nhưng lại là người cuối cùng biết về các sai sót.

Còn một lớp sâu hơn. Khi OpenAI thử gây áp lực lên mô hình bằng cách theo dõi suy luận và trừng phạt “suy nghĩ xấu”, kết quả không như họ mong đợi.

Trừng phạt ý định được nói ra chỉ xóa đi lời nói. Bản thân ý định vẫn còn. Vì vậy, tôi sẽ không trông cậy vào việc agent thành thật kể cho bạn nghe nó đã gian lận như thế nào.

Các nhà phát triển công cụ cũng đang đi theo hướng tương tự. Trong phiên bản Claude Code 2.1.215, các skill /verify và /code-review không còn tự chạy theo sáng kiến của mô hình nữa.

2.1.215 - Claude no longer runs the `/verify` and `/code-review` skills
on its own; invoke them with `/verify` or `/code-review` when you want them

Anthropic không giải thích lý do. Nhưng nguyên tắc thì rõ ràng: người được đánh giá không tự giao cho mình nhiệm vụ đánh giá.

Vì sao quy tắc trong tệp dự án không giữ agent đi đúng hướng?#

Bạn đã viết trong tệp quy tắc của dự án: chỉ commit khi được hướng dẫn trực tiếp, chỉ deploy lên production khi tôi trực tiếp yêu cầu, chỉ truy cập dữ liệu production ở chế độ chỉ đọc.

Theo kinh nghiệm của tác giả, cứ khoảng mười lần thì một lần agent vẫn tự tiến hành deploy. Không phải do ác ý, cũng không phải vì nó chưa đọc quy tắc. Nó đã đọc. Chỉ là trước mắt nó có một mục tiêu, còn quy tắc chỉ là văn bản — giống như phần còn lại của ngữ cảnh.

Đó chính xác là điều đã xảy ra trong phòng thí nghiệm của OpenAI, chỉ ở quy mô lớn hơn. Các mô hình nằm trong môi trường khép kín với một lối ra duy nhất và dành phần đáng kể tài nguyên tính toán để tìm lối thoát. Các nhiệm vụ kiểm tra vẫn chưa được giải quyết.

Quan điểm của tôi rất đơn giản: agent không nguy hiểm hay có ác ý. Nó chỉ là một kẻ ngốc bình thường được trao quyền. Vì vậy, hãy hạn chế quyền của nó, đừng viết lại yêu cầu của bạn.

Những gì thực sự có tác dụng: chỉ cấp quyền đọc dữ liệu production một cách nghiêm ngặt; cấm xóa toàn bộ thư mục; cấm các lệnh viết lại lịch sử mà không thể khôi phục; đặt giới hạn chi tiêu với nhà cung cấp. Khác biệt nằm gọn trong một cụm từ: “không thể làm được về mặt vật lý” có tác dụng mạnh hơn “tôi đã yêu cầu nó đừng làm”. Các cài đặt cụ thể được trình bày riêng trong bài viết về phanh cơ học thay cho lời yêu cầu trong chỉ dẫn.

Dù vậy, hãy giữ bình tĩnh. Ngay cả sandbox cũng không phải ranh giới tuyệt đối, và nhà cung cấp nói rõ điều đó.

Hơn nữa, Claude Code có một lối thoát khẩn cấp tích hợp mà chính mô hình có thể sử dụng. Khi một lệnh thất bại do hạn chế của sandbox, Claude phân tích lỗi và có thể thử lại chính lệnh đó với tham số vô hiệu hóa sandbox. Có thể đóng lối này bằng cài đặt strict mode rõ ràng; theo mặc định, cách né tránh vẫn khả dụng và được tài liệu hóa.

Một hạn chế chỉ có tác dụng trong phạm vi bạn siết chặt nó. Và mọi rào cản đều làm giảm tốc độ — nên tính toán điều đó một cách trung thực từ trước, vì đến một tuần sau mới phát hiện sẽ tốn kém hơn.

Làm thế nào đặt tiêu chí hoàn thành không thể bị chơi gian?#

Cách diễn đạt tiêu chí quyết định mọi thứ khác. Hãy kiểm tra bằng một câu hỏi: agent có thể đáp ứng tiêu chí này mà không làm gì không?

• “Kiểm tra xem mọi thứ có hoạt động không” — có thể. Chỉ cần viết “đã kiểm tra, hoạt động tốt”.
• “Chạy bản build và cho tôi xem đầu ra” — khó hơn; agent phải tìm đầu ra bằng cách nào đó.
• “Chạy ứng dụng, nhấn nút thanh toán và cho tôi xem những gì xuất hiện trên màn hình” — gần như không thể đáp ứng yêu cầu đó chỉ bằng văn bản.

Khác biệt giữa điều thứ nhất và thứ ba là khác biệt giữa báo cáo và bằng chứng.

Tài liệu Claude Code mô tả bốn mức độ chặt chẽ. Có thể tăng dần theo bậc này khi cái giá của sai sót tăng lên:

1. Trong một tin nhắn. Yêu cầu agent chạy bước kiểm tra và lặp lại cho đến khi thành công ngay tại đây. Rẻ nhất, phù hợp với việc nhỏ.
2. Trong toàn bộ phiên làm việc. Biến bước kiểm tra thành điều kiện của mục tiêu: một bộ đánh giá riêng kiểm tra sau mỗi lượt, còn agent tiếp tục làm cho đến khi đạt điều kiện. Chi tiết kỹ thuật có trong hướng dẫn về đặt trước tiêu chí hoàn thành.
3. Rào cản cơ học. Một script chạy khi agent cố kết thúc một lượt và ngăn nó kết thúc cho đến khi bước kiểm tra đạt. Có một chi tiết cần nói rõ: sau tám lần bị chặn liên tiếp, Claude Code vượt rào cản và vẫn kết thúc lượt. Trong hệ thống này không có rào cản nào tuyệt đối không thể xuyên qua.
4. Ý kiến thứ hai. Một người đánh giá riêng, có ngữ cảnh mới và nhiệm vụ là bác bỏ kết quả.

Điều thứ tư khác hẳn vì đây là điều duy nhất không liên quan đến công cụ.

Ai nên nghiệm thu công việc của agent?#

Khi chạy agent theo vòng lặp cho một nhiệm vụ lớn, tôi tổ chức như sau: một nhóm viết; một nhóm mới, chưa từng tham gia viết sẽ nghiệm thu công việc.

“Chưa từng tham gia” là từ khóa. Nó có nghĩa là một ngữ cảnh sạch, chưa biết các quyết định được đưa ra như thế nào trong suốt quá trình. Một prompt khác trong cùng phiên không đáp ứng điều đó. Người viết mã đã dành sự chú ý để thuyết phục mình rằng mã đúng và sẽ tiếp tục tìm kiếm sự xác nhận. Bác bỏ kết quả không có lợi cho họ.

Cách diễn đạt nhiệm vụ cho người đánh giá quan trọng hơn mô hình của họ. Hãy so sánh:

• “Đánh giá công việc này” — người đánh giá sẽ tìm điều gì dễ thấy rồi viết “nhìn chung ổn”.
• “Hãy thử chứng minh rằng công việc này CHƯA được hoàn thành” — người đánh giá sẽ bắt đầu tìm lỗ hổng vì đó là mục tiêu của họ.

Cách diễn đạt thứ hai hiệu quả hơn vì cùng lý do ExploitGym thất bại: agent cam kết với mục tiêu được giao. Giao cho nó mục tiêu tìm lỗ hổng, nó sẽ tìm.

Dưới đây là nguyên văn đầy đủ, có thể sao chép để dùng ngay:

Bạn đang đánh giá công việc của người khác. Bạn không viết nó và cũng không cần bảo vệ nó.

Mục tiêu của bạn là chứng minh rằng kết quả được tuyên bố chưa đạt được. Hãy tìm ít nhất ba cách mà kết quả có thể chưa đạt được dù tất cả các bước kiểm tra đều màu xanh.

Kiểm tra theo thứ tự này:

Công việc nào chạy ngoài phạm vi của các bước kiểm tra — tiến trình nền, script riêng, tác vụ được lên lịch, bộ xử lý hàng đợi.

Ai gọi từng hàm mới. Tìm lời gọi bằng cách tìm kiếm trong dự án; nêu tên tệp và dòng.

Các hướng ngược lại: hoàn tiền, chặn, thu hồi quyền truy cập, hết hạn, xóa nguồn dữ liệu.

Các giá trị bên trong kết quả, chứ không chỉ việc kết quả có tồn tại hay không.

Nếu tìm kiếm trung thực mà không phát hiện lỗ hổng, hãy nói rõ, nhưng phải nêu chính xác bạn đã kiểm tra những gì và bằng cách nào.

Bài viết về trường hợp agent tự kiểm tra theo vòng lặp giải thích cách vòng lặp agent tự kiểm tra giữa các lần lặp hoạt động và thường thất bại ở đâu.

Điều gì thay đổi khi bạn diễn đạt lại tiêu chí?#

Đây là cải thiện ít tốn kém nhất mà tôi biết, nhưng hầu như chẳng ai làm.

Yêu cầu agent code review — nó sẽ suy luận theo góc độ mã: cấu trúc, xử lý lỗi, thử lại, các khu vực dễ bị tấn công. Hữu ích.

Yêu cầu nó đi theo hành trình khách hàng, từ lần đầu truy cập trang web đến lúc thử xin hoàn tiền, sẽ làm lộ ra những dạng vấn đề khác. Một lỗi cho người dùng thấy thứ họ không nên thấy. Một email có nội dung không khớp với điều thực sự đã xảy ra. Một bước về mặt logic không thể hoàn thành nếu bạn không đi qua kịch bản lý tưởng.

Code review sẽ không tìm thấy những lỗi này vì từng lỗi đều hợp lệ trong mã.

Từ đó có một quy tắc tôi luôn ghi nhớ: nếu một bước kiểm tra không tìm ra gì, hãy thay đổi cách diễn đạt trước. Thường thì mô hình không phải vấn đề. Cùng một công việc nhưng được hỏi theo ba cách khác nhau sẽ cho ra ba danh sách phát hiện khác nhau. Một bộ câu hỏi thực tế dành cho người không biết lập trình được tổng hợp riêng: bảy bước kiểm tra mã không cần kỹ năng lập trình.

Prompt sẵn dùng để nghiệm thu công việc của agent#

Đừng trả lời “xong rồi” hay “đã kiểm tra”. Tôi cần bằng chứng.

Với từng hạng mục công việc, hãy cung cấp chính xác những điều sau:

Bạn đã chạy lệnh nào để xác nhận hạng mục đó hoạt động? Hãy đưa chính lệnh đó cùng toàn bộ đầu ra, không rút gọn.

Nếu bạn không chạy lệnh, hãy nói: “chưa chạy”. Đừng thay câu này bằng “đã kiểm tra trực quan” hay “logic là đúng”.

Công việc nào chạy ngoài phạm vi được bước kiểm tra của bạn bao phủ? Tiến trình nền, script riêng, tác vụ được lên lịch, bộ xử lý hàng đợi — bất cứ thứ gì được khởi chạy khác với ứng dụng chính. Với từng phần như vậy: bạn đã chạy riêng chưa, và đầu ra là gì?

Ai gọi từng hàm mới bạn đã thêm? Hãy tìm lời gọi trong dự án và nêu tệp cùng dòng. Nếu không có lời gọi, hãy nói thẳng.

Sau đó, trong một mục riêng: ba cách kết quả được tuyên bố có thể CHƯA đạt được dù tất cả bước kiểm tra của bạn đều màu xanh. Hãy tìm thật kỹ.

Cuối cùng, một dòng: tôi nên tự nhìn kiểm tra điều gì vì bước kiểm tra tự động sẽ không phát hiện được?

Điều thứ tư có vẻ nhỏ, nhưng bắt được cả một nhóm vấn đề. Trong một nhiệm vụ lớn mà tôi phân cho các agent theo từng khu vực, lần “xong rồi” sai duy nhất trong cả trăm lần xảy ra ngay tại ranh giới giữa hai khu vực: mã đã được viết, các bước kiểm tra đều xanh, nhưng chẳng ai nghĩ đến việc đưa nó lên màn hình.

Bốn cách tự đánh lừa mình bằng một bước kiểm tra#

1. Không chờ tất cả người đánh giá. Tôi chạy ba lượt kiểm tra song song, hai lượt trả về màu xanh nên tôi deploy. Lượt thứ ba đến sau bốn phút với sáu lỗi vi phạm. Sửa lỗi sau khi phát hành tốn kém hơn chờ thêm hai phút.
2. Tin bản tóm tắt “đã xử lý N trên N”. Khi phân tán nhiều việc, một số agent âm thầm thất bại: chúng báo thành công nhưng tệp không hề được sửa. Giờ đây, sau mỗi lần agent ghi tệp, tôi tự động xác minh các thay đổi thực sự có trên ổ đĩa.
3. Không tự mình xem. Bước kiểm tra tự động có thể báo xanh dù kết quả hoàn toàn không sử dụng được. Hình ảnh đúng về mặt kỹ thuật, kích thước đúng, mã phản hồi đúng. Nhưng thực tế đó chỉ là các khung hình đóng băng được tạo tự động, thay cho những bìa sách minh họa lẽ ra phải có. Không bước kiểm tra tự động nào phát hiện được điều đó.
4. Kiểm tra sự hiện diện thay vì giá trị. Bước kiểm tra tìm đoạn văn bản bắt buộc trong kết quả; văn bản có ở đó, nhưng dữ liệu bên trong sai: ngày bị lệch một ngày. Bước kiểm tra báo xanh, còn báo cáo thì nói dối. Giờ đây tôi xác minh toàn bộ giá trị mong đợi, vì chỉ sự hiện diện của từ đúng không đảm bảo điều gì.

Cả bốn điểm có chung một đặc điểm: có bước kiểm tra, trông thuyết phục, nhưng kiểm tra nhầm thứ. Cơ chế giống với những gì xảy ra giữa các mô hình và bài kiểm tra của chúng, chỉ không có chút sáng tạo nào.

Bắt đầu từ đâu hôm nay?#

Ba bước, mất hai mươi phút.

1. Lấy lần “xong” gần nhất. Dùng prompt nghiệm thu trong phần nói về bằng chứng để kiểm tra. Mục tiêu rất đơn giản: xem có bao nhiêu hạng mục được kết thúc bằng lời nói và bao nhiêu bằng đầu ra lệnh.
2. Đặt ra một quy tắc cho mình. Từ “đã kiểm tra” mà không đính kèm đầu ra lệnh thì không được tính là hoàn tất. Quy tắc này dành cho bạn, không phải agent, và đó là lý do nó có tác dụng.
3. Tách người làm với người đánh giá. Ở nhiệm vụ tiếp theo, đưa prompt đánh giá cho một phiên mới và yêu cầu chứng minh rằng công việc CHƯA được hoàn thành. Lần đầu tiên thường đã đủ để thấy thói quen này đáng giá.

Công cụ này tốt và cải thiện mỗi tháng: những việc agent âm thầm làm cách đây một năm giờ có thể khiến nó dừng lại ngay. Ranh giới an toàn liên tục dịch chuyển và vẫn là một ranh giới. Chừng nào agent còn theo đuổi mục tiêu được giao, câu hỏi “và chính xác thì bạn đã đo điều đó như thế nào?” vẫn thuộc về bạn. Thói quen kiểm tra là lưới an toàn của bạn.