Nguyên tắc quan trọng: Thực thi các bất biến, không vi quản lý triển khai. Ví dụ, yêu cầu "dữ liệu được parse tại ranh giới," nhưng không chỉ định nên sử dụng thư viện nào. Thông báo lỗi phải bao gồm hướng dẫn sửa chữa — không chỉ nói "vi phạm," mà nói với agent chính xác cách thay đổi.
Nguồn: OpenAI: Harness engineering: leveraging Codex in an agent-first world
1. Harness Phải Bao gồm Một Lớp End-to-End
Làm rõ ràng trong luồng xác minh của bạn: đối với các tác vụ liên quan đến thay đổi xuyên component, vượt qua test end-to-end là điều kiện tiên quyết cho hoàn thành:
## Thứ bậc Xác minh
- Mức 1: Unit test (Bắt buộc vượt qua)
- Mức 2: Integration test (Bắt buộc vượt qua)
- Mức 3: Test End-to-end (Bắt buộc vượt qua khi có thay đổi xuyên component)
- Bỏ qua bất kỳ mức nào bắt buộc = Chưa Hoàn thành
2. Biến Quy tắc Kiến trúc Thành Kiểm tra Có thể Thực thi
Mỗi ràng buộc kiến trúc nên có test hoặc quy tắc lint tương ứng:
# Kiểm tra xem render process có gọi trực tiếp Node.js API không
grep -r "require('fs')" src/renderer/ && exit 1 || echo "OK: no direct fs access in renderer"
3. Thiết kế Thông báo Lỗi Hướng Agent
Thông báo lỗi nên chứa ba yếu tố: điều gì đã sai, tại sao, và cách sửa:
LỖI: Tìm thấy import trực tiếp 'fs' trong src/renderer/App.tsx:12
TẠI SAO: Render process không có quyền truy cập Node.js API vì lý do bảo mật
CÁCH SỬA: Di chuyển các hoạt động tệp sang src/preload/file-ops.ts và gọi qua window.api.readFile()
4. Thiết lập Quy trình Đẩy Phản hồi Review
Mỗi khi tìm thấy một loại lỗi agent mới trong code review, biến nó thành kiểm tra tự động. Một tháng sau, harness của bạn sẽ mạnh hơn đáng kể so với lúc đầu tháng. Giống như ghi chú buổi tập cho hợp xướng — ghi lại các vấn đề được tìm thấy trong mỗi buổi tập để có thể kiểm tra trước buổi tiếp theo. Theo thời gian, các lỗi phổ biến giảm đi, và âm nhạc trở nên hài hòa hơn.
Trường hợp Thực tế
Tác vụ: Triển khai tính năng xuất tệp trong ứng dụng Electron. Liên quan đến UI render process, proxy hệ thống tệp preload script, và chuyển đổi dữ liệu lớp service.
Hát từng bè riêng (Unit test vượt qua): Test component Render (vượt qua, file operations được mock), test preload script (vượt qua, filesystem được mock), test lớp service (vượt qua, data source được mock). Agent tuyên bố hoàn thành.
Hát cùng nhau (Lỗi được Test End-to-End tiết lộ):
| Lỗi | Mô tả | Unit Test | E2E |
|---|---|---|---|
| Không khớp giao diện | Định dạng đường dẫn tệp không nhất quán | Bỏ qua | Bắt được |
| Truyền trạng thái | Tiến trình xuất không được gửi trở lại UI qua IPC | Bỏ qua | Bắt được |
| Rò rỉ tài nguyên | File handle xuất tệp lớn không được giải phóng | Bỏ qua | Bắt được |
| Vấn đề quyền | Quyền khác nhau trong môi trường đóng gói | Bỏ qua | Bắt được |
| Truyền lỗi | Ngoại lệ lớp service không đến được lớp UI | Bỏ qua | Bắt được |
Tất cả 5 lỗi đều được test end-to-end bắt được, trong khi unit test không bắt được cái nào. Chi phí là tăng thời gian test từ 2 giây lên 15 giây — hoàn toàn chấp nhận được trong quy trình agent. Dù từng bè hát tốt đến đâu, không thể so với một buổi tập hòa tấu đầy đủ.
Những Điểm chính cần Nhớ
- Unit test mù có hệ thống với các lỗi ranh giới component — thiết kế cô lập của chúng chính xác là điều ngăn chúng phát hiện các vấn đề tương tác. Mọi người đều hát đúng không có nghĩa là hợp xướng không lạc nhịp.
- Testing end-to-end không chỉ phát hiện lỗi, nó thay đổi hành vi lập trình của agent — làm cho nó tập trung hơn vào tích hợp và ranh giới.
- Các quy tắc kiến trúc phải có thể thực thi — không viết trong tài liệu để được đọc, mà được kiểm tra tự động trên mỗi commit.
- Thông báo lỗi phải được thiết kế cho agent — bao gồm các bước cụ thể về "cách sửa nó" để tạo thành vòng lặp tự sửa chữa.
- Đẩy phản hồi review làm cho harness tự động mạnh hơn — mỗi danh mục lỗi được bắt trở thành một tuyến phòng thủ vĩnh viễn.
Đọc thêm
- How Google Tests Software - Whittaker et al. — Nguồn kinh điển của mô hình Tháp Kiểm thử
- Harness Engineering - OpenAI — Thực hành kỹ thuật để thực thi tự động các ràng buộc kiến trúc
- Chaos Engineering - Netflix (Basiri et al.) — Chủ động đưa vào lỗi để xác minh độ bền hệ thống
- QuickCheck - Claessen & Hughes — Phương pháp property testing, nằm giữa example testing và kiểm chứng hình thức
Bài tập
-
Phát hiện Lỗi Xuyên Component: Chọn một tác vụ sửa đổi liên quan đến ít nhất ba component. Đầu tiên, chỉ chạy unit test và ghi lại kết quả, sau đó chạy test end-to-end. Phân tích mỗi lỗi được phát hiện thêm thuộc loại vấn đề tương tác xuyên lớp nào.
-
Tự động hóa Quy tắc Kiến trúc: Chọn một ràng buộc kiến trúc từ dự án của bạn và biến nó thành kiểm tra có thể thực thi (với thông báo lỗi hướng agent). Tích hợp nó vào harness và xác minh hiệu quả của nó với một tác vụ baseline.
-
Đẩy Phản hồi Review: Tìm một loại nhận xét lặp lại từ lịch sử code review của bạn và chuyển đổi nó thành kiểm tra tự động bằng quy trình năm bước. So sánh tần suất của vấn đề trước và sau khi đẩy.