Kỹ thuật ngữ cảnh cho tác nhân AI dài hạn

Gộp lại, phân tích của Arize, bài báo arXiv về tràn cửa sổ ngữ cảnh, bài giải thích cho môi trường production của Redis, và so sánh về kỹ thuật harness của Atlan cho thấy một dịch chuyển thực tế trong thiết kế tác nhân. Tác nhân chạy lâu đang được đánh giá ít theo kích thước cửa sổ ngữ cảnh của mô hình hơn, và nhiều hơn theo lớp điều khiển bao quanh nó. Arize làm sự dịch chuyển đó trở nên cụ thể. Họ nêu tên các công cụ tác nhân và hệ thống bộ nhớ/harness đã phát hành, gồm Pi, OpenClaw, Claude Code và Letta, như ví dụ về kỹ thuật ngữ cảnh ở tầng harness, đồng thời mô tả một trình mô phỏng tương tác cho thấy cửa sổ 200K token được lấp đầy.

Các chi tiết công khai trong những nguồn được trích dẫn không đồng đều. Arize đưa ra các con số triển khai cụ thể cho Pi, OpenClaw, Claude Code và Letta. Một bài nghiên cứu về giải quyết tràn cửa sổ ngữ cảnh trong tác nhân AI đưa ra một cơ chế tổng quát hơn để xử lý đầu ra công cụ có thể vượt quá bất kỳ cửa sổ thực tế nào. Bài giải thích của Redis về tràn cửa sổ ngữ cảnh tóm tắt các triệu chứng trong production: lỗi API cứng, chất lượng suy giảm âm thầm, đầu ra công cụ tích tụ, và độ trễ dài hơn khi prompt phình to. So sánh của Atlan về kỹ thuật prompt, ngữ cảnh và harness cung cấp ẩn dụ ngăn xếp hữu ích: kỹ thuật prompt định hình thông điệp, kỹ thuật ngữ cảnh định hình những gì mô hình thấy, và kỹ thuật harness định hình toàn bộ môi trường tác nhân.

Tin quan trọng không phải là cửa sổ ngữ cảnh quá nhỏ. Các nhà xây dựng đã biết điều đó. Điểm hữu ích hơn là những hệ thống tác nhân được trích dẫn đang hội tụ quanh bốn cơ chế harness giúp công việc tiếp tục sống sau khi transcript không còn là nguồn sự thật an toàn.

Một tác nhân nông đọc tệp, gọi công cụ, nối kết quả vào, rồi hy vọng mô hình xử lý được. Một tác nhân ưu tiên harness sẽ chặn hoặc định dạng lại đầu vào lớn trước khi chúng tới mô hình.

Cách đọc rõ ràng hơn cho nhóm giới hạn đầu tiên là:

• Pi: việc đọc tệp dừng ở 2.000 dòng hoặc 50KB, tùy mốc nào đến trước. Nội dung trả về gồm một gợi ý tiếp tục cho mô hình biết khoảng dòng nào đã được hiển thị và cách tiếp tục bằng offset và limit. OpenClaw kế thừa hành vi đó, rồi thêm các giới hạn riêng: tệp bootstrap bị giới hạn ở 12.000 ký tự mỗi tệp và tổng cộng 60.000 ký tự. Kết quả công cụ có một ngân sách khác là 16.000 ký tự hoặc 30% cửa sổ ngữ cảnh, tùy giá trị nào nhỏ hơn.

Claude Code dùng thiết kế hai cổng. Theo Arize, nó kiểm tra giới hạn byte 256KB trước khi mở tệp, rồi đếm token của kết quả so với ngân sách 25.000 token sau khi đọc. Ngay cả với các tệp nằm dưới giới hạn, mặc định nó trả về 2.000 dòng từ đầu và cắt ngắn các dòng dài hơn 2.000 ký tự. Nếu mô hình đọc lại cùng một khoảng trong cùng tệp và tệp chưa thay đổi, Claude Code có thể trả về một stub thay vì lặp lại toàn bộ nội dung.

Đó không chỉ là tối ưu hóa. Nó thay đổi chế độ thất bại. Thay vì để một lần đọc lớn lấn át nhiệm vụ, harness biến “đọc mọi thứ” thành “đọc một lát cắt có kiểm soát”. Nếu mô hình cần thêm, nó có thể yêu cầu. Với các nhà xây dựng đang thiết kế agent harness từ đầu, đây là tuyến phòng thủ đầu tiên: đừng bao giờ để dữ liệu thô bên ngoài mặc định trở thành transcript.

Mẫu tiếp theo là xem ngữ cảnh như một viewport, không phải kho lưu trữ.

Pi và Claude Code cung cấp phân trang thông qua offset và limit. OpenClaw thêm cơ chế cắt phần đầu/đuôi ở một số nơi, giữ phần đầu và cuối khi phần giữa ít có khả năng quan trọng. Arize nói OpenClaw dùng tỷ lệ 75% đầu / 25% đuôi cho các tệp bootstrap quá lớn, và có thể giữ cả đầu lẫn đuôi cho kết quả công cụ khi phần đuôi có vẻ quan trọng, chẳng hạn lỗi, dấu ngoặc đóng JSON hoặc các từ khóa giống phần tóm tắt.

Letta đi xa hơn bằng cách để tệp nằm ngoài prompt. Tệp được tải lên sẽ được phân tích, chia chunk và nhúng vào vector store, cho tác nhân khả năng xem trực tiếp, tìm kiếm chính xác và tìm kiếm ngữ nghĩa. Khi một tệp được mở trong ngữ cảnh, Letta hiển thị một khung xem được quản lý có kích thước tỷ lệ theo ngữ cảnh mô hình: 5.000 ký tự cho ngữ cảnh 8K, 15.000 cho 32K, 25.000 cho 128K, và 40.000 cho 200K+. Số tệp có thể mở đồng thời cũng tỷ lệ theo, từ 3 với mô hình nhỏ đến 15 với mô hình rất lớn, cùng chính sách LRU loại bỏ các tệp được truy cập cách đây lâu nhất.

Đây là cùng ý tưởng thiết kế phía sau RAG trong production: đừng nhồi toàn bộ corpus vào prompt; hãy truy xuất phần quan trọng. Điểm khác biệt là agent harness phải làm việc đó liên tục, xuyên suốt tệp, đầu ra công cụ, bộ nhớ và các kế hoạch trung gian. Cùng ràng buộc đó cũng áp dụng cho hệ thống RAG: truy xuất không chỉ là mức độ liên quan, mà còn là việc giữ đủ ngân sách ngữ cảnh cho bước suy luận thực sự.

Redis đưa ra một điểm liên quan: cửa sổ ngữ cảnh lớn hơn không loại bỏ nhu cầu quản lý ngữ cảnh. System prompt, tài liệu được truy xuất, lịch sử hội thoại và đầu ra công cụ đều cạnh tranh cùng một không gian. Ngay cả trước khi chạm giới hạn cứng, mô hình vẫn có thể suy giảm khi thông tin liên quan bị chôn trong đầu vào dài.

Tràn là thất bại dễ thấy. Mất mục tiêu thì âm thầm hơn. Tác nhân vẫn còn chỗ để phản hồi, nhưng quên mục tiêu ban đầu, bỏ lỡ một ràng buộc, hoặc bắt đầu tối ưu hóa một tác vụ con cục bộ.

Đó là lúc nén gọn trở nên quan trọng. Làm dở, tóm tắt sẽ thay một lịch sử lộn xộn nhưng trung thực bằng một câu chuyện gọn gàng nhưng mất mát. Làm tốt, nó giữ được trạng thái nhiệm vụ, công việc gần đây, các mục đang chờ và tính toàn vẹn của lệnh gọi công cụ.

Arize cho biết Pi kích hoạt nén gọn khi số token ngữ cảnh ước tính vượt quá cửa sổ ngữ cảnh trừ đi token dự trữ, với mức dự trữ mặc định là 16.384 token. Nó giữ khoảng 20.000 token gần nhất và tóm tắt nội dung cũ hơn thành một tin nhắn người dùng tổng hợp được đặt trước phần đuôi được giữ lại. Nó cũng tránh cắt ngang các cặp lệnh gọi công cụ/kết quả công cụ.

OpenClaw thêm một chính sách lịch sử quyết liệt hơn. Khi lịch sử vượt quá 50% cửa sổ ngữ cảnh, nó chia tin nhắn thành các chunk token có khối lượng bằng nhau, bỏ chunk cũ nhất, tóm tắt nội dung bị bỏ qua quá trình tóm tắt nhiều lượt theo giai đoạn, và sửa lại cặp lệnh gọi/kết quả công cụ. Nó cũng thực hiện flush trước nén gọn: một lượt agentic im lặng cho tác nhân cơ hội lưu trạng thái vào tệp bộ nhớ trước khi lịch sử biến mất. Riêng biệt, nó cắt tỉa kết quả công cụ trong bộ nhớ bằng hành vi soft-trim và hard-clear trên TTL bộ nhớ đệm 5 phút.

Claude Code nén gọn gần cuối cửa sổ. Arize nói điểm kích hoạt của nó là cửa sổ ngữ cảnh hiệu dụng trừ đi bộ đệm 13.000 token, đưa việc nén gọn tới khoảng 167K token với mô hình ngữ cảnh 200K. Prompt tóm tắt của nó yêu cầu các phần có cấu trúc bao gồm yêu cầu chính, khái niệm kỹ thuật, tệp và mã, lỗi và bản sửa, giải quyết vấn đề, tin nhắn người dùng, nhiệm vụ đang chờ, công việc hiện tại và bước tiếp theo. Sau khi nén gọn, nó có thể gắn lại tối đa 5 tệp đã đọc gần đây trong phạm vi ngân sách token.

Mẫu ở đây rất rõ: nén gọn không phải là “tóm tắt cuộc trò chuyện”. Nó là checkpoint. Một tác nhân chạy lâu cần thứ tương đương một tệp lưu: mục tiêu, ràng buộc, quyết định, handle đang mở, bằng chứng gần đây và hành động tiếp theo.

Một số đầu ra tuyệt đối không nên được đặt vào cửa sổ ngữ cảnh.

Bài báo arXiv làm điều này cụ thể bằng một quy trình khoa học vật liệu. Một công cụ tạo ra cấu trúc lưới điện tử cho một phân tử: ma trận 3D kích thước 128 × 128 × 128, tổng cộng 2.097.152 phần tử float32. Đầu ra đó vượt xa cửa sổ ngữ cảnh của các LLM được dùng rộng rãi. Nhưng công cụ tiếp theo cần lưới này làm đầu vào.

Giải pháp được đề xuất là lưu các giá trị lớn bên ngoài ngữ cảnh mô hình và trả về các định danh ngắn, hay con trỏ. Tool wrapper kiểm tra đầu vào để xem chúng là giá trị thô hay đường dẫn bộ nhớ. Đầu ra quá lớn được lưu trong bộ nhớ runtime dưới một đường dẫn, và các công cụ sau đó có thể nhận con trỏ rồi tự phân giải nội bộ. Mô hình thao tác với tham chiếu, trong khi harness giữ dữ liệu đầy đủ. Trong một thí nghiệm so sánh mà cả hai phương pháp đều thành công, cách tiếp cận dựa trên con trỏ dùng ít token hơn quy trình truyền thống khoảng bảy lần, theo bài báo.

Đây là sự tách bạch rõ nhất giữa suy luận và vận chuyển dữ liệu. Mô hình không cần “nhìn thấy” một ma trận 2 triệu phần tử để chuyển nó cho công cụ khác. Nó cần biết rằng ma trận tồn tại, nó đại diện cho gì, và thao tác nào nên tiêu thụ nó tiếp theo.

Logic tương tự áp dụng ngoài các mảng khoa học. Phản hồi JSON lớn, PDF, log, embedding, tệp media và bản xuất cơ sở dữ liệu thường nên nằm trong lưu trữ, không phải trong prompt. Với các hệ thống xây quanh công cụ MCP hoặc connector API tùy chỉnh, truyền con trỏ nên là một lựa chọn thiết kế hạng nhất, không phải bản vá sau lần tràn đầu tiên.

Cửa sổ ngữ cảnh 200K token có vẻ lớn cho đến khi một tác nhân bắt đầu hành động. System prompt, định nghĩa công cụ, vài tài liệu được truy xuất, lượt đọc tệp, log, dấu vết lỗi và tóm tắt có thể tiêu thụ nó nhanh hơn dự kiến. Khung nhìn thực tế không phải là cửa sổ trông lớn thế nào trên giấy, mà là tác nhân tiêu nó nhanh ra sao ở runtime. Hướng dẫn của Redis về bộ nhớ tác nhân hướng tới bộ nhớ bên ngoài, bền vững cho trạng thái cần tồn tại qua nhiều lệnh gọi, trong khi cách đóng khung kỹ thuật ngữ cảnh của Atlan tách prompt tốt hơn khỏi lắp ráp ngữ cảnh tốt hơn. Kết hợp lại, chúng xem cửa sổ ngữ cảnh ít giống nhà kho hơn và giống một working set bị ràng buộc hơn.

Bài học sâu hơn là cửa sổ ngữ cảnh là một tài nguyên runtime khan hiếm. Xem nó là “bộ nhớ” thì hữu ích, nhưng chỉ khi harness hành xử như một hệ điều hành: cấp phát, loại bỏ, phân trang, nén gọn, khử trùng lặp và lưu bền vững. Phân biệt tầng của Atlan hữu ích ở đây. Kỹ thuật prompt không thể sửa một trình đọc tệp đổ 80.000 token không liên quan vào lệnh gọi tiếp theo. Kỹ thuật ngữ cảnh có thể cải thiện working set. Kỹ thuật harness quyết định ngay từ đầu working set đó có được bảo vệ hay không.

Điều này cũng thay đổi cách các đội nên đánh giá tác nhân. Một prompt demo là chưa đủ. Đánh giá dài hạn nên bao gồm transcript ngày càng dài, đọc lại tệp nhiều lần, đầu ra công cụ lớn, lệnh gọi công cụ thất bại, tiếp tục sau nén gọn, và các nhiệm vụ mà bước tiếp theo đúng phụ thuộc vào một ràng buộc xuất hiện sớm. Hướng dẫn của chúng tôi về kỹ thuật ngữ cảnh cho tác nhân bao quát phiên bản phía mô hình của vấn đề đó; tầng harness là nơi nó trở thành vận hành thực tế.

Đầu tiên, đặt ngân sách cho mọi nguồn ngữ cảnh. Tệp, đầu ra công cụ, chunk được truy xuất, mục chèn vào bộ nhớ và lịch sử hội thoại đều nên có giới hạn rõ ràng. Một giới hạn token tối đa toàn cục duy nhất là quá thô.

Thứ hai, hãy làm cho việc cắt ngắn có thể hành động được. Nếu harness cắt nội dung, mô hình nên biết nó đã thấy khoảng nào và cách yêu cầu thêm. Cắt ngắn âm thầm còn tệ hơn từ chối, vì nó tạo ra công việc đầy tự tin trên dữ liệu bị thiếu.

Thứ ba, nén gọn quanh trạng thái, không phải văn xuôi. Tóm tắt nên giữ mục tiêu của người dùng, ràng buộc, quyết định, nhiệm vụ đang chờ, tệp đã chạm tới, kết quả công cụ quan trọng và bước tiếp theo ngay lập tức. Các cặp lệnh gọi công cụ nên được giữ nguyên vẹn.

Thứ tư, đưa các giá trị lớn ra khỏi prompt. Lưu chúng, đặt tên cho chúng và truyền con trỏ qua các công cụ. Điều này đặc biệt quan trọng với tác nhân gọi API, xử lý tài liệu hoặc điều phối hệ thống đa tác nhân.

Cuối cùng, hãy kiểm thử mất mục tiêu tách biệt với tràn. Một tác nhân có thể vẫn nằm dưới cửa sổ cứng mà vẫn trôi hướng. Câu hỏi đúng không chỉ là “API có chấp nhận prompt không?” Mà là “hành động tiếp theo có còn phục vụ nhiệm vụ ban đầu không?”

Phần tóm tắt dưới đây biến các mẫu đó thành một checklist nhanh trước FAQ.

• Tác nhân dài hạn thất bại qua cả tràn ngữ cảnh và mất mục tiêu, nên harness phải quản lý nhiều hơn độ dài prompt.
• Hệ thống tác nhân production dùng ngân sách cứng cho tệp, đầu ra công cụ và lịch sử trước khi dữ liệu thô tới mô hình.
• Phân trang, tìm kiếm và khung xem được quản lý xem ngữ cảnh như một viewport giới hạn thay vì lưu trữ vĩnh viễn.
• Nén gọn hiệu quả nhất khi là checkpoint: nó giữ mục tiêu, ràng buộc, quyết định, công việc đang chờ và tính toàn vẹn của lệnh gọi công cụ.
• Đầu ra công cụ lớn thường nên nằm trong lưu trữ bên ngoài, với con trỏ ngắn được truyền giữa các công cụ thay vì đưa toàn bộ giá trị vào prompt.

Phần này trả lời các câu hỏi thực tế phía sau kỹ thuật ngữ cảnh cho tác nhân dài hạn: cái gì bị tràn, mục tiêu bị mất như thế nào, và mẫu harness nào giữ công việc đi đúng hướng.

Tràn ngữ cảnh xảy ra khi prompt, lịch sử, dữ liệu được truy xuất, tệp và đầu ra công cụ tích lũy của tác nhân vượt quá cửa sổ ngữ cảnh có thể dùng của mô hình hoặc làm suy giảm chất lượng trước khi đạt giới hạn cứng.

Mất mục tiêu xảy ra khi nhiệm vụ ban đầu vẫn hiện diện đâu đó trong transcript nhưng không còn dẫn dắt hành động tiếp theo của tác nhân, thường sau lịch sử dài hoặc tóm tắt kém.

Chúng đặt ngân sách theo từng nguồn, phân trang lượt đọc tệp, chỉ truy xuất khung xem liên quan, nén gọn lịch sử quanh trạng thái, khử trùng lặp các lượt đọc lặp lại và lưu đầu ra lớn bên ngoài prompt.

Con trỏ cho phép mô hình tham chiếu tới các giá trị lớn được lưu trong bộ nhớ runtime, như ma trận, log hoặc PDF, trong khi công cụ downstream phân giải dữ liệu đầy đủ mà không đặt nó vào cửa sổ ngữ cảnh.

Không. Cửa sổ lớn hơn có ích, nhưng system prompt, định nghĩa công cụ, tài liệu được truy xuất, log và lịch sử vẫn cạnh tranh không gian, và thông tin liên quan vẫn có thể bị chôn vùi trước khi chạm giới hạn cứng.