Benchmark Claude Code "solo" vs đội 3 agent: đa agent chậm gần gấp đôi, rẻ hơn một chút, nhưng thắng ở task bảo mật lớn

Một lập trình viên vừa công bố kết quả đo đạc khá hiếm hoi: cho Claude Code làm một mình đấu trực tiếp với một "đội" 3 agent — Claude làm trưởng nhóm điều phối, agent giá rẻ pi viết code, Codex review độc lập — trên cùng một dự án Rust, cùng một commit gốc, và chấm điểm bằng blind review. Kết quả đi ngược kỳ vọng của nhiều người: workflow nhiều agent không nhanh hơn, thậm chí chậm gần gấp đôi; tiền tiết kiệm được mỏng hơn tưởng tượng; nhưng ở bài toán bảo mật lớn nhất, bản của đội agent lại là bản duy nhất được duyệt.

Trả lời nhanh

• Về tốc độ: đội nhiều agent chậm hơn ở cả 3 bài test — task nhỏ 28 phút so với 19 phút, task vừa 16,1 so với 8,7 phút, task lớn 66,2 so với 30,5 phút (tức chậm gần gấp đôi ở hai bài sau).
• Về chi phí: giao việc viết code cho model giá rẻ giúp giảm chi phí Claude khoảng 25% (task vừa: 1,54 USD so với 2,05 USD) và 15% (task lớn: 3,30 USD so với 3,90 USD) — nhưng con số này chưa tính chi phí các lượt Codex review mà nhánh đa agent dùng nhiều gấp 2–3 lần.
• Về chất lượng: hai bài nhỏ và vừa, cả hai bên đều được blind review duyệt (APPROVE). Ở bài lớn đụng tới MFA, bản của đội agent được APPROVE, còn bản Claude tự làm bị đánh CHANGES_REQUIRED vì lọt một lỗi lệch hợp đồng OpenAPI.
• Cỡ mẫu rất nhỏ: toàn bộ kết luận rút từ 3 cặp thử nghiệm trên một dự án của chính tác giả Brian Ng — tác giả cũng tự nhấn mạnh đây mới là "tín hiệu ban đầu", chưa phải kết luận chắc chắn.
• Chiến lược tác giả đang dùng: phân tầng theo rủi ro — task nhỏ cho Claude làm một mình, task thường giao agent rẻ viết code kèm 1 lượt review, task đụng auth/database/API công khai thì bắt buộc 2 lượt review độc lập.

Bài benchmark này đo cái gì, đo như thế nào?

Đây là phép đo so sánh hai cách tổ chức công việc cho AI coding agent trên cùng một dự án Rust có sẵn:

• Nhánh solo: một mình Claude Code (theo cấu hình tác giả ghi: Opus 5.5, mức Medium) tự đọc hiểu yêu cầu, tự viết code, tự kiểm tra.
• Nhánh đội: Claude Code đóng vai trưởng nhóm (Tech Lead), agent pi chạy model giá rẻ (DeepSeek V4.1 Flash, mức High) làm dev chính viết code, và Codex (GPT-6.1 Sol, mức High) làm reviewer độc lập soi lỗi chéo. Toàn bộ quá trình được tác giả quan sát trực tiếp qua giao diện Herdr TUI.

Phương pháp đo được thiết kế để hạn chế thiên vị — điểm khiến benchmark này đáng đọc hơn mặt bằng chung:

• Cùng điểm xuất phát: mỗi bài toán được tách từ cùng một commit gốc ra hai worktree độc lập, phiên làm việc hoàn toàn mới cho mỗi nhánh.
• Khóa bằng "hợp đồng" (task contract): để tránh cảnh agent "tự làm tự khen", mỗi task đều có contract ghi rõ mục tiêu, danh sách file được phép sửa và lệnh chạy test; worker báo xong vẫn chưa đủ — code bắt buộc phải vượt qua một script kiểm tra tự động (gate) mới được tính là hoàn thành.
• Chấm mù (blind review): hai bản patch được ẩn danh thành "Bản X" và "Bản Y", đưa cho reviewer đánh giá mà không biết bản nào do ai viết.
• Lưu ý công bằng: chỉ Cặp 1 là Claude solo 100%. Ở Cặp 2 và 3, nhánh Claude làm một mình vẫn có thêm một bước Codex review ở cuối, nên hai cặp sau thực chất đo câu hỏi hẹp hơn: đẩy phần gõ code sang model giá rẻ thì lời bao nhiêu tiền, mất bao nhiêu thời gian? Chi phí được quy đổi từ log token theo bảng giá niêm yết để so sánh tương đối.

Đội hình 3 agent gồm những ai?

Vai trò	Agent / model (theo tác giả)	Nhiệm vụ
Tech Lead	Claude Code (Opus 5.5 – Medium)	Đọc hiểu yêu cầu, viết task contract, điều phối và nghiệm thu kết quả
Dev chính	pi (DeepSeek V4.1 Flash – High)	Trực tiếp viết code, rà tài liệu, chạy test — chọn vì chi phí rẻ
Reviewer độc lập	Codex (GPT-6.1 Sol – High)	Cố vấn và soi lỗi chéo, không tham gia viết code

Kết quả qua 3 cấp độ khó

Cặp	Bài toán	Thời gian: đội vs solo	Chi phí: đội vs solo	Blind review
1	Thêm trường version vào health endpoint (nhỏ)	~28 phút vs 19 phút	Claude tốn hơn cả khi solo (24.737 vs 22.232 output token)	Cả hai APPROVE
2	Thêm lệnh CLI quản trị, sửa 6 file, ~400–500 dòng (vừa)	16,1 vs 8,7 phút	1,54 USD vs 2,05 USD (−25%)	Cả hai APPROVE
3	Xem và gỡ khóa MFA, ~25 file, nhạy cảm bảo mật (lớn)	66,2 vs 30,5 phút	3,30 USD vs 3,90 USD (−15%)	Đội: APPROVE — Solo: CHANGES_REQUIRED

Đọc kỹ từng cặp sẽ thấy bức tranh không đơn giản là "đội thua":

• Cặp 1 — task nhỏ thì chia việc là lỗ. Chi phí điều phối vượt xa giá trị bài toán; lượt chạy đội còn gặp trục trặc hạ tầng khiến tác giả phải gõ lệnh nhắc thêm, đội số liệu lên. Điểm cộng duy nhất: quy trình nhiều bước giúp reviewer bắt được một chỗ thiếu unit test mà bên solo bỏ qua.
• Cặp 2 — tiền bắt đầu giảm, thời gian vẫn thua. Khi Claude chỉ điều phối, lượng output token của nó giảm mạnh từ 33.009 xuống 18.730. Cả hai bản đều chạy tốt, nhưng model của pi yếu hơn nên phải qua 2 vòng review mới xong — vòng đầu Codex bắt được một bug logic thật mà pi bỏ sót.
• Cặp 3 — bài toán phân định thắng thua. Về logic bảo mật cốt lõi, hai bên ngang nhau. Khác biệt nằm ở khâu review: bản solo để lọt một lỗi sai lệch hợp đồng OpenAPI qua được review nội bộ, chỉ bị bắt ở vòng blind review cuối; ngược lại bản của pi bị chặn 2 lỗi nghiêm trọng ngay vòng review đầu, bị ép sửa kỹ qua nhiều vòng nên bản cuối lại sạch hơn. Tác giả đã mang bản của đội pi chạy thử trên server thật: mọi kịch bản đều mượt, trừ luồng OIDC chưa kịp kiểm thử. Output token của Claude ở cặp này giảm từ 63.439 xuống 37.595, đỉnh ngữ cảnh (peak context) hạ từ 240.402 xuống 183.060 token.

Ba kết luận đáng giá nhất

1. Giao việc cho model rẻ không tự động làm giảm chi phí

Dù đã nhường phần gõ code cho pi, Claude vẫn "ngốn" phần lớn chi phí. Ở Cặp 3, tới 77% lượng dữ liệu Claude đọc nằm ở giai đoạn trước khi giao việc — nó phải đọc hết codebase mới đủ thông tin viết task contract. Khối dữ liệu đó sau đó nằm lại trong cửa sổ ngữ cảnh, khiến mọi lượt hội thoại về sau đều phải trả tiền đọc lại. Cộng thêm việc nhánh pi tiêu tốn số lượt Codex review gấp 2–3 lần nhánh solo (chưa được tính vào con số tiết kiệm 15–25%), khoản lời thực tế mỏng hơn nhiều so với kỳ vọng ban đầu.

2. Một lượt AI review là không đủ cho tính năng nhạy cảm

Cùng một model, cùng một mẫu prompt, nhưng reviewer này cho qua lỗi mà reviewer khác bắt được — hiện tượng xuất hiện ngay trong 3 cặp test. Với các phần đụng tới xác thực (auth), cấu trúc dữ liệu, migration hay API công khai, tác giả hiện bắt buộc 2 lượt review độc lập trên đúng bản code cuối cùng trước khi merge.

3. Thêm agent là thêm gánh nặng vận hành

Càng nối nhiều công cụ, điểm gãy càng nhiều: từ script hook, đến cảnh agent báo "đã xong" trong khi thực chất đang treo ở một thông báo ngầm — mỗi lỗi lặt vặt đều từng làm hỏng một lượt chạy của tác giả. Ngay cả script kiểm tra tự động (gate) do chính tác giả viết cũng có bug, phải nhờ Codex review qua 7 vòng mới vá hết.

Chiến lược tác giả đang áp dụng: chia theo mức rủi ro

Vì ưu tiên độ an toàn của code và chi phí hơn tốc độ chờ, tác giả vẫn giữ workflow nhiều agent làm mặc định — nhưng phân tầng thay vì áp dụng máy móc:

• Task nhỏ, vị trí sửa đã rõ: Claude làm một mình, tối đa 1 lượt review độc lập, bỏ qua bước dò codebase rườm rà.
• Task tính năng thông thường: giao toàn bộ phần dò codebase và viết code cho pi, kèm 1 lượt review.
• Task đụng auth, database hoặc API công khai: Codex kiểm tra chéo ngay từ bản thiết kế contract, sau đó 2 lượt review độc lập ở đầu ra.

Hướng tinh chỉnh tiếp theo đang được tác giả thử nghiệm: cấm Claude tự đọc code trực tiếp quá nhiều, đẩy phần trinh sát sang agent rẻ hơn với mục tiêu cắt thêm ít nhất 30% chi phí; đồng thời cân nhắc hạ cấp model điều phối từ Opus xuống Sonnet để giảm một nửa giá — kết quả đo lại sẽ được cập nhật sau.

Giới hạn của benchmark này

Để tránh đọc kết quả quá tay, cần giữ rõ các giới hạn mà chính tác giả thừa nhận hoặc thể hiện trong cách đo:

• Cỡ mẫu n=3 trên một dự án Rust duy nhất và một người vận hành duy nhất — đủ để rút tín hiệu, không đủ để tổng quát hóa cho mọi đội, mọi ngôn ngữ.
• Nhánh solo không hoàn toàn "solo" ở Cặp 2 và 3 vì có thêm Codex review cuối, nên phép so sánh ở hai cặp này là "ai gõ code" chứ không phải "có hay không có review".
• Số liệu Cặp 1 bị nhiễu bởi sự cố hạ tầng giữa chừng (phải nhắc agent bằng tay), làm thời gian và token đội lên.
• Chi phí là quy đổi tương đối từ log token theo bảng giá niêm yết của model đắt nhất, chưa tính đủ chi phí Codex ở mọi vòng review của nhánh đội.

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

Dùng nhiều AI agent có nhanh hơn một agent không?

Theo đo đạc này: không. Cả 3 bài test, đội nhiều agent đều chậm hơn — từ 1,5 đến hơn 2 lần — vì thời gian điều phối, giao việc, review qua lại và xử lý sự cố hạ tầng ăn hết lợi thế song song. Đa agent đổi tốc độ lấy chất lượng kiểm chứng và một phần chi phí.

Vì sao giao cho model rẻ mà chỉ tiết kiệm được 15–25%?

Vì phần đắt nhất không nằm ở gõ code mà ở đọc hiểu: model điều phối phải nạp gần như toàn bộ codebase để viết task contract cho đúng (77% lượng đọc ở Cặp 3 diễn ra trước khi giao việc), và dữ liệu đó tiếp tục bị tính tiền trong mọi lượt hội thoại sau vì nằm trong cửa sổ ngữ cảnh.

Blind review trong benchmark này là gì?

Là cách chấm điểm khách quan: hai bản patch của cùng một bài toán được ẩn danh (Bản X, Bản Y) và đưa cho reviewer đánh giá mà không biết tác giả là nhánh solo hay nhánh đội — tránh thiên vị theo "thương hiệu" của model viết ra nó.

Khi nào nên dùng workflow nhiều agent?

Khi bài toán đủ lớn hoặc đủ nhạy cảm để chi phí review là xứng đáng: tính năng đụng auth, database, migration, API công khai. Ngược lại, task nhỏ và vị trí sửa đã rõ ràng thì một agent mạnh làm một mình, kèm tối đa một lượt review độc lập, là lựa chọn kinh tế hơn hẳn.

Task contract và "gate" tự động có tác dụng gì?

Contract khóa phạm vi công việc (mục tiêu, file được phép sửa, lệnh test) để agent không lan man và không tự tuyên bố hoàn thành; còn script gate là cổng kiểm tra máy móc mà code bắt buộc phải vượt qua trước khi được tính là xong — hai cơ chế chống lại thói quen "tự làm tự khen" của AI agent.

Kết luận

Giá trị của benchmark này không nằm ở con số thắng thua, mà ở cách nó bóc trần ba sự thật ít được nói ra trong các bài ca ngợi multi-agent: điều phối có giá của nó, model rẻ không làm hóa đơn rẻ đi một cách thần kỳ, và chất lượng thật sự đến từ nhiều lớp review độc lập chứ không phải từ số lượng agent. Với các đội đang xây workflow AI để lập trình, công thức phân tầng theo rủi ro của tác giả — nhỏ thì solo, lớn và nhạy cảm thì nhiều lớp kiểm chứng — là một điểm khởi đầu thực tế hơn nhiều so với việc "cái gì cũng đa agent".

Nguồn: bài benchmark của Brian Ng trên Facebook (03/11/2026), biên tập và hệ thống hóa bởi Wotech Electronics. Mọi số liệu trong bài là kết quả đo của tác giả trên dự án cá nhân, không phải số liệu chính thức từ các nhà cung cấp model.