Agent tự dựng lấy bộ khung của mình — benchmark đầu tiên chấm điểm, và điểm không đẹp

Bối cảnh. Gần như mọi so sánh model hiện nay đều ngầm giữ harness cố định: cùng một vòng lặp agent, cùng bộ tool, chỉ thay model rồi xem điểm. Nhưng thực tế ai từng xây agent đều biết harness quyết định điểm số không kém model — digest hôm qua có Harness-of-Harness nâng Codex từ 49,58 lên 71,52 chỉ bằng cách bọc thêm một vòng lặp bên ngoài. Câu hỏi tự nhiên tiếp theo: nếu harness quan trọng đến thế, model có tự viết được harness cho chính nó không? HarnessDev là nỗ lực đầu tiên biến câu hỏi đó thành một phép đo có kiểm soát thay vì một giai thoại.

Cách làm, từng bước. Bước 1 — mỗi model tạo lập nhận một "seed" tối thiểu (khung sườn trần trụi, chưa có logic điều phối) cùng một tập nhỏ ca ví dụ, rồi phải tự viết ra toàn bộ hệ thống thực thi: vòng lặp, cách gọi tool, cách giữ trạng thái, luật dừng. Bước 2 — harness vừa dựng được đem chạy trên benchmark hạ nguồn, và model nhận lại phản hồi từ chính lần chạy đó. Bước 3 — model sửa harness của mình, chạy lại, lặp. Bước 4 — bản cuối cùng bị đem ra chấm trên tập task giấu kín, tức những ca chưa từng xuất hiện trong quá trình phát triển. Đây là chi tiết quan trọng nhất của thiết kế: nó tách bạch "harness thật sự tốt hơn" khỏi "harness được vá vừa khít với đúng những ca đã thấy".

Vì sao kết quả chia đôi theo lĩnh vực. Cách đọc hợp lý nhất: viết lách và chạy thí nghiệm ML là những việc mà bản thân model đã biết quy trình — nó chỉ cần viết ra thành code điều phối. Còn code, search và research là những việc mà harness tốt chứa đầy tri thức cay đắng tích luỹ từ thất bại thật: retry thế nào, khi nào cắt context, tool nào hay trả rác, lỗi nào đáng bỏ qua và lỗi nào phải dừng. Loại tri thức đó không suy ra được từ một seed và vài ví dụ; nó phải trả giá mới có.

Hạn chế. Chính paper nói rõ phần yếu nhất là Evolution: mức tăng bấp bênh và chỉ chuyển được một phần sang task giữ kín — nghĩa là một phần đáng kể của cái gọi là "tự cải thiện" thực chất là overfit vào tập phát triển. Thêm nữa, việc mức tăng bám vào model thực thi có nghĩa harness sinh ra không phải một tài sản độc lập: đổi model là mất. Bản tóm tắt cũng không nêu con số tuyệt đối theo từng lĩnh vực, nên hiện chỉ đọc được chiều hướng, chưa đọc được biên độ.

Bối cảnh. Một agent nghiên cứu ML giỏi cần biết những thứ rất cụ thể: thư viện nào dùng cho loại dữ liệu nào, hyperparameter nào thường sống được, lỗi nào là do phiên bản. Toàn bộ tri thức đó đã tồn tại — trong hàng nghìn repo GitHub. Nhưng repo là thứ hàng trăm nghìn dòng, không thể nạp vào context lúc agent đang chạy. Đây chính là điểm nghẽn mà paper gọi tên: kiến thức thao tác nằm ngoài agent, và mỗi lần chạy agent lại phải mò lại từ đầu.

Cách làm, từng bước. Bước 1 — chọn 1.000 repo ML được dùng rộng rãi. Bước 2 — chưng cất mỗi repo thành các "skill": mô tả ngắn, đọc được, đủ để nạp vào context, ghi lại cách làm chứ không phải toàn bộ mã. Bước 3 — kiểm chứng từng skill (đây là chỗ phân biệt thư viện này với một đống tóm tắt tự sinh: paper nhấn mạnh "verified"). Bước 4 — sắp xếp thành 20 lĩnh vực và 178 họ năng lực, để lúc chạy agent tra được đúng nhánh cần thay vì quét cả kho. Bước 5 — song song, sinh thêm skill theo hướng task-oriented cho từng bài toán cụ thể. Agent DisCo lúc làm việc sẽ kéo skill phù hợp vào context.

Vì sao con số MLE-bench lớn bất thường. Chú ý biên độ chênh nhau rất xa giữa các benchmark: +134,3% ở MLE-bench nhưng chỉ +9,2% ở FrontierCS. Cách đọc hợp lý: MLE-bench là loại việc mà phần lớn công sức nằm ở quy trình đã có người làm rồi — dựng pipeline, chọn baseline, tránh bẫy quen thuộc. Đó đúng là thứ chưng cất từ repo được. FrontierCS thiên về suy luận mới, nơi không có repo nào chứa sẵn đáp án. Nói cách khác, skill không làm model thông minh hơn; nó xoá đi phần công việc mà loài người đã giải xong và viết lại được.

Hạn chế. Bản tóm tắt chỉ nêu một hạn chế cốt lõi (tri thức thao tác nằm ngoài agent) mà không nêu giới hạn của chính phương pháp — đó là điểm trừ về báo cáo. Ba câu hỏi tự nhiên chưa có câu trả lời: skill hỏng khi thư viện lên phiên bản mới thì phát hiện bằng cách nào; "verified" được kiểm ở mức nào (chạy được, hay ra đúng kết quả); và con số phần trăm tương đối luôn phóng đại khi baseline thấp — cần biết điểm tuyệt đối mới đọc đúng được.

Bối cảnh. "Agent tự cải thiện" thường được nói như một năng lực duy nhất. Thực ra nó là một chuỗi ba bước, và chuỗi đứt ở đâu cũng ra cùng một triệu chứng: agent chạy nhiều vòng mà không khá lên. Bước một, agent phải tự sinh ra phép thử có ý nghĩa cho chính mình. Bước hai, nó phải chấm đúng kết quả của phép thử đó. Bước ba — và đây là bước ít ai đo — nó phải biến kết luận thành hành vi khác đi ở lần sau. S3Gym là nỗ lực tách ba bước để biết bước nào đang hỏng.

Cách làm, từng bước. Bước 1 — dựng 7 game dạng văn bản, mỗi game có verifier chạy được, tức máy chấm đúng/sai một cách khách quan chứ không nhờ một model khác chấm. Bước 2 — cho agent một pha thăm dò tự do: tự thử, tự quan sát, tự chấm. Bước 3 — tách hẳn một tập đánh giá giữ kín; điểm cuối cùng chỉ tính trên tập này. Bước 4 — so ba cách chuyển kinh nghiệm từ pha thăm dò sang pha đánh giá: nhét thẳng lịch sử tương tác vào context; nén thành bản tóm tắt có gắn điểm số; hoặc train thẳng vào tham số. Vì cả ba dùng chung một pha thăm dò, khác biệt về điểm phản ánh đúng chất lượng của cách nhớ, không phải chất lượng của trải nghiệm.

Vì sao không có đường nào thắng tuyệt đối. Đây là kết quả có cấu trúc chứ không phải nhiễu. Tóm tắt là một phép nén có mất mát: nó giữ lại quy luật và vứt đi chi tiết. Khi bài toán thật sự có quy luật — "cửa luôn khoá cho đến khi lấy được chìa" — nén là lợi. Khi bài toán đòi chi tiết phụ thuộc trạng thái — "phòng số 7 có cái bẫy này" — nén chính là chỗ mất thông tin quyết định, và lịch sử thô thắng. Điều này dự đoán được ngay từ bản chất nhiệm vụ, nghĩa là lựa chọn cơ chế nhớ nên là một quyết định thiết kế có cân nhắc, không phải mặc định.

Hạn chế. Bảy game văn bản là môi trường sạch, có verifier khách quan — đúng cái làm phép đo tin được, và cũng đúng cái khiến khó suy ra công việc thật, nơi tín hiệu đúng/sai thường mơ hồ và trễ. Bản tóm tắt không nêu số tuyệt đối nên biên độ của negative transfer chưa đọc được. Ngoài ra, việc pha thăm dò do chính agent điều khiển khiến chất lượng kinh nghiệm gắn với năng lực tự test của model — một biến bị trộn vào mà thiết kế chưa tách hết.

Bối cảnh. Chấm agent đắt theo một cách mà chấm model thường thì không. Một câu hỏi trắc nghiệm tốn một lần gọi model; một task SWE-bench tốn hàng chục vòng đọc file, chạy test, sửa, chạy lại. Và phần lớn chi phí đó bị đốt vào những lần chạy mà kết cục đã rõ từ sớm: agent đi sai hướng ngay từ phút đầu rồi vùng vẫy thêm ba mươi bước nữa trước khi hết ngân sách. EarlyEval khai thác đúng chỗ dư thừa đó.

Cách làm, từng bước. Bước 1 — trích đặc trưng từ trạng thái đang chạy của agent: hành vi (đang gọi tool gì, lặp lại bao nhiêu, có tiến triển không), văn bản (nội dung agent sinh ra), và đối chiếu với lời giải tham chiếu. Bước 2 — train hai bộ phân loại LightGBM riêng biệt thay vì một: một chuyên bắt tín hiệu "chắc chắn xong được", một chuyên bắt "chắc chắn hỏng". Tách đôi như vậy cho phép đặt ngưỡng khác nhau cho hai hướng, vì hai loại sai lầm có giá khác nhau. Bước 3 — hiệu chỉnh ngưỡng: chỉ dừng khi độ tin cậy vượt mức đã calibrate. Bước 4 — khi một trong hai bên vượt ngưỡng, huỷ các bước còn lại và ghi nhận kết cục dự đoán. Ba benchmark được đo: SWE-bench Verified, TerminalBench, Toolathlon.

Chỗ cần đọc kỹ. Chênh lệch giữa "cắt 13–26% số bước" và "giảm tới 44,1% input token" không mâu thuẫn — nó cho biết các bước bị cắt là những bước đắt nhất. Điều này hợp lý về mặt cơ chế: context của agent phình theo thời gian, nên bước thứ 40 tốn nhiều token đầu vào hơn hẳn bước thứ 5. Nói cách khác, phần bị cắt đúng là phần đuôi đắt đỏ, và đó là lý do tỷ lệ tiết kiệm token cao gấp đôi tỷ lệ tiết kiệm bước.

Hạn chế. Sai lệch 1–2 điểm phần trăm nghe nhỏ, nhưng phải đặt cạnh khoảng cách thật giữa các model đang được so: rất nhiều bảng xếp hạng agent hiện nay có các vị trí liền kề cách nhau đúng 1–2 điểm. Nghĩa là EarlyEval an toàn cho vòng lặp phát triển nội bộ, và không an toàn để công bố một bảng xếp hạng. Ngoài ra việc dùng đặc trưng từ lời giải tham chiếu giới hạn phương pháp ở những benchmark có sẵn đáp án — không dùng được để giám sát agent chạy trên việc thật. Và ngưỡng phải hiệu chỉnh lại cho từng phân bố agent/benchmark mới, tức có chi phí thiết lập không nhỏ.