Context Engineering: Kỷ nguyên tiếp theo sau prompt engineering

Context engineering là kỷ nguyên tiếp theo sau prompt engineering: không còn là việc viết prompt tốt hơn, mà là thiết kế toàn bộ pipeline xác định cách ngữ cảnh được tạo ra, lọc, tích lũy và tiến hóa qua từng lượt tương tác. Đây là sự thay đổi kiến trúc đang diễn ra âm thầm trong mọi hệ thống AI production, và hiểu nó là điều kiện để xây dựng AI thực sự hoạt động theo thời gian.

Tóm tắt các điểm chính

• Hệ thống AI production không hoạt động như API, chúng hoạt động như process: cần trạng thái, bộ nhớ và chuỗi tương tác phụ thuộc nhau
• Bộ nhớ không phải một thứ mà là năm loại khác nhau: Policy, Preference, Fact, Episodic và Trace, mỗi loại cần được lưu trữ và quản trị khác nhau
• Vòng lặp agent gồm năm pha: Ingest, Retrieve, Infer & Act, Evaluate và Promote, mỗi pha có điểm hỏng đặc thù
• Pha Evaluate là pha hầu hết hệ thống không có, và pha Promote là pha hầu hết team làm sai khi có
• Theo Infinity News Lợi thế cạnh tranh dài hạn không đến từ model (mọi người dùng cùng Claude, GPT, Gemini) mà từ memory layer, thứ bạn tự xây và không ai sao chép được

Sự thay đổi kiến trúc đang diễn ra

Trong vài năm qua, hầu hết mọi người đối xử với AI như một API. Bạn gửi prompt vào, nhận phản hồi ra, và nếu tinh tế hơn, bạn bọc nó với retry, thêm logging, và gọi đó là hệ thống. Cách đó đủ cho demo và giúp cả làn sóng này triển khai nhanh. Nhưng pattern đó dừng hoạt động ngay khi bạn cố xây thứ gì đó phải vận hành theo thời gian.

Hệ thống AI production không hoạt động như API. Chúng hoạt động như process. Khoảnh khắc bạn đưa tính liên tục vào, mọi thứ thay đổi. Bạn không còn xử lý một request và response đơn lẻ. Bạn đang xử lý một chuỗi tương tác phụ thuộc nhau. Bạn bắt đầu cần bộ nhớ. Bạn bắt đầu cần trạng thái. Bạn cần quyết định điều gì quan trọng lúc này, điều gì quan trọng năm phút trước, và điều gì vẫn nên quan trọng vào ngày mai.

Và khi bạn vượt qua ranh giới đó, bạn nhận ra đây không phải prompt engineering ở quy mô lớn. Đây là thiết kế hệ thống. Những gì bạn thực sự đang xây không phải prompt tốt hơn mà là hệ thống xác định cách ngữ cảnh được tạo ra, lọc, tích lũy và tiến hóa. Đó là không gian vấn đề thực sự. Đó là kỷ luật đang nổi lên. Đó là context engineering.

Context không phải prompt, context là thứ lắp ráp nên prompt

Mở bất kỳ production agent nào trong debugger và nhìn vào những gì thực sự được gửi đến model trong một lượt cụ thể. Hầu như không bao giờ chỉ là tin nhắn của người dùng. Một request điển hình trông như thế này: tin nhắn người dùng là phần nhỏ nhất của payload. Mỗi khối khác là thứ hệ thống của bạn tạo ra, chọn lọc, nén, xếp hạng và đưa vào. Những khối đó là đầu ra của một pipeline mà bạn đã thiết kế, dù bạn không nhận ra mình đang thiết kế nó.

Pipeline đó mới là sản phẩm thực sự. Model là runtime. Context engineering là việc thiết kế pipeline. Khi bạn chấp nhận sự phân biệt đó, kiến trúc trông rất khác.

Bộ nhớ không phải một thứ duy nhất

"Thêm bộ nhớ" là câu mới của "thêm caching." Nghe như một tính năng, nhưng thực ra là nhiều hệ thống khác nhau cùng chung một tên. Nếu bạn không phân tách chúng, bạn sẽ kết thúc với một blob store trả lời mọi câu hỏi đều tệ — hay quên ở những chỗ này, ám ảnh ở những chỗ khác.

Phân biệt đầu tiên là bộ nhớ ngắn hạn (STM) và bộ nhớ dài hạn (LTM). Bộ nhớ ngắn hạn là bất cứ thứ gì đang nằm trong cửa sổ ngữ cảnh, working set mà model có thể thấy ở lượt này. Bộ nhớ dài hạn là mọi thứ tồn tại sau một lần gọi: sự kiện, artifact, kế hoạch, quyết định trước đó, kết quả công cụ và quy tắc. Bộ nhớ ngắn hạn là bài toán ngân sách. Bộ nhớ dài hạn là bài toán hệ thống. Năm loại bên dưới đều là bộ nhớ dài hạn, được tổ chức theo mục đích và cách lưu trữ.

Policy memory là các quy tắc và ràng buộc chuẩn mực. Thường có phạm vi toàn cầu hoặc theo tenant. Được phiên bản hóa và kiểm soát chặt. Đây là những gì hệ thống được phép làm: quy tắc tuân thủ, giới hạn thương hiệu, ranh giới bảo mật. Nó thay đổi hiếm khi và có chủ ý. Đây là dạng bộ nhớ quy trình trong khung nhận thức học, các quy tắc và workflow định hình hành vi xuyên phiên. Cùng danh mục với các file như CLAUDE.md hay AGENTS.md trong filesystem-first agent.

Preference memory là các tham số cá nhân hóa ổn định. Thường có phạm vi theo người dùng. Người dùng này muốn phản hồi JSON, người dùng kia thích bullet point, tenant này định dạng ngày DD/MM/YYYY. Preference memory là thứ làm hệ thống cảm thấy được tùy chỉnh mà không cần được nhắc lại mỗi phiên.

Fact memory là các khẳng định bền vững mà agent có thể tái sử dụng. Phải bao gồm provenance. "Database production của khách hàng nằm ở us-east-1" là một fact. "Năm tài chính của họ bắt đầu vào tháng 4" cũng vậy. Facts là nơi lợi thế cộng hưởng sống, và cũng là nơi có những vấn đề thiết kế khó nhất, vì mỗi fact bạn viết là một cược về tương lai.

Episodic memory là các bản tóm tắt có cấu trúc của công việc đã hoàn thành. "Case đã giải quyết." "Migration hoàn tất." "Ngoại lệ được cấp phép." Các artifact có thể tái sử dụng được trích xuất và tóm tắt từ trace, không phải trace thô. Episodic memory là thứ giúp hệ thống nhận ra chúng ta đã làm điều này trước đây và truy xuất lại hình dạng của giải pháp trước đó.

Trace memory là các sự kiện thực thi thô, chỉ có thể thêm vào. Đây là hộp đen ghi chú của bạn. Khối lượng lớn, hữu ích chủ yếu cho truy xuất và replay, và không phải nơi đúng để xem khi bạn muốn biết người dùng như thế nào mà chỉ là họ đã làm gì.

Working memory không nằm trong danh sách này vì nó không phải bộ nhớ dài hạn. Đó là cửa sổ ngữ cảnh, working set mà model thực sự có thể thấy ở lượt hiện tại. Nó là tạm thời theo định nghĩa, và việc nhầm lẫn nó với các kho lưu trữ bền vững ở trên là thứ tạo ra các kiến trúc mà scratchpad và system of record dùng chung một database. Chúng không nên dùng chung.

Khi ai đó nói "agent của chúng tôi có bộ nhớ," hãy hỏi họ có ý nói đến loại nào trong năm loại này. Nếu câu trả lời là "chúng tôi dump mọi thứ vào một vector store," bạn vừa tìm ra lý do tại sao agent của họ hay quên ở một số chỗ và ám ảnh ở những chỗ khác.

Vòng lặp agent và những điểm hỏng thực sự

Mọi hệ thống AI production cuối cùng đều hội tụ về cùng một hình dạng. Không phải pipeline. Là vòng lặp. Giải phẫu năm pha này xuất hiện ở mọi cách tiếp cận, dù bạn đến từ agent harness, database hay prompt. Điều quan trọng không phải biết tên các pha mà là biết điểm hỏng của từng pha để quyết định nên đầu tư kỹ thuật vào đâu.

Ingest hỏng khi bạn chấp nhận quá nhiều. Đây là nửa đầu của việc lắp ráp ngữ cảnh: hấp thụ đầu vào thô từ môi trường. Coi mọi sự kiện là ngữ cảnh tiềm năng tạo ra nhiễu mà retrieval phải hoàn tác sau đó. Kỷ luật ở đây nằm ở ranh giới. Bạn đang từ chối hấp thụ gì?

Retrieve hỏng một cách âm thầm. Đây là nửa sau của lắp ráp ngữ cảnh: chọn tập con nào của bộ nhớ dài hạn quan trọng lúc này. Nó không ném exception khi trả về chunk sai, nó chỉ làm model nghe có vẻ hơi lạc lõng. Retrieval là pha mà hầu hết team đầu tư thiếu và pha tương quan chặt chẽ nhất với chất lượng hệ thống được cảm nhận. Semantic search thuần túy là bản nháp đầu tiên. Baseline production là metadata filtering cộng hybrid retrieval (từ khóa và ngữ nghĩa) với reranking.

Infer & Act hỏng khi ngữ cảnh điều khiển hành vi sai. Đây là gọi model và thực hiện hành động gộp làm một, vì lập kế hoạch và gọi công cụ đều là hệ quả của những gì ngữ cảnh đã lắp ráp khiến model quyết định làm. Đây là nơi các failure mode long-context cắn: lost-in-the-middle, attention dilution, context rot. Trực giác thông thường là nhiều ngữ cảnh hơn sẽ cải thiện phản hồi đơn điệu. Trong thực tế, nhiều token hơn thường làm model tệ hơn. Ngân sách ngữ cảnh giờ là một kỷ luật thực sự.

Evaluate là pha hầu hết hệ thống không có. Nó đưa phản hồi vào hệ thống bằng cách quan sát kết quả của các hành động. Phản hồi có giúp không? Workflow có thành công không? Người dùng có sửa nó không? Ngay cả khi phản hồi không được thu thập rõ ràng, tín hiệu vẫn tồn tại. Một vài tín hiệu hiệu quả trong production: thời gian đến tin nhắn tiếp theo (follow-up nhanh thường nghĩa là câu trả lời không đáp ứng), khoảng cách chỉnh sửa giữa output của bạn và phiên bản người dùng thực sự gửi đi (chỉnh sửa nhỏ là nhiễu, chỉnh sửa lớn là sửa lỗi), và bỏ cuộc trong N giây sau kết quả công cụ. Không ai trong những tín hiệu này yêu cầu người dùng đánh giá bất cứ thứ gì. Chúng chỉ yêu cầu bạn đo những gì đã xảy ra. Không có bước này, vòng lặp không khép lại và hệ thống không học được gì.

Promote là pha hầu hết team làm sai khi họ có. Promote là nửa của "cập nhật bộ nhớ" quyết định không chỉ có ghi hay không mà còn cái gì nên giữ lại, nó thuộc loại nào, và nó nên tồn tại bao lâu. Viết mọi thứ trở lại tạo ra một memory store tự đầu độc. Viết quá ít tạo ra hệ thống cảm thấy mất trí nhớ. Câu trả lời đúng là một chính sách, không phải một cờ. Một chính sách tốt trả lời sáu câu hỏi: cái gì được viết, ở độ chi tiết nào, vào loại bộ nhớ nào, với provenance gì, với chu kỳ suy giảm như thế nào, và dưới thẩm quyền của ai.

Pipeline kết thúc. Vòng lặp cộng hưởng. Sự khác biệt nằm ở Promote.

Các anti-pattern bạn có thể đang triển khai

Nếu bạn đã xây agent trong hơn vài tháng, bạn gần như chắc chắn đã triển khai nhiều trong số này.

Dump toàn bộ transcript mỗi lượt là cách lười để bảo toàn trạng thái, và nó tốn kém đến mức tàn phá, đạt context rot nhanh chóng, và âm thầm làm giảm chất lượng model. Một compacting summarizer chạy nền là không thể tùy chọn ở quy mô lớn. Khai thác prompt caching chỉ cho các prefix ổn định: system prompt, tool definition và static policy block, và thiết kế layout request để payload retrieval biến động nằm sau các phần được cache.

Dùng retrieval như kitchen sink là kéo top-20 chunk và hy vọng model tự sắp xếp. Model không sắp xếp. Nó trung bình hóa.

Coi scratchpad như bộ nhớ: kết quả tool call, reasoning trung gian và generated asset, tất cả rò rỉ vào lưu trữ dài hạn vì không có gì bao giờ rõ ràng loại bỏ chúng. "Bộ nhớ" của bạn chủ yếu là xả thải.

Một memory store cho mọi loại bộ nhớ là một vector index duy nhất giữ trace, fact, preference, policy và episodic summary. Retrieval không thể phân biệt chúng và model cũng không.

Bộ nhớ không bao giờ quên là không có TTL, không suy giảm, không eviction. Sau chỉ vài tháng, điều này trở thành trách nhiệm pháp lý, không phải tài sản. Một số hành vi tốt nhất bạn có thể thêm vào hệ thống là chính sách quên tích cực.

Promote dựa trên thumbs-up của người dùng là tín hiệu phản hồi mạnh nhất cũng là hiếm nhất và có độ lệch nhất. Hệ thống chỉ promote dựa trên tín hiệu tích cực rõ ràng học những gì làm người dùng nhấn nút, không phải những gì làm hệ thống tốt.

Không có replay: bạn không thể tái tạo phiên hôm qua vì memory store đã thay đổi. Debugging là đoán mò. Đây là lỗi sẽ ăn mòn on-call rotation của bạn trong 2026.

Memory layer đang hội tụ về đâu?

Khi bạn chấp nhận rằng bộ nhớ là năm thứ khác nhau với các access pattern khác nhau, câu hỏi tiếp theo là: tất cả chúng nên ở đâu?

Kiến trúc vô tình mà hầu hết team kết thúc với là: dữ liệu quan hệ trong Postgres, hybrid retrieval trong Elasticsearch hoặc vector store như Pinecone, Weaviate hoặc LanceDB, trace trong S3 hoặc time-series database. Mỗi lựa chọn đều tốt cho công việc nó được xây dựng để làm. Vấn đề không phải bất kỳ thành phần riêng lẻ nào — vấn đề là mỗi đường retrieval có nghĩa là join giữa các hệ thống: "tìm fact liên quan đến query này, lọc theo policy áp dụng cho tenant này, phạm vi đến user mà agent này được phép thấy." Join đó vượt qua ranh giới tin cậy, ranh giới giao dịch và ranh giới độ trễ.

Điều ít phổ biến hơn là đặt dữ liệu quan hệ, document và vector cùng một chỗ dưới một ranh giới giao dịch và bảo mật duy nhất, để policy, preference, fact và episodic memory có thể được query cùng nhau với đảm bảo ACID thay vì được đối chiếu giữa các hệ thống. Ví dụ, câu SQL sau thực hiện bốn thứ cùng lúc: thực thi tenant policy, tôn trọng user preference, áp dụng kiểm soát truy cập theo fact, và xếp hạng theo semantic similarity:

-- Tìm fact liên quan đến câu hỏi này, phạm vi theo policy và preference áp dụng cho user, trong một query duy nhất.
SELECT f.fact_text, f.provenance, f.created_at
FROM   fact_memory f
JOIN   user_preferences p
       ON p.user_id = :current_user
JOIN   tenant_policies t
       ON t.tenant_id = p.tenant_id
      AND t.is_active = 'Y'
WHERE  f.tenant_id = p.tenant_id
  AND  JSON_VALUE(p.prefs, '$.allow_personalization') = 'true'
  AND  f.access_level <= t.max_access_level
ORDER BY VECTOR_DISTANCE(
           f.embedding,
           VECTOR_EMBEDDING(MINILM USING :query AS DATA),
           COSINE
         )
FETCH FIRST 5 ROWS ONLY;

Trong kiến trúc phân tán, đó là bốn round trip qua ba store khác nhau, với consistency model mà bạn phải tự bảo vệ. Ở đây là một query plan, một transaction boundary, một nơi để audit.

Model layer đang được commodity hóa. Hybrid retrieval đang được commodity hóa. Điều tạo ra sự khác biệt là liệu dữ liệu quan hệ quản trị bộ nhớ có sống cùng chỗ với bản thân bộ nhớ hay không, dưới các đảm bảo giao dịch như nhau, và chính sách quyết định những gì cần nhớ.

Bảy dự báo cho những gì sắp tới

1. Model không trở thành bộ nhớ. Câu chuyện hấp dẫn là các nhà cung cấp model hấp thụ bộ nhớ vào bản thân model. Context window mở rộng, caching thông minh hơn, và memory layer bên ngoài lặng lẽ biến mất. Điều đó sẽ không xảy ra. Context window sẽ tiếp tục tăng, nhưng chúng vẫn cần được priming mỗi lượt. Model duy trì stateless mỗi phiên, và memory layer bên ngoài duy trì là kiến trúc của record. Điều thay đổi là memory bên ngoài trở nên thông minh hơn nhiều.

2. Đầu tư vào memory infrastructure vượt inference với sản phẩm AI trưởng thành. Chi phí inference đang giảm khoảng một bậc 10 mỗi 18 tháng. Lưu trữ, retrieval, tạo embedding, reranking và lắp ráp ngữ cảnh per-request thì không. Hóa đơn cloud chiếm ưu thế cho sản phẩm AI trưởng thành sẽ trở thành vector và hybrid retrieval infrastructure, không phải GPU token.

3. RAG cổ điển trở thành kiến trúc kế thừa. "Embed tài liệu, top-k theo query người dùng, nhét vào prompt" là COBOL của kiến trúc AI. Nó hoạt động, nó ở khắp mọi nơi, và nó sẽ rất đáng xấu hổ nhìn lại. Phần thay thế đã hiện rõ: agentic retrieval, nơi model lập kế hoạch tự tìm kiếm của mình, thực hiện query nhiều bước, đọc kết quả trung gian và quyết định cần fetch gì tiếp theo.

4. Bộ nhớ trở thành bề mặt tấn công adversarial. Tấn công prompt nhắm một request. Tấn công bộ nhớ cộng hưởng. Kẻ tấn công có thể viết vào memory store tồn tại lâu dài có thể định hình hành vi của hệ thống đó với mọi người dùng tương lai mà nó chạm đến. Sự cố poisoning bộ nhớ nghiêm trọng đầu tiên trong thực tế đang đến. Cuộc tranh giành của ngành về provenance, attestation và kiểm soát truy cập per-fact sẽ tiếp theo.

5. Ranh giới quyền riêng tư ngữ cảnh trở thành yêu cầu tuân thủ. Bước tiếp theo từ "context scoping là ranh giới bảo mật" là cách ly mật mã của các đoạn bộ nhớ, để agent chỉ có thể tiết lộ ngữ cảnh trên cơ sở need-to-know. Đây quan trọng ngay khi bạn có sub-agent với các mức tin cậy khác nhau, hoặc các chế độ quản lý yêu cầu scoping có thể chứng minh của các fact nhạy cảm.

6. Multi-agent consistency trở thành khả năng được đặt tên và kỳ vọng. Hiện tại, một billing agent và một support agent chạm vào cùng một tài khoản khách hàng có thể đưa ra câu trả lời mâu thuẫn vì chúng kéo các phần bộ nhớ khác nhau và không có gì đối chiếu chúng. Khi hệ thống multi-agent chuyển vào production ở quy mô lớn, người dùng sẽ bắt đầu phát hiện ra mâu thuẫn, và "contextual consistency" sẽ trở thành khả năng được đặt tên mà các platform cạnh tranh.

7. "Useful context per capita" trở thành metric benchmark. Ngày nay chúng ta benchmark model. Chúng ta sẽ bắt đầu benchmark hệ thống, và metric tiêu đề sẽ là thứ gì đó như useful context được mang theo mỗi người dùng, mỗi tương tác. Đó là con số thực sự dự báo retention, sự hài lòng và khoảng cách giữa sản phẩm cảm thấy như nó biết bạn và một sản phẩm cảm thấy như reset mỗi tuần.

Bắt đầu từ đâu?

Nếu bạn mới với lĩnh vực này và muốn có điểm khởi đầu: dừng coi bộ nhớ là một thứ. Chọn một production agent bạn có quyền truy cập, gán nhãn loại bộ nhớ nào mà mỗi store thực sự giữ, và chú ý xem thường xuyên như thế nào một store được dùng cho ba công việc.

Nếu bạn đã xây agent: đo vòng lặp. Cụ thể, đo tín hiệu giữa retrieval và promotion. Hầu hết team có thể cho bạn biết hệ thống của họ đã truy xuất gì ở một lượt nhất định. Ít hơn nhiều có thể cho biết trong số những bộ nhớ được truy xuất đó, bộ nhớ nào model thực sự sử dụng, và gần như không ai có thể cho biết tại sao một bộ nhớ nhất định được promote ngay từ đầu.

Biết bộ nhớ nào được sử dụng là thứ cho phép bạn củng cố chúng ở bước promotion tiếp theo, đó là cách memory system ngừng là write-once log và bắt đầu thực sự học. Vòng phản hồi đó là nơi lợi thế cộng hưởng sống, và là nơi hai năm tới của kỷ luật này sẽ được quyết định.

Kết luận

Không ai đang xây model thông minh hơn. Mọi người đang xây hệ thống nhớ, thích nghi và khi được thiết kế tốt, từ chối quên những thứ quan trọng.

Model layer là tài nguyên chung. Mọi người đều dùng cùng Claude, cùng GPT, cùng Gemini theo cùng timeline. Memory layer và cách bạn lắp ráp ngữ cảnh không phải tài nguyên chung. Đó là thứ duy nhất bạn xây mà không ai khác có thể sao chép, vì nó được định hình bởi người dùng của bạn, quyết định của bạn và phán xét của bạn về những gì đáng nhớ và những gì đáng truy xuất.

Model thông minh hơn là lợi thế của mọi người. Memory system tốt hơn là của bạn.