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ế
Production proof: ongboit.com ship 15+ Claude Code skills, 3000+ GitHub stars tổng. Số liệu về context engineering trong bài từ testing thực tế hàng ngày với Claude Code, không phỏng đoán.
Đăng: 26/04/2026 | Cập nhật: 26/04/2026
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. 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.
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.
—
Nguyễn Minh Thế là DevOps engineer, dùng Claude Code mỗi ngày để build và vận hành hệ thống ng- workflow cho ongboit.com. Bài viết phản ánh kinh nghiệm thực tế, không phải lý thuyết.*
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.
