От дирижера к оркестратору.
Есть полезное разграничение двух режимов работы с ИИ:
Дирижер. Вы работаете с одним агентом в режиме диалога. Написал промпт, получил ответ, поправил, следующий промпт. Синхронно, внимательно, по одной задаче за раз.
Оркестратор. Вы формулируете задачу верхнего уровня и отходите в сторону. Система сама раскладывает на подзадачи, запускает агентов, мониторит прогресс. Вы возвращаетесь к готовым результатам: веткам с кодом, запросам на слияние, отчетам.
Большинство из нас пока в режиме дирижера. Но инструменты для оркестрации уже есть и работают.
На задачах по программированию такой подход дал прирост от 58% до 149% по сравнению с фиксированными архитектурами.
Иерархия с тремя специалистами. Верхний агент-планировщик раздает задачи трем подчиненным: один ищет информацию в интернете, другой взаимодействует с веб-страницами, третий анализирует данные в разных форматах. Каждый работает через стандартный интерфейс, планировщику не нужно знать, как именно устроен каждый подчиненный. Результат: 92% точности на простых задачах, 84% на средних.

Когда это не нужно.
Оркестрация добавляет сложность. Она оправдана, когда задач много, и они независимы (могут делаться параллельно), есть четкие критерии успеха для каждой подзадачи (тесты, метрики). Человек готов ревьюить результаты, а не процесс.
Если задача одна и непростая, один хороший агент в цикле справится лучше, чем десять плохо скоординированных.
Итого по серии:
Бесконечный цикл для задач сделай и добей (инженерные)
Журнал экспериментов для задач найди лучшее решение (исследовательские)
Оркестратор для задач сделай много всего сразу (масштабирование)
Три паттерна, можно комбинировать: оркестратор раздаёт задачи, каждый агент работает в цикле с журналом экспериментов.

Ссылки для тех, кто хочет разобраться:
- Оркестратор для параллельных агентов: github.com/ComposioHQ/agent-orchestrator
- Обучаемый «кукловод»: arxiv.org/abs/2505.19591
- Самоконструирующаяся система: arxiv.org/abs/2505.14996
- Иерархический фреймворк: arxiv.org/abs/2506.12508
- От дирижёра к оркестратору (Addy Osmani): addyosmani.com/blog/future-agentic-coding
- Обзор исследовательских агентов: arxiv.org/abs/2508.12752

Мы разобрали три паттерна: бесконечный цикл, журнал экспериментов и оркестратор. Но у всех трех есть общая ахиллесова пята - память.
Каждый раз, когда вы начинаете новую сессию с ИИ-агентом, он просыпается с чистого листа. Не помнит, что делал вчера. Не помнит, какие подходы не сработали. Не помнит ваших предпочтений.
Бесконечный цикл обходит это через файлы и историю изменений. Журнал экспериментов через таблицу результатов. Но все это костыли. Настоящая проблема глубже.

Почему контекстное окно это не память.
Контекстное окно - это то, что модель "видит" прямо сейчас. Промпт, последние сообщения, ход рассуждений. Это как рабочий стол: на нем лежит то, с чем вы работаете прямо сейчас. Но рабочий стол, это не шкаф с архивами.

Три проблемы:
Ограничен. Даже у самых продвинутых моделей окно конечно, длинные проекты не влезают.
Эфемерен. Закрыли сессию все исчезло.
Не умеет выбирать. Модель видит все в окне одинаково. Не может вытащить нужное из прошлого, только из того, что перед глазами.
Свежие исследования (март 2026) подтвердили контринтуитивный факт: длинный контекст - это не память. Модели, которые отлично справляются с извлечением фактов из длинного текста, падают до 40–60% точности, когда нужно принять решение на основе прошлого опыта.

Четыре вида памяти.
Ученые классифицировали память ИИ-агентов по аналогии с человеческой:
Рабочая, то, что в голове прямо сейчас. Контекстное окно, быстро, точно, но мало.
Эпизодическая, конкретные воспоминания: вчера в 15:00 я попробовал увеличить скорость обучения, и метрика упала. Журнал экспериментов из прошлого поста про нее.
Семантическая, абстрактные знания, извлеченные из опыта: увеличение скорости обучения выше 0.01 обычно ухудшает результат для этой архитектуры. Не конкретное воспоминание, а правило.
Процедурная, навыки: как развернуть сервис в продакшн, как мигрировать базу данных. Не факты и не события, а готовые рецепты.

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

Как это работает на практике.
Заметки по методу Цеттелькастен.
Один из самых интересных подходов - система памяти, вдохновленная методом ведения заметок немецкого социолога Никласа Лумана. Каждое воспоминание не просто строчка в логе, а структурированная карточка: содержание, ключевые слова, категории, развернутое описание контекста, и, главное, ссылки на связанные воспоминания.
Когда появляется новое воспоминание, система не просто кладет его в стопку. Она анализирует все старые карточки, находит связанные и перелинковывает. Более того, новая карточка может обновить описание старых, если появилось новое понимание.
Результат: сеть знаний, которая растет и уточняет сама себя. На вопросах, связанных со временем, эта система точнее ближайшего конкурента в 1.8 раза, а токенов тратит в 6.7 раз меньше.

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

Библиотека навыков.
Самый необычный вид - процедурная память. Агент, играющий в Minecraft, не запоминает факты. Он запоминает навыки: готовые программы, решающие конкретные задачи. Как добыть алмаз, как построить печь, как переплыть озеро.
Каждый новый навык проверяется перед сохранением (работает ли он?), а сложные задачи решаются комбинацией ранее освоенных навыков. Результат: агент осваивает дерево технологий в 15 раз быстрее, чем без библиотеки навыков.
Прямой аналог в программировании: агент, который сохраняет проверенные утилиты и переиспользует их в новых проектах.

Что это значит для наших паттернов?
Вот как три паттерна из предыдущих постов используют память:
Паттерн Что запоминает Тип памяти
Бесконечный цикл Прогресс, чеклист задач Эпизодическая + Семантическая
Журнал экспериментов Все попытки (успехи + провалы) Эпизодическая
Оркестратор Результаты сессий, ретроспективы Эпизодическая -> Семантическая

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

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

Пять правил хорошей памяти для агента.
Вести полный журнал (эпизодическая память), записывать ВСЕ попытки, включая неудачные.
Регулярно извлекать правила (консолидация), каждые N итераций спрашивать: какие принципы я могу вывести из своего опыта?
Сохранять проверенные рецепты (процедурная память), работающие решения оформлять как переиспользуемые шаблоны.
Забывать устаревшее, без очистки агент начнет вытаскивать противоречивую информацию.
Логировать операции с памятью, иерархическая память создает тихие отказы: агент дает плохой ответ, но не сигналит об ошибке.

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

Четвертый элемент. Без него первые три одноразовые, с ним накапливающие знания.

Ссылки для тех, кто хочет копнуть глубже:
- Обзор памяти агентов (март 2026): arxiv.org/abs/2603.07670
- Заметки по Цеттелькастен для ИИ: arxiv.org/abs/2502.12110
- Память как продукт (Mem0): arxiv.org/abs/2504.19413
- Библиотека навыков (Voyager): arxiv.org/abs/2305.16291
- Список статей по теме: github.com/Shichun-Liu/Agent-Memory-Paper-List

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

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

Проблема не в агенте. Проблема в задании.

---

Почему это важно именно сейчас.

Анализ 2500+ файлов с инструкциями для агентов на крупнейшем хостинге кода показал: большинство провалов из-за расплывчатости, а не из-за технических ограничений. Агенты игнорируют файлы длиннее ~150 строк. Каждый раздел должен быть короче 50 строк. Общие пожелания, вроде мы ценим чистый код, не вызывают никакого измеримого изменения в поведении.

Хорошая новость: написать эффективное задание - навык, который можно освоить. И он переносится между любыми инструментами.

Шесть обязательных блоков.

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

1. Команды.

Не описания, а ровно то, что нужно запустить в терминале.

Плохо: Убедись, что все зависимости установлены и тесты проходят

Хорошо: `pip install -r requirements.txt && pytest -v --tb=short`

Команды однозначны, агент точно знает, что запустить, с какими параметрами, и как проверить успех по коду выхода.

2. Определение готово.

Самый важный блок. Без него агент объявит задачу выполненной, когда ему вздумается.

Плохо: Когда все работает

Хорошо:
- Все тесты проходят (`pytest` возвращает 0)
- Проверка типов без ошибок (`mypy .` возвращает 0)
- Форматирование в порядке (`ruff check .` возвращает 0)
- Сообщение коммита в формате: `feat: краткое описание`

Каждое условие проверяемое. Не мнение, а факт.

3. Структура проекта.

Агент должен знать, куда класть файлы.

`src/` - код приложения, `tests/` - тесты, `migrations/` - миграции БД

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

4. Стиль кода.

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

5. Границы - что НЕЛЬЗЯ.

Три уровня:

Делай всегда - безопасные действия без вопросов. Запускай тесты перед каждым коммитом.

Спроси перед тем как серьезные изменения. Не меняй схему базы данных без подтверждения.

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

Самый частый полезный запрет из анализа тысяч проектов: никогда не коммить секреты.

6. Правило эскалации.

Что делать, когда агент застрял.

Если тесты не проходят после 3 попыток, то остановись и опиши проблему.

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

Три главные ошибки.

Ошибка 1: Расплывчатость.

Построй что-нибудь интересное, и у агента нет ни одной опоры. Нет цели, нет границ, нет критериев.

Решение: конкретный стек (Python 3.12, FastAPI, PostgreSQL 16, SQLAlchemy 2.0), конкретная задача (добавь эндпоинт для пагинированного списка заказов), конкретный результат (тесты проходят, документация обновлена).

Ошибка 2: Перегрузка.

50 страниц документации в одном контексте и агент теряется. Исследования подтверждают: производительность падает, когда агенту нужно удовлетворить слишком много требований одновременно.

Решение: разбивайте на модули. Отдельный файл для бэкенда, отдельный для фронтенда. Суммаризируйте каждый раздел до 1–2 ключевых пунктов. Детали по запросу.

Ошибка 3: Пропуск планирования.

Опытные разработчики планируют перед тем, как кодить, и это самое важное изменение, которое можно внести в работу с агентом.

Решение: сначала попросите агента составить план. В режиме только чтение, пусть изучит код, задаст вопросы, предложит подход. Только после утверждения плана переходите к исполнению.
Задание как рецепт, не как пожелание.

Хорошая аналогия: задание для агента - это рецепт, а не просьба приготовь что-нибудь вкусное.

В рецепте есть:
- Список ингредиентов (стек, зависимости)
- Порядок действий (план)
- Время и температура (критерии готовности)
- Что должно получиться (ожидаемый результат)
- Чего избегать (не пересолить = не сломать существующее)

Без рецепта каждый раз сюрприз. С рецептом - предсказуемый результат.

Развитие заданий через ошибки.

Не пытайтесь написать идеальное задание с первого раза. Лучшая стратегия:
1. Начните с минимума, команды + определение готово + границы.
2. Запустите агента.
3. Посмотрите, где он свернул не туда.
4. Добавьте правило, которое предотвратит эту ошибку.
5. Повторите.

Каждое новое правило - реакция на реальную проблему, а не попытка предусмотреть все заранее. Задание растет вместе с опытом.
Помните пост про память? Файл с инструкциями - это семантическая память проекта. Он накапливает знания о том, что работает, и передает их каждой новой сессии.

Формат имеет значение.

Несколько технических деталей:
- Используйте разметку, заголовки, списки, блоки кода. Структурированный текст модели разбирают лучше, чем сплошную прозу.
- Держите файл коротким, до 150 строк. Длиннее, и агент начинает игнорировать куски.
- Храните в системе контроля версий, задание эволюционирует, как и код. История изменений покажет, почему каждое правило появилось.
- Формат зависит от инструмента, то, что идеально работает с одной моделью, может потребовать правок для другой. Экспериментируйте.

---

Итого по серии:

Бесконечный цикл -> сделай и добей
Журнал экспериментов -> найди лучшее
Оркестратор -> сделай много сразу
Память -> помни и учись
Задание -> скажи точно, что нужно

Пятый элемент. Без него остальные четыре работают вслепую. С ним каждый цикл, каждый эксперимент, каждый агент в оркестраторе знает, что от него требуется.

---

Ссылки для тех, кто хочет попробовать:
- Как писать задания (Addy Osmani): addyosmani.com/blog/good-spec
- Какие паттерны реально работают (анализ 2500+ файлов): blakecrosley.com/blog/agents-md-patterns
- Практики от создателей Cursor: cursor.com/blog/agent-best-practices
- 10 вещей про задания для агентов: tessl.io/blog/spec-driven-development-10-things-you-need-to-know-about-specs
- Разработка через задания (ThoughtWorks): thoughtworks.com/en-us/insights/blog/agile-engineering-practices/spec-driven-development-unpacking-2025-new-engineering-practices

Теория - это хорошо, но как же это будет на практике? Хороший вопрос требует такого же ответа. Начал проект с реализацией памяти для самых распространенных продуктов - claude code/codex/opencode. Все как описывал, у субагента есть три типа памяти: эпизодическая (что было), семантическая (какие правила извлечены) и процедурная (проверенные рецепты).
Проект выложил в опенсорс - https://github.com/snow-ghost/mem
Принимаются пожелания, замечания, вопросы и запросы )

Развлекался сегодня с аналогом проекта Karpathy autoresearch, адаптировал его на язык go и не использую gpu (та что есть в домашней системе слишком неподходящая - rx590). Вместо этого используется codex/cc. Попробовал автоисследование одним агентом. Что могу сказать, когда есть заранее заданное множество для проверок, например, оптимизация под конкретное железо, то использование такого способа вполне оправданно. По сути это стенд + протокол для агентного цикла, где агент правит код. В репу еще не пушил, посмотрю, нужно ли это делать, а вот рисерч тим (дрим тим) после реализации выложу на гитхабе.

Выложил вчерашнее на гх - https://github.com/snow-ghost/autoresearch
сразу скажу, что очень удобно, когда есть инструменты, которые многое делают за тебя. Попробовал поисследовать пример, полет нормальный, продолжаю работать над рисерч тим

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

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

и на сегодняшний вечер дашборд рисерч тимы выглядит примерно так

Последние 2-3 дня занимался составлением кода для агента в PAC1-DEV Рината Абдуллина (https://t.iss.one/llm_under_hood/779) Первоначальная версия на опенсорсных моделях решала от 15 до 19 задач из 22, модели использовал qwen3-30b-a3b, qwen3-next-80b-a3b, qwen3-4b и gpt-oss-20b (спасибо Паше!), qwen3.5-35b-a3b и gpt-oss-120b (спасибо Валере!). Сегодня переделал немного архитектуру агента и на qwen3-next80b смог достичь 100% успеха - 22/22, осталось на других моделях протестировать и поправить промпты, чтобы не было моделезависимого решения. Также занимаюсь подготовкой к внутреннему митапу AI для разработчиков, буду выступать там с темой небольших llm, готовлю презентацию.

Черновик презентации сделал, как и доклад с заметками. Занимался дальше адаптацией агента для новых задач. Смог на двух моделях qwen3-next-80b-a3b и qwen3.5-35b-a3b сделать выполнение 30 из 30 задач. Возможно получившийся вариант выложу на гитхабе после окончания активной фазы контеста. Хочу заметить, что выбранные модели как раз из тех, что могут выполняться на gpu 8Гб (активных 3 млрд. параметров, при fp8 - это 3ГБ памяти, на q4 - 1,5 Гб. И часть памяти можно использовать под MoE (эти модели как раз такого класса) и контекст.

Взялся поисследовать небольшую модель на 350 млн. параметров, она не поддерживает so, но вместо этого есть возможность использовать GBNF грамматику - это специальная форма Бэкуса-Наура. Мне она известна еще со времен учебы, когда изучал теорию языков программирования. Любой ЯП можно описать в этой форме.
Пример такой грамматики:

grammar_string = r"""
root ::= "{" pair ("," pair)* "}"
pair ::= string ":" list
list ::= "[" value ("," value)* "]"
value ::= string | number
string ::= "\"" [a-zA-Z0-9_]+ "\""
number ::= [0-9]+
"""

кроме этого модель также поддерживает и tool calls, а это значит, что она отличный кандидат для написания небольших агентов (такое количество параметров дает возможность запускать на cpu и на vps/vds без доступа к gpu на вполне приемлемой скорости)
не дорабатывал (и не проверял) еще на всех 40 задачах в PAC1-DEV, но 31 из 31 решала успешно с агентской обвязкой по моему алгоритму. Обязательно попробую позапускать эту модель на агентских бенчмарках, расскажу в следующий раз об этом

Выложил сегодня правки по агенту для PAC1-dev на моделях LFM2.5-350M и LFM2.5-1.2B-Instruct набирают 40 из 40 задач. С кодом можно ознакомиться тут - https://github.com/snow-ghost/sample-agent

Часть задач покрыты эвристикой и не требуют использования LLM для их решения, впрочем, в коде можно все посмотреть

сегодня с первой попытки на 3-х новых задачах вышел в топ-1, продолжаю заниматься доработками агента, на данный момент уже 352 тестовых сценария для проверки работы связки агента + ллм. На локальных моделях типа 350M/1.2B также выполняются все задачи успешно. Не знаю, что будет на соревновании в субботу, но готовлюсь встретить, текущий код обновил в репе, мне нежалко ) также продолжаю работать над mcp сервером для памяти, нашел бенчмарк в сети LongMemEval, пока 47.8% буду продолжать его вечерами дорабатывать, идей по улучшению хватает.

Сегодня еще довел данное решение до более стабильного, на тестах вместо 16 уже 22 вызова llm (такое малое количество вызовов говорит лишь о том, что выполняемые сначала проверки на безопасность отсеивают задачи до вызова, но если задача не будет поддаваться эвристике, то дойдет до этапа вызова llm и не одного, если потребуется, и решение будет уже с ее помощью)
Кроме этого начал реализацию новой версии агента с помощью роевого интеллекта. Завтра буду подбивать итоги на чем именно остановиться и какой из вариантов стоит использовать уже на реальном прод прогоне. Самое успешное решение (даже если это будет не текущий вариант), выложу на гх в субботу.

Поисследовал в разных llm + в своих рисерч тимах проблематику написания персонального агента (для участия в PAC1) в итоге сформировался неплохой вариант комбо из MRKL-роутера, ReAct, Plan-and-Solve и RAG. Роутер маршрутизирует запросы к подмодулям - RAG/файловая навигация/планировщик/валидатор. И наворот в виде роевого ансамбля - судьи-классификаторы на этапе самоулучшения, когда малая LLM читает отчет анализатора и решает - это инъекция и нарушение политики или цикл вызова тулов и дегенерация или протокольная ошибка, что позволяет отбрасывать кандидатов, второй вариант - роевое оценивание, когда не один судья, а набор 5-9 дешевых судей с разными инструкциями (строгий безопасник, минимизатор вызовов инструментов, планировщик-критик и т.д.), далее голосование или агрегация. Тема интересная и возможно с ней что-то можно было бы сделать, но это если успею за завтра провести обучение и успею с ним до начала соревнования. Ну а если не успею, то попробую другой вариант. Как я уже говорил, на победу не рассчитываю, так как мой выбор в пользу OSS LLM, причем не самой лучшей. Просто поучаствую, чтобы набрать опыта работы с такими агентами. Ну и доступ к бесплатному бенчмарку для обкатки идей и теорий. =)

И да, мем агент все улучшается и проверяется на бенчмарках

с мем-агентом сегодня вышло уже так, в клодкоде разочарование, составил план через speckit, анализировал, создавал таски, имплементация была разбита на 5 фаз, по 20+ задач в каждой фазе, в итоге собрал решение сегодня утром, натравил его на pac1-dev - 0, пытался запускать через клодкод эволюцию решения, молотил несколько часов, ввел меня в заблуждение, что все сломалось у провайдера моделей, по-прежнему 0. Ну и с той версией, что выкладывал на гитхаб на qwen3-next-80b-a3b от 21 до 30 на pac1-prod. Больше доверять кодовому агенту проектировать не буду. Потратил совсем немного времени, по сути только промптил несколько десятков раз, но на этом все. Сам же умею нормально все проектировать, а тут понадеялся на бездушную программу. Даже в такой мелочи не стоит перекладывать решение. А я запросил исследование от llm, потом эту же llm попросил спроектировать и реализовать и получилось то, что получилось. Спасибо Ринату за возможность погонять бенчмарк, придумаю в следующий раз нормальный вариант )