"Prompt engineer" tidak pernah menjadi jawatan yang tepat, tetapi buat seketika ia tidak perlu tepat pun. Jika seluruh kerja anda hanyalah mendapatkan satu respons yang baik daripada satu panggilan inferens, satu set kemahiran sudah memadai: susun arahan dengan baik, berikan beberapa contoh, mungkin tambah sedikit teks yang diperoleh, selesai. Set kemahiran itu masih penting. Tetapi ia tidak lagi merangkumi apa yang dimaksudkan dengan "membina ejen" pada pertengahan 2026, dan jurang ini muncul sebagai satu corak kegagalan yang khusus dan boleh dikenal pasti: ejen yang berfungsi dengan baik dalam demo tetapi kemudian merosot secara senyap-senyap, bercanggah dengan diri sendiri, atau melupakan apa yang diberitahu oleh pengguna dua sesi sebelumnya.
Satu artikel terkini daripada Machine Learning Mastery menamakan jurang ini secara terus terang, dan ia patut difikirkan kerana ia sepadan dengan jelas kepada dua jenis kerja berbeza yang boleh anda diupah untuk lakukan. Context engineering ialah apa yang berlaku dalam satu panggilan inferens: menentukan apa yang dimasukkan ke dalam tetingkap konteks, di mana kedudukannya secara struktur, dan apa yang dimampatkan atau dibuang supaya model tidak lemas dengan token yang tidak relevan. Memory engineering pula ialah masalah berbeza yang hanya wujud merentasi panggilan-panggilan: apa yang dicatatkan selepas sesuatu sesi berakhir, di mana ia disimpan, bagaimana ia diambil semula pada kali seterusnya, dan bagaimana ia diselenggara (dikemas kini, dinyahduaan, ditamatkan tempoh) supaya ia tidak reput. Menurut artikel tersebut, kegagalan yang muncul dalam aliran kerja ejen yang panjang dan merentasi banyak sesi selalunya berpunca daripada mencampuradukkan kedua-dua kerja ini, atau mengabaikan salah satunya — terutamanya pada apa yang mereka namakan "sempadan pengambilan semula" (retrieval boundary), iaitu detik apabila seorang ejen perlu memutuskan sama ada sesuatu yang diperlukannya sudah berada di hadapannya atau perlu diambil daripada storan.
Mengapa mencampuradukkan kedua-duanya adalah pepijat sebenar, bukan sekadar butiran kecil
Fikirkan apa yang cuba dioptimumkan oleh setiap disiplin ini. Context engineering mengoptimumkan satu tetingkap yang terhad, bersempadan dan boleh dibuang — dapatkan sepotong maklumat yang betul di hadapan model sekarang, untuk pertukaran ini sahaja, kemudian buang selebihnya. Memory engineering pula mengoptimumkan simpanan yang tahan lama yang perlu bertahan merentasi sesi-sesi, kekal konsisten apabila maklumat baharu tiba, dan menjawab soalan yang jauh lebih sukar: bukan "apa yang relevan dengan prompt ini" tetapi "apa yang benar-benar berbaloi untuk disimpan, dan untuk berapa lama."
Ini adalah masalah reka bentuk yang berbeza dengan corak kegagalan yang berbeza. Kesilapan dalam context engineering menjadikan satu respons lebih teruk. Kesilapan dalam memory engineering pula berganda — penulisan yang tidak baik terkumpul, fakta yang lapuk diambil semula seolah-olah ia masih terkini, dan tiada siapa yang perasan sehinggalah ejen itu dengan yakin mengulangi sesuatu yang telah dibetulkan tiga sesi sebelumnya. Jika seorang individu (atau satu templat prompt) secara senyap-senyap melakukan kedua-dua kerja ini tanpa membezakannya, lapisan memori itu cenderung mewarisi tabiat context engineering yang sepatutnya tidak diwarisi: memenuhkan storan secara berlebihan sepertimana anda memenuhkan tetingkap secara berlebihan, atau menganggap pengambilan semula sebagai masalah penentuan kadar relevans sedangkan sebenarnya ia adalah masalah kurasi dan penyelenggaraan. Itulah percampuran yang cuba ditunjukkan oleh ringkasan penyelidikan tersebut, dan ia selari dengan sesuatu yang sudah pun diperkatakan secara anekdot oleh para pengamal: ejen yang mengagumkan dalam satu sesi tetapi tidak boleh dipercayai menjelang sesi kelima.
Bagaimana rupa sebenar setiap kerja ini pada kebiasaan seharian
Jika anda cuba memahami yang mana satu daripada kerja ini sudah anda lakukan, atau yang mana satu ingin anda bina ke arahnya, kerja seharian bagi kedua-duanya cukup berbeza untuk dapat dibezakan:
Context engineering, pada praktiknya: menentukan subset maklumat yang tersedia (dokumen, output alat, giliran sebelumnya) yang sebenarnya patut ada dalam panggilan ini; memilih di mana kedudukannya dalam prompt, kerana kedudukan mempengaruhi cara model memberikan bobot kepadanya; menulis langkah-langkah pemampatan atau peringkasan supaya jejak alat yang panjang tidak menghabiskan keseluruhan bajet; dan menyesuaikan ini mengikut setiap tugas, kerana ejen penyahpepijatan dan ejen penulisan mahukan bentuk konteks yang berbeza walaupun menggunakan model asas yang sama.
Memory engineering, pada praktiknya: menentukan polisi penulisan (apa yang berbaloi untuk dikekalkan selepas sesuatu sesi — bukan semuanya berbaloi); memilih lapisan storan (vector store, pangkalan data berstruktur, fail biasa, atau sesuatu yang hibrid) dan berterus terang tentang pertukaran ganti bagi setiap satu; membina strategi pengambilan semula yang menentukan apa yang dikeluarkan semula dan bila; serta menjalankan penyelenggaraan berterusan — memangkas, menggabungkan fakta berganda, dan menangani percanggahan apabila pengguna berubah fikiran. Bahagian terakhir itu, iaitu penyelenggaraan, adalah bahagian yang paling kerap diabaikan orang, kerana ia tidak kelihatan sehinggalah ejen itu telah berjalan selama berminggu-minggu.
Anda dapat lihat industri ini mula memisahkan kedua-dua fokus ini secara struktural, bukan sekadar konseptual. Panduan Lenny's Newsletter tentang membina rangka penyahpepijatan (debugging harness) menggunakan Claude Agent SDK memperlakukan kebenaran (permissions), penyesuai alat (tool adapters), dan "rangka" (harness) di sekelilingnya sebagai permukaan kejuruteraan tersendiri yang berbeza daripada prompting di dalamnya — naluri yang sama, diterapkan pada sambungan yang berbeza. Dan ciri-ciri "Managed Agents" terbaharu daripada Gemini API milik Google — pelaksanaan latar belakang, pembaharuan kelayakan (credential refresh) merentasi interaksi — sebenarnya adalah pengakuan vendor platform bahawa keadaan yang berterusan sepanjang sesi kini merupakan infrastruktur yang perlu direka bentuk, bukan sekadar kesan sampingan daripada tetingkap konteks yang cukup panjang. Seseorang perlu memiliki tanggungjawab bagi reka bentuk itu. Buat masa ini, dalam banyak pasukan, tiada siapa yang melakukannya secara jelas.
Mengapa ini penting bagi jawatan anda, bukan sekadar kod anda
Jika anda berada di peringkat awal atau pertengahan kerjaya dan "prompt engineer" atau "AI engineer" tertera pada resume anda, ada baiknya anda bertanya yang mana satu daripada dua kerja ini yang benar-benar mempunyai bukti telah anda lakukan — kerana peranan generalis ejen-AI mula terpecah kepada peranan yang lebih khusus, sama seperti "webmaster" yang akhirnya terbahagi kepada frontend, backend, dan DevOps. Ini adalah satu andaian berhemat, bukan tajuk berita: saya belum melihat data pengambilan pekerja yang kukuh yang mengesahkan "memory engineer" sebagai jawatan berasingan lagi, jadi anggaplah ini sebagai tanggapan tentang ke arah mana kerja ini sedang menuju, bukan dakwaan bahawa papan pekerjaan sudah tersusun sedemikian. Tetapi tekanan yang mendasarinya adalah nyata dan boleh dikesan kembali kepada ringkasan di atas: pasukan ejen sedang menghadapi kegagalan yang khusus dan boleh dinamakan (kemerosotan merentasi sesi) yang mempunyai punca yang khusus dan boleh dinamakan (percampuran dua disiplin), dan gabungan sebegini biasanya adalah apa yang mengubah satu peranan yang kabur kepada dua peranan yang jelas.
Langkah praktikalnya bukanlah untuk mencipta jawatan sendiri. Sebaliknya, ia adalah untuk dapat menjawab secara konkrit, masalah mana yang sebenarnya telah anda selesaikan. Adakah anda pernah menghasilkan sesuatu di mana anda mereka bentuk polisi penulisan — satu peraturan tentang apa yang disimpan oleh sesebuah ejen ke dalam memori dan apa yang dibuangnya? Adakah anda pernah menyahpepijat kegagalan sempadan-pengambilan-semula, di mana seorang ejen memerlukan sesuatu daripada storan tetapi sama ada tidak mengambilnya atau mengambil versi yang salah? Itulah dakwaan yang boleh disahkan yang boleh anda buat semasa temu duga, disokong oleh repositori atau post-mortem, dan ia menyatakan sesuatu yang tidak dinyatakan oleh kenyataan umum seperti "saya menulis prompt yang baik": bahawa anda memahami perbezaan antara menjadikan satu jawapan lebih baik dengan menjadikan sesebuah ejen boleh dipercayai dalam jangka masa panjang.
Satu peringatan
Jangan gelar diri anda sebagai "memory engineer" hanya kerana pernah menambah pangkalan data vektor ke dalam satu projek pada satu ketika. Disiplin yang ditunjukkan oleh penyelidikan ini merangkumi separuh yang tidak glamor — penyelenggaraan, tamat tempoh, penanganan percanggahan — dan itulah separuh yang sebenarnya mencegah corak kegagalan yang diterangkan di atas. Jika karya portfolio anda hanyalah sebuah sistem yang menulis ke dalam memori tetapi tiada apa-apa yang pernah dipangkas atau dibetulkan, anda baru membina separuh daripada kerja seorang memory engineer, dan masalah kegagalan-selepas-sesi-ketiga masih menanti anda pada separuh yang satu lagi.