Có một con số đáng dừng lại: Claude Opus 5 nguyên bản, chạy trực tiếp trên benchmark ARC-AGI-3, đạt khoảng 30% theo metric RHAE. Bọc chính model đó trong harness AVO mới của NVIDIA — không fine-tune, không đổi trọng số — và nó đạt 100.00 trên 183 level trải khắp 25 environment. Cùng một model. Cùng trọng số. Cùng API. Khoảng cách giữa “một phần ba” và “toàn bộ” hoàn toàn nằm ở lớp scaffolding bao quanh model, không nằm ở bản thân model.

Mình đã nói đi nói lại một phiên bản nào đó của “harness quan trọng hơn model” trong gần như mọi bài về kiến trúc mình viết năm nay, và AVO là bằng chứng thực nghiệm sạch nhất cho luận điểm đó mà mình từng thấy — không phải vì nó là một demo khéo léo, mà vì NVIDIA công bố cả phép so sánh ablation. Đó là phần đáng đào sâu.

AVO thực sự là gì

AVO là viết tắt của “Agentic Variation Operators,” và bất chấp cái tên kêu, kiến trúc bên trong là thứ hầu hết chúng ta xây hệ thống agent production sẽ nhận ra ngay lập tức, chỉ là được thực thi kỷ luật hơn phần lớn các team thường làm:

• Bộ nhớ bền vững xuyên suốt toàn bộ tác vụ, không chỉ trong một context window đơn lẻ — agent không phải suy luận lại từ đầu những gì nó đã học về luật của một environment mỗi khi chạm level mới.
• Một lớp giám sát theo dõi các trajectory tìm kiếm bị mắc kẹt và điều hướng lại chúng, thay vì để agent cứ lặp mãi trên một hướng tiếp cận bế tắc cho đến khi cạn budget.
• Tích hợp tool theo từng environment cụ thể — harness không đưa cho model một bộ tool chung chung rồi hy vọng; nó nối dây các tool đúng theo những gì mỗi environment ARC-AGI-3 thực sự cần.
• Một vòng lặp inspect → plan → implement → evaluate tường minh, chạy như các pha rời rạc thay vì để model tự do liên tưởng xuyên suốt một completion dài.

Không ý tưởng nào trong số này mới nếu xét riêng lẻ. Điều đáng chú ý là NVIDIA chạy phép so sánh có kiểm soát — cùng model gốc, có harness và không có harness — và công bố cả hai con số thay vì chỉ dẫn dắt bằng con số 100% giật tít. Đó là khác biệt giữa một tuyên bố marketing và một kết quả thật bạn có thể lý giải được.

Con số hiệu suất mới là thứ mình thực sự quan tâm

Điểm 100% chiếm headline, nhưng con số quan trọng hơn với bất kỳ ai đang chạy agent trong production là: AVO hiệu quả hơn VISTA — người dẫn đầu bảng xếp hạng trước đó — tới 12% về số hành động, trong khi đạt điểm cao hơn. Hiệu quả hành động là một proxy cho chi phí — mỗi hành động lãng phí là chi phí API và thời gian thực bạn không cần phải đốt. Một harness đưa bạn tới đáp án đúng trong ít bước hơn không chỉ “gọn gàng hơn” — nó rẻ hơn khi chạy ở quy mô lớn, và đó mới là metric thực sự quyết định một kiến trúc có khả thi cho workload thật hay chỉ là một lần chạy benchmark làm một lần cho vui.

Có một điểm dữ liệu thứ hai trong cùng bản phát hành củng cố điều này: trong một tác vụ tối ưu GPU-kernel riêng biệt, AVO chạy tìm kiếm tự động trong 7 ngày và cho ra các kernel nhanh hơn tới 10,5% so với FlashAttention-4 trên một DGX B200. Đó không phải benchmark đồ chơi — đó là kiến trúc harness tổng quát hóa sang một domain (tối ưu kernel cấp thấp) chẳng liên quan gì tới giải câu đố trừu tượng. Khi cùng một pattern cấu trúc — inspect, plan, implement, evaluate, cộng bộ nhớ bền vững và phát hiện bế tắc — tạo ra lợi ích ở hai domain không liên quan, đó là tín hiệu cho thấy chính kiến trúc đang làm việc thật, không phải overfit vào đặc thù của một benchmark.

Vòng lặp, rút gọn

Nếu bạn muốn hình dạng của nó mà không cần cái tên thương hiệu của NVIDIA, đây là control loop trông đại khái như sau:

state = load_persistent_memory(task_id)

while not solved and budget_remaining:
    inspection = inspect(environment, state)
    if stall_detector.flags(state.trajectory):
        plan = replan(inspection, discard=state.trajectory)
    else:
        plan = plan_next_step(inspection, state)

    result = implement(plan, tools=environment.scoped_tools)
    evaluation = evaluate(result, environment)

    state = update_memory(state, evaluation)
    if evaluation.stalled:
        stall_detector.record(state.trajectory)

Phần mà hầu hết team bỏ qua khi tự xây agent loop của mình là stall detector và nhánh discard-and-replan tường minh. Rất dễ để cứ để agent tiếp tục lặp trên hướng tiếp cận hiện tại vì “nó đã có tiến triển rồi” — nhưng đó chính xác là failure mode đốt budget mà không đẩy được kết quả đi đâu. Lớp giám sát của AVO coi “trajectory này không hội tụ” là một tín hiệu hạng nhất kích hoạt một reset cấu trúc, không chỉ là một lần retry nữa.

Vì sao điều này quan trọng nếu bạn đang chạy fleet agent của riêng mình

Mình chạy một phần đáng kể công việc vận hành của chính mình — pipeline xuất bản của blog này, vài digest hàng ngày — qua các scheduled agent, và kết quả AVO là một phép kiểm tra hữu ích với một thói quen mình thấy ở nhiều team (kể cả, thỉnh thoảng, chính mình trước đây): với tới một model lớn hơn hoặc mới hơn khi agent hoạt động kém, thay vì hỏi xem liệu harness bao quanh nó có phải nút thắt thực sự hay không. Một khoảng cách 30 điểm được đóng hoàn toàn nhờ scaffolding là một lập luận mạnh rằng “nâng cấp model” không nên là bước đi mặc định đầu tiên khi một tác vụ agent thất bại. Câu hỏi chẩn đoán rẻ hơn là: agent này có bộ nhớ bền vững xuyên suốt tác vụ không, có gì phát hiện khi nó bị kẹt không, và bộ tool của nó có được giới hạn đúng theo những gì tác vụ thực sự cần không — hay nó đang làm việc với tương đương một terminal trống và một lời cầu nguyện?

Hàm ý khó chịu cho bất kỳ ai đang bán “cứ dùng frontier model của chúng tôi” như toàn bộ pitch là kết quả của AVO cho thấy một phần đáng kể của thứ trông giống năng lực model thực ra là năng lực harness, và khoảng trống đó hiện đang rộng mở cho bất kỳ ai sẵn sàng xây scaffolding một cách nghiêm túc thay vì chờ bản phát hành model tiếp theo đóng nó lại thay mình.