Nghiên cứu thực nghiệm về thiết kế harness cho agent lập trình

Các agent lập trình tự động đang trở thành một trong những hướng ứng dụng thực tiễn nhất của AI tạo sinh. Thay vì chỉ sinh ra vài đoạn mã rời rạc, chúng có thể tự đọc mã nguồn, chạy lệnh, sửa lỗi và hoàn thành những tác vụ kỹ thuật phần mềm kéo dài hàng giờ. Nhưng yếu tố quyết định năng lực đó không chỉ nằm ở mô hình nền tảng, mà còn ở harness — lớp khung điều phối bao quanh mô hình.

Một bài báo mới trên arXiv mang tên An Empirical Study of Harness Design for Coding Agents đã tách nhỏ câu hỏi này để xem từng thành phần của harness thực sự đóng góp bao nhiêu.

Harness là gì và vì sao cần mổ xẻ từng thành phần?

Trong bối cảnh agent lập trình, harness là toàn bộ hạ tầng phần mềm bao quanh mô hình ngôn ngữ: vòng lặp thực thi, cách gọi công cụ, cách quản lý lịch sử hội thoại, cách lập kế hoạch và giới hạn ngân sách ngữ cảnh.

Các nghiên cứu trước đây thường đánh giá harness như một khối thống nhất. Điều đó khiến giới phát triển không biết thành phần nào thật sự mang lại giá trị, thành phần nào chỉ làm hệ thống cồng kềnh thêm. Nhóm tác giả đã chọn cách tiếp cận khác: cố định vòng lặp thực thi, rồi lần lượt thay đổi ba biến số là lập kế hoạch (planning), không gian hành động (action space) và quản lý ngữ cảnh (context management).

Thử nghiệm được chạy trên SWE-Bench Verified và Terminal-Bench 2.1 với bốn mô hình khác nhau, tổng cộng 176 cấu hình tương ứng, bao gồm năm chiến lược quản lý ngữ cảnh và bốn mức ngân sách cửa sổ ngữ cảnh.

Quản lý ngữ cảnh: càng siết chặt, càng quan trọng

Phát hiện đầu tiên khá trực quan nhưng có ý nghĩa thực tiễn lớn: giá trị của quản lý ngữ cảnh tăng lên khi ngân sách cửa sổ ngữ cảnh bị thu hẹp. Phần lớn lợi ích đến từ việc ngăn chặn lỗi tràn ngữ cảnh — tình huống agent đang làm dở dang thì hết chỗ nhớ và buộc phải dừng.

Điều này lý giải vì sao nhiều agent lập trình thất bại ở các tác vụ dài: vấn đề không nằm ở năng lực suy luận của mô hình, mà ở chỗ harness không biết cách dọn dẹp bộ nhớ.

Về chiến lược cụ thể, nhóm nghiên cứu phát hiện rằng áp dụng quy tắc loại bỏ nội dung (rule-based elision) trước, rồi mới tóm tắt bằng LLM cho hiệu quả tổng thể tốt nhất. Ngược lại, việc làm cho nội dung đã bị loại bỏ có thể khôi phục được lại bổ sung thêm cơ chế phức tạp mà mô hình hiếm khi dùng, và không cải thiện độ chính xác.

Lập kế hoạch: từ chỗ hỗ trợ độ chính xác sang tiết kiệm chi phí

Kết quả về planning cho thấy một sự dịch chuyển thú vị theo năng lực mô hình.

• Với các mô hình yếu hơn, lập kế hoạch đóng vai trò giàn giáo nâng độ chính xác.
• Với các mô hình mạnh hơn, nó chuyển thành công cụ tiết kiệm chi phí, trong khi độ chính xác gần như không đổi.

Nói cách khác, khi mô hình đã đủ giỏi, việc bắt nó lập kế hoạch chi tiết trước khi hành động chủ yếu giúp tránh đi lạc đường — tức tránh đốt token vào những hướng vô ích — hơn là giúp tìm ra đáp án đúng.

Không gian hành động: bash có thể là đủ

Phát hiện thứ tư liên quan trực tiếp đến thiết kế công cụ. Bộ công cụ định sẵn (predefined tools) giúp ích cho những mô hình yếu về bash. Nhưng với các mô hình thành thạo bash, giao diện chỉ có bash vẫn vận hành hiệu quả và tiết kiệm chi phí đáng kể, đặc biệt trên các tác vụ thiên về dòng lệnh.

Đây là gợi ý đáng cân nhắc cho các đội đang xây dựng agent nội bộ: không phải lúc nào cũng cần một bộ API công cụ đồ sộ. Với mô hình đủ mạnh, để agent dùng terminal trực tiếp có thể vừa đơn giản vừa rẻ hơn.

Phân tích quỹ đạo: vì sao các hiệu ứng này xảy ra

Nhóm tác giả không dừng ở số liệu tổng hợp mà đi sâu phân tích quỹ đạo thực thi (trajectory-level analysis) để giải thích cơ chế:

• Quản lý ngữ cảnh kéo dài quỹ đạo thực thi mà không thay đổi đáng kể hành vi của agent.
• Lập kế hoạch thay đổi điểm dừng của quỹ đạo — tức agent dừng lại ở đâu.
• Không gian hành động thay đổi độ chi tiết mà mã được viết ra.

Cách lý giải này hữu ích vì nó biến những con số rời rạc thành mô hình tư duy có thể áp dụng khi thiết kế harness mới.

Ý nghĩa cho cộng đồng phát triển tại Việt Nam

Với các nhóm kỹ sư Việt Nam đang thử nghiệm agent lập trình trong quy trình phát triển phần mềm, bài báo đưa ra vài bài học thực tế:

• Đừng xem harness là hộp đen. Từng thành phần có thể được đo lường và tinh chỉnh riêng.
• Ưu tiên quản lý ngữ cảnh nếu bạn đang chạy agent trên các tác vụ dài với chi phí API hạn chế.
• Cân nhắc theo năng lực mô hình. Cùng một thiết kế harness có thể tối ưu cho mô hình này nhưng lãng phí với mô hình khác.

Nhóm tác giả kỳ vọng kết quả này sẽ định hướng cho việc thiết kế harness nhận biết mô hình và ngân sách, đồng thời cung cấp một khuôn khổ module để đánh giá các thành phần harness trong tương lai. Với tốc độ phát triển của agent lập trình hiện nay, những nghiên cứu mổ xẻ ở mức thành phần như thế này có thể hữu ích hơn cả việc chạy đua benchmark.