eval-harness

Tổng quan về kỹ năng eval-harness

eval-harness làm gì

Kỹ năng eval-harness là một khung đánh giá chính thức cho các phiên Claude Code và cho phát triển theo hướng eval-driven. Nó giúp bạn xác định trước thế nào là “tốt” trước khi phát hành, rồi đo xem một agent, prompt hay workflow có thực sự đạt chuẩn đó hay không.

Ai nên dùng

Hãy dùng kỹ năng eval-harness nếu bạn cần các kiểm tra lặp lại cho lập trình có hỗ trợ AI, thay đổi prompt, hoặc hành vi của agent. Kỹ năng này đặc biệt hữu ích cho các nhóm đang so sánh phiên bản model, theo dõi hồi quy, hoặc biến các kỳ vọng công việc mơ hồ thành tiêu chí đạt/không đạt.

Vì sao nó quan trọng

Giá trị chính của eval-harness for Model Evaluation là độ tin cậy: thay vì đánh giá kết quả theo cảm tính, bạn viết các eval để lộ ra khi hành vi thay đổi. Nhờ đó, việc gỡ lỗi hiệu năng agent, so sánh các lần chạy, và tránh phát hành những cập nhật prompt làm chất lượng giảm đi một cách âm thầm sẽ dễ hơn nhiều.

Khi nào phù hợp

Kỹ năng này phù hợp nhất khi nhiệm vụ có thể được diễn đạt bằng tiêu chí thành công có thể quan sát được, cấu trúc đầu ra, hoặc hành vi có các mốc kiểm tra rõ ràng. Nó kém hữu ích hơn với công việc sáng tạo mở, trừ khi bạn vẫn có thể xác định điều kiện chấp nhận có thể đo được.

Cách dùng kỹ năng eval-harness

Cài đặt và kích hoạt

Để thực hiện eval-harness install, hãy dùng luồng cài đặt skill của repo trong môi trường Claude Code của bạn, rồi mở trực tiếp file skill. Skill nằm ở skills/eval-harness/SKILL.md, và đây là file đầu tiên cần đọc vì nó định nghĩa khi nào kích hoạt framework và cách tổ chức các eval.

Xây một prompt mà skill có thể đánh giá

Với eval-harness usage hiệu quả, đừng bắt đầu bằng “test my agent”. Hãy bắt đầu bằng một mục tiêu cụ thể, chẳng hạn: agent phải hoàn thành tác vụ gì, điều gì được tính là thành công, thế nào là thất bại, và bạn đang kiểm tra năng lực hay hồi quy. Một đầu vào tốt hơn sẽ là: “Đánh giá xem agent có thể cập nhật một React form mà không làm hỏng validation hay không, và yêu cầu ba tiêu chí thành công rõ ràng.” Như vậy harness mới có cái để đo lường.

Đọc đúng file trước

Nếu bạn đang áp dụng cách tiếp cận eval-harness guide trong workflow riêng, hãy đọc SKILL.md trước, rồi kiểm tra mọi ghi chú trong repo mô tả phong cách đánh giá, logic chấm điểm, hoặc quy ước đầu ra. Trong repo này không có script phụ trợ hay thư mục hỗ trợ bổ sung, nên chính file skill là nguồn chuẩn duy nhất.

Dùng trong một workflow thực tế

Một workflow tốt là: xác định hành vi, viết một eval cho đường đi thuận lợi, thêm một eval hồi quy cho một lỗi đã biết, rồi chạy harness và tinh chỉnh tiêu chí. Cách này giúp các eval đủ nhỏ để gỡ lỗi, đồng thời giảm nguy cơ viết test quá rộng nên không thể diễn giải.

Câu hỏi thường gặp về skill eval-harness

eval-harness chỉ dành cho Claude Code à?

Không. Skill này được viết xoay quanh các phiên Claude Code, nhưng phương pháp nền tảng vẫn hữu ích ở bất cứ đâu bạn cần đánh giá agent theo cấu trúc rõ ràng. Nếu stack của bạn dùng công cụ khác, bạn vẫn có thể điều chỉnh định dạng eval và logic chấm điểm.

eval-harness có giống một prompt bình thường không?

Không. Một prompt bình thường yêu cầu một câu trả lời; eval-harness yêu cầu một cách lặp lại được để đánh giá các câu trả lời. Sự khác biệt này rất quan trọng khi bạn cần tính nhất quán qua nhiều phiên bản, chứ không chỉ một phản hồi tốt duy nhất.

Nó có thân thiện với người mới không?

Có, nếu bạn có thể mô tả nhiệm vụ rõ ràng. Phần khó hơn không phải cú pháp, mà là viết tiêu chí thành công tốt. Người mới thường làm tốt khi bắt đầu bằng một eval năng lực đơn giản thay vì cố mô hình hóa cả một workflow ngay từ đầu.

Khi nào tôi không nên dùng?

Hãy bỏ qua eval-harness nếu công việc mang tính chủ quan cao, nếu đầu ra không thể kiểm tra nhất quán, hoặc nếu bạn chỉ cần một câu trả lời dùng một lần. Kỹ năng này mạnh nhất khi độ tin cậy, theo dõi hồi quy, hoặc so sánh model mới là mục tiêu thật sự.

Cách cải thiện kỹ năng eval-harness

Làm cho tiêu chí có thể quan sát được

Mức cải thiện chất lượng lớn nhất đến từ việc biến ý kiến thành các kiểm tra cụ thể. Hãy thay “làm nó tốt hơn” bằng những điều kiện như “giữ nguyên shape của API hiện có,” “trả về JSON hợp lệ,” hoặc “qua cả ba trường hợp hồi quy.” Tiêu chí càng quan sát được thì eval-harness càng dễ chạy và càng đáng tin.

Tách biệt năng lực và hồi quy

Nếu bạn trộn kiểm tra tính năng mới với kiểm tra hành vi cũ, lỗi sẽ rất khó diễn giải. Hãy giữ các eval năng lực tập trung vào việc Claude có làm được điều mới hay không, và các eval hồi quy tập trung vào việc một baseline đã biết có còn được giữ nguyên hay không.

Cho harness các ca biên thực

Các eval mạnh hơn luôn có cả chế độ thất bại, không chỉ đường đi thuận lợi. Hãy thêm input khó, ngữ cảnh thiếu, hoặc hướng dẫn mơ hồ để eval-harness skill có thể cho thấy agent đủ vững hay chỉ là gặp may trên các ví dụ sạch.

Lặp lại sau lần chạy đầu tiên

Hãy coi lần chạy đầu tiên là bước hiệu chỉnh, không phải bằng chứng cuối cùng. Nếu kết quả chưa rõ, hãy siết chặt tiêu chí thành công, thêm một baseline, hoặc tách một eval quá rộng thành nhiều kiểm tra nhỏ hơn. Đó thường là cách nhanh nhất để cải thiện eval-harness usage và có được kết quả có thể hành động ngay.