Context Engineering - Nghệ thuật Quản lý Ngữ cảnh cho LLM Agents 2026

Posted on: 4/14/2026 10:13:16 AM

Nếu prompt engineering là nghệ thuật viết ra một chuỗi ký tự duy nhất gửi vào LLM, thì Context Engineering là kỷ luật kỹ thuật của việc quản lý toàn bộ không gian token mà mô hình nhìn thấy tại mỗi bước suy luận. Khi các AI agent bước vào năm 2026 với vòng đời hàng trăm lượt gọi tool, hàng triệu token lịch sử và hàng chục sub-agent chạy song song, câu hỏi không còn là "viết prompt thế nào cho hay" - mà là "làm sao để mỗi token trong cửa sổ ngữ cảnh đều có giá trị tối đa". Bài viết này đi sâu vào kiến trúc, kỹ thuật và anti-pattern của Context Engineering - kỹ năng quyết định chất lượng, chi phí và độ ổn định của mọi hệ thống LLM Agent production.

1. Context Engineering là gì và tại sao nó thay thế Prompt Engineering?

Context Engineering là tập hợp các chiến lược để quản lý, sắp xếp và bảo vệ toàn bộ thông tin mà một LLM nhìn thấy khi thực hiện suy luận. Khác với prompt engineering vốn tập trung vào một prompt tĩnh, context engineering coi cửa sổ ngữ cảnh (context window) như một tài nguyên dynamic, có giới hạn và phải được tối ưu liên tục giữa các lượt gọi tool của agent.

Anthropic mô tả sự khác biệt khá rõ ràng: prompt engineering trả lời câu hỏi "viết prompt nào?", còn context engineering trả lời câu hỏi "tập token nào nên xuất hiện trong cửa sổ ngữ cảnh lúc này, và tại sao?". Với agent chạy 100 vòng lặp tool, câu trả lời cho mỗi vòng sẽ khác nhau - và chính khả năng thay đổi có kỷ luật này là bản chất của context engineering.

2. Context Rot - Kẻ thù thầm lặng của LLM Agents

Một ngộ nhận phổ biến: "Tôi có mô hình 1 triệu token, cứ nhồi hết tài liệu vào là xong." Thực tế, độ chính xác của LLM không tỉ lệ thuận với độ dài ngữ cảnh. Hiện tượng này được gọi là Context Rot - mô hình suy giảm khả năng suy luận khi ngữ cảnh dài ra, ngay cả khi vẫn còn dư budget token.

graph LR
    A["Ngữ cảnh ngắn
10K tokens"] -->|"Độ chính xác
~95%"| R1["Kết quả tốt"]
    B["Ngữ cảnh vừa
50K tokens"] -->|"Độ chính xác
~85%"| R2["Chấp nhận được"]
    C["Ngữ cảnh dài
200K tokens"] -->|"Độ chính xác
~65%"| R3["Bắt đầu rot"]
    D["Ngữ cảnh rất dài
1M tokens"] -->|"Độ chính xác
~40%"| R4["Mất tập trung"]
    style A fill:#4CAF50,stroke:#fff,color:#fff
    style B fill:#8BC34A,stroke:#fff,color:#fff
    style C fill:#ff9800,stroke:#fff,color:#fff
    style D fill:#e94560,stroke:#fff,color:#fff

Hình 1: Context Rot - độ chính xác suy giảm phi tuyến theo độ dài ngữ cảnh

2.1. Ba biểu hiện chính của Context Rot

Positional Bias (Thiên kiến vị trí): Mô hình xử lý tốt thông tin ở đầu và cuối ngữ cảnh, nhưng dễ bỏ lỡ thông tin nằm ở giữa. Hiện tượng này còn được gọi là "lost in the middle". Một chunk tài liệu quan trọng đặt ở vị trí token thứ 80.000 trong ngữ cảnh 150.000 token có thể bị mô hình gần như bỏ qua hoàn toàn.

Attention Dilution (Loãng attention): Cơ chế attention phân phối "ngân sách chú ý" cho mọi token. Khi số token tăng tuyến tính, mỗi token nhận được lượng attention nhỏ hơn. Kết quả: tín hiệu bị nhiễu bởi noise từ thông tin không liên quan.

Instruction Drift (Trôi lệnh): Khi lịch sử hội thoại dài, mô hình bắt đầu quên các ràng buộc đặt từ system prompt ban đầu - định dạng, phong cách, tool usage policy. Agent có thể bắt đầu trả lời "lan man" hoặc gọi tool sai format sau vòng thứ 30-40.

3. Giải phẫu Context Window hiện đại

Trước khi nói về kỹ thuật, cần hiểu cửa sổ ngữ cảnh của một LLM agent điển hình được chia thành những khu vực nào. Mỗi khu vực có vai trò, chi phí và chiến lược tối ưu khác nhau.

graph TD
    CTX["Context Window - 200K tokens"]
    CTX --> S1["1. System Prompt
3-10K tokens (cacheable)"]
    CTX --> S2["2. Tool Definitions
5-30K tokens (cacheable)"]
    CTX --> S3["3. Retrieved Knowledge
10-50K tokens (dynamic)"]
    CTX --> S4["4. Conversation History
20-100K tokens (rolling)"]
    CTX --> S5["5. Current Turn
1-5K tokens (hot)"]
    CTX --> S6["6. Response Budget
4-16K tokens (reserved)"]
    style CTX fill:#0f3460,stroke:#fff,color:#fff
    style S1 fill:#4CAF50,stroke:#fff,color:#fff
    style S2 fill:#4CAF50,stroke:#fff,color:#fff
    style S3 fill:#ff9800,stroke:#fff,color:#fff
    style S4 fill:#ff9800,stroke:#fff,color:#fff
    style S5 fill:#e94560,stroke:#fff,color:#fff
    style S6 fill:#888,stroke:#fff,color:#fff

Hình 2: Cấu trúc 6 tầng của một context window agent điển hình

3.1. Budget và ưu tiên theo tầng

4. Bốn trụ cột của Context Engineering

Anthropic và LangChain đã đúc kết context engineering thành bốn họ chiến lược - dùng phối hợp, không loại trừ nhau. Hiểu bốn trụ cột này là hiểu hầu như toàn bộ kỹ thuật production.

graph TD
    CE["Context Engineering"]
    CE --> P1["1. Offloading
Đưa thông tin ra ngoài LLM"]
    CE --> P2["2. Retrieval
Lấy đúng thứ, đúng lúc"]
    CE --> P3["3. Isolation
Cô lập giữa subtask"]
    CE --> P4["4. Reduction
Nén có kiểm soát"]
    P1 --> O1["Filesystem, Scratchpad, Database"]
    P2 --> O2["RAG, Just-in-Time, Progressive Disclosure"]
    P3 --> O3["Sub-agents, Separate sessions"]
    P4 --> O4["Summarization, Compaction, Truncation"]
    style CE fill:#e94560,stroke:#fff,color:#fff
    style P1 fill:#4CAF50,stroke:#fff,color:#fff
    style P2 fill:#0f3460,stroke:#fff,color:#fff
    style P3 fill:#ff9800,stroke:#fff,color:#fff
    style P4 fill:#2c3e50,stroke:#fff,color:#fff

Hình 3: Bốn họ chiến lược cốt lõi của Context Engineering

4.1. Offloading - Đẩy thông tin ra ngoài LLM

Nguyên tắc: Không mọi thông tin đều phải ở trong context window mọi lúc. Lưu dữ liệu ở hệ thống ngoài (filesystem, database, object store), chỉ nạp vào context khi cần.

Ví dụ: Thay vì đọc toàn bộ log 500MB vào context rồi hỏi "có bao nhiêu lỗi 500", agent viết script tính trực tiếp trên file, chỉ đưa con số kết quả vào context. Đây là lý do Code Interpreter và File System tool là hai tool quan trọng nhất của một agent chuyên nghiệp - chúng cho phép offload công việc xử lý dữ liệu thô.

4.2. Retrieval - Lấy đúng thứ, đúng lúc

Thay vì tải sẵn toàn bộ knowledge base vào context (front-loading), agent chủ động lấy thông tin tại thời điểm cần - gọi là Just-in-Time Retrieval. Pattern này có hai lợi ích: (1) tiết kiệm token, (2) đảm bảo thông tin là mới nhất tại thời điểm suy luận.

4.3. Isolation - Cô lập ngữ cảnh giữa subtask

Một agent lớn làm nhiều việc sẽ tích tụ lịch sử bẩn. Giải pháp: phân rã công việc thành nhiều sub-agent, mỗi sub-agent có context window sạch cho một subtask cụ thể, chỉ trả về tóm tắt cho agent cha.

4.4. Reduction - Nén có kiểm soát

Khi lịch sử vẫn vượt budget, cần rút gọn. Ba kỹ thuật chính: Truncation (xóa các turn cũ), Summarization (dùng LLM tóm tắt), Compaction (xóa chi tiết có thể tái tạo từ environment). Chọn sai kỹ thuật là nguyên nhân số một của agent "mất trí nhớ giữa chừng".

5. Prefix Caching - Nền tảng kinh tế của Context Engineering

Không có prefix caching (còn gọi là prompt caching hay context caching), hầu hết lý thuyết context engineering chỉ là tối ưu cho chi phí. Có prefix caching, các lựa chọn thiết kế mới thực sự trở nên hợp lý về mặt kinh tế. Anthropic báo cáo mức tiết kiệm tới 90% chi phí và 85% độ trễ cho các prompt dài có cache hit.

5.1. Cơ chế hoạt động

sequenceDiagram
    participant C as Client
    participant G as LLM Gateway
    participant K as KV Cache
    participant L as LLM
    C->>G: Request 1 - System + Tools + Query A
    G->>K: Lookup hash của prefix
    K-->>G: Miss
    G->>L: Full forward pass
    L-->>G: KV states + Response A
    G->>K: Store KV states cho prefix
    G-->>C: Response A
    Note over C,L: Request 2 - cùng prefix, khác query
    C->>G: Request 2 - System + Tools + Query B
    G->>K: Lookup hash của prefix
    K-->>G: Hit - trả KV states
    G->>L: Resume từ KV states, chỉ tính Query B
    L-->>G: Response B
    G-->>C: Response B - nhanh hơn 5-10x

Hình 4: Dòng chảy KV Cache - phần prefix trùng nhau được tái sử dụng

Về mặt kỹ thuật, Transformer tính toán mỗi token dựa trên các token trước đó thông qua các ma trận Key và Value (KV). Nếu prefix của hai request giống hệt nhau, các KV này có thể được tái sử dụng. Phần mới (suffix) chỉ cần được tính toán thêm vào, thay vì forward pass lại từ đầu.

5.2. Quy tắc vàng để maximize cache hit

{
  "model": "claude-sonnet-4-6",
  "system": [
    {
      "type": "text",
      "text": "You are a senior backend engineer..."
    },
    {
      "type": "text",
      "text": "[long coding guidelines and style guide]",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "tools": [
    { "name": "read_file", "...": "..." },
    { "name": "write_file", "...": "...",
      "cache_control": { "type": "ephemeral" }
    }
  ],
  "messages": [
    { "role": "user", "content": "Query A - phần động" }
  ]
}

Khi đặt cache_control vào block cuối của một prefix, mọi block trước đó cũng trở thành cacheable. Cache có TTL 5 phút (hoặc 1 giờ với extended caching), vì vậy các session liên tục của agent hưởng lợi rất lớn.

5.3. Cache-aware system design

Khi thiết kế agent, coi cache như một thành phần kiến trúc thực sự, không phải tối ưu hậu kỳ:

• Fixed tool order: Cố định thứ tự tool definitions, không sort động theo tên hay theo tần suất sử dụng.
• Stable system prompt: Đưa ngày giờ "hôm nay" vào tin nhắn user, không vào system prompt.
• Scoped templates: Một agent dùng một template system prompt duy nhất. Tránh sinh động system prompt theo từng loại task.
• Warm-up strategy: Gửi một request "nháp" ở đầu phiên để prefix được cache trước khi traffic thực đến.

6. Just-in-Time Retrieval - Pattern chủ đạo của agent hiện đại

Pattern truyền thống của RAG: ở mỗi request, embed query, lấy top-k chunk, nhét vào context, gọi LLM. Với agent dài 50-100 vòng, pattern này có ba vấn đề nghiêm trọng: (1) chunks cũ tích tụ, (2) noise chặn tín hiệu, (3) cache hit thấp do context luôn đổi.

Just-in-Time Retrieval đảo ngược tiếp cận: agent không có knowledge base trong context ban đầu. Thay vào đó, agent có các retrieval tools và chủ động gọi chúng khi cần - giống như một kỹ sư mở IDE và tìm file, thay vì đọc toàn bộ repo trước khi code.

graph TD
    Q["User query"] --> A["Agent
Lightweight context"]
    A --> D1["Decide: cần gì?"]
    D1 -->|"Cần code"| T1["grep_code tool"]
    D1 -->|"Cần docs"| T2["search_docs tool"]
    D1 -->|"Cần lịch sử"| T3["git_log tool"]
    T1 --> R1["Chỉ chunk liên quan"]
    T2 --> R2["Chỉ section liên quan"]
    T3 --> R3["Chỉ commit liên quan"]
    R1 --> SYN["Synthesize
in place"]
    R2 --> SYN
    R3 --> SYN
    SYN --> ANS["Câu trả lời"]
    style A fill:#e94560,stroke:#fff,color:#fff
    style SYN fill:#4CAF50,stroke:#fff,color:#fff

Hình 5: Just-in-Time Retrieval - agent chủ động điều phối retrieval tools thay vì front-loading

6.1. Ưu điểm kỹ thuật

• Progressive Disclosure: Agent chỉ thấy thông tin khi nó thực sự cần - tránh context rot từ trước.
• Freshness: Dữ liệu được lấy tại thời điểm suy luận, không phải từ snapshot đầu session.
• Cache-friendly: System prompt và tool definitions không đổi, prefix cache hit cao.
• Debuggable: Mỗi lần truy xuất có log riêng, dễ audit hơn "magic chunks" của classic RAG.

6.2. Trade-off thực tế

6.3. Hybrid Approach

Trong production, kết hợp cả hai thường là tối ưu: front-load những kiến thức "nền" không đổi (glossary, schema, policy), just-in-time cho dữ liệu động (code, logs, tickets). Đây cũng là cách Claude Code hoạt động - có một số knowledge tĩnh trong system prompt, nhưng mọi file thực tế được đọc qua tool.

7. Context Compaction vs Summarization - Chọn đúng kỹ thuật Reduction

Khi agent chạy dài, lịch sử tăng vượt giới hạn. Không thể giữ tất cả, phải rút gọn. Vấn đề: rút gọn sai cách làm agent "quên mất" mình đang làm gì. Có ba kỹ thuật chính, mỗi kỹ thuật phục vụ mục đích khác nhau.

7.1. Compaction - Kỹ thuật yêu thích của coding agent

Ví dụ điển hình: agent đã đọc file user_service.py ở vòng thứ 5, có toàn bộ nội dung 300 dòng trong context. Đến vòng thứ 40, agent đã tham chiếu tới file này hàng chục lần nhưng nội dung thực sự chỉ là một đoạn 10 dòng ở function create_user. Compaction xóa phần nội dung thô, để lại metadata "đã đọc file X, có function create_user, nếu cần lại thì đọc lại". Nội dung gốc vẫn tồn tại trên filesystem, có thể tái tạo bất kỳ lúc nào.

7.2. Summarization - Kỹ thuật cho long-horizon agent

Khi task thực sự dài (hàng trăm vòng, nhiều session), summarization là không thể tránh. Best practice từ Anthropic:

• Giữ nguyên các turn gần nhất (3-5 turn cuối) ở dạng raw, để agent giữ được "nhịp" format và tool use. Tóm tắt chỉ áp dụng cho phần lịch sử xa.
• Structured summary: yêu cầu LLM xuất ra tóm tắt theo template - goals đã hoàn thành, decisions đã đưa ra, open questions còn lại. Không để LLM tóm tắt tự do.
• Preserve tool signatures: danh sách tool đã dùng và các error đã gặp cần được liệt kê rõ, tránh agent lặp lại sai lầm cũ.

## Tóm tắt phiên làm việc (vòng 1-45)

### Mục tiêu
Refactor module thanh toán để tách PaymentProvider thành interface abstraction.

### Đã hoàn thành
- Đọc và phân tích src/payment/*.py (8 file, ~2400 dòng)
- Thiết kế interface IPaymentProvider với 4 method chính
- Viết StripeProvider kế thừa IPaymentProvider

### Quyết định quan trọng
- Không dùng ABC, dùng Protocol (PEP 544) cho flexibility
- Giữ backward compat với PaymentService API cũ qua adapter

### Mở đang dở
- Chưa viết test cho StripeProvider
- Cần migrate file src/payment/legacy.py cuối cùng
- Error cần nhớ: pytest fixture "db_session" bị conflict với mock

8. Sub-agent Isolation - Kỷ luật phân chia công việc

Cô lập ngữ cảnh (Context Isolation) là trụ cột số 3. Ý tưởng đơn giản: một agent không nên thấy toàn bộ noise của subtask mà nó delegate cho agent khác. Mỗi sub-agent chạy trong một context window riêng, thực hiện một việc cụ thể, và chỉ trả về một summary được compress.

graph TD
    M["Main Agent
Context: 30K"]
    M --> SA1["Sub-agent: Explore
Context riêng: 80K"]
    M --> SA2["Sub-agent: Summarize
Context riêng: 40K"]
    M --> SA3["Sub-agent: Verify
Context riêng: 25K"]
    SA1 -->|"Summary 2K"| M
    SA2 -->|"Summary 1K"| M
    SA3 -->|"Summary 500"| M
    M --> F["Final output"]
    style M fill:#e94560,stroke:#fff,color:#fff
    style SA1 fill:#4CAF50,stroke:#fff,color:#fff
    style SA2 fill:#0f3460,stroke:#fff,color:#fff
    style SA3 fill:#ff9800,stroke:#fff,color:#fff

Hình 6: Sub-agent Isolation - main agent giữ context nhỏ, sub-agent xử lý noise

8.1. Hiệu quả định lượng

Trong hệ thống multi-agent research của Anthropic, việc đưa các công việc explore và summarize sang sub-agent cho phép main agent giữ context nhỏ. Kết quả: độ chính xác trên các task nghiên cứu phức tạp vượt đáng kể so với cách tiếp cận single-agent. Lý do cốt lõi: sub-agent "ăn đạn" context rot thay cho main agent.

8.2. Pattern triển khai

• Role-based sub-agents: mỗi sub-agent chỉ được equip tool cần thiết cho vai trò - explorer có grep/list, summarizer có read, verifier có test runner.
• Parallel execution: các sub-agent không phụ thuộc nhau nên chạy song song, giảm latency end-to-end.
• Bounded output: ép sub-agent trả về kết quả theo schema cố định, max N token. Không cho phép "dump" raw output vào main.
• Stateless contract: sub-agent không biết về history của main. Đầu vào: nhiệm vụ rõ ràng. Đầu ra: summary có cấu trúc.

9. Memory Systems - Context xuyên session

Context window chết theo session. Memory là cơ chế cho phép agent nhớ xuyên session. Đây là nơi Context Engineering gặp gỡ kiến trúc hệ thống: file system, vector database, relational DB.

9.1. Mô hình file-based memory của Claude Code

Claude Code lấy hướng tiếp cận rất pragmatic: memory là file markdown trong thư mục dự án (CLAUDE.md, MEMORY.md). Khi session mới bắt đầu, agent đọc các file này vào context. Không vector database, không graph DB. Ưu điểm: (1) user kiểm soát được, (2) git-friendly, (3) debug được bằng mắt thường.

Pattern này dạy cho ta một bài học: memory không nhất thiết phải là vector store phức tạp. Với agent chuyên biệt, một file markdown hoặc vài dòng SQLite thường là đủ - và dễ hiểu hơn nhiều cho production support.

9.2. Khi nào cần Vector Memory?

10. Context Engineering trong Claude Code - Case study

Claude Code là reference implementation rõ ràng nhất của context engineering hiện đại. Kiến trúc của nó là sự kết hợp của cả bốn trụ cột.

graph TD
    U["User prompt"] --> SM["System prompt - cached"]
    SM --> TD["Tool definitions - cached"]
    TD --> MEM["CLAUDE.md memory - cached"]
    MEM --> HIST["Rolling history
Compaction khi vượt threshold"]
    HIST --> CUR["Current turn"]
    CUR --> LOOP["Agent loop"]
    LOOP -->|"Tool call"| TOOLS["Built-in + MCP tools"]
    TOOLS -->|"Just-in-time read"| FS["File system"]
    TOOLS -->|"Delegate"| SUB["Sub-agents
Explore/Plan/Test"]
    SUB -->|"Compressed summary"| LOOP
    LOOP --> OUT["Response"]
    style SM fill:#4CAF50,stroke:#fff,color:#fff
    style TD fill:#4CAF50,stroke:#fff,color:#fff
    style MEM fill:#4CAF50,stroke:#fff,color:#fff
    style HIST fill:#ff9800,stroke:#fff,color:#fff
    style CUR fill:#e94560,stroke:#fff,color:#fff
    style SUB fill:#0f3460,stroke:#fff,color:#fff

Hình 7: Context pipeline của Claude Code - cache-friendly prefix + just-in-time tools + sub-agents

10.1. Cache-first prefix

System prompt, tool definitions và CLAUDE.md được tổ chức theo thứ tự ổn định nhất trước. Mỗi lần một turn mới được gửi, phần prefix này ăn cache 100%. Chỉ phần history + current turn mới cần tính mới.

10.2. Just-in-time file access

Claude Code không dùng RAG preloading. Mọi file được đọc qua tool Read, grep qua tool Grep, tìm qua tool Glob. Agent tự quyết định đọc cái gì, khi nào. Hiệu quả: một session chỉnh sửa 20 file trong repo 10.000 file vẫn có thể giữ context ở mức vài chục K token.

10.3. Sub-agent cho exploration

Khi một câu hỏi "what files handle authentication?" xuất hiện, Claude Code có thể dispatch Explore sub-agent - sub-agent này grep/list hàng trăm file trong context riêng, chỉ trả về danh sách file liên quan + mô tả ngắn. Main agent giữ context nhỏ nhưng vẫn có được overview.

10.4. Compaction tự động

Khi context gần đầy, Claude Code tự động nén: tool results cũ được thay bằng placeholder, các turn raw được tóm tắt structured. Nó hoạt động đằng sau, user ít khi phải can thiệp.

11. Observability - Đo được thì tối ưu được

Không có observability, mọi chiến lược context engineering chỉ là phỏng đoán. Cần đo chính xác: mỗi request tiêu tốn bao nhiêu token? Cache hit rate là bao nhiêu? Token nào được "wasted" vào noise? Turn thứ bao nhiêu bắt đầu rot?

11.1. Stack quan sát khuyến nghị 2026

Sau khi ClickHouse mua lại Langfuse (tháng 1/2026), stack observability mặc định cho LLM agent đã hội tụ: OpenTelemetry (instrumentation) + Langfuse SDK v3 (LLM-aware spans) + ClickHouse (backend lưu trữ analytic). Đây là kiến trúc Langfuse đang chạy chính thức, cả cloud lẫn self-hosted.

graph LR
    APP["LLM Agent"] --> SDK["Langfuse SDK v3
OTEL-native"]
    SDK --> OTC["OTel Collector"]
    OTC --> CH["ClickHouse
MergeTree"]
    CH --> MV["Materialized Views
Cost, Latency, Rot"]
    MV --> HD["HyperDX UI"]
    MV --> ALERT["Alert: cache hit drop"]
    style APP fill:#e94560,stroke:#fff,color:#fff
    style SDK fill:#0f3460,stroke:#fff,color:#fff
    style CH fill:#4CAF50,stroke:#fff,color:#fff

Hình 8: Observability stack 2026 cho LLM Agent

11.2. Bốn metric cốt lõi

12. Anti-patterns thường gặp

Sau hàng trăm triển khai production, cộng đồng context engineering đã định danh được nhiều anti-pattern phổ biến. Biết để tránh:

13. Checklist Context Engineering cho Production

Danh sách kiểm tra có thể dùng ngay cho agent đang chuẩn bị lên production:

• System prompt < 10K token, tĩnh hoàn toàn, đặt ở đầu tuyệt đối
• cache_control đã được set ở block cuối của prefix tĩnh
• Tool definitions được sort ổn định, không sort động
• Mỗi timestamp/user ID chỉ xuất hiện trong user message cuối, không trong system
• Có retrieval tools, không front-load knowledge base trừ khi < 5K token
• Có threshold tự động compact khi context vượt 60-70%
• Sub-agents có role rõ ràng, output schema cố định, max_tokens bounded
• Observability: cache hit rate, context utilization, tool success rate đều có dashboard
• Alert khi cache hit rate giảm đột ngột (dấu hiệu có ai đó phá cache prefix)
• Chạy đánh giá regression sau mỗi thay đổi system prompt hoặc tool schema

14. Roadmap học Context Engineering

15. Kết luận

Context Engineering không phải một buzzword, nó là sự trưởng thành của kỹ thuật xây dựng LLM application. Nếu 2023 là năm của prompt engineering - viết câu lệnh khéo léo - thì 2026 là năm mà thành bại của một AI agent được quyết định bởi câu hỏi: "Tại turn thứ 40 của phiên làm việc, cửa sổ ngữ cảnh của bạn còn chứa những gì có giá trị?"

Năm điểm cốt lõi cần ghi nhớ:

• Tìm tập token nhỏ nhất, tín hiệu cao nhất - đó là nguyên tắc vàng duy nhất
• Prefix caching là infrastructure, không phải tối ưu - thiết kế cache-first ngay từ đầu
• Just-in-time > front-loading cho agent phức tạp, lâu dài
• Compaction giữ lại cái có giá trị, bỏ cái có thể tái tạo - đừng xóa bừa
• Sub-agent isolation là cách rẻ nhất để nhân đôi context window hiệu dụng

Context Engineering cùng với MCP, A2A Protocol, và Semantic Caching tạo thành bộ tứ kỹ năng không thể thiếu cho bất kỳ kỹ sư nào đang xây dựng hệ thống Multi-Agent AI nghiêm túc trong 2026. Ba giao thức đầu định nghĩa cách agent kết nối, context engineering định nghĩa cách agent suy nghĩ hiệu quả.