Xây dựng trình biên dịch C bằng đội ngũ Claude chạy song song

 (anthropic.com)
8 điểm bởi GN⁺ 2026-02-06 | 2 bình luận | Chia sẻ qua WhatsApp
  • 16 agent Claude đã hợp tác song song để hoàn thiện trình biên dịch C dựa trên Rust, đạt tới mức có thể build kernel Linux 6.9
  • Với khoảng 2.000 phiên làm việc và chi phí 20.000 USD, hệ thống đã tạo ra khoảng 100.000 dòng mã, hỗ trợ các kiến trúc x86·ARM·RISC-V
  • Các agent liên tục làm việc mà không cần con người can thiệp thông qua harness vòng lặp tự động, đồng thời tăng hiệu quả nhờ cấu trúc kiểm thử·song song hóa·phân chia vai trò
  • Kết quả cho thấy tính tương thích với GCC và tỷ lệ vượt qua kiểm thử cao, nhưng các phần như sinh mã x86 16-bit·linker·chất lượng tối ưu hóa vẫn chưa hoàn thiện
  • Thí nghiệm này là một trường hợp kiểm chứng giới hạn và tiềm năng của đội ngũ LLM tự chủ, đồng thời làm nổi bật an toàn và quản lý chất lượng trong môi trường phát triển hoàn toàn tự động như một bài toán trọng yếu trong tương lai

Tổng quan dự án trình biên dịch C dựa trên đội ngũ agent

  • Một thí nghiệm trong đó nhiều instance Claude hợp tác song song để phát triển cùng một codebase
    • Lặp lại một cách tự chủ việc viết mã·kiểm thử·sửa lỗi mà không có sự can thiệp thời gian thực của con người
  • Mục tiêu là hoàn thiện một trình biên dịch C viết bằng Rust để có thể trực tiếp build kernel Linux
  • Tổng cộng sử dụng 16 agent, khoảng 2.000 phiên, 200 triệu token đầu vào·140 triệu token đầu ra
  • Kết quả là một trình biên dịch quy mô 100.000 dòng, có thể build kernel Linux 6.9 và các dự án mã nguồn mở lớn (QEMU, FFmpeg, SQLite, Redis, v.v.)

Thiết kế harness Claude cho vận hành dài hạn

  • Claude Code trước đây cần đầu vào từ con người, nhưng với harness chạy tự động theo cấu trúc vòng lặp vô hạn, nó có thể vận hành tự chủ
    • Cấu trúc lặp tự động thực hiện ngay tác vụ tiếp theo sau khi hoàn thành tác vụ hiện tại
    • Cũng từng có trường hợp Claude vô tình chạy pkill -9 bash và tự kết thúc chính mình
  • Kiến trúc chạy song song tận dụng container Docker và đồng bộ Git
    • Mỗi agent làm việc trong /workspace rồi push sang /upstream
    • Dùng lock dựa trên tệp văn bản để tránh xung đột công việc
    • Xung đột khi merge được Claude tự xử lý

Cách vận hành đội ngũ Claude song song

  • Ưu điểm của chạy song song là debug đồng thời và phân hóa vai trò
    • Một số agent viết mã, số khác phụ trách tài liệu hóa·quản lý chất lượng·tối ưu hiệu năng
  • Không có kênh giao tiếp hay bộ điều phối trung tâm; mỗi agent tự chủ chọn nhiệm vụ tiếp theo
  • Trong lịch sử Git vẫn còn lưu bản ghi lock công việc và tài liệu tiến độ của từng agent

Những bài học rút ra từ lập trình theo đội ngũ Claude

Tầm quan trọng của kiểm thử chất lượng cao

  • Claude làm việc tự chủ dựa trên các bài kiểm thử được cung cấp, nên độ chính xác của trình xác minh là yếu tố cốt lõi
    • Nếu có false positive, quá trình phát triển có thể đi sai hướng
  • Xây dựng pipeline continuous integration (CI) để bắt buộc xác minh rằng các chức năng hiện có không bị phá vỡ
  • Đảm bảo chất lượng bằng cách tận dụng script build mã nguồn mở và compiler test suite

Thiết kế môi trường từ góc nhìn của Claude

  • Mỗi agent khởi đầu trong một container mới không có ngữ cảnh, nên việc ghi chép tiến độ là bắt buộc
    • Chỉ thị cho agent liên tục cập nhật README và các tệp tiến độ
  • Ngăn ô nhiễm ngữ cảnh: giảm log xuống mức tối thiểu và ghi lỗi sao cho có thể nhận diện bằng từ khóa ERROR
  • Để bù cho việc thiếu nhận thức về thời gian, dùng tùy chọn --fast để chạy kiểm thử mẫu 1~10%

Giới hạn của song song hóa và cách khắc phục

  • Khi có nhiều bài kiểm thử độc lập, song song hóa tương đối dễ; nhưng build kernel Linux là một tác vụ khổng lồ đơn lẻ nên dễ phát sinh xung đột
  • Giải pháp là dùng GCC làm compiler oracle tham chiếu
    • Build một phần tệp bằng GCC, phần còn lại bằng trình biên dịch Claude
    • Khi thất bại, có thể thu hẹp dần các tệp có vấn đề để debug song song
    • Sau đó dùng delta debugging để phát hiện các lỗi phụ thuộc lẫn nhau

Phân hóa vai trò giữa các agent

  • Phân công chuyên biệt cho các nhiệm vụ như loại bỏ mã trùng lặp, cải thiện hiệu năng, sinh mã hiệu quả hơn, cải thiện cấu trúc Rust, tài liệu hóa, v.v.
  • Kết hợp song song hóa với chuyên môn hóa để nâng cao hiệu quả quản lý codebase quy mô lớn

Đánh giá hiệu năng của mô hình Opus 4.6

  • Cho đến Opus 4.5, việc build các dự án lớn vẫn chưa khả thi; đến Opus 4.6 mới lần đầu đạt mức thực dụng
  • Triển khai clean-room, không truy cập Internet và chỉ dùng thư viện chuẩn Rust
  • Vượt 99% GCC torture test suite, có thể chạy Doom
  • Hạn chế:
    • Không thể sinh mã x86 16-bit, nên ở giai đoạn boot vẫn cần gọi GCC
    • Assembler·linker chưa hoàn thiện, vẫn còn một số lỗi
    • Hiệu quả của mã sinh ra còn thấp, kém hiệu quả hơn cả mức GCC khi tắt tối ưu hóa
    • Chất lượng mã Rust nhìn chung ổn nhưng chưa đạt trình độ chuyên gia

Giới hạn và tiềm năng của đội ngũ agent tự chủ

  • Dự án là một benchmark để đo lường giới hạn của hợp tác tự chủ bằng LLM
  • Phát triển hoàn toàn tự chủ đi kèm đảm bảo chất lượng và rủi ro bảo mật
    • Có nguy cơ hiểu lầm rằng chỉ cần qua kiểm thử là đã hoàn thiện
  • Bày tỏ lo ngại về việc triển khai mã mà không có con người thẩm định
  • Tuy vậy, thí nghiệm này cũng chứng minh rằng đội ngũ agent tự chủ có thể hoàn thành các dự án phức tạp
  • Cùng với sự tiến bộ của mô hình, chiến lược phát triển tự chủ an toàn sẽ trở thành nhiệm vụ thiết yếu

Triển vọng sắp tới

  • Sự phát triển của mô hình ngôn ngữ đang tiến hóa theo lộ trình tự động hoàn thành trong IDE → hoàn thành hàm → pair programming → thực hiện dự án tự chủ
  • Agent teams cho thấy khả năng của phát triển hoàn toàn tự chủ
  • Bên cạnh sự ngạc nhiên trước tốc độ tiến bộ công nghệ, nhu cầu về khung đạo đức và an toàn mới cũng được nhấn mạnh
  • Kỳ vọng các ứng dụng tích cực sẽ bù đắp được rủi ro tiêu cực, nhưng cần chuẩn bị cho một mô hình phát triển mới

Bài viết liên quan

2 bình luận

 
mammal 2026-02-06

Vì đây là một dự án không phải là trình biên dịch viết bằng C mà được tạo chỉ bằng thư viện chuẩn của Rust, nên tôi thấy lời chỉ trích rằng dữ liệu huấn luyện có chứa mã C của gcc/clang hơi giống như đang dời khung thành. Dù sao thì vẫn rất ấn tượng.
 
GN⁺ 2026-02-06
Ý kiến trên Hacker News

  • Tôi đã làm việc gần 10 năm ở Google về build Linux kernel bằng Clang. Dự án lần này (clangbuiltlinux.github.io) nói rằng một LLM đã làm được điều tương tự với 2.000 phiên và 20.000 USD chi phí API. Nghe nói còn boot được thật nên rất đáng kinh ngạc. Tuy vậy, hiệu quả của mã được tạo ra khá thấp, thậm chí còn kém hiệu quả hơn cả bản GCC tắt tối ưu hóa. Dù vậy, đây vẫn là một dự án thực sự tuyệt vời

    • Dù rất ấn tượng, nhưng cũng có thể đây là kết quả của việc chép bài tập về nhà của người khác
    • Có nói rằng Opus không thể triển khai bộ sinh mã x86 16-bit nên đã dùng một mẹo lách là gọi GCC ở giai đoạn boot. Vì vậy có thể nghi ngờ liệu nó có thật sự tự boot hay không
    • Cảm giác như thời kỳ “Trusting Trust” của Ken Thompson đang quay trở lại. AI có khi sớm sẽ tự cấy chính nó vào bên trong compiler
    • Nếu đã tốn 20.000 USD, thì số tiền đó cũng có thể thuê ngắn hạn 8 lập trình viên senior. Có vẻ chi phí marketing bị đội lên quá mức, còn mô hình doanh thu thực tế thì chưa rõ ràng

  • Đây là cách tiếp cận thực tế hơn nhiều so với dự án trình duyệt của Cursor. Họ nói đây là một triển khai clean-room, không có truy cập Internet và chỉ dùng thư viện chuẩn Rust. Một compiler 100.000 dòng có thể build được Linux 6.9, QEMU, FFmpeg, SQLite, Postgres và Redis.
    Opus 4.5 lần đầu tiên có thể vượt qua các bài test quy mô lớn, và kết quả lần này dường như đã khai thác gần hết giới hạn đó.
    Dù có nhiều ràng buộc, tôi vẫn nghĩ đây là một thí nghiệm ấn tượng

    • Cách gọi là “triển khai clean-room” có vẻ hơi phóng đại. Mô hình vốn đã được huấn luyện trên toàn bộ Internet với các C compiler, nên không cần phải gắn nhãn như vậy
    • Đánh giá kết quả này chỉ dựa trên mặt bằng hiện tại thì hơi đáng tiếc. Nhìn vào tốc độ tiến bộ trong vài tháng gần đây, 1 năm nữa có lẽ sẽ vượt xa sức tưởng tượng
    • Thực ra, thay vì clean-room, có lẽ đúng hơn là LLM đã giải nén lượng kiến thức được nén trong quá trình huấn luyện theo kiểu dựa trên test
    • Dù sao thì đây chắc chắn cũng là mô hình được huấn luyện từ mã GCC hay Clang, nên tôi tò mò mức độ tương đồng mã thực tế là bao nhiêu
    • Cá nhân tôi thấy rất đáng nể, nhưng ở góc nhìn người dùng thực tế thì lại bớt thú vị hơn. Có lẽ việc thêm ISA mới vào LLVM hoặc tạo compiler cho ngôn ngữ mới sẽ có ý nghĩa hơn

  • Ban đầu tôi nghĩ “wow, thật ghê gớm”, nhưng rồi lại đổi ý. C compiler là loại phần mềm có đặc tả rất chặt chẽ, nên tương đối dễ để LLM xử lý.
    Nhưng phần lớn công việc của chúng ta lại diễn ra trong môi trường mà yêu cầu mơ hồ và mục tiêu liên tục thay đổi. Tôi tò mò liệu nó có hoạt động tốt trong những lĩnh vực như vậy không

    • Tôi chỉ biết cười với câu “C compiler là rõ ràng”. Có biết bao nhiêu “unspecified behavior” cơ mà
    • Việc sinh mã để khớp với test giống như fitting mô hình ML. Con người vẫn phải là người thiết kế và kiểm chứng test

  • Kỳ vọng rằng kết quả phải hoàn hảo nghe hơi lạ. Chính việc nó khả thi đã là đáng kinh ngạc rồi. Những thử nghiệm như thế này có thể sẽ được phản ánh vào quá trình huấn luyện của Opus hay Sonnet thế hệ tiếp theo, và biết đâu một ngày nào đó sẽ có mô hình tự tạo ra compiler hiệu quả

    • Tôi cũng nghĩ vậy. “Điều đáng kinh ngạc không phải là con chó nhảy múa giỏi đến đâu, mà là việc nó có thể nhảy múa”
    • Gần đây làn sóng phản cảm với generative AI quá mạnh, nên chỉ cần có một chút lỗi là bị quy thành ‘rác AI’. Điều đó khá đáng tiếc, vì đây đơn giản chỉ là một demo và proof of concept

  • Dự án này được nói là có thể build Linux kernel, QEMU, FFmpeg, Redis và cả Doom. Thật sự đáng kinh ngạc.
    Nhưng các hệ thống agent kiểu này hoạt động tốt trong những miền có thể kiểm thử được, còn ở những miền cần ngữ cảnh như ra quyết định kinh doanh thì vẫn có giới hạn

    • Tôi nghi ngờ liệu khái niệm “triển khai clean-room” có còn ý nghĩa gì với một mô hình đã được huấn luyện trên toàn bộ Internet hay không
    • Bước tiếp theo là AI thật sự hiểu và vận hành trong ngữ cảnh kinh doanh. Ví dụ, nhìn vào benchmark như Vending-Bench, có lẽ không còn lâu nữa trước khi một AI product manager có thể tự động thực hiện phỏng vấn người dùng, thí nghiệm và đề xuất roadmap

  • Đây là một dự án hay, nhưng tốt hơn là đừng nhắc đến “clean-room”. Vì đó là mô hình được huấn luyện trên mã có bản quyền, nên thực tế gần như là điều ngược lại

    • Nhưng con người cũng học từ các codebase có sẵn, rồi dựa trên kiến thức đó để làm triển khai clean-room
    • Cũng giống như con người tái sử dụng kiến thức học được ở công ty này sang nơi khác, LLM cũng chỉ đang tái cấu trúc dữ liệu đã học theo cách mang tính biến đổi. Chừng nào không phải sao chép trực tiếp thì vấn đề là khác

  • Theo GitHub issue, vấn đề là do thiếu đường dẫn include. Bản thân compiler thì vẫn ổn

    • Có vẻ chỉ đơn giản là thiếu gói như glibc-devel
    • Bài viết quá dài và thiếu căn cứ. Cảm giác như đã bỏ lỡ ý chính
    • AI là tương lai
    • Kết quả thật sự đáng kinh ngạc

  • Tôi muốn họ công khai toàn bộ prompt và cấu trúc agent. Sẽ rất tuyệt cho mục đích học tập, chứ tự bỏ ra 20.000 USD để tái hiện thì khá nặng

    • Dạo này hơi tiếc vì mọi người chỉ nhìn kết quả cuối cùng mà không còn tò mò về quá trình

  • Cái này giống như phiên bản hoạt động được của bài blog Cursor. Bằng chứng rằng nó thực sự đã build được Linux kernel thuyết phục hơn rất nhiều

    • Ban đầu tôi định làm một ngôn ngữ nhẹ nhàng kiểu cá tháng tư, nhưng giờ thấy kết quả đã đến mức này thì thật bất ngờ. Dù vậy tôi vẫn định tiếp tục thử

  • Đây là kiểu tiếp cận “có thể xây kim tự tháp nhưng không thể xây nhà thờ lớn” (bài liên quan).
    Về bản chất là đã ném vào một lượng tài nguyên tính toán khổng lồ để ép cho tính năng hoạt động, và có thể nói 20.000 USD đã bị đốt cháy.
    Dùng compute theo cấp số nhân để đổi lấy kết quả tuyến tính thì cũng có ý nghĩa, nhưng về dài hạn có vẻ là một hướng đi kém hiệu quả

    • 20.000 USD đó là theo giá API; nếu tính theo gói thuê bao thì có lẽ chỉ tương đương 5-6 gói Max
    • Dù vậy thì số đó cũng chỉ bằng 2 tuần lương của một kỹ sư FAANG. Con người không thể làm ra compiler trong 2 tuần, nên xét như một màn trình diễn thì hoàn toàn xứng đáng