Mười sáu tác nhân AIClaude cùng nhau tạo ra một trình biên dịch C mới.

Tác giả dangkhoa 23/02/2026 20 phút đọc

Mười sáu tác nhân AI Claude cùng nhau tạo ra một trình biên dịch C mới.

Thí nghiệm trị giá 20.000 đô la đã biên dịch được nhân Linux nhưng cần sự quản lý chuyên sâu của con người.

Nguồn ảnh: akinbostanci qua Getty Images

Trong bối cảnh xu hướng phát triển các tác nhân AI đang diễn ra mạnh mẽ , với việc cả Anthropic và OpenAI đều tung ra các công cụ đa tác nhân trong tuần này, Anthropic đã sẵn sàng giới thiệu một số thử nghiệm lập trình AI táo bạo hơn của mình. Nhưng như thường lệ với những tuyên bố về thành tựu liên quan đến AI, bạn sẽ thấy một số lưu ý quan trọng phía trước.

Hôm thứ Năm, nhà nghiên cứu Nicholas Carlini của Anthropic đã đăng một bài viết trên blog mô tả cách ông thả 16 phiên bản của mô hình AI Claude Opus 4.6 của công ty vào một cơ sở mã chung với sự giám sát tối thiểu, giao nhiệm vụ cho chúng xây dựng một trình biên dịch C từ đầu.

Trong hơn hai tuần và gần 2.000 phiên Claude Code với chi phí khoảng 20.000 đô la phí API, các tác nhân mô hình AI được cho là đã tạo ra một trình biên dịch dựa trên Rust gồm 100.000 dòng, có khả năng xây dựng nhân Linux 6.9 có thể khởi động trên các kiến trúc x86, ARM và RISC-V.

Carlini, một nhà khoa học nghiên cứu thuộc nhóm Bảo vệ của Anthropic, người trước đây đã có bảy năm làm việc tại Google Brain và DeepMind, đã sử dụng một tính năng mới được ra mắt cùng với Claude Opus 4.6 có tên là “ nhóm tác nhân ”. Trên thực tế, mỗi phiên bản Claude chạy bên trong một container Docker riêng, sao chép một kho lưu trữ Git được chia sẻ, nhận nhiệm vụ bằng cách ghi các tệp khóa, sau đó đẩy mã đã hoàn thành trở lại kho lưu trữ gốc. Không có tác nhân điều phối nào điều khiển lưu lượng truy cập. Mỗi phiên bản độc lập xác định vấn đề nào có vẻ rõ ràng nhất cần giải quyết tiếp theo và bắt đầu giải quyết nó. Khi xảy ra xung đột hợp nhất, các phiên bản mô hình AI sẽ tự giải quyết chúng.

Trình biên dịch này, được Anthropic phát hành trên GitHub , có thể biên dịch một loạt các dự án mã nguồn mở lớn, bao gồm PostgreSQL, SQLite, Redis, FFmpeg và QEMU. Nó đạt tỷ lệ vượt qua 99% trong bộ kiểm thử khắc nghiệt GCC và, trong cái mà Carlini gọi là “bài kiểm tra cuối cùng dành cho nhà phát triển”, đã biên dịch và chạy Doom .

Điều đáng chú ý là trình biên dịch C là một nhiệm vụ gần như lý tưởng cho việc lập trình mô hình AI bán tự động: Đặc tả đã có từ nhiều thập kỷ trước và được định nghĩa rõ ràng, các bộ kiểm thử toàn diện đã tồn tại, và có một trình biên dịch tham chiếu tốt đã được biết đến để kiểm tra. Hầu hết các dự án phần mềm thực tế không có được những lợi thế này. Phần khó khăn nhất trong hầu hết quá trình phát triển không phải là viết mã vượt qua các bài kiểm thử; mà là tìm ra những bài kiểm thử nào cần thực hiện ngay từ đầu.

Trình biên dịch này cũng có những hạn chế rõ ràng mà Carlini đã thẳng thắn thừa nhận. Nó thiếu phần phụ trợ x86 16-bit cần thiết để khởi động Linux từ chế độ thực, vì vậy nó phải gọi đến GCC cho bước đó. Trình hợp dịch và trình liên kết của chính nó vẫn còn nhiều lỗi. Ngay cả khi bật tất cả các tối ưu hóa, nó vẫn tạo ra mã kém hiệu quả hơn so với GCC chạy với tất cả các tối ưu hóa bị tắt. Và chất lượng mã Rust, mặc dù hoạt động được, nhưng không thể đạt đến chất lượng mà một lập trình viên Rust chuyên nghiệp sẽ tạo ra. “Trình biên dịch cuối cùng gần như đã đạt đến giới hạn khả năng của Opus,” Carlini viết. “Tôi đã cố gắng (rất nhiều!) để khắc phục một số hạn chế nêu trên nhưng không hoàn toàn thành công. Các tính năng mới và các bản sửa lỗi thường xuyên làm hỏng chức năng hiện có.”

Những hạn chế đó thực ra có thể cung cấp nhiều thông tin hơn cả những thành công. Carlini báo cáo rằng vào giai đoạn cuối của dự án, việc sửa lỗi và thêm tính năng "thường xuyên làm hỏng các chức năng hiện có", một mô hình quen thuộc với bất kỳ ai đã từng chứng kiến một codebase phát triển vượt quá điểm mà bất kỳ người đóng góp nào cũng hiểu rõ về nó.

Và hạn chế đó thậm chí còn phổ biến hơn khi xử lý các tác nhân lập trình AI, vốn mất đi tính nhất quán theo thời gian. Mô hình đã gặp phải giới hạn này ở khoảng 100.000 dòng mã, điều này cho thấy một giới hạn thực tế đối với việc lập trình tự động của tác nhân, ít nhất là với các mô hình hiện tại.

Công sức của con người đằng sau quá trình tự động hóa.

Anthropic mô tả trình biên dịch này là một "phiên bản được phát triển trong môi trường sạch" vì các tác nhân không có quyền truy cập Internet trong quá trình phát triển. Nhưng cách diễn đạt đó có phần gây hiểu lầm. Mô hình cơ bản được huấn luyện trên một lượng lớn mã nguồn công khai, gần như chắc chắn bao gồm GCC, Clang và nhiều trình biên dịch C nhỏ hơn khác. Trong phát triển phần mềm truyền thống, "môi trường sạch" đặc biệt có nghĩa là những người triển khai chưa bao giờ nhìn thấy mã nguồn gốc. Theo tiêu chuẩn đó, đây không phải là một môi trường như vậy.

Trên Hacker News, sự phân biệt này đã gây ra cuộc tranh luận gay gắt, phản ánh sự đón nhận trái chiều đối với tin tức này trong giới lập trình viên. "Đó giống như một nỗ lực dùng vũ lực để giải mã những kiến thức được lưu trữ một cách mơ hồ trong mạng lưới," một người bình luận viết .

Con số 20.000 đô la cũng cần được xem xét trong bối cảnh cụ thể. Con số đó chỉ bao gồm chi phí mã thông báo API và không bao gồm hàng tỷ đô la đã chi cho việc huấn luyện mô hình, công sức của con người mà Carlini đã đầu tư vào việc xây dựng nền tảng, và hàng thập kỷ làm việc của các kỹ sư biên dịch, những người đã tạo ra các bộ kiểm thử và các triển khai tham chiếu giúp dự án khả thi.

Và việc xây dựng khung sườn đó không hề đơn giản, điều này khiến bất kỳ tuyên bố nào về việc các tác nhân AI tự động hóa quá trình biên dịch C đều trở nên đáng ngờ. Mặc dù kết quả nổi bật là một trình biên dịch được viết mà không cần lập trình song song giữa người và máy tính, nhưng phần lớn công việc thực sự giúp dự án hoạt động lại liên quan đến việc thiết kế môi trường xung quanh các tác nhân mô hình AI hơn là viết trực tiếp mã biên dịch. Carlini đã dành nhiều công sức để xây dựng các bộ công cụ kiểm thử, các quy trình tích hợp liên tục và các hệ thống phản hồi được tinh chỉnh cho các cách thức cụ thể mà các mô hình ngôn ngữ gặp lỗi.

Ví dụ, ông nhận thấy rằng đầu ra kiểm thử quá chi tiết làm rối loạn cửa sổ ngữ cảnh của mô hình, khiến nó mất dấu những gì đang thực hiện. Để giải quyết vấn đề này, Carlini đã thiết kế các trình chạy thử nghiệm chỉ in ra một vài dòng tóm tắt và ghi chi tiết vào các tệp riêng biệt.

Ông cũng phát hiện ra rằng Claude không có khái niệm về thời gian và sẽ dành hàng giờ để chạy thử nghiệm mà không có tiến triển gì, vì vậy ông đã xây dựng một chế độ nhanh chỉ lấy mẫu từ 1% đến 10% các trường hợp thử nghiệm. Khi cả 16 tác nhân đều gặp khó khăn trong việc sửa cùng một lỗi nhân Linux đồng thời, ông đã sử dụng GCC làm công cụ tham chiếu, biên dịch ngẫu nhiên hầu hết các tệp nhân bằng GCC và chỉ một tập hợp con bằng trình biên dịch của Claude, để mỗi tác nhân có thể xử lý các lỗi khác nhau trong các tệp khác nhau.

Carlini viết: “Claude sẽ tự động giải quyết bất kỳ vấn đề nào tôi giao cho nó. Vì vậy, điều quan trọng là bộ kiểm chứng nhiệm vụ phải gần như hoàn hảo, nếu không Claude sẽ giải quyết sai vấn đề.”

Tất cả những điều này không nên làm lu mờ những gì dự án thực sự chứng minh. Một năm trước, không có mô hình ngôn ngữ nào có thể tạo ra một trình biên dịch đa kiến trúc hoạt động hiệu quả, ngay cả với sự hỗ trợ tận tình và ngân sách không giới hạn như thế này. Phương pháp phối hợp giữa các tác nhân song song thông qua Git với sự giám sát tối thiểu của con người là một điều mới mẻ, và các thủ thuật kỹ thuật mà Carlini đã phát triển để duy trì hiệu quả hoạt động của các tác nhân (đầu ra kiểm thử dựa trên ngữ cảnh, giới hạn thời gian, công cụ GCC để song song hóa) có tiềm năng đóng góp hữu ích cho việc sử dụng rộng rãi hơn các công cụ phát triển phần mềm dựa trên tác nhân.

Chính Carlini thừa nhận cảm thấy mâu thuẫn về kết quả của mình. Ông viết: “Việc xây dựng trình biên dịch này là một trong những điều thú vị nhất mà tôi từng làm gần đây, nhưng tôi không ngờ điều này lại có thể thực hiện được sớm như vậy vào năm 2026”. Ông cũng nêu lên những lo ngại xuất phát từ kinh nghiệm trước đây trong lĩnh vực kiểm thử xâm nhập, lưu ý rằng “việc các lập trình viên triển khai phần mềm mà họ chưa từng tự mình kiểm chứng là một mối lo ngại thực sự”.