Lần đầu mình dùng một AI agent để lên lịch họp, trải nghiệm khá… gây thất vọng. Mình chỉ gửi đúng một dòng:
“Hey, mai có rảnh họp nhanh không?”
Nó phản hồi ngay, đúng kiểu mẫu demo:
“Cảm ơn, bạn muốn chọn giờ nào?”
Kỹ thuật thì ổn — gọi LLM, sinh phản hồi. Nhưng vô dụng. Mình có lúc bận kín lịch, người gửi là đối tác thân, và mình cần một phản hồi mềm mại, nhanh gọn.
Chỉ đến khi mình tự đưa vào lịch làm việc, lịch sử email, kiểu giọng nói phù hợp… câu trả lời mới “ra dáng” một trợ lý thực thụ:
“Mai kín lịch cả ngày rồi, sáng thứ Năm rảnh. Mình gửi invite nhé?”
Câu chuyện đó làm mình nhận ra một điều: vấn đề không phải mô hình AI yếu, mà là nó bị thiếu bối cảnh. Và kỹ năng quan trọng nhất không còn là viết prompt, mà là context engineering – khả năng cung cấp đúng dữ liệu, đúng công cụ, đúng định dạng, đúng thời điểm.
Một người bạn trong ngành tài chính kể với mình một trải nghiệm tương tự. Công ty của anh triển khai một AI Agent để hỗ trợ chăm sóc khách hàng. Phiên bản đầu chỉ “hỏi gì trả lời nấy” – không phân biệt người đang hỏi là khách VIP hay người mới, không biết lịch sử khiếu nại, không nhớ ai vừa mua sản phẩm gì. Kết quả? Khách thì khó chịu, đội chăm sóc vẫn phải can thiệp thủ công.
Chỉ khi nhóm kỹ thuật bắt đầu bổ sung các lớp context — lịch sử giao dịch, tông giọng phù hợp theo phân khúc khách hàng, hướng dẫn nội bộ xử lý đặc biệt — thì AI mới thực sự “làm việc như một người”. Và tỷ lệ khách hài lòng tăng lên đáng kể.
Hai ví dụ đó có chung một kết luận: Agent không thất bại vì không “thông minh” – mà vì nó không được cho đủ ngữ cảnh để hành động như một con người. Và đó là nơi Context Engineering trở thành kỹ năng cốt lõi trong kỷ nguyên AI.
Context không chỉ là prompt
Chúng ta vẫn quen nghĩ “context” chỉ là câu hỏi hoặc chỉ dẫn mà bạn gõ vào ô chat. Thực ra, context là toàn bộ những gì mô hình nhìn thấy trước khi nó phản hồi, bao gồm:
- System Prompt/Instructions: Bộ chỉ dẫn nền tảng để định nghĩa hành vi, có thể kèm ví dụ, quy tắc.
- User Prompt: Câu hỏi hay yêu cầu cụ thể từ người dùng.
- State/History: Lịch sử hội thoại, gồm cả các câu trả lời trước đó.
- Long-term Memory: Thông tin lưu trữ lâu dài: sở thích, dự án, sự kiện cũ.
- Retrieved Information (RAG): Kiến thức ngoài, cập nhật từ tài liệu, API.
- Available Tools: Các công cụ mà agent có thể gọi, như gửi email, đặt lịch.
- Structured Output: Định dạng đầu ra rõ ràng, ví dụ JSON.
Thử hình dung một tình huống đơn giản: nhận email “Có rảnh mai họp nhanh không?”.
Một agent kém context chỉ thấy câu hỏi và đáp máy móc: “Cảm ơn. Mai được. Bạn muốn giờ nào?”.
Còn một agent tốt context sẽ nhìn vào lịch của bạn (đang kín mít), lịch sử email (biết đây là đối tác quan trọng), và tông giọng bạn hay dùng (thân mật), rồi đáp:
“Mai mình kín lịch, sáng thứ Năm được. Đã gửi lời mời, cậu xem nhé!”
Vì sao Context Engineering quan trọng?
Trước đây, khi công nghệ mô hình ngôn ngữ (LLM) còn hạn chế, thất bại của các agent thường bắt nguồn từ chính mô hình: hiểu sai ý, phản hồi lạc chủ đề, câu cú ngô nghê. Nhưng ngày nay, với những LLM mạnh mẽ và tinh vi hơn, nguyên nhân của sự thất bại đã thay đổi — phần lớn không còn do mô hình, mà do thiếu bối cảnh đúng.
Hãy hình dung một chatbot bán hàng được huấn luyện bài bản. Khi khách hàng nhắn:
“Tôi muốn trả hàng, phải làm sao?”
Nếu bot chỉ nhìn thấy đúng câu hỏi này, nó có thể trả lời rất máy móc:
“Anh/chị vui lòng làm theo hướng dẫn trả hàng tại website.”
Nghe thì hợp lý, nhưng lại vô hồn. Vì thực tế, nếu bot được cung cấp thêm bối cảnh — như lịch sử giao dịch của khách (mua sản phẩm gì, từ khi nào), các chính sách cụ thể của công ty áp dụng cho sản phẩm đó, và phân loại khách (VIP hay thông thường) — thì câu trả lời sẽ trở nên tự nhiên và chính xác hơn nhiều:
“Anh Hùng, đơn hàng #1234 đặt ngày 12/6 với sản phẩm giày thể thao vẫn nằm trong thời gian đổi trả 30 ngày. Mình sẽ gửi link trả hàng kèm hướng dẫn chi tiết ngay nhé!”
Một hệ thống như vậy không chỉ thỏa mãn khách hàng mà còn giảm tải cho nhân viên hỗ trợ.
Nhiều công ty khi trình diễn AI agent hay chatbot trong các hội thảo, demo rẻ tiền vẫn chạy được: chỉ cần gửi câu hỏi, nhận lại câu trả lời. Nhưng để tạo ra trải nghiệm thật sự “ma thuật”, khiến người dùng quên rằng họ đang nói chuyện với một cỗ máy, thì cần nhiều hơn thế — cần một hệ thống context engineering: thu thập, sắp xếp và cung cấp đúng dữ liệu, công cụ, và định dạng, giúp mô hình hiểu sâu và phản hồi chính xác, tinh tế.
Đó chính là lý do ngày càng nhiều chuyên gia chuyển từ tập trung vào viết prompt sang đầu tư vào thiết kế context — yếu tố quyết định một agent thất bại hay tỏa sáng.
Context Engineering là gì?
Tobi Lutke định nghĩa rất hay: “nghệ thuật cung cấp đủ bối cảnh để nhiệm vụ có thể được giải quyết một cách hợp lý bởi LLM.”
Ở đây, nó không chỉ là nghệ thuật, mà còn là một hệ thống kỹ thuật được triển khai rõ ràng. Ví dụ: trong một hệ thống chăm sóc khách hàng, context engineering có thể là một pipeline tự động thu thập lịch sử mua hàng, ghi chú nhân viên, và tone of voice phù hợp, sau đó định dạng thành tóm tắt súc tích để gửi cho LLM trả lời. Điều này giúp phản hồi vừa chính xác vừa tự nhiên, không dư, không thiếu.
- Một hệ thống, không phải một chuỗi: Context là sản phẩm của một hệ thống động, tự động chuẩn bị dữ liệu, không chỉ là một đoạn text mẫu.
- Động, không tĩnh: Context được tạo mới theo từng tình huống. Ví dụ: với một yêu cầu hỗ trợ, hệ thống truy xuất hồ sơ khách; với yêu cầu lên lịch, hệ thống truy xuất lịch cá nhân.
- Đúng thông tin, đúng thời điểm: Cung cấp cả kiến thức (knowledge) và công cụ (tools) phù hợp đúng lúc. Ví dụ: khi khách hỏi chính sách hoàn trả, chỉ đưa chính sách liên quan, không dump cả tài liệu nội quy.
- Định dạng quan trọng: Tóm tắt rõ ràng và có cấu trúc (schema JSON hoặc bảng) giúp LLM xử lý dễ dàng hơn là đổ dữ liệu raw khó đọc.
Từ prompt đến context engineering
Nếu prompt engineering là viết một chỉ dẫn hay, thì context engineering là thiết kế cả hệ thống để đảm bảo mô hình có tất cả những gì cần thiết để hoàn thành nhiệm vụ.
“Nghệ thuật thiết kế hệ thống động để cung cấp thông tin & công cụ phù hợp, đúng định dạng, đúng thời điểm, để LLM có thể hoàn thành nhiệm vụ.”
Và đây chính là lý do mà nhiều agent thất bại — không phải vì model yếu, mà vì context nghèo nàn.
Gợi mở
Khi AI mạnh lên, câu hỏi không còn là: “Prompt này hay chưa?” mà là: “Bạn đã dựng đúng bối cảnh chưa?”. Bạn đã chuẩn bị lịch, email, công cụ, định dạng, và cả tông giọng phù hợp chưa? Ví dụ thực tế: Một công ty triển khai AI để trả lời ticket hỗ trợ khách hàng, ban đầu chỉ gửi câu hỏi của khách hàng đến LLM và nhận được phản hồi chung chung, đôi khi sai. Sau khi bổ sung context đầy đủ — hồ sơ khách, lịch sử mua, tone hỗ trợ — agent trả lời chính xác, tự nhiên và tiết kiệm 30% thời gian xử lý. Bạn đã chấp nhận rằng thất bại của agent thường đến từ bối cảnh, không phải mô hình?
Một hành động nhỏ, thử ngay hôm nay
Lần tới khi bạn xây một AI agent, thử liệt kê tất cả các nguồn dữ liệu, công cụ, và định dạng mà agent cần trước khi gọi LLM. Tạo một tác vụ cụ thể (ví dụ: trả lời email), chạy một lần với context tối thiểu và một lần với context đầy đủ — và so sánh kết quả.
Ở góc độ cá nhân, mình cũng từng thất bại vì đánh giá thấp phần “nghệ thuật” này. Những lần đầu, mình quá chăm chăm chỉnh prompt, mà quên mất phải “nuôi” cho agent đủ bối cảnh. Cũng phải ngượng vài lần với những câu trả lời ngớ ngẩn trước khi nhận ra điều này.
Vậy nên, câu hỏi mình vẫn tự nhắc mỗi lần xây agent: “Liệu mình đã kể đủ câu chuyện cho nó chưa?”.