Harness engineering là gì? Kiến trúc, vai trò và tương lai

Trong kiến trúc hệ thống hiện đại, người ta định nghĩa agent qua một công thức rất thực dụng: agent = model + harness. Nếu bạn không tự huấn luyện các trọng số của mô hình—việc đòi hỏi tài nguyên khổng lồ và dữ liệu chuyên biệt—thì gần như toàn bộ giá trị kỹ thuật nằm ở phần harness.

Trong khi cộng đồng lập trình phổ thông còn tranh luận mô hình nào có điểm benchmark cao hơn, các kỹ sư hệ thống thực thụ đã tập trung thiết kế logic thực thi, chính sách ngữ cảnh và vòng lặp phản hồi quanh chúng.

Thực tế triển khai AI hiện nay cho thấy mô hình chỉ là một thành phần đầu vào của hệ thống agent. Phần còn lại chính là harness: gồm các prompt hệ thống, hệ thống công cụ (tools), chính sách quản lý ngữ cảnh (context policies), các hook can thiệp, sandbox an toàn, subagent và các đường phục hồi (recovery paths) để mô hình thực sự làm xong việc. Mục tiêu của harness engineering không phải là "nhờ" AI làm tốt hơn bằng những câu lệnh văn chương, mà là dựng một môi trường thực thi ràng buộc chặt, liền mạch về trạng thái và có khả năng tự sửa lỗi. Khi một agent mắc lỗi, thay vì đổ cho mô hình rồi chờ phiên bản tiếp theo (như GPT-6 hay Claude 4), kỹ sư harness xem đó là một "vấn đề cấu hình" và kỹ thuật hóa cách khắc phục để lỗi đó không bao giờ lặp lại.

Chặng đường từ một bản demo ấn tượng đến một sản phẩm ổn định trong production chính là quá trình lấp dần khoảng cách về harness. Những gì bạn thấy một agent làm được trong thực tế thường thấp hơn nhiều so với năng lực lý thuyết của nó; khoảng cách đó chính là chỗ thiếu của các "dây cương" kỹ thuật. Nắm vững kỷ luật này giúp bạn chuyển từ tư duy của một người dùng AI sang tư duy của một kiến trúc sư hệ thống AI: bạn dựng sẵn các rào cản tất định để kiểm soát hành vi của agent, thay vì trông chờ vào sự may rủi của những phản hồi mang tính xác suất.

Harness engineering là gì?

Trong kỹ thuật AI, harness engineering không phải là nghệ thuật đặt câu hỏi, mà là kỷ luật thiết kế trọn vẹn cái "môi trường thực thi" (execution environment) đó. Harness là mọi mảnh code, cấu hình và logic thực thi không thuộc về bản thân mô hình. Bóc tách phần trọng số mô hình ra, tất cả những gì còn lại chính là harness. Một mô hình thô (raw model) chỉ là một bộ dự đoán văn bản; nó chỉ trở thành agent khi được harness cấp cho trạng thái (state), khả năng kích hoạt công cụ (actuation) và các ràng buộc có thể kiểm soát.

Xét về cấu thành kỹ thuật, một harness trưởng thành gồm nhiều thành phần đan xen: các tệp cấu hình quy tắc như CLAUDE.md hay AGENTS.md, các MCP server (Model Context Protocol) để mở rộng khả năng, hạ tầng đóng gói (sandbox, filesystem), logic điều phối (orchestration) và các middleware để nén ngữ cảnh (compaction) hoặc chạy linter. Thay đổi tư duy cốt lõi ở đây là coi agent như một hệ thống phần mềm truyền thống: LLM chỉ đóng vai CPU xử lý phần logic mờ, còn harness đóng vai một hệ điều hành (OS) quản lý tài nguyên, quyền hạn và luồng thực thi. Mỗi khi agent định làm một hành động, harness đứng giữa kiểm tra xem hành động đó có phạm chính sách bảo mật hay convention của dự án hay không, rồi mới cho chạy.

Mục tiêu sau cùng của harness engineering là tạo ra một cấu trúc bền vững cho agent. Thói quen quan trọng nhất của một kỹ sư harness là coi mỗi lỗi của agent như một tín hiệu hệ thống để cập nhật giàn giáo. Nếu agent xóa nhầm một file quan trọng, lời giải không phải là nhắc nó "cẩn thận hơn", mà là cài một hook trong harness để chặn các lệnh bash nguy hiểm hoặc bắt buộc có người xác nhận. Cứ như vậy, harness được siết chặt dần sau mỗi lần vấp, biến những thất bại ngẫu nhiên thành các quy tắc vận hành tất định. Đó là bước chuyển từ chỗ dựa vào "vibe" (cảm tính) sang kỹ thuật hệ thống nghiêm túc.

Tại sao harness quyết định hiệu năng nhiều hơn mô hình?

Dữ liệu thực tế từ các bài đo hiệu năng chuẩn như Terminal Bench 2.0 phơi bày một sự thật khắc nghiệt: năng lực lý thuyết của mô hình chỉ là mức trần, còn harness mới là thứ quyết định mức sàn trong production. Chẳng hạn, mô hình Claude Opus 4.6 khi chạy trong môi trường Claude Code (một harness được tối ưu sâu) đạt điểm vượt trội so với khi chạy trong một harness tự chế kém tối ưu. Tái cấu trúc lại harness—chia nhỏ tác vụ, quản lý trạng thái và dựng tín hiệu phản hồi—có thể đưa một coding agent từ top 30 lên top 5 trên các bảng xếp hạng mà không đụng đến bất kỳ trọng số mô hình nào. Nó cho thấy tiềm năng chưa khai phá của mô hình thường bị kẹt lại chỉ vì lớp giàn giáo bao quanh quá lỏng lẻo.

Bài toán chi phí cho một góc nhìn rất thực dụng về giá trị của harness. Một agent chạy đơn lẻ (solo agent) có thể chỉ tốn 9 USD và 20 phút để xong một tác vụ, nhưng kết quả thường là một sản phẩm lỗi hoặc không chạy được. Ngược lại, một hệ thống dùng harness đầy đủ (gồm Planner, Generator và Evaluator) có thể tốn tới 200 USD và 6 giờ làm việc liên tục—đổi lại là một phần mềm hoàn chỉnh, đã qua kiểm thử và sẵn sàng triển khai (deploy). Khi mô hình tiến từ phiên bản 4.5 lên 4.6, chi phí này giảm còn khoảng 124,70 USD nhờ tỉa bớt các thành phần harness dư thừa. Với một doanh nghiệp, bỏ 200 USD để có kết quả đúng vẫn rẻ hơn nhiều so với bỏ 9 USD rồi nhận về một kết quả sai nhưng trông có vẻ đúng.

Phần lớn thất bại của agent hiện nay thực ra là "vấn đề kỹ năng" (skill issue) đến từ cấu hình sai hoặc thiếu hụt ngữ cảnh trầm trọng, chứ không phải do mô hình "ngốc". Thực tế cho thấy chuyển cách tiếp cận từ context engineering sang harness engineering có thể đẩy tỷ lệ thành công của tác vụ từ 70% lên hơn 95%. Luận điểm của Ryan Lopopolo (OpenAI) củng cố điều này: khi code trở thành một tài nguyên gần như miễn phí và dồi dào, rào cản duy nhất còn lại là cách chúng ta khai thác (harness) năng lực đó. Khi mỗi kỹ sư có thể vận hành hàng nghìn agent song song, khả năng giữ cho hệ thống ổn định bằng các guardrail và linter riêng trong harness sẽ trở thành lợi thế cạnh tranh cốt lõi, chứ không còn chỉ là việc sở hữu API key của mô hình mạnh nhất.

Harness, prompt và context engineering khác nhau thế nào?

Để thấy rõ vị trí của harness engineering, hãy nhìn vào ba giai đoạn tiến hóa của kỹ thuật AI. Giai đoạn 1 là prompt engineering, nơi trọng tâm là câu lệnh (mô hình có hiểu tôi không?). Giai đoạn 2 là context engineering, tập trung vào quản lý dòng dữ liệu qua RAG, MCP và tool calling (mô hình có đủ thông tin không?). Giai đoạn 3 chính là harness engineering, tập trung vào hệ thống và thực thi bền vững (mô hình có giữ được hành động đúng không?). Harness không thay thế hai giai đoạn trước mà bao trùm chúng, đồng thời nâng chúng lên mức thực thi cưỡng bức (enforcement). Nếu prompt engineering chỉ dừng ở những "lời yêu cầu", thì harness engineering dựng ra các cơ chế kiểm tra tự động mà agent buộc phải vượt qua.

Khung phân loại của ThoughtWorks cho ta một ma trận 2x2 cực kỳ hữu ích để phân biệt các kiểu kiểm soát trong một harness. Trục thứ nhất chia thành Feedforward (dẫn dắt — áp dụng trước khi agent hành động) và Feedback (phản hồi — áp dụng sau khi agent đã hành động). Trục thứ hai chia thành Computational (tính toán — các kiểm tra tất định như linter, type-check chạy trong mili giây) và Inferential (suy diễn — dùng một LLM khác để đánh giá ngữ nghĩa, chậm và đắt hơn). Một harness mạnh phải kết hợp đủ cả bốn ô này: chẳng hạn dùng AGENTS.md làm hướng dẫn (Inferential Feedforward), dùng Zod schema để kiểm soát định dạng (Computational Feedforward), chạy bộ test tự động (Computational Feedback) và dùng một Evaluator agent để chấm chất lượng UI (Inferential Feedback).

Khác biệt lớn nhất nằm ở khả năng chống lại "chệch hướng thực thi". Trong context engineering, khi một agent đi qua 40 bước, nó rất dễ lạc lối vì ngữ cảnh bị pha loãng (Context Rot). Harness engineering xử lý chuyện này bằng cách dựng sẵn các đường ray nghiêm ngặt. Thay vì để agent tự quyết định bước tiếp theo, harness cưỡng ép một quy trình: hiểu mục tiêu → đánh giá thông tin → thu thập dữ liệu → phân tích → tạo → xác thực. Nếu bước xác thực thất bại, harness ném agent trở lại bước phân tích kèm một thông báo lỗi chi tiết, thay vì để nó tự tin tuyên bố thành công trong khi kết quả vẫn đang lỗi.

Một harness gồm những thành phần nào?

Một kiến trúc harness trưởng thành thường được dựng trên sáu lớp, mỗi lớp lo một loại thất bại khác nhau. Lớp đầu tiên là Information Boundaries (phạm vi nhận thức). Đây là nơi hệ thống phân loại và giới hạn những gì mô hình được nhìn thấy để tránh hiện tượng "nhiễu ngữ cảnh". Nhồi quá nhiều dữ liệu thô vào cửa sổ ngữ cảnh không làm mô hình thông minh hơn, chỉ làm nó xao nhãng khỏi các quy tắc cốt lõi. Kỹ thuật "Progressive Disclosure" (tiết lộ lũy tiến) là một thành phần quan trọng ở lớp này: harness chỉ hé lộ schema của công cụ và tài liệu hướng dẫn khi tác vụ thực sự cần, nhờ đó giảm "áp lực ngữ cảnh" (Context Anxiety) cho mô hình.

Lớp thứ hai và thứ ba là Tool System (hệ thống kích hoạt) và Execution Orchestration (điều phối thực thi). Lớp kích hoạt không chỉ cấp công cụ mà còn quản lý quyền thực thi. Sandbox là thành phần bắt buộc ở đây, để mọi lệnh bash hay code do agent tạo ra đều chạy trong môi trường cô lập, an toàn. Lớp điều phối lo việc vạch lộ trình thực thi và giữ tính tất định. Thay vì để agent "tự do tự tại", lớp này cắm các checkpoint bắt buộc. Ví dụ, một agent không được phép viết code nếu chưa hoàn thành bản đặc tả kỹ thuật (Technical Spec) và được lớp Evaluator phê duyệt.

Các lớp còn lại gồm Memory and State (quản lý trạng thái), Evaluation and Observability (đánh giá và quan sát) và Constraints and Recovery (ràng buộc và phục hồi). Trong một harness thực chiến, filesystem và Git đóng vai các primitive (nguyên thủy) cơ bản cho trạng thái bền vững, cho agent chỗ để đẩy bớt các kết quả trung gian thay vì giữ tất cả trong RAM (ngữ cảnh). Lớp phục hồi đảm bảo khi một API timeout hoặc một subagent bị treo, hệ thống có thể tự động thử lại hoặc khôi phục về trạng thái ổn định gần nhất trên Git. Đáng chú ý, kiến trúc "Managed Agents" đề xuất tách hẳn ba phần Brain (mô hình), Hands (môi trường thực thi) và Session logs (nhật ký sự kiện): khi một phần gặp sự cố, các phần còn lại vẫn giữ được tính toàn vẹn của tác vụ.

Những nguyên tắc cốt lõi khi xây dựng harness

Nguyên tắc cao nhất trong harness engineering là thói quen "The Ratchet" (bánh răng một chiều). Mỗi khi agent mắc lỗi trong production, hãy coi đó là một tín hiệu quý để siết chặt hệ thống. Bạn cần kỹ thuật hóa một cách khắc phục—có thể là một quy tắc mới trong AGENTS.md, một linter viết riêng, hoặc một hook kiểm tra bảo mật—để lỗi đó không bao giờ lặp lại lần thứ hai. Một tệp quy tắc tốt không đến từ việc ngồi nghĩ ra đủ các tình huống giả định, mà là một "nhật ký chiến trường" nơi mỗi dòng lệnh đều truy ngược được về một thất bại cụ thể trong quá khứ.

Để đối phó với hiện tượng "thối rữa ngữ cảnh" (Context Rot) trong các tác vụ dài hơi, kỹ thuật "Context Reflect" (phản chiếu ngữ cảnh) là một vũ khí quan trọng. Khi cửa sổ ngữ cảnh sắp đầy, thay vì nhồi tiếp hoặc tóm tắt qua loa, harness chạy lại một quy trình khởi động bảy bước: (1) xác nhận thư mục làm việc, (2) đọc git logs và progress files, (3) đối chiếu danh sách tính năng ưu tiên, (4) khởi động môi trường kiểm thử, (5) chạy xác thực end-to-end cơ bản, (6) làm đúng một tính năng duy nhất, (7) commit và cập nhật trạng thái. Quy trình này cho phép khởi động lại agent với một bản tóm tắt nén "sạch sẽ"—reset trạng thái chú ý của mô hình mà vẫn giữ được mạch liên tục của công việc.

Một nguyên tắc thực thi khác là tách bạch tuyệt đối giữa Planner (lập kế hoạch), Generator (tạo) và Evaluator (đánh giá). Mô hình ngôn ngữ có một thiên hướng tâm lý: luôn ưu ái sản phẩm của chính mình. Vì vậy, dùng cùng một agent vừa viết code vừa tự chấm điểm là một sai lầm chết người. Harness cần lập một "Sprint Contract" (hợp đồng sprint) giữa Generator và Evaluator: trước khi bắt đầu, cả hai phải thống nhất về định nghĩa "hoàn thành" (definition of done). Evaluator phải là một instance độc lập, thậm chí dùng các công cụ thật như Playwright hay browser automation để tương tác với sản phẩm như một người dùng thật, thay vì chỉ đọc code rồi đoán xem nó có chạy hay không.

Claude Code và các harness thực chiến

Trong thực tiễn phát triển AI năm 2026, các công cụ như Claude Code, Cursor hay Aider thực chất là những harness khác nhau dựng trên cùng một mô hình nền tảng. Claude Code dùng cấu trúc tệp chuẩn gồm CLAUDE.md cho các quy tắc cấp dự án (tech stack, coding convention) và AGENTS.md cho các chỉ dẫn riêng của agent. Những tệp này hoạt động như một "Pilot's Checklist" (danh sách kiểm tra của phi công), được tiêm vào mỗi lượt tương tác để nhắc agent về các ràng buộc phi chức năng như timeout, retry hay giới hạn độ dài file. Một quy tắc phổ biến trong AGENTS.md của các kỹ sư senior thường là: "Cấm comment-out test; nếu không sửa được thì phải xóa và log lại lý do".

Nguồn: I built an autonomous harness for Claude Code — r/ClaudeAI

Một ví dụ cấu hình thực tế trong lớp "Constraints and Recovery" là việc cài các hook chạy code. Thay vì để agent tự do gõ npm test, harness bọc lệnh này trong một middleware để bắt lỗi và định dạng lại output. Nếu linter báo lỗi, harness không chỉ hiện thông báo lỗi thô mà còn chèn thêm các bước sửa (remediation steps) vào prompt tiếp theo. Nhờ vậy agent tự sửa lỗi nhanh mà không cần con người can thiệp. Ryan Lopopolo (OpenAI) chia sẻ rằng việc triển khai các linter viết riêng—chẳng hạn giới hạn mỗi file không quá 350 dòng để tối ưu ngữ cảnh—đã giúp đội của ông giữ được một codebase có "harnessability" cao, tức cực kỳ dễ đọc và dễ bảo trì với các agent.

Một ví dụ về quy tắc thực thi nghiêm ngặt trong một file harness tiêu chuẩn:

# Quy tắc thực thi (Enforcement)
- Mọi API endpoint mới PHẢI có Zod schema để xác thực dữ liệu đầu vào.
- Nếu git diff vượt quá 500 dòng, hãy chia nhỏ PR thành các sub-task.
- Thành công thì im lặng (silent success), thất bại thì ồn ào (verbose failure).
- Không bao giờ dùng git push --force trên các nhánh main/production.
- Luôn chạy linter và type-check trước khi đề xuất hoàn thành tác vụ.

Cấu trúc này biến mong muốn của lập trình viên thành ràng buộc hệ thống. Khi agent định phá vỡ quy tắc, lớp middleware của harness sẽ chặn hành động đó ngay tại sandbox, tạo ra một vòng lặp phản hồi tức thì kéo agent về đúng hướng mà không làm hỏng codebase.

Harness engineering đang đi về đâu?

Tương lai của kỷ luật này đang dịch mạnh sang mô hình HaaS (Harness-as-a-Service). Lập trình viên sẽ không còn phải tự dựng vòng lặp ReAct hay quản lý sandbox thủ công. Thay vào đó, họ dùng các harness SDK trưởng thành (như OpenAI Agents SDK hoặc Claude Agent SDK) đã đóng gói sẵn các lớp quản lý trạng thái, điều phối subagent và firewall ngữ cảnh. Mặt trái là chính sự tiện lợi này lại sinh ra một hiện tượng mới gọi là "Harness Decay" (sự thoái hóa của harness). Khi các mô hình nền tảng (như GPT-5 hay Claude 4.7) ngày càng thông minh, chúng bắt đầu tự tiếp thu (internalize) một số khả năng vốn thuộc về harness, chẳng hạn tự lập kế hoạch hoặc tự xác thực kết quả.

Hướng đi này gợi nhớ "Bitter Lesson" (bài học cay đắng) của Rich Sutton: về dài hạn, các phương pháp tính toán tận dụng sức mạnh phần cứng luôn thắng các phương pháp do con người thiết kế thủ công. Với agent, điều đó có nghĩa là một số logic giàn giáo phức tạp ta dựng hôm nay có thể thành "rác hệ thống" vào ngày mai, khi mô hình đủ mạnh để tự lo. Vì thế, một senior AI architect phải theo nguyên tắc "Build to Delete" (xây để xóa). Mọi thành phần trong harness nên được thiết kế theo dạng module và có sẵn một "nút tắt" (kill switch), để bạn gỡ bỏ khi mô hình mới đã đủ sức tự làm tác vụ đó một cách ổn định—qua đó giảm độ trễ và chi phí token.

Xa hơn nữa, harness sẽ không còn là cấu hình tĩnh mà trở thành một thực thể động, giống như một trình biên dịch (compiler). Thay vì một bộ quy tắc cố định cài đặt lúc startup, harness sẽ tự phân tích độ phức tạp của tác vụ rồi lắp ráp đúng các công cụ, ngữ cảnh và subagent cần thiết ngay tại thời điểm thực thi (just-in-time). Lúc đó, harness đóng vai một hệ thống điều khiển thông minh, liên tục cân bằng ba yếu tố: chi phí (token budget), tốc độ (latency) và độ tin cậy. Harness engineering sẽ không biến mất; nó chỉ dịch từ việc "vá lỗi mô hình" sang việc "tối ưu hiệu năng hệ thống AI" ở quy mô lớn.

Các câu hỏi thường gặp

Harness khác gì một framework như LangChain hay AutoGPT? Framework là bộ công cụ cung cấp các viên gạch (code library), còn harness là bản thiết kế và cách bạn xếp các viên gạch đó lại thành một môi trường thực thi ổn định. Harness nhấn vào sự ràng buộc, kiểm soát và phục hồi trong production, chứ không chỉ là việc nối các API lại với nhau.

Vì sao chi phí vận hành harness lại cao hơn hẳn so với prompt đơn thuần? Vì một harness tốt thường chạy nhiều lượt suy diễn (multi-turn), nhiều agent (Planner, Generator, Evaluator) và các bước xác thực tốn kém. Bù lại, chi phí đó được hoàn vốn nhờ cắt được khâu sửa lỗi thủ công và ngăn các thảm họa trong production.

Khi nào tôi nên gỡ bỏ một thành phần trong harness? Hãy chạy thử nghiệm A/B mỗi khi có mô hình mới. Nếu bạn tắt lớp Evaluator mà tỷ lệ thành công của tác vụ không giảm, đó là lúc thành phần đó đã "thoái hóa" và nên xóa đi để tiết kiệm tài nguyên, theo đúng nguyên tắc "Build to Delete".

Harness engineering có dành cho dự án nhỏ không? Có. Ngay với một dự án nhỏ, việc duy trì tệp CLAUDE.md và dựng một sandbox cơ bản đã là bước khởi đầu của harness engineering. Nó giúp bạn tránh cảnh agent làm hỏng cấu trúc thư mục hay ghi đè code bừa bãi ngay từ những ngày đầu.

Tài liệu tham khảo

• Harness Engineering: What Every AI Engineer Needs to Know in 2026 — Yanli Liu
• Agent Harness Explained in 8 Minutes — Caleb Writes Code
• Harness Engineering: Make Your AI Agent Perform Better Than 80% of Others — Nick T.
• Building Claude Code with Harness Engineering
• How to Build Harness 2.0: Better Than 99% of People — Gao Dalie
• Agent Harness Engineering — Addy Osmani
• Harness Engineering: How to Build Software When Humans Steer, Agents Execute — Ryan Lopopolo, OpenAI