Xếp hạng tác nhân lập trình AI năm 2026: ai thực sự giải quyết được nhiệm vụ

Mỗi tuần, lại có người đăng một biểu đồ: các cột, tỷ lệ phần trăm và một dòng tiêu đề in đậm ở trên cùng ghi “AI lập trình tốt nhất năm 2026”. Ngay bên dưới, một cuộc tranh luận với hàng trăm bình luận bắt đầu. Người này khẳng định công cụ của mình giải quyết được 80 phần trăm nhiệm vụ, người kia đưa ra ảnh chụp màn hình cho thấy chính công cụ đó đạt 74 điểm. Cả hai đều đúng. Họ chỉ đang nhìn vào những phép đo khác nhau và đo những thứ khác nhau.

Tác giả ban đầu đã trải qua chuyện này khi chọn công cụ cho các dự án của mình. Cứ chạy theo vị trí dẫn đầu trong bảng xếp hạng, rồi một tuần sau bạn nhận ra con số đó đến từ thử nghiệm trong phòng thí nghiệm, còn nhiệm vụ thực tế của bạn lại là chuyện khác. Vì vậy, bài viết này không bàn xem ai đứng đầu, mà giải thích cách hoạt động của bất kỳ bảng xếp hạng tác nhân lập trình AI nào: nó đo điều gì, vì sao cùng một mạng nơ-ron lại cho kết quả khác nhau, chi phí thực tế ra sao, và cách đọc bất kỳ bảng nào trong năm phút để chọn công cụ phù hợp với nhiệm vụ của bạn.

Tìm thêm hướng dẫn trong tài liệu Ailoot.

Vì sao bảng xếp hạng tác nhân AI không nói về thương hiệu?#

Điều đầu tiên cần bỏ khỏi đầu là thói quen cổ vũ một thương hiệu. “Anthropic đấu với OpenAI”, “Claude đấu với Gemini” tạo nên tiêu đề thuận tiện, nhưng hầu như không liên quan đến việc chọn công cụ. Bởi thứ bạn chạy trên máy tính là một tác nhân. Và một tác nhân gồm ít nhất hai lớp, cả hai đều ảnh hưởng đến kết quả.

Hãy hình dung một đầu bếp và một căn bếp. Mô hình là đầu bếp: họ biết nấu ăn, có tài năng và kinh nghiệm. Tác nhân là căn bếp cùng toàn bộ thiết bị: bếp nấu, dao, quy trình làm việc và một trợ lý đưa nguyên liệu. Đặt một đầu bếp tài ba vào căn bếp đổ nát thì bữa ăn cũng chỉ ở mức bình thường. Đặt một đầu bếp trung bình vào căn bếp được trang bị hoàn hảo thì họ sẽ nấu ăn nhanh và ổn định. Trong bảng xếp hạng tác nhân AI, bạn đang chọn cả căn bếp, bao gồm cả đầu bếp.

Điều đó dẫn đến một quy tắc đơn giản giúp mọi việc dễ hiểu hơn từ đây. Khi thấy “công cụ X giải quyết được 80 phần trăm nhiệm vụ”, trước hết hãy hỏi: bên trong là mô hình nào, tác nhân nào điều khiển nó, và phép thử nào được dùng để đo lường? Nếu thiếu câu trả lời cho dù chỉ một câu hỏi, thứ bạn đang xem là biểu đồ được tạo ra để khơi mào tranh cãi. Chưa thể gọi đó là bảng xếp hạng.

Mỗi tác nhân AI gồm những gì: mô hình, harness và cấu hình#

Tôi sẽ lần lượt đi qua ba lớp; nếu không hiểu chúng thì không thể đi xa hơn.

Lớp thứ nhất là mô hình. Đây chính là mạng nơ-ron: Claude Opus và Sonnet của Anthropic, GPT-5 của OpenAI, Gemini của Google. Nó là “bộ não” tìm ra giải pháp và viết mã. Nhưng bản thân mô hình không thể chạy bất cứ thứ gì hay xem tệp. Nó chỉ có thể tạo văn bản để phản hồi văn bản.

Lớp thứ hai là harness, hay tác nhân. Đây là chương trình bao quanh mô hình. Nó trao cho mạng nơ-ron đôi tay: mở tệp dự án, chạy lệnh trong terminal, hiển thị những gì bị lỗi và yêu cầu mô hình sửa vấn đề. Claude Code, Codex CLI của OpenAI, Cursor, Cline và Aider đều là harness. Các kỹ sư có một thuật ngữ chuyên môn cho lớp thứ hai này: “harness”. Ý tưởng chính là như vậy: harness là nơi mô hình kéo công việc thực tế vào xử lý.

Lớp thứ ba là cấu hình. Đây là các tùy chọn điều khiển bên trong harness: mô hình được phép “suy nghĩ” bao lâu trước khi trả lời, giao cho nó bao nhiêu lần thử cho một nhiệm vụ và cung cấp những công cụ nào. Cùng một tổ hợp có thể cho điểm khác nhau với các cấu hình khác nhau.

Đó là nguồn gốc của mọi nhầm lẫn quanh các bảng xếp hạng. Mọi người tranh luận về lớp thứ nhất (“mô hình nào thông minh hơn”), trong khi kết quả trong bảng phụ thuộc đồng thời vào cả ba lớp. Giải thích chi tiết cách các lớp này kết hợp thành một hệ thống hoạt động nằm trong bài tác nhân AI là gì, giải thích đơn giản.

Đọc bảng xếp hạng là một chuyện; tự lắp ghép tổ hợp mô hình, tác nhân và cấu hình phù hợp là chuyện khác. Đó là mục đích của kỹ thuật ngữ cảnh: quản lý những gì AI nhìn thấy trước khi nhận prompt.

SWE-bench, bảng xếp hạng lập trình chính, thực sự đo lường điều gì?#

Để đọc bất kỳ bảng xếp hạng lập trình nào, bạn cần hiểu phép đo chính mà mọi người nhắc đến. Đó là SWE-bench. Nó do các nhà nghiên cứu học thuật tạo ra và được trình bày tại một hội nghị học thuật uy tín. Đây không phải biểu đồ tự làm trên blog.

Bài kiểm tra đơn giản và công bằng. Người ta lấy một dự án thực tế có lỗi thật mà lập trình viên từng sửa. Tác nhân nhận dự án đó cùng mô tả vấn đề bằng ngôn ngữ thông thường. Nó phải hiểu mã của người khác, tìm đúng chỗ và gửi bản vá. Sau đó, hệ thống chạy các bài kiểm thử thực tế của dự án. Nếu bài kiểm thử vượt qua, nhiệm vụ được tính là đã giải quyết. Nếu không, thì không. Không có chuyện “tôi nghĩ là đã sửa”: chỉ có dấu kiểm xanh từ các bài kiểm thử tự động.

Trong toàn bộ 2,294 nhiệm vụ, kết quả thường được công bố cho một tập con được xác minh cẩn thận, gọi là SWE-bench Verified. Tập này có 500 nhiệm vụ được con người xem xét thủ công để bảo đảm chúng không có lỗi hoặc vốn dĩ không thể giải quyết. Phiên bản này được xây dựng cùng OpenAI vào tháng 8 năm 2024, và là phiên bản có tỷ lệ phần trăm xuất hiện trong hầu hết mọi bảng xếp hạng. Khi thấy “X phần trăm trên SWE-bench Verified”, điều đó có nghĩa là tỷ lệ trong 500 nhiệm vụ đó.

Vì sao cùng một AI lại có kết quả khác nhau trong các tác nhân khác nhau?#

Đây là một sự thật lập tức giải quyết được một nửa các cuộc tranh luận trong phần bình luận. Cùng một mô hình tạo ra tỷ lệ phần trăm khác nhau trong các harness khác nhau, và khoảng cách giữa chúng khá rõ rệt.

Bạn có thể thấy điều này trong dữ liệu công khai. Một benchmark đo lường các tác nhân làm việc trong terminal có một bảng công bằng: hai cột riêng cho mô hình và tác nhân. Bảng cũng cho thấy chi phí và mức sử dụng. Các tác giả cố ý thiết kế như vậy để thể hiện rằng kết quả luôn là một cặp: “mô hình cộng tác nhân”. Chỉ có mạng nơ-ron thì chưa đủ để tạo ra điểm số.

Lý do tạo ra chênh lệch sẽ rõ nếu bạn quay lại ba lớp. Một tác nhân cho mô hình mười lần thử mỗi nhiệm vụ, tác nhân khác chỉ cho ba lần. Một tác nhân hiển thị toàn bộ nội dung lỗi, tác nhân khác cắt ngắn nó. Một tác nhân cho phép chạy kiểm thử và tiếp tục sửa cho đến khi mọi thứ hoạt động, tác nhân khác dừng lại sau bản vá đầu tiên. Mạng nơ-ron vẫn vậy, nhưng điều kiện làm việc khác nhau nên tỷ lệ phần trăm cũng khác.

Kết luận thực tế cho bạn rất đơn giản. Nếu thấy “Claude giải quyết 77 phần trăm”, đó là Claude trong một harness cụ thể với cấu hình cụ thể. Đặt cùng mô hình vào tác nhân khác sẽ cho một con số khác. Vì vậy, “mô hình thông minh” và “tổ hợp giải quyết được nhiệm vụ” là những nhận định về hai thứ khác nhau.

Chi phí để giải quyết một nhiệm vụ là bao nhiêu?#

Giờ là chuyện tiền bạc, vì hầu hết tranh luận bắt đầu từ đây. Mọi người so sánh giá thuê bao: tác nhân này tốn 20 đô la một tháng, tác nhân kia 200 đô la. Rồi họ kết luận: “Cái đầu tiên rẻ hơn.” Kết luận đó sai, vì thuê bao không cho biết kết quả.

Giá thuê bao cho bạn biết rất ít trong trường hợp này. Bạn cần tính chi phí của một nhiệm vụ mà tác nhân thực sự hoàn thành thành công. Bạn trả tiền cho token — những mẩu văn bản được trao đổi giữa bạn và mô hình. Mô hình đọc và viết càng nhiều thì dùng càng nhiều token và hóa đơn càng cao. Các công ty công khai giá token. Ví dụ, đây là thông tin Anthropic đưa ra về mô hình Sonnet:

Tiếp theo là phép tính cho thấy vì sao giá niêm yết thấp có thể gây hiểu lầm. Hãy lấy hai mô hình. Mô hình thứ nhất có giá mỗi token cao hơn nhưng giải quyết nhiệm vụ ngay lần thử đầu. Mô hình thứ hai rẻ hơn nhưng thử mười lần, mỗi lần đọc lại toàn bộ dự án. Cuối cùng, mô hình có giá niêm yết thấp hơn lại dùng nhiều token hơn và tạo ra hóa đơn cao hơn mô hình đắt tiền. Tôi giải thích chi tiết những yếu tố cấu thành chi phí làm việc với AI trong bài tác nhân AI cho doanh nghiệp tốn bao nhiêu và, riêng biệt, bài cách tính giá cho các công cụ vibe-coding.

Các bảng xếp hạng tốt hiểu điều này và hiển thị chi phí bên cạnh tỷ lệ phần trăm: đã tiêu tốn bao nhiêu tiền cho tất cả nhiệm vụ. Hãy chú ý điều đó. Một tác nhân giải quyết 75 phần trăm với chi phí một đô la mỗi nhiệm vụ thường là lựa chọn tốt hơn cho bạn so với tác nhân đạt 78 phần trăm với chi phí ba đô la mỗi nhiệm vụ.

Vì sao tốc độ cũng là một phần của bảng xếp hạng?#

Điều thứ ba thường bị bỏ quên sau các tỷ lệ phần trăm là thời gian. Nếu làm việc với tác nhân mỗi ngày, thời gian quan trọng không kém chi phí.

Đây là điểm mấu chốt. Độ chính xác và tốc độ kéo theo hai hướng ngược nhau. Muốn giải quyết nhiều nhiệm vụ hơn, bạn cho tác nhân thêm thời gian “suy nghĩ” và thêm lượt thử: nó thử các lựa chọn khác nhau, chạy kiểm thử và chỉnh sửa kết quả. Tỷ lệ phần trăm tăng, thời gian phản hồi cũng tăng. Với một lần sửa duy nhất, chênh lệch giữa một phút và mười phút hầu như không đáng kể. Nhưng nếu dành cả buổi tối làm việc với tác nhân, giao nhiệm vụ này nối tiếp nhiệm vụ khác, những phút đó cộng dồn thành hàng giờ chờ trước màn hình.

Đó là lý do tốc độ có hai mặt trong bảng xếp hạng. Vị trí đầu về độ chính xác thường đồng thời là lựa chọn chậm nhất và đắt nhất — nó được đẩy lên mức cài đặt tối đa để có con số đẹp. Nhưng với công việc hằng ngày, bạn có thể cần một tổ hợp thấp hơn một chút trong bảng nhưng nhanh và rẻ hơn gấp ba lần. Điều gì quan trọng hơn tùy thuộc vào nhiệm vụ của bạn, và bảng xếp hạng không thể chọn thay bạn.

Vì sao chênh lệch vài điểm phần trăm thường chỉ là nhiễu#

Một cái bẫy khác của bảng xếp hạng là tin rằng vị trí thứ nhất thực sự tốt hơn vị trí thứ ba. Thường chênh hai hoặc ba điểm phần trăm, tức 10 tới 15 việc trên 500; diễn giải tùy mẫu và biến động giữa lượt. Chạy lại cùng phép thử, các ứng viên dẫn đầu có thể đổi vị trí vì mô hình không đưa ra chính xác cùng một câu trả lời mỗi lần.

Phép đo trung thực hiện bất định bên cạnh điểm. “Râu” có thể là khoảng tin cậy 95 phần trăm; xem định nghĩa benchmark. Chồng lấp không chứng minh hai tác nhân bằng nhau và không tự quyết ý nghĩa thống kê của chênh. Cần so chênh bằng cách phù hợp, xét cỡ mẫu và biến động, tốt nhất giữ ghép cặp khi cả hai thử cùng việc.

Không dùng ngưỡng ba điểm phần trăm chung để tuyên bố hòa. Khoảng nhỏ có thể có nghĩa hoặc chưa kết luận tùy mẫu, lượt lặp và phương pháp. Xem bất định cùng phí, tốc độ, khả dụng rồi thử nhóm dẫn đầu trên việc mình.

Ai đang dẫn đầu ở các benchmark khác nhau tại thời điểm viết bài?#

Giờ hãy đến với những con số, cùng một lưu ý quan trọng. Bất kỳ tỷ lệ phần trăm cụ thể nào cũng có thời hạn sử dụng ngắn. Một phiên bản mô hình mới ra mắt hoặc một tác nhân được cập nhật, và một tuần sau bảng đã khác. Vì vậy, đừng ghi nhớ con số; hãy nắm quy mô tương đối và học cách tự kiểm tra.

Theo tuyên bố chính thức của chính các công ty, đây là bức tranh về 500 nhiệm vụ SWE-bench đã xác minh. OpenAI viết về mô hình GPT-5 của mình:

Anthropic báo cáo các con số tương tự cho mô hình của mình. Với Claude Opus 4.1, hãng báo cáo 74.5 phần trăm trên cùng benchmark SWE-bench Verified. Với Claude Sonnet 4.5 mới hơn, hãng báo cáo trung bình 77.2 phần trăm qua mười lần chạy, và lên đến 82 phần trăm nếu cho mô hình thử nhiều lần rồi chọn lần tốt nhất.

Bạn thấy điều gì đang diễn ra không? Các tổ hợp dẫn đầu từ những công ty khác nhau nằm trong một khoảng hẹp: khoảng 74–77 phần trăm. Khoảng cách giữa chúng chỉ là vài điểm phần trăm như vậy, thường nằm trong biên sai số. Vì thế, “ai đứng đầu” phụ thuộc vào tuần benchmark được chạy và cấu hình. Điều quan trọng hơn là cả nhóm dẫn đầu đều làm được những việc gần tương đương, và bạn nên chọn trong nhóm đó dựa trên chi phí, tốc độ và việc công cụ có sẵn cho bạn hay không.

Còn một chi tiết nữa được các công ty ghi chú bằng chữ nhỏ nhưng lại quan trọng. Kết quả GPT-5 không được tính trên toàn bộ 500 nhiệm vụ:

Điều đó có nghĩa 74.9 phần trăm là tỷ lệ trên 477 nhiệm vụ, chứ không phải toàn bộ 500. Chi tiết nhỏ ư? Không. Đây chính là lý do hai bảng xếp hạng trung thực có thể đưa ra các con số khác nhau cho cùng một mô hình. Phần tiếp theo giải thích cần chú ý điều gì trong các chú thích này.

Cách đọc bất kỳ bảng xếp hạng nào trong năm phút: danh sách kiểm tra#

Sau đây là một chuỗi bước ngắn. Mở bất kỳ bảng xếp hạng tác nhân AI nào và lần lượt trả lời sáu câu hỏi sau.

1. Đây là benchmark nào? SWE-bench Verified hay thứ gì khác. Nếu không nêu tên benchmark, hãy đóng trang; đó là biểu đồ được tạo ra để khơi mào tranh cãi.
2. Tổ hợp nào? Chỉ nói “Claude” là chưa đủ; bạn cần biết “phiên bản Claude này trong harness này”. Thiếu một trong hai phần thì tỷ lệ phần trăm cũng lơ lửng giữa không trung.
3. Đã tính bao nhiêu nhiệm vụ? Toàn bộ 500 hay chỉ một tập con, như ví dụ GPT-5 với 477 nhiệm vụ. Tập nhỏ hơn làm con số tăng lên.
4. Được phép thử bao nhiêu lần? Một lần thử công bằng hơn “thử mười lần rồi lấy kết quả tốt nhất”. Cách thứ hai trông có vẻ tốt hơn, nhưng ngoài đời không ai làm việc như vậy.
5. Chi phí là bao nhiêu? Có cột chi phí bên cạnh tỷ lệ phần trăm không? Nếu không, một nửa bức tranh đang bị che khuất.
6. Có hiện độ phân tán không? “Râu” nghĩa gì, từ bao nhiêu việc/lượt, có so chênh đúng cách không? Chồng lấp hay khoảng ba điểm cố định đều chưa chứng minh hòa.

Làm theo sáu bước này, bất kỳ tiêu đề ồn ào nào cũng sẽ đứng vững hoặc sụp đổ trong năm phút. Cũng nên nhớ rằng ngay cả khi vượt qua bài kiểm tra, kết quả trên dự án của bạn vẫn không được đảm bảo: tôi giải thích lý do trong bài vì sao tác nhân AI nói “xong rồi” dù công việc chưa xong.

Thông tin sai lệch về bảng xếp hạng bắt nguồn từ đâu: nhiệm vụ cũ trong dữ liệu huấn luyện?#

Còn một lý do nữa để không tôn sùng các tỷ lệ phần trăm, và những người tạo benchmark thẳng thắn nói về điều đó. Các nhiệm vụ SWE-bench đến từ những dự án công khai đã tồn tại trên mạng nhiều năm. Mạng nơ-ron lại được huấn luyện bằng internet. Điều này có nghĩa mô hình có thể đã bắt gặp chính những dự án ấy và các bản sửa lỗi có sẵn trong quá trình huấn luyện.

Điều đó có ý nghĩa gì trong thực tế? Mô hình không tự giải quyết một số nhiệm vụ được cho là đã “giải quyết”; nó nhớ lại câu trả lời có sẵn. Nó đã thấy câu trả lời đó trong quá trình huấn luyện và chỉ tái tạo lại. Tỷ lệ phần trăm ấy thể hiện trí nhớ. Nó không nói gì về khả năng hiểu mã mới. OpenAI công khai thừa nhận rủi ro này đối với SWE-bench.

Đây là điều người đọc cần ghi nhớ. Nhiệm vụ càng mới và càng có nhiều nhiệm vụ kín mà mô hình chắc chắn chưa từng thấy thì phép đo càng công bằng. Đó là lý do các benchmark mới có bài kiểm tra ẩn đáng tin hơn những bộ dữ liệu mở cũ mà mọi người đã luyện tập. Khi chọn giữa hai bảng xếp hạng, hãy ưu tiên bảng sử dụng nhiệm vụ mới và có một số nhiệm vụ được giấu khỏi mô hình.

Nên chọn tác nhân AI nào cho nhiệm vụ của bạn?#

Hãy tổng hợp mọi thứ thành một lựa chọn thực tế. Không có người chiến thắng phù hợp với tất cả, vì vậy hãy xem xét nhiệm vụ của riêng bạn.

Nếu dự án phức tạp, có cơ sở mã lớn và sẽ kéo dài, hãy chọn một mô hình mạnh trong một harness hoàn thiện. Trong số các tổ hợp gần đầu bảng có Claude Code của Anthropic với các mô hình Opus và Sonnet, cùng Codex của OpenAI với các mô hình thuộc dòng GPT-5. Đây là những tác nhân sẵn sàng sử dụng, mọi thứ đã được cấu hình và chúng xử lý ổn định các nhiệm vụ khó. Chúng tốn nhiều token hơn nhưng cần ít công sức thiết lập hơn.

Nếu nhiệm vụ đơn giản — sửa văn bản, dựng một trang nhỏ hoặc viết script — thì không cần trả thêm tiền cho mô hình hàng đầu. Các mô hình đơn giản, rẻ hơn có thể xử lý mà không tạo khác biệt về kết quả, và hóa đơn sẽ thấp hơn nhiều lần.

Nếu cần thứ gì đó miễn phí chạy cục bộ, hãy xem các tác nhân mở như Cline, Aider và OpenHands. Chúng không có mô hình riêng; bạn kết nối một mô hình bằng khóa của mình. Chúng linh hoạt, nhưng bạn sẽ phải tự cấu hình. Cursor là một trình soạn thảo riêng có tích hợp tác nhân; nó có thể làm việc với mô hình của nhiều công ty khác nhau và bạn chọn mô hình phù hợp với nhiệm vụ. Tôi bàn về những nhiệm vụ nào doanh nghiệp thực sự có thể giao cho tác nhân trong bài những nhiệm vụ kinh doanh nào thực sự có thể giao cho tác nhân AI.

Câu hỏi thường gặp#

Khi sẵn sàng, hãy tìm hiểu Ailoot.