Context window là một ngân sách
Model có giới hạn context window (ví dụ 200K token). Mọi thứ agent "biết" tại một thời điểm — system prompt, file đã đọc, lịch sử chat, tool output — đều nằm chung trong ngân sách này. Khi đầy, thông tin cũ bị cắt bớt (truncation) hoặc bị nén (compaction), và agent có thể "quên" điều bạn nói 20 phút trước.
Hãy coi context window như RAM, không phải ổ cứng. Nó nhỏ, quý, và cần dọn dẹp liên tục.
Ví dụ cụ thể về sự trôi context
Bạn làm một phiên refactor dài. Đầu phiên bạn dặn: "Dùng snake_case cho tên hàm." Sau 40 lượt trao đổi, agent đọc thêm 15 file test dài, log lỗi, diff... Ngân sách gần đầy, dặn dò ban đầu bị đẩy ra. Đột nhiên agent bắt đầu sinh getUserData (camelCase). Không phải nó "cãi" — quy tắc đó đã rơi khỏi context.
Bài học: quy ước quan trọng phải nằm ở nơi bền (file CLAUDE.md, được nạp lại mỗi phiên), không chỉ nói một lần trong chat.
Ước lượng token nhanh
1 token ≈ 0.75 từ tiếng Anh ≈ 4 ký tự
Một file 400 dòng code ≈ 4.000–6.000 token
Một lần dán log lỗi dài ≈ 2.000+ token
Dán 10 file "cho chắc" có thể ngốn 50K token — 1/4 ngân sách — phần lớn là nhiễu.
Ba kỹ thuật quản lý context window
- Selective retrieval — chỉ đọc file thật sự liên quan. Dùng grep/search để agent tìm đúng đoạn, thay vì đọc cả file.
- Compaction / summarize — khi phiên dài, yêu cầu agent tóm tắt trạng thái ("đã làm gì, còn gì") rồi bắt đầu phiên mới sạch với bản tóm tắt đó.
- Externalize memory — ghi quyết định quan trọng ra file (TODO.md, CLAUDE.md), thay vì để trong lịch sử chat dễ bay hơi.
Quy trình vận hành một phiên dài
- Bắt đầu: nạp CLAUDE.md + chỉ file liên quan tác vụ đầu tiên.
- Mỗi khi chuyển tác vụ con: yêu cầu agent quên file cũ, đọc file mới.
- Khi context đạt ~70%: dừng, yêu cầu tóm tắt tiến độ ra file.
- Mở phiên mới, nạp bản tóm tắt + CLAUDE.md, tiếp tục.
- Không bao giờ để một lỗi/log dài nằm mãi trong context sau khi đã xử lý xong.
Checklist tối ưu ngân sách
- [ ] Chỉ đọc file cần cho tác vụ hiện tại
- [ ] Log lỗi đã xử lý xong thì bỏ khỏi ngữ cảnh
- [ ] Quy ước bền nằm trong file, không chỉ trong chat
- [ ] Phiên quá dài đã được tóm tắt và khởi động lại
- [ ] Không dán trùng lặp cùng một file nhiều lần
Đoạn hướng dẫn agent tự nén
Context đang gần đầy. Hãy:
1. Tóm tắt các quyết định kiến trúc đã chốt (gạch đầu dòng).
2. Liệt kê file đã sửa + trạng thái test.
3. Ghi các việc còn lại.
Ghi tất cả vào PROGRESS.md. Sau đó ta mở phiên mới từ file này.
Hiện tượng "lost in the middle"
Một điểm ít người biết: ngay cả khi thông tin vẫn nằm trong context window, model có xu hướng chú ý mạnh vào phần đầu và phần cuối của context, còn phần ở giữa dễ bị bỏ sót. Vì vậy đừng nghĩ "window 200K nên cứ nhét thoải mái". Hệ quả thực hành: đặt thông tin quan trọng nhất (yêu cầu hiện tại, ràng buộc then chốt) ở gần cuối prompt, ngay trước khi agent hành động; đừng chôn nó giữa một biển log dán từ 30 phút trước. Đây là lý do khác để dọn dẹp và tóm tắt: giữ context ngắn giúp mọi thông tin đều nằm ở "vùng chú ý cao".
Một quy trình mẫu cho phiên 2 giờ
- 0:00 — nạp CLAUDE.md + file cho tác vụ A. Làm A, verify, xong.
- 0:40 — chuyển tác vụ B: bảo agent quên file của A, đọc file của B.
- 1:10 — context ~65%: yêu cầu tóm tắt A, B vào PROGRESS.md.
- 1:15 — mở phiên mới, nạp PROGRESS.md + CLAUDE.md, làm tác vụ C.
Sai lầm thường gặp
- Phiên chat vô tận — làm 3 tiếng trong một phiên, cuối cùng agent "lú" vì context đầy nhiễu. Nên chia phiên.
- Dán cả file 2000 dòng để hỏi 1 hàm — đọc đúng đoạn thôi.
- Tưởng context window lớn = không cần quản lý — window lớn vẫn bị "lost in the middle": thông tin ở giữa dễ bị bỏ sót.
- Để dặn dò quan trọng chìm trong lịch sử — chuyển nó thành quy ước bền trong file.
- Chôn yêu cầu hiện tại dưới đống log cũ — đặt nó ở cuối, nơi model chú ý mạnh nhất.