# Context engineering là gì? Bốn chiến lược quản lý cửa sổ ngữ cảnh

> Hướng dẫn context engineering cho hệ thống AI agent: quản lý cửa sổ ngữ cảnh hữu hạn và tránh mất thông tin ở giữa ngữ cảnh ('lost in the middle').

Nguồn: https://camnangai.com/ung-dung-ai/lap-trinh-vien/context-engineering  
Xuất bản: 2026-06-03

**Context engineering** là nghệ thuật và khoa học thiết kế, quản lý hệ thống thông tin bao quanh
  mô hình ngôn ngữ lớn (LLM) để tối ưu kết quả.



  Coi LLM là CPU, còn cửa sổ ngữ cảnh là RAM — đó là tư duy nền tảng của một hệ thống agent.

Thay vì chỉ viết prompt, bạn đang thiết kế toàn bộ hệ sinh thái dữ liệu nạp vào RAM cho mỗi bước xử
lý. Nghiên cứu của Chroma (2025) trên 18 mô hình cho thấy hiệu suất giảm mạnh từ 95% xuống 60% khi
vượt ngưỡng context nhất định — nạp thêm dữ liệu có thể khiến AI kém thông minh đi.

![Sơ đồ ẩn dụ context engineering: LLM là CPU và cửa sổ ngữ cảnh là RAM, với context engineering điều phối luồng dữ liệu nạp vào cho mỗi bước xử lý](https://camnangai.com/articles/context-engineering/01-infographic-vn.webp)

## Context engineering là gì, và khác prompt engineering ra sao?

Context engineering là bước tiến hóa tất yếu khi bạn chuyển từ chatbot đơn giản sang các agent tự vận
hành. Prompt engineering lo việc "hỏi thế nào", còn **context engineering** giải bài toán hệ thống: mô
hình cần biết thông tin gì, ở định dạng nào và tại thời điểm nào để hành động chính xác. Mỗi token rác
bạn nạp vào là một "khoản nợ" trừ thẳng vào khả năng suy luận của mô hình.

| Tiêu chí           | Prompt Engineering                      | Context Engineering                            |
| ------------------ | --------------------------------------- | ---------------------------------------------- |
| Câu hỏi cốt lõi    | Tôi nên diễn đạt câu lệnh này thế nào?  | Mô hình cần biết gì để hoàn thành tác vụ?      |
| Phạm vi thiết kế   | Một câu lệnh đơn lẻ (instruction layer) | Toàn bộ thông tin xung quanh (infrastructure)  |
| Trạng thái (state) | Thường bắt đầu mới (stateless)          | Xây dựng và tích lũy trạng thái theo thời gian |
| Khả năng mở rộng   | Phụ thuộc cách hành văn, khó mở rộng    | Thiết kế theo hệ thống, dễ mở rộng và tự động  |

Nói gọn lại, prompt engineering chỉ là một tập con bên trong context engineering, lo riêng lớp chỉ thị
đầu vào.

## Context của một LLM gồm những thành phần nào?

Một cửa sổ ngữ cảnh hiện đại là cấu trúc phức hợp gồm bảy thành phần chính tranh nhau không gian:

- **System instructions:** luật chơi, persona và hướng dẫn kiểm soát luồng.
- **User input:** truy vấn trực tiếp từ người dùng.
- **Conversation history:** bộ nhớ ngắn hạn của phiên làm việc.
- **Retrieved knowledge:** dữ liệu lấy về từ RAG (tài liệu, API, cơ sở dữ liệu).
- **Tool descriptions:** định nghĩa schema của các công cụ mà agent được phép gọi.
- **Tool outputs:** kết quả trả về từ các công cụ đã thực thi.
- **Agent state:** kế hoạch, to-do list và ghi chú tạm thời.

![Sơ đồ cửa sổ ngữ cảnh hữu hạn chia thành bảy thành phần: chỉ dẫn hệ thống, đầu vào người dùng, lịch sử hội thoại, kiến thức truy xuất, mô tả công cụ, kết quả công cụ và trạng thái agent](https://camnangai.com/articles/context-engineering/02-vn.webp)

Mọi thành phần này đều tiêu tốn "attention budget" (ngân sách chú ý). Vì mô hình có tài nguyên chú ý hữu
hạn, nhồi quá nhiều thông tin không liên quan sẽ làm loãng sự tập trung vào các token quan trọng.

## Vì sao context là tài nguyên hữu hạn, không phải càng nhiều càng tốt?

Hầu hết LLM hiện nay dựa trên kiến trúc Transformer với cơ chế attention có độ phức tạp n². Context tăng
gấp đôi thì khối lượng tính toán tăng gấp bốn. Quan trọng hơn, sự chú ý không phân bổ đều, do cơ chế
Rotary Position Embedding (RoPE) tạo ra hiệu ứng suy giảm (decay) khiến các token nằm xa điểm đầu và điểm
cuối rơi vào "vùng chú ý thấp".

Hiện tượng "Lost in the Middle" cho thấy độ chính xác giảm hơn 30% khi thông tin quan trọng nằm ở giữa
input. Bên cạnh đó là "context rot" (ngữ cảnh suy giảm): hiệu suất sụt giảm đột ngột và khó dự đoán khi
input chạm một ngưỡng nhất định, dù vẫn nằm trong giới hạn lý thuyết. Bạn phải phân biệt "cửa sổ ngữ cảnh
lý thuyết" (quảng cáo cả triệu token) với "cửa sổ ngữ cảnh hiệu dụng" (thường chỉ đạt 40–60% dung lượng
lý thuyết) để agent hoạt động ổn định.

![Đường cong chú ý hình chữ U của hiện tượng Lost in the Middle: độ chính xác cao ở đầu và cuối ngữ cảnh nhưng giảm hơn 30% ở giữa](https://camnangai.com/articles/context-engineering/03-vn.webp)

## Những kiểu lỗi context thường gặp là gì?

Dựa trên nghiên cứu của Drew Breunig, có bốn chế độ lỗi (failure modes) chính:

### Context poisoning (nhiễm độc)

Thông tin sai lệch hoặc lỗi suy luận (hallucination) lọt vào context rồi bị mô hình lặp lại, lấy làm căn
cứ cho các bước sau, tạo ra sai lệch dây chuyền.

### Context distraction (xao nhãng)

Thông tin thừa hoặc dữ liệu nhiễu kéo sự chú ý khỏi nhiệm vụ chính, khiến agent phản hồi hời hợt hoặc đi
chệch mục tiêu.

### Context confusion (nhầm lẫn)

Xảy ra khi có quá nhiều lựa chọn. Llama 3.1 8B chạy tốt với 19 công cụ nhưng thất bại hoàn toàn khi phải
chọn giữa 46 công cụ, dù tổng token vẫn trong giới hạn.

### Context clash (xung đột)

Thông tin mới mâu thuẫn với chỉ thị hệ thống hoặc dữ liệu cũ. Thiếu phân cấp ưu tiên (kiểu System Prompt
đứng trên Knowledge), mô hình sẽ hành động không nhất quán.

## Bốn chiến lược cốt lõi: Write, Select, Compress, Isolate

Khung chiến lược từ LangChain và Anthropic giúp bạn quản lý context một cách bài bản:

![Bốn chiến lược cốt lõi của context engineering trình bày dạng lưới bốn ô: Write (ghi), Select (chọn), Compress (nén) và Isolate (cô lập)](https://camnangai.com/articles/context-engineering/04-vn.webp)

### Write (ghi)

Lưu thông tin ra ngoài cửa sổ ngữ cảnh qua "scratchpads" hoặc file bền vững như `CLAUDE.md`. Ghi lại các kế
hoạch trung gian là bắt buộc để khỏi mất mát khi context bị cắt cụt (truncation) ở ngưỡng 200k token.

### Select (chọn)

Chỉ nạp những gì cần thiết. Dùng RAG không chỉ cho dữ liệu mà cho cả công cụ (RAG-MCP). Sau khi truy
xuất, hãy áp dụng bước reranking (tái xếp hạng) để chỉ nạp các đoạn dữ liệu liên quan nhất vào context,
giảm thiểu nhiễu.

### Compress (nén)

Tóm tắt lịch sử hội thoại và cắt tỉa (trimming) các output công cụ dài dòng. Kỹ thuật "auto-compact" của
Anthropic tự kích hoạt khi đạt 95% dung lượng để tóm tắt tiến trình, giữ lại các kết quả then chốt cùng
vài file gần nhất.

### Isolate (cô lập)

Chia nhỏ nhiệm vụ cho các sub-agent. Mỗi agent phụ làm việc trong một context sạch và chỉ trả kết quả cô
đọng về cho agent chính. Chiến lược này tăng tới 90.2% hiệu suất trên các tác vụ nghiên cứu phức tạp so
với việc dùng một agent duy nhất xử lý tất cả.

## Làm sao đưa đúng thông tin vào đúng thời điểm?

Vì context là tài nguyên hữu hạn, bạn không nên nạp sẵn mọi thứ ngay từ đầu. Thay vì "loading upfront"
(nạp trước toàn bộ tài liệu phòng khi cần), hãy dùng chiến lược "just-in-time" (chỉ nạp đúng thứ cần cho
bước hiện tại). Cách triển khai cụ thể là "progressive disclosure" (tiết lộ dần dần): thay vì đọc trọn cả
tài liệu, agent chỉ đọc lướt tiêu đề và tóm tắt trước, rồi mới quyết định gọi công cụ để đọc chi tiết đúng
phần nó thực sự cần. Nhờ vậy, context luôn gọn và chỉ chứa thông tin liên quan đến việc đang làm.

Cốt lõi của just-in-time là agent không ôm sẵn toàn bộ dữ liệu trong context, mà chỉ giữ các tham chiếu
nhẹ — đường dẫn file, câu truy vấn đã lưu, hay đường link — rồi dùng công cụ (tool) để nạp dữ liệu thật
vào đúng lúc cần. Cách này phản chiếu đúng cách con người làm việc: ta không thuộc lòng cả kho tài liệu, mà
dựa vào hệ thống file, hộp thư hay bookmark để lấy thông tin khi cần. Ngay cả siêu dữ liệu (metadata) cũng
là tín hiệu để agent quyết định nên đọc gì: tên file gợi ý nội dung, kích thước gợi ý độ phức tạp, thời gian
sửa đổi gợi ý mức độ liên quan, và cấu trúc thư mục cho biết vai trò — ví dụ `test_utils.py` nằm trong
`tests/` mang ý nghĩa khác hẳn khi cùng tên file đó nằm trong `src/core_logic/`.

Trên thực tế, chiến lược tốt nhất thường là kết hợp (hybrid): nạp sẵn phần cốt yếu để có tốc độ, rồi để
phần còn lại nạp khi cần. Claude Code là ví dụ điển hình — nó nạp thẳng file `CLAUDE.md` vào context ngay
từ đầu (vì đây là chỉ dẫn lúc nào cũng cần), nhưng lại dùng các công cụ như `glob` và `grep` để dò tìm và
đọc các file khác đúng lúc, thay vì lập chỉ mục (index) sẵn cả dự án — vốn dễ lỗi thời và cồng kềnh.

Đổi lại, just-in-time không miễn phí: dò tìm lúc chạy (runtime) chậm hơn so với truy xuất dữ liệu đã chuẩn
bị sẵn, và nó đòi hỏi bạn thiết kế công cụ cùng chỉ dẫn điều hướng đủ tốt. Thiếu điều đó, agent dễ lãng phí
context vì dùng sai công cụ, đi vào ngõ cụt hoặc bỏ sót thông tin quan trọng. Vì vậy, hãy chọn điểm cân
bằng theo đặc thù tác vụ: dữ liệu biến động liên tục thì nghiêng về just-in-time, còn dữ liệu ổn định thì
nạp sẵn lại nhanh và đơn giản hơn.

Bên cạnh "khi nào" nạp, "cách trình bày" cũng quan trọng không kém. Định dạng có cấu trúc rõ ràng như XML
tags (ví dụ `<rules>`, `<context>`) hoặc Markdown header giúp LLM phân biệt đâu là chỉ thị, đâu là dữ liệu
tham khảo và đâu là lịch sử hội thoại. Ranh giới rõ ràng giúp mô hình dồn "vùng chú ý" vào đúng thành phần
quan trọng, thay vì phải tự đoán mọi thứ nằm lẫn trong một khối văn bản.

## Quản lý context cho tác vụ dài hơi như thế nào?

Với agent chạy nhiều giờ, bạn cần các kỹ thuật quản lý trạng thái bền vững:

- **Agentic memory:** yêu cầu agent liên tục cập nhật nhật ký tiến độ (`progress.md`) để theo dõi trạng
  thái nhiệm vụ.
- **Frequent intentional compaction:** chia quy trình thành các giai đoạn (Research → Planning →
  Implementation). Mỗi lần chuyển giai đoạn, reset context và chỉ mang theo tóm tắt (artifact) của giai
  đoạn trước.
- **Tối ưu KV-cache:** đặt các phần cố định — System instructions và Tool descriptions — ở ngay đầu
  context và giữ nguyên qua mỗi lượt gọi. Mô hình xử lý context tuần tự từ trái sang phải, nên nó có thể
  lưu lại (cache) kết quả tính toán cho đoạn đầu không đổi và tái sử dụng ở lượt sau thay vì tính lại từ
  đầu — đó là cơ chế prefix caching. Nhờ vậy, chi phí token đầu vào giảm tới 10 lần (ví dụ với Claude
  Sonnet) và phản hồi nhanh hơn hẳn. Ngược lại, chỉ cần một token ở đầu thay đổi là toàn bộ cache phía sau
  bị vô hiệu — nên hãy để những phần hay biến động ở cuối context.

![Quy trình Frequent Intentional Compaction bốn bước: khảo sát, xóa ngữ cảnh, lập kế hoạch và thực thi](https://camnangai.com/articles/context-engineering/05-vn.webp)

## Áp dụng vào thực tế: mô hình ACE và năm nguyên tắc khởi đầu

Mô hình ACE (Agentic Context Engineering) từ Stanford là điểm tham chiếu tốt nhất hiện nay. Nó chạy vòng
lặp ba vai trò: Generator (thực hiện), Reflector (đánh giá) và Curator (tinh chỉnh playbook). Playbook tự
tiến hóa sau mỗi lần thực thi, giúp tăng 10.6% hiệu suất benchmark agent và 8.6% trên các tác vụ tài
chính mà không cần đổi mô hình.

Năm nguyên tắc cho Product Builder:

1. **Ưu tiên tinh lọc hơn tích lũy:** loại bỏ thông tin thừa còn quan trọng hơn nạp thêm dữ liệu.
2. **Giữ context dưới 40% dung lượng lý thuyết** để duy trì độ minh mẫn cao nhất.
3. **Dùng agent nhỏ và chuyên biệt** để cô lập ngữ cảnh.
4. **Coi context là một sản phẩm:** cần có SLA (Service Level Agreement — cam kết mức chất lượng) về độ tươi (freshness) và độ chính xác.
5. **Luôn đặt chỉ thị quan trọng nhất ở đầu hoặc cuối input** để tận dụng cấu trúc U-shape của attention.

## Tài liệu tham khảo

- [A Guide to Context Engineering for LLMs — ByteByteGo](https://blog.bytebytego.com/p/a-guide-to-context-engineering-for)
- [Context Engineering Clearly Explained (YouTube)](https://www.youtube.com/watch?v=jLuwLJBQkIs)
- [Context Engineering for Agents (YouTube)](https://www.youtube.com/watch?v=4GiqzUHD5AA)
- [Context Engineering for Product Builders: The 2026 Operating Manual — Karo Zieminski](https://karozieminski.substack.com/p/context-engineering-product-builders-guide-2026)
- [Context Is the New Code — Patrick Debois, Tessl (YouTube)](https://www.youtube.com/watch?v=bSG9wUYaHWU)
- [Effective Context Engineering for AI Agents — Anthropic](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)
- [What Is Context Engineering? — IBM](https://www.ibm.com/think/topics/context-engineering)
- [What Is Context Engineering? — System Design Newsletter](https://newsletter.systemdesign.one/p/what-is-context-engineering)