Khi quy tắc nghiệm thu tác tử đã sai

Hướng dẫn Agents CLI ngày 28 tháng 10 năm 2026 của Google khuyên quản lý riêng phiên bản đầu vào và kỳ vọng đánh giá. Khuyến nghị này thuộc về Google, không phải sáng kiến của bài viết. Bản gốc

Câu hỏi của chúng tôi bắt đầu sau một phát hiện khó chịu hơn: nếu chính quy tắc nghiệm thu sai thì sao? Nhóm có thể từng thưởng cho tác tử vì hành động mà nghiệp vụ không nên cho phép. Sửa quy tắc có thể làm điểm hôm qua giảm mà không thay đổi hành vi hôm qua. Nó cũng có thể bộc lộ hệ quả mà riêng điểm mới không giải quyết được.

Open Market Notes dùng ví dụ giả định về quy trình bảo trì thiết bị để xem xét vấn đề. Đây là đề xuất vận hành độc lập, không phải thử nghiệm đã đo hay mô tả một hệ thống Google đang triển khai.

Một lần sửa sai, hai nhóm người cần câu trả lời

Hãy hình dung trợ lý chuẩn bị phiếu bảo trì thiết bị. Ban đầu, bài đánh giá coi phiếu đầy đủ là thành công. Sau đó, nghiệp vụ nhận ra công việc trong một khu vực hạn chế phải được phê duyệt trước. Tác tử nhanh chóng hoàn thành phiếu như vậy có thể đạt bài kiểm tra cũ nhưng vượt ranh giới vận hành mà doanh nghiệp muốn duy trì.

Nhóm thứ nhất là kỹ sư chọn phiên bản tiếp theo. Nhóm thứ hai là người phụ trách nghiệp vụ chịu trách nhiệm về công việc đã xử lý. Bên thứ nhất cần quy tắc nghiệm thu cho tương lai; bên thứ hai cần biết đầu ra trước đây có vượt ranh giới không. Coi cả hai là bài toán sửa lời nhắc có thể khiến câu hỏi thứ hai bị bỏ ngỏ.

Phát hiện này chưa chứng minh sự cố thực tế đã xảy ra. Phiếu chuẩn bị có thể chưa được gửi, đã bị người kiểm tra từ chối, hoặc chỉ là thử nghiệm mô phỏng không có tác động bên ngoài. Việc đầu tiên là xác định bằng chứng hỗ trợ trạng thái nào, không biến lỗi đánh giá thành cáo buộc đã gây thiệt hại vận hành.

Giữ kết quả lịch sử và bổ sung phán đoán mới

Tài liệu CLI cho phép chấm lại dấu vết đã lưu mà không chạy lại tác tử. Tài liệu đánh giá

Hồ sơ sửa sai chúng tôi đề xuất giữ kết quả ban đầu cùng ý nghĩa khi đó, bổ sung đánh giá mới và giải thích lý do thay đổi. Nó không ghi đè quá khứ như thể quy tắc đúng luôn tồn tại. Người đọc phải thấy được rằng kết quả “đạt” cũ có thể phản ánh chính xác bài kiểm tra cũ, nhưng chưa đủ chứng minh hành vi chấp nhận được trong nghiệp vụ.

Phân biệt này quan trọng với trách nhiệm. Nhà phát triển không nhất thiết phớt lờ yêu cầu thành văn; yêu cầu có thể chưa tồn tại hoặc còn mơ hồ. Ngược lại, thiếu một phép kiểm tra cũng không cho phép bỏ qua hạn chế nghiệp vụ đã biết. Hồ sơ cần tách yêu cầu sản phẩm, điều bài kiểm tra thực sự xét và hành động của người vận hành. Không thể suy ra lỗi thuộc về ai chỉ từ việc nhãn đánh giá thay đổi.

Hỏi điều phản thực tế mà hồ sơ có thể trả lời

Một bước nối tiếp hữu ích có hai phần. Xem lại tương tác đã lưu hỏi: quy tắc mới có chấp nhận hành vi được quan sát này không? Chạy lại ca với tác tử đã sửa hỏi câu khác: dưới điều kiện được tái dựng, cách sửa dự kiến có tạo ra bước tiếp theo đạt yêu cầu không?

Hai câu hỏi không thể thay thế nhau. Tác tử mới xin phê duyệt không chứng minh tác tử cũ đã hỏi. Nó cũng không chứng minh phê duyệt chắc chắn sẽ được cấp. Nếu dấu vết lịch sử chỉ có bản tóm tắt phiếu cuối cùng, thiếu bản ghi quyền có thể là chưa kiểm tra, hoặc chỉ là nhật ký bỏ sót. Hãy giữ sự khác biệt đó ở trạng thái chưa xác định cho tới khi hồ sơ khác mà nhóm được phép sử dụng giải đáp được.

Vì thế, mục tiêu sửa trong ví dụ phải có giới hạn: dừng ở ranh giới phê duyệt và chỉ ra quyền còn thiếu. Không chấm dựa trên kết quả phê duyệt tưởng tượng. Ca thử có thể kiểm tra bước tiếp theo mà hệ thống kiểm soát được mà không bịa ra quyết định nghiệp vụ về sau.

Tái dựng cũng cần ranh giới rõ ràng. Hồ sơ thiết bị hiện tại có thể chứa thay đổi sau yêu cầu gốc. Dùng nó để chạy lại hữu ích khi kiểm tra quy trình hôm nay, nhưng không tái hiện thông tin tác tử cũ từng biết. Nếu không có đầu vào lịch sử, hãy nói rõ và giới hạn kết luận hồi cứu, thay vì lấp chỗ trống bằng câu chuyện nghe hợp lý.

Sửa kỹ thuật chưa khép lại vụ việc nghiệp vụ

Lời nhắc tốt hơn có thể thay đổi hành vi tương lai. Nó không rút lại phiếu đã gửi, thông báo người giám sát liên quan hay xác định công việc đã bắt đầu chưa. Các hành động đó thuộc quy trình nghiệp vụ được ủy quyền, không phải điều tập lệnh đánh giá được tự quyết.

Với nhóm bảo trì giả định, hồ sơ sửa sai nên nối với trạng thái xử lý riêng: chưa có hành động bên ngoài; người có thẩm quyền xác nhận phiếu phù hợp; phiếu đã được rút; hoặc trạng thái chưa giải quyết. Đây là phân loại đề xuất, không phải sự kiện đã quan sát. Mục đích là tránh nhầm “đã sửa trong bản tiếp theo” với “đã giải quyết hệ quả trước đây”.

Rủi ro ngược lại cũng có thật: rà soát quá khứ quá rộng có thể tiêu tốn nguồn lực cần cho sửa chữa khẩn cấp. Cách cân đối là ưu tiên hạn chế vừa phát hiện, khoảng thời gian liên quan và hành động bên ngoài quan sát được. Không nên mặc định mọi lỗi cũ cần điều tra như nhau. Người chịu trách nhiệm cụ thể phải giải thích phạm vi đó và phần bất định còn lại.

Xác định hoàn tất là gì trước khi đuổi theo điểm tốt hơn

Trong quy trình đề xuất này, hoàn tất không chỉ là đạt bài kiểm tra đã sửa. Chủ nghiệp vụ chấp nhận quy tắc đúng; kỹ sư chứng minh bước tiếp theo được phép; người có thẩm quyền giải quyết hoặc nhận rõ trách nhiệm tiếp tục xử lý các ca lịch sử. Mỗi xác nhận trả lời một câu hỏi khác nhau.

Cách tiếp cận có giới hạn. Nó cần kiểm soát truy cập hồ sơ nghiệp vụ, chính sách lưu trữ hợp lý và thời gian xem xét bằng chứng mơ hồ. Chạy lại chính xác có thể bất khả thi sau khi công cụ hoặc mô hình đổi. Đó là lý do giới hạn kết luận, không phải lý do trình bày tái dựng gần đúng như điều chắc chắn.

Lợi ích thực tế là ranh giới rõ hơn giữa cải thiện hệ thống và sửa một quyết định trước đây về nó. Quy tắc chấm có thể sửa ngay. Niềm tin chỉ được phục hồi khi tổ chức giải thích được việc sửa xác lập điều gì, còn chưa biết gì và ai phụ trách công việc chưa xong.