Trang này là một buổi diễn tập mô phỏng trên lớp: để nhiều Agent phối hợp phân công quanh cùng một nhiệm vụ phát triển, đưa các bản sửa đổi ứng viên do mỗi bên tạo ra vào chung một cổng kiểm thử tự động và nghiệm thu; chỉ những sửa đổi đáp ứng tiêu chuẩn nghiệm thu có thể thực thi mới được đưa vào đường cơ sở lịch sử, còn sửa đổi không đạt sẽ bị chặn lại và trả về phản hồi có thể tái hiện. Mục tiêu của việc này không phải để các Agent "thảo luận ra cái đúng", mà là chạy thông suốt vòng lặp kỹ thuật khép kín "hợp tác phát triển — nghiệm thu tự động — kế thừa lịch sử".
Mục tiêu diễn tập
- Hiểu được phân công nhiệm vụ, việc hội tụ các bản sửa đổi ứng viên trong hợp tác phát triển đa Agent, cũng như vai trò chặn đứng các sửa đổi không đạt của cổng nghiệm thu.
- Trải nghiệm việc dùng kiểm thử có thể thực thi và điều kiện nghiệm thu thay cho phê duyệt chủ quan, quan sát ứng viên nào vào được đường cơ sở, ứng viên nào cần thử lại.
- So sánh các vấn đề nâng cao: quy tắc nghiệm thu có tái hiện được không, phản hồi có thể hành động không, rủi ro chặn nhầm và bỏ sót, độ mịn của việc phân rã và chi phí hợp tác.
Phân công vai trò và quy trình cơ bản
Có thể chia nhóm trên lớp thành Agent lập kế hoạch/phân rã, Agent hiện thực, Agent sinh kiểm thử, Agent thẩm định/điều phối. Cùng một nhiệm vụ cho phép sinh ra nhiều bản sửa đổi ứng viên, sau đó cổng nghiệm thu sẽ phán quyết tập trung.
- Phân rã nhiệm vụ: chia mục tiêu thành các nhiệm vụ con có thể kiểm chứng độc lập, ví dụ "kiểm tra giao diện — sửa thuật toán — kiểm thử hồi quy".
- Hiện thực song song: nhiều Agent hiện thực nộp bản vá ứng viên, Agent kiểm thử sinh các ca kiểm thử biên.
- Nghiệm thu tự động: chạy kiểm thử tự động, kiểm tra tĩnh và kiểm tra hợp đồng, cổng nghiệm thu phán định theo tiêu chuẩn có thể thực thi.
- Kế thừa lịch sử: các sửa đổi được thông qua sẽ hợp nhất vào đường cơ sở lịch sử, trở thành nền tảng để các Agent sau tiếp tục làm việc; các sửa đổi bị từ chối sẽ giữ lại nguyên nhân thất bại và thông tin tái hiện để thử lại.
Tiêu chuẩn của cổng nghiệm thu
Tiêu chí của cổng phải có thể thực thi, không thể dừng ở mức "trông có vẻ đúng". Trọng tâm là chặn các sửa đổi không thỏa mãn quy ước giao diện, gây hồi quy, không bao phủ điều kiện biên hoặc vi phạm ràng buộc chất lượng. Một phản hồi dùng được tối thiểu phải bao gồm: ca kiểm thử thất bại, nhật ký, các bước tái hiện, hành vi mong đợi và các ràng buộc liên quan.
Kế thừa lịch sử và quan sát nâng cao
Sau khi các sửa đổi được thông qua vào đường cơ sở, các Agent sau không cần bắt đầu lại từ đầu; còn các sửa đổi bị từ chối sẽ trở thành ví dụ phản diện có thể tra cứu, tránh lặp lại sai lầm. Khi đánh giá loại hệ thống hợp tác này, cần đặc biệt chú ý liệu quy tắc nghiệm thu có tái hiện được không, phản hồi có thể hành động không, cũng như các rủi ro khác nhau do chặn nhầm và bỏ sót. Phân rã quá mịn sẽ làm tăng chi phí hợp nhất và nghiệm thu, còn quá thô sẽ khiến các bản sửa đổi ứng viên chồng chéo lên nhau; cách ổn định hơn là chia theo ranh giới "có thể kiểm chứng độc lập".
