Context Engineering 2026: Khi nào nên để AI tự quyết và khi nào phải viết bằng code?

Tại hội nghị AGNTCon, chuyên gia Drew Breunig đã có bài nói ngắn mang tên "Context Fails & Fixes", đóng vai trò như một bản tổng kết hiện trạng của lĩnh vực context engineering (kỹ thuật ngữ cảnh). Ông lần theo hành trình từ cuối năm 2024 đến nay: cửa sổ ngữ cảnh phình to đến đâu, bộ công cụ khắc phục lỗi đã tiến hóa ra sao, và những thất bại mới nào đang xuất hiện khi các hãng tập trung huấn luyện mô hình agent tự vận hành harness.

Minh họa về kỹ thuật ngữ cảnh trong hệ thống AI

Bài học từ con người: ngay cả người với người cũng khó truyền đạt

Khi bàn với nhà xuất bản O'Reilly về cuốn sách The Context Engineering Handbook vào tháng 6/2025, Breunig nhận được một câu hỏi rất hợp lý: làm sao biết cuốn sách này không lỗi thời sau vài tuần? Với sách công nghệ AI, tốc độ lạc hậu là nỗi lo thường trực.

Câu trả lời của ông: đưa ra chỉ dẫn rõ ràng về việc nên và không nên làm, đồng thời bảo đảm các chỉ dẫn đó nhất quán và không nhiễu, sẽ mãi là thách thức, bất kể mô hình giỏi đến đâu.

Lập luận này rất đáng chú ý với người Việt làm công nghệ: đồng nghiệp và đối tác của chúng ta là người thật, vượt qua bài kiểm tra Turing, vậy mà chúng ta vẫn thường xuyên hiểu sai ý nhau. Context engineering sẽ tiếp tục khó, nhưng khó theo cách riêng, bởi mô hình không phải con người. Cách chúng được xây dựng, tối ưu và huấn luyện tạo ra những kiểu thất bại đặc thù mà ta buộc phải tính đến.

Giai đoạn 2024: ảo tưởng "nhét tất cả vào ngữ cảnh"

Cuối năm 2024 là đỉnh điểm của trào lưu "RAG đã chết". Kỳ vọng khi đó: chỉ cần cửa sổ ngữ cảnh đủ lớn để nhét cả internet vào, ta không cần chọn lọc, không cần hệ thống agent phức tạp, và bài toán AI coi như được giải.

Các hãng đua nhau nâng cửa sổ ngữ cảnh từ khoảng 128.000 token lên hàng triệu token, mở màn bằng Gemini 1.5. Tài liệu quảng cáo của Gemini 1.5 Pro chủ yếu xoay quanh con số một triệu token, thậm chí còn nhá hàng mô hình 10 triệu token đang nằm trong phòng thí nghiệm. Llama 4 Scout sau đó về đích trước với 10 triệu token, nhưng suy luận quá nặng, không tạo được tiếng vang, và dòng Llama cũng dừng ở đó.

Điệp khúc thời ấy rất đơn giản: cứ đưa hết vào ngữ cảnh rồi để mô hình tự xoay xở. Nhưng ngữ cảnh dài hơn cũng là chỗ chứa nhiều lỗi hơn.

Bốn kiểu thất bại kinh điển của ngữ cảnh

Breunig đúc kết bốn dạng lỗi mà giới làm AI đều đã gặp:

• Ngộ độc ngữ cảnh (context poisoning): một thông tin sai hoặc ảo giác lọt vào ngữ cảnh và mô hình không thể thoát ra khỏi nó.
• Xao nhãng ngữ cảnh (context distraction): ngữ cảnh dài đến mức mô hình chú ý vào chính ngữ cảnh thay vì tri thức nền của nó.
• Nhầm lẫn ngữ cảnh (context confusion): những dữ kiện không liên quan len vào và ảnh hưởng đến câu trả lời. Mô hình tự suy diễn về bạn là ai, rồi những giả định đó bẻ hướng kết quả. Đây là lỗi nguy hiểm nhất và cũng là lỗi tác giả tâm đắc nhất, dù bài nói không đi sâu.
• Xung đột ngữ cảnh (context clash): các lệnh gọi công cụ, kỹ năng và thông tin trong harness mâu thuẫn với nhau, quay ra chống lại người dùng.

Ví dụ sinh động nhất là chuyện mô hình chơi Pokémon. Trong báo cáo kỹ thuật của Gemini 2.5, nhóm nghiên cứu cho mô hình chơi game như một bài kiểm tra agent vì môi trường khá kiểm soát được. Ở bản Pokémon Red gốc năm 1996, muốn qua một gã bảo vệ khát nước, người chơi phải đưa hắn chai nước chanh. Bản FireRed năm 2004 đổi thành trà đá. Gemini 2.5 nhiều lần tin chắc mình cần tìm trà, dù đang chơi bản cũ, và dành hàng giờ loanh quanh tìm trà cho gã bảo vệ. Nhiệm vụ trà nằm sẵn trong trọng số của mô hình, nó tự đầu độc ngữ cảnh của mình.

Mô hình AI bị mắc kẹt trong vòng lặp nhiệm vụ

Bằng chứng khoa học: ngữ cảnh càng dài, hiệu suất càng tụt

Nghiên cứu Do as I Say, Not as I Do của Carolina Camassa và Derek Shiller minh họa rõ cơ chế xao nhãng. Nhóm tác giả yêu cầu mô hình dịch mọi câu hỏi sang tiếng Nga, rồi đưa vào hàng loạt ví dụ trái ngược, toàn câu trả lời tiếng Pháp trong lịch sử trò chuyện. Kết quả: mô hình nhỏ như Gemma 3 12B chỉ cần vài ví dụ sai là tuân thủ chỉ dẫn dưới 50% số lần. Ngay cả Opus 4.6, một mô hình rất mạnh, cũng gục ngã khi số ví dụ nhiễu tăng lên.

Hãy liên hệ với công việc hằng ngày: bạn chỉnh CSS qua lại hàng chục lượt để vừa ý một component. Mỗi lượt chỉnh hỏng là một ví dụ xấu gieo vào ngữ cảnh, và dần dần chúng chi phối câu trả lời của mô hình.

Ngay cả Gemini 2.5 khi chơi Pokémon cũng dính lỗi này. Báo cáo kỹ thuật ghi nhận: một khi ngữ cảnh vượt xa 100.000 token, agent bắt đầu lặp lại hành động cũ thay vì lập kế hoạch mới. Điều thú vị là quan sát này nằm sâu trong phần phụ lục, trong khi phần quảng cáo vẫn hào hứng với mốc 2 triệu token.

Sáu công cụ sửa lỗi vẫn giữ nguyên

Dù thách thức mới liên tục xuất hiện, bộ công cụ cốt lõi gần như không đổi, và ngày càng được đưa vào harness thay vì để trong ngữ cảnh:

1. Tăng cường ngữ cảnh (augmentation): RAG, kỹ năng, mọi cách đưa thông tin liên quan vào đúng lúc.
2. Chọn bộ công cụ (tool loadout): chỉ mở ra những công cụ cần thiết. Tác giả kể về một đội doanh nghiệp có agent đột nhiên chạy rất tệ, kiểm tra mới phát hiện phần mềm của họ nạp 600 kỹ năng cho mỗi kỹ sư ngay khi khởi động.
3. Cách ly ngữ cảnh (quarantine): dùng subagent khởi đầu với lịch sử trống nhưng vẫn làm việc trong cùng môi trường.
4. Tỉa ngữ cảnh (pruning): Claude Code và Codex âm thầm cắt bỏ những kết quả công cụ không còn cần, thường là ở giai đoạn đầu của quá trình nén.
5. Đẩy ngữ cảnh ra ngoài (offloading): lưu thông tin vào file Markdown hay cơ sở dữ liệu để tra cứu sau.
6. Tóm tắt ngữ cảnh (summarization/compaction): nén lịch sử thành bản tóm tắt ngắn.

Breunig dùng DSPy để chứng minh những mẫu này đơn giản đến mức nào. Một agent chỉ là vòng lặp while với module ReAct, nhận yêu cầu, trả phản hồi, gọi công cụ Python. Ông ghép thêm một mô hình quyết định cực nhỏ và siêu nhanh để lọc công cụ, cắt lượt hội thoại thừa, và chọn lọc trước khi nén. Tổng cộng khoảng 16 dòng thay đổi.

Kiến trúc harness với các công cụ quản lý ngữ cảnh

Từ prompt engineering đến harness engineering: tên đổi, việc không đổi

Cách gọi tên thay đổi gần như mỗi ngày. Năm 2023 gọi là prompt engineering, tức chọn đúng thông tin để có phản hồi đúng. Năm 2025 gọi là context engineering, khi hệ thống tự động lắp ghép ngữ cảnh thay vì con người gõ prompt. Rồi khi các công cụ dần được chuyển từ ngữ cảnh sang code, người ta gọi là harness engineering.

Nhưng bản chất công việc vẫn vậy: chuyển dần việc lắp ghép ngữ cảnh từ những lần gọi mô hình mang tính xác suất sang code tất định. Breunig dẫn câu nói của Stewart Brand: muốn biết tương lai đang được tạo ra ở đâu, hãy tìm nơi ngôn ngữ mới đang hình thành và giới luật sư đang tụ tập.

Giai đoạn 2026: các hãng chuyển sang huấn luyện mô hình tự lái harness

Mục tiêu mới không còn là nhét thật nhiều vào ngữ cảnh, mà là dạy mô hình tự điều khiển harness và tự quản lý ngữ cảnh của nó. Các báo cáo METR cho thấy GPT-5 xử lý được tác vụ dài khoảng 3,4 giờ, Gemini 3.1 lên 6,4 giờ, còn Opus 4.6 chạm mức 12 giờ. Giờ người ta nói đến agent chạy nhiều ngày, đến bầy agent, đến mô hình lái harness trong thời gian rất dài.

Cách tiếp cận này sinh ra hai kiểu thất bại mới.

"Đấu với trọng số"

Khi huấn luyện mô hình dùng harness thật giỏi, ta vô tình khiến nó quá khớp với bộ công cụ và môi trường cụ thể trong dữ liệu huấn luyện. Những mô hình nhỏ như Haiku hay Luna thường làm hỏng lần gọi Playwright MCP đầu tiên rồi mới sửa tham số, đơn giản vì công cụ chúng từng thấy khi huấn luyện trông khác đi.

Biểu hiện dễ nhận ra nhất là trong system prompt. Nếu mở prompt của Claude Code, ta thấy các chỉ dẫn lặp đi lặp lại, viết hoa, nhiều lần liên tiếp: hãy gọi công cụ song song khi chúng độc lập. Sự lặp lại ấy chính là dấu hiệu ta đang phải chống lại thói quen tuần tự mà mô hình được huấn luyện.

"Quán tính ngữ cảnh"

Đây là hiện tượng mô hình quá tập trung vào một giả thuyết, một nhiệm vụ con hay một mục tiêu trong ngữ cảnh, và tiếp tục theo đuổi nó kể cả khi đã đến lúc phải dừng. Bốn nhóm nghiên cứu độc lập cùng chạm đến vấn đề này chỉ trong một tuần.

Anthropic ghi nhận điều này khi thử nghiệm harness Memento: agent chạy quá lâu sẽ cố chấp với một nhiệm vụ con và lặp mãi một cách làm. Cách khắc phục rất đơn giản: cứ mỗi 90 phút, agent ghi lại một ghi chú ngắn, rồi ngữ cảnh bị xóa sạch trong khi môi trường và mọi thành quả vẫn được giữ nguyên.

Nhóm Microsoft Research công bố nghiên cứu Fork-and-Flush: trong các thí nghiệm tự nghiên cứu, agent đạt bước nhảy lớn rồi đường đồ thị phẳng lì. Nhìn kỹ thì chúng không hề ngồi không, mà chỉ sửa những thay đổi ngày càng nhỏ quanh một ý tưởng đã bám chặt, thay vì tìm hướng sáng tạo khác.

Còn nhóm của Shangyin Tan tại UC Berkeley với bài Scaling Discovery Requires Forgetting đưa ra kết luận tương tự: định kỳ xóa ngữ cảnh nhưng giữ lại sản phẩm trong môi trường. Mỗi lần "quên", hiệu suất lại nhảy thêm một bậc.

Điều đáng chú ý: dù mô hình đã tiên tiến hơn nhiều, cách sửa vẫn là những công cụ cũ, gồm cách ly, đẩy ra ngoài và xóa lịch sử tích lũy. Lời khuyên lặp đi lặp lại của Breunig rất thực tế: nếu agent lập trình của bạn hành xử kỳ lạ và ngữ cảnh đã lên tới 800.000 token, hãy xóa ngữ cảnh đi. Ông tự đặt ngưỡng cảnh báo khoảng 200.000 token.

Dọn dẹp ngữ cảnh để agent thoát khỏi vòng lặp cố chấp

Dự báo 2027: bài toán "quên có chiến lược"

Breunig cho rằng vấn đề ngữ cảnh tiếp theo sẽ nằm ở các trợ lý cá nhân như Hermes, OpenClaw, Dot, Bot hay Muse. Rất ít người thực sự trải nghiệm những harness này chạy liên tục hơn sáu tháng. Ông đã tự chạy một agent Hermes trong nửa năm và nhận ra các kỹ năng nó tạo, cập nhật dần dần có thể khiến cách giải quyết vấn đề trở nên tệ hơn chứ không tốt lên. Các kỹ năng tích tụ những bản vá kỳ quặc, bộ nhớ chồng chéo và mâu thuẫn với nhau.

Khi giới phát triển AI càng chú trọng bộ nhớ, họ cũng sẽ phải nghĩ đến quên có chiến lược: những ký ức quá chi tiết, theo thời gian, sẽ xung đột và lộn xộn, và chưa ai giải được bài toán này.

Kết luận: chọn đúng chỗ để tất định, đúng chỗ để xác suất

Công thức nền tảng vẫn không đổi: đầu ra của mô hình là tích của ngữ cảnh và trọng số. Muốn gỡ lỗi, phải hiểu dữ liệu huấn luyện. Muốn cải thiện, phải cung cấp ngữ cảnh đúng cho đúng mô hình, hoặc bằng quyết định thủ công của kỹ sư, hoặc bằng harness do chính ta thiết kế.

Trong ba lựa chọn là dùng mô hình lớn hơn, cho mô hình "suy nghĩ" lâu hơn, hay cải thiện ngữ cảnh, chỉ có một lựa chọn là rẻ và nhanh.

Nhiệm vụ của chúng ta khi xây dựng ứng dụng thông minh, harness và quy trình làm việc là chọn lúc nào nên tất định, tức đưa vào code, và lúc nào nên xác suất, tức để mô hình tự dẫn dắt.

Với các đội ngũ phát triển tại Việt Nam đang đưa AI vào sản phẩm thật, đây là lời nhắc thực dụng: đừng kỳ vọng mô hình tự lo mọi thứ chỉ vì cửa sổ ngữ cảnh đã lớn, và cũng đừng viết code cứng cho mọi tình huống. Giá trị nằm ở việc phân định ranh giới giữa hai phía.