Auto-Harness: Khi LLM Agent tự cải thiện mà không cần retrain
Thay vì fine-tune model, hệ thống mới tự động edit prompts, tools, memories và giải quyết vấn đề 'brittle harness' trên open-ended task streams.
Nguyễn Nhật Long
@nguyennhatlong1303
Có một bài toán mà bất kỳ team nào đang build agentic system cũng sẽ gặp phải: làm sao để agent tự cải thiện theo thời gian mà không cần phải retrain toàn bộ model? Fine-tuning tốn kém, chậm, và mỗi lần có task mới lại phải lặp lại từ đầu. Đây là lý do tại sao hướng tiếp cận auto-harness đang được chú ý nhiều và paper "Adaptive Auto-Harness" vừa ra tuần này đẩy hướng này đi xa hơn đáng kể.
Harness là gì, và tại sao nó lại "brittle"?
Trước hết nói qua về khái niệm. Trong agentic system, harness là toàn bộ lớp bao quanh LLM: prompts, tools, skills, memories. Thay vì sửa weights của model, bạn sửa harness để thay đổi hành vi của agent. Nghe có vẻ hợp lý và thực tế các hệ thống như A-Evolve, GEPA, Meta-Harness đều đang làm vậy.
Vấn đề nằm ở chỗ: khi task stream là open-ended tức là task liên tục đến, đa dạng, không có điểm kết thúc thì một harness duy nhất bị update liên tục sẽ trở nên brittle. Accuracy tăng nhanh lúc đầu, rồi đạt đỉnh, rồi... giảm. Mình thấy pattern này quen lắm, kiểu như bạn optimize code cho một use case rồi nó bắt đầu break các case khác.
Paper này formalize vấn đề đó thành hai loại loss:
Hai cái này độc lập nhau, và cần giải pháp riêng cho từng cái.
| Loss | Định nghĩa | Nguyên nhân |
|---|---|---|
| **Evolution loss** | Evolver không build được harness tốt từ lịch sử | Thiếu context, memory yếu, feedback loop kém |
| **Adaptation loss** | Commit vào một harness duy nhất trước khi thấy task | Không có cơ chế routing theo task type |
Pipeline multi-agent để giảm evolution loss
Phần này mình thấy khá thú vị về mặt thiết kế. Thay vì dùng một agent duy nhất để evolve harness, họ build một stateful multi-agent evolver với flow:
1Analyst → Researchers → Builder → Verifier
Mỗi agent có vai trò riêng:
- Analyst nhìn vào task stream, phân tích pattern, xác định điểm yếu của harness hiện tại
- Researchers đào sâu vào từng vấn đề cụ thể, tìm hướng cải thiện
- Builder thực sự edit harness sửa prompt, thêm tool, cập nhật memory
- Verifier kiểm tra harness mới có thực sự tốt hơn không trước khi deploy
Cái hay ở đây là cross-cycle memory tức là memory được giữ xuyên suốt các evolution cycle, không bị reset. Kết hợp với temporal-reveal feedback (feedback được reveal dần theo thời gian, giống như bạn không biết kết quả ngay mà phải chờ), hệ thống có thể học từ lịch sử dài hơn thay vì chỉ nhìn vào kết quả gần nhất.
Theo kinh nghiệm của mình khi build RAG pipeline, cái memory và feedback loop chính là điểm yếu chết người của hầu hết agentic system. Nếu agent chỉ nhớ được vài turn gần nhất thì việc "học từ kinh nghiệm" gần như vô nghĩa.
Harness tree + solve-time routing để giảm adaptation loss
Đây là phần giải quyết vấn đề thứ hai và mình nghĩ đây là contribution thực sự differentiated của paper này.
Thay vì maintain một harness duy nhất, hệ thống build một harness tree một cây các harness variants, mỗi nhánh được optimize cho một loại task khác nhau. Khi task mới đến, hệ thống route đến harness phù hợp nhất tại solve time (không phải lúc training hay evolution).
Nghe quen không? Đây về cơ bản là mixture-of-experts nhưng ở tầng harness thay vì tầng model weights. Bạn không cần một harness "biết tất cả" bạn cần một router thông minh và một tập harness chuyên biệt.
Cái này giải quyết đúng vào điểm đau: khi bạn update harness cho task A, nó có thể làm hỏng performance trên task B. Với harness tree, task A và task B có thể đi theo hai nhánh khác nhau, evolution của nhánh này không ảnh hưởng nhánh kia.
Kết quả thực tế trên các benchmark khác nhau
Họ test trên ba loại task stream khá diverse:
So sánh với 5 auto-harness baselines khác và beat hết. Anh em lưu ý là đây không phải so sánh với fine-tuned models, mà so sánh với các hệ thống auto-harness khác cùng category. Tức là trong cùng paradigm "không sửa weights", approach này tốt hơn đáng kể.
| Benchmark | Task type | Kết quả |
|---|---|---|
| PolyBench | Prediction market | **80.9% accuracy** |
| CTF challenges | Security/hacking | Beat tất cả 5 baselines |
| Event forecasting | Time-series prediction | +330 coverage-scaled return |
Mình không có điều kiện reproduce hết, nhưng code đã public tại github.com/A-EVO-Lab/a-evolve nên bạn có thể tự verify.
Tại sao hướng này quan trọng với team đang build production agent?
Nhìn từ góc độ engineering thực tế: fine-tuning một model tốn vài ngàn đô và vài ngày. Còn update harness về cơ bản là sửa text config và code có thể làm liên tục, tự động, và rẻ hơn nhiều bậc.
Vấn đề là trước giờ không ai giải quyết được việc harness bị degraded theo thời gian trên open-ended streams. Hầu hết team mình biết đều phải manually review và update harness định kỳ tốn nhân lực, chậm, và không scale được.
Nếu approach này work ở production scale, nó có thể thay đổi cách chúng ta nghĩ về agent maintenance. Thay vì "deploy rồi maintain bằng tay", bạn có thể có một hệ thống tự evolve trong khi đang serve traffic thật.
Một điểm mình còn chưa rõ là chi phí compute của cái multi-agent evolver pipeline này chạy Analyst → Researchers → Builder → Verifier cho mỗi evolution cycle chắc không rẻ. Paper chưa breakdown rõ phần này. Nếu bạn có thời gian đọc full paper, mình rất muốn nghe feedback về phần cost analysis của họ.
Overall, đây là một trong những paper agentic system đáng đọc nhất mình thấy gần đây không phải vì nó làm model mạnh hơn, mà vì nó tackle đúng vấn đề operational mà engineer thực tế phải đối mặt.
Nguyễn Nhật Long
@nguyennhatlong1303Nguyễn Nhật Long is a Senior Frontend Engineer and Frontend Team Leader with 7 years of experience building real-time fintech platforms. Specializing in React, Next.js, TypeScript, and React Native, shipping 10+ products across Web, Mobile, Telegram Mini-Apps, and Web3.
Thấy hay? Chia sẻ cho bạn bè!