Мвп готов, готовы два воркера, легкий и тяжелый, разница между ними заключается в том, что первый вид оперирует информацией из базы знаний, второй делает запросы в ллм и пишет в qdrant. После праздников займусь другими составляющими фабрики, нужна быть точно оркестрация, агент-исследователь по идеологии DS-STAR, про которую писал уже в канале, также потребуется декомпозиция задач (еще один тип воркера) и агент-критик. На праздниках буду перечитывать имеющиеся книги, как бумажные, так и электронные и обдумывать задачи и знания, которые потребуются для фабрики, есть уже мысли как интегрировать в нее производство скиллов и агентов, связанных с ллм. Но об этом всем расскажу уже в Новом, 2026-м году. Всех с наступающим НГ!

Давно не писал сюда, нужно исправляться, за это время (и в свободное от работы) поучаствовал в разработке LocalDesk он же ValeDesk. В том числе запилил туда фичу запуска нескольких сабагентов с разными ролями, практически команда разработки как в жизни - PM, TeamLead, Arhitect, Analyst, QA, DevOps, Front & Back Devs. Каждый сабагент решает задачу согласно своей роли, вывод идет в общий поток, получилось довольно интересно. Можно переиспользовать, например, в курсоре - планировать спринты, запускать, выносить техдолг, определять приоритеты - тоже попробовал на небольшом проекте. Думаю, что буду периодически использовать, сделал набор cursor rules для такой реализации. Не стал участвовать в модной ныне теме - clawbot, moltbot, openclaw. Некоторые с помощью opus 4.6 напилили аналоги такого бота для тг. Если бы была необходимость в таком боте, сделать весьма несложно, необязательно использовать под него топовую модель. Главное, ограничить на уровне кода опасные операции, вынести рабочее пространство в докер, чтобы у пользователей не было возможности подсмотреть или повлиять на других.
Задумался над агентами для суммаризации и сжатия контекста. Хочу их использовать с неожиданной стороны, сделать возможность построения AST дерева по коду и его сжатия, отбрасывать ненужные куски для конкретной задачи. Первое, о чем подумал, сделать проверку архитектурных схем и/или паттернов по исходному коду. Для чего это нужно, периодически проверять текущий код, не было ли там изменений, сломавших спроектированное поведение, например, не нарушена ли диаграмма последовательности. Это уместно как для вайбкода, так и крупных проектов. Еще бывает потребность получить алгоритм работы на псевдоязыке для какого-то процесса или функции. В проекте много кода, искать по нему бывает трудно, особенно, если изучаемый код находится в нескольких файлах. Думаю, что еще найдутся примеры полезности таких агентов для меня. Буду держать в курсе.

я сделал прототип для самообучающейся фабрики, которая сохраняет код решения задачи на абстрактном языке в базе знаний и потом переиспользует для похожих по тексту задач вместо запросов llm. Проект вышел достаточно сложным и у меня возникла мысль его упростить, точнее не саму фабрику, а исходную мысль. А что если сделать самообучаемого агента в том виде, как сейчас их "готовят". Из самого простого (и как сделано в примере реализации DGM от SakanaAI) - можно модифицировать промпт, еще по аналогии просится набор tools/skills - их также можно изменять под нужную задачу. Но чтобы сделать именно самообучение агентов, достаточно ли таких изменений. Поставил задачу llm проанализировать подходы в таких случаях, получил следующую картину:

Если ваша среда даёт быструю и проверяемую обратную связь (юнит‑тесты, валидаторы формата, симулятор, “правильно/неправильно”), то агент может существенно улучшаться без дообучения весов за счёт:
рефлексии/разбора ошибок + повторных попыток (например, подходы в духе Reflexion учат агента сохранять “уроки” из провалов и пробовать снова)
Источник: Reflexion (arXiv:2303.11366) — улучшение через динамическую память и self-reflection без fine-tuning.
библиотеки навыков (код/шаблоны действий) + извлечение по похожести
Источник: Voyager (arXiv:2305.16291) — “lifelong learning” в Minecraft через библиотеку навыков и итеративные подсказки, без обновления весов.
улучшения маршрутизации инструментов и “когда звать инструмент”
Источник: Toolformer (arXiv:2302.04761) показывает важность политики вызова инструментов (там через обучение, но идея применима и как инженерная политика/роутер).
Иными словами: одни только промпты/тулы могут дать заметный эффект, если у вас есть:

измеримая цель,
механизм хранения опыта,
цикл “попробовал → оценил → извлёк урок → изменил стратегию”.

Изменение промптов и tools недостаточно, по мнению llm в таких случаях:

Во многих реальных задачах “самообучение” ломается, если нет ещё нескольких компонентов:
Функция качества (reward/metric)
Без метрики вы оптимизируете “ощущение” качества, а не качество. Нужен хотя бы суррогат: тесты, правила, ранжирование, бизнес‑метрика.

Контур данных и верификации
Агент должен уметь собирать датасет собственных попыток (state, action, tool I/O, outcome) и отделять:

“я сделал хорошо” vs “мне просто повезло”,
“модель убедительно написала” vs “результат корректен”.

Память (долгосрочная) и политика её обновления
“Менять промпт” без памяти — это амнезия между эпизодами. Нужны:

хранилище опыта,
индексация/поиск,
правила: что сохранять, что забывать, как обобщать.

Защита от дрейфа и регрессий
Самоизменение промптов/тулов часто ведёт к:

деградации на старых задачах,
росту длины промпта (“prompt bloat”),
переоптимизации под узкий набор проверок.

Безопасность
Агент, который сам себе меняет промпт и инструменты, уязвим к:

prompt injection (особенно через веб/документы),
“reward hacking” (обман метрики),
утечкам секретов через инструменты/логи.

Из этого можно сделать вывод, что не хватает наличия памяти, рефлексии и ретраев. То есть, агент после провала формирует краткий урок, сохраняет его в память, и при повторе извлекает релевантные уроки.

Пока это наброски мысли, буду дальше смотреть варианты и исследовать возможности, не забывая о возможных недостатках.

Нашел свои бумажные записи. Код, который должен храниться в базе знаний состоит из четырех основных типов (прямо как нуклеотиды в ДНК). Последовательность, выбор, итерации, косвенность. Последовательность - это выполнение инструкций одна за другой в порядке записи. Выбор - это выполнение разных веток программы в зависимости от условия. Итерации - это повторение действий. Косвенность - это обращение не напрямую, а через посредника, то есть программа работает через ссылку, указатель, функцию, интерфейс или абстракцию. Иногда эти типы называются базовыми управляющими структурами. Любую программу можно собрать из комбинации этих конструкций. Почему я заостряю на этом внимание, ведь по сути можно же собрать большую древовидную или графовую структуру, в которой по некоторым путям можно собирать конкретные алгоритмы. И можно совместить формирование алгоритма для решения некой задачи с обходом графа. Чем это не ДНК, а ее фрагменты - белки?

Сегодня смотрел на проект Карпатого microgpt, решил попробовать переписать его на другой язык, сначала на go, потом посоветовали переписать на раст и еще было предложение с фортраном. Еще от себя решил чуть оптимизировать алгоритм на go за счет алгоритма fused, в итоге получилось, что фортран впереди всех за счет крайней оптимизации векторно-матричных операций. Посмотрел я на это все, как будет свободное время, попробую запустить на фортране инференс на qwen3.5-0.8b на cpu и сравнить с ollama/llama.cpp по скорости генерации, как говорится, а вдруг )

И еще вдогонку из интересного. Не раз читал у Валеры в канале про Ralph loop - так называемую петлю или цикл Ральфа. А сегодня у Алексея увидел ссылку на линкедин, где были разобраны три варианта. Вкратце, суть в том, что первый вариант - это использование того же промпта с ограниченным максимальным количеством итераций, иными словами мир меняется вокруг модели. Второй вариант - наличие внешнего верификатора, который проверяет, выполнены ли критерии, то есть меняется место принятия решения об успехе. Третий вариант - изменение артефактов, формирующих следующую попытку, то есть агент не просто еще раз пробует решить задачу - он меняет собственный рабочий контур перед следующей попыткой. Все эти три варианта имеют место быть, но... можно собрать решение на основе всех трех слоев, с небольшими улучшениями - в первом случае сделать структурное завершение - например, done, blocked, questions - это сильно уменьшает риск ложного "готово". Во втором внешний верификатор сделать многоступенчатым, сначала проверка по правилам, потом интеграционные тесты, потом llm-as-judge или human review, тогда агент будет меньше оптимизировать прокси-метрику и чаще закрывать реальную задачу. В третьем разбить артефакты на изменяемые и неизменяемые, это делает схему намного безопаснее, так как возможен дрейф - когда агент закрепит неудачную гипотезу как истину. И еще есть существенное но... у агентов типа codex/claude code уже есть своя агентная петля/цикл. Например, codex работает по схеме:

plan → edit → run tools → observe → repair → update docs/status → repeat

и вводить Ralph поверх Ralph - не очень вариант, а вот добавлять во внешний цикл верификатор/оркестратор - идея получше. Думаю, что попробую реализовать такой подход для примера.

Откуда взялось название Ralph loop?
Ральф Виггам из Симпсонов - тот самый мальчик, который с невозмутимым упорством продолжает делать свое дело, несмотря ни на что. Подход назван в его честь: ИИ-агент, который не останавливается.
Придумал такой подход Джеффри Хантли - австралийский разработчик. Его оригинальная идея умещалась в одну строку:
пока правда: отправь задание -> агент работает -> проверь результат -> не готово? -> повтори.
Классический агент (или промпт в llm) работает так: получил задачу, подумал, ответил, забыл. Одна попытка - один результат. Петля Ральфа работает чуть иначе:
1) вы описываете задачу и четкие критерии приемки (тесты проходят, нет ошибок, все собирается)
2) агент берется за задачу
3) когда он думает, что закончил - внешний скрипт проверяет, реально ли все готово?
4) если не готово, то скрипт подсовывает задание обратно, и цикл повторяется
5) если готово, то цикл останавливается.

Главная хитрость - агент не помнит свои прошлые попытки. Вместо этого он смотрит на файлы проекта и историю изменений. Каждая попытка как чистый лист, но вся предыдущая работа видна в файлах.

Почему это важно. Модель в общем случае сама решает, когда она закончила, и часто ошибается, решение есть, а тесты/линтер/сборка падают. Использование петли Ральфа добавляет объективную проверку. Тесты проходят? Код собирается? Линтер не выдает ошибок? Тогда и готово.

Где это уже используют. Механический рефакторинг - переписать 100+ файлов с одного формата тестов на другой. Увеличение покрытия кода - добавь тесты, пока покрытие не достигнет 80%. Создание проектов с нуля по четкому ТЗ. Миграции - перевод кодовой базы на новые версии библиотек, другой язык программирования.

Что можно улучшить. Тройной самоучитель - три роли из одной модели, одна придумывает задачи, другая решает, третья судит. Все трое учатся одновременно, подтягивая друг друга. Дистилляция опыта, когда агент не просто запоминает, что делал, а извлекает из своего опыта абстрактные принципы, например, что в таких ситуациях делать так.

Чего не хватает такому алгоритму. Приток новой информации, нужны свежие данные извне. Рост возможностей, так как статичная система выходит на плато. Разделение ролей, придумывать задачи и проверять решения должен не тот, кто решает.

Из данного алгоритма можно и нужно делать гибриды. Это не революция в ИИ, это инженерная находка, которая использует простую идею с правильной проверкой. А часто именно простые идеи дают самый мощный результат.

Журнал экспериментов.
Как ИИ ставит сто опытов за ночь.
Есть способ заставить ИИ работать как настоящий ученый, то есть выдвигать гипотезы, ставить эксперименты, записывать результаты, и повторять, пока не получится. Не один раз, сотню раз, пока вы спите.

Идея в одном предложении.
ИИ-агент бесконечно крутит цикл: придумал -> попробовал -> измерил -> получилось? -> оставил, не получилось? -> откатил -> записал в журнал -> следующая попытка.
Это называется механизм храповика, как трещотка в часах, движение возможно только в одну сторону. Каждое удачное изменение фиксируется, каждое неудачное отменяется. Деградация невозможна по конструкции.

Как это устроено.
Представьте лабораторный журнал, исследователь пишет:
Эксперимент №1: Увеличил скорость обучения. Результат улучшился. Оставляю.
Эксперимент №2: Уменьшил глубину модели. Стало хуже. Откатываю.
Эксперимент №3: Добавил нормализацию. Упало с ошибкой. Записываю как сбой.

Ключ: код проекта содержит только успешные изменения, а журнал вообще все попытки, включая провалы и падения. Две системы записи работают параллельно: история изменений кода (только то, что улучшило результат), журнал экспериментов (полная картина по попыткам). Агент из первой системы понимает текущее состояние, а из второй, что пробовать уже не стоит.

Чем это отличается от простого цикла.
В прошлом посте я рассказывал про бесконечный цикл (петля Ральфа), где агент повторяет задачу, пока внешняя проверка не подтвердит, что готово. Тот подход хорошо для инженерных задач. Журнал экспериментов для другого, для исследований, где нет единственного правильного ответа. Есть метрика, например, число, которое нужно улучшить, и есть пространство возможных решений, которое нужно исследовать.

Бесконечный цикл Журнал экспериментов
Цель Довести задачу до конца Найти лучшее решение
Критерий Тесты прошли / не прошли Метрика стала лучше / хуже
Что делает
с провалом Пробует заново Записывает и учитывает
Код при
провале Остаётся как есть Откатывается к предыдущему состоянию
Память о
неудачах Нет Да, в журнале

Кто это уже делает.
Ринат Абдуллин в канале LLM under the hood разобрал красивый вариант этого паттерна. Агент ведет полноценный дневник исследований с отдельным файлом на каждый эксперимент: что сейчас есть, какая гипотеза, что собираюсь менять, какой результат получил. Если результат лучше, то сохраняет и код, и дневник. Если хуже - откатывает код, дневник оставляет. В следующей итерации агент читает свои прошлые записи и не наступает на те же грабли. Запускается цикл на 50+ итераций, и агент часами молотит сам, улучшая метрику шаг за шагом.

Андрей Карпатый выложил в открытый доступ минималистичную версию того же подхода. 630 строк кода, один компьютер с видеокартой. Вместо отдельных файлов единая таблица результатов: номер эксперимента, метрика, статус (оставлено/откачено/упало). Результат: 100 экспериментов за ночь, 20 успешных улучшений, модель стала обучаться на 11% быстрее и без участия человека.
Каждый эксперимент занимает ровно 5 минут. 12 штук в час, за 8 часов почти сотня. Утром вы просыпаетесь и открываете таблицу результатов, которую агент составил, пока вы спали.

Два варианта одного паттерна, у Рината развернутый дневник с ходом мыслей, у Андрея - лаконичная таблица с числами. Первый лучше подходит, когда важно понимать почему что-то работает, а второй, когда важна только метрика и скорость перебора.

А что еще интереснее.
Коллективные исследования. Несколько ИИ лабораторий работают параллельно и выкладывают свои результаты на общую площадку, как ученые публикуют свои статьи. Агенты читают работы друг друга и строят на них свои эксперименты. Результат: 14% к эффективности по сравнению с одиночной работой.
Поиск по дереву вместо линейного перебора. Вместо того, чтобы пробовать улучшения одно за другим, агент строит дерево экспериментов - разветвляет перспективные направления, прекращает тупиковые. Результат: первая научная статья, полностью написана ИИ и принятая на рецензируемый воркшоп.

Для чего это можно применять.
Оптимизация моделей машинного обучения: подбор архитектуры, гиперпараметров.
Улучшение промптов: автоматический поиск лучших формулировок для llm.
Оптимизация любого кода с измеримой метрикой: скорость, потребление памяти, точность.
Подбор конфигураций: серверы, базы данных, сетевые настройки.
A/B тестирование: автоматический перебор вариантов с замером конверсии.
Общее правило, если вы можете превратить лучше/хуже в число, то этот паттерн для вас.

Вывод.
Бесконечный цикл (из прошлого поста) хорош, когда задача понятна и нужно добить ее до конца. Журнал экспериментов используется, когда нужно искать лучшее решение в пространстве возможностей. Первый вариант для инженера, второй - для исследователя. А в сочетании для того, кто хочет, чтобы ИИ работал вместо него, пока он спит.

Ссылки для тех, кто хочет попробовать:
- Паттерн с дневником экспериментов: t.iss.one/llm_under_hood/727
- Проект Карпатого: github.com/karpathy/autoresearch
- Обобщённая версия для любых метрик: gist.github.com/adhishthite/16d8fd9076e85c033b75e187e8a6b94e
- Рекомендации от создателей Claude по длинным автономным сессиям: anthropic.com/engineering/effective-harnesses-for-long-running-agents
- Коллективные исследования агентов: arxiv.org/abs/2503.18102