Context Engineering Là Gì? Giải Thích Đơn Giản Cho Developer
Bạn đã từng spend cả buổi chiều chỉnh sửa prompt cho hoàn hảo, chạy AI agent, và nó vẫn fail ngay bước đầu tiên. Không nhớ task trước. Không biết dùng tool nào. Trả lời chung chung như thể chưa đọc gì cả. Đó không phải lỗi prompt của bạn. Đó là lỗi context.
Context engineering là kỹ thuật giải quyết đúng vấn đề đó. Không phải viết prompt hay hơn, mà là xây dựng hệ thống cung cấp đúng thông tin cho AI tại đúng thời điểm. Gartner gọi đây là “breakout AI capability of 2026”, không phải vì nó mới, mà vì chúng ta mới bắt đầu làm nó có hệ thống.
Bài này giải thích context engineering là gì, tại sao nó khác prompt engineering, và cách mình đang dùng nó mỗi ngày trong Claude Code.
TL;DR
- Context engineering là kỹ thuật thiết kế hệ thống cung cấp đúng thông tin cho AI agent, không chỉ viết prompt tốt hơn
- Một context đầy đủ gồm 7 thành phần: system prompt, user prompt, conversation history, long-term memory, RAG, available tools, và structured output format
- 4 pillars xây dựng hệ thống: dynamic info flow, tool integration, memory architecture, format optimization
- Prompt engineering = bạn nói gì. Context engineering = hệ thống biết gì trước khi bạn nói
- Trong Claude Code: CLAUDE.md + memory/ folder + skills/ folder = context engineering đang chạy thực tế
Context Engineering Là Gì?
Context engineering là kỹ thuật thiết kế và xây dựng các hệ thống động cung cấp đúng thông tin, đúng công cụ, đúng định dạng, vào đúng thời điểm cho một LLM. Định nghĩa này đến từ Philipp Schmid, kỹ sư tại Google DeepMind, người viết bài gốc về chủ đề này vào giữa 2025.
Andrej Karpathy mô tả context engineering là “nghệ thuật và khoa học thiết kế cửa sổ ngữ cảnh” (context window). Nó là khoa học vì có nguyên tắc rõ ràng, đo lường được. Nó là nghệ thuật vì không có công thức đúng cho mọi trường hợp.
Tobi Lütke, CEO của Shopify, là người phổ biến khái niệm này vào mid-2025 khi tuyên bố AI competency trở thành tiêu chí bắt buộc trong đánh giá nhân viên tại Shopify. Ông mô tả context engineering là kỹ năng core của người làm việc với AI agent.
Cách đơn giản nhất để hiểu: nếu prompt engineering là việc bạn viết gì cho AI, thì context engineering là việc hệ thống chuẩn bị gì cho AI trước khi bạn viết bất cứ điều gì.
Tại Sao Prompt Engineering Không Còn Đủ Nữa?
Prompt engineering hoạt động tốt với task ngắn, đơn giản. Nhưng khi bạn build AI agent cho task phức tạp và dài hạn, nó bắt đầu fail theo một cách rất cụ thể: context rot.
Context rot là hiện tượng AI giảm hiệu suất khi lượng token trong context window tăng lên. Nguyên nhân nằm trong kiến trúc transformer: với n tokens, mô hình phải tính n² mối quan hệ pairwise. Khi n tăng, “attention budget” bị chia nhỏ, mô hình mất khả năng nhớ chính xác thông tin ở xa. Đây là lý do tại sao agent thường fail sau nhiều bước, dù từng bước đơn lẻ nó làm tốt.
Anthropic mô tả vấn đề này trong guide chính thức về context engineering cho AI agents: cùng một model, cùng một task, nhưng kết quả chênh lệch lớn phụ thuộc vào context quality, không phải prompt quality.
Con số cụ thể để hình dung mức độ nghiêm trọng: nghiên cứu Stanford “Lost in the Middle” (2023) cho thấy LLM mất 25-39% độ chính xác khi thông tin liên quan nằm ở giữa context dài thay vì đầu hoặc cuối. Ở ngưỡng 100K+ tokens, các mô hình như GPT-4 và Claude giảm 32% accuracy trên multi-step reasoning task so với context ngắn. Thậm chí o3, model mạnh nhất của OpenAI, giảm từ 98.1% xuống 64.1% trên FRAMES benchmark (long-context retrieval) so với short-context tasks.
Phân biệt rõ hai failure mode:
- Cheap demo: AI trả lời đúng câu hỏi đơn lẻ, prompt tốt
- Magical agent: AI hoàn thành task phức tạp qua nhiều bước, nhớ context, dùng đúng tool đúng lúc
Để đi từ demo sang production agent, bạn cần context engineering, không chỉ prompt engineering.
AI Agent Cần Những Gì Để Hoạt Động Đúng?
Một AI agent hoạt động đúng cần đủ 7 Thành Phần Context, theo framework của Philipp Schmid từ Google DeepMind:
| # | Thành phần | Là gì | Ví dụ thực tế |
|---|---|---|---|
| 1 | System Prompt | Hướng dẫn cố định, luôn có mặt | CLAUDE.md trong Claude Code |
| 2 | User Prompt | Câu hỏi / lệnh của người dùng | “/ng-write context engineering” |
| 3 | State/History | Lịch sử cuộc trò chuyện hiện tại | Các turn trước trong session |
| 4 | Long-term Memory | Thông tin lưu trữ giữa các session | memory/ folder trong Claude Code |
| 5 | Retrieved Information | Dữ liệu lấy từ nguồn ngoài (RAG) | Search kết quả, database query |
| 6 | Available Tools | Danh sách tool AI có thể gọi | skills/ files, MCP servers |
| 7 | Structured Output | Format mong muốn của output | JSON schema, markdown template |
Phần lớn developer chỉ quan tâm thành phần 1 và 2, tức system prompt và user prompt. Context engineering là việc cố tình thiết kế tất cả 7 thành phần còn lại, đặc biệt là thành phần 4, 5, và 6 thường bị bỏ qua nhất.
MCP (Model Context Protocol) là context engineering cho thành phần 6 (Available Tools) theo chuẩn hóa. Thay vì mỗi agent tự định nghĩa tool schema theo cách riêng, MCP cung cấp giao thức thống nhất để AI agent discover và sử dụng external tools. Kết quả: thay vì hardcode tool list vào system prompt, agent có thể dynamically load tools qua MCP server, đây là “just-in-time tooling” tương tự just-in-time context mà Karpathy mô tả.
Điểm quan trọng: không phải lúc nào cũng cần đủ cả 7. Task đơn giản chỉ cần 1-2. Task phức tạp cần 5-7. Context engineering là kỹ thuật quyết định lúc nào cần gì, thay vì nhồi tất cả vào một lúc (vì điều đó tạo ra context rot).
4 Pillars Nào Tạo Nên Hệ Thống Context Engineering Tốt?
Từ 7 thành phần trên, 4 Pillars Context Engineering là 4 trụ cột giúp bạn thiết kế hệ thống có khả năng mở rộng:
1. Dynamic Information Flow
Không load tất cả thông tin ngay từ đầu. Load đúng thứ đúng lúc. Ví dụ: khi agent cần viết bài về SEO, chỉ load context liên quan đến SEO, không phải toàn bộ knowledge base. Karpathy gọi đây là “just-in-time context”.
2. Tool Integration and Orchestration
Xác định rõ tool nào available, khi nào dùng tool nào. Vibrant toolset không giúp ích gì nếu agent không biết chọn đúng tool. Đây là lý do bloated tool sets là failure mode phổ biến nhất trong AI agent production.
3. Memory Architecture
Kết hợp nhiều loại memory: short-term (conversation history), long-term (stored preferences + past decisions), semantic (RAG từ knowledge base). Mỗi loại phục vụ mục đích khác nhau và không thể thay thế nhau.
4. Format Optimization
Cấu trúc thông tin theo cách AI có thể xử lý hiệu quả. Thông tin cùng nội dung nhưng định dạng khác nhau cho kết quả khác nhau rõ rệt. JSON structured > free-text paragraph cho task phân tích. Numbered list > prose cho task step-by-step.
Bốn pillars này cũng giải thích tại sao 95% industry leaders coi context engineering là yếu tố quan trọng nhất để scale AI agents, theo DataHub State of Context Management Report 2026. Framework này được Philipp Schmid (Google DeepMind) tổng hợp và formalize từ các pattern quan sát trong production AI agent deployments.
Context Engineering Khác Prompt Engineering Ở Điểm Nào?
Nhiều người nhầm lẫn hai khái niệm này. Ranh giới rõ nhất:
| Tiêu chí | Prompt Engineering | Context Engineering |
|---|---|---|
| Làm gì | Tối ưu hóa text input cho AI | Thiết kế hệ thống cung cấp thông tin cho AI |
| Ai làm | User/marketer | Developer/architect |
| Scale | Một lần, per task | Hệ thống, tái sử dụng |
| Khi nào fail | Task phức tạp, nhiều bước | Khi thiếu nguồn lực (API, data) |
| Output | Tốt hơn cho task đơn | Agent đáng tin cậy ở production |
| Công cụ | System prompt, few-shot examples | RAG, memory systems, tool orchestration |
Prompt engineering là subset của context engineering. kỹ thuật few-shot prompting giải thích đầy đủ. Viết system prompt tốt là prompt engineering. Quyết định thông tin gì nên vào system prompt, thông tin gì nên load qua RAG, thông tin gì nên lưu vào long-term memory là context engineering.
Khi nào dùng cái nào? Nếu task đơn giản và không cần nhớ gì giữa các lần chạy, prompt engineering là đủ. Khi bạn build agent phải hoàn thành task phức tạp qua nhiều bước, cần nhớ trạng thái, cần truy cập nhiều nguồn dữ liệu thì cần cả hệ thống context engineering đằng sau.
Đây cũng là lý do tại sao Claude Code hoạt động tốt hơn khi bạn có context window được thiết kế tốt thay vì chỉ dùng prompt đơn thuần.
Mình Đã Dùng Context Engineering Trong Claude Code Như Thế Nào?
Sau nhiều tháng dùng Claude Code để viết blog cho ongboit.com, mình nhận ra mình đang làm context engineering mà không biết tên của nó.
Hệ thống ng-* workflow mình build có đủ 5/7 thành phần context:
CLAUDE.md = System Prompt Layer. File này bảo Claude “dùng tiếng Việt casual, brand color #FF7F00, không dùng em dash, bài viết cần >15% diacritics”. Đây là context engineering thành phần 1, và nó tiết kiệm cho mình 3-5 phút setup mỗi session vì không cần nhắc lại các rule này.
memory/ = Long-term Memory Layer. Mỗi khi mình học được gì mới về cách viết, cách tối ưu, hay preference cụ thể, mình save vào file trong memory/. Session sau Claude Code đọc lại và nhớ. Đây là thành phần 4, và nó giải quyết vấn đề “tại sao Claude không nhớ mình thích gì từ tuần trước”.
skills/ = Available Tools Layer. Mỗi file skill (ng-write, ng-audit, ng-image…) là một tool available. Thay vì giải thích từ đầu “hãy viết bài theo cách này”, mình chỉ cần /ng-write [keyword] và Claude biết chính xác phải làm gì. Đây là thành phần 6.
ng-research output = Retrieved Information. Kết quả từ DataForSEO, competitor analysis, PAA questions là RAG layer, thành phần 5. Claude không cần “biết” keyword data, nó chỉ cần có data đúng lúc cần.
Cái mình chưa có là thành phần 3 (conversation history automation) và thành phần 7 (structured output format enforcement). Đó là 2 thứ mình đang plan thêm vào.
Insight quan trọng hơn: context engineering không phải kỹ năng hoàn toàn mới. Developer giỏi đã làm nó từ lâu dưới tên khác, CLAUDE.md, .cursorrules, system prompts trong production. Cái thay đổi bây giờ là chúng ta làm nó có hệ thống, đặt tên cho từng thành phần, và đo lường được hiệu quả. Agent framework adoption tăng từ 9% lên 18% trong một năm (Datadog 2026) chính xác là vì developer đang formalize việc này.
Nếu bạn đang dùng AI agent cho bất kỳ workflow nào, có một câu hỏi đơn giản để check mình đang làm context engineering hay chưa: “Agent của mình có biết mình là ai, đang làm gì, và cần tool gì ngay từ khi bắt đầu session không?” Nếu không, bạn đang bỏ qua ít nhất 3 trong 7 thành phần context.
Context Engineering Liên Kết Với Phần Còn Lại Của Hệ Sinh Thái LLM Như Thế Nào?
Phần này giúp người đọc hiểu rõ vị trí của Context Engineering trong toàn bộ hệ sinh thái LLM năm 2026. Hiểu được mối liên kết giữa các khái niệm giúp lập trình viên thiết kế hệ thống AI agent hiệu quả ngay từ đầu, tránh việc phải tái cấu trúc về sau khi đã đầu tư công sức vào pattern không phù hợp với mô hình thực tế.
Trước khi đi sâu vào Context Engineering, người mới cần nắm vững khái niệm nền tảng về LLM. Mọi kỹ thuật Context Engineering đều xoay quanh cách LLM xử lý input để đưa ra response. Không hiểu cơ chế dự đoán token và xử lý context của model thì khó áp dụng đúng Context Engineering cho dự án production thực tế. Đầu tư 2-3 ngày đọc kỹ tài liệu nền tảng giúp người mới có cơ sở vững chắc để xây dựng hệ thống AI agent chất lượng cao cho khách hàng.
Khía cạnh kỹ thuật quan trọng nhất của Context Engineering là token mà model xử lý. Mỗi token gửi vào context đều tính phí, vì vậy Context Engineering hiệu quả về bản chất là quản lý token hiệu quả. Pattern khôn ngoan là chỉ đưa thông tin thực sự cần thiết vào context, loại bỏ các phần dư thừa qua kỹ thuật summary hoặc trích xuất chỉ phần quan trọng. Đối với pipeline automation quy mô lớn, mỗi token tiết kiệm được nhân với số lượng request hằng ngày có thể trở thành khoản tiết kiệm chi phí đáng kể cho doanh nghiệp.
Để định nghĩa static context áp dụng cho mọi cuộc trò chuyện, lập trình viên cần hiểu rõ vai trò của System Prompt. System Prompt là lớp context đầu tiên mà model đọc khi bắt đầu session, định nghĩa vai trò, quy tắc hành xử, và context chung của AI agent. Pattern khôn ngoan là đặt các thông tin ổn định trong System Prompt và tận dụng cơ chế Prompt Caching để giảm chi phí cho phần static context được lặp lại nhiều lần.
Đối với pipeline automation cần truy cập nhiều nguồn dữ liệu bên ngoài làm dynamic context, kết hợp với MCP (Model Context Protocol) là điều bắt buộc. MCP cho phép AI agent tự động lấy context từ cơ sở dữ liệu nội bộ, API của bên thứ ba, hoặc các dịch vụ cloud chuyên dụng. Kỹ thuật reasoning như Chain-of-Thought kết hợp với dynamic context phong phú tạo ra hệ thống AI agent cấp doanh nghiệp có khả năng xử lý các tác vụ phức tạp mà các pattern đơn giản hơn không làm được. Tham khảo bài tổng hợp Prompt Engineering chi tiết để có bức tranh đầy đủ về cách kết hợp các kỹ thuật này trong thực tế.
Bài Học Quản Lý Ngữ Cảnh Hiệu Quả Cho Đội Nhóm Việt Nam Năm 2026
Phần này tổng hợp 3 bài học quan trọng nhất rút ra từ 3 tháng triển khai Context Engineering cho nhiều dự án thực tế tại ongboit.com và một số khách hàng doanh nghiệp tại Việt Nam. Đây là kinh nghiệm thực chiến đáng được chia sẻ cho người mới bắt đầu áp dụng kỹ thuật này vào sản phẩm của mình.
Bài học đầu tiên là về tầm quan trọng của việc cấu trúc ngữ cảnh theo lớp ưu tiên. Nhiều đội nhóm mới triển khai có xu hướng đưa tất cả thông tin có thể tìm thấy vào ngữ cảnh với hy vọng trợ lý sẽ có đầy đủ thông tin cần thiết. Thực tế ngược lại hoàn toàn, ngữ cảnh quá dài làm trợ lý mất tập trung vào các thông tin quan trọng nhất. Pattern khôn ngoan là cấu trúc ngữ cảnh theo ba lớp ưu tiên rõ ràng. Lớp một chứa thông tin bắt buộc trợ lý phải có để hoàn thành tác vụ, lớp hai chứa thông tin hữu ích nhưng không bắt buộc, lớp ba chứa thông tin tham khảo có thể lấy khi cần qua công cụ tìm kiếm. Cách phân lớp này giúp trợ lý tập trung vào thông tin quan trọng nhất và đưa ra phản hồi chất lượng cao hơn nhiều.
Bài học thứ hai là về việc đo lường hiệu quả của context qua các chỉ số cụ thể. Nhiều đội nhóm chỉ đánh giá chất lượng response theo cảm tính, không có cách đo lường khách quan để biết đang cải thiện hay đang đi xuống. Pattern khôn ngoan là thiết lập bộ chỉ số đo lường gồm tỉ lệ AI agent đưa ra response chính xác, thời gian response trung bình, chi phí token cho mỗi tác vụ, mức độ hài lòng của end user. Theo dõi các chỉ số này hằng tuần giúp đội ngũ phát hiện sớm khi context cần được tinh chỉnh, không phải chờ đến khi có phàn nàn từ khách hàng mới bắt đầu xử lý.
Bài học cuối cùng là về việc document Context Engineering cụ thể của dự án để chia sẻ trong đội ngũ. Mỗi dự án có đặc thù riêng về loại context cần cung cấp, cách cấu trúc, và các pattern hiệu quả nhất. Nếu không document, kiến thức này chỉ tồn tại trong đầu của một vài thành viên, khi họ rời đội thì đội ngũ phải học lại từ đầu. Pattern khôn ngoan là viết tài liệu hướng dẫn Context Engineering cho dự án ngay từ những ngày đầu, cập nhật định kỳ khi có pattern mới được phát hiện. Đầu tư 1-2 ngày viết tài liệu ban đầu tiết kiệm hàng tuần đào tạo lại đội ngũ về sau, đặc biệt quan trọng cho doanh nghiệp đang trong giai đoạn mở rộng quy mô đội ngũ phát triển sản phẩm.
Context Engineering 2026: Anthropic Chính Thức Hóa + MCP Làm Context Layer
Từ giữa 2026, Context Engineering không còn là khái niệm ngầm hiểu nữa. Anthropic đã ra một hướng dẫn chính thức, định nghĩa nó là tập các chiến lược để tuyển chọn và duy trì đúng tập token (thông tin) mà model cần trong lúc inference (Anthropic, Effective context engineering for AI agents). Nói cách khác: cái mình mô tả ở các phần trên giờ đã có định nghĩa first-party từ chính nhà làm model.
Thay đổi lớn thứ hai là MCP (Model Context Protocol) đang thành lớp giao context thực tế cho coding agent. Thay vì nhồi mọi thứ vào prompt, agent kéo đúng context liên quan qua MCP server, đúng tinh thần 4 pillars ở trên (InfoWorld, The role of MCP in context engineering). Nếu bạn dùng Claude Code, đây là lý do mấy MCP server biết đúng thứ cần biết mà không cần bạn dán cả tài liệu vào.
Pillar đáng để ý nhất năm nay là memory: thay vì agent reset sạch mỗi session, xu hướng 2026 là persistent/cross-agent memory để kiến thức tích lũy qua nhiều phiên. Với team, đây là khác biệt giữa hỏi lại từ số 0 và agent nhớ context dự án.
- Định nghĩa đã chuẩn hóa (Anthropic): trích dẫn được thay vì tự giải thích mơ hồ.
- MCP = context layer: đừng nhồi prompt, để agent kéo context qua tool.
- Memory đang lên: pillar tiến hóa nhanh nhất 2026.
Câu Hỏi Thường Gặp
Context engineering là gì?
Context engineering là kỹ thuật thiết kế hệ thống cung cấp đúng thông tin cho AI agent. Thay vì chỉ viết prompt tốt, context engineering xây dựng toàn bộ pipeline: từ system prompt, long-term memory, RAG, đến danh sách tool available. Khái niệm này được formalize vào mid-2025 bởi Philipp Schmid (Google DeepMind) và phổ biến rộng bởi Tobi Lütke (Shopify CEO).
Context engineering khác prompt engineering như thế nào?
Prompt engineering tối ưu hóa text input bạn viết cho AI, thường là việc user hoặc marketer làm. Context engineering thiết kế hệ thống cung cấp thông tin cho AI trước khi bạn viết gì, là việc developer và architect làm. Prompt engineering là subset của context engineering: viết system prompt tốt là prompt engineering, quyết định gì nên vào system prompt là context engineering.
4 pillars của context engineering là gì?
Bốn pillars là: (1) Dynamic Information Flow, tức load đúng thông tin đúng lúc; (2) Tool Integration and Orchestration, tức orchestrate tool usage có hệ thống; (3) Memory Architecture, tức kết hợp short-term, long-term và semantic memory; (4) Format Optimization, tức cấu trúc thông tin để AI xử lý hiệu quả. Bốn pillars này đến từ framework của Philipp Schmid (Google DeepMind), người formalize khái niệm context engineering vào mid-2025.
Khi nào nên dùng context engineering thay vì chỉ viết prompt?
Khi task cần nhiều hơn một câu trả lời đơn lẻ: agent phải hoàn thành nhiều bước, nhớ trạng thái giữa các lần chạy, truy cập nhiều nguồn data khác nhau, hoặc phối hợp với nhiều tool. Nếu AI agent của bạn fail sau 3-5 bước dù từng bước riêng lẻ nó làm tốt, đó là dấu hiệu bạn cần context engineering, không phải prompt tốt hơn.
Context engineering có liên quan đến RAG không?
RAG (Retrieval-Augmented Generation) là một trong 7 thành phần của context engineering, cụ thể là thành phần “Retrieved Information”. Context engineering là khái niệm rộng hơn, bao gồm cả RAG cùng với memory systems, tool orchestration, và format optimization. Bạn có thể có context engineering tốt mà không cần RAG nếu task không cần truy cập external knowledge.
Làm sao bắt đầu với context engineering trong Claude Code?
Bắt đầu với 3 thành phần dễ nhất: (1) Viết CLAUDE.md tốt = system prompt layer. (2) Tạo memory/ folder để lưu preferences giữa các session = long-term memory layer. (3) Tạo skills/ files cho các task lặp lại = available tools layer. Đây là 3/7 thành phần và đã đủ để thấy cải thiện rõ rệt. Đọc thêm về memory trong Claude Code để bắt đầu.
Kết Luận
Context engineering giải quyết vấn đề mà prompt engineering không thể: tại sao AI agent fail khi task trở nên phức tạp. Bằng cách xây dựng hệ thống với đủ 7 Thành Phần Context và tuân theo 4 Pillars Context Engineering, bạn đi từ “demo hoạt động” sang “production agent đáng tin cậy”.
Điểm thực tế nhất để bắt đầu: nhìn vào workflow AI của bạn và tự hỏi agent đang thiếu thành phần context nào trong số 7. Thường câu trả lời là long-term memory (thành phần 4) và structured output format (thành phần 7). Fix hai thứ đó trước.
Trong Claude Code, bước đầu tiên đơn giản nhất là viết CLAUDE.md nghiêm túc. Đó là system prompt layer, và nó một mình đã giải quyết phần lớn vấn đề “tại sao Claude không hiểu mình muốn gì”. Tìm hiểu thêm về prompt caching để tối ưu cost khi context window của bạn lớn hơn.
Kiến thức nền này sẽ giúp bạn học Claude Code hiệu quả hơn. Xem lộ trình 8 levels để biết bước tiếp theo.
