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

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.

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.

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.

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.

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.

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.

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ũ.

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.

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.

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.

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.

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.

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.

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.

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.