Blog / Series AI Agents Thực Chiến

Context Engineering 2026: Work IQ, Fabric IQ và Web IQ đang biến context thành asset cốt lõi của agent

Vấn đề gốc: nơi agent thường hỏng nhất là lớp context

Phần lớn lỗi của agent production không đến từ việc model “dốt”. Nó đến từ việc model được đặt vào một bối cảnh sai, thiếu hoặc quá nhiễu. Một agent có thể rất giỏi suy luận, nhưng nếu nó không biết người dùng này là ai, đang ở bước nào của quy trình, dữ liệu nào là mới nhất, quyền nào đang có hiệu lực và khi nào phải hỏi lại con người, thì kết quả vẫn dễ lệch.

Đây là lý do các bài trước trên AIWiki như State of AI Agent Memory 2026, Agent Reliability 2026 và Workflow, memory, approval đều chạm vào cùng một sự thật: độ thông minh của agent chỉ có ý nghĩa khi context đủ tốt.

Điểm mới của 2026 là các nhà cung cấp lớn bắt đầu gọi đích danh lớp này bằng tên riêng. Họ không còn nói mơ hồ về “prompt tốt hơn”. Họ nói về context layer, retrieval planning, workspace intelligence, semantic foundation và live web grounding. Đó là một chuyển dịch rất đáng chú ý.

Context engineering là gì, khác prompt engineering ra sao

Prompt engineering tối ưu phần bạn nói gì với model. Context engineering tối ưu model được phép biết gì, biết theo thứ tự nào, từ đâu, trong trạng thái nào, và với quyền nào.

Nếu prompt là câu hỏi đặt ra, thì context là toàn bộ hệ thống tín hiệu đứng sau câu hỏi đó. Nó thường bao gồm:

• dữ liệu người dùng và tổ chức,
• trạng thái workflow hiện tại,
• memory ngắn hạn và dài hạn,
• kết quả retrieval từ tài liệu, search và database,
• chính sách quyền, approval và audit,
• tín hiệu thời gian thực từ web, màn hình hoặc ứng dụng đang mở.

Điều đáng nói là context engineering không chỉ giúp trả lời hay hơn. Nó quyết định agent có hành động đúng hay không. Một agent có thể biết trả lời email rất tốt, nhưng nếu nó không biết email đó thuộc luồng nào, mức độ khẩn cấp ra sao, hay có cần chuyển sang người thật không, thì vẫn có thể gây thiệt hại.

Câu chuyện này nối trực tiếp với bài AI Agent Identity 2026: context tốt luôn đi cùng identity tốt. Không có danh tính và ranh giới quyền rõ ràng thì context chỉ khiến agent tự tin sai nhanh hơn.

Ba lớp context nên tách ra

Để không biến mọi thứ thành một đống prompt dài, nên tách context thành ba lớp:

1. Operational context: bước đang làm, task id, trạng thái workflow, deadline, SLA.
2. Knowledge context: tài liệu, CRM, ticket, chính sách, lịch sử tương tác, dữ liệu sản phẩm.
3. Control context: quyền, policy, mức confidence, approval, vùng dữ liệu nhạy cảm.

Nếu trộn cả ba vào một prompt duy nhất, bạn sẽ rất khó debug. Nếu tách ra, bạn có thể cache, cập nhật, kiểm tra và kiểm soát từng phần riêng.

Use case end-to-end: trợ lý vận hành cho team bán hàng

Giả sử một team bán hàng B2B có ba nguồn việc chính mỗi ngày:

• khách hỏi báo giá và điều khoản,
• sales rep cần tóm tắt lịch sử account trước cuộc gọi,
• manager cần biết deal nào đang kẹt vì pháp lý, giá hoặc người duyệt.

Đây là môi trường lý tưởng để context engineering phát huy tác dụng, vì dữ liệu nằm rải ở email, CRM, docs nội bộ, lịch họp, bảng giá và ticket hỗ trợ.

Luồng làm việc

1. Agent nhận một task: “Chuẩn bị brief cho cuộc gọi với Công ty A lúc 15:00”.
2. Context layer kéo về account profile, lịch sử email, ticket mở, file proposal gần nhất, trạng thái deal trong CRM và các mốc thời gian liên quan.
3. Retrieval planning quyết định phần nào cần đọc từ tài liệu, phần nào cần query live data, phần nào nên bỏ qua vì cũ hoặc trùng lặp.
4. Agent tạo brief ngắn, gắn rủi ro và đề xuất câu hỏi cần hỏi lại khách.
5. Nếu agent muốn gửi email follow-up hoặc sửa giá, control context buộc nó đi qua approval.

Điểm khác biệt là agent không còn dựa vào một prompt dài cố định. Nó được cung cấp một bản đồ ngữ cảnh có chủ đích. Điều này làm giảm hallucination, giảm việc lấy nhầm dữ liệu cũ và tăng khả năng audit.

Đây cũng là chỗ các công bố kiểu Work IQ, Fabric IQ và Web IQ trở nên đáng chú ý. Work IQ gom lại “cách công việc diễn ra” trong workspace. Fabric IQ tạo nền ngữ nghĩa cho dữ liệu cấu trúc. Web IQ giữ vai trò grounding ra thế giới thật. Một hệ context layer tốt không phải chỉ là RAG nhiều hơn, mà là phân phối đúng loại context vào đúng thời điểm.

Kiến trúc một context layer thực dụng

Muốn context engineering có ích trong production, nên coi nó là một hệ con của runtime, không phải vài hàm tiện ích quanh prompt.

1. Context ingestion

Lớp này hút dữ liệu từ email, docs, CRM, ticket system, calendar, database, browser session và các nguồn web hợp lệ. Mấu chốt không phải hút nhiều nhất, mà là hút theo độ tin cậy và độ mới.

2. Normalization và semantic indexing

Dữ liệu thô cần được chuẩn hóa thành entity, event, relation và policy signals. Nếu không, retrieval sẽ chỉ là tìm kiếm văn bản chứ chưa phải hiểu ngữ nghĩa công việc.

3. Retrieval planning

Đây là lớp quyết định “đọc gì trước, đọc gì sau, dùng nguồn nào, bỏ nguồn nào”. Không có lớp này, agent thường nhồi quá nhiều context, vừa tốn token vừa làm loãng tín hiệu.

4. Context budget

Mọi agent đều có giới hạn. Context engineering tốt phải biết ưu tiên. Những phần có xác suất ảnh hưởng cao nhất đến quyết định nên được đưa vào trước. Những phần phụ trợ nên được tóm tắt hoặc giữ ở mức tham chiếu.

5. Policy and redaction

Không phải context nào cũng được phép vào prompt. Một context layer nghiêm túc phải biết che bớt dữ liệu nhạy cảm, gắn nhãn nguồn, kiểm tra phân quyền và ghi log việc truy cập.

6. Memory write-back

Agent không chỉ đọc context. Nó còn tạo context mới sau mỗi run: quyết định đã làm, tri thức học được, trạng thái cập nhật và mốc cần revisit. Nếu write-back kém, agent sẽ “quên có hệ thống”.

Trade-off và failure mode thường bị xem nhẹ

Context engineering nghe rất hấp dẫn, nhưng nếu làm ẩu sẽ tạo ra một loại phức tạp mới.

1. Context càng nhiều, độ tin cậy không tự động tăng

Nhồi thêm tài liệu không đồng nghĩa với hiểu tốt hơn. Khi context quá rộng, agent dễ bị phân tán, mất tín hiệu quan trọng và tốn chi phí suy luận nhiều hơn.

2. Retrieval sai còn nguy hiểm hơn không retrieval

Agent lấy đúng một đoạn tài liệu sai phiên bản có thể dẫn tới quyết định sai rất tự tin. Điều này nguy hiểm hơn việc agent thừa nhận “tôi không biết”.

3. Context stale là lỗi rất khó thấy

Rất nhiều lỗi trong thực tế không phải lỗi logic mà là lỗi dữ liệu cũ. Deal đã đóng nhưng context vẫn báo mở. Policy đã đổi nhưng memory chưa cập nhật. Người duyệt đã vắng nhưng approval vẫn hiện là hợp lệ.

4. Control context làm hệ thống chậm hơn, nhưng đó là cái giá cần trả

Nếu muốn agent thật sự đáng tin, bạn phải chấp nhận thêm bước kiểm tra quyền, approval và audit. Đây không phải chi phí thừa. Đây là chi phí để tránh tự động hóa sai.

5. Web grounding mở rộng hiểu biết, đồng thời mở thêm bề mặt rủi ro

Lấy dữ liệu web live giúp agent biết tình hình mới nhất, nhưng cũng mở ra nguy cơ nhiễm nguồn, prompt injection từ nội dung ngoài và nhiễu tín hiệu. Vì vậy, web context phải được lọc và gắn nhãn khác với dữ liệu nội bộ.

Failure mode nên test sớm

• agent đọc nhầm tài liệu cũ vì index chưa re-sync,
• agent ưu tiên nguồn noisy hơn nguồn chuẩn,
• agent đưa dữ liệu nhạy cảm vào prompt do redaction sai,
• agent dùng context hợp lệ nhưng ở sai người dùng hoặc sai tenant,
• agent viết memory mới nhưng không gắn version hay nguồn gốc.

Checklist triển khai trước khi mở rộng quyền

Nếu bạn muốn đưa context engineering vào production, hãy đi theo thứ tự này.

1. Xác định một workflow thật

• Chọn tác vụ có dữ liệu thật, outcome rõ và lỗi dễ đo.
• Đừng bắt đầu từ “trợ lý tổng hợp mọi thứ”.

2. Tách dữ liệu thành các nguồn có nhãn

• Public, internal, sensitive, ephemeral.
• Nguồn nào cũng phải có owner và quy tắc hết hạn.

3. Thiết kế retrieval plan trước khi tăng context window

• Ưu tiên chọn đúng dữ liệu trước.
• Chỉ mở rộng context window khi retrieval đã tốt.

4. Gắn confidence và policy vào mọi hành động

• Hành động đọc có thể tự động.
• Hành động ghi, gửi, xóa, sửa phải có ngưỡng và approval rõ.

5. Ghi log đủ để replay

• Lưu nguồn context nào đã được dùng, phiên bản nào, ai là người yêu cầu và agent đã quyết định gì.
• Nếu không replay được, bạn sẽ không debug được khi hệ thống lệch.

6. Đo bằng kết quả vận hành, không chỉ bằng chất lượng câu trả lời

• Theo dõi tỉ lệ brief đúng, tỉ lệ phải sửa tay, thời gian hoàn tất task, số lần lấy nhầm dữ liệu và số lần cần approval lại.
• Chất lượng hội thoại tốt chưa chắc là chất lượng vận hành tốt.

Insight cuối cùng: context đang trở thành lớp tài sản, không còn là lớp phụ trợ

Model đang ngày càng dễ thay thế. Prompt cũng ngày càng bớt là lợi thế dài hạn. Lớp sẽ quyết định ai thắng trong agent production là lớp context: dữ liệu nào được đưa vào, được đưa theo thứ tự nào, được bảo vệ ra sao, và được cập nhật thế nào qua thời gian.

Nếu nhìn sâu hơn, context engineering thực chất là bài toán biến tri thức rời rạc thành năng lực hành động có kiểm soát. Đó là khác biệt lớn nhất giữa một chatbot “trông có vẻ hiểu” và một agent có thể sống trong tổ chức thật.

Vì thế, những cái tên như Work IQ, Fabric IQ hay Web IQ không chỉ là marketing layer. Chúng phản ánh một chuyển dịch kiến trúc rất thật: context trở thành hệ điều hành ngầm của agent. Ai thiết kế lớp đó tốt hơn sẽ có agent hiểu tổ chức tốt hơn, ra quyết định ít sai hơn, và có cơ hội scale lâu hơn.