Xây dựng AI agent thực chất là một bài toán quản trị tài nguyên. Nếu coi mô hình ngôn ngữ lớn (Large Language Model, LLM) là CPU thì cửa sổ ngữ cảnh (context window) chính là RAM. Context engineering là nghệ thuật lấp đầy "thanh RAM" này bằng đúng những thông tin cần thiết cho bước xử lý tiếp theo. Tuy nhiên, đừng nhầm lẫn: context window không phải là cái túi không đáy để bạn nhét mọi thứ vào. Khi bạn nhồi nhét vô tội vạ hoặc sắp xếp dữ liệu cẩu thả, agent sẽ rơi vào các trạng thái lỗi hệ thống mà giới kỹ sư gọi là context failure modes.
Hiệu suất của agent không tỷ lệ thuận với độ dài ngữ cảnh. Ngược lại, quản lý context kém sẽ trực tiếp gây ra lỗi logic, làm tăng latency và đốt tiền vô nghĩa. Hiểu rõ các mode lỗi này là bước đầu tiên để bạn tối ưu hệ thống từ mức "chạy được" lên mức "đạt benchmark" trong vận hành thực tế.
Context failure modes là gì, và vì sao thêm ngữ cảnh lại làm agent kém đi?
Andrej Karpathy từng ví von mô hình ngôn ngữ lớn (Large Language Model, LLM) giống như một hệ điều hành kiểu mới, trong đó context window đóng vai trò là bộ nhớ RAM. RAM có hạn, và giống như OS phải điều phối dữ liệu vào RAM để CPU xử lý, bạn phải làm context engineering để đưa đúng token vào "tầm mắt" của mô hình.
Trong thực tế vận hành agent (như trường hợp của Manus), tỷ lệ token đầu vào so với đầu ra thường cực kỳ chênh lệch, rơi vào khoảng 100:1. Nghĩa là bạn nạp vào một lượng lớn thông tin chỉ để đổi lấy vài dòng lệnh function call. Vấn đề nằm ở "ngân sách chú ý" (attention budget). LLM dựa trên kiến trúc Transformer với các mối quan hệ n² giữa các token. Càng nhiều token, khả năng tập trung vào các mối quan hệ quan trọng giữa các cặp token càng bị loãng.
Đừng bị đánh lừa bởi những con số 1M hay 10M token của Gemini hay Llama 4. Ngữ cảnh lớn không đồng nghĩa với việc mô hình thông minh hơn. Khi attention budget bị kéo căng, khả năng truy xuất chính xác và suy luận logic của mô hình sẽ suy giảm đáng kể trước khi bạn kịp dùng hết context window đó. Các mô hình vẫn có xu hướng xử lý tốt nhất ở hai đầu và kém dần ở giữa.
Context poisoning: khi một lỗi trở thành sự thật
Context poisoning (nhiễm độc ngữ cảnh) xảy ra khi một thông tin sai hoặc một lỗi ảo giác (hallucination) lọt vào history và bị agent coi là sự thật hiển nhiên cho các bước sau. Đây là một vòng lặp chết chóc: agent tin vào dữ liệu rác, hành động dựa trên rác, và tiếp tục ghi thêm rác vào context.
Báo cáo kỹ thuật của Gemini 2.5 khi chơi Pokémon đã chỉ rõ lỗi này. Agent có thể tự bịa ra trạng thái hiện tại của game (ví dụ: tưởng mình đã thắng một trận đấu chưa diễn ra), sau đó ghi thông tin sai này vào mục tiêu (goals) hoặc tóm tắt (summary). Kết quả là agent bị "ám ảnh" (fixated) bởi việc thực hiện các mục tiêu không tưởng hoặc vô nghĩa dựa trên dữ liệu lỗi ban đầu. Một khi context đã bị "độc hóa", agent sẽ kẹt trong một vòng lặp logic sai lầm kéo dài, làm tiêu tốn tài nguyên mà không mang lại kết quả.
Context distraction: khi lịch sử lấn át những gì mô hình đã học
Đây là hiện tượng agent quá tập trung vào những gì vừa xảy ra trong lịch sử giao tiếp mà quên mất các kiến thức cốt lõi đã được huấn luyện. Ngữ cảnh quá dài khiến mô hình bị "xao nhãng", nó bắt đầu lặp lại các hành vi cũ như một cái máy thay vì tư duy.
Dữ liệu từ Databricks cho thấy độ chính xác của các mô hình như Llama 3.1 405b bắt đầu tụt dốc khi ngữ cảnh vượt ngưỡng 32k token. Với Gemini 2.5 Pro, khi context vượt quá 100k token, agent có xu hướng lặp lại các hành động trong quá khứ thay vì đưa ra một kế hoạch mới tối ưu hơn. Bạn cần phân biệt rõ: ngữ cảnh cho truy xuất (retrieval) và ngữ cảnh cho suy luận (reasoning) là hai bài toán khác nhau. Càng nhiều dữ liệu lịch sử không liên quan, khả năng reasoning càng dễ bị nhiễu và sa lầy vào những thói quen cũ trong chính thread đó.
Context confusion: khi nội dung thừa vẫn được đem ra dùng
Lỗi này thường gặp khi bạn nhồi nhét quá nhiều công cụ (tools) hoặc tài liệu không liên quan vào prompt. Bạn nghĩ rằng đưa cho agent "full loadout" là tốt, nhưng thực tế LLM buộc phải chú ý đến mọi thứ bạn đưa vào, kể cả những mô tả công cụ thừa thãi làm loãng attention budget.
Theo Berkeley Function-Calling Leaderboard, hầu như mọi mô hình đều kém đi khi phải xử lý nhiều hơn một công cụ cùng lúc. Thí nghiệm "Less is More" trên Llama 3.1 8b là bằng chứng thép: mô hình thất bại hoàn toàn khi có 46 tools trong context, nhưng khi cắt giảm xuống còn 19 tools trong cùng một cửa sổ ngữ cảnh thì lại đạt benchmark thành công. Đừng bắt agent phải phân vân giữa quá nhiều lựa chọn không cần thiết; nếu mô tả công cụ chồng chéo, agent sẽ gọi sai tool là chuyện đương nhiên.
Context clash: khi ngữ cảnh tự mâu thuẫn
Context clash xảy ra khi các phần thông tin trong cùng một ngữ cảnh đối chọi nhau. Nghiên cứu của Microsoft và Salesforce về "sharded prompts" (chia nhỏ thông tin qua nhiều lượt chat) cho thấy hiệu suất giảm kinh khủng. Ngay cả o3, vốn cực mạnh về lý luận, cũng bị tụt điểm thê thảm từ 98.1 xuống còn 64.1 khi thông tin bị xé lẻ.
Nguyên nhân là do trong các lượt chat đầu, khi chưa có đủ thông tin, agent thường đưa ra các giả định hoặc câu trả lời sai. Những nội dung sai này vẫn nằm chình lình trong history và "đấm nhau" (clash) với các dữ liệu đúng được nạp vào sau đó. Khi ngữ cảnh tự mâu thuẫn, mô hình thường bị kẹt vào những "vết xe đổ" ban đầu và không thể quay đầu lại, dù bạn có đưa thêm dữ liệu chuẩn xác đến thế nào.
Context rot: độ chính xác giảm trước khi cửa sổ đầy
Báo cáo kỹ thuật của Chroma đã định nghĩa hiện tượng "mục rỗng ngữ cảnh" (context rot). Qua bài test "Repeated Words", hiệu suất mô hình giảm dần khi chiều dài input/output tăng lên, ngay cả khi chưa đầy context window.
Đáng chú ý nhất là hiện tượng "Lost in the Middle": độ chính xác cao nhất ở phần đầu và phần cuối (U-shaped curve), và thấp nhất ở đoạn giữa. Các model như Claude Opus 4 có hành vi khá tiêu cực khi ngữ cảnh quá dài (thường từ 2500 từ trở lên): nó sẽ từ chối thực hiện (refusal) với các lý do như lo ngại bản quyền hoặc chỉ đưa ra các quan sát vô thưởng vô phạt thay vì thực hiện hành động cụ thể. Điều này chứng tỏ agent bắt đầu mất khả năng kiểm soát dữ liệu khi khối lượng token vượt ngưỡng chịu tải của attention budget.
Dữ liệu cũ: truy xuất đúng chủ đề nhưng sai sự thật
Trong các hệ thống agent phức tạp như Manus hay Windsurf, việc Indexing (lập chỉ mục) và Context Retrieval (truy xuất ngữ cảnh) là hai việc khác nhau. Khi codebase lớn dần, embedding search (tìm kiếm bằng vector) trở nên kém tin cậy vì các vector bắt đầu nằm quá gần nhau trong không gian biểu diễn.
Vấn đề là agent có thể truy xuất được đúng file liên quan đến chủ đề, nhưng dữ liệu trong file đó đã cũ hoặc không còn đúng với trạng thái thực tế của môi trường. Nếu chỉ tin vào kết quả search mà không có bước re-ranking hoặc kết hợp với các công cụ kiểm tra thực tế như grep hay file search, agent sẽ hành động dựa trên những "bóng ma" dữ liệu lỗi thời.
Agent của bạn đang dính kiểu lỗi nào?
Để chẩn đoán, bạn cần sử dụng các công cụ như LangSmith để trace (theo dõi) và đánh giá hiệu suất từng bước. Một chỉ số thực dụng cần quan sát là KV-cache hit rate. KV-cache giúp giảm latency và chi phí đáng kể: với Claude Sonnet, cached input token chỉ tốn 0.30 USD/MTok so với 3 USD/MTok của uncached token, rẻ hơn 10 lần.
Trong sáu kiểu trên, theo tôi context poisoning là kiểu khó chịu nhất, vì nó không làm agent dừng lại mà chỉ khiến agent sai trong khi vẫn rất tự tin. Các kiểu còn lại ít nhất còn để lại dấu vết trong trace; poisoning thì trông y hệt một phiên chạy bình thường.
Tuy nhiên, cache cực kỳ dễ hỏng. Một lỗi phổ biến của "newbie" là chèn timestamp hoặc random seed vào đầu prompt. Chỉ cần bạn thay đổi một dấu cách hoặc một ký tự ở đầu prompt, toàn bộ cache phía sau sẽ bị hủy bỏ (invalidated), buộc mô hình phải prefill lại từ đầu. Nếu latency đột ngột tăng và hóa đơn API vọt lên, hãy kiểm tra ngay tính ổn định của prompt prefix.
Sửa từng kiểu lỗi: RAG, tool loadout, quarantine, pruning, summarization, offloading
Để tối ưu hệ thống, bạn cần áp dụng các bộ lọc kỹ thuật sau:
- RAG & Tool Loadout (chọn lọc công cụ): Đừng nạp tất cả tools. Hãy dùng RAG cho chính các mô tả công cụ để chỉ nạp tối đa khoảng 30 tools phù hợp nhất với task hiện tại. Điều này có thể tăng độ chính xác lên gấp 3 lần.
- Context Quarantine (cách ly): Dùng cấu trúc multi-agent. Mỗi sub-agent xử lý một context window riêng biệt cho các task nhỏ, sau đó chỉ trả về kết quả cô đọng (1000–2000 token) cho agent chính để tránh gây nhiễu history.
- Pruning (cắt tỉa): Sử dụng các công cụ chuyên dụng như Provence (một context pruner nhỏ gọn khoảng 1.75 GB) để xóa bỏ đến 95% nội dung rác mà vẫn giữ được tín hiệu (signal) cần thiết cho việc trả lời câu hỏi.
- Summarization (tóm tắt/nén): Tự động tóm tắt (auto-compact) khi ngữ cảnh đầy 95% giống như cách Claude Code vận hành. Xóa bỏ các tool output thô và chỉ giữ lại kết luận quan trọng.
- Context Offloading (đẩy ra ngoài): Dùng "scratchpad" hoặc hệ thống file bên ngoài (externalized memory) để agent tự đọc/ghi khi cần. Đừng nhét mọi thứ vào "RAM" (context window), hãy để agent dùng "ổ cứng" (file system).
Cắt tỉa quá tay cũng là một kiểu lỗi
Đừng coi context window là ngăn kéo chứa rác, nhưng cũng đừng cắt tỉa cực đoan theo kiểu "gọt chân cho vừa giày". Mục tiêu là tìm ra tập hợp token nhỏ nhất nhưng có tín hiệu cao nhất (high-signal tokens). Nếu bạn cắt tỉa quá đà, agent sẽ mất đi những chi tiết nhỏ, thứ có thể là mấu chốt để giải quyết vấn đề ở các bước sau.
Điểm trừ của cả sáu cách sửa ở trên là chúng đều đánh đổi: mỗi token bạn cắt đi là một token agent không còn để suy luận, và không có ngưỡng nào đúng cho mọi bài toán. Tôi vẫn phải chỉnh tay theo từng hệ thống, và tôi nghĩ giai đoạn này thì chưa ai thoát được việc đó.
Tài liệu tham khảo
- How Long Contexts Fail — Drew Breunig
- How to Fix Your Context — Drew Breunig
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Chroma
- Lost in the Middle: How Language Models Use Long Contexts
- Effective context engineering for AI agents — Anthropic
- Context Engineering for Agents — LangChain
- Context Engineering for AI Agents: Lessons from Building Manus
- The RAG Freshness Problem: How Stale Embeddings Silently Wreck Retrieval Quality