Chuyến đi vào một codebase khổng lồ. 4 AI agent vượt qua Claude Opus 4.8

Sapo

Hãy tưởng tượng bạn bước vào một codebase doanh nghiệp đã tồn tại nhiều năm. Hàng nghìn file nằm rải rác. API gọi qua nhiều service. Một cấu hình tưởng như vô nghĩa lại có thể quyết định toàn bộ đường đi của một request.

Bạn giao cho một AI nhiệm vụ tìm nguyên nhân của một lỗi.

Nó bắt đầu đọc code, chạy lệnh, kiểm tra log, lần theo dependency. Nhưng càng đi xa, nó càng phải nhớ nhiều thứ hơn. Một phát hiện ở cuối cuộc điều tra có thể khiến giả thuyết ban đầu trở nên sai hoàn toàn.

Đây chính là nơi bài toán AI agent bắt đầu thay đổi.

Nghiên cứu AgentRadio cho thấy một điều đáng chú ý: bốn AI agent được tổ chức để giao tiếp với nhau theo thời gian thực có thể giải quyết 62,1% bài toán trên benchmark codebase doanh nghiệp, cao hơn mức 57,2% của một agent đơn chạy trên model mạnh hơn.

Điểm đáng nói không nằm ở con số 62,1%.

Điểm đáng nói là kiến trúc phối hợp đã tạo ra lợi thế mà việc chỉ tăng sức mạnh model không tạo ra được.

Tin tức chính vừa xảy ra

Các nhà nghiên cứu tại Coral AI Labs cùng nhiều trường đại học đã phát triển AgentRadio, một lớp giao tiếp bất đồng bộ dành cho các AI agent.

Ý tưởng khá đơn giản nhưng lại đánh trúng một điểm yếu lớn của hệ thống multi-agent hiện nay.

Các agent không chỉ được giao nhiệm vụ riêng. Chúng có thể gửi phát hiện cho nhau ngay trong khi vẫn đang thực hiện công việc của mình.

Một agent phát hiện ra manh mối mới không cần đợi hết nhiệm vụ.

Nó có thể gửi thông tin.

Agent khác tiếp tục công việc, nhận thông tin đó ở bước tiếp theo và điều chỉnh hướng điều tra.

Trong thử nghiệm trên 124 nhiệm vụ của SWE-Atlas QnA, một agent Claude Code chạy Opus 4.6 chỉ giải quyết được 32,3% nhiệm vụ.

Khi chuyển sang Opus 4.8, tỷ lệ tăng lên 57,2%.

Nhưng cấu hình bốn agent sử dụng AgentRadio đạt 62,1%.

Với DeepSeek V4 Pro, tỷ lệ cũng tăng từ 29,0% lên 50,8%.

Nói cách khác, vấn đề không chỉ là AI thông minh đến đâu.

Nó còn là AI được tổ chức như thế nào.

Điều gì mới?

Trong vài năm qua, hình ảnh phổ biến nhất của AI coding agent là một kỹ sư và một trợ lý AI.

Bạn đưa yêu cầu.

Agent đọc repository.

Agent lập kế hoạch.

Agent sửa code.

Agent chạy test.

Agent trả kết quả.

Mô hình này hoạt động tốt khi nhiệm vụ có phạm vi nhỏ.

Sửa một file.

Tạo một API.

Viết một module.

Thêm một test.

Nhưng enterprise software không vận hành theo cách đó.

Một bug có thể bắt đầu ở API nhưng nguyên nhân nằm trong database layer. Một lỗi timeout có thể bắt nguồn từ cache. Một hành vi bất thường của service có thể liên quan tới cấu hình triển khai từ nhiều năm trước.

Đây là một bài toán long-horizon reasoning.

Agent không chỉ cần biết bước tiếp theo.

Nó phải duy trì một bức tranh về toàn bộ cuộc điều tra.

Và đây là nơi single-agent bắt đầu gặp vấn đề về coverage.

Một agent thường đi theo một đường tuần tự xuyên qua repository. Khi context ngày càng lớn, kế hoạch ban đầu khó thay đổi. Những phát hiện xuất hiện muộn có thể không được truyền ngược đầy đủ vào các quyết định đã đưa ra trước đó.

Con người xử lý chuyện này khá tự nhiên.

Một kỹ sư nói:

“Khoan, tôi vừa tìm thấy thứ này. Có thể giả thuyết của chúng ta sai.”

Đồng nghiệp nghe thấy.

Cả nhóm đổi hướng.

AI agent hiện nay chưa làm việc tự nhiên như vậy.

Tại sao nó quan trọng?

Có một hiểu lầm phổ biến về multi-agent.

Nhiều người nghĩ chỉ cần chạy bốn agent thay vì một agent là hiệu suất sẽ tăng gấp bốn.

Không phải vậy.

Nếu bốn agent làm việc độc lập, bạn chỉ có bốn cuộc điều tra riêng biệt.

Nếu bốn agent chỉ được phép trao đổi sau khi hoàn thành một vòng, bạn lại tạo ra một vấn đề khác.

Giả sử:

• Agent A điều tra API.
• Agent B điều tra storage.
• Agent C kiểm tra security.
• Agent D tìm trong configuration.

Agent A phát hiện ra một log quan trọng.

Log đó chứng minh giả thuyết của Agent B có thể sai.

Nhưng nếu A chỉ được nói với B sau khi cả nhóm hoàn thành vòng làm việc hiện tại, B có thể mất hàng chục phút tiếp tục đi sai hướng.

Đây là chi phí của thời điểm giao tiếp.

Thông tin không chỉ có giá trị vì nó đúng.

Nó còn có giá trị vì nó đến đúng lúc.

AgentRadio tập trung chính xác vào khoảng trống này.

Sản phẩm hoạt động thế nào?

AgentRadio không cố xây dựng lại Claude Code hay Codex CLI.

Nó nằm bên ngoài agent harness.

Kiến trúc gồm một message server và lớp tích hợp rất mỏng ở phía agent.

Hệ thống cung cấp ba primitive chính.

create_thread tạo một cuộc hội thoại giữa các agent.

send_message gửi thông tin vào thread mà không buộc agent gửi phải dừng công việc.

wait_for_mention khiến agent chờ thông báo liên quan đến mình và nhận được trạng thái của các thread khi có tin nhắn phù hợp.

Điều quan trọng nhất nằm ở đây:

Agent có thể làm việc và lắng nghe cùng lúc.

Đó là trạng thái mà nghiên cứu gọi là passive awareness.

Agent không cần liên tục dừng lại để kiểm tra xem đồng đội có gì mới.

Một watcher chạy nền.

Khi có thông tin liên quan, agent nhận được tín hiệu và có thể sử dụng nó ở bước tiếp theo.

Về mặt kiến trúc, đây là một thay đổi nhỏ.

Về mặt hành vi, nó có thể tạo ra khác biệt rất lớn.

Một ví dụ cho thấy sức mạnh của giao tiếp đúng lúc

Một trong những tình huống thử nghiệm liên quan tới hệ thống MinIO.

Nhiệm vụ yêu cầu các agent tìm câu trả lời dựa trên hành vi thực tế của hệ thống.

Trong quá trình điều tra, các agent phát hiện rằng cần kiểm tra log phía server cho từng request.

Vấn đề là phát hiện này xuất hiện sau khi kế hoạch ban đầu đã được triển khai.

Trong cấu hình multi-agent thông thường, hai agent đều nhận ra nhu cầu kiểm tra log nhưng không truyền phát hiện đó đủ sớm.

Đến giai đoạn review, cả nhóm cùng thống nhất một câu trả lời sai.

Kết quả bỏ lỡ năm tiêu chí đánh giá.

Khi bật AgentRadio, một agent vừa phát hiện ra yêu cầu về server-side log đã gửi thông tin cho nhóm.

Các agent khác đang làm việc đồng thời nhận được manh mối.

Kết quả chuyển từ thất bại thành 16/16 điểm.

Đây là ví dụ quan trọng vì nó cho thấy vấn đề không phải thiếu agent.

Không phải thiếu compute.

Không phải thiếu một vòng review.

Vấn đề là thông tin đến quá muộn.

Dữ liệu nằm ở đâu?

Khi nói về AI agent, chúng ta thường tập trung vào model.

Nhưng với enterprise software, một thành phần khác quan trọng không kém là context.

Codebase.

Log.

Database.

Configuration.

API.

Documentation.

Ticket.

Lịch sử thay đổi.

Security policy.

Mỗi nguồn dữ liệu lại có một cấu trúc khác nhau.

Một agent càng làm việc lâu, bài toán context càng trở nên khó.

Đây là lý do hệ thống multi-agent không đơn giản là “chia codebase thành bốn phần”.

Trong thực tế, các phần của hệ thống liên kết với nhau.

Một file configuration có thể thay đổi cách API hoạt động.

Một log có thể bác bỏ giả thuyết của database agent.

Một dependency cũ có thể giải thích hành vi tưởng như bất thường của một service.

Vì vậy, architecture tốt không chỉ cần nhiều agent.

Nó cần một hệ thống trao đổi bằng chứng.

AgentRadio đang đi theo hướng đó.

Doanh nghiệp tạo giá trị thế nào?

Giá trị của coding agent không nằm ở việc AI tạo ra bao nhiêu dòng code.

Doanh nghiệp quan tâm một thứ khác:

Nhiệm vụ có hoàn thành đúng hay không?

Một agent viết 500 dòng code nhưng làm hỏng production không tạo ra giá trị.

Một nhóm agent mất thêm thời gian nhưng tìm đúng nguyên nhân của một sự cố nghiêm trọng lại có thể tạo ra giá trị rất lớn.

Đây là lý do cách đánh giá AI enterprise đang dịch chuyển từ:

model benchmark → task completion → reliable outcome.

Trong nghiên cứu, chi phí phối hợp không phải bằng không. Một nhóm bốn agent sử dụng AgentRadio tiêu tốn nhiều tài nguyên hơn một agent đơn.

Nhưng khi so sánh với sáu lần chạy Opus độc lập có ngân sách tính toán tương đương, nhóm AgentRadio vẫn đạt 62,1% trong khi nhóm chạy độc lập chỉ đạt 37,9%.

Điều này rất quan trọng.

Nếu chỉ tăng số lần chạy, doanh nghiệp đang mua thêm compute.

Nếu tổ chức agent tốt hơn, doanh nghiệp đang mua khả năng giải quyết vấn đề.

Platform hay product?

AgentRadio thú vị nhất khi nhìn nó như một lớp infrastructure thay vì một coding tool đơn thuần.

Model là bộ não.

Agent harness là môi trường thực thi.

Tool là đôi tay.

Context là trí nhớ.

Message layer là hệ thần kinh.

Và orchestration là cách cả hệ thống quyết định ai làm gì, khi nào cần trao đổi và bằng chứng nào đáng tin.

Nếu AI agent trở thành lực lượng lao động số, doanh nghiệp sẽ không thể chỉ triển khai một model rồi chờ phép màu.

Họ sẽ cần một agent operating environment.

Trong môi trường đó, agent phải có danh tính.

Có quyền hạn.

Có trách nhiệm.

Có log.

Có lịch sử.

Có khả năng giao tiếp.

Có cơ chế phục hồi.

Và quan trọng nhất, phải biết khi nào cần gọi con người.

Đối thủ và lợi thế cạnh tranh

Cuộc cạnh tranh mới của AI coding không chỉ là Claude đối đầu GPT hay DeepSeek.

Một tầng cạnh tranh khác đang hình thành:

Ai xây được kiến trúc agent tốt hơn?

Single-agent systems có ưu điểm rõ ràng.

Chúng đơn giản.

Dễ triển khai.

Dễ kiểm soát.

Phù hợp với nhiệm vụ nhỏ và có thể đảo ngược.

Nhưng khi nhiệm vụ kéo dài, multi-agent có một lợi thế tự nhiên: phân chia nhận thức.

Một agent có thể tập trung vào API.

Agent khác tập trung vào database.

Agent thứ ba kiểm tra security.

Agent thứ tư giữ vai trò tổng hợp.

Tuy nhiên, lợi thế thật sự không nằm ở số lượng agent.

Nó nằm ở khả năng phối hợp giữa các agent.

Đây có thể trở thành một lớp lợi thế cạnh tranh mới của các nền tảng AI doanh nghiệp.

Nhưng multi-agent cũng có một mặt trái

Thêm agent không đồng nghĩa với thêm trí thông minh.

Một nhóm có thể cùng nhau khuếch đại một sai lầm.

Nếu một agent đưa ra giả thuyết sai và ba agent khác tin vào nó, hệ thống có thể đi sai nhanh hơn.

Giao tiếp cũng có thể tạo nhiễu.

Một agent đang đi đúng hướng có thể bị một thông tin không liên quan kéo lệch khỏi nhiệm vụ.

Nghiên cứu cũng chỉ ra một giới hạn đáng chú ý qua trường hợp Grafana.

Một số tiêu chí yêu cầu agent đưa ra kết luận phủ định, tức là xác nhận rằng một hành vi không xảy ra.

Các agent có chạy test nhưng không hình thành được giả thuyết cần thiết.

Kết quả là cả hai cấu hình đều bỏ lỡ những tiêu chí đó.

Điều này cho thấy một nguyên tắc quan trọng:

Giao tiếp chỉ giúp truyền một ý tưởng đã xuất hiện. Nó không tự tạo ra một ý tưởng mà cả nhóm chưa từng nghĩ tới.

Bài toán lớn hơn là governance

Khi agent còn nhỏ, con người có thể kiểm tra từng hành động.

Nhưng nếu doanh nghiệp có hàng trăm hoặc hàng nghìn agent, mô hình “human in the loop” có thể trở thành một nút thắt.

Đây là nơi các hệ thống governance như SAGE của Rubrik đưa ra một hướng tiếp cận đáng chú ý: để một lớp AI khác đánh giá hành động của agent dựa trên chính sách và ngữ cảnh.

Ý tưởng này giải quyết một vấn đề thực tế.

Nếu một agent có quyền truy cập Salesforce và email, từng quyền riêng lẻ có thể hợp lệ.

Nhưng khi kết hợp, chúng tạo ra một rủi ro mới.

Agent có thể đọc dữ liệu nội bộ rồi truyền dữ liệu đó ra ngoài.

Vấn đề không nằm ở một permission.

Nó nằm ở tổ hợp permission.

Đây là kiểu rủi ro mà hệ thống quản trị AI trong doanh nghiệp phải bắt đầu hiểu.

Dữ liệu khảo sát được cung cấp trong bài cho thấy 66% doanh nghiệp đã cho phép hoặc đang tiến tới triển khai agent mà không cần con người duyệt từng hành động, trong khi chỉ 5% hoàn toàn tin tưởng các hệ thống đánh giá tự động.

Khoảng cách này rất lớn.

Doanh nghiệp muốn autonomy.

Nhưng họ chưa hoàn toàn tin vào cơ chế kiểm soát autonomy.

Việt Nam sẽ bị tác động thế nào?

Việt Nam có một lợi thế đặc biệt trong giai đoạn này.

Phần lớn doanh nghiệp vẫn đang trong quá trình hiện đại hóa hệ thống.

Điều đó có nghĩa nhiều công ty đang sở hữu một hỗn hợp rất quen thuộc:

ERP cũ.

Database cũ.

Microservice mới.

API mới.

Hệ thống cloud.

Server nội bộ.

Kho tài liệu.

Log.

Và hàng chục quy trình được xây dựng qua nhiều thế hệ kỹ sư.

Đây chính là môi trường mà AI agent sẽ gặp bài toán khó nhất.

Một chatbot có thể trả lời câu hỏi.

Một coding agent có thể viết API.

Nhưng để AI thực sự điều tra một hệ thống doanh nghiệp Việt Nam, nó cần hiểu mối quan hệ giữa hàng chục hệ thống khác nhau.

Trong ngân hàng, AI có thể điều tra sự cố xuyên qua API, fraud system, database và hệ thống giao dịch.

Trong thương mại điện tử, agent có thể đồng thời kiểm tra frontend, payment service, inventory, order system và logistics.

Trong viễn thông, một sự cố mạng có thể yêu cầu phối hợp giữa monitoring, configuration, routing và ticket system.

Đây không còn là bài toán chatbot.

Đây là bài toán AI workforce.

Doanh nghiệp Việt Nam nên làm gì?

Không nên bắt đầu bằng việc triển khai hàng trăm agent.

Hãy bắt đầu bằng một nhiệm vụ mà con người hiện đang mất nhiều thời gian để điều tra.

Chẳng hạn:

• Phân tích incident xuyên nhiều service.
• Kiểm tra security của repository.
• Điều tra dependency migration.
• Phân tích architecture của hệ thống cũ.
• Tìm nguyên nhân lỗi production.
• Review một thay đổi lớn trên nhiều module.

Sau đó xây dựng một nhóm nhỏ.

Một agent điều tra.

Một agent kiểm chứng.

Một agent chuyên về security.

Một agent tổng hợp.

Quan trọng hơn, hãy thiết kế kênh giao tiếp giữa chúng ngay từ đầu.

Mỗi agent cần có identity riêng.

Quyền truy cập nên được giới hạn theo nhiệm vụ.

Mọi hành động cần có provenance.

Mọi kết luận quan trọng cần có bằng chứng.

Và hệ thống phải có khả năng biết:

Agent nào đã nói điều này? Dựa vào dữ liệu nào? Khi nào? Vì sao nhóm tin nó?

Đây sẽ là nền tảng của AI enterprise đáng tin cậy.

Kết luận

Chúng ta từng nghĩ tương lai của AI software engineering là một model ngày càng lớn.

Sau đó chúng ta nghĩ tương lai là một coding agent mạnh hơn.

Nhưng những thử nghiệm như AgentRadio cho thấy câu chuyện có thể đang chuyển sang một hướng khác.

Tương lai có thể thuộc về những hệ thống biết tổ chức nhiều AI thành một đội ngũ.

Điều đáng chú ý không phải bốn agent thông minh hơn một agent.

Chúng không nhất thiết thông minh hơn.

Điểm khác biệt là chúng nhìn thấy nhau.

Một phát hiện có thể đi từ agent này sang agent khác trước khi giá trị của nó biến mất.

Một giả thuyết có thể được kiểm chứng độc lập.

Một hướng điều tra sai có thể được sửa giữa chừng.

Và một codebase phức tạp có thể được nhìn từ nhiều góc độ cùng lúc.

Đó là sự chuyển dịch quan trọng.

AI không còn chỉ là câu chuyện về model intelligence.

Nó đang trở thành câu chuyện về organizational intelligence.

Khi các agent làm việc trong thời gian dài hơn, khả năng giao tiếp, phân quyền, kiểm chứng, ghi lại bằng chứng và phục hồi sau sai lầm sẽ quan trọng không kém khả năng viết code.

Và nếu một ngày doanh nghiệp có hàng nghìn agent hoạt động liên tục, câu hỏi quan trọng nhất sẽ không còn là:

“Model nào thông minh nhất?”

Mà sẽ là:

“Chúng ta đã xây được một môi trường đủ tốt để những AI này làm việc cùng nhau chưa?”

Đó mới có thể là chiến trường lớn tiếp theo của phần mềm doanh nghiệp.