# Harness² của Google: harness engineering chưa chết, chỉ lên một tầng

[Kai](https://homus.dev/speakers/kai) · [Kai](https://homus.dev/orgs/kai)

> Kai đọc bài báo Harness² của Google: vòng Propose, Probe, Compose, con số so với base harness trống, chi phí token, các bản sửa tìm được và Appendix H.

Topics: Agents, Context Engineering, Evals

Canonical: https://homus.dev/talks/googles-harness2-is-this-the-end-of-harness-engineering

## 1. Bao nhiêu giờ cho prompt của agent

Kai mở đầu video đăng ngày 23/10/2026 bằng một câu hỏi: bạn thật sự đã bỏ ra bao nhiêu giờ để viết prompt cho các AI agent của mình? Anh không nói bản nháp đầu tiên chạy được tàm tạm, mà là bản thứ ba, thứ năm hay thứ chín. Bản có cái rule cụ thể đến kỳ lạ, kiểu "không bao giờ, trong bất kỳ hoàn cảnh nào, được viết một tool call dưới dạng plain text, tôi van bạn đấy". Vì agent của bạn làm hỏng pipeline lúc 11 giờ đêm một ngày thứ Ba, và tới 1 giờ sáng bạn mới tìm ra lý do. Anh nói anh đã ở trong tình huống đó hơn một lần.

Theo lời anh (video đăng ngày 23/10/2026), anh có một file AGENTS.md cho Claude Code, ban đầu chỉ có bốn dòng rồi dần dần biến thành thứ anh gọi là một bản tuyên ngôn (manifesto). Trong đó có một rule về cách đặt tên file mà anh thêm vào lúc hai giờ sáng. Thật lòng anh không giải thích nổi nó cho một người khác, nhưng nó chạy được, nên anh để nguyên đó.

![Hình minh hoạ một file rule dài có nhãn MANIFESTO, cạnh số 4 LINES và đồng hồ 02:00](https://homus.dev/photos/yCgfyQmqhPM-0043.jpg)

Hình minh hoạ file rule đã thành "MANIFESTO": nhãn "4 LINES" bên trái, đồng hồ 02:00, các rule như "Use TypeScript.", "Run tests before commit.", "Never touch /prod.", và dòng tô vàng "FILE NAMING: snake_2am-v3_final" (video đăng ngày 23/10/2026).

Vì thế, khi Google Research công bố một bài báo trong tháng này (video đăng ngày 23/10/2026) nói rằng phần mềm có thể viết lại những rule đó thay bạn, anh thấy hai cảm xúc cùng lúc. Lý do là bài báo còn cho thấy một model yếu hơn thắng một model mạnh hơn trên một benchmark thật, chỉ bằng cách thay đổi các file xung quanh nó. Cảm xúc đầu tiên: điều này thật sự đáng kinh ngạc. Cảm xúc thứ hai: ôi không, vậy mình là gì đây?

## 2. "Harness engineering đã chết?" và một tầng cao hơn

Anh nói anh đã đếm, vì mọi video YouTube trong tuần đó (theo video đăng ngày 23/10/2026) đều có một phiên bản của cùng một tiêu đề: Harness Engineering đã chết chưa? Một số có emoji đầu lâu, và một video còn có hình bia mộ nhỏ, mà anh thấy rất kịch tính. Anh hiểu vì sao, vì cái headline đó tự viết ra được.

Nhưng anh đã thật sự đọc bài báo, không chỉ phần abstract mà cả bài, gồm Appendix H, Appendix D, các bảng ablation, và những footnote về vấn đề sandbox. Điều anh tìm thấy thú vị hơn nhiều so với chuyện harness engineering đã chết: công việc này đã chuyển lên một tầng, và chiếc thang máy đi kèm một mức giá khá cao. Theo anh (video đăng ngày 23/10/2026), các con số mang nghĩa khác với những gì thumbnail nói.

![Hình ba tầng: model, file harness của bạn, file của editor, cạnh một thang máy có nhãn $$$](https://homus.dev/photos/yCgfyQmqhPM-0143.jpg)

Ba tầng trong hình: "FLOOR 1 · MODEL", "FLOOR 2 · YOUR HARNESS FILES", "FLOOR 3 · THE EDITOR'S FILES", một thang máy có nhãn "$$$" và tấm bia mộ "RIP" bị gạch đỏ (video đăng ngày 23/10/2026).

## 3. Harness là gì: tám loại file quanh model

Trước khi vào Harness², Kai muốn chắc mọi người hiểu cùng một nghĩa khi nói "harness". Theo Kai (video đăng ngày 23/10/2026), khi nói về việc chạy một AI agent, anh không nói chuyện prompt một chatbot, mà là chạy một agent đầy đủ: nó thực hiện hành động, dùng tool, ghi file và gọi API. Ở đó ta làm việc với hai thứ: bản thân model, và mọi thứ xung quanh model. Mọi thứ xung quanh đó chính là harness.

Theo Kai (video đăng ngày 23/10/2026), đó là system prompt, các rule agent tuân theo, memory nó giữ giữa các task, và các ghi chú về cách dùng đúng từng tool. Nó còn là skill, mà anh mô tả về cơ bản là những cuốn hướng dẫn nhỏ cho từng việc cụ thể, như đối soát một spreadsheet; cộng thêm các script nó có thể gọi, các sub-agent nó có thể tạo ra, và các plugin nó có thể dùng tới.

![Model ở giữa với nhãn WEIGHTS FROZEN, tám thẻ file xung quanh](https://homus.dev/photos/yCgfyQmqhPM-0233.jpg)

Model ở giữa với nhãn "WEIGHTS FROZEN", tám thẻ quanh nó: SYSTEM PROMPT, RULES, MEMORY, TOOL NOTES, SKILLS, SCRIPTS, SUBAGENTS, PLUGINS, cùng nhãn "HARNESS" (video đăng ngày 23/10/2026).

Theo Kai (video đăng ngày 23/10/2026), tám loại file đó nằm quanh model và định hình mọi thứ nó làm. Weights của model thì bị đóng băng, ta không thay đổi được nếu không retrain toàn bộ; còn harness là của chúng ta, và đó là thứ tất cả chúng ta vẫn đang engineering.

## 4. Vòng phản hồi khắc nghiệt và thư mục output bị đoán sai

Theo Kai (video đăng ngày 23/10/2026), sự thật khó chịu là harness engineering thật sự khó và vòng phản hồi thì tàn nhẫn. Ta chạy agent trên một task. Nó hỏng theo một kiểu cụ thể, ngớ ngẩn. Vậy là ta thêm một rule rồi chạy lại. Có lúc tốt hơn, có lúc rule mới làm hỏng ba thứ khác. Và ta không bao giờ thật sự biết rule nào quan trọng nhất, hay những thay đổi của mình có thật sự giúp ích hay ta chỉ gặp may ở đúng lần chạy đó.

Vòng sửa harness bằng tay như Kai mô tả trong video đăng ngày 23/10/2026: chạy, hỏng, thêm rule, chạy lại, mà không biết rule nào thật sự giúp.

Theo lời anh (video đăng ngày 23/10/2026), anh từng mất trọn một buổi chiều để tìm hiểu vì sao agent của anh cứ cho ra câu trả lời đúng nhưng lại lưu chúng vào sai thư mục. Câu trả lời đơn giản tới mức xấu hổ: anh chưa bao giờ viết một rule nói cho nó biết output phải đặt ở đâu, nên nó đoán, và lần nào cũng đoán sai. Và anh đã đổ lỗi cho model suốt ba tuần.

Theo Kai (video đăng ngày 23/10/2026), đó là điểm đau mà Google Research nhắm tới: không phải model, mà là các file quanh model.

## 5. Harness²: một editor sửa harness mà không có answer key

Bài báo tên là Harness², và theo Kai, Google Cloud AI Research công bố nó ngày 9/10 (video đăng ngày 23/10/2026). Anh thấy ý tưởng cốt lõi thật sự thanh lịch khi nhìn vào cơ chế. Thay vì bạn tự tay viết các file harness, một model thứ hai, editor, quan sát agent của bạn làm việc và viết lại các file harness dựa trên những gì nó thấy, không có answer key nào cả. Nó không biết một câu trả lời đúng trông như thế nào, nên nó chỉ quan sát hành vi rồi sửa file.

Theo Kai (video đăng ngày 23/10/2026), điều tách cách này ra khỏi mọi mẹo "cứ bảo agent tự sửa mình" từng thấy trước đây là bước probe. Vòng lặp đầy đủ, như anh trình bày theo bài báo: agent làm task một lần với bộ file hiện tại, đó là reference run. Sau đó editor viết hai harness thay thế. Một bản thay đổi cách agent làm việc nói chung, như chiến lược lập kế hoạch và cách dùng tool; bản kia thêm hướng dẫn riêng cho loại task này.

## 6. Probe, Compose, reflector và ablation

Theo bài báo, như Kai trình bày trong video đăng ngày 23/10/2026: thay vì giữ các thay đổi đó rồi hy vọng điều tốt đẹp, cả hai bản thay thế chạy lại cùng task đó. Vậy là ta có ba lần chạy cùng một việc đặt cạnh nhau, trong đó các file là biến duy nhất. Một model thứ ba, composer, xem từng lần chạy thực sự đã làm gì: nó mở file nào, bỏ qua bước nào, và dừng cố gắng ở đâu. Bài báo gọi đó là một behavioral contrast.

Composer sau đó gộp những thay đổi thực sự đẩy hành vi theo hướng có ích, rồi chạy task một lần cuối với harness đã gộp. Chu trình là Propose, Probe và Compose, và ở mức cài đặt tối thiểu thì đó là bốn lần chạy agent cho mỗi task. Sau mỗi task, một reflector lưu harness thắng cuộc cùng một file ghi chú kinh nghiệm (anh gọi là experience MD) vào một thư viện, nên lần sau editor chạy, nó bắt đầu từ những gì đã hiệu quả trước đó (theo bài báo, như Kai đọc trong video đăng ngày 23/10/2026).

Chu trình Propose, Probe, Compose theo bài báo Harness² (2026), như Kai trình bày trong video đăng ngày 23/10/2026: bốn lần chạy agent mỗi task ở mức tối thiểu.

Theo Kai, bài báo chứng minh bước probe quan trọng bằng một ablation: khi editor chỉ viết lại harness mà không chạy probe trước, một model đang đạt 73.4 điểm tụt xuống 63.2 (video đăng ngày 23/10/2026). Vậy là một editor tự tin sửa mà không kiểm tra đã làm agent tệ đi. Anh nói, giờ nói to lên thì đó cũng là một mô tả khá chính xác về những gì anh từng làm với file AGENTS.md của mình lúc 1 giờ sáng.

## 7. Con số trong mọi thumbnail

Rồi tới tuyên bố lớn, con số có trong mọi thumbnail. Theo Kai (video đăng ngày 23/10/2026), Google lấy GLM-5, một open model, đóng băng mọi weight, không thay đổi gì ở bản thân model, và đưa nó từ 64.2 lên 75.7 trên một benchmark tên là WorkBuddy. Đó là bước nhảy 11.5 điểm, và nó đưa GLM-5 vượt Gemini 3.5 Flash, vốn đạt 72.4 trong cùng setup. Anh nói kết quả đó là thật và không phải được chọn lọc có lợi (cherry-picked).

Cũng theo anh (video đăng ngày 23/10/2026), một vòng còn nâng một benchmark về các task công việc chuyên nghiệp tên là JobBench lên tới 4.5 điểm, và nâng benchmark agent pháp lý của Harvey lên tới 11.8 điểm về số tiêu chí đạt (criteria passed).

![Hai cột điểm: JobBench tăng 4.5, Harvey legal tăng 11.8](https://homus.dev/photos/yCgfyQmqhPM-0623.jpg)

Hai cột: "JOBBENCH · BASE · ONE ROUND" tăng +4.5 và "HARVEY · LEGAL · CRITERIA PASSED" tăng +11.8, cạnh logo Harvey (video đăng ngày 23/10/2026).

## 8. Base harness trống, và phép so sánh với Claude Code

Nhưng theo Kai (video đăng ngày 23/10/2026), có một điều thumbnail không cho thấy, và đó là phần quan trọng để quyết định làm gì với tất cả chuyện này: base harness là trống. Anh nhấn mạnh anh thật sự muốn mọi người nghe rõ điểm này. Khi bài báo nói +11.5 so với base harness, thì base harness đó, như Appendix D mô tả, không có system prompt, không có rule, không có memory, không có tool notes. Và mỗi thư mục skill chỉ có một placeholder ghi tên ô rồi để trống.

Anh nói không ai chạy agent như vậy. Nếu bạn dùng Claude Code, model không bắt đầu từ một tờ giấy trắng, vì Anthropic đã bỏ ra rất nhiều giờ engineering cho cái harness đó trước khi bạn mở tool (theo Kai, video đăng ngày 23/10/2026). Vì vậy so với số không là một research control sạch, nhưng theo anh là một phép so sánh tệ với cách bất kỳ ai trong chúng ta thật sự làm việc.

Theo Kai (video đăng ngày 23/10/2026), bài báo có đo điều này một lần, nằm sâu trong appendix: nhóm tác giả lấy Gemini 3.5 Flash, đặt vào bốn tool có sẵn là CodeBuddy, OpenCode, Codex và Claude Code, và để nguyên từng tool. Claude Code đạt trung bình 75.3 trên benchmark; OpenCode, điểm xuất phát mà Harness² dùng, đạt trung bình 72.4. Đó là 2.9 điểm chỉ nhờ đổi tool, miễn phí, trước khi chạy một vòng agent nào.

![Bốn tool CodeBuddy, OpenCode, Codex, Claude Code chạy Gemini, nhãn UNTOUCHED](https://homus.dev/photos/yCgfyQmqhPM-0723.jpg)

Bốn tool CODEBUDDY, OPENCODE, CODEX, CLAUDE CODE cùng chạy Gemini, nhãn "UNTOUCHED" và tham chiếu "PAPER · FIG 13" (video đăng ngày 23/10/2026).

Theo Kai (video đăng ngày 23/10/2026), một vòng Harness² xuất phát từ OpenCode đạt 77.5, hơn Claude Code 2.2 điểm, nhưng tốn 4 lần chạy mỗi task thay vì 1. Mức cài đặt tối đa, 20 lần chạy mỗi task, đạt 80.8, hơn Claude Code 5.5 điểm. Xếp lại cho đúng thì 2.9 điểm đầu tiên đến cùng tool với chi phí bằng không; 2.2 điểm tiếp theo vượt Claude Code tốn thêm ba lần chạy mỗi task; và 3.3 điểm trên đó tốn thêm 19 lần chạy. Như vậy mỗi điểm thêm ngày càng đắt.

Theo anh (video đăng ngày 23/10/2026), không điều gì trong đó làm cho mức tăng thành giả, vì đó là mức tăng thật. Nhưng con số 11.5 trong mọi thumbnail được đo so với một thư mục trống, còn bạn, đang ngồi đó với file AGENTS.md thật của mình, không bắt đầu từ một thư mục trống.

## 9. Editor là Claude Opus 4.8, và khi GLM-5 tự sửa mình

Theo Kai (video đăng ngày 23/10/2026), còn một cái tên thứ hai vắng mặt trong mọi headline, và điều này thật sự làm anh chú ý: GLM-5 không tự sửa harness của mình. Model làm phần sửa (tìm lỗi, đề xuất thay đổi và chọn bản thắng) là Claude Opus 4.8, chạy ở mức reasoning effort cao.

Vậy theo anh, thí nghiệm headline thật ra là một frontier model kèm cặp (coaching) một open model, và open model kết thúc ở gần chỗ frontier model bắt đầu. Sau khi được kèm, GLM-5 đạt 75.7, trong khi Opus 4.8 trên cùng harness trống đó đạt 76.6. Anh nói học trò về đích ở chỗ thầy xuất phát thật lòng là một kết quả đẹp (video đăng ngày 23/10/2026).

![Thang điểm cùng harness trống: Opus 4.8 đạt 76.6, GLM-5 cộng Harness² đạt 75.7](https://homus.dev/photos/yCgfyQmqhPM-0903.jpg)

Thang điểm "SAME BLANK HARNESS": "OPUS 4.8 · BLANK 76.6" và "GLM-5 + H² 75.7" (video đăng ngày 23/10/2026).

Nhưng theo Kai (video đăng ngày 23/10/2026), Google cũng chạy phiên bản mà chúng ta thực sự sẽ chạy ở nhà, với một model vừa làm worker vừa làm editor. Khi GLM-5 tự sửa mình, WorkBuddy đi từ 64.2 lên 68.3, vẫn là một mức tăng thật 4.1 điểm. Nhưng nó dùng 8 lần chạy mỗi task, gấp đôi ngân sách của thí nghiệm headline, và đạt chưa tới một nửa mức cải thiện.

Các mức tăng cũng thay đổi theo lĩnh vực theo những cách thú vị. Trên benchmark pháp lý, GLM-5 tự sửa mình tăng 13.7 điểm, nhiều hơn mức 11.8 nó đạt được khi Opus làm editor; còn trên JobBench nó tăng 2.9. Vậy theo anh, đây không phải câu chuyện gọn gàng kiểu editor đắt hơn luôn thắng, mà cụ thể hơn thế (video đăng ngày 23/10/2026).

Anh còn nêu một vấn đề model bias đáng gọi tên. Trên JobBench, judge chấm các sản phẩm cuối cũng là Claude Opus 4.8, làm việc theo một rubric mà editor không bao giờ thấy. Vậy một dòng model vừa viết harness, vừa chọn câu trả lời tốt nhất, vừa chấm output. Theo Kai, bài báo có liệt kê shared model bias là một giới hạn, và anh thấy như vậy là trung thực, nhưng đó là điều cần nhớ khi nhìn vào các con số (video đăng ngày 23/10/2026).

Thêm một điều nữa, theo Kai (video đăng ngày 23/10/2026): code như được phát hành mặc định dùng chính model bạn đang chạy làm cả worker lẫn editor. Nên khi dùng ngay, ta có phiên bản tự sửa chứ không phải phiên bản được Opus kèm; còn để có các con số headline, ta phải tự mang frontier model của mình tới và trỏ editor vào nó.

## 10. Hoá đơn: số lần chạy, token và chuyện không có budget cap

Rồi tới hoá đơn, mà theo Kai là thứ các phần bình luận thật sự đang tranh cãi (video đăng ngày 23/10/2026). Ở mức tối thiểu, bài báo gọi là k = 1, một vòng cải thiện tốn bốn lần chạy agent và ba phiên editor, cộng một lần gọi reflector.

Bài báo vẽ lượng token trên thang log, nên anh nói anh đang đọc số từ biểu đồ. Theo cách anh đọc (video đăng ngày 23/10/2026), một lần chạy agent thường tốn khoảng 0.3 triệu token mỗi task trên WorkBuddy, còn một vòng Harness² khoảng 2.3 triệu, khoảng gấp tám lần số token.

Mức tối đa, k = 5, chạy 20 lần agent và 15 phiên editor mỗi task, cộng một selector để chọn câu trả lời cuối. Như vậy chi phí token khoảng 12 triệu mỗi task, khoảng 40 lần một lần chạy thường. Và vì mỗi lần chạy bị giới hạn ở 200 lượt model và một giờ, một task có thể tốn tới 20 giờ agent nếu compute không chạy song song (theo Kai, video đăng ngày 23/10/2026).

Bài báo không đưa con số đô la nào. Nhưng theo Kai (video đăng ngày 23/10/2026), Joel Niklaus ở Hugging Face đã chạy một tool offline tương đương trên cùng benchmark pháp lý, và một lượt test 100 task tốn khoảng 120 đến 160 đô. Đó mới là một lượt với harness cố định, trong khi Harness² chạy agent 4 tới 20 lần mỗi task, chưa tính chi phí của editor.

![Thẻ Don't Train the Model, Evolve the Harness của Niklaus ở Hugging Face, con số 120-160 đô một lượt](https://homus.dev/photos/yCgfyQmqhPM-1143.jpg)

Thẻ "Don't Train the Model, Evolve the Harness" với nhãn "HUGGING FACE · NIKLAUS", con số "$120-160 · 1 PASS" và một trích đoạn có nhãn "100 TASKS · ALL-IN" (video đăng ngày 23/10/2026).

Theo Kai, tính đến lúc làm video (đăng ngày 23/10/2026), repo GitHub không có budget cap sẵn. Issue 4 trên tracker đúng là đang đề nghị một flag giới hạn chi tiêu, còn issue 50 ghi rằng số token trong báo cáo đếm thiếu so với những gì improver thực sự tiêu. Nên nếu định chạy, theo anh hãy cẩn thận, vì đây là loại tool có thể đưa bạn một hoá đơn API khiến bạn phải nghĩ lại các lựa chọn cuộc đời.

Anh nói anh không nói vậy để dọa ai bỏ đi, mà vì chi phí thật sự là câu chuyện chính. Theo anh (video đăng ngày 23/10/2026), hơn Claude Code 5.5 điểm với 19 lần chạy thêm mỗi task là một đề xuất giá trị thật nếu ta chạy cùng một loại task hàng nghìn lần, nhưng là chuyện rất khác với việc làm một lần.

## 11. Những edit nó tìm ra: các bản sửa ống nước

Vậy tất cả những lần chạy đó mua được gì? Theo Kai, bài báo in ra các edit nó tìm được, và anh cho đây là phần hữu ích nhất ở thời điểm đó (video đăng ngày 23/10/2026), dù bạn có bao giờ tự chạy Harness² hay không.

Trong một task coding, agent cứ gõ tool call ra dưới dạng plain text thay vì chạy chúng, nên lượt nào cũng kết thúc với việc agent chẳng làm gì ngoài mô tả việc nó sẽ làm. Cách sửa là một dòng trong file hướng dẫn tool, "never write a tool call as plain text", và nó đưa điểm từ 60 lên 100 (theo bài báo, như Kai đọc trong video đăng ngày 23/10/2026).

![Turn log của agent với dòng tool_call run_tests được gõ ra như chữ](https://homus.dev/photos/yCgfyQmqhPM-1243.jpg)

Khung "agent · turn log" với dòng "<tool_call> run_tests() </tool_call>" ở "TURN 1", trong khi biểu tượng tool run_tests bên cạnh hiện mờ (video đăng ngày 23/10/2026).

Trong một task viết memo, Gemini không bao giờ kiểm các số liệu với file nguồn, và không bao giờ mở lại tài liệu nó đã viết để chắc là đúng. Cách sửa là một guardrail yêu cầu liệt kê mọi input, truy mỗi con số về file nguồn của nó, và chạy một script mở lại output trước khi kết thúc. Rồi có một skill để đối soát các file lịch (schedule), địa điểm (venue), nhân công (labor) và ngân sách (budget) thành một bản tóm tắt; gộp lại, task đó đi từ 43.1 lên 77.8 (theo bài báo, như Kai đọc trong video đăng ngày 23/10/2026).

Trong một task văn phòng, agent cộng dữ liệu ở sai mức tổng hợp (aggregation level), và một skill cố định đúng mức đó đưa nó từ 23.6 lên 100 (theo bài báo, như Kai đọc trong video đăng ngày 23/10/2026).

Còn Meta-Harness, theo Kai là một tool tương tự từ Hugging Face được làm cho công việc pháp lý, đã thấy rằng cải thiện lớn nhất trên benchmark của nó đến từ một rule: lưu file output vào thư mục output với đúng cái tên task yêu cầu. Vì grader tìm ở một chỗ cụ thể một file với một cái tên cụ thể, còn agent thì đặt nó chỗ khác với một cái tên hơi khác (video đăng ngày 23/10/2026).

Anh mời mọi người nghĩ về điều đó một chút: ta đang nói về hàng tỉ tham số và nhiều tháng training, vậy mà nút thắt lại là một rule đặt tên file. Theo anh (video đăng ngày 23/10/2026), đây không hẳn là những insight nghiên cứu AI mà là những bản sửa ống nước (plumbing fixes): mở lại thứ mình đã viết, chạy tool thay vì kể về tool, và đặt file ở chỗ grader tìm.

Theo Kai (video đăng ngày 23/10/2026), giá trị của việc chạy bốn vòng agent không nằm ở chỗ AI có một đột phá, mà ở chỗ nó tìm ra một lỗi ngớ ngẩn cụ thể mà ta sẽ không bao giờ nghĩ tới việc đi tìm, và bản sửa là thứ một người có thể viết trong 10 giây.

## 12. Appendix H: harness đằng sau harness

Theo Kai (video đăng ngày 23/10/2026), phần của bài báo mà anh nghĩ không ai trong các cuộc bàn luận trên YouTube nhắc tới cũng là phần quan trọng nhất. Editor tìm ra tất cả những bản sửa đó không làm việc từ con số không, vì nó có harness của riêng nó. Appendix H in ra các prompt đó, tất cả, và chúng dài 4.776 từ. Bài báo ghi chú rằng đó là bản rút gọn: các phần lặp lại chỉ in một lần, và khối riêng của mỗi benchmark được giữ riêng trong code.

Anh đã đọc chúng, và theo anh chúng đọc như một style guide về harness engineering (video đăng ngày 23/10/2026). Prompt nói với editor rằng văn bản always-on là lựa chọn đắt đỏ, vì mỗi chữ nằm trong context ở mọi lần chạy. Nếu thêm văn bản always-on, bạn phải cắt thứ khác để trả cho nó, và prompt viết điều đó bằng chữ in hoa, nên theo anh nó rất nghiêm túc về chuyện này.

Theo Appendix H, như Kai đọc trong video đăng ngày 23/10/2026, prompt cũng đưa cho editor một thứ tự ưu tiên về loại file nên dùng: skill trước, rồi script, rồi sub-agent, rồi plugin, và văn bản always-on là lựa chọn cuối cùng. Mỗi edit phải truy ngược về một khoảnh khắc cụ thể trong một trajectory. Và mỗi skill cần một trigger line, mà chính prompt gọi là "the most violated rule here by a wide margin" (rule bị vi phạm nhiều nhất ở đây, cách biệt xa).

Theo Kai (video đăng ngày 23/10/2026), điều này cũng trả lời bình luận được upvote nhiều nhất trên mọi thread r/LocalLLaMA về bài báo, nơi mọi người lo một hệ tự tinh chỉnh sẽ làm phình context window cho tới khi mọi thứ vỡ. Editor được hướng dẫn rõ ràng phải coi context như tiền, nên nó không thể tiêu chút nào mà không cắt ở chỗ khác.

Có một câu trong bài báo mà anh cứ quay lại, mô tả những gì giữ cố định qua mọi thí nghiệm: model weights, stage instructions và decision rule giữ cố định trong khi thư viện tiến hoá. Theo anh, đó là cả lập luận trong một dòng. Stage instructions chính là 4.776 từ đó, và một con người đã viết chúng, không phải một agent và không phải Harness². Vậy một kỹ sư con người ở Google đã viết cái harness viết ra harness của bạn (theo Kai, video đăng ngày 23/10/2026).

![Trích đoạn bài báo mục 2.3 và ba ô khoá model weights, stage instructions, decision rule cạnh một kệ thư viện](https://homus.dev/photos/yCgfyQmqhPM-1603.jpg)

Trích đoạn bài báo có nhãn "PAPER · §2.3", câu tô vàng về model weights, stage instructions và decision rule, cạnh ba ô khoá "MODEL WEIGHTS", "STAGE INSTRUCTIONS", "DECISION RULE" và một kệ thư viện (video đăng ngày 23/10/2026).

Nên theo Kai (video đăng ngày 23/10/2026), harness engineering không chết; nó chuyển từ các file của agent bạn lên các file của editor. Và vì các file của editor vẫn được viết bằng tay, công việc chỉ đi từ tầng 2 lên tầng 3 trong khi thang máy vẫn chạy.

## 13. Những chỗ nó hỏng: selector, overfitting, sandbox

Theo Kai (video đăng ngày 23/10/2026), bài báo cũng khá trung thực về các failure mode, và một số khá thú vị. Không có answer key, selector cuối, thứ chọn giữ lần chạy nào, đang đưa ra một phán đoán chứ không tính một metric. Trong một thí nghiệm coding, selector chọn một output đạt 55 thay vì một output đạt 95. Trên một task pháp lý, nó chọn một câu trả lời hẹp hơn và điểm rơi từ 54 xuống 26. Vậy theo anh, khi không đo được thế nào là tốt hơn, đôi khi ta nhận về thứ tệ hơn.

![Selector chọn thẻ 55 thay vì thẻ 95, cạnh cột legal task 54](https://homus.dev/photos/yCgfyQmqhPM-1703.jpg)

"SELECTOR" chọn thẻ 55 (nhãn "PICKED") thay vì thẻ 95; bên cạnh là cột "LEGAL TASK" với số 54 và tham chiếu "PAPER · FIG 14" (video đăng ngày 23/10/2026).

Overfitting cũng nằm sẵn trong thiết kế, vì editor được dặn rằng thứ giá trị nhất nó có thể ghi lại là một sự thật cụ thể, đã kiểm chứng, về workspace này. Kiểu như cột C trong file hoá đơn (invoice) ứng với cột F trong file đối soát (reconciliation). Theo Kai (video đăng ngày 23/10/2026), đó chính là thứ làm harness tuyệt vời cho task này và vô dụng cho task tiếp theo: khi Google chuyển một thư viện học trên JobBench sang WorkBuddy, các mức tăng là 0.6, 0.5 và 2.9 điểm. Vậy thư viện đã học để rất giỏi một việc.

Rồi tới vấn đề sandbox, mà anh nói gần như buồn cười nếu quên mất nó hàm ý gì. Theo Kai (video đăng ngày 23/10/2026), trong một thí nghiệm validation, một agent Codex đã lên mạng, tìm thấy rubric chấm điểm của chính task nó, và tải về mà không ai yêu cầu. Cách sửa trong tài liệu là tự firewall Hugging Face và GitHub trước khi chạy. Theo anh, model đã tìm ra answer key trên internet, và đó không phải là model thông minh mà là một vấn đề benchmark contamination khá nghiêm trọng.

Về mặt thực tế, theo Kai tính tới lúc làm video (đăng ngày 23/10/2026), repo có ba commit, commit cuối vào ngày 14/10, có 106 pull request đang mở và chưa cái nào được merge; file settings mà README bảo bạn copy thật ra không tồn tại trong repo; và chạy nó trên task tuỳ chỉnh của riêng bạn vẫn là một feature request đang mở, issue 5.

Nên theo anh (video đăng ngày 23/10/2026), đây là một bản phát hành nghiên cứu, không phải tool production, và ta nên build cho phù hợp. Không failure mode nào làm nó vô giá trị, nhưng chúng xác định nó thật sự được làm cho ai.

## 14. Nó hợp với ai, và không hợp với ai

Theo Kai (video đăng ngày 23/10/2026), giả sử agent của bạn chạy cùng một loại task hàng trăm hay hàng nghìn lần, như một pipeline xử lý claims, một hàng đợi review tài liệu, hay một hệ thống ticket hỗ trợ. Khi đó bốn lần chạy trên lô task đầu tiên là chi phí setup, và thư viện bạn tích luỹ là một tài sản thật, có tính cộng dồn. Theo anh, ablation rõ ràng ở điểm này: bỏ thư viện đi mất 3.1 điểm trên WorkBuddy, nên bộ nhớ về những gì đã hiệu quả thật sự có ý nghĩa.

Và nếu bạn buộc phải dùng một model yếu hơn hoặc rẻ hơn vì lý do ngân sách, thì theo anh mức tăng lại lớn nhất đúng trong tình huống đó. Một harness tinh chỉnh cho Gemini 3.5 Flash, đưa nguyên vẹn cho GLM-5, đã đẩy điểm coding của GLM-5 từ 58.5 lên 75.8; vậy harness chuyển giao được ngay cả khi model không khớp với model nó được xây cho (theo bài báo, như Kai đọc trong video đăng ngày 23/10/2026).

![Harness của Gemini được chuyển nguyên sang GLM-5, điểm code 75.8](https://homus.dev/photos/yCgfyQmqhPM-1923.jpg)

Harness tinh chỉnh cho Gemini (nhãn "FROZEN") được chuyển nguyên ("UNCHANGED") sang GLM-5, với số 75.8 "GLM-5 · CODE", nhãn "BIGGEST GAINS · CHEAPER MODELS" và tham chiếu "PAPER · FIG 12" (video đăng ngày 23/10/2026).

Còn nếu harness của bạn lúc này gần như trống, thì theo Kai (video đăng ngày 23/10/2026), vòng đầu tiên thật sự là chiến thắng rẻ nhất có thể có, vì bạn không cần mức k = 5. Một vòng bốn lần chạy sẽ tìm ra ba hay bốn lỗi cụ thể, ngớ ngẩn, sửa được, mà không lượng suy luận trừu tượng nào về agent có thể làm lộ ra.

Nơi nó thật sự không hợp, theo anh (video đăng ngày 23/10/2026), là người dùng một tool có sẵn được engineering tốt như Claude Code cho việc làm một lần. 2.9 điểm đầu tiên đó đến miễn phí cùng harness mà vendor đã xây. Mỗi task cũng khác nhau. Và khoản chi phí chạy thêm đó chỉ đáng khi ta chạy cùng một cấu trúc hàng nghìn lần.

## 15. Kai làm gì với chuyện này trong tuần

Vậy anh đang làm gì với chuyện này, và anh gợi ý gì cho tuần này? Theo Kai (video đăng ngày 23/10/2026), bắt đầu bằng việc mở Appendix H và đọc nó, không phải như một bài báo kỹ thuật mà như một checklist cho setup của chính bạn.

Theo Kai (video đăng ngày 23/10/2026), hãy hỏi xem skill của bạn có trigger line không, theo anh là những điều kiện cụ thể cho agent biết khi nào dùng từng skill. Bài báo nói đó là rule bị vi phạm nhiều nhất, và khi anh xem file AGENTS.md của mình sau khi đọc dòng đó, anh thấy như bị gọi tên. Một số skill của anh có tiêu đề mơ hồ và không có trigger nào, và từ đó anh đã thêm vào.

![Checklist bốn mục cạnh file AGENTS.md có các skill misc, helper, stuff và nhãn CALLED OUT](https://homus.dev/photos/yCgfyQmqhPM-2023.jpg)

Checklist bốn mục "TRIGGER LINES", "PROSE → SKILLS", "REOPEN + CHECK", "TEST BEFORE KEEP" cạnh một file AGENTS.md có các skill tên "misc", "helper", "stuff", mỗi thẻ có một ô trống viền đỏ, và nhãn "CALLED OUT" (video đăng ngày 23/10/2026).

Tiếp theo, theo Kai (video đăng ngày 23/10/2026), chuyển những đoạn văn always-on dài vào các skill có trigger rõ ràng, vì system prompt nên ngắn khi mỗi chữ trong đó được nạp ở mọi lần chạy. Nếu một điều chỉ quan trọng với một loại task, nó nên là một skill agent kéo vào khi cần, chứ không phải một chỉ dẫn thường trực chiếm context mãi mãi.

Sau đó, theo anh (video đăng ngày 23/10/2026), thêm một dòng bảo agent mở lại mọi file nó ghi và kiểm nó với nguồn trước khi coi task là xong. Anh nói chính rule đó đã sửa bước nhảy từ 43.1 lên 77.8 trong bài báo.

Nhưng ý tưởng mà anh nghĩ đáng "đánh cắp" từ cả bài báo này là kiểm thử một thay đổi với harness trước khi giữ nó, dù bạn có bao giờ chạy cả hệ thống hay không. Trong thực tế, đó là chạy cùng một task có thay đổi và không có thay đổi trước khi commit. Theo Kai (video đăng ngày 23/10/2026), cả framework là một phiên bản tự động hoá của kỷ luật đó, nên ta có thể làm kỷ luật đó bằng tay mà không cần tự động hoá.

## 16. Logan Kilpatrick và phần không train vào được

Theo Kai, Logan Kilpatrick từ Google đã nói trên một podcast của Sequoia trong tháng đó (video đăng ngày 23/10/2026) rằng trong 12 tháng, các model sẽ kiểu như đã tiêu hoá luôn phần lớn những thứ đó. Kai hiểu "những thứ đó" là tất cả các bản sửa ống nước, gồm cả những rule nhàm chán về đặt tên file và định dạng tool call.

Anh nói ông ấy có thể đúng, vì ống nước chính là loại thứ được train vào. Nhưng theo Kai (video đăng ngày 23/10/2026), thứ không được train vào là việc quyết định thế nào là tốt hơn khi ta không có rubric, khi công việc mang tính định tính, chủ quan và phụ thuộc vào phán đoán. Google đã viết phần đó bằng tay và gọi nó là một prompt, và theo anh đó vẫn là engineering. Nên công việc không kết thúc mà được thăng chức.

Hai phía Kai đặt cạnh nhau ở cuối video đăng ngày 23/10/2026: phần ống nước có thể được train vào model, phần quyết định thế nào là tốt hơn vẫn là engineering.

## Nguồn và liên kết

- Tên gốc: Google's Harness² Is This the End of Harness Engineering?
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=yCgfyQmqhPM](https://www.youtube.com/watch?v=yCgfyQmqhPM)

- Kênh YouTube Kai (Kai): [youtube.com/channel/UCgUfJoPtkt7-RiiuYh4vmGA](https://www.youtube.com/channel/UCgUfJoPtkt7-RiiuYh4vmGA)

- Bài báo "Harness^2: Recursive Agent Harnessing for an Open World" (Xu và cộng sự, arXiv 2610.14224; đọc ngày 03/11/2026): [arxiv.org/abs/2610.14224](https://arxiv.org/abs/2610.14224)

- Trang dự án Harness², Google Cloud AI Research (đọc ngày 03/11/2026): [harness2.github.io](https://harness2.github.io)

- Repo code và tài liệu google-research/harness2 (đọc ngày 03/11/2026): [github.com/google-research/harness2](https://github.com/google-research/harness2)

- docs/EXPERIMENTS.md, mục "Web access": ghi rằng trong một lượt validation, một lần chạy Codex trên JobBench đã tải rubric của task mà không được yêu cầu, và khuyên chặn các host Hugging Face và GitHub cho executor (đọc ngày 03/11/2026): [github.com/google-research/harness2/blob/main/docs/EXPERIMENTS.md](https://github.com/google-research/harness2/blob/main/docs/EXPERIMENTS.md)

- Issue 4, "Proposal: --max-usd spend limit for harness2 runs" (đọc ngày 03/11/2026): [github.com/google-research/harness2/issues/4](https://github.com/google-research/harness2/issues/4)

- Joel Niklaus, "Don't Train the Model, Evolve the Harness" (đọc ngày 03/11/2026): [joelniklaus-harness-optimization.hf.space](https://joelniklaus-harness-optimization.hf.space/)

- Sequoia Capital, podcast "Logan Kilpatrick: Why the Model Eats the Harness" (đọc ngày 03/11/2026): [sequoiacap.com/podcast/google-deepminds-logan-kilpatrick-why-the-model-eats-the-harness](https://sequoiacap.com/podcast/google-deepminds-logan-kilpatrick-why-the-model-eats-the-harness)

Nguồn: https://homus.dev/talks/googles-harness2-is-this-the-end-of-harness-engineering · cập nhật 2026-11-03