Почему кодинг-агент забывает требования проекта
Кодинг-агент нарушает правило, заданное неделю назад, и дело не в том, что история сессий потерялась. Она сохраняется. Ломается другое: система вытаскивает из архива лексически похожий фрагмент, но не проверяет, действует ли это требование сейчас, не отменено ли оно более новым решением и относится ли оно к текущей задаче.
Intent continuity добавляет ровно этот слой проверки. Вместо того чтобы просто подтягивать связанную историю, система верифицирует каждое старое требование по трём пунктам: актуальность, отсутствие перекрытия новым решением, релевантность текущей задаче. Автор статьи на Towards Data Science собрал такую систему на чистом Python, без эмбеддингов, векторных баз и вызовов LLM, и получил на синтетическом наборе 8 решённых задач из 8. Базовый агент без истории прошёл 0 из 8, обычный лексический поиск - 4 из 8.
Длинного контекста для этого недостаточно. Контекстное окно LLM ограничено, а расширение окна само по себе не добавляет проверок, без которых старые требования превращаются в балласт и мешают выполнить текущую задачу.
Что такое контекстное окно и почему оно не бесконечное
Контекстное окно - это максимальный объём текста в токенах, который языковая модель учитывает одновременно. В него попадает всё сразу: ваш промпт, вставленные документы, история диалога и ответ модели. Токен - единица текста, которой оперирует модель. Ориентир для английского текста: примерно 1000 токенов ≈ 750 слов.
Работает это так. Трансформер, архитектура почти всех современных языковых моделей, через механизм attention сопоставляет каждое слово отрывка с каждым другим. Такой механизм позволяет держать смысл на длинных отрезках текста. Но ни attention, ни само окно не создают долговременной памяти: за границей окна текст перестаёт учитываться, и длинные разговоры иногда теряют нить. Как размер окна связан с KV-cache, VRAM и стоимостью инференса при локальном запуске, разобрано в материале про открытые LLM 2026 года.
Второй слой проблемы лежит в природе модели. LLM не имеет базы фактов и может генерировать правдоподобные ложные сведения, то есть галлюцинации. Дата отсечки знаний добавляет своё: без поиска модель не знает недавних событий. Кодинг-агенту это грозит тем, что он уверенно сошлётся на несуществующую функцию проекта или на правило, которого никто не задавал.
Почему простое увеличение окна не решает проблему
Логичный вывод из сказанного: взять модель с окном побольше и закинуть туда всю историю проекта. Это помогает с объёмом, но не с качеством. Даже если технически впихнуть в окно все прошлые сессии, модель не проверяет актуальность требований. Принятое на прошлой неделе решение «используем библиотеку X» и вчерашнее «переходим на Y» для неё равнозначны, оба фрагмента просто лежат рядом в контексте.
Аналогия простая: держать перед глазами весь архив проекта и не иметь ни одного фильтра. Чем больше архива, тем выше шанс, что действующее правило утонет среди устаревших. Расширенное окно полезно, но слой верификации оно не заменяет.
Что такое intent continuity и чем он отличается от обычного поиска по истории
Intent continuity - это подход к работе с историей прошлых сессий, при котором система верифицирует каждое старое требование перед применением. Разница с лексическим поиском принципиальная. Лексический поиск, и в значительной степени RAG, отвечает на вопрос «есть ли в истории текст, похожий на текущий запрос». Intent continuity отвечает на другой вопрос: «действует ли это требование сейчас и применимо ли оно к этой задаче».
Второй вопрос требует состояния, а не близости слов. Нужно знать, какие решения принимались позже, какие требования отменяли друг друга и к какому модулю относится каждое правило. Именно поэтому у автора всё уместилось в чистый Python, без эмбеддингов, векторных баз и вызовов LLM.
Три проверки, которые превращают историю в требования
Каждое извлечённое требование проходит три фильтра.
- Актуальность. Требование ещё действует или привязано к уже удалённому модулю? Устаревшее правило отбрасывается.
- Перекрытие. Не заменено ли оно более новым решением? Если в прошлой сессии договорились использовать библиотеку X, а в новой приняли переход на Y, требование про X снимается.
- Релевантность. Требование относится к текущей задаче или к соседнему компоненту? Правило про формат логирования не должно влиять на схему базы данных.
Только требование, прошедшее все три проверки, попадает в контекст агента как действующее ограничение. Остальное остаётся в архиве как история, но не как инструкция.
Почему подход работает без эмбеддингов и вызовов LLM
Отсутствие эмбеддингов и векторных баз означает, что система опирается на структурированные связи компонентов и правила, а не на семантическую близость. У такого выбора есть цена и есть выигрыш. Выигрыш: детерминированность, предсказуемость, отсутствие расходов на инференс и полная прозрачность в том, почему требование отброшено. Цена: система не улавливает семантические связи там, где формулировки расходятся, а совпадений по структуре нет.
RAG и лексический поиск решают задачу извлечения, intent continuity решает задачу допуска требования к исполнению. Слои дополняют друг друга: найти кандидатов можно поиском, а проверить их стоит верификацией.
Эксперимент: 0/8, 4/8 и 8/8 - что стоит за цифрами
Сравнение трёх подходов дало три разных результата на одном и том же наборе задач. Базовый агент без доступа к истории прошлых сессий не решил ни одной задачи: 0/8. Обычный лексический поиск по истории вытянул половину: 4/8. Intent-aware подход с верификацией требований закрыл все восемь: 8/8.
Цифры выглядят убедительно, и поэтому сразу обозначим их границы. Все они получены на синтетическом наборе, и переносить их на реальные проекты напрямую нельзя. Любой синтетический бенчмарк измеряет то, что заложено в его дизайн; похожая логика разбора применима к бенчмаркам, которые проверяют выживание агента в игровой среде.
Как устроен синтетический набор из 70 взаимодействий
Набор состоял из 70 взаимодействий, 12 требований и 8 задач. Синтетика здесь не случайна: она позволяет контролировать условия и точно знать, какое требование должно быть применено в каждой задаче, а какое нет. С реальным репозиторием так не получится, потому что в нём требования размыты, конфликтуют и меняются непредсказуемо.
Внешняя валидность у такого дизайна низкая. Результат отвечает на вопрос «работает ли механизм в принципе», а не на вопрос «сработает ли он у вас в монорепозитории на 200 тысяч строк».
Почему лексический поиск решает только 4 из 8 задач
Лексический поиск опирается на совпадение слов. Если требование сформулировано другими словами и структура фразы не совпала, оно не найдётся. Если требование перекрыто новым решением, поиск всё равно подтянет старую формулировку, потому что слова остались прежними. Половина задач из набора провалена именно на этом: система находила историю, но не понимала её статус.
Лексический поиск при этом не бесполезен. Он быстрый, простой и не требует ни эмбеддингов, ни дополнительных сервисов. Слабое место у него одно, зато критичное для долгоживущих агентов: он не верифицирует.
Как автор исключил подгонку результата: урок про per-task подсказки
Первая версия эксперимента выглядела подозрительно удачной, и автор это заметил. В дизайне использовались per-task подсказки, которые фактически подгоняли результат под конкретную задачу. Отказ от подсказок в пользу единой схемы связей компонентов уронил счёт до 6/8. После доработки система снова вышла на 8/8, но уже без подсказок.
История полезна не столько ради самой цифры, сколько ради методологии. Такой разбор собственной ошибки в дизайне теста встречается редко, а сама ошибка типична для всех, кто тестирует агентов.
Что такое per-task подсказки и почему они искажают результат
Per-task подсказка - это заранее подготовленная инструкция под каждую конкретную задачу, которая содержит часть решения. Если система получает намёк до старта, её результат ничего не говорит о её реальных возможностях: вы измеряете не механизм, а собственную подсказку. Эксперимент становится нечестным.
Автор признал, что ранние измерения с per-task подсказками подгоняли результат, и отказался от них.
Как единая схема связей компонентов вернула 8/8 без подсказок
Замена была архитектурной. Единая схема связей компонентов описывает, как элементы системы связаны между собой, и не зависит от конкретной задачи. Система получает не намёк на решение, а карту того, где хранятся требования, какие из них пересекаются и как отменяют друг друга. С такой картой она снова решает 8/8, но уже честно.
Здесь важна оговорка: возврат к 8/8 не доказывает универсальность подхода. Он доказывает, что на этом синтетическом наборе механизм работает без внешних подсказок.
Кому и когда нужен intent continuity, а когда хватит других подходов
Подход оправдан там, где агент живёт долго: работает над проектом неделями, накапливает правила и решения, а цена ошибки растёт вместе со временем. Долгоживущие агентные пайплайны - основной сценарий. Похожий класс задач разобран в кейсе про сборку персональной книги знаний из 206 видео, где агент работает с большим объёмом материала, проверкой provenance и дедупликацией смысловых повторов.
Признаки того, что вашему агенту нужна верификация требований
- Агент повторяет ошибки, которые вы уже разбирали в прошлых сессиях.
- Он игнорирует правила проекта, хотя они записаны в документации.
- Требования из разных задач перемешиваются, и правило применяется не к тому модулю.
- Правила менялись по ходу проекта, а агент продолжает использовать старые.
Если это знакомо, стоит присмотреться к слою верификации. Гарантий он не даёт.
Ограничения подхода и что он не решает
Первое ограничение прямое: результаты получены на синтетическом наборе из 70 взаимодействий, 12 требований и 8 задач. Независимого воспроизведения в открытых материалах нет. В реальных проектах требования нечёткие, конфликтующие и меняются чаще, чем в контролируемом датасете.
Второе: версия без эмбеддингов может не улавливать семантические связи. Требование, сформулированное другими словами и не попавшее в структурную схему, будет потеряно.
Третье: intent continuity не лечит галлюцинации. Если агент уверенно выдумал функцию или ссылку, проверка требований к истории проекта тут не поможет.
Альтернативы стоит держать в голове. Длинный контекст проще в настройке, но не верифицирует. RAG даёт семантический поиск, но не проверяет актуальность. Ручное управление правилами надёжно, но трудоёмко и плохо масштабируется на команду. Универсального победителя нет.
Как подойти к реализации: три проверки и единая схема связей
Концептуальный план выглядит так: хранить требования из прошлых сессий в структурированном виде, извлекать кандидатов под новую задачу (лексическим поиском хотя бы как черновой фильтр), прогонять три проверки и только после этого отдавать требования агенту. Каркас держится на единой схеме связей компонентов, а не на подсказках под конкретную задачу.
Вся логика помещается в чистый Python. Это заметно упрощает встраивание: нет вызовов LLM на каждом шаге, нет векторной базы, нет расходов на инференс. Такой слой верификации легко добавить рядом с существующим агентом, не переписывая его. Общий инженерный паттерн самопроверки в агентах разобран в разборе архитектуры LLM-агентов с верификацией.
Три проверки на практике: актуальность, перекрытие, релевантность
Под каждую проверку нужны свои правила.
- Актуальность. Сравнить версию или дату требования с текущим состоянием проекта. Требование, привязанное к удалённому модулю, теряет силу.
- Перекрытие. Найти более новое требование, которое отменяет старое. Часто это пара «решение принято» и «решение изменено».
- Релевантность. Сопоставить требование с текущей задачей и не тащить в неё лишние ограничения.
Готового алгоритма для этих проверок автор не приводит, поэтому формулировать их придётся под свой проект.
Почему единая схема связей компонентов лучше per-task подсказок
Per-task подсказки подгоняют результат под конкретную задачу и не масштабируются: для каждой новой задачи нужна новая подсказка, а значит, решения снова принимает человек. Единая схема связей компонентов описывает систему целиком и не зависит от задачи. Цифры говорят сами: с подсказками 8/8, без них 6/8, после доработки снова 8/8 уже без подсказок.
Это не готовое решение, а подход, который нужно адаптировать под свои требования, свой репозиторий и свою дисциплину ведения правил. Начинать разумно с малого: зафиксировать требования в структурированном виде, добавить проверку перекрытия, а остальное наращивать по мере появления реальных провалов. Ревью кода агента остаётся обязательным, и о том, почему скорость генерации не отменяет проверку, подробно написано в материале про риски слепого доверия к AI-агенту.