Context Engineering là gì? Cách thiết kế ngữ cảnh cho AI Agent

Trong vài năm đầu của làn sóng AI tạo sinh, một kỹ năng được nhắc đến gần như ở mọi nơi: Prompt Engineering — viết câu lệnh thế nào để AI trả lời tốt hơn.

Nhưng khi chúng ta chuyển từ chatbot trả lời từng câu hỏi sang những AI Agent có thể đọc file, tìm dữ liệu, gọi công cụ, viết code, tự kiểm tra và làm việc qua hàng chục bước, câu hỏi quan trọng dần thay đổi.

Không còn chỉ là:

“Tôi phải viết prompt thế nào?”

Mà trở thành:

“Ở thời điểm này, AI cần nhìn thấy những thông tin nào để đưa ra quyết định đúng?”

Đó là bài toán của Context Engineering — kỹ thuật thiết kế và quản lý ngữ cảnh cho AI.

Điều thú vị là các model mới càng mạnh, cách làm Context Engineering cũng đang thay đổi. Anthropic cho biết với thế hệ Claude mới, họ đã loại bỏ hơn 80% system prompt của Claude Code mà không ghi nhận suy giảm đo được trên các bài đánh giá coding. Thay vì tiếp tục thêm luật và ví dụ, hướng tiếp cận mới là cho model nhiều không gian hơn để phán đoán, đồng thời cung cấp đúng thông tin vào đúng thời điểm.

Đây không chỉ là thay đổi dành cho người xây AI Agent.

Với Data Scientist, Data Engineer, Marketer làm Automation hay bất kỳ ai đang xây workflow bằng Claude Code, Codex hoặc các coding agent khác, nó đặt ra một câu hỏi lớn hơn:

Liệu chúng ta có đang dành quá nhiều thời gian để viết prompt, trong khi vấn đề thật lại nằm ở cách tổ chức context?

Prompt Engineering và Context Engineering khác nhau ở đâu?

Với một tác vụ AI đơn giản, prompt vẫn cực kỳ quan trọng.

Ví dụ:

Dữ liệu đầu vào
→ Prompt
→ Model
→ Kết quả

Bạn đưa một bảng dữ liệu vào, yêu cầu AI phân tích, model xử lý rồi trả về kết quả.

Thông tin cần thiết gần như nằm ngay trong lần gọi đó.

Nhưng một Agent hoạt động khác.

Ví dụ một coding agent có thể phải:

Đọc yêu cầu
→ xem cấu trúc repository
→ đọc instruction
→ tìm file liên quan
→ đọc code
→ chạy test
→ phát hiện lỗi
→ sửa code
→ chạy test lại
→ kiểm tra git diff
→ báo cáo kết quả

Phía sau một câu yêu cầu của người dùng có thể là rất nhiều lần gọi model và tool.

Trong trường hợp đó, prompt của người dùng chỉ là một phần nhỏ của toàn bộ thông tin AI đang sử dụng.

Anthropic mô tả context của một agent có thể bao gồm system instruction, tools, MCP, dữ liệu bên ngoài, lịch sử hội thoại, memory và các nguồn khác. Context Engineering vì vậy là việc chọn và duy trì tập thông tin phù hợp trong mỗi vòng suy luận, chứ không đơn thuần viết một prompt thật hay.

Có thể hình dung đơn giản:

Prompt Engineering
= Tôi nói gì với AI?

Context Engineering
= AI biết gì, nhìn thấy gì và có thể truy cập gì
  tại thời điểm nó phải quyết định?

Đây là hai lớp liên quan đến nhau, không phải cái mới hoàn toàn thay thế cái cũ.

Thay đổi số 1: Từ “thêm luật” sang “cho model quyền phán đoán”

Một phản xạ khá phổ biến khi AI làm sai là:

AI làm sai
→ thêm một instruction
→ lần sau lại sai kiểu khác
→ thêm instruction tiếp
→ instruction ngày càng dài

Cuối cùng chúng ta có một file hướng dẫn hàng nghìn dòng.

Vấn đề là các luật có thể bắt đầu xung đột.

Anthropic từng phát hiện chính hệ thống của họ chứa những chỉ dẫn chồng chéo như yêu cầu “thêm documentation khi thích hợp” ở một nơi nhưng lại hạn chế comment ở nơi khác. Model vẫn có thể xử lý, nhưng phải dành nhiều khả năng suy luận hơn để giải quyết chính những quy tắc do con người tạo ra.

Với các model mới, Anthropic chuyển từ:

Trước đây:
Hãy cho Claude thật nhiều rules.

Hiện nay:
Cho Claude đủ context để tự judgement.

Điều này không có nghĩa:

“Không cần instruction nữa.”

Mà là:

Chỉ nên quy định những thứ thực sự cần quy định.

Ví dụ trong một dự án Data Science, file instruction cấp cao chỉ cần cho Agent biết:

Đây là thư mục Exploratory Data Analysis.

Ưu tiên:
- khám phá dữ liệu trước khi biến đổi;
- không loại missing value nếu chưa kiểm tra;
- notebook được phép dùng để thử nghiệm;
- không coi output ở đây là production-ready.

Không cần viết thêm hàng trăm dòng hướng dẫn AI phải đặt tên từng biến thế nào nếu model có thể nhìn codebase và tự suy ra convention.

Thay đổi số 2: Context tốt không phải context thật nhiều

Một trong những hiểu nhầm nguy hiểm nhất là:

Context window càng lớn → cho AI càng nhiều thông tin càng tốt.

Thực tế không đơn giản như vậy.

Anthropic coi context là một nguồn lực hữu hạn. Khi lượng thông tin tăng lên, khả năng model tập trung chính xác vào thông tin cần thiết có thể giảm. Vì vậy mục tiêu không phải tối đa số token, mà là tìm tập token có tín hiệu cao nhỏ nhất nhưng đủ để hoàn thành nhiệm vụ.

Đây là khác biệt rất quan trọng:

Sai:
More Context = Better

Đúng hơn:
Relevant Context + Right Timing = Better

Một agent phân tích dữ liệu không nhất thiết cần đọc:

toàn bộ data warehouse;
toàn bộ documentation;
toàn bộ notebook;
toàn bộ quy trình modeling;
toàn bộ coding standard;

ngay từ đầu.

Nó chỉ cần biết những thứ nào tồn tại và cách tìm tới chúng.

Thay đổi số 3: Từ “nhét hết lên đầu” sang Progressive Disclosure

Đây có lẽ là nguyên tắc đáng ứng dụng nhất.

Progressive Disclosure có thể hiểu đơn giản là:

Chỉ mở thêm thông tin khi nhiệm vụ thực sự cần đến nó.

Bài viết của Towards Data Science đưa ra một ví dụ khá gần với công việc Data Science.

Thay vì tạo một file khổng lồ:

data.md

- load data
- validate schema
- clean missing value
- detect outlier
- transform
- feature engineering
- train model
- evaluate
- deploy
...

có thể xây dạng cây:

data.md

├── loading.md
├── quality-check.md
├── preprocessing.md
├── transformation.md
└── validation.md

data.md chỉ đóng vai trò router.

Nếu yêu cầu là:

“Load bộ dữ liệu này.”

Agent chỉ cần truy cập:

data.md
→ loading.md

Nó không cần tiêu tốn context cho feature engineering hay model evaluation.

Bài gốc gọi đây là cách xây một taxonomy of skills — cây kỹ năng, trong đó mỗi tác vụ nhỏ có context riêng.

Anthropic cũng đang đi đúng hướng này: những hướng dẫn như verification hay code review được tách thành Skill riêng để Agent chỉ tải khi cần thay vì luôn đặt chúng trong system prompt.

Thay đổi số 4: Thiết kế interface quan trọng hơn viết thật nhiều ví dụ

Trong các thế hệ model trước, chúng ta thường cung cấp rất nhiều ví dụ:

Nếu trường hợp A → làm X.
Nếu trường hợp B → làm Y.
Nếu trường hợp C → làm Z.

Cách này vẫn có giá trị, nhưng có một giới hạn.

Quá nhiều ví dụ có thể vô tình giới hạn không gian giải pháp mà model khám phá.

Với những model ngày càng có khả năng suy luận tốt hơn, Anthropic cho rằng cần chú ý nhiều hơn tới thiết kế interface và tool.

Ví dụ thay vì viết hàng chục dòng giải thích trạng thái task, một interface:

status:
- pending
- in_progress
- completed

đã cung cấp rất nhiều semantic signal cho model.

Tương tự trong Data Science, một cấu trúc:

/data/raw/
/data/processed/
/notebooks/
/src/features/
/src/models/
/tests/

đã mang ý nghĩa.

File ở /data/raw/ và file ở /data/processed/ dù cùng định dạng CSV nhưng rõ ràng không nên được xử lý giống nhau.

Cấu trúc hệ thống cũng là context.

Tên file là context.

Folder hierarchy là context.

Schema là context.

Metadata là context.

Timestamp cũng có thể là context.

Thay đổi số 5: Đừng bắt Agent ghi nhớ mọi thứ — hãy xây hệ thống để nó tìm lại được

Con người không nhớ toàn bộ Internet.

Chúng ta nhớ:

thông tin nằm ở đâu;
tìm bằng từ khóa gì;
bookmark nào chứa nó;
tài liệu nào đáng tin.

AI Agent cũng có thể hoạt động theo logic tương tự.

Anthropic mô tả chiến lược Just-in-Time Context: thay vì đưa toàn bộ dữ liệu vào context ngay từ đầu, Agent có thể giữ các tham chiếu nhẹ như:

file path
URL
stored query
database identifier

sau đó tự lấy thông tin cần thiết khi nhiệm vụ tiến triển.

Ví dụ:

Không làm:

Đưa 20 GB dữ liệu vào context.

Làm:

Cho Agent biết database tồn tại
→ Agent xác định table
→ xem schema
→ viết query
→ lấy subset cần thiết
→ phân tích.

Đây thực chất là một thay đổi quan trọng về tư duy:

Không cần làm AI “biết tất cả”. Hãy làm cho AI biết cách tìm đúng thứ nó cần.

Điều này thay đổi công việc của Data Scientist như thế nào?

Nếu trước đây workflow có thể bắt đầu bằng:

“Viết prompt tốt hơn.”

thì với agentic workflow, chúng ta nên đặt thêm một loạt câu hỏi.

1. Agent đang làm loại công việc nào?

Exploration và production không nên dùng cùng context.

Ví dụ:

EDA
→ ưu tiên khám phá
→ chấp nhận thử nghiệm
→ notebook phù hợp.

Production
→ ưu tiên reliability
→ test bắt buộc
→ xử lý lỗi rõ
→ code cần reproducible.

Chỉ cần Agent biết ngữ cảnh của công việc, rất nhiều quyết định nhỏ có thể được model tự suy luận.

2. Thông tin nào phải luôn có?

Đây là phần context lõi:

Project này làm gì?
Các constraint quan trọng là gì?
Điều gì tuyệt đối không được làm?
Convention nào không thể tự suy ra?

Nên giữ phần này ngắn và ổn định.

3. Thông tin nào chỉ cần khi gặp đúng task?

Đưa chúng vào Skill/module riêng.

Ví dụ:

loading-data/
preprocessing/
eda/
training/
evaluation/
deployment/
visualization/

4. Thông tin nào Agent có thể tự khám phá?

Nếu Agent có thể đọc repo, schema hoặc documentation thì không nhất thiết phải mô tả lại chúng bằng prompt.

Điều này vừa giảm duplication vừa giảm nguy cơ:

Code đã thay đổi
nhưng instruction chưa cập nhật.

5. Bài học nào cần lưu cho lần sau?

Ví dụ Agent từng tự động:

dropna()

nhưng team muốn luôn phân tích nguyên nhân missing trước.

Thay vì nhắc lại trong mọi prompt, có thể cập nhật skill preprocessing:

Before removing missing values:
1. quantify missingness;
2. inspect patterns;
3. assess possible mechanism;
4. document rationale;
5. only then choose treatment.

Một lỗi trở thành một cải tiến của hệ thống context.

Framework thực hành: 5 lớp Context cho AI Agent

Một cách đơn giản để thiết kế workflow là chia context thành 5 lớp.

Lớp 1 — Mission

Agent đang làm gì?

Phân tích dữ liệu?
Viết production code?
Nghiên cứu?
Audit?
Tạo báo cáo?

Lớp 2 — Guardrails

Những điều quan trọng không được vi phạm.

Ví dụ:

Không xóa dữ liệu gốc.
Không đưa secret vào code.
Không coi correlation là causation.
Không deploy production nếu chưa review.

Lớp 3 — Routing

Khi gặp từng loại vấn đề thì tìm context ở đâu?

Data quality → quality skill.
Visualization → visualization skill.
Training → training skill.
Deployment → deployment skill.

Lớp 4 — References

Nguồn dữ liệu thực tế:

code
schema
JSON
SQL
documentation
test
dashboard
dataset
HTML artifact

Không cần biến tất cả thành prompt.

Cho Agent truy cập nguồn gốc thường tốt hơn việc con người paraphrase lại chúng.

Lớp 5 — Memory & Feedback

Những bài học tích lũy qua quá trình sử dụng:

Preference
Known issue
Decision
Failure pattern
Convention
Lesson learned

Đây là nơi hệ thống dần trở nên phù hợp hơn với cách team thực sự làm việc.

Một ví dụ: từ “siêu prompt” sang Context System

Giả sử chúng ta muốn một AI Agent hỗ trợ Data Science.

Cách cũ

Một file:

DATA_SCIENCE_INSTRUCTIONS.md

dài hàng nghìn dòng:

Cách load data
Cách clean data
Cách xử lý NA
Cách xử lý outlier
Cách visualize
Cách train
Cách validate
Cách deploy
...

Mọi task đều tải toàn bộ.

Cách mới

AGENT.md

Mission
Guardrails
Project context
Skill routing
Known gotchas

Sau đó:

skills/
├── data-loading/
├── data-quality/
├── eda/
├── preprocessing/
├── feature-engineering/
├── modeling/
├── evaluation/
├── visualization/
└── production-review/

Agent nhận:

“Kiểm tra missing values của dataset này.”

Luồng context có thể trở thành:

AGENT.md
      ↓
data-quality
      ↓
missing-value guideline
      ↓
dataset/schema
      ↓
execute
      ↓
result

Thay vì:

Toàn bộ kiến thức Data Science
      ↓
Agent tự tìm xem phần nào cần dùng

Đó chính là giá trị của kiến trúc context.

Nhưng đừng biến Context Engineering thành một giáo điều mới

Bài gốc kết luận khá mạnh rằng khi model thất bại, nguyên nhân là nó đang nhìn sai thông tin hoặc không có đủ context.

Đây là một mental model hữu ích, nhưng nếu áp dụng tuyệt đối sẽ nguy hiểm.

Agent có thể thất bại vì:

dữ liệu nguồn sai;
model không đủ năng lực;
tool trả kết quả sai;
quyền truy cập thiếu;
API lỗi;
instruction xung đột;
retrieval tìm sai tài liệu;
workflow thiết kế sai;
state giữa các bước bị mất;
hoặc chính nhiệm vụ chưa được định nghĩa rõ.

Vì vậy khi Agent làm sai, đừng mặc định:

“Prompt chưa tốt.”

Nhưng cũng đừng mặc định:

“Context chưa đủ.”

Hãy debug như một hệ thống.

Một chuỗi kiểm tra hợp lý là:

Task definition
↓
Source data
↓
Available context
↓
Retrieved context
↓
Instructions
↓
Tools
↓
Model reasoning
↓
Verification
↓
Output

Đây cũng là điểm mà người làm Data có lợi thế lớn.

Chúng ta vốn đã quen với việc không tin ngay vào output cuối cùng mà truy ngược:

Metric
→ transformation
→ query
→ source

Với AI Agent cũng vậy.

Answer
→ reasoning context
→ retrieved information
→ source
→ tool

Context Engineering thực chất rất gần Data Engineering

Có thể Context Engineering nghe giống một thuật ngữ AI hoàn toàn mới.

Nhưng nhiều kỹ năng cốt lõi lại rất quen thuộc:

Data Engineering
→ đưa đúng data
→ đúng format
→ đúng nơi
→ đúng thời điểm.

Context Engineering
→ đưa đúng information
→ đúng representation
→ đúng agent
→ đúng thời điểm.

Khác biệt lớn nằm ở người tiêu thụ cuối pipeline.

Trước đây:

Database
→ pipeline
→ dashboard
→ con người quyết định.

Ngày càng nhiều workflow sẽ là:

Database
→ context layer
→ AI Agent
→ AI phân tích / quyết định / hành động.

Khi AI chỉ tạo một bản nháp, context sai có thể khiến một câu trả lời sai.

Nhưng khi AI được phép hành động, context sai có thể dẫn tới hành động sai.

Vì vậy Context Engineering không chỉ là bài toán tăng chất lượng câu trả lời.

Nó dần trở thành bài toán về độ tin cậy của hệ thống AI.

Checklist áp dụng ngay

Nếu đang dùng Claude Code, Codex hoặc một Agent tương tự, có thể bắt đầu bằng 7 câu hỏi:

Instruction gốc có đang quá dài không?
Có những rule nào model vốn có thể tự suy luận từ project không?
Có instruction nào mâu thuẫn hoặc trùng lặp không?
Có thể tách hướng dẫn lớn thành các Skill nhỏ không?
Agent có thể tìm context khi cần thay vì tải hết từ đầu không?
Code, schema, test và artifact có thể trở thành reference trực tiếp không?
Mỗi lỗi lặp lại có được biến thành cải tiến của context system không?

Nếu câu trả lời cho vài câu đầu tiên là “có”, có thể vấn đề không phải là cần viết thêm prompt.

Có thể đã đến lúc xóa bớt.

Kết luận: Kỹ năng mới không phải “nói với AI hay hơn”, mà là thiết kế môi trường để AI làm việc tốt hơn

Prompt Engineering chưa biến mất.

Một prompt rõ ràng vẫn quan trọng.

Nhưng khi AI chuyển từ chatbot sang Agent, prompt chỉ còn là phần nổi của hệ thống.

Phía dưới nó là:

Instructions
Skills
Memory
Files
Tools
Data
Metadata
References
History
Retrieval
Workflow
Verification

Và Context Engineering là cách chúng ta tổ chức những thành phần đó.

Điều đáng chú ý nhất từ thay đổi gần đây của Anthropic không phải việc họ tìm ra một “công thức prompt mới”.

Mà gần như ngược lại:

Model càng mạnh, chúng ta càng có thể bớt micromanage nó.

Thay vì cố viết mọi trường hợp có thể xảy ra, hãy:

Cho mục tiêu rõ.
Giữ guardrail quan trọng.
Thiết kế interface tốt.
Chia context thành module.
Cho Agent khả năng tìm thông tin.
Chỉ tải thông tin khi cần.
Lưu lại những bài học có giá trị.
Và kiểm chứng output bằng hệ thống.

Nếu Prompt Engineering tập trung vào câu lệnh, Context Engineering tập trung vào môi trường làm việc của AI.

Và khi AI Agent ngày càng trở thành một phần của Data, Automation và Software Workflow, năng lực thiết kế môi trường đó có thể sẽ quan trọng hơn rất nhiều so với việc thuộc lòng thêm một “công thức prompt”.

Nguồn tham khảo

Piero Paialunga, Context Engineering Is Changing. Here’s What It Means for Data Scientists, Towards Data Science, 30/08/2026.
Thariq Shihipar, The new rules of context engineering for Claude 5 generation models, Anthropic, 24/07/2026.
Anthropic Applied AI, Effective context engineering for AI agents, 29/09/2025.

Internal link đề xuất

Prompt Optimization: Vì sao prompt cũng cần được đo và tối ưu
AI Agent: hoàn thành task chưa có nghĩa là làm đúng
Cách xây Skills cho AI Agent
Vibe Coding: cách kiểm soát context khi AI làm việc với codebase