GitHub Copilot CLI giới thiệu "Rubber Duck": Kết hợp nhiều họ mô hình AI để có "ý kiến thứ hai"

GitHub Copilot CLI vừa ra mắt tính năng thử nghiệm "Rubber Duck", sử dụng một mô hình AI từ một họ khác để đóng vai trò là người đánh giá độc lập đối với công việc của tác nhân chính. Cơ chế này giúp phát hiện các lỗi tiềm ẩn và cải thiện chất lượng mã nguồn, đặc biệt trong các tác vụ phức tạp.

Khi yêu cầu một tác nhân AI xây dựng một đường ống dữ liệu (data pipeline), nó có thể không sử dụng cấu trúc tốt nhất. Nhưng nếu tác nhân đó có được một "ý kiến thứ hai" trước khi thực thi kế hoạch thì sao?

Hôm nay, GitHub Copilot CLI công bố tính năng thử nghiệm mang tên Rubber Duck. Tính năng này tận dụng một mô hình AI thứ hai thuộc một họ khác để đóng vai trò là người đánh giá độc lập, xem xét các kế hoạch và công việc của tác nhân chính tại những thời điểm quan trọng nhất.

GitHub Copilot CLI

Vấn đề: Những sai lầm tự tin có thể cộng hưởng

Các tác nhân lập trình hiện nay thường tuân theo một vòng lặp rõ ràng: đánh giá nhiệm vụ, lập kế hoạch, triển khai, kiểm thử và lặp lại nếu cần. Mặc dù quy trình này mạnh mẽ, nó vẫn có những điểm mù. Bất kỳ quyết định nào mà tác nhân đưa ra ở giai đoạn đầu, đặc biệt là khi lập kế hoạch, đều là nền tảng cho toàn bộ quá trình sau này. Các giả định và sự không hiệu quả sẽ trở thành sự phụ thuộc, và khi bạn nhận ra, có thể bạn đã phải sửa chữa nhiều hơn là một lỗi nhỏ ban đầu.

Việc sử dụng tự phản chiếu (self-reflection) và yêu cầu tác nhân xem xét lại đầu ra của chính mình là một kỹ thuật đã được chứng minh. Tuy nhiên, một mô hình tự đánh giá công việc của nó vẫn bị giới hạn bởi những thiên kiến trong quá trình huấn luyện của chính nó: cùng dữ liệu huấn luyện, cùng kỹ thuật, và cùng những điểm mù.

Rubber Duck thêm một góc nhìn mới

Rubber Duck là một tác nhân đánh giá tập trung, được cung cấp sức mạnh bởi một mô hình thuộc họ mô hình bổ trợ cho phiên bản Copilot chính của bạn. Khi bạn chọn mô hình Claude từ bộ chọn mô hình (model picker) làm điều phối viên (orchestrator), Rubber Duck sẽ sử dụng GPT-5.4.

Nhiệm vụ của Rubber Duck là kiểm tra công việc của tác nhân và đưa ra một danh sách ngắn gọn, tập trung vào các mối quan tâm có giá trị cao: các chi tiết mà tác nhân chính có thể đã bỏ lỡ, các giả định đáng ngờ cần được đặt câu hỏi, và các trường hợp ngoại lệ (edge cases) cần cân nhắc.

Hiệu năng trên các bài toán thực tế

Chúng tôi đã đánh giá Rubber Duck trên SWE-Bench Pro, một tiêu chuẩn đánh giá bao gồm các bài toán lập trình khó và thực tế được trích từ các kho lưu trữ mã nguồn mở. Kết quả cho thấy:

Claude Sonnet 4.6 khi kết hợp với Rubber Duck (chạy GPT-5.4) đạt tỷ lệ giải quyết vấn đề tiệm cận với Claude Opus 4.6 khi chạy độc lập, giúp thu hẹp 74,7% khoảng cách hiệu năng giữa Sonnet và Opus.

Rubber Duck tỏ ra hữu ích hơn với các vấn đề khó khăn, những bài toán trải rộng trên 3 tệp tin trở lên và thường mất hơn 70 bước để giải quyết.

Một số ví dụ điển hình:

Lỗi kiến trúc (OpenLibrary/async scheduler): Rubber Duck phát hiện rằng bộ lập lịch được đề xuất sẽ khởi động và thoát ngay lập tức, không chạy được công việc nào—và ngay cả khi sửa lỗi, một trong các nhiệm vụ đã lên kế hoạch lại là một vòng lặp vô hạn.
Lỗi một dòng, tác động lớn (OpenLibrary/Solr): Rubber Duck bắt gặp một vòng lặp âm thầm ghi đè cùng một khóa từ điển trong mỗi lần lặp. Ba trong số bốn danh mục phân loại Solr bị loại bỏ khỏi mọi truy vấn tìm kiếm mà không gây ra lỗi nào.
Xung đột chéo tệp (NodeBB/xác nhận email): Rubber Duck phát hiện ba tệp tin đều đọc từ một khóa Redis mà mã mới ngừng ghi vào. Giao diện người dùng xác nhận và đường dẫn dọn dẹp sẽ bị hỏng âm thầm khi triển khai.

Khi nào Rubber Duck được kích hoạt?

GitHub Copilot có thể gọi Rubber Duck tự động, cả theo cách chủ động và phản ứng, đồng thời người dùng cũng có thể kích hoạt nó bất cứ lúc nào để phê bình và sửa đổi công việc.

Đối với các công việc phức tạp, Copilot có thể tìm kiếm sự phê bình tự động tại các điểm kiểm tra mang lại lợi ích cao nhất:

Sau khi soạn thảo kế hoạch: Đây là nơi các nhà phát triển sẽ thấy lợi ích lớn nhất, vì việc phát hiện ra một quyết định không tối ưu sớm sẽ tránh các lỗi cộng hưởng về sau.
Sau khi triển khai phức tạp: Khi đó, "cặp mắt thứ hai" trên mã phức tạp có thể giúp bắt các trường hợp ngoại lệ.
Sau khi viết bài kiểm tra (tests), trước khi thực thi: Đây là cơ hội để bắt các lỗ hổng trong phạm vi kiểm tra hoặc các xác nhận bị sai lệch, trước khi tự củng cố rằng "mọi thứ đều vượt qua".

Tác nhân cũng có thể tìm kiếm sự phê bình một cách phản ứng nếu nó bị kẹt trong một vòng lặp hoặc không thể tiến triển. Việc tham vấn Rubber Duck có thể phá vỡ thế bế tắc.

Cách bắt đầu

Rubber Duck hiện đã có sẵn trong chế độ thử nghiệm.

Để bắt đầu sử dụng, bạn cần cài đặt GitHub Copilot CLI và chạy lệnh /experimental. Rubber Duck sẽ khả dụng khi bạn chọn bất kỳ mô hình nào thuộc họ Claude từ bộ chọn mô hình và có quyền truy cập được bật cho GPT-5.4. Bạn sẽ thấy các nhận xét phê bình xuất hiện theo hai cách:

Tự động, khi Copilot quyết định một điểm kiểm tra đáng lý có ý kiến thứ hai: sau khi lập kế hoạch, sau các triển khai phức tạp, hoặc sau khi viết bài kiểm tra.
Theo yêu cầu, bất cứ khi nào bạn muốn. Ch cần yêu cầu Copilot phê bình công việc của nó, và nó sẽ triệu hồi Rubber Duck, kết hợp phản hồi và hiển thị chính xác những gì đã thay đổi.

Tính năng này đặc biệt hữu ích cho các tình huống như tái cấu trúc phức tạp, các nhiệm vụ rủi ro cao mà việc bỏ sót chi tiết tốn kém, hoặc bất cứ khi nào bạn muốn có một ý kiến thứ hai về một kế hoạch trước khi cam kết thực hiện nó.