Chẳng là gần đây, mình dành khá nhiều thời gian để tự build các AI Agent cho dự án thực tế. Hồi mới bắt đầu, mình từng có một niềm tin mãnh liệt rằng: Viết prompt hay bằng với việc AI làm tốt.
Sự thật là mình đã sai hoàn toàn.
Hồi đó, mình cứ loay hoay cặm cụi chỉnh prompt. Mình thêm ví dụ, thêm hướng dẫn, nhét đủ thứ rào cản vào. Cái prompt ngày càng dài hơn, chi tiết hơn. Nhưng kết quả trả về? AI vẫn cho ra thứ không đúng ý mình, đôi lúc làm việc cực kỳ "ngáo".
Mình cứ lấn cấn mãi không hiểu vì sao, cho đến khi vô tình đọc được một câu cực kỳ giá trị và nó đã thay đổi hoàn toàn cách mình suy nghĩ:
"Câu hỏi không phải là 'làm sao trick AI viết code tốt?' — mà là: nhân viên mới cần biết gì để làm được việc, và mình đã cung cấp cho AI chưa?"
Đó là khoảnh khắc mình nhận ra một sự thật phũ phàng: Vấn đề không nằm ở prompt. Vấn đề nằm ở Context (Ngữ cảnh).
Prompt Engineering vs. Context Engineering: Sự khác biệt thực sự
Sự khác biệt cốt lõi giữa Prompt Engineering và Context Engineering nằm ở tư duy tiếp cận vấn đề:
- Prompt Engineering là nghệ thuật viết câu hỏi hoặc mệnh lệnh thật khéo léo để nhận được kết quả mong muốn từ AI. Nó đặt câu hỏi: "Mình nói thế nào để AI hiểu?"
- Context Engineering là việc chuẩn bị toàn bộ môi trường — bao gồm thông tin, ràng buộc, ký tự và công cụ — để AI có đủ điều kiện tự chủ làm tốt công việc ngay từ đầu. Nó đặt câu hỏi: "AI cần biết những dữ kiện gì để không phải đoán mò?"
Hai khái niệm này trông có vẻ giống nhau, nhưng về bản chất kiến trúc thì khác biệt hoàn toàn.
6 Loại Context Một AI Agent Thực Sự Cần
Theo Whitepaper của Google AI Agents Intensive (May 2026), có 6 loại context thiết yếu mà mọi AI Agent cần được cung cấp để hoạt động chính xác:
1. Instructions (Định hướng vai trò)
Xác định rõ Role (vai trò) của agent là gì, mục tiêu cốt lõi của task ra sao, và giới hạn được phép làm gì. Đây là thứ hầu hết mọi người lầm tưởng là toàn bộ prompt, nhưng thực ra nó chỉ là một trong sáu mảnh ghép.
2. Knowledge (Nền tảng kiến thức)
Bao gồm tài liệu kiến trúc, quy chuẩn, và những hiểu biết đặc thù về miền dữ liệu (domain knowledge) của dự án. Không có điều này, AI sẽ giải quyết bài toán theo cách nó thấy phổ biến nhất, chứ không phải theo cách hệ thống của bạn đang hoạt động.
3. Memory (Trạng thái và lịch sử)
Được chia làm hai tầng: Short-term memory (Session - chuyện gì vừa xảy ra trong cuộc hội thoại này) và Long-term memory (Project state - dự án đang ở giai đoạn nào, những gì đã quyết định trước đó). Thiếu bộ nhớ, AI phải bắt đầu lại từ đầu ở mỗi lượt phản hồi.
4. Examples (Ví dụ tham chiếu)
Các đoạn code mẫu (few-shot demonstrations) hoặc pattern lấy từ codebase thực tế. Khả năng AI học "phong cách" của dự án qua các ví dụ thực tế luôn tốt hơn bất kỳ lời hướng dẫn dông dài nào.
5. Tools (Định nghĩa công cụ)
Danh sách chi tiết các API, script, hoặc dịch vụ bên ngoài mà agent được phép gọi. Quan trọng nhất là cách chúng hoạt động. Nếu mô tả công cụ mơ hồ, agent chắc chắn sẽ sử dụng sai cách.
6. Guardrails (Ràng buộc cứng)
Những giới hạn tuyệt đối (hard constraints): định dạng đầu ra (format output) nào bắt buộc dùng, hành động nào tuyệt đối cấm làm. Guardrails chính là hàng rào ngăn agent "sáng tạo" quá đà theo hướng bạn không muốn.
Thiếu bất kỳ loại context nào trong số trên — AI sẽ tự điền vào bằng cách nó thấy hợp lý. Không phải cách bạn cần.
Bẫy Phổ Biến: Context Rot (Ngộ độc ngữ cảnh)
Nghe đến 6 loại context trên, rất nhiều anh em liền dùng cách đơn giản nhất: Bê nguyên xi cả 6 thứ nhét hết vào System Prompt. Đây lại là một sai lầm chí mạng.
Trong kỹ năng sử dụng AI hiện tượng này được gọi là "Context Rot" (Ngộ độc ngữ cảnh) — việc nhồi nhét quá nhiều thông tin vào cùng một chỗ khiến AI bị loãng tín hiệu, không còn phân biệt được đâu là thông tin quan trọng nhất.
Nghiên cứu thực nghiệm trên 18 mô hình AI hàng đầu hiện nay (như Claude, Gemini, Qwen...) đã chỉ ra một kết quả đáng kinh ngạc: Độ chính xác giảm đáng kể rất lâu trước khi giới hạn bộ nhớ (context window) bị lấp đầy.
Lý do không phải vì AI hết chỗ nhớ, mà vì Signal (tín hiệu) đã bị Noise (tín hiệu nhiễu) lấn át. Những dữ liệu như output của tool, nội dung RAG nửa liên quan, hay các bước suy luận trung gian... chính là những nguồn tạo noise tệ nhất.
Giải pháp tối ưu: Static Context vs. Dynamic Context
Cách tiếp cận đúng đắn là phân tách context thành hai nhóm rõ ràng, dựa trên thời điểm AI thực sự cần chúng:
Static Context (Ngữ cảnh tĩnh — Luôn được cung cấp):
- Bao gồm: System instructions, file
AGENTS.md, global memory, persona definitions, và core guardrails. - Định nghĩa: Thông tin cốt lõi mà AI luôn cần phải biết, bất kể đang thực hiện task gì.
- Chi phí: Token bị tính phí ở mỗi lượt hội thoại, bất kể thông tin có được sử dụng hay không.
Dynamic Context (Ngữ cảnh động — Tải theo yêu cầu):
- Bao gồm: Agent Skills (kích hoạt khi task khớp mô tả), tool results, tài liệu RAG, và lịch sử chat được giới hạn (windowed session history).
- Định nghĩa: Thông tin chuyên biệt mà AI chỉ cần biết khi làm một task cụ thể.
- Chi phí: Tối ưu chi phí, chỉ tốn token khi thực sự cần dùng.
Ranh giới giữa hai loại context này không phải là một quyết định tùy hứng. Nó thực sự là một quyết định kiến trúc hệ thống. Lời khuyên của mình là hãy đưa nó vào version-control và review kỹ lưỡng như bất kỳ file configuration nào trong dự án.
The Factory Model: Output Của Developer Đã Thay Đổi
Đây là sự dịch chuyển tư duy (mindset shift) lớn nhất mà whitepaper đặt ra: Trong kỷ nguyên Agentic Engineering, output của một developer không còn là code nữa.
Sản phẩm chính của bọn mình bây giờ là hệ thống tạo ra code (còn gọi là "The Harness") — bao gồm:
- Rule files: Các bộ quy tắc như
AGENTS.md, instruction sets. - Eval suites: Bộ test chất lượng output của agent.
- Skill libraries: Thư viện kiến thức (unit of procedural knowledge) chuyên biệt.
- Guardrails: Công cụ rào chắn và kiểm duyệt an toàn.
- Observability: Hệ thống theo dõi và giám sát xem agent đang làm gì.
Tất cả những thành phần bao quanh model này chính là sản phẩm thực sự mà bạn cần xây dựng và maintain. Bản thân bạn không còn là thợ tự tay viết từng dòng code nữa.
Mà trở thành những kiến trúc sư.