Chuyện gì đã xảy ra
Các nhà nghiên cứu Eric S. Qiu và Joyce Gill giới thiệu Đánh giá đối nghịch, một giao thức hợp tác tối thiểu để đánh giá mã tác nhân. Hệ thống sử dụng tác nhân mã hóa chính, người đánh giá và người phê bình để thách thức việc xem xét bằng cách nhấn mạnh vào bằng chứng trước khi tác nhân mã hóa thực hiện các thay đổi.
Bài báo được gửi tới arXiv vào ngày 16 tháng 8 năm 2026, mô tả Đánh giá đối nghịch là nền tảng trung gian giữa hai cách tiếp cận phổ biến đối với hệ thống mã hóa đa tác nhân. Các hệ thống phân tách vai trò trước đây có thể sử dụng nhiều tác nhân, nhưng các tác giả cho biết hiệu suất có thể cho thấy lợi nhuận giảm dần khi số lượng tác nhân tăng lên. Các hệ thống chỉ coi các tác nhân bổ sung là tác nhân phụ thụ động có thể giảm chi phí đó nhưng cũng loại bỏ phần lớn sự tương tác giữa các tác nhân. AR duy trì một mức độ hợp tác nhỏ trong khi giao các trách nhiệm riêng biệt cho ba tác nhân: tác nhân mã hóa chính, người đánh giá và người phê bình.
Người đánh giá đánh giá mã do tác nhân chính tạo ra. Sau đó, nhà phê bình sẽ kiểm tra đánh giá thông qua những gì các tác giả mô tả là sự bất đồng có cấu trúc. Sự bất đồng đó xảy ra trước khi tác nhân chính chỉnh sửa mã, khiến quá trình xem xét trở thành điểm kiểm tra quyết định thay vì trao đổi không có cấu trúc giữa nhiều tác nhân. Nguồn mô tả giao thức là có cơ sở bằng chứng, nhưng bản tóm tắt không nêu rõ các gợi ý chính xác, yêu cầu bằng chứng, hình thức bất đồng hoặc tiêu chí được sử dụng để xác định thời điểm tác nhân chính nên chấp nhận thay đổi được đề xuất.
Các tác giả báo cáo các bài kiểm tra trên ba đánh giá mã hóa. Trên LiveCodeBench, họ cho biết AR đã đạt được tỷ lệ vượt qua cao nhất trong số các phương pháp được thử nghiệm và vượt trội hơn so với đường cơ sở gồm 5 tác nhân trong khi sử dụng ba tác nhân. Trên SWE-PRBench, các tác giả cho biết một phiên bản AR đơn giản đã tiết lộ một phương thức thất bại do đồng thuận sai: các đại lý đồng ý mà không có đủ bằng chứng. Họ báo cáo rằng một lần lặp lại nhắc nhở có thêm sự bất đồng rõ ràng đã tạo ra F1 cao nhất trong số các phương pháp được thử nghiệm. Trên SWE-bench Verify, họ cũng báo cáo những cải tiến so với đường cơ sở về các tác vụ mã hóa cấp kho lưu trữ. Nguồn không cung cấp điểm cơ bản, khoảng tin cậy, nhận dạng mô hình, số lượng nhiệm vụ hoặc kiểm tra thống kê.
Bài viết được xác định là đã được chấp nhận tham gia Hội thảo ICML 2026 về DL4C. Trạng thái đó xác lập sự chấp nhận hội thảo đã nêu của tác giả, nhưng nó không giống như bằng chứng cho thấy phương pháp này đã được nhân rộng hoặc xác nhận một cách độc lập trong sản xuất. Nguồn có sẵn ở đây là bản ghi thư mục và tóm tắt arXiv; nó không chứng minh rằng AR được triển khai công khai, tích hợp vào sản phẩm mã hóa thương mại hoặc được chứng minh là có hiệu quả đối với các dự án phần mềm ngoài các đánh giá được báo cáo.
Tại sao nó quan trọng
Công trình này giải quyết một vấn đề về độ tin cậy thực tế trong các hệ thống mã hóa AI: việc thêm nhiều tác nhân hơn không nhất thiết cải thiện hiệu suất ở cấp kho lưu trữ và các tác nhân có thể đồng ý mà không cần có đủ bằng chứng. Nếu mẫu được báo cáo vượt xa các tiêu chuẩn đã được kiểm tra thì sự bất đồng có cấu trúc có thể đưa ra một cách tương đối nhẹ nhàng để cải thiện chất lượng đánh giá.
Các tác nhân mã hóa AI ngày càng thực hiện các nhiệm vụ đòi hỏi nhiều hơn là tạo ra một bản vá hợp lý cục bộ. Họ phải giải thích kho lưu trữ, thực hiện các thay đổi trên các tệp, chạy hoặc suy luận về các thử nghiệm và quyết định xem giải pháp đề xuất có phù hợp hay không. Cơ chế đánh giá kiểm tra cả mã và bản thân quá trình đánh giá nhắm đến điểm yếu mà việc tạo một lượt thông thường có thể không giải quyết được: người đánh giá có thể đưa ra đánh giá tự tin nhưng không được hỗ trợ và các tác nhân khác có thể chấp nhận đánh giá đó vì kết quả đầu ra của họ hội tụ.
Kết quả đồng thuận sai được báo cáo là đặc biệt quan trọng. Nó gợi ý rằng việc chỉ giao các vai trò khác nhau cho các tác nhân không đảm bảo sự bất đồng hữu ích. Trong tài khoản của nguồn, giao thức đã trở nên hiệu quả hơn trên SWE-PRBench sau khi có lời nhắc yêu cầu không đồng ý một cách rõ ràng. Phát hiện đó, nếu được nhân rộng, sẽ chuyển sự chú ý từ số lượng tác nhân là đòn bẩy thiết kế chính sang chất lượng của các quy tắc tương tác. Một hệ thống nhỏ hơn có thể dễ vận hành, kiểm tra và lập ngân sách hơn so với một nhóm đại lý lớn hơn, mặc dù nguồn không định lượng được những lợi ích hoạt động đó.
Đối với các nhà phát triển và tổ chức, giá trị tiềm năng không phải là ba tác nhân tự động tạo ra phần mềm chính xác. Đúng hơn, AR đưa ra một giả thuyết thiết kế: các tác nhân đánh giá mã có thể đáng tin cậy hơn khi một thành phần được giao nhiệm vụ thách thức bằng chứng của người đánh giá trước khi các thay đổi được chấp nhận. Điểm kiểm tra như vậy có thể giúp tìm ra các bài kiểm tra còn thiếu, các giả định không được hỗ trợ hoặc những bất đồng về hành vi của kho lưu trữ. Tuy nhiên, nguồn không báo cáo loại lỗi nào đã được cải thiện, liệu phương pháp này có phát hiện được lỗi bảo mật hay không hoặc liệu nó có làm giảm các hồi quy có hại hay không. Những thiếu sót đó hạn chế những gì có thể suy luận một cách có trách nhiệm về sự an toàn thực tế.
Kết quả cũng quan trọng để đánh giá. LiveCodeBench, SWE-PRBench và SWE-bench được xác minh đo lường các khía cạnh khác nhau của hiệu suất mã hóa, nhưng bản thân các cải tiến về điểm chuẩn không tạo ra kết quả tốt hơn trong các kho lưu trữ thực. Bản tóm tắt không cho biết liệu các nhiệm vụ có được chọn trước hay không, liệu các lời nhắc có được điều chỉnh trên các bộ đánh giá hay không, cách người đánh giá xử lý các bài kiểm tra không đạt hoặc liệu các đường cơ sở có nhận được ngân sách mã thông báo và quyền truy cập công cụ tương đương hay không. Nếu không có những chi tiết đó, thứ hạng được báo cáo là bằng chứng để điều tra thêm, chứ không phải là bằng chứng chung cho thấy sự bất đồng có cấu trúc là ưu việt hơn.
Cơ chế tương tác: Nó thực sự hoạt động như thế nào
Khám phá công nghệ cơ bản đằng sau sự phát triển này một cách tương tác.
crm_get_transaction(id='4092').What most distinguishes an AI agent from a basic chatbot?
Xem gì tiếp theo
Câu hỏi chính là liệu lợi ích có được nhân rộng trên nhiều kho lưu trữ, ngôn ngữ, mô hình và nhóm kỹ thuật thực tế hơn hay không và giao thức sẽ tăng độ trễ và chi phí đến mức nào. Nguồn không cung cấp kết quả bằng số, cấu hình thử nghiệm, phân tích lỗi hoặc bằng chứng về việc sử dụng sản xuất, vì vậy những phát hiện này phải được coi là sơ bộ.
Ưu tiên hàng đầu là sao chép với đầy đủ giấy tờ, mã, lời nhắc và cài đặt thử nghiệm. Người đọc nên tìm kiếm tỷ lệ vượt qua chính xác và điểm F1, số lượng và thành phần nhiệm vụ, mô hình được sử dụng cho từng đại lý, ngân sách mã thông báo và công cụ cũng như định nghĩa của từng đường cơ sở. Các nghiên cứu loại bỏ sẽ đặc biệt hữu ích: chúng có thể kiểm tra xem liệu lợi ích có đến từ vai trò phê phán, từ ngôn ngữ bất đồng rõ ràng, từ tính toán bổ sung hay từ sự khác biệt về số lượng chu kỳ xem xét.
Vấn đề thứ hai là tính khái quát. Nguồn nêu tên ba điểm chuẩn nhưng không thiết lập hiệu suất trên các ngôn ngữ lập trình, kho lưu trữ độc quyền, công việc bảo trì dài hạn, kiến trúc mới hoặc các nhóm có người đánh giá là con người. Cũng không biết liệu phương pháp này có hoạt động hay không khi các thử nghiệm không đầy đủ hoặc sai lệch, khi tài liệu kho lưu trữ xung đột với việc triển khai hoặc khi nhà phê bình phải đánh giá đánh giá liên quan đến cấu hình bảo mật, quyền riêng tư hoặc triển khai. Những trường hợp đó có thể tạo ra sự cân bằng khác với các nhiệm vụ chuẩn.
Chi phí hoạt động xứng đáng được quan tâm như nhau. AR sử dụng ít tác nhân hơn so với đường cơ sở gồm 5 tác nhân được trích dẫn, nhưng nó vẫn bổ sung giai đoạn đánh giá và phê bình trước khi chỉnh sửa. Điều đó có thể làm tăng độ trễ, lệnh gọi mô hình, mức sử dụng ngữ cảnh và chi phí cơ sở hạ tầng ngay cả khi tổng số tác nhân thấp hơn. Nguồn không đưa ra thước đo nào cho các yếu tố này và không cho biết tần suất người phê bình lật đổ người đánh giá, cách giải quyết các bất đồng hoặc liệu những thách thức lặp đi lặp lại có thể tạo ra những thay đổi không cần thiết hay không. Báo cáo trong tương lai nên kết nối mức độ chính xác với chi phí và thời gian thay vì chỉ trình bày số lượng đại lý.
Cuối cùng, người dùng nên theo dõi bằng chứng từ việc triển khai kỹ thuật độc lập và các nghiên cứu lấy con người làm trung tâm. Nguồn không chứng minh rằng AR cải thiện độ tin cậy của nhà phát triển, mức độ hiểu bài đánh giá hoặc tỷ lệ sự cố cũng như không cho thấy mọi người phản ứng như thế nào khi nhân viên không đồng ý. Một đánh giá mạnh mẽ sẽ đo lường cả kết quả kỹ thuật và chi phí sai sót, bao gồm phê duyệt sai, từ chối sai, hồi quy và sai sót liên quan đến bảo mật. Cho đến khi có bằng chứng đó, kết luận có thể bào chữa nhất là Đánh giá đối nghịch là một quy trình nghiên cứu đầy hứa hẹn với các tuyên bố chuẩn mực đảm bảo sự xem xét kỹ lưỡng và nhân rộng.