"Prompt engineer" chưa bao giờ là một chức danh chính xác, nhưng có một thời gian dài điều đó không thành vấn đề. Nếu toàn bộ công việc của bạn chỉ là lấy ra một phản hồi tốt từ một lần gọi suy luận (inference call) duy nhất, thì một bộ kỹ năng là đủ: diễn đạt câu lệnh cho khéo, đưa vài ví dụ, có thể thêm chút văn bản truy xuất được, thế là xong. Bộ kỹ năng đó vẫn còn giá trị. Nhưng nó không còn bao quát được ý nghĩa của việc "xây dựng một agent" vào giữa năm 2026, và khoảng trống đó đang bộc lộ thành một kiểu thất bại cụ thể, dễ nhận ra: những agent hoạt động tuyệt vời trong bản demo rồi âm thầm xuống cấp, tự mâu thuẫn với chính mình, hoặc quên mất điều người dùng đã nói với chúng hai phiên trước đó.
Một bài viết gần đây từ Machine Learning Mastery đã chỉ thẳng ra khoảng trống này, và đáng để suy ngẫm kỹ vì nó khớp gọn gàng với hai công việc khác nhau mà bạn thực sự có thể được thuê để làm. Context engineering là những gì diễn ra bên trong một lần gọi suy luận: quyết định cái gì sẽ đi vào cửa sổ ngữ cảnh, nó nằm ở vị trí nào về mặt cấu trúc, và cái gì sẽ bị nén lại hoặc loại bỏ để mô hình không bị chìm ngập trong những token không liên quan. Memory engineering là một vấn đề khác, chỉ tồn tại xuyên suốt nhiều lần gọi: cái gì được ghi lại sau khi một phiên kết thúc, nó được lưu trữ ở đâu, được truy xuất như thế nào vào lần sau, và được duy trì ra sao (cập nhật, loại bỏ trùng lặp, cho hết hạn) để nó không bị mục nát. Theo bài viết đó, những thất bại xuất hiện trong các quy trình agent dài, nhiều phiên thường bắt nguồn từ việc gộp lẫn hai công việc này, hoặc bỏ qua một trong hai — đặc biệt là tại cái mà họ gọi là "ranh giới truy xuất" (retrieval boundary), thời điểm mà một agent phải quyết định xem thứ nó cần đang nằm ngay trước mắt hay phải lấy về từ nơi lưu trữ.
Vì sao việc gộp lẫn hai công việc này mới thực sự là lỗi, chứ không phải là chi tiết vặt vãnh
Hãy nghĩ xem mỗi bộ môn đang tối ưu hóa cho điều gì. Context engineering đang tối ưu hóa một cửa sổ đơn lẻ, có giới hạn, dùng một lần rồi bỏ — đưa đúng lát cắt thông tin cần thiết ra trước mô hình ngay lúc này, cho riêng lượt trao đổi này, rồi vứt bỏ phần còn lại. Memory engineering đang tối ưu hóa một kho lưu trữ bền vững, phải tồn tại xuyên suốt nhiều phiên, giữ được tính nhất quán khi có thông tin mới xuất hiện, và trả lời một câu hỏi khó hơn nhiều: không phải "cái gì liên quan đến prompt này" mà là "cái gì đáng để giữ lại, và giữ trong bao lâu."
Đó là những bài toán thiết kế khác nhau với những kiểu thất bại khác nhau. Một sai lầm trong context engineering chỉ làm hỏng một phản hồi. Một sai lầm trong memory engineering thì tích lũy dần — những lần ghi sai chồng chất lên nhau, những sự kiện đã lỗi thời bị truy xuất ra như thể chúng vẫn còn đúng, và không ai để ý cho đến khi agent tự tin lặp lại điều gì đó đã được sửa từ ba phiên trước. Nếu một người (hoặc một mẫu prompt) âm thầm đảm nhận cả hai công việc mà không phân biệt chúng, tầng bộ nhớ có xu hướng thừa hưởng những thói quen của context engineering vốn không nên có: nhồi nhét kho lưu trữ quá mức giống như cách người ta nhồi nhét một cửa sổ ngữ cảnh, hoặc coi việc truy xuất là bài toán xếp hạng độ liên quan trong khi thực chất đó là bài toán tuyển chọn và bảo trì. Đó chính là sự gộp lẫn mà bản tóm lược nghiên cứu đang chỉ ra, và nó khớp với điều mà những người thực hành đã mô tả qua kinh nghiệm thực tế: những agent gây ấn tượng trong một phiên duy nhất nhưng lại không đáng tin cậy khi đến phiên thứ năm.
Mỗi công việc thực sự trông như thế nào trong thực tế hàng ngày
Nếu bạn đang cố tìm hiểu xem mình hiện đang làm công việc nào trong hai công việc này, hoặc bạn muốn hướng tới công việc nào, thì công việc hàng ngày của chúng khác nhau đủ rõ để phân biệt:
Context engineering, trong thực tế: quyết định tập con nào trong số thông tin sẵn có (tài liệu, kết quả từ công cụ, các lượt trao đổi trước đó) thực sự thuộc về lần gọi này; chọn vị trí nó nằm trong prompt, vì vị trí ảnh hưởng đến cách mô hình đánh trọng số cho nó; viết các bước nén hoặc tóm tắt để một dấu vết công cụ (tool trace) dài không ngốn hết toàn bộ ngân sách; và điều chỉnh việc này theo từng tác vụ, vì một agent gỡ lỗi và một agent viết lách muốn có hình dạng ngữ cảnh khác nhau ngay cả khi dùng chung một mô hình nền.
Memory engineering, trong thực tế: xác định một chính sách ghi (write policy) (cái gì đáng để lưu lại sau một phiên — không phải mọi thứ đều đáng); chọn một tầng lưu trữ (kho vector, cơ sở dữ liệu có cấu trúc, tệp văn bản thuần, hoặc dạng lai) và thẳng thắn nhìn nhận đánh đổi của từng lựa chọn; xây dựng chiến lược truy xuất quyết định cái gì được lấy ra và khi nào; và thực hiện việc bảo trì liên tục — cắt tỉa, gộp các sự kiện trùng lặp, xử lý mâu thuẫn khi người dùng đổi ý. Phần cuối cùng đó, việc bảo trì, là phần mà người ta bỏ qua nhiều nhất, vì nó không lộ ra cho đến khi một agent đã chạy được vài tuần.
Có thể thấy ngành này đang bắt đầu tách bạch những mối quan tâm này về mặt cấu trúc, chứ không chỉ về mặt khái niệm. Bài hướng dẫn của Lenny's Newsletter về việc xây dựng một harness gỡ lỗi trên Claude Agent SDK coi quyền hạn, các bộ chuyển đổi công cụ (tool adapters), và "harness" bao quanh là một bề mặt kỹ thuật riêng, tách biệt khỏi việc viết prompt bên trong nó — cùng một trực giác, chỉ được áp dụng vào một điểm nối khác. Và các tính năng "Managed Agents" mới hơn trong Gemini API của Google — thực thi nền, làm mới thông tin xác thực (credential refresh) xuyên suốt các lượt tương tác — thực chất là việc nhà cung cấp nền tảng thừa nhận rằng trạng thái tồn tại xuyên phiên giờ đây là hạ tầng cần được thiết kế, chứ không phải một hệ quả phụ của một cửa sổ ngữ cảnh đủ dài. Phải có ai đó chịu trách nhiệm cho thiết kế đó. Ngay lúc này, ở nhiều đội nhóm, không ai thực sự đảm nhận việc đó một cách rõ ràng.
Vì sao điều này quan trọng đối với chức danh công việc của bạn, chứ không chỉ đối với đoạn mã bạn viết
Nếu bạn đang ở giai đoạn đầu hoặc giữa sự nghiệp và "prompt engineer" hay "AI engineer" đang có trong hồ sơ của bạn, đáng để tự hỏi xem bạn thực sự có thể chỉ ra bằng chứng mình đang làm công việc nào trong hai công việc này — bởi vì các vai trò AI-agent tổng quát đang bắt đầu bị tách ra thành những vai trò cụ thể hơn, giống hệt cách "webmaster" cuối cùng đã tách thành frontend, backend, và DevOps. Đây là một nhận định thận trọng, không phải một tuyên bố chắc chắn: tôi chưa thấy dữ liệu tuyển dụng cứng nào xác nhận "memory engineer" đã trở thành một chức danh độc lập, vì vậy hãy coi đây là một dự đoán về hướng đi của công việc, chứ không phải một khẳng định rằng các trang tuyển dụng đã sắp xếp theo cách này. Nhưng áp lực nền tảng là có thật và có thể truy về bản tóm lược nêu trên: các đội ngũ agent đang gặp phải một thất bại cụ thể, có thể gọi tên (sự xuống cấp qua nhiều phiên) với một nguyên nhân cụ thể, có thể gọi tên (việc gộp lẫn hai bộ môn), và sự kết hợp đó thường là thứ biến một vai trò mờ nhạt thành hai vai trò rõ ràng.
Điều thực tế cần làm không phải là tự đặt ra một chức danh cho mình. Mà là có khả năng trả lời, một cách cụ thể, rằng bạn thực sự đã giải quyết vấn đề nào. Bạn đã từng phát hành thứ gì đó mà trong đó bạn thiết kế một chính sách ghi (write policy) — một quy tắc quy định cái gì một agent sẽ ghi vào bộ nhớ và cái gì nó sẽ loại bỏ, hay chưa? Bạn đã từng gỡ lỗi một thất bại ở ranh giới truy xuất, nơi một agent cần thứ gì đó từ kho lưu trữ nhưng hoặc không lấy được nó, hoặc lấy nhầm phiên bản, hay chưa? Đó là những tuyên bố có thể kiểm chứng mà bạn có thể đưa ra trong một cuộc phỏng vấn, được hậu thuẫn bởi một repo hay một bản báo cáo hậu sự cố (postmortem), và chúng nói lên điều mà câu "tôi viết prompt giỏi" chung chung không nói lên được: rằng bạn hiểu sự khác biệt giữa việc làm cho một câu trả lời tốt hơn và việc làm cho một agent đáng tin cậy theo thời gian.
Một lời cảnh báo
Đừng vội tự gắn cho mình danh xưng "memory engineer" chỉ vì đã từng thêm một cơ sở dữ liệu vector vào một dự án. Bộ môn mà nghiên cứu này chỉ ra bao gồm cả nửa kém hào nhoáng — bảo trì, cho hết hạn, xử lý mâu thuẫn — và đó chính là nửa thực sự ngăn chặn kiểu thất bại đã mô tả ở trên. Nếu tác phẩm trong portfolio của bạn là một hệ thống ghi vào bộ nhớ nhưng chẳng có gì từng được cắt tỉa hay sửa chữa, thì bạn mới chỉ xây dựng được một nửa công việc của một memory engineer, và vấn đề thất bại sau phiên thứ ba vẫn đang chờ bạn ở nửa còn lại.