- Kết quả thử nghiệm nhiều LLM trong cùng điều kiện cho thấy chỉ cần thay công cụ chỉnh sửa mã cũng có thể cải thiện hiệu năng đáng kể
- Thay vì phương thức Patch·Replace hiện có, nghiên cứu áp dụng định dạng ‘Hashline’ gắn thẻ băm cho từng dòng mã để nâng độ chính xác khi chỉnh sửa
- Hashline cho độ chính xác cao hơn cách cũ ở 14 trên 16 mô hình, đồng thời xác nhận hiệu quả giảm trung bình 20~30% số token
- Đặc biệt, mô hình Grok Code Fast 1 tăng vọt tỷ lệ thành công từ 6.7% lên 68.3%; chỉ với thay đổi harness đơn giản mà đã cải thiện gấp 10 lần
- Nghiên cứu cho thấy ‘harness’ mới là nút thắt cổ chai của hiệu năng thực tế, hơn là bản thân mô hình, và nhấn mạnh sự cần thiết của hợp tác trong hệ sinh thái mã nguồn mở
Tổng quan benchmark chỉnh sửa mã
- Thử nghiệm được tiến hành bằng cách so sánh ba định dạng chỉnh sửa: Patch, Replace, Hashline
- 16 mô hình thực hiện cùng một bài toán sửa mã trong điều kiện giống nhau
- Mỗi mô hình được kiểm tra bằng cách sửa lỗi trong một tệp được chọn ngẫu nhiên từ codebase React
- Định dạng Hashline cho kết quả tốt hơn Patch ở 14 mô hình và tiết kiệm trung bình 20~30% token
- Mức cải thiện lớn nhất là ở mô hình Grok Code Fast 1, với tỷ lệ thành công tăng từ 6.7% lên 68.3% (+61.6 điểm phần trăm)
- Gemini 3 Flash tăng 5.0 điểm phần trăm, Claude Sonnet 4.5 tăng 1.6 điểm phần trăm
Vấn đề của harness
- Thảo luận hiện nay chủ yếu tập trung vào câu hỏi “mô hình nào giỏi lập trình nhất”, nhưng nút thắt thực tế lại là harness chứ không phải mô hình
- Harness là giao diện cốt lõi quản lý token đầu vào và kết nối đầu ra của mô hình với thay đổi trong workspace
- Phần lớn thất bại không đến từ mô hình mà từ giới hạn cấu trúc của harness
- Tác giả đã thử cải thiện thông qua dự án cá nhân oh-my-pi, một bản fork của tác nhân lập trình mã nguồn mở Pi, với khoảng 1.300 commit
- Môi trường này độc lập với mô hình, cho phép thí nghiệm khi chỉ coi harness là biến số
Giới hạn của các công cụ chỉnh sửa hiện có
- Phương thức
apply_patch của Codex dùng định dạng diff dành riêng cho OpenAI nên tỷ lệ thất bại cao với các mô hình khác
- Ví dụ: tỷ lệ patch thất bại của Grok 4 là 50.7%, GLM-4.7 là 46.2%
- Phương thức
str_replace của Claude Code yêu cầu chuỗi phải khớp hoàn toàn, nên dễ lỗi do khác biệt khoảng trắng hoặc thụt dòng
- Lỗi “String to replace not found in file” đã được báo cáo nhiều trên GitHub
- Cursor xử lý việc hợp nhất bằng một mô hình 70B được huấn luyện riêng, nhưng với các tệp dưới 400 dòng thì viết lại toàn bộ (full rewrite) cho kết quả tốt hơn
- Các nghiên cứu Diff-XYZ và EDIT-Bench của JetBrains cũng xác nhận rằng hiệu năng thay đổi mạnh tùy theo định dạng chỉnh sửa
Nguyên lý của phương thức Hashline
- Mỗi dòng mã được gắn một mã băm nội dung dài 2~3 ký tự để mô hình có thể chỉ định chính xác mục tiêu cần sửa
- Ví dụ:
22:f1| return "world";
- Mô hình yêu cầu chỉnh sửa dựa trên mã băm, như “replace line 2:f1”
- Nếu tệp đã thay đổi và mã băm không còn khớp, chỉnh sửa sẽ bị từ chối để tránh làm hỏng nội dung
- Cách này giúp mô hình không cần tái tạo lại nội dung hiện có, từ đó giảm lỗi khoảng trắng·thụt dòng và cho phép chỉnh sửa ổn định hơn
Kết quả benchmark
- Bài kiểm tra gồm 180 tác vụ sửa lỗi, lặp lại 3 lần, với 4 công cụ (read, edit, write, v.v.)
- Kết quả cho thấy định dạng Patch gần như tệ nhất ở mọi mô hình, còn Hashline tương đương hoặc tốt hơn Replace
- Mô hình càng yếu thì mức cải thiện càng lớn
- Grok 4 Fast giảm 61% token đầu ra, MiniMax cải thiện hơn gấp đôi
- Tỷ lệ thành công của Gemini tăng +8% là mức cải thiện lớn hơn cả một lần nâng cấp mô hình thông thường, và đạt được mà không cần huấn luyện bổ sung
Chính sách của vendor và hệ sinh thái mã nguồn mở
- Anthropic đã chặn quyền truy cập Claude Code của tác nhân lập trình mã nguồn mở OpenCode
- Lý do được đưa ra là “đảo ngược kỹ thuật API không công khai”, nhưng trên thực tế bị hiểu là tín hiệu “hãy chỉ dùng harness của chúng tôi”
- Google đã khóa tài khoản của tác giả, chặn quyền truy cập Gemini
- Việc này xảy ra ngay sau benchmark cho thấy hiệu năng Gemini 3 Flash tăng lên 78.3% nhờ áp dụng Hashline
- Tác giả chỉ ra rằng các biện pháp này là hành động thụt lùi, cản trở cơ hội cải thiện mô hình
- Tối ưu hóa harness là nghiên cứu công ích giúp nâng chất lượng cho mọi mô hình, không chỉ một mô hình cụ thể
- Với cách nói “mô hình là hào lũy, harness là cây cầu”, tác giả nhấn mạnh rằng cách tiếp cận khép kín đang cản trở sự phát triển của hệ sinh thái
Kết luận
- Vấn đề harness đã được xác nhận là yếu tố có thể đo lường và tác động trực tiếp đến hiệu năng thực tế
- Chỉ với thay đổi định dạng đơn giản cũng có thể đạt mức cải thiện tương đương nâng cấp mô hình
- Hướng phát triển trong tương lai nên là hợp tác công khai dựa trên cộng đồng, thay vì cải tiến khép kín của một công ty đơn lẻ
- Toàn bộ mã nguồn, benchmark và kết quả chạy đều được công khai trong kho GitHub oh-my-pi
3 bình luận
Mô hình có gì đó kỳ lạ, sao lại phải làm prompt engineering nữa..
Harness và kỹ thuật prompt là hai chuyện hoàn toàn khác nhau.
Ý kiến trên Hacker News
Tôi đã đọc bài này với sự hứng thú thật sự. Tôi nghĩ tác giả đã chỉ ra đúng trọng tâm
Ngay cả với các model hiện có, vẫn còn rất nhiều dư địa để làm chúng hiệu quả hơn tùy vào cách chúng ta thiết kế agent harness.
Tôi cho rằng nên nhìn “AI” không chỉ là bản thân LLM, mà là toàn bộ hệ thống cybernetic nơi LLM và harness được nối với nhau bằng một vòng lặp phản hồi.
Model và harness củng cố lẫn nhau và cùng tiến hóa, nên cả hai đều quan trọng như nhau.
Góc nhìn này không chỉ giúp cải thiện hiệu năng mà còn cho phép diễn giải lại generative AI như một dự án neurosymbolic
Tôi thực sự đã làm một coding agent bằng GPT-4 phiên bản 2023.
Làm việc với model cũ buộc bạn phải giữ mọi thứ đơn giản, nên đôi khi lại khiến bạn nhìn vấn đề theo cách khác.
Ví dụ, trong Python, một dạng semantic compression đơn giản như
grep -r def .là thiết yếu.Nếu thêm một hook đơn giản như vậy vào các công cụ như Claude Code, có thể nắm được ngay cấu trúc code mà không lãng phí token
Chỉ với vài giờ prompt tuning và một ít code xử lý phản hồi, chất lượng đầu ra của các model cục bộ nhỏ đã được cải thiện đáng ngạc nhiên
Liên kết GitHub
OpenAI đã dùng phiên bản đầu của GPT-5.3-Codex để debug quy trình huấn luyện nội bộ và quản lý triển khai.
Claude Code nộp hơn 20 PR mỗi ngày, tất cả đều do chính nó sinh code
Thực tế chúng ta thậm chí còn chưa biết rõ model nào nhạy với context engineering tốt.
Nhưng tôi chắc chắn đồng ý rằng vẫn còn rất nhiều trái thấp dễ hái (low hanging fruit)
Công nghệ này thú vị, nhưng có cảm giác đang bị đánh giá quá cao.
Tác giả thấy benchmark find/replace đơn giản mà mình tạo ra cải thiện 5%, rồi nói như thể hiệu năng tổng thể đã tăng 14 điểm.
Trên thực tế, rất có thể mức cải thiện trên hiệu quả token tổng thể là dưới 1%.
Thêm nữa, giọng điệu cường điệu và văn phong kiểu ChatGPT trong bài làm giảm độ tin cậy
Bài này cho thấy rất rõ mức độ còn nhiều chỗ để cải thiện ở tầng harness.
Các agent đang lãng phí rất nhiều token trong việc chỉnh sửa, sandbox, và truyền dữ liệu giữa các lần gọi tool.
Sự kết hợp giữa địa chỉ hóa theo nội dung + đánh số dòng vừa thực dụng vừa đẹp
Dù giúp giai đoạn phát triển ban đầu dễ hơn, nó lại gây kém hiệu quả vì phải gọi những model lớn không cần thiết
Trong CC có thể dùng lệnh
/costđể xem chi phí theo từng session, và dùng chỉ số đó để đánh giá hiệu quả của plugin là một ý hayTầm quan trọng của harness lớn hơn rất nhiều so với những gì đa số mọi người nghĩ.
Ví dụ, điểm benchmark CORE của Opus gần như tăng gấp đôi khi chuyển từ harness nội bộ sang Claude Code
Liên kết liên quan
cũng giải thích rằng điểm TerminalBench cao nhất đạt được là nhờ harness Terminus 2
Bị khóa vào một harness cụ thể chỉ vì gói thuê bao 20 USD/tháng là điều vô lý
Tôi đã tạo một công cụ tên tilth để triển khai cách đọc/chỉnh sửa dựa trên hash.
Có thể cài qua npm và cargo, đồng thời tích hợp với các editor như Claude Code hoặc Cursor
Liên kết GitHub
Mục tiêu là giúp LLM dùng tool hiệu quả hơn và giảm lãng phí token
Tôi cũng từng nghĩ ra một phương pháp tương tự một cách độc lập, nhưng đã bỏ vì phụ thuộc vào abstraction.
Thay vào đó tôi dùng khoảng cách Damerau-Levenshtein để tính độ tương đồng của chỉnh sửa, và nếu vượt qua một ngưỡng nhất định thì cho phép sửa được áp dụng.
Cách này buộc model phải xuất rõ các source token sẽ được thay thế, nên độ chính xác cao hơn
Ví dụ mã
Điểm mấu chốt là thông báo lỗi phải cụ thể — xử lý lỗi kiểu kèm chỉ dẫn khôi phục như “Content mismatch. Reread the file” là rất quan trọng.
Cách này hoạt động tốt ngay cả với model 4B, và với các model không hỗ trợ tool call thì tôi xử lý bằng mẹo tiêm system prompt
Mã liên quan
Ngay cả với các model cũ, vẫn có thể có được kết quả khá chính xác.
Điều cốt lõi là phải “đối xử đúng cách” với model.
Bài này gợi ý rằng nếu model có thể trực tiếp thao tác trên biểu diễn có cấu trúc của source code (AST) chứ không chỉ văn bản, thì kết quả sẽ còn lớn hơn nhiều.
Ví dụ, OpenRewrite dùng Lossless Semantic Tree bao gồm đầy đủ thông tin về kiểu, định dạng và phụ thuộc của code.
Nếu model có thể tận dụng cấu trúc như vậy, nó sẽ sửa rất chính xác mà không lãng phí token không cần thiết.
Cuối cùng thì đây cũng giống như lý do câu trả lời cho cuộc tranh luận “Vim vs Emacs” lại là “IntelliJ” — thông tin có cấu trúc là một vũ khí cực mạnh.
Nếu model được học cùng với code, tài liệu, và cả cây cú pháp/ngữ nghĩa, thì đó sẽ là một coding model neurosymbolic thực sự
Khi thử nghiệm LLM bằng gptel trong Emacs, tôi nhận ra LLM không giỏi sửa code bằng công cụ Unix patch.
Vì vậy tôi đã tự làm tool cho gptel bằng cách tận dụng tree-sitter của Emacs.
Sau khi để nó sửa trực tiếp các AST node bằng các lệnh như
tree_sitter_list_nodes,tree_sitter_update_nodes, mọi thứ hoạt động hoàn hảoapply_patchcủa Codex thực ra dùng một schema lấy mẫu có ràng buộc.Mã liên quan
Tác giả đã so sánh đơn giản mà không biết điều này, nên benchmark thực tế hơn cần được chạy khi schema đó được bật
Trong các trích dẫn của bài này, có một đoạn khiến tôi đặc biệt ấn tượng
“Không phải model không hiểu vấn đề, mà là cách biểu diễn không ổn định. Đừng đổ lỗi cho phi công vì vấn đề ở càng hạ cánh.”
“Model là hào lũy (moat), harness là cây cầu (bridge).”
“Khác biệt giữa một bản demo hào nhoáng và một công cụ đáng tin cậy không phải là phép màu, mà là kỹ thuật nhàm chán nhưng tinh xảo.”