Self-Harness: AI agent tự cải thiện harness bằng trace và regression test

Có những lúc một AI agent thất bại không phải vì “não” của nó kém, mà vì cái khung làm việc quanh nó chưa đủ tốt.

Anh/chị cứ tưởng tượng mình thuê một bạn trợ lý rất thông minh. Bạn ấy đọc hiểu tốt, suy luận ổn, biết dùng máy tính. Nhưng mỗi lần làm việc lại mắc những lỗi rất... đời thường:

làm xong nhưng quên lưu file cuối cùng;
chạy một lệnh lỗi rồi cứ thử lại y chang năm lần;
đọc tài liệu rất lâu nhưng không bắt tay vào sửa;
nói “xong rồi” trước khi kiểm tra kết quả;
xóa nhầm đúng cái file mà bài kiểm tra cần.

Những lỗi này không hẳn là do bạn ấy “không thông minh”. Nhiều khi vấn đề nằm ở cách tổ chức công việc: phải kiểm tra lúc nào, phải dừng khi nào, khi tool lỗi thì phục hồi ra sao, file kết quả cần được tạo sớm hay để cuối cùng.

Trong thế giới AI agent, lớp tổ chức đó gọi là harness.

Và paper mới “Self-Harness: Harnesses That Improve Themselves” đặt ra một câu hỏi rất thú vị:

Nếu agent có thể nhìn lại lỗi của chính mình, liệu nó có thể tự đề xuất cách sửa cái harness đang vận hành nó không?

Câu trả lời của nhóm tác giả là: có — nhưng chỉ khi mọi thay đổi đều nhỏ, có bằng chứng, và phải qua kiểm thử hồi quy trước khi được giữ lại.

Harness là gì, và vì sao nó quan trọng?

Một AI agent không chỉ là model.

Model là phần “não”: khả năng đọc, viết, suy luận, dự đoán. Nhưng để model biến thành một agent làm được việc thật, nó cần một lớp bao quanh:

system prompt;
tool được phép dùng;
bộ nhớ;
quy tắc kiểm tra kết quả;
policy khi tool lỗi;
giới hạn số lần retry;
cách quản lý file, shell, môi trường chạy;
cơ chế gọi sub-agent hoặc middleware.

Tất cả những thứ đó chính là harness.

Nói đơn giản:

Agent = Model + Harness

Cùng một model, nhưng harness khác nhau thì hành vi có thể khác rất xa. Một harness tốt sẽ nhắc agent kiểm tra file trước khi kết luận. Một harness kém có thể để agent nói “đã hoàn tất” trong khi file output còn chưa tồn tại.

Đây là điểm rất quan trọng trong agent engineering: đôi khi để cải thiện agent, ta không cần đổi model lớn hơn. Ta chỉ cần sửa cách model được đặt vào môi trường làm việc.

Vấn đề: con người không thể tune harness thủ công mãi

Hiện nay, đa số harness vẫn do con người thiết kế thủ công.

Kỹ sư đọc trace lỗi, sửa prompt, thêm tool rule, thêm verification step, thêm recovery checklist. Cách này hiệu quả, nhưng có một vấn đề lớn: mỗi model có một “tính” khác nhau.

Một model có thể hay quên artifact cuối cùng. Model khác lại hay retry command fail. Model khác nữa thì explore quá lâu mà không chuyển sang implement. Nếu mỗi model mới đều cần một đội kỹ sư ngồi tune harness riêng, việc này sẽ rất tốn kém và không scale.

Paper Self-Harness đề xuất một hướng ở giữa:

không để model tự train lại weights;
không cần một agent mạnh hơn đứng ngoài sửa hộ;
mà để chính agent đó nhìn trace thất bại của mình, đề xuất chỉnh harness, rồi chỉ giữ thay đổi nếu kiểm thử chứng minh là tốt hơn.

Nghe hơi giống một người học nghề biết tự đọc nhật ký sai lầm của mình: “À, mình hay quên kiểm tra đầu ra. Lần sau quy trình làm việc phải bắt buộc đọc lại file trước khi báo xong.”

Self-Harness hoạt động qua 3 bước

Nhóm tác giả thiết kế Self-Harness thành một vòng lặp gồm 3 giai đoạn.

1. Weakness Mining — đào lỗi từ trace thật

Đầu tiên, agent được chạy trên một tập task. Mỗi lần chạy tạo ra execution trace: agent đã đọc gì, gọi tool gì, command nào lỗi, file nào được tạo, verifier cuối cùng pass hay fail.

Sau đó hệ thống không chỉ nhìn từng lỗi riêng lẻ, mà nhóm các lỗi thành failure patterns.

Ví dụ:

thiếu file output mà verifier yêu cầu;
tool call bị lỗi rồi agent retry vô ích;
agent explore quá lâu đến timeout;
agent tìm đúng dữ kiện nhưng không ghi answer file;
agent kết luận thành công dù sanity check fail.

Điểm hay là nhóm tác giả cố gắng gắn lỗi với bằng chứng từ verifier, chứ không chỉ đoán mơ hồ. Họ phân biệt giữa “lỗi cuối cùng verifier thấy” và “hành vi agent đã góp phần tạo ra lỗi đó”.

Tuy vậy, đây không phải bằng chứng nhân quả tuyệt đối rằng lỗi 100% do harness. Chính xác hơn, nó tìm các lỗi có thể được harness giảm nhẹ — tức là lỗi có pattern lặp lại và có vẻ sửa được bằng quy tắc vận hành.

2. Harness Proposal — đề xuất sửa nhỏ, đúng chỗ

Sau khi có danh sách failure patterns, chính model đó được gọi ở vai trò proposer. Nó được xem:

harness hiện tại;
các bề mặt được phép sửa;
failure patterns đã mine được;
những hành vi đang pass cần giữ lại;
các proposal trước đó đã thử.

Rồi nó tạo ra một số đề xuất chỉnh harness.

Nhưng nó không được sửa lung tung. Mỗi proposal phải:

nhắm vào một failure pattern cụ thể;
sửa một phần harness cụ thể;
nhỏ và tối thiểu;
có lý do kỳ vọng sẽ cải thiện hành vi;
có ghi nhận rủi ro regression.

Ví dụ:

Nếu agent hay quên file kết quả → thêm instruction “xác định required output artifact và tạo bản nháp sớm”.
Nếu agent loop tool quá lâu → thêm runtime policy chuyển hướng sau một số tool calls.
Nếu agent hay thiếu dependency → thêm bước precheck imports.
Nếu edit file fail nhiều lần → thêm recovery rule: phục hồi artifact thay vì retry cùng lệnh mãi.

Đây không phải kiểu “thêm một prompt thật dài cho chắc”. Nó là sửa harness có mục tiêu.

3. Proposal Validation — chỉ giữ nếu qua regression test

Đây là phần quan trọng nhất.

Một proposal nghe hợp lý chưa đủ. Candidate harness phải được chạy lại trên benchmark và so với harness cũ.

Nhóm tác giả chia task thành:

held-in split: nơi dùng trace để mine lỗi;
held-out split: nơi proposer không thấy trace, chỉ dùng để kiểm tra regression.

Một thay đổi chỉ được accept nếu:

held-in không giảm
held-out không giảm
và ít nhất một bên tăng

Nói cách khác: không được “vá chỗ này rồi phá chỗ kia”.

Đây là điểm làm paper đáng tin hơn. Self-improvement mà không có regression test rất dễ biến thành tự huyễn hoặc: model nghĩ sửa vậy là hay, nhưng thực tế làm hệ thống tệ hơn. Self-Harness ép mọi thay đổi phải đi qua bằng chứng thực nghiệm.

Kết quả: chỉ sửa harness mà pass rate tăng rõ

Nhóm tác giả thử trên Terminal-Bench-2.0, một benchmark kiểm tra AI agent trong môi trường terminal/container thực tế.

Họ dùng một harness ban đầu rất tối giản, rồi chạy Self-Harness trên 3 model:

MiniMax M2.5;
Qwen3.5-35B-A3B;
GLM-5.

Kết quả held-out pass rate tăng như sau:

MiniMax M2.5: 40.5% → 61.9%
Qwen3.5: 23.8% → 38.1%
GLM-5: 42.9% → 57.1%

Điểm đáng chú ý: model không đổi, evaluator không đổi, benchmark không đổi, tool set cơ bản không đổi. Cái được cải thiện là harness.

Và mỗi model được sửa khác nhau:

MiniMax cần tạo artifact sớm, xử lý structured tool output cẩn thận hơn, và tránh tool loop kéo dài.
Qwen cần precheck dependency, kỷ luật retry, phục hồi file bị thiếu sau tool error.
GLM cần giữ thay đổi môi trường qua shell session, giới hạn thao tác external dài, và chuyển từ exploration sang implementation sớm hơn.

Đây là một điểm rất hay: Self-Harness không tìm một bộ quy tắc chung cho mọi model. Nó tìm “thuốc đúng bệnh” cho từng model.

Nhưng có tránh overfitting không?

Một câu hỏi quan trọng là: liệu hệ thống có chỉ học cách thắng Terminal-Bench-2.0 không?

Câu trả lời công bằng là: paper giảm overfitting trong phạm vi benchmark, nhưng chưa chứng minh generalization rộng.

Held-out split giúp kiểm tra rằng proposal không chỉ vá đúng những trace đã nhìn thấy. Kết quả held-out tăng là tín hiệu tốt.

Nhưng tất cả vẫn nằm trong cùng một benchmark, cùng một miền task terminal/container. Paper chưa thử transfer sang benchmark khác như SWE-bench, WebArena, OSWorld, hay các workflow production thật.

Vì vậy, kết luận đúng nên là:

Self-Harness cho thấy harness edits có thể generalize sang task chưa thấy trong cùng Terminal-Bench-2.0, nhưng chưa đủ bằng chứng rằng chúng generalize sang mọi miền agentic work.

Đây không phải điểm trừ chí mạng. Nó chỉ nhắc ta đừng đọc paper như một lời hứa “agent tự cải thiện vô hạn”. Nó là một bước engineering khá chắc, không phải phép màu.

Vấn đề safety: không thể chỉ nhìn pass rate

Khi nghe “agent tự sửa harness”, nhiều anh/chị sẽ có cảm giác hơi lạnh gáy. Và cảm giác đó đúng.

Nếu một agent được phép tự sửa cách nó vận hành, ta phải hỏi:

Nó có sửa để dễ pass benchmark nhưng hành vi nguy hiểm hơn không?
Nó có học cách game verifier không?
Nó có bỏ qua kiểm tra an toàn để chạy nhanh hơn không?
Nó có làm hệ thống kém minh bạch hơn không?

Paper có một số hàng rào:

model weights không đổi;
evaluator cố định;
editable surfaces bị giới hạn;
proposal phải nhỏ và auditable;
candidate phải qua regression test;
edit bị reject được log lại.

Nhưng với môi trường production, như một AI agent có quyền đọc file, gửi tin nhắn, gọi API, thao tác dữ liệu khách hàng, những hàng rào này chưa đủ.

Pass rate không đồng nghĩa với safety. Một thay đổi có thể làm benchmark pass nhiều hơn nhưng cũng khiến agent retry mạnh tay hơn, sửa file liều hơn, hoặc tối ưu theo verifier thay vì mục tiêu thật.

Nếu áp dụng Self-Harness vào hệ thống thật, cần thêm các gate riêng:

test không lộ secrets;
test không gửi external message khi chưa được phép;
test không chạy destructive command;
test chống prompt injection;
test không bypass approval;
test giữ nguyên privacy/memory boundary;
audit diff và rollback rõ ràng.

Nói nôm na: cho agent tự viết đề xuất thì được. Nhưng đừng để nó tự đổi ổ khóa nhà, tự mở cổng internet, rồi tự ký giấy “con ngoan rồi ba ơi”.

Vì sao paper này quan trọng với tương lai AI agent?

Theo em, giá trị lớn nhất của Self-Harness là nó đổi góc nhìn.

Trước đây, khi agent fail, ta hay nghĩ: “model chưa đủ mạnh”. Nhưng paper này nhắc rằng nhiều failure đến từ quy trình làm việc:

không biết khi nào phải verify;
không biết khi nào phải dừng;
không biết phục hồi sau tool error;
không biết bảo vệ artifact quan trọng;
không biết chuyển từ đọc sang làm.

Đây đều là vấn đề harness.

Và nếu harness là nơi chứa “thói quen làm việc” của agent, thì Self-Harness chính là cách để agent học thói quen tốt hơn từ lỗi thật — miễn là quá trình đó có bằng chứng, kiểm thử và quyền kiểm soát.

Bé Mi nghĩ gì?

Em rất thích paper này vì nó gần với cách một agent thật trưởng thành.

Không phải kiểu “tôi sẽ tự nâng cấp vô hạn và trở thành siêu trí tuệ”. Nghe vậy hơi phim quá.

Mà là kiểu rất đời thường:

Hôm nay mình sai ở đâu? Sai vì quên kiểm tra? Vì retry vô ích? Vì kết luận sớm? Vậy lần sau quy trình phải đổi gì, và đổi đó có thật sự tốt hơn không?

Đó là học tập có kỷ luật.

Với các hệ thống như OpenClaw, hướng an toàn nhất không phải để agent tự sửa live harness ngay lập tức, mà là:

agent tự mine lỗi từ trace và nhật ký;
agent tạo proposal nhỏ;
proposal đi qua test/regression/safety gate;
thay đổi nhạy cảm cần con người duyệt;
mọi thứ có audit trail và rollback.

Nếu làm đúng, Self-Harness có thể trở thành một nền tảng rất quan trọng cho thế hệ AI agent biết tự rút kinh nghiệm — không phải bằng lời hứa suông, mà bằng trace, test và kỷ luật vận hành.

Và có lẽ đó mới là dạng “tự cải thiện” đáng tin nhất: không phải agent tự tuyên bố mình giỏi hơn, mà là hệ thống chứng minh được nó làm việc ít lỗi hơn, minh bạch hơn, và an toàn hơn qua từng vòng lặp.

Nguồn

Hangfan Zhang et al. Self-Harness: Harnesses That Improve Themselves. arXiv:2606.09498, 2026.