Bạn Không Cần Model Mạnh Hơn. Bạn Cần Harness Tốt Hơn.

Câu hỏi tôi nghe nhiều nhất trong một năm qua, từ cả khách hàng lẫn đồng nghiệp, luôn có cùng một hình dạng: "Nên dùng model nào?"

Claude hay GPT. Bản mới ra có hơn bản cũ không. Con số trên bảng xếp hạng tuần này là bao nhiêu. Cứ như thể chọn đúng ô trong bảng so sánh là xong việc.

Tôi đã hỏi y hệt như vậy suốt một thời gian dài. Và tôi sai — không phải sai chi tiết, mà sai ở chỗ tôi đang nhìn vào biến số ít quan trọng hơn.

Đây không phải bài chê model. Model giỏi vẫn hơn model dở. Nhưng có một lớp khác, nằm ngay dưới mũi chúng ta, quyết định kết quả mạnh hơn — và gần như không ai đưa nó vào bảng so sánh.

Con số khiến tôi phải đổi ý

Tháng 5/2026, một nhóm nghiên cứu công bố Harness-Bench (nộp ngày 27/5/2026) — bài đo đạc thẳng vào câu hỏi này. Thiết kế của nó đơn giản đến mức tàn nhẫn: lấy 6 harness khác nhau, ghép chéo với 8 model backend (Claude Opus/Sonnet, Gemini, Qwen, GLM, Kimi, GPT-5.4, DeepSeek), chạy trên 106 tác vụ giống hệt nhau, thu về hơn 5.000 lượt thực thi.

Cùng bộ tác vụ. Cùng dàn model. Chỉ khác cái harness bọc quanh.

Kết quả tổng hợp: harness thấp nhất đạt 52,4%. Harness cao nhất đạt 76,2%.

Khoảng cách 23,8 điểm phần trăm — sinh ra từ thứ không phải model.

Hãy dừng lại ở con số đó một nhịp. 23,8 điểm là khoảng cách lớn hơn phần lớn những gì bạn thấy giữa hai thế hệ model liền kề. Nó lớn hơn cái khoảng cách mà cả ngành đang cãi nhau mỗi lần có bản phát hành mới. Và nó đến từ lớp mà hầu hết đội ngũ coi là "phần cắm dây cho xong".

Kết luận của nhóm tác giả viết thẳng:

Năng lực của agent nên được hiểu là thuộc tính của một model nằm trong một hệ thống thực thi, chứ không phải thuộc tính của riêng model nền.

Tệ hơn: harness đảo được cả thứ hạng

Nếu chỉ là chuyện điểm cao thấp thì còn dễ sống. Vấn đề sâu hơn nằm ở một bài khác, nộp ngày 7/5/2026, với cái tên nói đúng vấn đề: Stop Comparing LLM Agents Without Disclosing the Harness.

Phát hiện trung tâm: phương sai do harness gây ra có thể lớn hơn hẳn phương sai do model gây ra. Và hệ quả của nó thì khó chịu thật sự — thứ hạng giữa các model có thể đảo ngược tuỳ theo harness bạn dùng để đo.

Đọc lại câu đó lần nữa. Model A thắng model B trong harness này, và thua chính model B trong harness khác. Cùng tác vụ.

Nghĩa là mỗi lần bạn đọc một dòng "model X vượt model Y", câu đó chỉ có nghĩa nếu kèm theo harness nào đã được dùng để đo. Không có thông tin đó, bảng xếp hạng không nói cho bạn biết model nào tốt hơn. Nó nói cho bạn biết tổ hợp model-harness nào đã được đo. Hai chuyện khác nhau hoàn toàn.

Nhóm tác giả đề xuất một điều mà đáng lẽ phải là mặc định từ lâu: bắt buộc công bố harness trước khi so sánh bất kỳ agent nào.

Agent = Model + Harness. Bạn không mua một model. Bạn vận hành một tổ hợp. Và tổ hợp đó có thể xê dịch hơn 20 điểm phần trăm mà không cần đổi lấy một chữ nào trong model.

Không phải lý thuyết: Epoch AI đã tự chứng minh

Đến đây sẽ có người nói: nghiên cứu học thuật thì hay đấy, nhưng thực tế khác.

Vậy hãy nhìn vào Epoch AI — một tổ chức đánh giá độc lập, chuyên chấm SWE-bench Verified. Họ không có động cơ thổi phồng chuyện này.

Tháng 2/2026, Epoch nâng cấp scaffold, môi trường chạy và giới hạn token lên bản v2.0.0. Không đổi model. Chỉ đổi lớp bọc quanh model.

Kết quả: điểm của các model cải thiện đáng kể — đủ đáng kể để Epoch phải tuyên bố rằng kết quả trước v2.0.0 không còn so sánh trực tiếp được nữa, và biểu đồ mặc định của họ chỉ hiển thị số liệu từ v2.0.0 trở đi.

Một tổ chức đo lường chuyên nghiệp đã phải thiết lập lại đường cơ sở chỉ vì họ sửa cái harness. Đó không phải chi tiết kỹ thuật vụn vặt. Đó là lời thú nhận rằng lớp bọc quyết định con số.

Vậy harness rốt cuộc là gì?

Nói gọn: harness là tất cả những gì thuộc về agent, trừ model.

Model chỉ làm đúng một việc — nhận vào một đống chữ, đoán ra đống chữ tiếp theo. Mọi thứ còn lại là harness:

Ngữ cảnh: cái gì được đưa vào cửa sổ context, theo thứ tự nào, và cái gì bị cắt bỏ khi hết chỗ.
Công cụ: agent được đọc file, chạy shell, gọi API nào — và mô tả của các công cụ đó rõ đến đâu.
Quyền hạn: chỗ nào cần người duyệt, chỗ nào được tự chạy.
Bộ nhớ: agent nhớ gì giữa các phiên làm việc.
Vòng kiểm chứng: agent làm sao biết là nó đã làm đúng — test, linter, type-check, build.
Phục hồi: khi hỏng thì quay lui bằng cách nào.

Harness-Bench còn chỉ ra kiểu hỏng phổ biến nhất, và nó rất đáng suy nghĩ: "execution-alignment failures" — lập luận của model trôi dạt khỏi phản hồi thực tế của công cụ, khỏi trạng thái thật của workspace, khỏi bằng chứng kiểm chứng được.

Model không ngu đi. Nó chỉ mất kết nối với thực tại — vì harness không đưa thực tại về cho nó đủ nhanh. Đổi sang model thông minh hơn không sửa được lỗi đó. Nó chỉ khiến agent sai một cách trôi chảy hơn.

Đội mạnh nhất đã chuyển toàn bộ công sức sang harness

Bằng chứng thuyết phục nhất không nằm trong paper, mà nằm trong cách những đội đi xa nhất đang tiêu thời gian.

OpenAI công bố thí nghiệm harness engineering với Codex hồi tháng 2/2026. Trong 5 tháng, một nhóm khởi đầu chỉ 3 kỹ sư đã ship một sản phẩm thật với ~1.500 pull request được merge, khoảng một triệu dòng code — và không một dòng nào do người viết tay. Toàn bộ: logic, test, cấu hình CI, tài liệu, công cụ quan sát — đều do Codex viết. OpenAI ước tính họ làm việc đó trong khoảng 1/10 thời gian so với gõ tay. Khi đội tăng lên 7 người, throughput còn tăng thay vì chững lại.

Nhưng chi tiết đắt nhất không phải mấy con số đó. Mà là việc của các kỹ sư đã biến thành việc gì.

Họ gần như không viết code nữa. Họ mô tả tác vụ, cho agent chạy, để nó mở PR. Còn khi agent vấp, họ không đổi model — họ coi cú vấp đó là tín hiệu chỉ ra harness đang thiếu cái gì: thiếu công cụ, thiếu rào chắn, thiếu tài liệu. Rồi họ bổ sung đúng thứ còn thiếu vào repo, và bảo Codex tự viết bản vá.

Triết lý gói trong một câu: con người lái, agent thực thi.

Anthropic đi tới cùng một chỗ từ hướng khác. Trong bài Effective harnesses for long-running agents (26/11/2025), họ mô tả vấn đề cốt lõi của agent chạy dài bằng một hình ảnh rất đúng: giống một dự án phần mềm mà kỹ sư làm theo ca — mỗi ca đến là một người hoàn toàn không nhớ gì về ca trước.

Cửa sổ context có hạn. Việc thì dài hơn cửa sổ. Nên lời giải của họ hoàn toàn nằm ở harness: một agent khởi tạo dựng sẵn môi trường và ngữ cảnh nền, rồi bàn giao cho agent code tiến từng bước — với claude-progress.txt, lịch sử git, danh sách tính năng và cổng test bắt buộc làm phương tiện bàn giao giữa các ca.

Không có dòng nào trong lời giải đó nói về việc đổi model.

Và không, chuyện này sẽ không tự biến mất

Phản biện hợp lý nhất: rồi model sẽ nuốt hết harness vào trong, phải không? Đợi vài thế hệ nữa là xong.

Ngày 8/7/2026, Lilian Weng công bố một bài tổng hợp 35 nghiên cứu về harness engineering, và trả lời thẳng câu đó:

Ngay cả khi nhiều cải tiến harness rốt cuộc được nội hoá vào model, nhu cầu chỉ định mục tiêu và ngữ cảnh sẽ không biến mất.

Model có thể học được cách tự lập kế hoạch, tự kiểm tra, tự quay lui. Nhưng nó không bao giờ tự biết đâu là định nghĩa "xong" trong dự án của bạn, hệ thống nội bộ của bạn nằm ở đâu, luật ngành của bạn cấm gì, khách hàng của bạn thật ra muốn gì. Phần đó là của bạn. Vĩnh viễn.

Tôi đã sai chỗ nào

Nói cho sòng phẳng: trong một thời gian dài, mỗi lần agent làm hỏng việc, phản xạ đầu tiên của tôi là đổ cho model — rồi đi tìm bản mới hơn, chờ bản phát hành tiếp theo, đọc bảng xếp hạng như đọc bảng tỷ số.

Sai lầm không nằm ở chỗ tôi chọn nhầm model. Nó nằm ở chỗ tôi đã coi mỗi lần hỏng là giới hạn của model, thay vì là một lỗ hổng trong harness.

Gần như lần nào cũng vậy, mổ ra thì thấy: agent thiếu thông tin lẽ ra phải có sẵn; nó không có cách nào tự kiểm chứng việc mình vừa làm; nó không biết dự án này coi thế nào là "xong". Toàn bộ đều là thứ tôi sửa được trong buổi chiều — và không thứ nào cần một model mới cả.

Bảng xếp hạng dễ đọc hơn nhiều so với việc ngồi xuống thiết kế vòng kiểm chứng. Đó chính là lý do nó hấp dẫn.

Sửa gì, theo thứ tự nào

Nếu đội bạn đang dùng agent — viết code, xử lý nội dung, chăm khách — đây là thứ tự tôi khuyên, xếp theo tỷ lệ hiệu quả trên công sức:

Dựng vòng kiểm chứng trước tiên. Agent phải tự biết mình đúng hay sai mà không cần bạn nhìn: test, type-check, linter, build. Không có vòng này, mọi thứ khác chỉ là đoán. Đây là khoản đầu tư sinh lời cao nhất, luôn luôn.
Viết ra định nghĩa "xong". Thành file, trong repo, không nằm trong đầu ai. Agent không đọc được văn hoá công ty bạn.
Cắt ngữ cảnh thay vì nhồi ngữ cảnh. Cửa sổ to hơn không cứu bạn. Đưa đúng thứ cần, đúng lúc cần. Nhồi hết mọi thứ vào là cách nhanh nhất tạo ra execution-alignment failure.
Thiết kế đường bàn giao giữa các phiên. Nếu việc dài hơn một cửa sổ context — mà việc thật thì luôn dài hơn — bạn cần thứ tương đương claude-progress.txt: trạng thái ghi ra đĩa, commit sạch, test xanh trước khi hết ca.
Mỗi lần agent vấp, sửa harness — đừng đổi model. Đây là kỷ luật khó giữ nhất, và cũng là thứ phân biệt đội tiến bộ với đội cứ chạy vòng quanh. Mỗi cú vấp là một lỗ hổng đang chỉ tay vào chính nó.

Cái giá của việc nhìn nhầm chỗ

Đây là phần đáng tiền nhất của câu chuyện.

Đổi model là khoản chi. Xây harness là tài sản.

Mỗi lần bạn nâng model để mong hết lỗi, bạn trả tiền cho một cú hích một lần, rồi tháng sau lại trả tiếp. Bạn không tích luỹ được gì. Cái vòng kiểm chứng bạn dựng hôm nay thì ngược lại — nó còn nguyên giá trị khi model đổi thế hệ, và nó làm mọi model bạn cắm vào chạy tốt hơn. Harness-Bench cho thấy 23,8 điểm phần trăm đang nằm ở lớp đó. Đó là phần bạn sở hữu.

Và đây là chỗ đau nhất: đối thủ đang xây harness thì mỗi tháng lại nhanh hơn một chút, kể cả khi họ dùng model y hệt bạn. Còn đội chỉ chờ model mới thì đứng yên giữa các bản phát hành — rồi tự hỏi vì sao cùng công cụ mà người ta ship được, mình thì không.

Ba kỹ sư ở OpenAI ship một triệu dòng code trong 5 tháng không phải vì họ có model bí mật. Họ có Codex — thứ ai cũng mua được. Cái họ xây, và bạn chưa xây, là phần bọc quanh nó.

Câu hỏi đúng chưa bao giờ là "dùng model nào". Câu hỏi đúng là: khi agent của bạn làm sai, nó có cách nào tự phát hiện ra không?

Nếu câu trả lời là "không" — thì model mạnh hơn sẽ không cứu bạn. Nó chỉ giúp bạn sai nhanh hơn.

Nếu bạn đang cân nhắc đưa agent vào quy trình thật và muốn một góc nhìn thẳng về việc nên bắt đầu từ đâu — kể cả khi câu trả lời là "chưa cần" — tôi sẵn sàng trao đổi trực tiếp. Chi tiết về mảng tích hợp AI ở trang Tích hợp AI.

Nguồn tham khảo: