Bạn đang tìm thứ gì đó thật, từ người đã thực sự đi qua.
Mình hiểu cảm giác đó. Việt đã ở đó rồi.
Hệ thống GTD Notion mình đang dùng hằng ngày —
Copy về, điền vào, dùng ngay hôm nay.
Không mất tiền. Không cần cam kết gì hết. Chỉ là bước đầu tiên — nếu bạn muốn.
Không spam. Unsubscribe 1 click bất cứ lúc nào.
Prompt Engineering, Context Engineering, và giờ là Harness Engineering — thế giới AI đang đổi tên gọi mỗi năm. Nhưng lần này không phải chỉ là trend mới: đây là sự thay đổi thật sự trong cách chúng ta tư duy về AI systems.
Câu hỏi không còn là "viết prompt thế nào cho hay?" Câu hỏi đúng là: "Làm sao thiết kế toàn bộ môi trường để AI hoạt động đúng, ổn định, và không lặp lại lỗi?"
Key Takeaways
Harness Engineering = thiết kế toàn bộ "hệ sinh thái" xung quanh AI model (tools, memory, permissions, feedback loops) — không phải bản thân model
Model không phải thứ quan trọng nhất: Cùng 1 model, chỉ thay đổi môi trường → hiệu suất tăng 64% (Princeton NLP, NeurIPS 2024)
Context Engineering là tập con: Harness Engineering bao rộng hơn — tool design, state management, multi-agent coordination, verification
Anthropic xây Claude Code tạo $2.5 tỷ ARR chủ yếu nhờ harness, không phải model weights
Harness Engineering Là Gì?
Harness Engineering là kỹ thuật xây dựng toàn bộ "môi trường" xung quanh một AI model — bao gồm tools, quyền truy cập, bộ nhớ, feedback loops, guardrails, cách quản lý context, cách handoff giữa các sessions — tất cả mọi thứ trừ bản thân model.
Thuật ngữ này do Mitchell Hashimoto — founder HashiCorp, cha đẻ Terraform — đặt tên vào tháng 2/2026. Định nghĩa của ông rất thực chiến:
"Anytime you find an agent makes a mistake, you take the time to engineer a solution such that the agent never makes that mistake again."
Trích dẫn
Dịch thẳng: Mỗi khi agent sai, đừng cầu nguyện nó làm tốt hơn lần sau — xây giải pháp để nó không bao giờ sai cách đó nữa.
Ba Giai Đoạn Tiến Hóa
Giai đoạn
Thời kỳ
Câu hỏi cốt lõi
Prompt Engineering
2022–2024
"Hỏi AI thế nào cho đúng?"
Context Engineering
2025
"Đưa thông tin gì cho AI để nó trả lời tốt?"
Harness Engineering
2026+
"Toàn bộ hệ thống xung quanh AI vận hành ra sao?"
Nếu muốn có một hình dung cụ thể hơn:
Prompt engineering = viết email
Context engineering = đính kèm đúng file vào email
Harness engineering = thiết kế cả văn phòng — quy trình, công cụ, kiểm soát chất lượng — để công việc thật sự hoàn thành
Tại Sao Model Không Phải Thứ Quan Trọng Nhất?
Đây là điểm nhiều người chưa "ngấm" được — và nó đi ngược hoàn toàn với cách AI labs truyền thông.
Số liệu thực tế từ nghiên cứu: Nhóm Princeton NLP đã publish paper SWE-agent tại NeurIPS 2024 — một trong những conference uy tín nhất về AI. Kết quả:
Cùng model, cùng task, cùng compute budget — chỉ thay đổi cách thiết kế môi trường — hiệu suất tăng 64%.
Trích dẫn
64% không phải con số nhỏ. Đó là sự khác biệt giữa một tool dùng được và một tool vô dụng. Và nó đến hoàn toàn từ environment design.
Rohit Verma, một AI engineer nổi tiếng trên X, tóm gọn trong một câu:
"The model is what thinks. The harness is what it thinks about. Getting that distinction right is the entire game."
Trích dẫn
Tạm dịch: Model là thứ suy nghĩ. Harness là thứ mà nó suy nghĩ VỀ. Hiểu đúng sự khác biệt này — bạn thắng.
Bài Học Từ SWE-Agent: +64% Chỉ Nhờ Thiết Kế Interface
Paper SWE-agent giới thiệu khái niệm ACI (Agent-Computer Interface) — interface giữa AI agent và môi trường làm việc. Giống như HCI (Human-Computer Interface) thiết kế giao diện cho người dùng, ACI thiết kế giao diện cho AI agent.
Insight quan trọng: AI agent không suy nghĩ như con người. Nó xử lý token tuần tự, nhạy cảm với thứ tự thông tin, working memory giới hạn, và rất dễ bị "nhiễu" bởi thông tin không liên quan. Thiết kế interface tốt nghĩa là hiểu những hạn chế này và build xung quanh chúng, không phải chống lại chúng.
4 Quyết Định Thiết Kế Tạo Nên 64%
1. Giới hạn kết quả tìm kiếm (tối đa 50 items)
Khi chạy grep trên codebase lớn → 10,000 dòng kết quả. Đây không phải thêm thông tin cho agent — đây là flood working memory bằng rác. Agent sẽ loop thêm grep, tạo noise, fill hết context window, rồi sai hoặc kẹt.
Giải pháp: Giới hạn tối đa 50 items. Vượt 50 thì báo "quá nhiều kết quả, hãy refine query." Nghe đơn giản — nhưng đây là một trong những quyết định có đòn bẩy cao nhất trong toàn bộ paper.
2. File viewer hiển thị số dòng (100 dòng/lần)
100 dòng là con số "Goldilocks": ít hơn (30 dòng) thì mất context xung quanh; nhiều hơn thì agent quên mất đang ở đâu. Và quan trọng: prepend số dòng vào mỗi dòng. Khi agent cần edit dòng 47-52, nó đọc trực tiếp thay vì đếm. Tiết kiệm working memory cho việc quan trọng hơn.
3. Editor tích hợp linter sau mỗi lần edit
Sau mỗi lần edit, tool tự động chạy linter. Nếu tạo ra syntax error → reject ngay trước khi apply, kèm error message rõ ràng. Cái này ngăn failures dây chuyền: agent tạo lỗi → chạy test → thấy fail ở chỗ khác → 10 bước đuổi theo bug "ma" → hết context mà chưa fix được.
4. Context compression sau 5 turns
Lịch sử cũ hơn 5 turns được nén thành summary 1 dòng. Agent vẫn biết mình đã làm gì, nhưng không bị chôn vùi trong full history.
Anthropic Dạy Chúng Ta Cách Build App Dài Hơi
SWE-agent giải quyết bài toán "làm sao thiết kế interface cho một session." Nhưng thực tế thì sao? Hầu hết project phần mềm đều quá lớn để hoàn thành trong một context window.
Team Anthropic phát hiện hai pattern thất bại lặp đi lặp lại:
Pattern 1 — "Làm quá nhiều một lúc": Agent nhận prompt "build clone của claude.ai", cố implement tất cả cùng lúc. Feature này chưa xong đã nhảy sang feature kia, hết context window giữa chừng, session tiếp theo nhận được đống code dở dang, không tài liệu.
Pattern 2 — "Tuyên bố chiến thắng quá sớm": Agent nhìn quanh, thấy có code rồi, kết luận "xong rồi!" rồi dừng. Lý do: suy luận hợp lý từ thông tin không đầy đủ — agent không biết "xong" nghĩa là gì cho project này.
Giải Pháp: Kiến Trúc Multi-Agent
Phiên bản V1 (2025) — 2 agent:
Initializer: Session đầu tiên chuyên biệt — setup môi trường, tạo feature list 200+ items (mỗi item: "passes": false), commit git đầu tiên
Coding Agent: Mỗi session sau — làm 1 feature, test, commit, update progress file, clean state
Chi tiết đáng chú ý: Feature list lưu dạng JSON thay vì Markdown. Lý do: empirically, model ít có xu hướng tự ý overwrite file JSON hơn Markdown. JSON có cấu trúc cứng, chống edit bừa bãi.
Phiên bản V2 (3/2026) — 3 agent:
Agent
Vai trò
Planner
Nhận prompt 1-4 câu → expand thành full product spec (ambitious về scope, không đi sâu chi tiết kỹ thuật)
Generator
Build từng feature theo sprint, dùng React + Vite + FastAPI
Evaluator
Dùng Playwright MCP → click vào app như user thật, cho điểm 4 tiêu chí: design, originality, craft, functionality
Kết quả thực tế (cùng 1 prompt):
Cách tiếp cận
Thời gian
Chi phí
Kết quả
Solo agent
20 phút
$9
Game KHÔNG chạy được
Full harness (3-agent)
6 giờ
$200
Game chạy được + AI features + design coherent
$200 nghe có vẻ nhiều. Nhưng bạn nhận lại một sản phẩm hoạt động — so với $9 nhận về một đống code không dùng được.
Vụ Leak Claude Code: Bằng Chứng Harness Là "Bí Mật Thật"
Ngày 31/3/2026, Anthropic vô tình ship một file source map 59.8MB trong package @anthropic-ai/claude-code v2.1.88 trên npm. Trong vài giờ, 512,000 dòng TypeScript bị mirror khắp GitHub.
Điều đáng chú ý: thứ bị leak không phải model weights — mà là agentic harness — toàn bộ lớp vỏ bọc xung quanh model. Và nhìn vào nó, ta hiểu tại sao Claude Code tạo ra $2.5 tỷ ARR.
Những Phát Hiện Kinh Khủng Bên Trong
5 chiến lược quản lý context (theo thứ tự leo thang):MicroCompact → AutoCompact → Full Compact → Session Memory → Truncation
Memory 3 tầng:
Tầng 1: MEMORY.md — chỉ ~200 tokens, luôn được load, đây là "index" trỏ đến knowledge khác
Tầng 2: Topic files — load on-demand khi cần
Tầng 3: Full session transcripts — có thể search
Còn có mode autoDream — khi user idle, một forked subagent chạy ngầm để merge observations, loại bỏ mâu thuẫn logic, nén insights. Giống hệt cơ chế memory consolidation trong giấc ngủ của con người.
3 mô hình subagent:
Fork: Chia sẻ KV cache với parent (parallel gần như free!)
Teammate: Giao tiếp qua mailbox
Worktree: Git branch riêng biệt
Frustration detection bằng regex — không cần LLM:
Claude Code phát hiện user frustrated qua pattern matching: "wtf", "so frustrating", "this is broken" → điều chỉnh tone phản hồi. $0 regex thắng $0.01 model call khi accuracy tương đương. Đây là nguyên tắc harness engineering cốt lõi: dùng tool rẻ nhất, nhanh nhất giải quyết được vấn đề.
Harness Engineering vs Context Engineering: Khác Nhau Chỗ Nào?
Đây là câu hỏi phổ biến nhất — và ranh giới vẫn còn mờ.
Theo cách hiểu hợp lý nhất:
Context Engineering là tập con của Harness Engineering. Context Engineering trả lời câu hỏi: "Agent cần thấy thông tin gì, lúc nào, dưới format nào?"
Harness Engineering bao gồm context engineering nhưng rộng hơn nhiều. Nó còn bao gồm:
Thành phần
Câu hỏi
Tool design
Agent dùng tools gì? Permissions ra sao?
Feedback loops
Lỗi được bắt ở đâu, phản hồi thế nào?
State management
State sống sót qua sessions như thế nào?
Multi-agent coordination
Các agents phối hợp ra sao?
Security & permissions
Ai được làm gì?
Verification & testing
Output được kiểm chứng thế nào?
Harness Engineering trả lời: "Toàn bộ hệ thống vận hành ra sao?"
Ứng Dụng Thực Tế: Bạn Nên Làm Gì Ngay Hôm Nay?
Bạn không cần xây hệ thống phức tạp như Anthropic để bắt đầu áp dụng tư duy Harness Engineering. Ba việc cụ thể:
1. Audit lỗi lặp lại
Ghi lại những điểm AI của bạn hay sai. Chú ý pattern lặp lại. Thay vì nhắc nhở mỗi lần, hãy build một constraint cứng: file instructions, tool limit, template output.
2. Thiết kế tool tốt hơn
Giới hạn output để agent không bị flood. Thêm validation trước khi apply changes. Nén context khi cần thay vì throw everything vào window.
3. Tách agent theo vai trò
Đừng để 1 agent làm tất cả. Phân vai rõ ràng: Planner (nghĩ big picture) → Executor (làm từng bước nhỏ) → Reviewer (kiểm tra output). Mỗi agent làm đúng 1 việc.
Kết
"Model là thứ suy nghĩ. Harness là thứ mà nó suy nghĩ VỀ. Và harness mới là thứ quyết định kết quả cuối cùng."
Trích dẫn
Harness Engineering, xét cho cùng, là systems thinking áp dụng cho AI agent environments. Không phải một kỹ năng hoàn toàn mới — mà là kỹ năng thiết kế hệ thống, API design, error handling, testing strategy... được áp dụng vào domain mới: thiết kế môi trường cho LLM agents thay vì interface cho con người.
Nếu bạn đang xây dựng hệ thống AI — dù là automation workflow, coding assistant, hay customer service bot — đây là thứ bạn cần bắt đầu đầu tư hôm nay.
Câu Hỏi Thường Gặp
Harness Engineering là gì?
Harness Engineering là kỹ thuật thiết kế toàn bộ môi trường xung quanh AI model — tools, memory, permissions, feedback loops, context management — tất cả trừ bản thân model. Mục tiêu: xây dựng hệ thống để agent không bao giờ lặp lại cùng một lỗi.
Harness Engineering khác Prompt Engineering thế nào?
Prompt Engineering tập trung vào "hỏi AI thế nào." Harness Engineering tập trung vào "thiết kế cả hệ thống xung quanh AI hoạt động ra sao." Prompt Engineering là một phần nhỏ trong Harness Engineering.
Harness Engineering có khó học không?
Nền tảng là systems thinking và software design — những kỹ năng mà developer đã có. Khác biệt chỉ ở domain: thiết kế cho LLM agent thay vì cho người dùng.
Khi nào nên nghĩ đến Harness Engineering?
Khi AI agent của bạn lặp lại cùng một lỗi. Khi agent "tuyên bố xong" quá sớm. Khi hiệu suất giảm sau nhiều turns. Đây là những dấu hiệu môi trường cần được thiết kế lại.
Tài liệu nào để đọc thêm về Harness Engineering?
Paper SWE-agent (Princeton NLP, NeurIPS 2024) là điểm xuất phát tốt nhất. Blog engineering của Anthropic về multi-agent architecture (tháng 3/2026) cũng rất solid về methodology.
