Bỏ qua đến nội dung chính

Tại Sao Agent Tuyên Bố Chiến Thắng Quá Sớm

Cách Ngăn chặn Việc Nộp bài Sớm

1. Ngoại hóa việc Đánh giá Kết thúc

Việc đánh giá hoàn thành không nên do chính agent thực hiện. Harness phải thực hiện xác nhận kết thúc một cách độc lập, sử dụng các tín hiệu runtime làm đầu vào chứ không phải sự tự tin của agent. Viết rõ điều này trong CLAUDE.md:

## Định nghĩa Hoàn thành (Definition of Done)
- Tính năng hoàn thành = xác minh end-to-end đã qua, không phải "mã đã được viết"
- Các cấp độ xác minh bắt buộc:
  1. Unit tests pass
  2. Integration tests pass
  3. End-to-end flow verification passes
- Không chuyển sang cấp độ 2 nếu cấp độ 1 thất bại
- Không chuyển sang cấp độ 3 nếu cấp độ 2 thất bại

2. Xây dựng Xác nhận Kết thúc Ba Lớp

  • Lớp 1: Cú pháp và Phân tích Tĩnh. Chi phí thấp nhất, ít thông tin nhất, nhưng phải vượt qua. Đây là mức kiểm tra tối thiểu—bạn phải đánh vần đúng các từ trước khi chúng ta xem xét bất cứ thứ gì khác.
  • Lớp 2: Xác minh Hành vi Runtime. Thực thi test, kiểm tra khởi động ứng dụng, xác nhận đường dẫn quan trọng. Đây là bằng chứng cốt lõi của sự hoàn thành. Chỉ viết ra thôi là chưa đủ; nó phải chạy được.
  • Lớp 3: Xác nhận Cấp Hệ thống. Kiểm thử end-to-end, xác nhận tích hợp, mô phỏng kịch bản người dùng. Tuyến phòng thủ cuối cùng chống lại các tuyên bố sớm. Nó không chỉ phải chạy; nó phải chạy chính xác.

3. Thiết kế "Bút đỏ Đánh dấu" Tốt cho Agents

OpenAI đã giới thiệu một mẫu đặc biệt hiệu quả trong quá trình thực hành Codex của họ: các thông báo lỗi cho agent phải bao gồm các hướng dẫn sửa chữa. Đừng chỉ vẽ một dấu chéo đỏ lớn như một người chấm điểm lười biếng; hãy giống như một giáo viên giỏi và viết "đây là cách bạn nên thay đổi điều này" ở lề. Đừng sử dụng "Test failed", mà hãy sử dụng "Test failed: POST /api/reset-password returned 500. Check that the email service config exists in environment variables. The template file should be at templates/reset-email.html." Phản hồi cụ thể, có thể hành động này cho phép agent tự sửa lỗi mà không cần sự can thiệp của con người.

4. Nắm bắt các Tín hiệu Runtime

Các tín hiệu runtime hiệu quả bao gồm:

  • Ứng dụng có khởi động thành công và đạt đến trạng thái sẵn sàng không?
  • Các đường dẫn tính năng quan trọng có thực thi thành công trong runtime không?
  • Các thao tác ghi cơ sở dữ liệu, hoạt động tệp và các hiệu ứng phụ khác có chính xác không?
  • Các tài nguyên tạm thời có được dọn dẹp không?

Trường hợp Thực tế

Tác vụ: Triển khai chức năng đặt lại mật khẩu người dùng. Bao gồm hoạt động cơ sở dữ liệu, gửi email và sửa đổi API endpoint.

Đường dẫn nộp bài sớm: Agent sửa đổi cấu trúc cơ sở dữ liệu, viết API endpoint, thêm mẫu email, chạy unit test (qua) và tuyên bố hoàn thành. Bài kiểm tra đã được điền đầy đủ.

Các điểm trừ thực tế: (1) Luồng end-to-end chưa được kiểm tra—việc gửi và xác minh thực tế liên kết đặt lại chưa bao giờ được xác nhận. (2) Quá trình migration cơ sở dữ liệu thất bại sau khi thực thi một phần, gây ra sự không nhất quán cấu trúc. (3) Cấu hình dịch vụ email bị thiếu trong môi trường đích.

Sự can thiệp của Harness: Xác nhận kết thúc bị bắt buộc—(1) Khởi động toàn bộ ứng dụng để xác minh khả năng truy cập endpoint đặt lại; (2) Thực thi toàn bộ quy trình đặt lại; (3) Xác minh tính nhất quán của trạng thái cơ sở dữ liệu. Tất cả các khiếm khuyết đã được tìm thấy trong phiên, tiết kiệm 5-10 lần chi phí của các bản sửa lỗi sau này. Người chấm điểm độc lập đã tìm ra các vấn đề thực sự.

Những Điểm chính cần Nhớ

  • Các Agent thường quá tự tin một cách có hệ thống—sai lệch hiệu chuẩn độ tự tin là một thực tế khách quan. Điền kín bài kiểm tra không có nghĩa là bạn đã làm đúng.
  • Đánh giá hoàn thành phải được ngoại hóa—harness tự xác minh một cách độc lập; đừng tin vào "cảm giác" của agent. Học sinh không thể tự chấm bài thi của mình.
  • Cả ba lớp xác nhận đều rất cần thiết—qua được cú pháp, qua được hành vi, qua được hệ thống, tiến triển từng lớp một.
  • Các thông báo lỗi nên giống như việc dùng bút đỏ đánh dấu của một giáo viên giỏi—bao gồm các bước sửa chữa cụ thể để agent có thể tự sửa đổi.
  • Không tái cấu trúc (refactoring) cho đến khi chức năng cốt lõi được xác minh—ràng buộc ưu tiên hoàn thành là chìa khóa để ngăn chặn tối ưu hóa sớm.

Đọc thêm

Bài tập

  1. Thiết kế Hàm Xác nhận Kết thúc: Thiết kế một quy trình xác nhận kết thúc hoàn chỉnh cho một tác vụ liên quan đến việc di chuyển cơ sở dữ liệu và sửa đổi API. Liệt kê các tín hiệu runtime cần thiết và các tiêu chí đạt/trượt (pass/fail) cho từng tín hiệu. Chạy nó trên một tác vụ thực tế và ghi lại những vấn đề tiềm ẩn mà nó tìm thấy.

  2. Đo lường Sai lệch Hiệu chuẩn: Chọn 10 loại tác vụ lập trình khác nhau và ghi lại độ tự tin hoàn thành tự báo cáo của agent so với chất lượng hoàn thành thực tế. Tính toán giá trị sai lệch và phân tích mối quan hệ của nó với độ phức tạp của tác vụ.

  3. Thử nghiệm Phòng thủ Đa Lớp: Chạy ba cấu hình trên cùng một bộ tác vụ—(a) chỉ phân tích tĩnh, (b) thêm unit testing, (c) xác nhận đầy đủ ba lớp. So sánh tỷ lệ các tuyên bố hoàn thành sớm và số lượng các khiếm khuyết không bị phát hiện.

Góp ý / Báo lỗiPhát hiện sai sót hoặc có ý tưởng cải thiện?