Các tác nhân ngữ cảnh dài đã có khả năng tóm tắt.
Điều này hữu ích.
Đây không phải là bộ nhớ.
Tính năng tự động nén tích hợp giúp Claude Code, Codex, Cursor, Windsurf hoặc một tác nhân lập trình khác tồn tại trong một phiên làm việc dài. Tuy nhiên, quy trình làm việc nhóm cần một thứ chặt chẽ hơn là "cuộc trò chuyện đã được tóm tắt".
Nó cần trạng thái hoạt động có thể di chuyển được.
Đó là sự khác biệt mà tôi luôn quay trở lại khi làm việc trên một ngăn xếp kinh tế token MCP cục bộ: nén giữ cho một cuộc trò chuyện tồn tại; chuyển giao cho phép một không gian làm việc tiếp tục.
Những gì tính năng tự động nén tích hợp làm tốt
Tự động nén tốt trong việc giảm ngữ cảnh thô của một sản phẩm.
Các tác nhân có ngữ cảnh dài đã có khả năng tóm tắt.
Điều này hữu ích.
Đây không phải là bộ nhớ.
Tính năng tự động nén tích hợp giúp Claude Code, Codex, Cursor, Windsurf hoặc một tác nhân lập trình khác tồn tại trong một phiên làm việc dài. Tuy nhiên, quy trình làm việc nhóm cần một thứ chặt chẽ hơn là "cuộc trò chuyện đã được tóm tắt".
Nó cần trạng thái hoạt động có thể di chuyển được.
Đó là sự khác biệt mà tôi luôn quay lại khi làm việc với ngăn xếp kinh tế mã thông báo MCP cục bộ: nén giữ cho một cuộc trò chuyện tồn tại; chuyển giao cho phép một không gian làm việc tiếp tục.
**Những gì tính năng tự động nén tích hợp làm tốt**
Tự động nén rất tốt trong việc giảm ngữ cảnh thô của một phiên sản phẩm khi cửa sổ quá đầy.
Đối với một tác nhân duy nhất trong một cuộc trò chuyện duy nhất, điều đó có thể là đủ:
* giữ mục tiêu chung;
* nén các cuộc thảo luận trước đó;
* giữ cho mô hình hoạt động;
* tránh buộc người dùng phải bắt đầu lại từ đầu.
Đó là giá trị thực.
Vấn đề xuất hiện khi công việc không còn chỉ là một cuộc trò chuyện.
Trong một kho lưu trữ thực tế, cùng một tác vụ có thể di chuyển giữa Claude Code, Codex, Cursor, Windsurf, một máy Mac Mini từ xa, các công cụ MCP, cổng CI và đánh giá của con người. Tại thời điểm đó, một bản tóm tắt tường thuật không giống như một hợp đồng hoạt động.
**Những gì tính năng tự động nén thường mất đi**
Các chi tiết quan trọng nhất thường ít có hình dạng tóm tắt nhất:
* những phê duyệt nào thực sự được cấp;
* những tệp hoặc dịch vụ nào bị cấm;
* những giá trị chính xác nào không được thay đổi;
* những nguồn nào được tin cậy, bán tin cậy hoặc không tin cậy;
* những lỗi nào đã được thử và sửa;
* những lệnh nào đã được thông qua;
* những kiểm tra nào vẫn đang chờ xử lý;
* những gì tác nhân tiếp theo không được làm lại.
Đó không chỉ là "ngữ cảnh".
Chúng là trạng thái mặt phẳng điều khiển.
Nếu trạng thái đó biến mất trong quá trình nén, tác nhân tiếp theo có thể tự tin trong khi âm thầm mở lại các rủi ro mà tác nhân trước đó đã đóng.
**Lớp bị thiếu: MCP chuyển giao cục bộ**
Cơ chế tôi muốn là một MCP chuyển giao cục bộ ghi lại một bản chuyển giao có cấu trúc trước khi cửa sổ đầy.
Mục đích không phải là tạo ra một bản tóm tắt đẹp hơn.
Mục đích là tạo ra một hợp đồng tiếp tục mà một tác nhân khác có thể sử dụng an toàn.
Một bản chuyển giao tối thiểu nên giữ lại:
* mục tiêu và điều kiện hoàn thành;
* hướng dẫn và ràng buộc đã tải;
* trạng thái phê duyệt;
* các giá trị chính xác không được thay đổi;
* rủi ro và cờ đỏ;
* các hành động đã thực hiện;
* lỗi và sửa lỗi;
* xác minh đang chờ xử lý;
* bước tiếp theo được đề xuất;
* những gì không được làm lại.
Hợp đồng đó nên nằm trong không gian làm việc, không chỉ bên trong bộ nhớ trò chuyện riêng tư của sản phẩm.
**Tự động nén so với chuyển giao cục bộ**
Sự khác biệt về thời gian rất quan trọng.
Tự động nén thường xảy ra sau khi áp lực ngữ cảnh đã cao. Một giao thức chuyển giao có thể chấm điểm trước phiên sớm hơn và quyết định xem quá trình chuyển đổi tiếp theo có cần một bản tóm tắt bình thường, một bản chuyển giao cờ đỏ hay một điểm dừng cứng để xem xét của con người hay không.
**Tại sao cửa sổ ngữ cảnh 1 triệu không loại bỏ nhu cầu**
Một cửa sổ ngữ cảnh lớn hơn rất có giá trị.
Tôi muốn nó. Tôi sẽ sử dụng nó.
Nó cho phép tác nhân giữ nhiều mã, nhật ký, tài liệu nguồn và lý do trước đó có sẵn trước khi cần nén.
Nhưng một cửa sổ lớn hơn chủ yếu trì hoãn chế độ lỗi. Nó không tự động làm cho trạng thái có thể di chuyển được, đáng tin cậy, có thể kiểm toán hoặc được chia sẻ giữa các sản phẩm.
Một triệu mã thông báo vẫn có thể chứa:
* các phê duyệt cũ;
* bí mật bị chôn vùi;
* hướng dẫn mâu thuẫn;
* chẩn đoán lỗi thời;
* các lần thử thất bại lặp đi lặp lại;
* sự tin cậy nguồn không được gắn nhãn;
* không có bước tiếp theo rõ ràng.
Nhiều không gian hơn không giống như quản lý trạng thái tốt hơn.
**Một hợp đồng chuyển giao đơn giản**
Đây là hình dạng mà tôi muốn các tác nhân tạo ra tại các điểm chuyển đổi thực tế:
## Mục tiêu
Nội dung cần hoàn thành.
## Điều kiện hoàn thành
Trạng thái quan sát được chính xác cho thấy nhiệm vụ đã hoàn thành.
## Ràng buộc
Các quy tắc kho lưu trữ đã tải, ràng buộc người dùng, giới hạn rủi ro và nhãn tin cậy.
## Trạng thái phê duyệt
Nội dung người dùng đã phê duyệt, nội dung chưa được phê duyệt và nội dung yêu cầu kiểm tra.
## Các hành động đã thực hiện
Các lệnh, chỉnh sửa, triển khai, xuất bản bên ngoài hoặc các lệnh gọi công cụ đã hoàn thành.
## Xác minh
Các kiểm tra đã đạt, các kiểm tra đã thất bại và các kiểm tra vẫn đang chờ xử lý.
## Cảnh báo
Các bí mật, hoạt động trực tiếp, lệnh phá hủy, quyền sở hữu không rõ ràng hoặc các vòng lặp lỗi tương tự.
## Bước tiếp theo
Hành động tiếp theo được khuyến nghị cho một tác nhân mới.
## Không làm lại
Công việc đã hoàn thành hoặc các phương án đã bị loại trừ.
Nội dung này được trình bày một cách khô khan có chủ đích.
Việc bàn giao tốt không nhằm mục đích thông minh. Nó nhằm mục đích khó bị hiểu sai.
Chúng ta có thể đo lường được gì
Câu hỏi hữu ích không phải là "bản tóm tắt có đẹp không?".
Câu hỏi hữu ích là liệu tác nhân tiếp theo có thể tiếp tục với ít lãng phí và ít sai sót hơn hay không.
Tôi sẽ đo lường:
Thành công khi tiếp tục: liệu một tác nhân mới có thể thực hiện bước tiếp theo chỉ từ việc bàn giao hay không?
Tỷ lệ đọc lại: tác nhân cần mở lại các tệp cũ hoặc ngữ cảnh trò chuyện cũ bao nhiêu lần?
Ước tính token: bao nhiêu ngữ cảnh đã được tránh trong quá trình tiếp tục?
Tỷ lệ rò rỉ: liệu các bí mật, chi tiết triển khai riêng tư hoặc các sự kiện ngoài giới hạn có lọt vào quá trình bàn giao hay không?
Bảo toàn phê duyệt: liệu tác nhân được tiếp tục có giữ lại ranh giới quyền chính xác hay không?
Tỷ lệ làm lại: liệu tác nhân có lặp lại công việc đã hoàn thành hay không?
Đây là lúc góc độ kinh tế token của MCP trở nên thực tế. Vấn đề không chỉ là ít token hơn. Vấn đề là ít vòng lặp phục hồi không an toàn hoặc lãng phí hơn.
Những trường hợp hữu ích
Mô hình này hữu ích khi:
một phiên mã hóa đang tiếp cận áp lực ngữ cảnh;
một nhiệm vụ đang chuyển từ Claude Code sang Codex hoặc Cursor;
một tác nhân cục bộ bàn giao công việc cho một máy từ xa;
một quy trình làm việc MCP nền cần tiếp tục sau đó;
công việc liên quan đến triển khai trực tiếp, thông tin xác thực, xuất bản hoặc phê duyệt;
lớp lỗi tương tự đã xuất hiện hai lần.
Trong những trường hợp đó, "cuộc trò chuyện sẽ tự tóm tắt" là không đủ quy trình.
Bài học thực tế
Sử dụng tính năng tự động nén.
Sử dụng các cửa sổ ngữ cảnh lớn hơn khi có sẵn.
Nhưng đừng nhầm lẫn cả hai với bộ nhớ.
Bộ nhớ cho kỹ thuật tác nhân không chỉ là ghi nhớ những gì đã nói. Đó là bảo toàn trạng thái hoạt động cho phép tác nhân tiếp theo tiếp tục một cách an toàn.
Tự động nén giúp một cuộc trò chuyện tồn tại.
Bàn giao giúp một không gian làm việc tiếp tục.
Nguồn
Kinh tế token của ngăn xếp MCP — phép đo cục bộ
Nguồn tin: Dev.to AI — Tác giả: Gregory Shevchenko. Bản dịch tiếng Việt do AI thực hiện, có thể có sai sót.