Tác nhân AI của bạn hoạt động rất tốt trong 10 bước đầu tiên.
Rồi đến khoảng bước thứ 15, nó bắt đầu trở nên cẩu thả.
Gọi sai công cụ. Quên mất hướng dẫn ban đầu của bạn. Đầu ra chất lượng thấp.
Hầu hết mọi người đều đổ lỗi cho mô hình.
Hầu như không bao giờ là lỗi của mô hình.
Đó là những gì mô hình đang thấy.
Việc tổ chức những gì mô hình thấy được gọi là kỹ thuật quản lý ngữ cảnh (context engineering).
Nó đang nhanh chóng trở thành kỹ năng quan trọng nhất cho bất kỳ ai xây dựng tác nhân AI.
Đây là toàn bộ cẩm nang.
Kỹ thuật tạo prompt (prompt engineering) đã chết. Kỹ thuật quản lý ngữ cảnh (context engineering) mới là thứ quan trọng bây giờ.
Bạn đã từng nghe đến kỹ thuật tạo prompt (prompt engineering).
Viết hướng dẫn rõ ràng. Đưa ra các ví dụ tốt. Bảo mô hình đóng vai trò gì.
Điều đó hoạt động hoàn hảo cho một chatbot.
Nó ngừng hoạt động ngay khi bạn xây dựng một tác nhân.
Đây là lý do.
Một chatbot trả lời một câu hỏi và dừng lại.
Một tác nhân thực hiện các hành động — duyệt web, gọi API, viết mã, chạy lệnh — hết bước này đến bước khác, đôi khi qua hàng chục bước.
Mỗi bước đều tạo ra đầu ra được thêm vào ngữ cảnh của mô hình.
Và ngữ cảnh đó có giới hạn.
Đội ngũ kỹ thuật của Anthropic định nghĩa nó như sau:
"Ngữ cảnh là tập hợp các token được bao gồm khi bạn lấy mẫu từ một LLM. Kỹ thuật quản lý ngữ cảnh là tối ưu hóa tiện ích của các token đó để luôn đạt được kết quả mong muốn."
Nói một cách đơn giản: hãy đảm bảo tác nhân của bạn nhìn thấy thông tin phù hợp, ở định dạng phù hợp, vào đúng thời điểm.
Kỹ thuật tạo prompt (Prompt engineering) là một tập con của kỹ thuật quản lý ngữ cảnh.
Kỹ thuật quản lý ngữ cảnh (Context engineering) là tất cả.
Cửa sổ ngữ cảnh của tác nhân là RAM. Và nó đang đầy dần.
LangChain có một phép so sánh đúng cho điều này.
Hãy nghĩ về một LLM như một loại hệ điều hành mới.
Mô hình là CPU — nó thực hiện việc suy nghĩ.
Cửa sổ ngữ cảnh là RAM — bộ nhớ làm việc nơi mọi thứ mô hình hiện có thể thấy và suy luận đều tồn tại.
Cũng giống như máy tính của bạn chậm lại khi RAM đầy, khả năng suy luận của tác nhân cũng suy giảm khi cửa sổ ngữ cảnh trở nên quá tải.
Điều này được gọi là sự suy giảm ngữ cảnh (context rot).
Chroma đã thực hiện một nghiên cứu đánh giá 18 mô hình hàng đầu — GPT-4.1, Claude 4, Gemini 2.5, Qwen3, và các mô hình khác.
Hiệu suất của mọi mô hình đều giảm khi độ dài đầu vào tăng lên.
Không phải ở giới hạn cứng. Mà là trước đó rất xa.
Một mô hình với cửa sổ 200K token có thể cho thấy sự suy giảm đáng kể ở 50K token.
Sự suy giảm diễn ra liên tục. Không phải là một vách đá.
Tại sao? Transformers hoạt động bằng cách cho mọi token chú ý đến mọi token khác — tạo ra các mối quan hệ n-bình phương. Khi ngữ cảnh phát triển, khả năng nắm giữ tất cả các mối quan hệ đó của mô hình bị suy yếu.
Và sau đó là vấn đề "Lạc lõng ở giữa" (Lost in the Middle).
LLM cho thấy một đường cong chú ý hình chữ U.
→ Đầu ngữ cảnh: được nhớ tốt
→ Cuối ngữ cảnh: được nhớ tốt
→ Ở giữa: phần lớn bị bỏ qua
Các nhà nghiên cứu đã đo lường mức giảm độ chính xác hơn 30 điểm phần trăm khi thông tin liên quan được chuyển từ đầu ngữ cảnh vào giữa.
Các hướng dẫn ban đầu của bạn — bị chôn vùi dưới 50.000 token đầu ra của công cụ — thực sự biến mất.
Người dùng Claude Code đã phát hiện ra chất lượng đầu ra giảm ở mức 40–60% dung lượng ngữ cảnh. Trước bất kỳ giới hạn cứng nào.
Những gì thực sự đang cạnh tranh không gian trong ngữ cảnh tác nhân của bạn
7 loại. Tất cả đều chiến đấu cho cùng một cửa sổ hữu hạn.
1. Prompt Hệ thống
Bản sắc của tác nhân. Các quy tắc hành vi. Logic luồng điều khiển. Hướng dẫn cho các loại nhiệm vụ khác nhau. Trong một tác nhân, cái này không chỉ là "hãy hữu ích." Nó có thể định nghĩa toàn bộ kiến trúc.
2. Định nghĩa Công cụ
Mọi công cụ mà tác nhân có thể gọi đều cần một lược đồ mô tả nó làm gì, nó nhận tham số nào và khi nào sử dụng nó.
3. Kết quả Gọi Công cụ
Mọi lệnh gọi công cụ đều thêm đầu ra của nó vào ngữ cảnh. Một lần truy xuất trang web: 5.000–10.000 token. Một lần đọc tệp: tương tự. Những thứ này tích lũy nhanh chóng.
4. Kiến thức được Truy xuất (RAG)
Các tài liệu được lấy từ cơ sở dữ liệu vector, kết quả tìm kiếm, phản hồi API — bất cứ thứ gì được truy xuất để cung cấp thông tin cho các quyết định của tác nhân.
5. Lịch sử Trò chuyện
Bản ghi đầy đủ của mọi thứ đã xảy ra. Tin nhắn người dùng, phản hồi của tác nhân, suy luận, các quyết định trước đó. Phát triển tuyến tính theo mỗi lượt.
6. Bộ nhớ
Bộ nhớ ngắn hạn từ phiên hiện tại. Bộ nhớ dài hạn từ các phiên trước — sở thích người dùng, kết quả trước đó, các mẫu đã học.
7. Trạng thái Tác nhân
Kế hoạch hiện tại, danh sách việc cần làm, điểm đánh dấu tiến độ, ghi chú nháp. Thông tin siêu dữ liệu theo dõi vị trí của tác nhân trong một nhiệm vụ nhiều bước.
Tất cả 7 loại cạnh tranh cho cùng một cửa sổ.
Kỹ thuật quản lý ngữ cảnh là quyết định cái gì thắng cuộc.
4 Chiến lược Cốt lõi
LangChain đã xuất bản khuôn khổ tổ chức mọi kỹ thuật quản lý ngữ cảnh thành 4 nhóm.
Mọi kỹ thuật bạn từng học sẽ nằm gọn trong một trong số này.
Ghi lại (Write). Chọn lọc (Select). Nén (Compress). Cô lập (Isolate).
Chiến lược 1 — Ghi lại (Write) (Tác nhân hay quên. Hãy cho chúng cách để ghi nhớ.)
Khi ngữ cảnh của tác nhân đầy lên và bị nén lại, nó sẽ mất thông tin.
Nếu tác nhân không ghi lại bất cứ điều gì trước khi điều đó xảy ra — thông tin đó sẽ mất vĩnh viễn.
Ghi lại (Write) có nghĩa là cung cấp cho tác nhân những cách để lưu giữ thông tin bên ngoài cửa sổ ngữ cảnh.
Ba hình thức:
Bảng nháp (Scratchpads)
Cung cấp cho tác nhân một công cụ cho phép nó ghi chú trong suốt một nhiệm vụ. Các phát hiện trung gian. Các quyết định đã đưa ra. Thông tin nó biết mình sẽ cần sau.
Anthropic đã xây dựng một công cụ "suy nghĩ" — một không gian chuyên dụng để Claude giải quyết vấn đề.
Trên điểm chuẩn tau-bench, điều này đã cải thiện hiệu suất lên đến 54% trong một số nhiệm vụ nhất định.
Tệp Quy tắc (Rules Files)
Bộ nhớ thủ tục bền vững.
Nếu bạn đã sử dụng Claude Code, bạn đã thấy CLAUDE.md.
Các hướng dẫn được tải ở đầu mỗi phiên — kiến trúc dự án, quy ước, cách chạy thử nghiệm, những điều cần cẩn thận.
Tác nhân đọc nó mỗi khi nó bắt đầu.
Nó không bao giờ quên những điều cơ bản.
Trích xuất Bộ nhớ (Memory Extraction)
Tác nhân lưu các sự kiện, sở thích của người dùng và các mẫu đã học để có thể truy xuất chúng qua các phiên.
Tồn tại hoàn toàn bên ngoài cửa sổ ngữ cảnh.
Thông tin tác nhân cần cho ngày mai đã ở đó chờ sẵn khi ngày mai đến.
Chiến lược 2 — Chọn lọc (Select) (Đừng đưa cho tác nhân mọi thứ. Hãy đưa cho nó những gì nó cần ngay bây giờ.)
Một tác nhân với 40 công cụ, một cơ sở kiến thức lớn và vài phiên lịch sử không thể tải tất cả cùng một lúc.
Một cái gì đó phải quyết định cái gì có liên quan cho bước này.
RAG truyền thống: hệ thống quyết định.
Người dùng hỏi → truy xuất tài liệu → nhồi nhét vào prompt → xong.
Tĩnh. Một lần. Mô hình không có tiếng nói.
RAG tác nhân (Agentic RAG): tác nhân quyết định. Nó tìm kiếm những gì nó cần, tinh chỉnh các truy vấn, chọn công cụ, xác định khi nào nó có đủ thông tin.
Truy xuất như một quy trình lặp đi lặp lại, không phải một đường ống một lần.
Điều này quan trọng vì những gì có liên quan thay đổi ở mỗi bước — và chỉ có tác nhân mới biết nó cần gì tiếp theo.
Vấn đề lựa chọn công cụ là thứ khiến mọi người vấp ngã nhiều nhất.
Nếu tác nhân của bạn có 40+ công cụ, đó có khả năng là 10.000 token định nghĩa công cụ nằm trong ngữ cảnh trước khi bất kỳ công việc nào bắt đầu.
Cách khắc phục: RAG trên các mô tả công cụ.
Thay vì đổ tất cả định nghĩa công cụ vào mọi lệnh gọi, hãy sử dụng tìm kiếm ngữ nghĩa để chỉ đưa ra các công cụ liên quan đến bước hiện tại.
Một bài báo có tên RAG-MCP đã thử nghiệm điều này.
Độ chính xác lựa chọn công cụ: 14% → 43% (cải thiện gấp 3 lần). Lượng token sử dụng: giảm khoảng một nửa.
Anthropic gọi nó là một chiến lược kết hợp (hybrid strategy): tải ngữ cảnh thiết yếu từ đầu (như CLAUDE.md), để tác nhân thực hiện truy xuất đúng lúc cho mọi thứ khác.
Tải trước những điều cơ bản. Truy xuất phần còn lại theo yêu cầu.
Chiến lược 3 — Nén (Compress) (Ngữ cảnh tích tụ. Giữ lại ý nghĩa, cắt giảm token.)
Ngay cả với sự lựa chọn tốt, ngữ cảnh vẫn tích tụ.
Mọi lệnh gọi công cụ, tài liệu được truy xuất và quyết định vẫn ở trong cửa sổ.
Hãy tưởng tượng tác nhân của bạn đã thực hiện 20 lệnh gọi công cụ.
Ngữ cảnh: 80.000 token đầu ra công cụ tích lũy, lịch sử trò chuyện, dấu vết suy luận.
Phần lớn những thứ đó không còn liên quan nữa. Tác nhân đã hành động dựa trên nó rồi.
Nhưng nó vẫn ở đó, chiếm không gian, làm suy giảm sự chú ý, đẩy chi phí và độ trễ lên cao.
Bạn có thể nén ở 3 điểm.
Trước khi thông tin vào ngữ cảnh:
→ Chia nhỏ các tài liệu lớn thành các phần mạch lạc trước khi truy xuất
→ Sắp xếp lại thứ hạng để chỉ những phần hữu ích nhất lọt vào
→ Tóm tắt đầu ra công cụ ngay lập tức trước khi chúng vào ngữ cảnh chính
Trong khi tác nhân đang làm việc:
→ Tóm tắt luân phiên lịch sử trò chuyện — được cập nhật liên tục
→ Kết hợp phổ biến: giữ nguyên văn 10 tin nhắn cuối + tóm tắt mọi thứ cũ hơn
→ Cắt bỏ cứng: xóa các tin nhắn cũ hơn khi ngữ cảnh đạt đến một ngưỡng kích thước
→ Tự động nén của Claude Code: kích hoạt ở mức 95% dung lượng, tự động tóm tắt toàn bộ quỹ đạo
Sau khi tác nhân đã hành động dựa trên một cái gì đó:
→ Xóa kết quả công cụ: một khi kết quả công cụ đã được sử dụng cách đây 15 bước, hãy loại bỏ nó
→ Thay thế bằng một dòng tóm tắt hoặc xóa hoàn toàn
→ Tác nhân không cần văn bản đầy đủ của một trang web nó đã tìm nạp cách đây 20 bước
Mục tiêu: giảm số lượng token. Giữ lại những gì thực sự quan trọng.
Chiến lược 4 — Cô lập (Isolate) (Chiến lược mạnh mẽ nhất. Cho phép các hệ thống đa tác nhân.)
Đây là vấn đề sâu sắc hơn với các lần chạy tác nhân dài.
Nó không chỉ là không gian. Đó là sự ô nhiễm.
Các kết quả tìm kiếm tệp chi tiết từ giai đoạn nghiên cứu vẫn nằm trong ngữ cảnh khi tác nhân chuyển sang viết mã.
Bối cảnh nghiên cứu cũ đó bây giờ là nhiễu. Nó đang làm xao nhãng mô hình trong một giai đoạn mà nó cần tập trung vào việc triển khai sạch sẽ.
Cô lập (Isolation) có nghĩa là cung cấp cho các phần khác nhau của công việc các cửa sổ ngữ cảnh riêng biệt của chúng.
Tác nhân phụ (Sub-agents)
Một tác nhân mẹ ủy thác một nhiệm vụ phụ tập trung — "tìm kiếm cơ sở mã cho tất cả các tệp liên quan đến xác thực" — cho một tác nhân phụ.
Tác nhân phụ làm việc trong cửa sổ ngữ cảnh sạch sẽ của riêng nó.
Khi nó báo cáo lại, nó chỉ trả về một bản tóm tắt cô đọng.
Tất cả các thao tác tìm kiếm lộn xộn vẫn được cô lập trong ngữ cảnh của tác nhân phụ và không bao giờ làm ô nhiễm tác nhân mẹ.
Cô lập lược đồ trạng thái (State schema isolation) (Cách tiếp cận của LangGraph)
Thiết kế trạng thái của tác nhân để các trường khác nhau lưu trữ các loại ngữ cảnh khác nhau.
LLM chỉ nhìn thấy các trường liên quan đến bước hiện tại.
Kết quả công cụ nằm trong trường "hậu trường" — vô hình đối với mô hình cho đến khi được đưa ra một cách rõ ràng.
Kiểm soát chi tiết những gì tác nhân thấy ở mỗi bước mà không cần tạo ra các tác nhân phụ riêng biệt.
Cô lập là thứ làm cho các quy trình làm việc nhiều bước phức tạp thực sự đáng tin cậy.
Các công việc khác nhau. Các cửa sổ ngữ cảnh khác nhau. Không có ô nhiễm.
4 Cách Tác nhân Thất bại (Đặt tên cho sự thất bại. Sửa nó.)
Drew Breunig đã xác định bốn chế độ thất bại riêng biệt khi ngữ cảnh tác nhân phát triển.
Mọi tác nhân bị hỏng bạn từng thấy đều rơi vào một trong số này.
Thất bại 1: Nhiễm độc Ngữ cảnh (Context Poisoning)
Một ảo giác hoặc lỗi xâm nhập vào ngữ cảnh.
Tác nhân tham chiếu nó nhiều lần trong các bước tiếp theo.
Dữ liệu xấu từ bước 5 kết hợp thành mọi bước sau đó.
Cách khắc phục: Xác thực đầu ra công cụ trước khi chúng vào ngữ cảnh. Sau khi phục hồi từ lỗi, hãy nén lịch sử lần thử thất bại. Đừng để 10 bước gỡ lỗi không có kết quả hiển thị khi chỉ có giải pháp mới quan trọng.
━━━
Thất bại 2: Mất tập trung Ngữ cảnh (Context Distraction)
Ngữ cảnh trở nên quá dài khiến mô hình bắt đầu phụ thuộc quá nhiều vào lịch sử gần đây.
Thay vì tổng hợp một kế hoạch mới, nó chỉ lặp lại những gì nó vừa làm.
Nó ngừng suy nghĩ. Nó bắt đầu lặp lại.
Cách khắc phục: Tóm tắt và cắt tỉa mạnh mẽ. Ngay cả khi bạn có một cửa sổ ngữ cảnh lớn. Cửa sổ lớn không có nghĩa là lấp đầy nó.
━━━
Thất bại 3: Nhầm lẫn Ngữ cảnh (Context Confusion)
Nội dung thừa thãi dẫn đến các quyết định chất lượng thấp của mô hình.
Ví dụ kinh điển: một mô hình thất bại trong điểm chuẩn khi được cung cấp 46 công cụ — mặc dù ngữ cảnh nằm trong giới hạn — nhưng hoạt động tốt với chỉ 19 công cụ.
Các công cụ không quá nhiều để ngữ cảnh chứa.
Chúng quá nhiều để mô hình suy luận rõ ràng.
Cách khắc phục: Quản lý công cụ động. Sử dụng RAG-MCP để chỉ đưa ra các công cụ liên quan đến bước hiện tại. Giữ bộ công cụ phù hợp với giai đoạn hiện tại.
━━━
Thất bại 4: Xung đột Ngữ cảnh (Context Clash)
Thông tin mới mâu thuẫn với một cái gì đó đã có trong ngữ cảnh.
Prompt hệ thống nói một điều. Một tài liệu được truy xuất nói một điều khác.
Tác nhân không thể dung hòa sự mâu thuẫn. Tạo ra hành vi không nhất quán.
Cách khắc phục: Thiết lập một thứ tự ưu tiên rõ ràng. Prompt hệ thống > sự kiện được truy xuất > lịch sử trò chuyện. Xác thực thông tin mới so với ngữ cảnh hiện có trước khi đưa vào. Sử dụng các thẻ XML và tiêu đề rõ ràng để mô hình biết nguồn nào đáng tin cậy.
Cách Viết Prompt Hệ thống cho Tác nhân (Không phải Chatbot. Là Tác nhân.)
Một prompt hệ thống chatbot thiết lập một giọng điệu.
"Bạn là một trợ lý hữu ích. Hãy ngắn gọn và thân thiện."
Một prompt hệ thống tác nhân định nghĩa kiến trúc.
Nó chỉ định luồng điều khiển — cách tiếp cận các loại nhiệm vụ, sử dụng công cụ nào khi nào, phải làm gì khi gặp lỗi, tuân theo những rào cản nào.
Nó gần với việc viết một bản mô tả công việc cho một nhân viên tự động hơn là một prompt về tính cách.
Anthropic gọi nó là viết ở "độ cao phù hợp."
Quá cứng nhắc:"Nếu người dùng đề cập đến thanh toán VÀ đề cập đến hoàn tiền VÀ số tiền trên $100, hãy gọi công cụ X." Dễ vỡ. Hỏng ở mọi trường hợp ngoại lệ bạn không lường trước được.
Quá mơ hồ:"Hãy hữu ích và sử dụng các công cụ thích hợp." Không cho tác nhân điều gì cả. Nó không thể đưa ra các quyết định tự động tốt nếu không có các tín hiệu cụ thể.
Điểm ngọt ngào (sweet spot): Đủ cụ thể để hướng dẫn hành vi tự động. Đủ linh hoạt để mô hình áp dụng phán đoán trong các tình huống mới. Các phán đoán mạnh mẽ. Không phải các quy tắc cứng nhắc.
Mẹo thực tế:
→ Sắp xếp với các thẻ XML hoặc tiêu đề markdown — Bối cảnh, Hướng dẫn, Hướng dẫn Công cụ
→ Bắt đầu tối thiểu và lặp lại dựa trên các thất bại — đừng cố đoán trước mọi trường hợp ngoại lệ từ đầu
→ Tối thiểu không có nghĩa là ngắn — một prompt hệ thống tác nhân phức tạp có thể dài hàng nghìn token và điều đó ổn miễn là mọi token đều xứng đáng với vị trí của nó
→ Sử dụng các ví dụ few-shot — chỉ cho tác nhân thấy hành vi tốt trông như thế nào thay vì cố gắng mô tả mọi quy tắc bằng lời
KV-Cache: Lý do $$$ để quan tâm đến thứ tự ngữ cảnh
Hầu hết những người xây dựng tác nhân không biết điều này tồn tại.
Khi bạn gửi token đến một LLM, mô hình sẽ tính toán các biểu diễn khóa-giá trị cho mỗi token.
Tốn kém về mặt tính toán.
Vì vậy, các nhà cung cấp suy luận lưu vào bộ nhớ đệm các biểu diễn này.
Nếu phần đầu ngữ cảnh của bạn — tiền tố — giữ nguyên giữa các lệnh gọi API, nhà cung cấp sẽ tái sử dụng phép tính đã lưu trong bộ nhớ đệm và chỉ xử lý các token mới ở cuối.
Nhanh. Rẻ.
Nhưng nếu bạn sắp xếp lại hoặc thay đổi phần đầu của ngữ cảnh giữa các lệnh gọi — bạn sẽ làm mất hiệu lực của bộ đệm. Nhà cung cấp tính toán lại mọi thứ từ đầu.
Sự khác biệt về chi phí trên Claude Sonnet:
→ Token đầu vào được lưu trong bộ nhớ đệm: $0.30 mỗi triệu
→ Token đầu vào không được lưu trong bộ nhớ đệm: $3.00 mỗi triệu
Chênh lệch 10 lần.
Đối với một tác nhân thực hiện 30–40 lệnh gọi API mỗi nhiệm vụ, điều này tăng lên nhanh chóng.
Các quy tắc thực tế cho hiệu quả KV-cache:
→ Nội dung ổn định được đặt ở ĐẦU ngữ cảnh — prompt hệ thống, định nghĩa công cụ, bất cứ thứ gì không thay đổi giữa các lượt
→ Nội dung động được đặt ở CUỐI — lịch sử trò chuyện, bước hiện tại, trạng thái tác nhân
→ Không thêm và xóa công cụ một cách linh hoạt giữa cuộc trò chuyện — điều đó làm mất hiệu lực của bộ đệm
→ Sử dụng che dấu công cụ (tool masking) thay vì loại bỏ công cụ — giữ tất cả định nghĩa công cụ ổn định trong tiền tố (đã lưu trong bộ nhớ đệm), chỉ đánh dấu những công cụ không liên quan là không khả dụng cho giai đoạn hiện tại
Quy trình Làm việc Đã Giao 35.000 Dòng Mã trong 7 Giờ
Dex Horthy (CEO của HumanLayer) đã trình bày điều này tại Hội nghị Thượng đỉnh Mã Kỹ sư AI.
Nhóm của anh ấy được cho là đã sử dụng nó để giao ~35.000 dòng mã cho một cơ sở mã Rust lớn trong một phiên làm việc kéo dài 7 giờ.
Phương pháp: Nén chủ động thường xuyên (Frequent Intentional Compaction).
Cấu trúc công việc tác nhân thành các giai đoạn. Mỗi giai đoạn tạo ra một tạo phẩm được nén. Mỗi giai đoạn mới bắt đầu với một cửa sổ ngữ cảnh mới chỉ chứa tạo phẩm đó.
Luôn ở dưới 40–60% cửa sổ ngữ cảnh tại mọi thời điểm.
Giai đoạn 1 — Nghiên cứu
Các tác nhân phụ khám phá cơ sở mã. Đọc tệp. Theo dõi luồng dữ liệu. Lập bản đồ kiến trúc.
Tất cả các kết quả grep lộn xộn và nội dung tệp vẫn nằm trong ngữ cảnh của tác nhân phụ. Không bao giờ chạm đến tác nhân mẹ. (Cô lập)
Đầu ra: một research.md nhỏ gọn — đường dẫn tệp, chữ ký hàm, các mẫu, các điểm cần lưu ý. (Ghi lại)
Đặt lại ngữ cảnh: nghiên cứu thô sử dụng 60–80% cửa sổ. Tạo phẩm nghiên cứu nén nó xuống còn 15–20%. (Nén)
Giai đoạn 2 — Lập kế hoạch
Cửa sổ ngữ cảnh mới. Chỉ chứa: tài liệu nghiên cứu + định nghĩa vấn đề.
Tác nhân tạo ra một kế hoạch triển khai chi tiết.
Đây là điểm kiểm tra đánh giá của con người quan trọng nhất.
Phát hiện lỗi logic ở đây, nơi sửa chúng dễ dàng và miễn phí. Sau này sẽ mất hàng giờ.
Giai đoạn 3 — Triển khai
Một cửa sổ ngữ cảnh mới. Chỉ chứa: kế hoạch.
Tác nhân làm theo nó từng bước một.
Đối với các nhiệm vụ phức tạp: một progress.md theo dõi những gì đã hoàn thành và những gì còn lại. (Ghi lại)
Kết quả: một tác nhân sạch sẽ, tập trung ở mọi giai đoạn. Không ô nhiễm. Không suy giảm ngữ cảnh. Không có "bước 20 cẩu thả."
Cách các nền tảng tốt nhất xử lý điều này khác nhau
Claude Code
Truy xuất kết hợp. CLAUDE.md được tải từ đầu. Các công cụ như glob và grep xử lý việc điều hướng cơ sở mã đúng lúc.
Tự động nén ở mức 95% — bảo tồn các quyết định kiến trúc và 5 tệp được truy cập gần đây nhất.
Có thể sinh ra các tác nhân phụ cho các nhiệm vụ phụ phức tạp, mỗi tác nhân có ngữ cảnh sạch sẽ riêng.
Triết lý: "làm điều đơn giản nhất có hiệu quả." Để mô hình thông minh về những gì nó cần và cung cấp cho nó các công cụ để đi tìm.
Manus
Sắp xếp ngữ cảnh nhận biết KV-cache: tiền tố ổn định, hậu tố động. Che dấu công cụ chứ không phải loại bỏ.
Quy trình nén quan sát — mọi đầu ra công cụ đều được xử lý trước khi vào ngữ cảnh của tác nhân.
Danh sách việc cần làm liên tục để theo dõi trạng thái.
Hệ thống tệp như bộ nhớ tràn cho ngữ cảnh đã bị loại bỏ.
Được xây dựng để mở rộng quy mô. Phục vụ hàng trăm nghìn người dùng nơi hiệu quả là một vấn đề chi phí kinh doanh.
ChatGPT Agent
Cách tiếp cận ưu tiên hình ảnh. Tác nhân tương tác với trình duyệt GUI.
Ảnh chụp màn hình được thêm vào ngữ cảnh dưới dạng ảnh chụp nhanh trực quan. Mô hình suy luận dựa trên những gì nó thấy.
Token hình ảnh đắt tiền vì vậy tác nhân có chọn lọc về số lượng ảnh chụp màn hình.
Sử dụng RL để học các chiến lược sử dụng công cụ tối ưu qua hàng nghìn máy ảo thay vì lập trình chúng một cách rõ ràng.
Google ADK
Phương pháp kiến trúc có nguyên tắc nhất.
Ba nguyên tắc thiết kế:
- Tách biệt lưu trữ khỏi trình bày — trạng thái bền vững không giống với những gì xuất hiện trong mỗi lệnh gọi API
- Các phép biến đổi rõ ràng — các bộ xử lý được đặt tên, có thứ tự để biến đổi ngữ cảnh trong các bước có thể kiểm tra, có thể kết hợp
- Phạm vi ngữ cảnh theo mặc định — mọi lệnh gọi mô hình chỉ thấy thông tin tối thiểu cần thiết
Kỷ luật kỹ thuật hơn là việc tạo prompt.
Quy trình xử lý lượt tác nhân phổ quát
Mọi nền tảng nghiêm túc đều hội tụ về cùng một vòng lặp 5 bước cho mỗi lượt tác nhân:
→ Thu thập (Collect) — đầu vào người dùng, lịch sử trò chuyện, kết quả công cụ, tài liệu được truy xuất, trạng thái tác nhân
→ Chọn lọc (Select) — những gì có liên quan cho bước này trong ngân sách token còn lại
→ Nén (Compress) — tóm tắt, cắt bớt hoặc tái cấu trúc để phù hợp với ngữ cảnh
→ Sắp xếp (Arrange) — nội dung ổn định trước (bộ nhớ đệm), nội dung động sau
→ Tổng hợp + gọi (Assemble + call) — ngữ cảnh cuối cùng → lệnh gọi API → nhận đầu ra → lặp lại
Đây là vòng lặp đang chạy bên trong mọi tác nhân sản xuất bạn từng sử dụng.
Hiểu nó là điều phân biệt những người xây dựng giao các tác nhân đáng tin cậy với những người xây dựng tự hỏi tại sao tác nhân của họ trở nên cẩu thả ở bước 15.
Tóm tắt
Sự suy giảm ngữ cảnh (Context rot) là có thật và bắt đầu từ rất lâu trước giới hạn ngữ cảnh của bạn.
4 chiến lược khắc phục nó:
→ Ghi lại (Write) — lưu giữ thông tin bên ngoài ngữ cảnh để tác nhân không quên
→ Chọn lọc (Select) — chỉ kéo vào những gì cần thiết cho bước này
→ Nén (Compress) — cắt token, giữ ý nghĩa, chủ động chứ không phải phản ứng
→ Cô lập (Isolate) — ngữ cảnh riêng biệt cho các công việc riêng biệt, không ô nhiễm
4 chế độ thất bại cần theo dõi:
→ Nhiễm độc (Poisoning) — dữ liệu xấu kết hợp qua mọi bước
→ Mất tập trung (Distraction) — lịch sử dài khiến tác nhân lặp lại thay vì suy nghĩ
→ Nhầm lẫn (Confusion) — quá nhiều công cụ làm giảm chất lượng quyết định
→ Xung đột (Clash) — mâu thuẫn tạo ra hành vi không nhất quán
KV-cache đáng giá tiết kiệm chi phí gấp 10 lần. Đặt nội dung ổn định lên đầu.
Quy trình làm việc tốt nhất: nghiên cứu → nén → lập kế hoạch → nén → triển khai. Ngữ cảnh mới ở mọi giai đoạn.
Kỹ thuật quản lý ngữ cảnh (Context engineering) không phải là tùy chọn cho công việc tác nhân nghiêm túc.
Nó chính là công việc.
Nếu điều này hữu ích:
→ Đăng lại để chia sẻ nó với mọi người xây dựng tác nhân bạn biết
→ Theo dõi @sairahul1 để biết thêm các hệ thống hoạt động trong khi bạn ngủ
→ Đánh dấu trang này — bạn sẽ quay lại khuôn khổ 4 chiến lược
Tôi viết về AI, xây dựng sản phẩm và các hệ thống thực sự hoạt động.
