# Context engineering cho AI agent: 4 failure mode cần tránh

[Martin Keen](https://homus.dev/speakers/martin-keen) · [IBM Technology](https://homus.dev/orgs/ibm-technology)

> Vì sao context window to hơn lại làm agent kém tin cậy (context rot), bốn failure mode của context và bốn cách sửa: validate, compact, curate, prune.

Topics: Context Engineering, Agents

Canonical: https://homus.dev/talks/context-engineering-for-ai-agents-4-failure-modes-to-avoid

## 1. Context window to hơn, agent giỏi hơn? Chưa chắc: context rot

Martin Keen mở đầu bằng một sự thật ai cũng thấy: context window đã lớn lên từ vài nghìn token thành một con số lớn hơn nhiều, cỡ một triệu token hoặc hơn. Như vậy là có thêm chỗ cho đủ thứ: thêm instruction, thêm tool result, thêm tài liệu, bạn muốn gì cũng có chỗ.

Vậy nếu ta nghĩ về AI agent và cho chúng truy cập vào cái context window to đùng này, thì lẽ ra chúng phải ngày càng giỏi hơn ở các tác vụ chạy dài (long-running task), đúng không? Context càng nhiều thì việc chúng làm càng tốt, nghe thì hợp lý.

Thế nhưng một nghiên cứu gần đây đã xem xét 18 frontier model, và kết quả là tất cả đều trở nên kém tin cậy hơn khi context window lớn dần. Các nhà nghiên cứu đã đặt cho hiện tượng này một cái tên: **context rot** (context bị "mục"). Càng nhiều token trong window, model càng dùng bất kỳ token nào trong đó một cách kém tin cậy hơn.

![Martin Keen đứng sau lightboard với AI Agents, Context Window, Context Rot và Context Engineering](https://homus.dev/photos/BwXremQ-i6I-0143.jpg)

Bảng vẽ đầu tiên: khối "AI Agents" nối hai chiều với một context window rất dài. Chữ "Context Rot" chỉ vào window, còn phía trên là "Context Engineering" kèm ghi chú "4 failure modes".

## 2. Context engineering, bốn failure mode và một nghịch lý

Đây chính là vấn đề mà **context engineering** sinh ra để giải quyết. Martin định nghĩa: context engineering là việc quyết định thứ gì thực sự được đưa vào context window ở mỗi bước trong một lần chạy của agent.

Context của một agent có thể hỏng theo rất nhiều cách, và Martin sẽ nói về bốn trong số đó: bốn failure mode bạn có thể gặp khi làm việc với những context window lớn như thế này. "Và vì hôm nay tôi thấy tử tế", anh đùa, anh sẽ gợi ý luôn cách sửa cho từng cái.

Điều buồn cười ở những cách sửa đó là chúng đều liên quan tới việc cố tình vứt bớt thông tin đi. Vậy làm sao một agent lại giỏi hơn khi giữ ít context hơn? Để trả lời, trước hết cần nhìn xem thứ gì thực sự đang lấp đầy những context window khổng lồ này.

Hai ý của phần mở đầu: càng nhiều token, model dùng chúng càng kém tin cậy; context engineering là chọn ra thứ thực sự cần đưa vào window ở từng bước.

## 3. Ví dụ migration agent: thứ gì đang lấp đầy context window

Martin dựng một ví dụ: một AI agent được giao việc chuyển (migrate) một codebase đã cũ sang dùng một database driver mới. Tức là ta đang build một migration AI agent. Trên lightboard, khối "AI Agents" giờ được ghi thêm chữ "Migration", và anh lần lượt vẽ các ngăn trong context window từ trái sang phải.

- **System prompt.** Ở đầu context window, thứ đầu tiên gần như chắc chắn có mặt là system prompt: bộ instruction thường trực về cách agent hoạt động nói chung.

- **Prompt của tác vụ.** Bản thân task của agent cũng nằm trong đó, như một prompt riêng. Nó có thể không lớn, có khi chỉ vài dòng.

- **Project instructions.** Sau đó, nhiều agent harness còn kéo vào một loạt hướng dẫn riêng của project, chẳng hạn một file agents giải thích project cụ thể này được build như thế nào.

- **Tool descriptions.** Tiếp theo có thể là các tool definition: mô tả cho từng tool mà agent được phép gọi.

- **Message history.** Từ đây trở đi, context window biến thành một kiểu log chạy liên tục. Message history là mọi bước agent đã thực hiện. Sau khoảng một tiếng chạy, phần này có thể khá lớn, vì đó là rất nhiều bước.

- **Tool results.** Và ngăn lớn nhất có lẽ là tool result được lưu ở đây: nội dung file, output của test, error log, schema dump.

![Lightboard: Migration AI Agents nối với context window gồm sáu ngăn](https://homus.dev/photos/BwXremQ-i6I-0323.jpg)

Context window của migration agent, chia thành sáu ngăn: Sys. Prompt, Prompt, Project Instr., Tool Desc., Message History và Tool Results. Ngăn prompt của task là ngăn hẹp nhất.

Như vậy, mô tả công việc, tức prompt, chỉ là vài dòng gần phía đầu, còn gần như tất cả phần còn lại là những thứ agent cứ thế chất đống dần trên đường làm việc.

## 4. Một ghi chú chôn trong history, và attention budget có hạn

À, và vùi trong đống đó còn có một ghi chú. Đây là ghi chú do chính agent tự viết cho mình. Nó nói rằng driver mới tự động retry các connection bị lỗi, nên đoạn code retry cũ có thể xoá đi. Nói gọn, ghi chú bảo: "này, khỏi cần viết code retry nữa". Martin vẽ một ô "No retry code" gắn lên ngăn message history. Vì sao anh nhắc tới nó? Lát nữa sẽ quay lại.

![Cận cảnh context window với ô No Retry Code gắn trên ngăn Message History](https://homus.dev/photos/BwXremQ-i6I-0422.jpg)

Ô "No Retry Code" được vẽ treo phía trên ngăn Message History: ghi chú agent tự viết, nói rằng driver mới đã tự retry nên code retry cũ có thể xoá.

Trở lại câu hỏi chính: tại sao một context window đầy lại là vấn đề? Bởi vì model không tra cứu thứ trong context của nó theo kiểu một database tra một dòng (row). Mỗi token trong window đều đang tranh nhau một lượng attention hữu hạn, về bản chất là một **attention budget**.

Với Martin, đây chính là mấu chốt: window có thể chứa một triệu token, nhưng lượng attention trải ra trên những token đó là có hạn.

Phép so sánh của Martin: database nhảy thẳng tới một dòng, còn model phải chia một attention budget có hạn cho mọi token trong window, nên window càng đầy thì mỗi token càng được ít attention.

## 5. Failure mode 1: context poisoning

Giờ tới các failure mode. Cái đầu tiên là **context poisoning** (context bị đầu độc).

Martin nhắc lại ghi chú bí ẩn anh vừa nói: agent tự ghi rằng driver mới tự động retry các connection lỗi. Hoá ra ghi chú đó sai hoàn toàn. Agent lẽ ra không nên làm vậy: về cơ bản nó đọc lướt tài liệu của driver, hiểu sai, rồi ghi xuống một kết luận sai.

Poisoning chỉ có vậy thôi: một lỗi lọt vào đâu đó trong context window, rồi được coi như sự thật, vì với AI model, chính những ghi chú của nó trông như ground truth. Thế là, hết file này tới file khác, agent của chúng ta cứ xoá đi những đoạn code retry hoàn toàn tốt.

![Lightboard với mục 1 Context Poisoning ở góc trái trên](https://homus.dev/photos/BwXremQ-i6I-0506.jpg)

Mục "1. Context Poisoning" xuất hiện ở góc trên bên trái, trong khi ô "No Retry Code" vẫn treo trên Message History: một kết luận sai nằm trong window và được đối xử như sự thật.

## 6. Failure mode 2: context distraction

Tiếp theo, số hai là **context distraction** (context làm agent xao nhãng). Đây là khi chính kích thước của history bắt đầu lái agent đi.

Martin giải thích: về cốt lõi, một language model chỉ là một cỗ máy nối tiếp pattern (pattern continuation machine). Khi context chứa, giả sử, một tiếng đồng hồ các hành động trong quá khứ của chính agent, thì history đó gần như trở thành pattern mạnh nhất có mặt, mạnh hơn cả khả năng suy luận model học được trong quá trình training.

Vì vậy, thay vì hỏi "việc này cần gì tiếp theo", model có thể trôi dần sang việc làm thêm những thứ nó đã làm trong message history. Agent ở trạng thái này có thể bị kẹt, cứ đi đi lại lại trên những phần việc cũ.

![Lightboard với mục 1 Context Poisoning và 2 Context Distraction](https://homus.dev/photos/BwXremQ-i6I-0548.jpg)

Mục "2. Context Distraction" được thêm bên dưới mục 1. Martin chỉ vào context window, nơi ngăn Message History ngày một dài ra khi agent chạy.

## 7. Failure mode 3: context confusion và tool sprawl

Thế còn số ba? Đó là **context confusion** (context gây rối), và cái này đến từ tool.

Agent của chúng ta được nối vào khá nhiều thứ. Có lẽ có một kiểu version control nào đó, có thể có quyền vào database console, và có thể nó còn ghi ticket vào một hệ thống ticketing. Trên bảng, Martin vẽ ba biểu tượng nhỏ phía trên ngăn tool result: chữ "V" cho version control, một hình trụ cho database và một ô cho hệ thống ticket.

![Lightboard với mục 3 Context Confusion và ba biểu tượng tool phía trên Tool Results](https://homus.dev/photos/BwXremQ-i6I-0643.jpg)

Mục "3. Context Confusion" ở góc phải trên. Phía trên ngăn Tool Results là ba biểu tượng tool agent được nối vào: version control, database và hệ thống ticket.

Mỗi tool definition này đều nằm trong window, dù tool đó có thật sự được dùng hay không. Và càng có nhiều tool, việc chọn đúng tool càng khó hơn một chút.

Martin dẫn một benchmark: một model đã fail một task khi được đưa 46 tool, nhưng lại pass đúng task đó khi chỉ được đưa 19 tool. Đó là **tool sprawl** (tool tràn lan) đang tác động.

Con số benchmark Martin dẫn: cùng một task, model fail với 46 tool nhưng pass với 19 tool (các vạch chỉ minh hoạ tỉ lệ, không đếm từng tool).

## 8. Failure mode 4: context clash

Được rồi, số bốn là **context clash** (context xung đột): khi window chứa thông tin tự mâu thuẫn với chính nó.

Quay lại ghi chú mang thông tin sai. Tới một lúc nào đó, agent sẽ thấy rằng chẳng có retry nào xảy ra cả, và nó sẽ nhận ra ghi chú kia sai. Rất có thể nó cũng sẽ ghi điều đó vào message history.

Nhưng vấn đề là giờ ta có cả hai phiên bản cùng nằm trong window, đưa ra những thông tin trái ngược nhau. Vậy là bốn cách khác nhau mà một context window có thể hỏng.

![Lightboard với đủ bốn failure mode: Poisoning, Distraction, Confusion, Clash](https://homus.dev/photos/BwXremQ-i6I-0723.jpg)

Đủ bốn failure mode trên bảng: 1. Context Poisoning, 2. Context Distraction, 3. Context Confusion và 4. Context Clash, cùng context window của migration agent ở phía dưới.

## 9. Cách sửa cho poisoning và distraction: validate, compact

Giờ tới vài cách sửa có thể áp dụng.

**Poisoning → validate.** Một trong các cách sửa cho poisoning là kiểm chứng. Trước khi một kết luận được ghi xuống context window, hãy đối chiếu nó với một thứ có thật. Chỉ cần một lần test connection nhanh, agent của chúng ta đã không bao giờ viết ra ghi chú "không cần code retry" kia.

**Distraction → compact.** Cách sửa cho distraction thực chất là nén lại. Khi history trở nên rất, rất dài, agent có thể tóm tắt nó, tức là vứt bỏ toàn bộ log và bắt đầu lại từ bản tóm tắt, một phiên bản rút gọn của những gì có trong message history của window.

Nhưng compaction là lossy (mất mát thông tin). Một bản tóm tắt của bản tóm tắt có thể bắt đầu lệch dần, giống như photocopy của một bản photocopy. Vì vậy, Martin gợi ý cân nhắc chuyển càng nhiều thứ ra khỏi context window càng tốt và đưa chúng vào các file lâu dài (permanent file). Thông tin chi tiết có thể được giữ lại trong những file đó, rồi chỉ được kéo vào context window khi thực sự cần.

![Lightboard với Validate dưới Poisoning, Compact dưới Distraction và một biểu tượng file có mũi tên chỉ vào context window](https://homus.dev/photos/BwXremQ-i6I-0843.jpg)

Hai cách sửa đầu được khoanh màu tím: "Validate" dưới Context Poisoning, "Compact" dưới Context Distraction. Bên dưới là biểu tượng một file lâu dài với mũi tên chỉ vào context window: thông tin nằm ở file, chỉ được kéo vào khi cần.

## 10. Cách sửa cho confusion và clash: curate, prune

**Confusion → curate.** Context confusion là một bài toán tuyển chọn, nên cách sửa là curate. Agent không cần 46 tool cho một lần migrate database. Hãy chỉ đưa cho nó một nhúm tool mà công việc thực sự đòi hỏi, và nó luôn có thể tự đi lấy thêm tool khác nếu thật sự cần.

**Clash → prune.** Cuối cùng, với context clash, cách sửa có thể là tỉa bớt. Khi thông tin đã bị thay thế bởi thông tin mới hơn, hãy xoá luôn phiên bản cũ thay vì để cả hai trong window. "Lẽ ra ta đã có thể xoá hẳn anh bạn này", Martin nói, và gạch chéo ô "No retry code" trên bảng.

Hoặc đi xa hơn: mở một window mới tinh, chỉ nêu lại trạng thái hiện tại đã được sửa đúng của công việc, và bỏ lại phía sau những thứ đã bị đầu độc.

![Cận cảnh Curate và Prune dưới Context Confusion và Context Clash, ô No Retry Code vẫn còn](https://homus.dev/photos/BwXremQ-i6I-0910.jpg)

"Curate" khoanh dưới Context Confusion và "Prune" dưới Context Clash. Ô "No Retry Code" phía trên Message History là thứ sắp bị gạch đi.

## 11. Bài học chính: agent giỏi hơn khi giữ ít hơn

Martin tóm lại cả bốn cặp:

- Nếu một kết luận sai được lưu lại, đó là poisoning, nên hãy **validate**.

- Nếu history đã chiếm quyền điều khiển, đó là distraction, nên hãy **compact**.

- Nếu agent có nhiều tool hơn mức task cần, đó là confusion, nên hãy **curate**.

- Và nếu context tự mâu thuẫn với chính nó, đó là clash, và cách sửa là **prune**.

![Lightboard cuối với bốn failure mode, bốn cách sửa và ô No Retry Code đã bị gạch](https://homus.dev/photos/BwXremQ-i6I-1003.jpg)

Bảng hoàn chỉnh: mỗi failure mode có cách sửa khoanh tím bên dưới (Validate, Compact, Curate, Prune), và ô "No Retry Code" trên Message History đã bị gạch chéo.

Cả bốn cách sửa đều hoạt động bằng cách vứt bớt một thứ gì đó đi. Một agent có thể làm tốt hơn ở các tác vụ dài bằng cách giữ ít hơn.

Bản tóm tắt của Martin dưới dạng bảng: mỗi failure mode, dấu hiệu nhận ra nó, và cách sửa. Cả bốn cách sửa đều là bỏ bớt thứ gì đó khỏi window.

Martin khép lại bằng một câu hỏi cho người xem: bạn giữ context của agent gọn nhẹ bằng cách nào, và bạn có cách context engineering riêng nào không? Anh mời mọi người chia sẻ ở phần bình luận.

## Nguồn và liên kết

- Tên gốc: Context Engineering for AI Agents: 4 Failure Modes to Avoid
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=BwXremQ-i6I](https://www.youtube.com/watch?v=BwXremQ-i6I)

- Kênh YouTube IBM Technology (Martin Keen): [youtube.com/channel/UCKWaEZ-_VweaEx1j62do_vQ](https://www.youtube.com/channel/UCKWaEZ-_VweaEx1j62do_vQ)

- IBM Think, "What is context engineering?", trang IBM giới thiệu context engineering được dẫn trong phần mô tả video: [ibm.com/think/topics/context-engineering](https://www.ibm.com/think/topics/context-engineering)

Nguồn: https://homus.dev/talks/context-engineering-for-ai-agents-4-failure-modes-to-avoid · cập nhật 2026-10-16