Agent đã tự sửa được chính mình — nhưng chưa ai lắp nút hoàn tác

Vì sao "gỡ được" khó hơn nghe rất nhiều

Trực giác thông thường là: nếu agent ghi ra một thay đổi thì cứ lưu bản cũ rồi khôi phục. Trực giác đó đúng với file, và sai với gần như mọi thứ khác. Bản tự sửa của agent thường không phải một file mà là một chuỗi tác động: nó cài thêm một tool, tool ấy ghi vào một kho trạng thái, kho ấy được một middleware khác đọc, và middleware đó đã kịp thay đổi hành vi ở vài chục lượt sau. Khôi phục file cấu hình không xoá được các dấu vết đã lan ra.

Điểm mấu chốt của paper là khái niệm phụ thuộc trạng thái. Một quy trình gỡ được viết ra trong lúc hệ đang ở trạng thái A thường ngầm giả định rất nhiều thứ về A — thư mục này tồn tại, biến kia đang có giá trị đó, tool nọ chưa bị thay. Đem đúng quy trình ấy chạy ở trạng thái B thì các giả định gãy, và cái gọi là "undo" trở thành một thay đổi mới. Vì vậy EvoUndo không kiểm tra hoàn tác ở nơi bản sửa ra đời, mà cố tình kiểm ở các trạng thái phản thực.

Bốn khâu, và khâu nào mang lại điểm

Khâu biểu diễn buộc bản tự sửa phải được mô tả dưới dạng có thể suy luận được, thay vì chỉ là một diff. Khâu tổng hợp sinh ra quy trình gỡ tương ứng. Khâu chẩn đoán chỉ ra chính xác chỗ nào trong quy trình gỡ bị hỏng. Khâu kiểm chứng độc lập — quan trọng nhất — xác nhận việc gỡ thật sự đưa hệ về trạng thái tương đương, do một thành phần khác đánh giá chứ không phải chính agent tự khai.

Thí nghiệm gỡ từng yếu tố cho thấy không có yếu tố nào một mình đủ. Kết luận nguyên văn của nhóm tác giả: tự-tiến-hoá đáng tin cậy đòi hỏi đồng thiết kế bốn thứ — kiểm chứng, neo trạng thái, ngữ nghĩa bằng chứng, và độ biểu đạt của ngôn ngữ hoàn tác — chứ không thể đạt được bằng cách prompt lặp đi lặp lại.

Số liệu đáng nhớ

Hạn chế

Đây là môi trường tác vụ tự-tiến-hoá one-shot, không phải một agent sản xuất chạy liên tục nhiều tuần — nơi các bản sửa chồng lên nhau và tương tác theo cách mà thí nghiệm one-shot chưa chạm tới. Kết quả cũng lệch theo model (bản replicate trên Qwen3.8-27B giữ xu hướng nhưng khác về độ lớn), nên các con số tuyệt đối nên đọc như thứ tự so sánh chứ không phải hằng số. Và "khả năng hoàn tác" ở đây được định nghĩa qua kiểm chứng viên của chính hệ thống — vẫn là một proxy, dù là proxy độc lập.

Bốn kiểu hỏng mà một vòng lặp mắc phải

Paper liệt kê rất cụ thể, và ai từng dựng agent loop đều nhận ra ngay. Vòng lặp có thể tin một ghi chú tiến độ đã cũ — nó đọc "đã xong bước 3" trong khi bước 3 đã bị một thay đổi sau đó phá vỡ. Nó có thể bỏ qua kiểm chứng cần thiết, tin lời khai của Worker thay vì đi xem môi trường thật. Nó có thể tiêu ngân sách sai hướng, đổ nhiều vòng vào một nhánh không dẫn tới đâu. Và nó có thể dừng trước khi task đủ an toàn để nộp.

Điểm tinh tế: cả bốn lỗi này đều xảy ra ngay cả khi coding agent hoàn toàn đủ năng lực. Đó là lý do phải đo riêng. Nếu chỉ nhìn kết quả cuối, một lần chạy hỏng vì Controller dừng sớm trông y hệt một lần chạy hỏng vì Worker không code nổi.

Ba tầng đo và vì sao tầng giữa là thứ đáng dùng

Type I rẻ nhất: đặt câu hỏi "bước kế nên là gì" với đáp án được xác thực bằng thực thi, và không cần chạy Worker. Type II cho Controller điều khiển lặp trên một đoạn task đã được chọn sẵn — vẫn có vòng lặp thật nhưng không phải trả giá cho toàn bộ hành trình. Type III là chạy full từ trạng thái gốc, đắt nhất và gần thực tế nhất.

Phát hiện dùng được ngay nằm ở tương quan: Type II dự báo Type III ở ρ = 0,9747. Nghĩa là muốn so vài model xem cái nào chỉ huy vòng lặp tốt hơn, bạn không cần chạy full benchmark — đo ở tầng đoạn-giữa cho gần như cùng thứ hạng với chi phí thấp hơn khoảng hai phần ba.

Số liệu đáng nhớ

Hạn chế

Controller chỉ nhìn thấy bản tóm tắt có cấu trúc sau mỗi vòng, nên một phần điểm số phản ánh chất lượng của lớp tóm tắt đó chứ không thuần tuý năng lực chỉ huy — đổi định dạng tóm tắt nhiều khả năng đổi kết quả. Chỉ số tương quan ρ = 0,9747 tính trên tập controller của paper, chưa có gì đảm bảo nó giữ nguyên khi thêm model có hành vi khác hẳn. Và con số 24,69% là trần của thiết kế loop trong benchmark này, không phải trần của loop engineering nói chung.

Vì sao "gán công thô" là nút thắt thật

Giả sử agent chạy 40 lượt, trong đó có 12 lần nó sửa context — xoá cái này, tóm tắt cái kia, cất một mẩu vào bộ nhớ. Cuối cùng nó trả lời sai. RL mức-quỹ-đạo sẽ phạt cả 12 thao tác như nhau, kể cả thao tác duy nhất đúng đắn đã cứu được thông tin quan trọng. Ngược lại khi trả lời đúng, thao tác xoá nhầm may mà không hại cũng được thưởng. Tín hiệu học vì thế rất nhiễu, và đó là lý do các phương pháp trước tiến chậm.

ContextPilot xử lý bằng cách chỉ phân nhánh tại những chỗ đáng phân nhánh. Nó dùng hai tín hiệu để phát hiện thao tác then chốt: context thay đổi nhiều bất thường, và entropy của model tăng — dấu hiệu model đang phân vân. Tại những điểm đó, hệ chạy nhiều nhánh khác nhau, rồi ước lượng lợi thế của chính thao tác ấy bằng cách gộp kết quả của mọi nhánh đi qua nó. Đó là phép đo phản thực đúng nghĩa: giữ mọi thứ khác cố định, chỉ đổi một quyết định.

Ba tool mới bù đúng ba chỗ thiếu

Lập kế hoạch tổng thể cho agent chỗ ghi ý định dài hạn, để nó không phải suy lại mục tiêu từ đống log mỗi lượt. Bộ nhớ dài hạn tách thứ cần giữ lâu ra khỏi thứ chỉ dùng trong lượt này. Offload mềm là điểm khác biệt so với "xoá": thông tin bị đẩy ra khỏi working context nhưng lấy lại được, nên agent không phải chọn giữa giữ tất cả và mất vĩnh viễn. Ba tool này cộng lại chính là lý do đường input length nằm ngang thay vì đi lên.

Số liệu đáng nhớ

Hạn chế

Nhóm tác giả nêu ba điểm. Bộ tool vẫn chưa phủ hết các nhu cầu biên tập context; còn nhiều thao tác tổ chức, nén và truy xuất chưa được thử. Chưa dò kỹ siêu tham số — đặc biệt các thiết lập cho partial rollout và gán công, vốn là hai cơ chế cốt lõi, nên hiệu quả huấn luyện lẫn điểm cuối đều có thể còn dịch chuyển. Và phạm vi task hẹp: thí nghiệm tập trung vào long-context QA và deep search; agentic coding và GUI agent — hai chỗ context phình dữ nhất trong thực tế — chưa được kiểm.

Mẹo thoát vòng luẩn quẩn

Chỗ đáng học nhất của paper này không phải con số mà là một thủ thuật thiết kế. Vấn đề gốc: ở miền không chấm được, để cải thiện Solver thì cần Judge tốt; để biết Judge có tốt không thì cần đáp án đúng; mà đáp án đúng chính là thứ không có.

J-Zero lách bằng cách nhận ra rằng ta không cần biết đáp án đúng, chỉ cần biết cặp nào hơn cặp nào. Và có hai quan hệ thứ tự luôn đúng mà không cần ground truth. Thứ nhất, đáp án của Solver — vốn được huấn luyện để giải — thì nhìn chung phải hơn đáp án của Challenger, vốn được huấn luyện để ra đề. Thứ hai, một đáp án được phân rã thành phần rồi ghép lại thì nhìn chung tốt hơn đáp án viết một mạch, vì quá trình phân rã bắt model xử lý từng phần kỹ hơn. Hai bất đẳng thức "gần như luôn đúng" này trở thành nhãn miễn phí để Judge học. Judge khá lên thì chấm Solver chuẩn hơn, Solver khá lên thì cặp ưu tiên lại chắc hơn — vòng lặp đóng lại mà không cần dữ liệu ngoài.

Vì sao "10 vòng vẫn tiến" mới là kết quả chính

Con số dễ bị lướt qua nhưng đáng chú ý nhất là độ bền qua vòng lặp. Các hệ tự tiến hoá trước đó thường suy giảm sau khoảng hai vòng — kinh điển là hiện tượng model bắt đầu học từ chính lỗi của mình và trôi dần khỏi phân phối thật. J-Zero vẫn cải thiện qua ít nhất mười vòng. Lý do hợp lý: vì Judge được neo bằng các quan hệ thứ tự cấu trúc chứ không phải bằng phán đoán tự do của nó, nó khó trôi hơn — mỗi vòng vẫn có một điểm tựa bên ngoài chính nó.

Số liệu đáng nhớ

Hạn chế

Nhóm tác giả nói rõ: giới hạn compute khiến họ chỉ chạy được Challenger và Solver tới 8B tham số với Judge 8B, và chỉ trên base model — chưa thử quy mô lớn hơn, cũng chưa thử các reasoning model đã qua post-training. Đây là hạn chế đáng kể vì cả hai mẹo cặp-ưu-tiên đều dựa trên giả định "Solver nhìn chung hơn Challenger"; giả định đó có thể yếu đi khi cả hai đều đã rất mạnh. Ngoài ra AlpacaEval 2.0 xuất phát rất thấp (6,22) nên mức tăng lớn một phần là hiệu ứng nền thấp.