Google Harness² Là Gì: Tối Ưu Hóa Agent Đệ Quy Không Đổi Trọng Số

Mỗi khi AI agent chạy lạc đề hoặc rơi vào vòng lặp vô tận, phản xạ phổ biến của kỹ sư là mong chờ một checkpoint (file lưu toàn bộ trọng số não bộ AI / model weights file) lớn hơn. Chúng ta chờ đợi Gemini 3.5, Claude 4 hay GPT-5 với niềm tin sức mạnh suy luận thuần túy sẽ tự động dọn dẹp các góc khuất thực chiến.

Thực tế production chứng minh điều ngược lại: agent không hỏng vì model thiếu thông minh, mà vì bộ khung điều phối bọc quanh nó quá cứng nhắc và mù tịt trước các lỗi thời gian chạy.

Đầu tháng 10/2026, nhóm nghiên cứu Google Cloud AI Research phối hợp cùng Đại học Northwestern công bố dự án mã nguồn mở google-research/harness2 (arXiv:2610.14224: Harness²: Recursive Agent Harnessing for an Open World). Framework này tối ưu hóa harness (bộ khung điều phối bọc quanh model / model execution framework) bằng cơ chế đệ quy hai tầng với trọng số model đóng băng hoàn toàn.

Tóm tắt (TL;DR)

Đúc kết nhanh:

• Google Harness² là gì? Framework mã nguồn mở do Google Cloud AI Research phát triển, tự động tối ưu hóa đệ quy bộ khung điều phối (harness) ở cấp độ tác vụ và hệ thống với trọng số model đóng băng (frozen weights), vận hành bền bỉ trong môi trường mở mà không cần đáp án mẫu (ground-truth labels).
• Cơ chế đệ quy 2 tầng: Tầng tác vụ áp dụng chu trình Đề xuất - Thăm dò - Tổng hợp (Propose - Probe - Compose) để tạo biến thể harness, chạy thử song song và chắt lọc điểm cải tiến từ sự đối lập hành vi; Tầng hệ thống đúc kết bài học vào ledger lâu dài để dẫn đường cho tác vụ sau.
• Cây thành tố 8 phần: Phân chia harness thành 8 khối rõ ràng (System Prompt, Guardrails, Memory, Tool Guidance, Skills, Subagents, Scripts, Plugins), thiết lập thứ bậc chi phí nghiêm ngặt: văn bản luôn bật (always-on prose) đắt nhất, ưu tiên chuyển logic sang kỹ năng theo yêu cầu (skills on-demand), script xác định và plugin chặn vòng lặp công cụ.
• Hiệu năng thực tế: Tăng tới 11.5 điểm trên WorkBuddy-Bench, 4.5 điểm trên JobBench và 11,8 điểm phần trăm trên tỷ lệ hoàn thành từng phần (partial pass rate) của benchmark pháp lý LAB trên các model cố định như Gemini 3.5 Flash và GLM-5.
• Kho mã nguồn: google-research/harness2 trên GitHub.

---

Bản đồ tư duy (Mô hình trực quan)

Một cỗ xe F1 sở hữu khối động cơ V8 cực mạnh nhưng nếu góc cánh gió sai và lốp xe trượt nước, xe sẽ văng khỏi khúc cua đầu tiên. Khối động cơ nguyên bản là model nền tảng; khung gầm, cánh gió khí động học, cảm biến bám đường và chiến thuật vào pit chính là harness.

Harness² biến agent thành một trạm kỹ thuật tự thích ứng: tự động chạy thử các góc cánh gió khác nhau trong buồng lái mô phỏng, chọn cấu hình tối ưu nhất cho đường đua hiện tại rồi lưu dữ liệu vào sổ tay kỹ sư cho toàn mùa giải.

---

Phần 1: Bối cảnh & Điểm mù của hệ thống Agent tĩnh

Trong kiến trúc phần mềm AI, harness là toàn bộ hệ thống bao bọc xung quanh model để biến một bộ dự đoán token đơn thuần thành thực thể giải quyết công việc. Harness kiểm soát 8 thành tố: System Prompt, Guardrails, Memory, Tool Guidance, Skills, Subagents, Scripts và Plugins.

Nghịch lý của các framework agent hiện nay nằm ở tính tĩnh tại: lập trình viên viết prompt dài hàng chục trang, khai báo 20 công cụ và kỳ vọng agent tự xoay xở. Khi bước vào thế giới mở, agent sụp đổ vì tài liệu lạ, output công cụ làm tràn context, tự ý đổi format kết quả và hoàn toàn thiếu đáp án chuẩn (ground-truth) để tự sửa sai.

Đó chính là bài toán thực chiến mà Google Research giải quyết triệt để.

---

Phần 2: Kiến trúc đệ quy hai tầng (Mổ xẻ Propose - Probe - Compose)

Sức mạnh cốt lõi của Harness² nằm ở khả năng tự học mà không cần đáp án mẫu qua hai chu kỳ lồng ghép:

1. Tầng tác vụ: Quy trình Propose - Probe - Compose

Khi nhận một tác vụ mới, Harness² triển khai ba bước:

• Bước 1 - Propose (Đề xuất): Module Proposer phân tích nhiệm vụ và các thất bại tiềm tàng để sinh ra k biến thể harness ứng viên, gồm biến thể bất biến (cải thiện định dạng, bẫy lỗi chung) và biến thể nghiệp vụ (nạp quy trình chuyên sâu).
• Bước 2 - Probe (Thăm dò): Chạy song song các cấu hình harness trên sandbox cách ly. Mỗi lần chạy sinh ra một trajectory ghi nhận: lệnh đã gọi, lỗi cú pháp, thời gian chờ và chi phí token.
• Bước 3 - Compose (Tổng hợp đối lập): Module Composer đặt các trajectory cạnh nhau để so sánh hành vi tương phản. Nếu một biến thể dùng plugin lọc bớt log rác giúp hoàn thành tác vụ trong 3 bước thay vì 15 bước, thành tố đó được giữ lại dựa trên sự đối chiếu hành vi thực nghiệm (behavioral contrast).

# Cài đặt môi trường Harness² cục bộ bằng uv
uv venv --python 3.12 .venv
source .venv/bin/activate
uv pip install -e '.[render]'

# Chạy bản thử nghiệm cục bộ với 2 bước đệ quy
harness2-demo --output runs/demo --k 2

Hệ thống hỗ trợ hai chế độ mở rộng ngân sách thăm dò:

• Chế độ song song (--mode parallel): Thăm dò k ứng viên chung và k ứng viên chuyên sâu cùng lúc, khám phá nhanh bề rộng không gian giải pháp.
• Chế độ tuần tự (--mode sequential): Mang kết quả tinh chỉnh qua k bước liên tiếp, đào sâu và khắc phục các lỗi logic phức tạp.

# Chạy đánh giá trên JobBench với chế độ song song
harness2-setup jb && harness2-check --bench jb
harness2 --bench jb --k 1 --mode parallel --only-domains legal --max-tasks 3
harness2-judge --bench jb --k 1 --mode parallel
harness2-report --bench jb --k 1 --mode parallel

2. Tầng hệ thống: Bộ phản tư kinh nghiệm (Experience Reflector & Ledger)

Sau khi tác vụ hoàn tất, bộ phản tư Experience Reflector phân tích diff giữa harness ban đầu và harness chiến thắng. Những bài học quy luật (ví dụ: với bảng biểu phức tạp, dùng plugin chia nhỏ trang thay vì đổ cả tài liệu vào context) được ghi nhận vào Ledger trung tâm để dẫn đường cho các tác vụ tiếp theo.

---

Phần 3: Cạm bẫy thực chiến & Thứ bậc chi phí thành tố (The Rough Edges)

Trong file harness2/core/prompts.py, Google Research đúc kết nguyên lý then chốt:

Always-on prose is the expensive option! (Văn bản luôn bật là sự lựa chọn đắt đỏ nhất).

Mỗi từ viết vào phần văn bản luôn bật (trong OpenCode là systemprompt.md, guardrails.md, LongTermMEMORY.md, tool_guidance.md; trong Codex là AGENTS.md) đều bị tính phí trên từng lượt gọi model, chiếm dụng cửa sổ chú ý và cạnh tranh trực tiếp với ngân sách token suy luận. Thất bại thảm khốc nhất là khi model suy nghĩ miên man cho đến khi cạn sạch token budget và không tạo ra bất kỳ sản phẩm nào.

Thứ bậc ưu tiên khi chỉnh sửa harness:

1. Ưu tiên 1 - Kỹ năng theo yêu cầu (Skills on-demand): Nạp vào context khi có tín hiệu kích hoạt. Chi phí bằng 0 cho đến thời điểm được gọi.
2. Ưu tiên 2 - Script tất định (Deterministic scripts): Gọi script chạy qua bash thay vì để model tự viết code tính toán bằng suy luận xác suất.
3. Ưu tiên 3 - Subagent cách ly (Isolated subagents): Phù hợp khi dữ liệu đầu vào cực lớn nhưng kết quả rút ra cực nhỏ.
4. Ưu tiên 4 - Plugin chặn trong vòng lặp (In-loop plugins): Can thiệp trực tiếp vào tool loop (cắt tỉa log terminal quá dài, chặn lệnh nguy hiểm). Hook runtime không thể bị model bỏ qua như câu chữ trong prompt.
5. Ưu tiên cuối cùng - Văn bản luôn bật (Always-on text): Chỉ thêm khi áp dụng cho 100% tình huống. Khi thêm một câu mới, phải cắt bỏ một câu cũ để cân bằng ngân sách.

Ba quy tắc sống còn loại bỏ ngay lập tức biến thể lỗi

Google Research thiết lập ba điều kiện kiểm tra nghiêm ngặt trước khi chạy:

1. Mọi Skill bắt buộc có dòng kích hoạt (Trigger line): Nếu tạo file skills/data_cleaner/SKILL.md nhưng trong prompt chính thiếu câu When handling dirty tabular datasets, load the data_cleaner skill, kỹ năng đó bị bỏ xó.
2. Nghiêm cấm dấu ngoặc nhọn template {{ trong văn bản luôn bật: File prompt render qua Jinja với StrictUndefined. Một dấu ngoặc nhọn vô tình {{ sẽ làm sập tiến trình ngay khi khởi động.
3. Hình hài sản phẩm thuộc về người dùng, không thuộc về agent: Nếu yêu cầu xuất file CSV 3 cột id, name, score, agent không được tự ý chèn thêm cột giải thích hay bước tính toán vào file kết quả.

---

Phần 4: Ma trận ứng dụng & Chiến lược triển khai (Decision Matrix)

Bảng so sánh hỗ trợ ra quyết định triển khai:

Góc nhìn thực chiến: Có nên cài đặt repo này lên máy làm việc không?

Câu trả lời dứt khoát: Không cần cài đặt nguyên bản repository này lên máy phát triển cá nhân, nhưng bắt buộc phải chắt lọc (clean-room distill) toàn bộ triết lý thiết kế của nó.

Lý do:

1. google-research/harness2 là testbed học thuật chạy sweep trên benchmark (JobBench, LAB, WorkBuddy-Bench), không phải interactive coding CLI dùng hàng ngày.
2. Chạy probe song song ngốn token cấp số nhân, đòi hỏi cài Docker, Pandoc, Poppler và tải dữ liệu hàng gigabyte.

Bốn bài học cốt lõi cần chắt lọc ngay:

• Tối giản prompt luôn bật: Đưa quy trình nghiệp vụ vào On-demand Skills.
• Quy tắc Trigger Line: Luôn khai báo câu kích hoạt trong prompt chính để skill không bị bỏ quên.
• Tỷ lệ vàng của Subagent: Chỉ dùng subagent khi đầu vào cực lớn nhưng câu trả lời cực nhỏ.
• Chặn lỗi ở tầng Middleware: Dùng plugin hook cắt tỉa output và kiểm tra file write ngay tại runtime.

Triển khai thực tế: Đoạn mã adapter mẫu

Cấu hình mẫu mô phỏng cách đọc cây thành tố và đo lường ngân sách văn bản luôn bật qua interface chuẩn của Harness²:

from pathlib import Path
from harness2.core import tree
from harness2.core.spec import ChannelSpec
from harness2.core.proposer import Proposer

# Cấu hình kênh giao tiếp OpenCode với model đóng băng qua Vertex AI
spec = ChannelSpec(
    kind="opencode",
    model="google-vertex/gemini-2.5-flash",
)
proposer = Proposer(spec=spec, attempts=2)

# Đọc cây harness và kiểm tra dung lượng văn bản luôn bật
harness = tree.read_tree(surface=tree.OPENCODE, d=Path("context/harness"))
prompt_body = tree.always_on_text(surface=tree.OPENCODE, tree=harness)
char_count = len(prompt_body)

print(f"Dung lượng prompt luôn bật: {char_count} ký tự (~{char_count // 4} tokens)")
assert char_count < 12000, "Cảnh báo: Prompt luôn bật đang chiếm quá nhiều context!"

---

Câu hỏi thường gặp (FAQ)

1. Lập trình viên có nên cài đặt repo google-research/harness2 lên máy làm việc không?

Không nên. Repo này là phòng thí nghiệm đo benchmark trên Docker, không phải công cụ lập trình trực tiếp. Giá trị thực tế lớn nhất là chắt lọc 4 nguyên lý kiến trúc (thứ bậc 5 tầng, prompt tinh gọn, trigger cho skill và hook can thiệp runtime) vào agent nội bộ.

2. Harness² có làm tăng chi phí API gấp nhiều lần không?

Trong giai đoạn thăm dò với ngân sách k > 1, Harness² tiêu tốn nhiều lượt gọi API hơn do chạy thử các biến thể song song. Tuy nhiên, khi cấu hình tối ưu được tổng hợp và bài học ghi vào Ledger, hệ thống giúp loại bỏ các vòng lặp vô tận, giảm thiểu các bước sai hướng và ngăn chặn việc đốt token vào những lệnh timeout không cần thiết.

3. Tại sao Harness² không cần đáp án chuẩn mà vẫn biết phương án nào tốt hơn?

Framework áp dụng cơ chế đánh giá đối lập hành vi (behavioral contrast). Bằng cách phân tích trajectory log, hệ thống nhận diện phương án nào gặp lỗi cú pháp, bị treo công cụ, hoặc hoàn thành đầy đủ các trường dữ liệu mà không làm tràn ngữ cảnh.

4. Tôi có thể áp dụng tư duy Harness² cho OpenCode hay Codex không?

Có. Mã nguồn chính thức của Harness² hỗ trợ sẵn cả hai môi trường thực thi là OpenCode và Codex (--substrate cx). Bạn có thể áp dụng cấu trúc cây 8 thành tố và các bộ lọc plugin vào dự án agent nội bộ ngay hôm nay.

5. Điểm khác biệt mấu chốt giữa Skill và Subagent trong Harness² là gì?

Skill là quy trình tác nghiệp nạp trực tiếp vào ngữ cảnh chính khi có tín hiệu kích hoạt (on-demand), phù hợp luồng công việc cần sự liền mạch. Ngược lại, Subagent chạy độc lập với context riêng biệt, chỉ trả về kết quả dạng văn bản ngắn gọn, là giải pháp tối ưu khi xử lý dữ liệu đầu vào khổng lồ.