Trong các cuộc trao đổi gần đây với người dùng Claude Code, một chủ đề liên tục xuất hiện: cửa sổ ngữ cảnh 1 triệu token giống như một con dao hai lưỡi.
Nó cho phép Claude Code hoạt động tự động lâu hơn và xử lý tác vụ đáng tin cậy hơn, nhưng nó cũng mở ra cánh cửa cho sự ô nhiễm ngữ cảnh nếu bạn không cẩn thận trong việc quản lý các phiên làm việc của mình.
Quản lý phiên làm việc giờ đây quan trọng hơn bao giờ hết và dường như có rất nhiều câu hỏi xoay quanh nó. Bạn có nên giữ một phiên mở trong terminal, hay hai? Bắt đầu lại từ đầu với mỗi prompt? Khi nào nên sử dụng compact, rewind, hay subagent? Điều gì gây ra một lần compact tồi?
Có một lượng chi tiết đáng ngạc nhiên ở đây có thể thực sự định hình trải nghiệm của bạn với Claude Code và hầu như tất cả đều đến từ việc quản lý cửa sổ ngữ cảnh của bạn.
Sơ Lược Nhanh Về Ngữ Cảnh, Nén (Compaction) & Suy Thoái Ngữ Cảnh (Context Rot)
Cửa sổ ngữ cảnh là tất cả những gì mô hình có thể "thấy" cùng một lúc khi tạo ra phản hồi tiếp theo. Nó bao gồm system prompt của bạn, toàn bộ cuộc hội thoại cho đến nay, mọi lệnh gọi công cụ và kết quả đầu ra của nó, và mọi tệp đã được đọc. Claude Code có một cửa sổ ngữ cảnh là một triệu token.
Thật không may, việc sử dụng ngữ cảnh có một chi phí nhỏ, thường được gọi là suy thoái ngữ cảnh (context rot). Suy thoái ngữ cảnh là hiện tượng hiệu suất mô hình giảm sút khi ngữ cảnh phát triển vì sự chú ý bị phân tán trên nhiều token hơn, và nội dung cũ hơn, không liên quan bắt đầu làm xao nhãng khỏi tác vụ hiện tại. Đối với mô hình ngữ cảnh 1MM của chúng tôi, chúng tôi thấy một số mức độ suy thoái ngữ cảnh xảy ra vào khoảng ~300-400k token, nhưng điều này phụ thuộc rất nhiều vào tác vụ - không phải là một quy tắc cứng nhắc.
Cửa sổ ngữ cảnh có một giới hạn cứng, vì vậy khi bạn sắp đến cuối cửa sổ ngữ cảnh, bạn sẽ cần tóm tắt tác vụ bạn đang thực hiện thành một mô tả nhỏ hơn và tiếp tục công việc trong một cửa sổ ngữ cảnh mới, chúng tôi gọi đây là nén (compaction). Bạn cũng có thể tự kích hoạt nén.
Mỗi Lượt Là Một Điểm Rẽ Nhánh
Giả sử bạn vừa yêu cầu Claude làm điều gì đó và nó đã hoàn thành, lúc này bạn đã có một số thông tin trong ngữ cảnh của mình (các lệnh gọi công cụ, kết quả đầu ra của công cụ, hướng dẫn của bạn) và bạn có một số lượng đáng ngạc nhiên các lựa chọn cho việc nên làm tiếp theo:
- Tiếp tục (Continue) — gửi một tin nhắn khác trong cùng phiên làm việc
- /rewind (esc esc) — quay lại một tin nhắn trước đó và thử lại từ đó
- /clear — bắt đầu một phiên làm việc mới, thường là với một bản tóm tắt ngắn gọn bạn đã chắt lọc từ những gì bạn vừa học được
- Nén (Compact) — tóm tắt toàn bộ phiên làm việc cho đến nay và tiếp tục dựa trên bản tóm tắt đó
- Subagent — ủy thác phần công việc tiếp theo cho một agent với ngữ cảnh sạch riêng của nó, và chỉ kéo kết quả của nó trở lại
Trong khi lựa chọn tự nhiên nhất chỉ là tiếp tục, bốn lựa chọn còn lại tồn tại để giúp bạn quản lý ngữ cảnh của mình.
Khi Nào Nên Bắt Đầu Một Phiên Làm Việc Mới
Cửa sổ ngữ cảnh 1M mới có nghĩa là giờ đây bạn có thể thực hiện các tác vụ dài hơn một cách đáng tin cậy hơn, ví dụ như yêu cầu nó xây dựng một ứng dụng full-stack từ đầu. Nhưng chỉ vì mô hình của bạn chưa hết ngữ cảnh, không có nghĩa là bạn không nên bắt đầu một phiên làm việc mới.
Nguyên tắc chung của chúng tôi là khi bạn bắt đầu một tác vụ mới, bạn cũng nên bắt đầu một phiên làm việc mới.
Một vùng xám là khi bạn có thể muốn thực hiện các tác vụ liên quan, nơi một phần ngữ cảnh vẫn cần thiết, nhưng không phải tất cả.
Ví dụ, viết tài liệu cho một tính năng bạn vừa triển khai. Mặc dù bạn có thể bắt đầu một phiên mới, nhưng Claude sẽ phải đọc lại các tệp bạn vừa triển khai, điều này sẽ chậm hơn và tốn kém hơn. Vì viết tài liệu có thể không phải là một tác vụ đòi hỏi độ nhạy thông minh cao, nên ngữ cảnh bổ sung có lẽ đáng đánh đổi để lấy hiệu quả tăng lên nhờ không phải đọc lại các tệp liên quan.
Quay Lại (Rewind) Thay Vì Sửa Lỗi
Nếu tôi phải chọn một thói quen báo hiệu việc quản lý ngữ cảnh tốt, đó là quay lại (rewind).
Trong Claude Code, nhấn đúp Esc (hoặc chạy /rewind) cho phép bạn nhảy trở lại bất kỳ tin nhắn nào trước đó và đưa ra prompt mới từ đó. Các tin nhắn sau điểm đó sẽ bị loại bỏ khỏi ngữ cảnh.
Quay lại thường là cách tiếp cận tốt hơn cho việc sửa lỗi. Ví dụ, Claude đọc năm tệp, thử một cách tiếp cận, và nó không hoạt động. Bản năng của bạn có thể là gõ "cái đó không hiệu quả, thử X đi." nhưng hành động tốt hơn là quay lại ngay sau khi đọc tệp, và đưa ra prompt mới với những gì bạn đã học được. "Đừng dùng cách tiếp cận A, module foo không expose cái đó — hãy đi thẳng đến B."
Bạn cũng có thể sử dụng "tóm tắt từ đây" để yêu cầu Claude tóm tắt những gì nó đã học và tạo một tin nhắn bàn giao, giống như một tin nhắn từ phiên bản Claude trước đó gửi đến phiên bản tương lai của chính nó, người đã thử một điều gì đó và nó không hiệu quả.
Nén (Compacting) so với Phiên Làm Việc Mới
Khi một phiên làm việc trở nên dài, bạn có hai cách để giảm tải: /compact hoặc /clear (và bắt đầu lại từ đầu). Chúng có vẻ giống nhau nhưng hoạt động rất khác biệt.
Compact yêu cầu mô hình tóm tắt toàn bộ cuộc hội thoại cho đến nay, sau đó thay thế lịch sử bằng bản tóm tắt đó. Nó có mất mát thông tin, bạn đang tin tưởng Claude quyết định điều gì quan trọng, nhưng bạn không phải tự viết gì cả và Claude có thể kỹ lưỡng hơn trong việc bao gồm các bài học hoặc tệp quan trọng. Bạn cũng có thể định hướng nó bằng cách truyền hướng dẫn (/compact tập trung vào việc tái cấu trúc auth, bỏ qua việc gỡ lỗi test).
Với /clear, *bạn* tự viết ra những gì quan trọng ("chúng ta đang tái cấu trúc auth middleware, ràng buộc là X, các tệp quan trọng là A và B, chúng ta đã loại trừ cách tiếp cận Y") và bắt đầu lại từ đầu. Nó tốn nhiều công sức hơn, nhưng ngữ cảnh kết quả là những gì bạn đã quyết định là có liên quan.
Điều Gì Gây Ra Một Lần Nén (Compact) Tồi?
Nếu bạn chạy nhiều phiên làm việc dài, bạn có thể đã nhận thấy những lúc việc nén có thể đặc biệt tồi tệ. Trong trường hợp này, chúng tôi thường thấy rằng các lần nén tồi có thể xảy ra khi mô hình không thể dự đoán hướng đi của công việc bạn.
Ví dụ, tính năng tự động nén (autocompact) kích hoạt sau một phiên gỡ lỗi dài và tóm tắt quá trình điều tra, và tin nhắn tiếp theo của bạn là "bây giờ hãy sửa cảnh báo khác mà chúng ta đã thấy trong bar.ts."
Nhưng vì phiên làm việc tập trung vào gỡ lỗi, cảnh báo khác đó có thể đã bị loại bỏ khỏi bản tóm tắt.
Điều này đặc biệt khó khăn, bởi vì do suy thoái ngữ cảnh, mô hình đang ở điểm kém thông minh nhất khi nén. Với một triệu ngữ cảnh, bạn có nhiều thời gian hơn để chủ động /compact với một mô tả về những gì bạn muốn làm.
Subagent & Cửa Sổ Ngữ Cảnh Mới
Subagent là một hình thức quản lý ngữ cảnh, hữu ích khi bạn biết trước rằng một phần công việc sẽ tạo ra nhiều kết quả đầu ra trung gian mà bạn sẽ không cần lại.
Khi Claude tạo ra một subagent thông qua công cụ Agent, subagent đó sẽ có cửa sổ ngữ cảnh mới của riêng nó. Nó có thể thực hiện nhiều công việc cần thiết, và sau đó tổng hợp kết quả của nó để chỉ báo cáo cuối cùng được trả về cho agent cha.
Bài kiểm tra tinh thần chúng tôi sử dụng: tôi có cần kết quả đầu ra của công cụ này một lần nữa không, hay chỉ cần kết luận?
Mặc dù Claude Code sẽ tự động gọi subagent, bạn có thể muốn yêu cầu nó làm điều này một cách rõ ràng. Ví dụ, bạn có thể muốn yêu cầu nó:
- "Tạo một subagent để xác minh kết quả của công việc này dựa trên tệp spec sau"
- "Tách ra một subagent để đọc qua codebase khác này và tóm tắt cách nó triển khai luồng auth, sau đó tự bạn triển khai nó theo cách tương tự"
- "Tách ra một subagent để viết tài liệu về tính năng này dựa trên các thay đổi git của tôi"
Tổng Kết
Tóm lại, khi Claude đã kết thúc một lượt và bạn sắp gửi một tin nhắn mới, bạn có một điểm quyết định.
Theo thời gian, chúng tôi hy vọng rằng Claude sẽ tự giúp bạn xử lý việc này, nhưng hiện tại, đây là một trong những cách bạn có thể định hướng đầu ra của Claude.
