«Промт-инженер» никогда не был точным названием должности, но какое-то время в этом и не было нужды. Если вся ваша работа сводилась к тому, чтобы получить один хороший ответ из одного вызова модели, для этого хватало одного набора навыков: грамотно сформулировать инструкцию, дать пару примеров, может быть, добавить немного найденного текста — и готово. Этот набор навыков всё ещё важен. Но он больше не покрывает того, что значит «построить агента» в середине 2026 года, и этот разрыв проявляется в виде конкретного, узнаваемого сбоя: агенты, которые прекрасно работают в демо, а затем незаметно деградируют, начинают противоречить сами себе или забывают, что пользователь говорил им две сессии назад.

Недавняя статья Machine Learning Mastery называет этот разрыв прямым текстом, и стоит в неё вдуматься, потому что она чётко накладывается на две разные работы, на которые вас действительно могли бы нанять. Инжиниринг контекста — это то, что происходит внутри одного вызова модели: решение о том, что попадает в окно контекста, где именно оно структурно располагается и что сжимается или отбрасывается, чтобы модель не тонула в нерелевантных токенах. Инжиниринг памяти — это другая проблема, которая существует только между вызовами: что записывается после завершения сессии, где это хранится, как это извлекается в следующий раз и как это поддерживается (обновляется, дедуплицируется, устаревает), чтобы не сгнить. Согласно этой статье, сбои, возникающие в длинных, многосессионных агентных workflow, чаще всего восходят к смешению этих двух работ или к пропуску одной из них — особенно на том, что там называют «границей извлечения» (retrieval boundary), в момент, когда агенту нужно решить, находится ли то, что ему нужно, прямо перед ним или его нужно достать из хранилища.

Почему их смешение — это настоящая ошибка, а не мелочь

Подумайте, что оптимизирует каждая из этих дисциплин. Инжиниринг контекста оптимизирует единое, ограниченное, одноразовое окно — вывести перед моделью нужный срез информации прямо сейчас, для этого одного обмена репликами, а затем выбросить всё остальное. Инжиниринг памяти оптимизирует устойчивое хранилище, которое должно пережить смену сессий, оставаться согласованным по мере поступления новой информации и отвечать на гораздо более сложный вопрос: не «что релевантно этому промту», а «что вообще стоит сохранять и на какой срок».

Это разные проектные задачи с разными видами сбоев. Ошибка в инжиниринге контекста ухудшает один ответ. Ошибка в инжиниринге памяти накапливается — плохие записи копятся, устаревшие факты извлекаются так, будто они актуальны, и никто этого не замечает, пока агент уверенно не повторит то, что было исправлено три сессии назад. Если один человек (или один шаблон промта) незаметно выполняет обе работы, не различая их, слой памяти, как правило, наследует привычки инжиниринга контекста, которые ему не нужны: он забивает хранилище так же, как забивают окно, или относится к извлечению как к задаче ранжирования релевантности, тогда как на самом деле это задача курирования и поддержки. Именно на это смешение указывает исследовательский дайджест, и это совпадает с тем, что практики уже описывают на уровне наблюдений: агенты, впечатляющие в рамках одной сессии и ненадёжные уже к пятой.

Как каждая из этих работ выглядит на самом деле изо дня в день

Если вы пытаетесь понять, какую из этих работ вы уже выполняете или к какой хотели бы двигаться, повседневная работа выглядит достаточно по-разному, чтобы их различить:

Инжиниринг контекста на практике: решение о том, какое подмножество доступной информации (документация, вывод инструментов, предыдущие реплики) действительно должно попасть в этот вызов; выбор того, в каком месте промта это разместить, поскольку позиция влияет на то, какой вес модель этому придаёт; написание шагов сжатия или суммаризации, чтобы длинная трасса вызова инструмента не съедала весь бюджет; и настройка этого под каждую задачу, поскольку агенту для отладки и агенту для написания текста нужна разная форма контекста даже на одной и той же базовой модели.

Инжиниринг памяти на практике: определение политики записи (что стоит сохранять после сессии — не всё подряд); выбор уровня хранения (векторное хранилище, структурированная база данных, обычные файлы, какой-то гибрид) и честная оценка компромиссов каждого варианта; построение стратегии извлечения, которая решает, что и когда возвращается обратно; и постоянное обслуживание — обрезка, слияние дублирующихся фактов, обработка противоречий, когда пользователь меняет своё мнение. Именно эту последнюю часть, обслуживание, чаще всего пропускают, потому что её не видно, пока агент не проработает несколько недель.

Видно, что индустрия начинает разделять эти задачи структурно, а не только концептуально. Разбор от Lenny's Newsletter о построении отладочного harness на Claude Agent SDK рассматривает разрешения, адаптеры инструментов и сам окружающий «harness» как отдельную инженерную поверхность, отличную от промтинга внутри него — тот же инстинкт, применённый к другому шву. А новые функции «Managed Agents» в Gemini API от Google — фоновое выполнение, обновление учётных данных между взаимодействиями — по сути являются признанием поставщика платформы в том, что состояние, устойчивое между сессиями, теперь является инфраструктурой, которую нужно проектировать, а не побочным эффектом достаточно длинного окна контекста. Кто-то должен отвечать за это проектирование. Прямо сейчас во многих командах этим явно никто не занимается.

Почему это важно для вашей должности, а не только для вашего кода

Если вы находитесь в начале или середине карьеры и в вашем резюме указано «промт-инженер» или «AI-инженер», стоит спросить себя, по какой из этих двух работ вы действительно можете предъявить доказательства — потому что универсальные роли AI-агентных инженеров начинают распадаться на более узкие, так же как в своё время «вебмастер» в итоге разделился на фронтенд, бэкенд и DevOps. Это оговорка, а не заголовок: я пока не видел жёстких данных по найму, подтверждающих «инженер по памяти» как отдельную должность, так что воспринимайте это как прогноз того, куда движется работа, а не как утверждение, что доски вакансий уже так рассортированы. Но лежащее в основе давление реально и прослеживается до упомянутого выше дайджеста: агентные команды сталкиваются с конкретным, поддающимся описанию сбоем (деградация в ходе многосессионной работы), у которого есть конкретная, поддающаяся описанию причина (смешение двух дисциплин), а такое сочетание обычно и превращает размытую роль в две чёткие.

Практический шаг — не придумывать себе название должности. А в том, чтобы уметь конкретно ответить, какую проблему вы на самом деле решили. Выпускали ли вы что-то, где сами спроектировали политику записи — правило, определяющее, что агент сохраняет в памяти, а что отбрасывает? Отлаживали ли вы сбой на границе извлечения, когда агенту было нужно что-то из хранилища, а он либо не смог это получить, либо получил не ту версию? Это проверяемые утверждения, которые можно озвучить на собеседовании, подкреплённые репозиторием или разбором инцидента, и они говорят о том, чего не говорит общее «я хорошо пишу промты»: что вы понимаете разницу между тем, чтобы сделать один ответ лучше, и тем, чтобы сделать агента надёжным на протяжении долгого времени.

Предостережение

Не переименовывайте себя в «инженера по памяти» только на основании того, что вы однажды добавили в проект векторную базу данных. Дисциплина, на которую указывает исследование, включает в себя непривлекательную половину — обслуживание, устаревание, обработку противоречий, — и именно эта половина на самом деле предотвращает описанный выше сбой. Если ваш кейс в портфолио — это система, которая пишет в память, но в которой ничего никогда не обрезается и не исправляется, вы построили только половину работы инженера по памяти, и проблема «сбоя после третьей сессии» всё ещё ждёт вас на другой половине.