Context & Harness Engineering

Trong vài năm qua, khi nói về AI, phần lớn cuộc thảo luận thường xoay quanh một câu hỏi quen thuộc:

Làm sao viết prompt tốt hơn?

Đó là một câu hỏi hợp lý.

Prompt Engineering từng là điểm khởi đầu quan trọng để mọi người khai thác LLM tốt hơn. Nhưng khi AI bắt đầu đi vào công việc thực tế — từ coding, research, debugging, viết tài liệu, vận hành workflow, cho đến tự động hóa nhiều bước thì một sự thật dần lộ ra:

Vấn đề không còn chỉ là ra lệnh cho model thế nào.

Vấn đề là làm sao để model có đủ context đúng, được đặt trong một khung vận hành đúng, và có thể hoàn thành công việc dài hơi mà không trôi, không quên, không tự ảo tưởng rằng mình đã xong.

Đó chính là lúc ba khái niệm bắt đầu trở nên quan trọng hơn rất nhiều:

• AI Agents

• Context Engineering

• Harness Engineering

Và nếu đi thêm một bước nữa, chúng ta sẽ thấy một chuyển động rất rõ: từ các prompt rời rạc sang workflow có thể scale và bài viết này mình chia sẻ lại hành trình và kinh nghiệm của bản thân mình trong 1 năm qua.

Một chatbot thông thường chủ yếu hoạt động theo mô hình:

Ask → Answer

Trong khi đó, một AI Agent không chỉ trả lời. Nó nhận nhiệm vụ, tự chia nhỏ vấn đề, sử dụng công cụ, ghi nhớ trạng thái, rồi tiếp tục ra quyết định để hoàn thành một chuỗi công việc nhiều bước. Một agent đúng nghĩa thường có 4 thành phần cốt lõi:

• tools

• planning

• memory

• và autonomy.

Nói đơn giản hơn:

• Chatbot giỏi phản hồi

• Agent giỏi thực thi

Sự khác biệt này rất quan trọng. Chatbot thường stateless, tương tác ngắn, rất ít công cụ; còn AI Agent có thể làm việc xuyên nhiều giờ hoặc nhiều ngày, có trạng thái, có quyền truy cập toolchain, và có thể tự quyết định bước tiếp theo.

Đây là lý do vì sao những công cụ như Claude Code không nên được nhìn như “chatbot biết code”. Ở mức vận hành, nó gần hơn với một agent đang làm việc trong production: có nhiều tools, có khả năng phối hợp sub-agent, có cơ chế xử lý lỗi, và có cách duy trì tiến trình dài hạn.

Câu trả lời nằm ở hai giới hạn nền tảng.

Thứ nhất, model không thật sự hiểu toàn bộ hệ thống nếu context được nạp vào sai cách.

Thứ hai, model không tự nhiên biết cách làm việc ổn định trong môi trường nhiều bước, nhiều tool, nhiều lần kiểm tra.

Chính vì vậy, agent mạnh đến đâu cũng bị giới hạn bởi hai bài toán gốc:

• Context Engineering: quản lý thông tin nào được đưa vào model, theo cách nào, vào thời điểm nào

• Harness Engineering: thiết kế hạ tầng và quy trình điều phối cách agent hoạt động trong thực tế

Nếu cần nói ngắn gọn:

Context Engineering giải quyết chất lượng suy luận

Harness Engineering giải quyết độ tin cậy khi thực thi

Đây không phải hai chủ đề tách rời. Chúng bổ sung trực tiếp cho nhau.

Trước khi đi sâu hơn, cần nói công bằng rằng Prompt Engineering không hề mất giá trị.

Một prompt tốt vẫn giúp:

• giảm ambiguity

• định dạng output rõ hơn

• buộc model tập trung vào mục tiêu chính

• tiết kiệm vài vòng sửa qua sửa lại

Ví dụ, thay vì viết:

• Analyze this issue

Ta nên viết:

• Analyze this issue and provide:

1. Summary

2. Root cause with evidence

3. Recommended fix

4. Client-facing explanation

Chỉ riêng việc này cũng đã nâng chất lượng lên đáng kể.

Nhưng vấn đề là: Prompt Engineering chỉ mạnh khi bài toán còn tương đối đơn lẻ. Khi công việc bắt đầu có những đặc điểm như:

• nhiều bước

• nhiều file

• nhiều audience

• nhiều tool

• nhiều trạng thái cần duy trì

• cần consistency lâu dài

Thì prompt thôi không đủ nữa. Bạn có thể viết prompt ngày càng dài hơn, chi tiết hơn, “thông minh” hơn. Nhưng đến một ngưỡng nào đó, chất lượng vẫn sẽ không ổn định. Lý do không phải vì prompt chưa đủ hay, mà vì hệ thống xung quanh model chưa được thiết kế đúng.

Đó là nơi Context Engineering và Harness Engineering bước vào.

Đây là một trong những điểm quan trọng nhất mà mình muốn chia sẻ.

Trong cách nghĩ thông thường, khi agent làm chưa tốt, nhiều người sẽ phản xạ:

thêm context vào đi

Nhưng có một vấn đề nền tảng hơn: context rot. Khi context window dài ra, attention bị pha loãng, khiến khả năng suy luận suy giảm. Vì thế, “nhồi càng nhiều càng tốt” không phải chiến lược đúng.

Đây là insight rất đáng nhớ:

Chọn những gì không nên đưa vào context quan trọng không kém gì chọn những gì nên đưa vào.

Có ba trụ cột khá rõ ràng.

Thứ nhất, system prompts phải đúng cao độ.

• Không quá chung chung để model bị mơ hồ, nhưng cũng không quá cứng đến mức dễ vỡ khi model thay đổi. Phần system prompt nên mang tính nguyên tắc và ranh giới rõ ràng.

Thứ hai, tools phải sạch.

• Nếu có quá nhiều tool trùng chức năng hoặc không rõ mục đích, model sẽ bị nhiễu trong việc chọn cách hành động. Claude Code dùng cơ chế deferred tools để ẩn bớt tool và chỉ “discover” khi cần.

Thứ ba, context nên được nạp “just in time”.

• Thay vì cố load toàn bộ codebase hay toàn bộ project notes, hãy để agent có công cụ đi tìm đúng thông tin đúng lúc. Ví dụ dùng grep, list_dir, search, file lookup thay vì ép model ôm toàn bộ mã nguồn ngay từ đầu.

Nói cách khác:

Context Engineering không phải là nạp thật nhiều thông tin.

Nó là thiết kế để model chạm đúng thông tin vào đúng thời điểm.

Nếu chuyển từ lý thuyết sang ứng dụng thực tế, thì Claude.md là một ví dụ rất điển hình của Context Engineering.

Claude.md không nên bị hiểu như một chỗ để nhồi tất cả prompt mẫu vào.

Vai trò đúng của nó gần hơn với:

• rule nền

• working conventions

• communication defaults

• assumptions được cấm

• style xử lý chuẩn của team

Tức là, Claude.md trả lời câu hỏi:

Trong môi trường làm việc này, AI nên hành xử như thế nào?

Ví dụ những gì nên nằm ở đó:

• không được assume environment nếu chưa xác nhận

• phải verify screenshot/log/CSV trước khi kết luận

• output mặc định là ngôn ngữ như nào, đơn giản

• internal/dev docs mặc định là tiếng Anh, có cấu trúc

• frontend patch phải read actual DOM hoặc template trước khi fix

Những thứ này rất hợp với tinh thần Context Engineering, bởi chúng giúp ổn định “bối cảnh làm việc” qua nhiều phiên, thay vì mỗi lần lại giải thích lại từ đầu.

Nói ngắn gọn:

Claude.md là nơi externalize những thứ mà nếu để model tự đoán, nó sẽ đoán sai hoặc không nhất quán.

Nếu Claude.md là luật nền, thì AGENTS.md gần hơn với một playbook.

Vai trò của nó là mô tả:

• workflow chuẩn

• checklist nhiều bước

• thứ tự các phase

• file nào phải update

• điều kiện nào mới được xem là done

Đây là bước chuyển rất quan trọng, bởi vì rất nhiều lỗi của agent không nằm ở phần “ý tưởng chính”, mà nằm ở phần “quy trình bị bỏ sót”.

Ví dụ rất điển hình:

• viết article xong nhưng quên update index.md

• compile wiki xong nhưng quên _brief.md

• phân tích xong nhưng chưa cross-reference nội dung liên quan

• sửa code xong nhưng chưa chạy test hoặc validation

Đây là loại lỗi khiến output trông có vẻ xong, nhưng thực tế chưa xong.

Và đó là lúc AGENTS.md phát huy giá trị. Nó trả lời câu hỏi:

Với loại công việc này, agent phải đi qua những bước nào, và những bước nào tuyệt đối không được bỏ?

Nếu Claude.md là lớp rule ổn định, thì AGENTS.md là lớp vận hành.

Đây là điểm mà cần lưu ý: không dừng ở chuyện “quản lý context cho một agent”, mà đi tiếp đến câu hỏi:

Nếu một agent phải làm việc dài hạn, nhiều bước, nhiều giờ, thì chỉ tối ưu context có đủ không?

Câu trả lời là không.

Bởi vì ngoài context rot, agent còn gặp hai failure mode kinh điển mà rất rõ:

• Premature completion — agent tự nghĩ là mình đã xong quá sớm.

• Scope explosion — agent cố làm quá nhiều thứ cùng lúc và mất kiểm soát.

Hai lỗi này không được giải quyết chỉ bằng prompt hay context tốt hơn. Chúng cần một lớp cao hơn:

một khung vận hành để agent biết khi nào bắt đầu, làm trong phạm vi nào, ai đánh giá, lưu trạng thái ở đâu, và tương tác với nhau ra sao.

Đó chính là Harness Engineering.

Nếu Context Engineering là “đưa đúng thông tin vào bộ não”, thì Harness Engineering là “thiết kế cả cơ thể và môi trường làm việc cho bộ não đó”.

Nói cách khác, harness là tất cả những thứ bao quanh model để giúp model làm việc được trong thực tế:

• lifecycle

• orchestration

• evaluator

• tool invocation

• checkpoint

• state storage

• retry logic

• testing loop

• artifact handoff

Đây là nơi chúng ta bắt đầu thấy những thứ như:

• Planner / Generator / Evaluator

• feature_list.json

• progress logs

• scripts

• sprint contract

• test harness

• file-based IPC

• hooks sau Write/Edit

• Playwright/Puppeteer để kiểm tra app thật

Những thứ này nghe có vẻ kỹ thuật, nhưng ý nghĩa của nó rất thực dụng:

Harness giúp agent bớt “nói có vẻ đúng”

và tiến gần hơn tới việc “làm đúng trong hệ thống thật”.

Trong phần Harness Engineering, có một pattern rất đáng chú ý:

Agent tự đánh giá chính mình gần như luôn thiên về lạc quan.

Đây là lý do vì sao một hệ thống chỉ có “generator” rất dễ thất bại. Model viết code xong, đọc lại, rồi tự tin rằng tính năng đã chạy. Nhưng thực tế thì UI vẫn lỗi, flow vẫn gãy, edge case vẫn chưa qua.

Vì vậy, một trong những harness pattern mạnh nhất là:

• Generator tạo ra output

• Evaluator đánh giá độc lập output đó

Một mô hình 3-agent gồm Planner, Generator, Evaluator, trong đó Evaluator có thể dùng Playwright để click qua app thật như người dùng thật. Điều này cực kỳ quan trọng, vì nó đưa việc đánh giá từ “ngôn ngữ” sang “thực nghiệm”.

Đây là một bước nhảy chất lượng rất lớn.

Không phải “code nhìn có vẻ đúng”

mà là “ứng dụng thật chạy đúng”

Nếu chỉ chọn một component có ROI cao nhất để thêm vào harness, báo cáo cũng gợi ý rất rõ: hãy thêm evaluator độc lập.

Đây có lẽ là phần cốt lõi nhất trong toàn bài viết này.

Không nên xem Context Engineering và Harness Engineering là hai lĩnh vực tách rời, mà là hai lớp đang giải cùng một bài toán ở hai cấp độ khác nhau.

• Context Engineering hỏi: đưa gì vào model?

• Harness Engineering hỏi: đặt model ở đâu trong hệ thống?

Có ba điểm giao nhau rất mạnh mà mình muốn chia sẻ

Nếu context không bị suy thoái khi kéo dài, về lý thuyết một agent duy nhất có thể đủ cho rất nhiều công việc. Nhưng vì context rot tồn tại, ta buộc phải:

• compact

• reset

• ghi notes

• tách agent

• cô lập context theo vai trò

Nghĩa là chính giới hạn của context đã tạo ra nhu cầu thiết kế harness.

Planner nhận full spec.

Coding agent chỉ nhận phần việc hiện tại.

Evaluator nhận tiêu chí đánh giá và quyền truy cập app chạy thật.

Tức là, ở cấp hệ thống, Harness Engineering cũng chính là Context Engineering ở quy mô lớn hơn.

Khi model mạnh hơn:

• prompt có thể bớt chi tiết hơn

• model tự tìm đúng tool tốt hơn

• context reset có thể ít cần hơn

• một số harness components có thể bị loại bỏ

Nhưng báo cáo cũng nhấn mạnh một insight rất hay:

Không gian harness thú vị không biến mất khi model tốt hơn — nó chỉ dịch chuyển lên tầng cao hơn.

Đây là một nhận định rất đúng. Model mạnh hơn không làm hệ thống biến mất; nó chỉ cho phép ta đẩy tự động hóa lên những bài toán phức tạp hơn.

Đến đây thì bức tranh đã rõ.

Trong giai đoạn đầu, mọi người thường làm việc với AI theo kiểu:

• có task thì viết prompt

• có bug thì prompt bug

• có report thì prompt report

• có issue thì prompt issue

Cách này không sai. Nhưng nó có giới hạn rất rõ:

• không nhất quán

• phụ thuộc vào trí nhớ của người prompt

• dễ bỏ sót bước

• khó scale cho team

• khó tái sử dụng

• càng phức tạp càng dễ trôi

Đó là lý do vì sao bài toán thực sự không còn là “viết prompt sao cho hay”, mà là:

làm sao biến những prompt rời rạc thành một workflow có thể lặp lại, tái dùng, và đáng tin hơn theo thời gian

Và đây chính là nơi các lớp bắt đầu ăn khớp với nhau:

Chứa rule nền, context ổn định, behavioral defaults.

Chứa playbook, process, checklist, định nghĩa done.

Chứa workflow tái sử dụng cho một loại việc cụ thể: Jira analysis, merchant support, TDD bugfix, wiki pipeline…

Chứa toolchain, hook, evaluator, scripts, validators, MCP, browser automation, test loops.

Chứa dữ liệu cụ thể của phiên hiện tại: ticket nào, URL nào, issue nào, output cho ai.

Khi năm lớp này được phân tách rõ, AI bắt đầu chuyển từ “một cái chat interface rất mạnh” thành “một thành phần làm việc trong hệ thống”.

Nếu phải rút ra các bài học hành động từ bài viết này, mình sẽ tóm gọn như sau.

Tối ưu một agent đơn thật tốt trước:

• rule rõ

• tool gọn

• context vừa đủ

• just-in-time retrieval

• note-taking có cấu trúc

Khi agent:

• hay quên

• tự đánh giá sai

• dừng sớm

• làm lan sang quá nhiều việc

thì mới là lúc cần tách vai trò, thêm evaluator, thêm checkpoint.

Nếu bạn chỉ thêm được một thứ, hãy thêm một evaluator độc lập. Đây là cách nhanh nhất để chống self-evaluation bias.

Thay vì bắt nhiều agent “cùng nhớ một thứ”, hãy để chúng giao tiếp qua artifact rõ ràng: JSON, progress logs, notes, reports.

Một system AI biết viết code chưa chắc là một system AI biết tạo ra thứ chạy được. Muốn vượt qua ranh giới đó, cần test thật, click thật, validate thật.

Điều thú vị nhất mà cá nhân mình cảm nhận hiện tại đó là thế giới AI đang cho thấy rất rõ một sự chuyển pha.

Ban đầu, AI được nhìn như một công cụ trả lời.

Sau đó, nó được nhìn như một công cụ biết làm việc.

Nhưng khi bước vào sản xuất thật, AI chỉ trở nên hữu ích bền vững nếu được đặt trong một hệ thống được thiết kế đúng.

Từ góc nhìn đó:

• Prompt Engineering giúp model bắt đầu

• Context Engineering giúp model hiểu đúng

• Harness Engineering giúp model làm việc được trong thực tế

• Workflow design giúp mọi thứ có thể scale

Và đó có lẽ là điểm quan trọng nhất.

Tương lai của việc làm việc với AI không phải là viết prompt ngày càng dài.

Tương lai là xây được những hệ thống trong đó AI có context đúng, có harness đúng, có evaluator đúng, và có workflow đủ rõ để lặp lại mà không sụp đổ.

Hay nói ngắn gọn hơn:

Prompt là điểm bắt đầu.

Context là điều kiện để suy luận đúng.

Harness là điều kiện để thực thi đáng tin.

Workflow là thứ biến tất cả những điều đó thành năng lực thật trong công việc hàng ngày.

Cảm ơn bạn đã đọc tới đây. Chúc bạn một ngày tốt lành!

Leave a comment