Bài 7 — Quản lý ngữ cảnh và giữ agent không lạc trôi

Agent có cửa sổ ngữ cảnh (context window) hữu hạn. Phiên làm việc càng dài, thông tin đầu càng bị đẩy ra ngoài, và agent bắt đầu "quên" spec, lặp lại lỗi cũ, mâu thuẫn với quyết định trước. Spec-driven cho bạn công cụ chống lại điều này — nhưng phải dùng đúng.

Vì sao drift ngữ cảnh xảy ra

• Cửa sổ đầy: chat cũ, output test dài, file lớn chiếm chỗ, đẩy spec ra ngoài.
• Không có nguồn sự thật cố định: nếu spec chỉ nằm trong 1 câu chat 200 tin nhắn trước, nó đã bay.
• Phiên quá dài không tổng kết: agent giữ đủ thứ nhiễu, mất tín hiệu chính.

Giải pháp cốt lõi: giữ nguồn sự thật trên đĩa (spec/plan file), không trong lịch sử chat.

Chiến thuật 1 — Neo lại spec ở mỗi task

Đừng giả định agent còn nhớ spec. Ở mỗi task, yêu cầu nó đọc lại:

Đọc lại specs/002-search.md và plans/002-search.plan.md.
Xác nhận T3 khớp AC nào, rồi thực hiện T3.

Việc "đọc lại" kéo spec trở vào ngữ cảnh tươi mới, ép agent nói ra nó đang phủ AC nào — lộ ngay nếu hiểu sai.

Chiến thuật 2 — Cập nhật plan như một "sổ tiến độ"

Sau mỗi task, cho agent đánh dấu tiến độ ngay trong plan:

### T1 — Index tìm kiếm ✅ (commit a1b2c3)
### T2 — Endpoint /search ✅ (commit d4e5f6)
### T3 — Xử lý rỗng ⬅ đang làm
### T4 — Test hiệu năng ⬜

Plan trở thành trí nhớ ngoài (external memory): mở phiên mới vẫn biết đang ở đâu, đã quyết gì.

Chiến thuật 3 — Tổng kết và làm mới phiên

Khi phiên dài/nặng, yêu cầu agent tổng kết trạng thái vào file, rồi bắt đầu phiên mới sạch:

Tóm tắt vào plans/002-search.plan.md: task đã xong, quyết định kiến trúc,
vấn đề còn treo. Đủ để một phiên mới tiếp tục không cần lịch sử chat này.

Phiên mới chỉ cần đọc AGENT.md + spec + plan là đủ ngữ cảnh — gọn và chính xác hơn kéo lê 300 tin nhắn.

Chiến thuật 4 — Kiểm soát cái gì vào ngữ cảnh

• Đừng dán nguyên file 2000 dòng; chỉ đưa phần liên quan.
• Cắt bớt output test dài; giữ phần fail.
• Một feature một phiên khi có thể, tránh trộn nhiều spec.

Ví dụ tình huống: agent mâu thuẫn chính nó

Giữa dự án, agent đổi cách phân trang từ offset (đã chốt ở plan) sang cursor mà không báo. Nguyên nhân: quyết định offset nằm ở đầu phiên, đã trôi khỏi ngữ cảnh. Xử lý: neo lại — "Plan chốt offset (xem mục Giả định). Giữ offset, hoàn tác thay đổi cursor." Và ghi rõ quyết định này vào plan để lần sau không tái diễn.

Khung tư duy: "Đĩa là bộ nhớ dài hạn, chat là bộ nhớ ngắn hạn"

Mọi quyết định quan trọng phải hạ cánh xuống file (spec/plan/AGENT.md). Chat chỉ là nơi làm việc tạm. Nếu một thông tin chỉ tồn tại trong chat, coi như agent sẽ quên nó.

Checklist chống lạc trôi

• [ ] Spec/plan nằm trong file, không chỉ trong chat.
• [ ] Mỗi task yêu cầu agent đọc lại spec/plan liên quan.
• [ ] Plan được cập nhật tiến độ + quyết định sau mỗi task.
• [ ] Phiên dài được tổng kết vào file trước khi làm mới.
• [ ] Chỉ nạp phần ngữ cảnh liên quan, cắt nhiễu.

Sai lầm thường gặp

• Ỷ lại vào trí nhớ của agent: "Nó vừa làm xong nên chắc còn nhớ" — sai khi phiên dài.
• Không ghi quyết định xuống file: Quyết định kiến trúc trôi mất, agent tự quyết lại khác đi.
• Nhồi cả repo vào ngữ cảnh: Càng nhiều nhiễu, agent càng dễ lạc trọng tâm.
• Kéo lê một phiên khổng lồ: Nên tổng kết + mở phiên mới sạch thay vì cố nhồi thêm.

Bài 8: ghép tất cả thành một quy trình vận hành thực chiến từ đầu đến khi giao hàng.