Harness-of-Harness: coding agent mạnh lên nhờ một vòng kiểm soát bên ngoài
HoH bọc coding harness trong vòng Planner–Developer–QA, giữ artifact và evidence qua từng phiên để phần mềm tiến bộ mà không giao cho agent quyền tự chấm bài.
Một coding agent giỏi có thể sửa một bug hoặc dựng nhanh một tính năng. Nhưng khi phải xây cả sản phẩm qua hàng chục vòng, vấn đề khó nhất không còn là viết code. Agent phải nhớ điều gì đã được xác minh, chọn đúng bước tiếp theo, không phá chức năng cũ, và biết lúc nào lời tuyên bố “đã xong” chưa đủ bằng chứng.
Harness-of-Harness (HoH), nghiên cứu mới của nhóm tác giả tại Shanghai AI Laboratory, đưa ra một câu trả lời đáng chú ý: thay vì chỉ cho coding agent thêm thời gian hoặc context, hãy đặt toàn bộ coding harness vào một vòng phát triển bên ngoài gồm lập kế hoạch → triển khai → kiểm thử độc lập.
Điểm quan trọng cần nói ngay: HoH không huấn luyện lại model và cũng không chứng minh model tự học. Model, coding harness, định nghĩa vai trò và runtime policy được giữ cố định trong một run. Thứ tiến bộ qua từng vòng là software artifact, kế hoạch phát triển và bằng chứng kiểm thử.
Coding agent dài hạn thất bại khác một lượt code ngắn
Một lượt coding thông thường có thể kết thúc sau khi agent sửa file, chạy test và báo hoàn tất. Với dự án dài hạn, ba vấn đề dần tích tụ:
- Mất liên tục: code hiện tại cho biết hệ thống đang có gì, nhưng không nói đầy đủ vì sao một quyết định được chọn, lỗi nào còn mở hoặc hành vi nào đã từng được xác minh.
- Chọn sai bước tiếp theo: agent có thể mắc kẹt trong sửa lỗi cục bộ, mở rộng phạm vi quá lớn hoặc làm một thay đổi hợp lý ở một module nhưng phá ràng buộc nơi khác.
- Tự xác nhận quá sớm: test do chính người triển khai chọn rất hữu ích để debug, nhưng chưa đủ làm bằng chứng chấp nhận độc lập.
HoH xem đây là vấn đề điều phối và quản trị trạng thái, không chỉ là vấn đề model intelligence.
Một vòng HoH có ba vai trò và một runtime xác định
Mỗi vòng bắt đầu từ specification tổng thể, phiên bản phần mềm hiện tại và evidence của vòng trước.
1. Project Planner chọn một increment quan sát được
Planner đọc yêu cầu toàn cục, codebase ở chế độ chỉ đọc và bằng chứng trước đó. Nó chọn một mục tiêu bounded nhưng locally complete: phạm vi đủ nhỏ để chẩn đoán, nhưng đủ đầy để tạo ra một hành vi có thể nhìn thấy và kiểm thử.
Development document phải nêu:
- nhóm tác vụ liên quan;
- chức năng cũ cần được bảo toàn;
- điều kiện quan sát dùng để xác minh increment.
Planner không sửa code. Việc tách quyền này buộc quyết định “làm gì tiếp theo” đứng riêng khỏi quyết định “triển khai bằng cách nào”.
2. Developer là người ghi duy nhất
Developer warm-start từ artifact đã có và là vai trò duy nhất được sửa workspace. Trong phạm vi mục tiêu, nó vẫn có quyền tự chọn thiết kế, tool và cách debug.
HoH không áp đặt một chuỗi suy luận cứng. Framework ràng buộc đầu ra có thể kiểm chứng và quyền truy cập, chứ không quy định agent phải nghĩ theo từng bước nào. Developer phải kiểm tra baseline trước khi sửa, retest sau các thay đổi có ý nghĩa và quan sát vùng regression liên quan. Tuy nhiên, self-test chỉ chứng minh candidate đủ sẵn sàng để chuyển sang QA, không tự động chứng minh yêu cầu sản phẩm đã đạt.
3. QA Tester kiểm tra một candidate bị đóng băng
QA nhận đúng một phiên bản artifact ở chế độ read-only, cùng kết quả build và execution check xác định. Nó không được âm thầm sửa candidate trong khi đánh giá.
QA dùng cả:
- black-box test để quan sát luồng người dùng, output và state transition;
- white-box test để kiểm tra source, config, resource binding, runtime state và log.
Mỗi claim chỉ được xác minh khi có record gắn với đúng candidate hỗ trợ claim đó. Failure, regression hoặc evidence chưa đủ phải được ghi thành gap thay vì suy diễn là thành công.
4. Runtime giữ ranh giới thật, không chỉ nhắc bằng prompt
Runtime đóng băng input của từng vai trò, áp quyền đọc/ghi, kiểm tra output schema và gắn evidence với đúng revision. Output sai schema sẽ bị retry. Đây là chi tiết production quan trọng: role separation chỉ đáng tin khi quyền hạn được hệ thống thực thi, không phải khi ba agent cùng có toàn quyền nhưng được nhắc “hãy độc lập”.
HoH mang qua hai loại trạng thái
Giữa hai vòng, HoH giữ đồng thời:
- Artifact state: source code, config, tài nguyên và metadata của phần mềm hiện tại.
- Evidence state: hành vi đã xác minh, claim chưa đủ bằng chứng, failure quan sát được và yêu cầu còn thiếu.
Chỉ giữ code là chưa đủ, vì vòng sau sẽ phải đoán lại lịch sử dự án từ implementation. Chỉ giữ report cũng chưa đủ, vì agent cần đúng artifact để tiếp tục. HoH cho rằng artifact continuity làm phát triển trở nên incremental, còn evidence-guided planning làm nó trở nên iterative.
Để không nhồi toàn bộ lịch sử vào context, kế hoạch, report, history, tool và skill được lưu trên filesystem rồi đưa ra qua một index ngắn. Agent chỉ mở phần chi tiết khi cần. Nhóm tác giả gọi cách này là progressive disclosure, thay vì dùng một memory module chuyên biệt.
Kết quả benchmark: tăng không chỉ vì chạy thêm lượt
Nhóm tác giả thử HoH trên ba benchmark và ba cặp harness–model:
- Codex CLI với GPT-5.5 ở reasoning high;
- OpenCode với DeepSeek-V4-Pro;
- Pi Coding Agent với MiniMax-M3.
Sau ba vòng, HoH tốt hơn baseline standalone ở cả ba cấu hình. Trên GameCraft-Bench, điểm Overall tăng:
- Codex: 49,58 → 71,52;
- OpenCode: 26,90 → 48,98;
- Pi: 42,16 → 58,78.
Trên ProgramBench, average test pass rate tăng lần lượt từ 60,41 → 66,50, 45,27 → 57,56 và 35,83 → 52,68. Trên FrontierSWE, dominance tăng thêm 19–29 điểm phần trăm sau ba vòng tùy cấu hình.
Một phép so sánh quan trọng dùng cùng Codex/GPT-5.5 cho thấy chạy Vanilla nhiều lượt vẫn không bằng HoH. Sau ba development pass, Vanilla Continuation đạt 58,24 điểm với 6,33 triệu token/task, trong khi HoH@2 đã đạt 64,84 điểm với 5,67 triệu token/task. HoH@3 đạt 71,52 nhưng dùng 8,41 triệu token/task. Điều này ủng hộ nhận định rằng lợi thế không chỉ đến từ việc tiêu nhiều inference hơn.
Ablation cũng cho thấy ba cơ chế đều có vai trò. So với HoH@3 đầy đủ ở 71,52 điểm:
- không cập nhật plan: giảm 8,13 điểm;
- không đưa execution evidence vào replanning: giảm 6,28 điểm;
- không warm-start artifact: giảm 7,85 điểm, đồng thời token tăng từ 8,41 lên 11,12 triệu/task vì phải tái dựng.
Trên 15 task FrontierSWE, cấu hình Codex tiếp tục chạy mười vòng. Dominance đạt đỉnh 76,00% ở vòng 9 và còn 72,67% ở vòng 10, so với 27,33% của Vanilla trong comparison pool được dùng cho thí nghiệm này. Đường tiến bộ vì vậy mạnh nhưng không hoàn toàn đơn điệu.
Hơn 70 vòng tạo game, nhưng không phải câu chuyện “AI tự làm hoàn hảo”
Trong case study Fusepoint, HoH dùng Codex CLI với GPT-5.6-Sol để xây một game FPS từ PRD ban đầu. Agent được trang bị Godot, Godot MCP, skill tạo asset, UI/UX và testing. Lịch sử code, issue và evidence packet được giữ qua GitHub.
Sau 70 vòng, hệ thống đã tạo một game có cốt truyện, combat, nhiệm vụ, giao diện, hình ảnh và âm thanh. Nhưng dữ liệu chi tiết đáng chú ý hơn demo đẹp: 81 issue được ghi nhận, 65 đã đóng, 16 vẫn mở và 17 issue từng đóng phải mở lại khi regression xuất hiện.
Con số này cho thấy đúng bản chất của phát triển dài hạn. HoH không xóa lỗi; nó biến lỗi, bằng chứng và regression thành trạng thái có thể truy vết để vòng sau xử lý, thay vì để chúng biến mất trong transcript.
Những giới hạn cần giữ tỉnh táo
Đây là arXiv v1 và kết quả hiện do chính nhóm tác giả báo cáo. GameCraft-Bench dùng mẫu 45/140 task; FrontierSWE dùng 15/17 task. Token accounting khác giữa provider và có thể gồm cached reads, nên paper chỉ khuyến nghị so sánh trong từng cấu hình, không quy đổi trực tiếp thành chi phí giữa các model.
Case FPS cũng dùng thêm tool, skill và hạ tầng theo miền; vì vậy chưa thể kết luận chỉ cần ba prompt Planner–Developer–QA là mọi coding agent sẽ tự xây sản phẩm production. Repository chính cho biết bản HoH-lite vẫn “coming soon” tại thời điểm bài này được viết, nên khả năng tái lập framework đầy đủ còn hạn chế.
Quan trọng hơn, independent QA ở đây là tách vai trò và quyền truy cập trong cùng fixed harness–model configuration. Nó giảm việc developer tự chấm bài, nhưng chưa loại bỏ hoàn toàn correlated blind spots của cùng một model family. Hệ thống production vẫn nên bổ sung deterministic tests, hidden holdout, evaluator khác biệt và human approval cho thay đổi rủi ro cao.
Góc nhìn của Bé Mi: cải thiện project, không thần thoại hóa model
Điểm hay nhất của HoH không nằm ở việc gọi ba agent thay vì một. Nó nằm ở năm ranh giới có thể triển khai:
- mỗi vòng chỉ có một increment quan sát được;
- planner không viết code;
- developer là single writer;
- QA đọc candidate đóng băng và không được sửa;
- evidence phải gắn với đúng revision trước khi chuyển sang vòng sau.
Đó là cách chuyển coding agent từ “một phiên chat biết gọi terminal” thành một quy trình phát triển có lịch sử, quyền hạn và tiêu chuẩn chấp nhận.
HoH cũng nhắc rằng context dài không phải là memory hoàn chỉnh, chạy thêm lượt không phải là continual improvement, và test do người viết code chạy không phải là independent acceptance. Năng lực coding dài hạn xuất hiện khi artifact tốt được giữ lại, evidence xấu không bị quên, và vòng kiểm soát bên ngoài vẫn có quyền nói chưa đạt.
Nguồn chính: arXiv:2609.01481 — Harness-of-Harness: Multi-Day Autonomous Software Development with Continual Improvement · Project page · GitHub repository · Fusepoint trajectory