Задайте большой языковой модели вопрос — она даст ответ. Задайте тот же вопрос через неделю — получите примерно то же самое: не лучше и не хуже. Модель не помнит прошлую неделю, не знает, что кодовая база с тех пор ушла вперёд, и не имеет никакого механизма заметить, что совет, который она только что дала, противоречит решению, принятому командой три коммита назад. Это тихий потолок, в который упирается большинство команд: агенты полезны в конкретный день, но по-настоящему лучше в вашей работе они не становятся никогда.
Из этого плато есть выход, и он не требует модели побольше. Он требует дать агентам то, чего у них обычно нет, — ночную смену. Эта статья описывает подход, который мы держим в продакшене: команда узких агентов, которые по расписанию и в основном тогда, когда за ними никто не смотрит, перечитывают собственные инструкции, изучают код, за который отвечают, вытаскивают наружу найденный техдолг и возможности и предлагают улучшения самим себе — на утверждение человеку. Откуда взялась идея, как устроен базовый цикл, как не превратить всё это в дорогую свалку и почему выигрыш накапливается.
Агенты, которые не становятся лучше
Обычный способ использовать LLM — без состояния и реактивно. На входе промпт, на выходе ответ, контекст выброшен. Для разовой задачи это нормально, но у такого режима три структурные проблемы, как только вы пытаетесь сделать агента постоянной частью команды.
Гниение контекста. Агент хорош ровно настолько, насколько хорош данный ему контекст. Кодовая база меняется каждый день; инструкции — почти никогда. За считанные недели картина мира агента тихо устаревает: он ссылается на переименованный модуль, на отброшенное соглашение, на сервис, которого больше нет.
Дрейф инструкций. Когда инструкции агента вы всё же поддерживаете вручную, они дрейфуют в другую сторону: копят правила для ситуаций, которых уже не бывает, противоречат друг другу и обрастают длинным хвостом указаний, которые никто не перечитывал месяцами. За то, чтобы это замечать, никто не отвечает.
Ничего не накапливается. И самое обидное: ничего не накапливается. Каждая сессия стартует с нуля. Коллега-человек, который в прошлом месяце разбирал ваш модуль платежей, приносит этот контекст в новый месяц; агент без состояния каждый раз выводит его заново — и плохо. Получается гениальный стажёр с полной амнезией — а амнезию никаким промпт-инжинирингом не лечат.
Лечение — не более умная модель. Это практика: повторяемая процедура по расписанию, которая превращает разовые ответы в растущий корпус знаний.
Дайте команде ночную смену
Идея проста в формулировке: пусть агенты работают, пока вы не работаете — не над продакшен-кодом, а над собственным его пониманием. Каждую ночь планировщик по очереди будит несколько агентов. Каждый перечитывает описание собственной роли, выборочно смотрит на ту часть кода, за которую отвечает, и записывает, что понял: на что смотреть, что выглядит неправильно, что он спросил бы, прежде чем что-то трогать. И, что важно, отмечает, где его собственные инструкции уже не соответствуют реальности, и набрасывает предлагаемую правку. К утру у вас стопка коротких конкретных заметок и несколько предложенных самоулучшений, ждущих ревью.
Мы называем это сновидением (dreaming), и это не просто маркетинг — название прямо указывает, откуда взялась идея.
Откуда взялась идея
Мысль о том, что интеллект улучшается в офлайне — в простое, без нового входа из внешнего мира, — стара и приходит сразу с нескольких сторон.
Из нейронауки. Мозг учится не только бодрствуя. Во сне он воспроизводит опыт прошедшего дня, консолидирует важное в долговременную память, а лишнее отсекает. Обучение — это не только получение, но и консолидация, а консолидация происходит, когда система «в офлайне».
Из обучения с подкреплением. Тот же принцип известен как повтор опыта (experience replay): агент хранит свой опыт и учится на нём позже, офлайн, отдельно от действия. Целое направление «модельных» агентов идёт дальше — они выучивают сжатую модель среды и совершенствуются, «воображая» прогоны внутри неё: буквально учатся на снах, а не на новом взаимодействии.
Из агентов на LLM. Самая полезная свежая линия — саморефлексия: агенты, которые критикуют собственный вывод, ведут память о том, что сработало, и подмешивают эти рефлексии в следующую попытку. Смежные работы дают долгоживущим агентам поток памяти, который они периодически сворачивают в рефлексии более высокого уровня, и библиотеки навыков, растущие со временем, — так агент становится способнее, чем дольше живёт.
Из инженерии. Ничто из этого не выживет в продакшене без второй половины родословной — операционной дисциплины cron-задач, непрерывной интеграции и практик SRE (ротации, таймауты, наблюдаемость), плюс привычки docs-as-code и infrastructure-as-code держать источник истины в системе контроля версий. По сути, здесь применяется принцип agents-as-code: сами агенты — это файлы в вашем репозитории, и улучшение агента — такое же ревьюируемое изменение, как любое другое.
Имя для недостающего куска. Андрей Карпаты сформулировал ту же интуицию резко. В разговоре 2025 года он заметил, что человек во сне дистиллирует контекст прошедшего дня в веса мозга — а у сегодняшних моделей нет аналогичной фазы дистилляции, и именно поэтому он относит непрерывное обучение и постоянную память к тем недостающим кускам, из-за которых агенты разваливаются на настоящей работе. Отдельно он набросал парадигму, которую назвал system prompt learning (обучение через системный промпт): вместо того чтобы менять веса градиентным спуском, модель должна учиться так, как человек ведёт заметки, — по сути писать себе книгу о том, как решать задачи, и улучшать её правками. Подход из этой статьи — конкретная, с человеком у шлагбаума, реализация ровно этого: инструкции агента — это книга, самообучение — ведение заметок, а предложение по эволюции — правка.
Сложите обе половины — «системы улучшаются в офлайне, воспроизводя и консолидируя опыт» из науки и «автоматизируй безопасно, держи всё в контроле версий, оставь человека в контуре» из инженерии — и вы получите практику, о которой эта статья.
Цикл самообучения
Всё держится на одном базовом цикле, выполняемом на каждого агента. Он намеренно маленький и ограниченный: цель — законченная заметка каждую ночь, а не идеальная карта репозитория.
1. Перечитать роль. Агент начинает с чтения собственного описания — для чего он и как должен себя вести. Это опорная точка: всё остальное измеряется относительно неё.
2. Выборочно посмотреть код — в рамках бюджета. Затем он смотрит на свою часть системы: файлы-манифесты, раскрывающие стек, листинг директорий, пару файлов, которые упомянуты в его же инструкциях по имени. Бюджет строгий намеренно — горстка чтений, а не сплошной обход. Короткая точная заметка лучше долгого расследования, которое так и не завершится, а жёсткий бюджет держит каждый запуск дешёвым и быстрым.
3. Написать учебную заметку. Результат — короткая markdown-заметка: роль агента в одном предложении, список наблюдения из трёх-пяти конкретных вещей, которые стоит проверить именно в этом репозитории (не общие советы), и один уточняющий вопрос, который агент задал бы человеку перед нетривиальным изменением. Это шаг консолидации — «что я сегодня узнал».
4. Обнаружить расхождение. По ходу чтения агент сверяет свои инструкции с тем, что реально находит. Файл, на который ссылаются инструкции, исчез. Правило описывает поток, которого больше нет. Отсутствует предохранитель. Само несоответствие и есть находка — и агенту прямо запрещено идти это чинить, только зафиксировать.
5. Предложить эволюцию. Когда несоответствие структурное — не опечатка, а настоящий разрыв, достойный ревью, — агент пишет отдельное предложение по эволюции: что не так, конкретное изменение в его собственном описании и обоснование. Это шаг самоулучшения и самое важное проектное решение во всём подходе: агент предлагает, решает человек. Это обучение правками, а не градиентным спуском — то самое system prompt learning Карпаты, — только перо держит человек. Агент никогда не правит свои инструкции напрямую. Человек смотрит предложение и применяет его за пару минут — или отклоняет.
Гоняйте этот цикл ночами по всей команде — и инструкции агентов перестают гнить. Они следуют за кодом, а не отстают от него, потому что лучше всех заметить, что инструкция устарела, способен тот агент, который читает инструкцию и код одновременно.
Один паттерн, много линз
Как только у вас есть безопасный способ запускать ограниченного агента по расписанию и собирать его вывод в артефакт, самообучение — лишь первое применение. Тот же механизм наводится на другие вопросы простой заменой промпта.
Поиск техдолга. Еженедельный проход читает репозиторий так, как это делал бы senior-инженер в плохой день: ищет TODO/FIXME/HACK, находит файлы с подозрительно частыми изменениями, пропущенные тесты, файлы на тысячу строк, дублированную логику — и заводит верхнюю горстку как конкретные, ограниченные, стоящие того пункты. Не десять тысяч придирок линтера, а пять вещей, реально стоящих чьего-то рабочего дня.
Генерация продуктовых идей. Другая линза читает тот же код и спрашивает, чего не хватает: какие фичи архитектура делает дешёвыми, какие пробелы почувствует пользователь — и заводит их как ревьюируемые идеи, в один клик от превращения в задачу в вашем трекере.
Операционные циклы. Ещё одна документирует повторяющиеся процессы команды — CI/CD, релиз, дежурства, ретро — как живые описания: триггер, шаги, режимы отказа, куда смотреть в первую очередь, когда что-то ломается.
Здоровье базы знаний. Ещё одна держит документацию проекта честной, отмечая, где написанная вики разошлась с кодом.
Объединяющая мысль: каждая линза — это узкий, запускаемый по расписанию, ограниченный агент, единственная задача которого — замечать и фиксировать, а не менять код. Разнообразие даёт вопрос, а не новый механизм.
Справедливость и предохранители
Запуск агентов без присмотра, по расписанию, порождающих реальные вызовы модели за реальные деньги, — это ровно та автоматизация, которая превращается в кошмар, если построить её наивно. Дисциплину, которая это предотвращает, целиком заимствуют из эксплуатации.
Ротация. Гонять всех агентов каждую ночь обычно не нужно — это долго и дорого. Вместо этого агенты стоят в ротации, и планировщик берёт верхних: сначала новых, затем тех, кого изучали дольше всего назад, а приоритетный тир поднимает наверх самых важных. Каждый агент получает свою очередь, никто не голодает, а важные приходят чаще. Та же логика справедливости, что и у графика дежурств.
Ограничение параллелизма. Глобальный лимит означает, что, даже если подошёл десяток агентов, одновременно бегут один-два. Машина остаётся отзывчивой, а расходы — предсказуемыми.
Таймауты и сторож. Каждая сессия ограничена по времени. Сторож следит за выводом; если запуск надолго замолкает, его убивают. Самообучение по замыслу — для коротких обзорных сессий, а не место, куда прячут долгие задачи без конца.
Сверка. Процессы иногда умирают некрасиво. Сверщик периодически проходит и закрывает любую сессию, чей процесс исчез, но запись всё ещё говорит «работает», чтобы баланс всегда сходился.
Ничего экзотического. Это скучный операционный слой — расписания, квоты, таймауты, проверки здоровья, — который превращает груду скриптов в то, что действительно можно оставить работать.
Направленная работа: оркестрация и контрольные ворота
Самообучение и сканеры — автономны и фоновы: никто ничего конкретного не просил, агенты просто держат базу знаний свежей. Зеркальная противоположность — направленно и на переднем плане: у вас есть конкретная цель, и вы хотите, чтобы команда её выполнила. Тех же агентов можно вести и так.
Здесь супервайзер берёт свободно сформулированную цель — «спроектировать и реализовать фичу X в модуле Y» — и раскладывает её на подагентов, разводя работу и собирая обратно. Для чего угодно нетривиального запуск структурируют как каскад: конвейер фаз с контрольными воротами между каждой.
Типичный каскад идёт: контракт → дизайн → реализация → ревью → QA. Между фазами стоят ворота, выдающие один из трёх вердиктов: одобрить (идти дальше), вернуть на этап (недостаточно хорошо, итерируем) или отклонить (остановить запуск). Ворота — это и есть суть. Если пустить всё насквозь, шаткий контракт отравляет дизайн, тот — реализацию, и обнаружите вы это всё на QA. Ворота ловят проблему на границе, где чинить дешевле всего, и делают качество запуска читаемым: видно ровно, где застряло и почему.
Это тот же инстинкт, что и у поэтапных CI-конвейеров и чекпойнтов дизайн-ревью, применённый к команде агентов вместо команды людей.
Артефакты как интерфейс
Сквозь всё вышесказанное проходит нить, которую легко пропустить и стоит проговорить явно: вывод каждого агента — это обычный файл в вашем репозитории. Учебная заметка, предложение по эволюции, пункт техдолга, идея, цикл, план — каждый является markdown с небольшим структурированным frontmatter, записанным в обычную папку и закоммиченным в git.
Один этот выбор даёт многое.
Долговечность и аудит. Вывод переживает сессию. Через полгода можно прочитать, почему агент что-то отметил, увидеть в diff, как менялось его понимание, и проследить строку до той ночи, когда её написали.
Переносимость. Markdown-с-frontmatter не привязан ни к вендору, ни к модели, ни к дашборду. Замените модель, смените исполнителя, выбросьте инструмент целиком — артефакты всё равно останутся файлами, которыми владеете вы.
Человек в контуре по умолчанию. Раз вывод — это файл, а самомодификация — это предложение, ревью становится обычной частью процесса: diff, pull request, кнопка «одобрить», а не особый аварийный люк. Агенты генерируют, решают люди.
Композиция вне зависимости от инструмента. Поверх может строиться что угодно, умеющее читать файлы: дашборд для просмотра заметок, «в один клик превратить идею в задачу», метрика по объёму открытого техдолга. Артефакты — это стабильный интерфейс; всё остальное — опционально.
Почему это работает
Если собрать воедино, подход окупается по нескольким связанным причинам.
Оно накапливается. Одна ночная заметка почти ничего не стоит. Триста таких, накопленных и консолидированных за год, — это живая база знаний о вашей системе, которую никому не пришлось садиться и писать. Именно маленькие скучные приращения и накапливаются — потому что они действительно случаются.
Оно бьёт по дрейфу в источнике. Лучше всех заметить, что инструкция устарела, способен агент, который читает эту инструкцию и текущий код на одном дыхании. Самообучение ставит обнаружение дрейфа туда, где есть информация, вместо надежды, что человек вспомнит про аудит.
Оно дёшево там, где должно. Ограниченные, короткие, внепиковые запуски по отдельности стоят мало. Вы тратите простой и мелочь, чтобы держать большую поверхность тёплой.
Оно управляемо и наблюдаемо. Ротация, квоты, таймауты и артефакт на каждый запуск означают, что это не чёрный ящик непрозрачной автоматизации. Видно, что запускалось, что оно произвело и сколько стоило, — и любое можно выключить.
Ответственности разделены. «Мозги» агентов живут рядом с кодом, о котором они рассуждают; планировщик и оркестратор — тонкий управляющий слой сверху. Ни один не владеет другим, так что менять можно любой по отдельности, — и тот же управляющий слой ведёт хоть один проект, хоть пятьдесят.
Компромиссы и когда не стоит
Это не бесплатно и для части задач — неправильный инструмент. Честность об этом — часть предложения.
Нужна дисциплина ревью. Человеческие ворота — это фича, но и постоянная обязанность. Если предложения никто не смотрит, они копятся, и ценность цикла утекает. Подход предполагает команду, которая потратит несколько минут в день на «да» или «нет».
Оно тратит токены. Скромно за запуск, ощутимо в сумме. Ротация и лимиты параллелизма и существуют, чтобы это ограничивать, но это статья расходов, и на крошечном или одноразовом проекте она себя не окупит.
Вывод недетерминирован. Две ночи — две слегка разные заметки. Для поиска и консолидации это нормально: смысл в том, чтобы вынести вещи человеку, — но это значит, что сырой вывод агента нельзя заводить напрямую в то, что требует детерминизма.
Оно вознаграждает гигиену. Агенты хороши ровно настолько, насколько хороши написанные вами роли и папки, куда вы разрешаете им писать. Принцип «мусор на входе» никто не отменял: цикл делает лучше хорошо определённого агента, а не связным — расплывчатого.
Если проект маленький, короткоживущий или целиком в голове одного человека, живущего в нём каждый день, — пропустите. Подход окупается на системах достаточно больших, достаточно долгоживущих и разделённых между достаточным числом людей, чтобы никто не держал всё это в голове. Именно там гниют знания — и именно там ночная смена окупается.
Как начать с малого
Ничего из этого не внедряют целиком. Минимально жизнеспособная версия почти неловко мала — и в этом весь смысл.
Начните с одного агента, одной заметки, одной привычки. Напишите одно описание агента для важной вам части системы. Пусть он произведёт одну заметку самообучения — руками, по таймеру, как угодно. Прочтите её на следующее утро. Если список наблюдения полезен, а отмеченный дрейф реален, — вы проверили всю идею за копейки.
Дальше добавьте цикл: запускайте по расписанию. Дальше добавьте ворота: разрешите предлагать изменения в собственное описание и заведите привычку одобрять или отклонять их. Дальше добавьте второго агента и вторую линзу — техдолг, потом идеи. Каждый шаг полезен сам по себе; ни один не требует следующего. К тому времени, как у вас будет полная команда на ночной ротации с оркестрацией и воротами, каждый кусок уже заслужит своё место.
Вся суть — в смене мышления: перестаньте относиться к ИИ как к торговому автомату, к которому подходят за ответом, и начните относиться к нему как к команде, которая становится чуть лучше каждую ночь — пока вы спите.
Частые вопросы
- Что такое самоулучшающиеся команды ИИ-агентов?
- Это команда узких ИИ-агентов, которые живут рядом с кодовой базой и работают по расписанию, в основном ночью. Каждый агент периодически перечитывает собственные инструкции, изучает код, за который отвечает, и записывает, что понял, — вытаскивая техдолг, идеи и предлагаемые правки к своим же инструкциям на утверждение человеку. Цель — чтобы агенты со временем становились лучше именно в вашей работе, а не упирались в потолок.
- Как устроен цикл самообучения?
- Это небольшой ночной цикл, выполняемый для каждого агента: агент перечитывает свою роль, выборочно смотрит код в рамках строгого бюджета, пишет короткую заметку со списком наблюдения и уточняющим вопросом и находит расхождения между инструкциями и реальным кодом. Только когда несоответствие структурное, он набрасывает предложение по правке собственного описания на ревью человеку.
- Агенты сами переписывают свои инструкции автоматически?
- Нет. Агент только предлагает изменение, а человек его просматривает и применяет или отклоняет. Именно этот принцип «агент предлагает, решает человек» делает подход безопасным для запуска без присмотра: плохое предложение ничего не стоит, а хорошее уже сделало самое трудное — заметило расхождение и написало правку.
- Откуда взялась идея «сна»?
- Сразу с нескольких сторон: консолидация памяти во сне в нейронауке, повтор опыта и «модельные» агенты в обучении с подкреплением, а также агенты с саморефлексией, которые хранят память о том, что сработало, — вместе с операционной дисциплиной расписаний, ротации и контроля версий. Андрей Карпаты сформулировал те же интуиции: у сегодняшних моделей нет фазы дистилляции, похожей на сон, и он описал «system prompt learning», где модель улучшается, редактируя собственные заметки, а не градиентным спуском.
- Когда этот подход стоит внедрять, а когда нет?
- Он окупается на кодовых базах, которые достаточно большие, долгоживущие и разделены между достаточным числом людей, чтобы никто не держал всё в голове, — именно там знания устаревают. Пропустите его на крошечных или одноразовых проектах: он тратит токены и требует дисциплины реально просматривать предложения. Рекомендуемый вход — начать с малого: один агент, одна ночная заметка и одна привычка ревью, — а потом расти.