Một phiên agentic coding có thể chạy hàng giờ liền, nhưng context window (cửa sổ ngữ cảnh — lượng thông tin AI có thể "nhớ" trong một lần xử lý) thì luôn có giới hạn — và nếu bạn không chủ động quản lý nó, agent của bạn sẽ dần quên mất chính những gì bạn vừa yêu cầu 20 phút trước.
Vì Sao Các Phiên Làm Việc Dài Lại Đi Chệch Hướng
Khi bạn mới bắt đầu một phiên làm việc với agent — dù là Claude Code, Cursor, hay bất kỳ công cụ agentic nào — mọi thứ thường rất mượt. Bạn ra yêu cầu, agent đọc code, đề xuất thay đổi, bạn duyệt, nó thực thi. Nhưng càng về sau, đặc biệt với các task lớn kéo dài qua hàng chục lượt trao đổi, bạn sẽ bắt đầu thấy chất lượng đi xuống rõ rệt. Đây không phải cảm giác chủ quan — có nguyên nhân kỹ thuật cụ thể đứng sau.
Vấn đề cốt lõi là context window bị lấp đầy. Mỗi lượt trao đổi — câu hỏi của bạn, phản hồi của agent, output của mọi tool call (đọc file, chạy test, grep code) — đều được cộng dồn vào lịch sử hội thoại và gửi lại cho model ở lượt tiếp theo. Một lệnh cat in ra file 2000 dòng, một lần chạy test suite với log dài dằng dặc, một lần agent đọc nhầm cả một thư mục node_modules — tất cả đều ngốn token, và token thì không tự biến mất. Với context window vài trăm nghìn token nghe có vẻ nhiều, nhưng một phiên làm việc thực tế trên codebase cỡ vừa có thể lấp đầy nó nhanh hơn bạn nghĩ, nhất là khi agent liên tục đọc lại file để "xác nhận" trạng thái hiện tại.
Khi context gần đầy, một số hiện tượng bắt đầu xuất hiện:
Thứ nhất là drift — agent dần trôi khỏi các ràng buộc (constraint) bạn đặt ra ban đầu. Bạn nói "không dùng thư viện ngoài, chỉ dùng stdlib" ở đầu phiên, nhưng đến lượt thứ 40, khi thông tin đó đã bị đẩy lùi rất xa trong lịch sử hoặc đã bị cắt bớt, agent có thể đề xuất import một package mới mà không hề "nhớ" ràng buộc đó nữa. Đây không phải agent "cố tình" phá luật — đơn giản là thông tin đó không còn đủ trọng số trong context để ảnh hưởng đến quyết định sinh token tiếp theo.
Thứ hai là lặp lại lỗi cũ. Nếu bạn đã sửa một bug, giải thích cách tránh nó, rồi vài chục lượt sau agent lại viết ra chính xác pattern gây bug đó — đó là dấu hiệu context về bài học đã học đã bị pha loãng hoặc rơi ra ngoài "vùng chú ý" (attention) hiệu quả của model.
Thứ ba là chất lượng output giảm dần. Khi context chứa quá nhiều nhiễu — các nhánh khám phá không dẫn đến đâu, các đoạn tool output dài dòng không còn liên quan, các cuộc thảo luận đã bị đảo ngược quyết định — model phải "gánh" thêm nhiễu đó mỗi lần sinh phản hồi. Tín hiệu hữu ích bị pha loãng giữa một biển thông tin không còn giá trị, khiến câu trả lời trở nên chung chung hơn, ít bám sát yêu cầu cụ thể hơn.
Thứ tư, thực tế và dễ đo lường nhất: chi phí và latency tăng. Mỗi request gửi lên đều kèm theo toàn bộ lịch sử trước đó (trừ khi có cơ chế nén). Phiên càng dài, mỗi lượt trao đổi càng tốn kém và càng mất nhiều thời gian để model xử lý xong phần context khổng lồ trước khi bắt đầu sinh ra câu trả lời hữu ích.
Hiểu rõ cơ chế này quan trọng vì nó thay đổi cách bạn làm việc: thay vì cố "chịu đựng" cho đến khi agent hỏng hẳn, bạn học cách can thiệp chủ động — nén, tóm tắt, và tái khởi tạo context trước khi mọi thứ đi vào vùng nguy hiểm.
Mẹo: Nếu bạn thấy mình đang scroll ngược lại rất xa để tìm một quyết định đã đưa ra trước đó, đó chính là lúc context của agent cũng đang "chật vật" tương tự — hãy coi đó là tín hiệu để hành động ngay, đừng đợi đến khi mọi thứ hỏng hẳn.
Nhận Biết Khi Nào Một Phiên Cần Được Can Thiệp
Kỹ sư giỏi làm việc với agent không phải là người tránh được mọi phiên bị degrade (suy giảm chất lượng), mà là người phát hiện sớm và xử lý trước khi thiệt hại lan rộng. Dưới đây là các tín hiệu cụ thể, quan sát được, mà bạn nên tập thành phản xạ theo dõi trong mọi phiên làm việc dài.
Agent hỏi lại điều đã được trả lời. Nếu bạn đã nói rõ tên database, convention đặt tên file, hay cách xử lý lỗi ưu tiên ở đầu phiên, và agent lại hỏi lại đúng câu hỏi đó (hoặc tệ hơn, tự đưa ra giả định sai lệch so với câu trả lời trước) — đây là dấu hiệu rõ ràng nhất rằng thông tin đó đã rơi khỏi "vùng nhìn thấy" hiệu quả của model.
Agent mâu thuẫn với quyết định trước đó. Ví dụ bạn đã quyết định dùng REST thay vì GraphQL cho một endpoint, agent đồng ý và triển khai theo hướng đó — nhưng 30 phút sau, khi bàn về một tính năng liên quan, nó lại đề xuất thêm GraphQL layer như thể cuộc thảo luận trước chưa từng xảy ra. Mâu thuẫn nội tại này là chỉ dấu mạnh của context bị mất mát hoặc bị đẩy ra ngoài cửa sổ.
Phản hồi chậm lại rõ rệt. Đây là tín hiệu cơ học chứ không phải "cảm tính" — khi context dài ra, thời gian xử lý (đặc biệt là time-to-first-token) tăng lên vì model phải "đọc" qua toàn bộ lịch sử trước khi sinh câu trả lời mới. Nếu bạn để ý thấy độ trễ tăng dần qua các lượt trong cùng một phiên, đó là bằng chứng trực tiếp rằng context đang phình to.
Agent "hallucinate" (bịa đặt) nội dung file. Đây là dấu hiệu nguy hiểm nhất vì nó âm thầm phá hoại độ tin cậy. Khi agent mô tả nội dung một file mà nó đã đọc từ rất lâu trong phiên (và nội dung file đó đã bị người dùng chỉnh sửa, hoặc bản thân agent chỉnh sửa nhưng không re-read), nó có thể "nhớ nhầm" hoặc tự suy diễn nội dung dựa trên pattern chung thay vì trạng thái thực tế. Luôn nghi ngờ khi agent mô tả chi tiết một file mà nó không vừa mới đọc lại.
Agent bắt đầu đề xuất giải pháp chung chung, ít bám context dự án. Khi tín hiệu hữu ích bị pha loãng, các đề xuất có xu hướng quay về "best practice" sách vở thay vì bám sát convention và kiến trúc cụ thể của dự án bạn đang làm.
Cách thực hành tốt là: cứ sau mỗi 15-20 lượt trao đổi trong một phiên phức tạp, dừng lại và tự hỏi "agent có còn nhớ chính xác 3 quyết định quan trọng nhất chúng ta đã chốt chưa?". Bạn có thể kiểm tra trực tiếp bằng một câu hỏi đơn giản:
Before we continue, quickly list the key architectural decisions
and constraints we've agreed on so far in this session, in order.
Nếu câu trả lời thiếu sót, sai lệch, hoặc mơ hồ so với thực tế — đó là bằng chứng rõ ràng bạn cần nén và tái khởi tạo context ngay, trước khi tiếp tục.
Mẹo: Đặt một "checkpoint câu hỏi" như trên thành thói quen định kỳ (ví dụ mỗi khi hoàn thành một sub-task), thay vì chỉ làm khi nghi ngờ có vấn đề — phát hiện sớm rẻ hơn rất nhiều so với sửa chữa sau khi agent đã đi lạc hướng nhiều bước.
Kỹ Thuật Tóm Tắt: Để Agent Tự Nén Trạng Thái Của Chính Nó
Cách hiệu quả nhất để nén một phiên dài không phải là bạn tự tay viết lại tóm tắt, mà là yêu cầu chính agent — vốn đang nắm giữ toàn bộ context — tự tóm tắt trạng thái của nó thành một bản brief gọn gàng. Model có khả năng tổng hợp thông tin tốt hơn nhiều so với việc bạn cố nhớ lại thủ công mọi chi tiết đã trao đổi.
Prompt tóm tắt hiệu quả cần yêu cầu rõ ràng những gì cần được capture, không chỉ nói chung chung "tóm tắt lại". Đây là một prompt mẫu bạn có thể dùng gần như nguyên văn:
Summarize everything we've decided and done so far into a compact
brief I can use to start a new session. Structure it as:
1. Goal: what are we trying to accomplish overall
2. Key decisions: every architectural/design choice we've locked in,
and briefly why
3. Files touched: which files were created or modified, and what
changed in each
4. Current state: what's working, what's tested, what's NOT done yet
5. Open TODOs: remaining work items, in priority order
6. Constraints to remember: coding conventions, libraries to avoid,
patterns to follow, anything I explicitly told you not to do
7. Next immediate step: the single next action to take when we resume
Keep it dense - no filler, no restating obvious context. Assume the
reader (a fresh session with no memory) needs everything to continue
seamlessly but nothing more.
Prompt này quan trọng ở chỗ nó ép agent phân loại thông tin theo mục đích sử dụng, thay vì tóm tắt tuyến tính theo thứ tự thời gian (vốn thường lẫn lộn giữa cái quan trọng và cái không). Mục "Constraints to remember" đặc biệt quan trọng vì đây chính là loại thông tin dễ bị drift nhất như đã phân tích ở phần trước.
Sau khi agent trả về bản tóm tắt, đừng vội tin tuyệt đối — hãy đọc lướt qua và tự hỏi: có thiếu quyết định quan trọng nào không? Có file nào đã sửa nhưng không được liệt kê không? Nếu bạn nhớ ra một chi tiết bị bỏ sót, bổ sung ngay bằng một lượt follow-up:
Add this to the brief: we also agreed to keep the API versioned
under /v2, and the payment webhook handler in
src/webhooks/payment.ts still needs idempotency handling before
it's production-ready.
Một biến thể hữu ích khác là tóm tắt theo góc nhìn "handoff cho người khác" thay vì "cho chính mình" — điều này ép agent viết rõ ràng và tự giải thích hơn, vì nó không thể giả định người đọc đã biết ngữ cảnh ngầm:
Write this summary as if you're handing this task off to another
engineer who has never seen this conversation. They need to be able
to pick up exactly where we left off without asking you any
clarifying questions.
Cách đặt câu hỏi này thường cho ra bản tóm tắt chất lượng cao hơn hẳn so với prompt "summarize this conversation" chung chung, vì nó buộc model đánh giá lại mức độ đầy đủ của thông tin thay vì chỉ nén cơ học.
Mẹo: Luôn yêu cầu bản tóm tắt ở dạng có cấu trúc (heading, bullet) thay vì văn xuôi liền mạch — cấu trúc rõ ràng giúp cả bạn và agent ở phiên mới dễ dàng "quét" lại thông tin cần thiết mà không phải đọc lại từ đầu đến cuối.
Nén Lịch Sử Hội Thoại: Giữ Gì, Bỏ Gì
Không phải mọi thứ trong lịch sử hội thoại đều đáng giữ lại như nhau. Việc nén hiệu quả đòi hỏi bạn (hoặc agent, khi được hướng dẫn đúng) phân biệt rõ tín hiệu và nhiễu.
Nên giữ:
- Quyết định cuối cùng, không phải toàn bộ quá trình tranh luận dẫn đến nó. Nếu bạn và agent đã cân nhắc 3 cách tiếp cận và chốt cách thứ 2, chỉ cần ghi lại "đã chọn cách 2 vì lý do X" — không cần giữ lại toàn bộ đoạn phân tích ưu nhược điểm của cả 3 phương án.
- Đường dẫn file đã dùng đến, kèm mô tả ngắn gọn về vai trò và trạng thái hiện tại của từng file (đã tạo mới / đã sửa phần nào / cần sửa tiếp).
- TODO còn mở — danh sách việc chưa hoàn thành, đặc biệt là những việc đã được xác định nhưng chưa triển khai.
- Ràng buộc và tiêu chí chấp nhận (acceptance criteria) — bất kỳ điều gì bạn đã nói "phải làm thế này" hoặc "không được làm thế kia". Đây là nhóm thông tin có giá trị cao nhất trên mỗi token, vì mất nó dẫn trực tiếp đến drift.
- Lỗi đã gặp và cách đã sửa — đặc biệt nếu lỗi đó có khả năng lặp lại (ví dụ một pattern code dễ gây race condition mà agent đã từng viết sai).
Nên bỏ:
- Các nhánh khám phá không dẫn đến kết quả — những lần bạn hỏi "thử cách A xem sao", agent thử, không hiệu quả, rồi cả hai chuyển sang cách khác. Bản thân việc "đã thử và không hiệu quả" đáng giữ lại một dòng, nhưng toàn bộ quá trình thử nghiệm chi tiết thì không cần.
- Kế hoạch đã bị thay thế — nếu bạn đổi ý về kiến trúc giữa chừng, kế hoạch cũ chỉ còn giá trị lịch sử, không có giá trị hành động. Giữ lại nó trong context chỉ tạo nguy cơ agent bị nhầm lẫn giữa "kế hoạch cũ" và "kế hoạch hiện tại".
- Tool output dài dòng — log test chạy dài hàng trăm dòng, output của
findliệt kê cả nghìn file, nội dung đầy đủ của một file lớn đã đọc để tham khảo một lần. Chỉ cần giữ lại kết luận rút ra từ output đó ("test suite pass, trừ 2 case liên quan đến timezone"), không cần giữ nguyên văn. - Các câu hỏi làm rõ đã được giải đáp — một khi câu hỏi "bạn muốn X hay Y" đã có câu trả lời, chỉ cần giữ câu trả lời, không cần giữ lại câu hỏi gốc.
Một cách thực hành cụ thể: khi yêu cầu agent tóm tắt (theo kỹ thuật ở phần trước), bạn có thể chỉ định rõ luật giữ/bỏ này ngay trong prompt:
When summarizing, drop any exploratory dead-ends, superseded plans,
and raw tool output. Keep only final decisions, file states, open
TODOs, and constraints. If something was tried and failed, mention
it in one line (what was tried, why it failed) - don't reconstruct
the full exploration.
Việc quy định rõ ràng "giữ gì bỏ gì" ngay trong prompt tóm tắt giúp bản brief cuối cùng nhỏ gọn hơn đáng kể mà không mất thông tin có giá trị hành động.
Mẹo: Khi phân vân không biết một đoạn thông tin có nên giữ hay không, tự hỏi: "Nếu ai đó chỉ đọc bản tóm tắt này mà không biết gì về phiên gốc, họ có đưa ra quyết định đúng không nếu thiếu đoạn này?" — nếu câu trả lời là có thể vẫn đúng, mạnh dạn bỏ.
Các Mẫu Hình Checkpoint Cho Phiên Làm Việc
Ngoài việc tóm tắt phản ứng (khi phiên đã bắt đầu có dấu hiệu degrade), một thói quen tốt hơn là checkpoint chủ động — tạo ra các điểm lưu trạng thái đều đặn trong suốt quá trình làm việc, thay vì đợi đến khi mọi thứ đã rối mới xử lý.
Progress file / handoff note dạng sống. Duy trì một file, ví dụ progress.md hoặc HANDOFF.md, trong thư mục dự án (hoặc trong thư mục plan theo quy ước của team bạn), được cập nhật liên tục trong suốt phiên làm việc chứ không chỉ viết một lần ở cuối. Cấu trúc gợi ý:
## Status: In progress
## Done
- [x] Set up schema migration for `orders` table
- [x] Implemented POST /orders endpoint with validation
## In progress
- [ ] Wiring up payment webhook handler
(src/webhooks/payment.ts - idempotency not done yet)
## Not started
- [ ] Refund flow
- [ ] Admin dashboard view
## Decisions
- Using REST, not GraphQL, for this feature (agreed 2026-07-09)
- Idempotency keys stored in Redis with 24h TTL
## Constraints
- No new npm dependencies without explicit approval
- All money fields must be integers (cents), never floats
File này đóng vai trò "nguồn sự thật" (source of truth) độc lập với context của bất kỳ phiên chat nào — bạn hoặc agent đều có thể đọc lại nó bất cứ lúc nào để đồng bộ trạng thái, kể cả sau khi context của phiên cũ đã mất hoàn toàn.
Commit incremental, thường xuyên. Mỗi khi hoàn thành một đơn vị công việc có ý nghĩa (không cần đợi đến khi cả feature xong), hãy commit. Commit message chính là một dạng checkpoint tự nhiên — nó ghi lại chính xác "tại thời điểm này, trạng thái code là gì và tại sao thay đổi này được thực hiện". Khi cần agent tóm tắt lại, git log là một nguồn thông tin đáng tin cậy hơn nhiều so với việc dựa hoàn toàn vào trí nhớ của model về hội thoại.
Dùng plan file như một checkpoint có cấu trúc. Nếu team bạn đã có quy ước viết plan trước khi implement (như quy định trong CLAUDE.md của một số dự án), plan file đó tự nhiên trở thành một checkpoint: nó ghi lại ý định ban đầu, và bạn có thể cập nhật nó dần dần khi có quyết định mới phát sinh trong lúc triển khai, thay vì để các quyết định đó chỉ tồn tại rải rác trong hội thoại.
Sự khác biệt giữa checkpoint chủ động và tóm tắt phản ứng là: checkpoint chủ động biến trạng thái dự án thành thứ tồn tại độc lập với context window, nên kể cả khi một phiên chat bị mất hoàn toàn (crash, đóng nhầm tab, hết quota), bạn vẫn có thể khôi phục lại gần như toàn bộ ngữ cảnh chỉ bằng cách đọc lại các file này.
Mẹo: Đặt quy tắc cho bản thân — không kết thúc một phiên làm việc dài mà không cập nhật progress file, kể cả khi task chưa xong. "Chưa xong" cũng là một trạng thái cần được ghi lại rõ ràng, không phải để ngầm hiểu.
Thực Hành: Nén và Khôi Phục Một Phiên Đã Bị Degrade
Hãy đi qua một kịch bản đầy đủ, từ lúc phát hiện phiên có vấn đề đến lúc khôi phục hoàn toàn năng suất làm việc trong một phiên mới.
Bước 1 — Nhận diện dấu hiệu degrade. Giả sử bạn đang làm việc với agent để xây dựng một tính năng thanh toán, đã qua khoảng 35 lượt trao đổi. Bạn nhận thấy agent vừa đề xuất dùng float cho trường amount, trong khi bạn đã nói rõ từ đầu phải dùng số nguyên (cents). Đây là tín hiệu drift rõ ràng. Bạn xác nhận bằng câu hỏi kiểm tra:
Before we continue, quickly list the key architectural decisions
and constraints we've agreed on so far in this session, in order.
Nếu bản trả lời không nhắc đến quy tắc "money as integer cents", bạn đã có bằng chứng cụ thể để hành động.
Bước 2 — Yêu cầu agent tự tóm tắt. Thay vì cố sửa từng lỗi nhỏ một, bạn dừng lại và yêu cầu nén toàn bộ trạng thái:
We're going to start a fresh session soon because this one has
gotten long. Summarize everything we've decided and done so far
into a compact brief I can use to seed a new session. Structure it
as: Goal, Key decisions (with reasons), Files touched (with what
changed), Current state (what works/what's tested/what's not done),
Open TODOs (priority order), Constraints to remember (things I
explicitly told you, like: money fields must be integer cents, no
new dependencies without approval), and Next immediate step.
Drop exploratory dead-ends and raw tool output - only keep
information with action value for someone with zero memory of this
conversation.
Bước 3 — Kiểm tra và bổ sung bản tóm tắt. Đọc lại bản brief agent trả về. Giả sử bạn phát hiện nó quên mất một quyết định về việc dùng idempotency key cho webhook — bổ sung ngay:
Add to the brief: we agreed to use idempotency keys (stored in
Redis, 24h TTL) for the payment webhook handler at
src/webhooks/payment.ts - this is not implemented yet, it's the
highest priority TODO.
Bước 4 — Lưu bản tóm tắt ra ngoài phiên chat. Copy bản brief cuối cùng vào file progress.md trong dự án (theo mẫu ở phần trước), và commit lại nếu có thay đổi code liên quan. Điều này đảm bảo bản tóm tắt không chỉ tồn tại trong context sắp bị bỏ đi, mà còn tồn tại độc lập trên disk.
Bước 5 — Bắt đầu phiên mới, dùng bản tóm tắt làm seed context. Mở một phiên/thread mới hoàn toàn (context trống). Thay vì để agent mò mẫm lại từ đầu, bạn seed ngay bằng bản tóm tắt:
We're continuing work on the payment feature from a previous
session. Here's the current state:
[paste the brief here]
Please read src/webhooks/payment.ts and src/orders/schema.ts to
confirm the current code matches this summary, then let's continue
with the idempotency key implementation.
Lưu ý bước yêu cầu agent đọc lại file thực tế để xác nhận, không chỉ tin tuyệt đối vào bản tóm tắt bằng văn bản — đây là bước kiểm tra chéo quan trọng vì bản tóm tắt có thể lệch nhẹ so với code thực tế (đặc biệt nếu có thay đổi thủ công ngoài agent).
Bước 6 — Kiểm chứng tính liên tục. Sau khi agent xác nhận đã đọc file, đặt lại đúng câu hỏi checkpoint đã dùng ở bước 1, ở phiên mới:
Quickly confirm: what are the key constraints I need you to
remember for this feature, and what's the very next thing we're
implementing?
Nếu câu trả lời khớp với bản tóm tắt (nhắc đúng "money as integer cents", đúng next step là idempotency key), bạn đã khôi phục thành công ngữ cảnh làm việc mà không mất thông tin quan trọng — trong khi context window của phiên mới gần như trống, sẵn sàng cho hàng chục lượt trao đổi tiếp theo với hiệu suất tối đa.
Toàn bộ quy trình 6 bước này thường chỉ mất 3-5 phút nhưng tiết kiệm được rất nhiều thời gian debug những lỗi do drift gây ra sau này.
Mẹo: Đừng đợi agent tự nhận ra nó cần tóm tắt — trách nhiệm phát hiện degrade luôn thuộc về bạn, người quan sát từ bên ngoài. Bản thân agent, khi đang ở trong context bị pha loãng, thường không có khả năng tự nhận biết mình đang bị degrade.
Cách Claude Code Tự Động Xử Lý Context
Các công cụ agentic hiện đại, trong đó có Claude Code, không để bạn tự xoay sở hoàn toàn thủ công — có một số cơ chế được xây dựng sẵn để giảm nhẹ vấn đề context bị lấp đầy, dù hiểu biết thủ công ở các phần trước vẫn cần thiết để dùng các cơ chế này hiệu quả.
Auto-compaction (tự động nén). Khi context của một phiên tiến gần đến giới hạn của context window, Claude Code có cơ chế tự động kích hoạt việc nén lại lịch sử hội thoại thành một bản tóm tắt gọn hơn, sau đó tiếp tục phiên làm việc dựa trên bản tóm tắt đó thay vì toàn bộ lịch sử gốc. Về bản chất, đây là phiên bản tự động hóa của chính kỹ thuật "để agent tự tóm tắt trạng thái" mà chúng ta đã thực hành thủ công ở trên — điểm khác biệt là nó được kích hoạt bởi hệ thống dựa trên ngưỡng sử dụng context, không phải do bạn chủ động yêu cầu.
Lệnh /compact. Bên cạnh cơ chế tự động, Claude Code cũng cho phép bạn chủ động kích hoạt việc nén context bất cứ lúc nào bằng lệnh /compact, thay vì phải đợi đến ngưỡng tự động hoặc tự tay viết prompt tóm tắt dài dòng. Đây là công cụ hữu ích khi bạn — dựa trên các tín hiệu degrade đã học ở phần trước — nhận thấy đã đến lúc nén nhưng chưa muốn kết thúc hẳn phiên làm việc để mở phiên mới. Bạn hoàn toàn có thể kết hợp: dùng /compact để nén nhanh, sau đó vẫn tự kiểm tra lại bằng câu hỏi checkpoint để đảm bảo các ràng buộc quan trọng không bị nén mất.
Cô lập context qua sub-agent (sub-agent isolation). Một cơ chế khác quan trọng không kém là khả năng giao việc cho các sub-agent chạy trong context riêng biệt, tách khỏi context chính (main context). Khi bạn giao một việc tốn nhiều "khảo sát" — ví dụ tìm kiếm một đoạn logic trong codebase lớn, hay đọc qua hàng chục file để trả lời một câu hỏi — cho một sub-agent, toàn bộ quá trình dò tìm, đọc file, thử-sai đó diễn ra trong context của riêng sub-agent đó. Chỉ có kết quả cuối cùng (câu trả lời cô đọng) được trả về và cộng vào main context. Điều này về bản chất là một dạng "nén từ gốc" — thay vì để main context phình to vì phải chứa toàn bộ quá trình khảo sát, bạn chỉ giữ lại kết luận, giống hệt nguyên tắc "giữ kết quả, bỏ quá trình khám phá" đã bàn ở phần nén lịch sử hội thoại.
Hiểu cách các cơ chế tự động này hoạt động giúp bạn dùng chúng chủ động thay vì bị động: bạn có thể chủ động giao việc khảo sát nặng cho sub-agent ngay từ đầu (thay vì để main context tự phình to rồi mới xử lý hậu quả), và bạn có thể chủ động gọi /compact tại đúng thời điểm dựa trên các tín hiệu degrade đã học, thay vì hoàn toàn phó mặc cho ngưỡng tự động của hệ thống — vốn được thiết kế cho trường hợp chung, không nhất thiết tối ưu cho task cụ thể của bạn.
Dù công cụ có tự động hóa đến đâu, các nguyên tắc nền tảng — nhận biết dấu hiệu degrade, phân biệt tín hiệu và nhiễu khi nén, checkpoint chủ động ra ngoài context — vẫn là kỹ năng cốt lõi bạn cần thành thạo, vì không có cơ chế tự động nào biết chính xác quyết định nào trong dự án của bạn là quan trọng sống còn và cần được bảo toàn tuyệt đối.
Mẹo: Đừng đợi auto-compaction tự kích hoạt khi bạn đang giữa một thao tác rủi ro cao (migrate DB, sửa logic thanh toán) — hệ thống có thể nén đúng lúc bạn cần giữ nguyên một chi tiết quan trọng. Chủ động gọi
/compactở một điểm dừng an toàn (sau khi đã checkpoint bằng progress file), thay vì để ngưỡng tự động chọn thời điểm hộ bạn.
Những điểm chính
- Context window có giới hạn cứng; phiên làm việc càng dài, nguy cơ drift (trôi khỏi ràng buộc ban đầu), lặp lỗi cũ, chất lượng giảm và chi phí/latency tăng càng cao.
- Theo dõi các tín hiệu cụ thể để phát hiện phiên cần can thiệp: agent hỏi lại điều đã trả lời, mâu thuẫn với quyết định trước, phản hồi chậm dần, hoặc "hallucinate" nội dung file.
- Yêu cầu agent tự tóm tắt trạng thái bằng prompt có cấu trúc rõ ràng (goal, decisions, files, state, TODO, constraints, next step) hiệu quả hơn nhiều so với việc tự tay ghi nhớ thủ công.
- Khi nén lịch sử, giữ lại quyết định cuối cùng, đường dẫn file, TODO mở và ràng buộc; loại bỏ nhánh khám phá thất bại, kế hoạch đã bị thay thế và tool output thô dài dòng.
- Checkpoint chủ động — progress file/handoff note sống, commit incremental, plan file — giúp trạng thái dự án tồn tại độc lập với context window, chống chịu tốt hơn trước sự cố mất phiên.
- Quy trình khôi phục phiên degrade: nhận diện dấu hiệu, yêu cầu tóm tắt, kiểm tra/bổ sung, lưu ra ngoài phiên, seed context mới, xác nhận lại bằng câu hỏi checkpoint.
- Claude Code có auto-compaction, lệnh
/compact, và cơ chế cô lập context qua sub-agent để giảm nhẹ vấn đề — nhưng hiểu nguyên tắc nền tảng vẫn cần thiết để dùng các cơ chế này đúng thời điểm và đúng cách.