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

Проблема.
Один агент работает линейно: взял задачу, сделал, перешел к следующей. Десять задач и десять последовательных циклов. Медленно.
Хочется запустить десять агентов параллельно. Но тут начинается хаос: двое правят один и тот же файл, третий ломает тесты, четвертый не знает, что пятый уже решил ту же проблему.
Нужен кто-то, кто раздаёт задачи, следит за прогрессом и разруливает конфликты.

Оркестратор.
Если совсем просто, это ещё один ИИ-агент, но он не пишет код сам. Вместо этого он:
Читает список задач из трекера, из списка проблем, из технического задания.
Разбивает большую задачу на маленькие так, чтобы каждую можно было делать независимо
Запускает отдельного агента на каждую подзадачу, каждый в своей изолированной копии кода
Следит за результатами, тесты прошли? сборка не сломалась? ревью получено?
Реагирует на проблемы, если тесты упали, подсовывает агенту логи ошибки и говорит почини
Метафора: дирижер оркестра. Сам не играет ни на одном инструменте, но знает, кто что должен играть и когда.

Как это выглядит на практике.
Один из таких инструментов открытый проект от Composio. Вот что он умеет:
1. Изоляция. Каждый агент получает собственную копию кода (рабочее дерево). Они физически не могут наступить друг другу на пятки, каждый работает в своей ветке.
2. Автоматические реакции. Настраивается через простые правила: Тесты упали, то запусти агента с логами ошибки. Пришёл комментарий к ревью, то перенаправь нужному агенту. Агент закончил, то создай запрос на слияние.
3. Наблюдение. Панель управления показывает все сессии: кто работает, у кого проблемы, кто ждет ревью.
Результат за 8 дней: 40 тысяч строк кода, 3300 тестов, 17 модулей. До 30 агентов одновременно. 41 падение тестов исправлено автоматически. Человек занимался только архитектурными решениями и финальным ревью.

А что говорит наука.
Ученые тоже думают над этим, но подходят с другой стороны, как обучить оркестратора, а не просто запрограммировать правила.
Обучаемый кукловод. Центральный агент-кукловод выбирает на каждом шаге, какой из подчиненных агентов должен думать дальше. Обучается через подкрепление: получает награду за правильные ответы и штраф за лишние вычисления. Результат: со временем оркестратор не только улучшает качество, но и снижает расход ресурсов. Это нетипично, обычно качество и стоимость растут вместе.
Интересное наблюдение: по мере обучения между агентами спонтанно возникают циклы взаимной проверки. Агент А проверяет работу агента Б, а тот работу агента А. Никто их этому не учил, это появилось само.
Самоконструирующаяся система. Ещё один подход: мета-агент для каждой новой задачи с нуля собирает оптимальную команду. Анализирует задачу, решает, сколько агентов нужно, какие роли им дать, как организовать взаимодействие, потом наблюдает за выполнением и перестраивает команду, если что-то идет не так.

От дирижера к оркестратору.
Есть полезное разграничение двух режимов работы с ИИ:
Дирижер. Вы работаете с одним агентом в режиме диалога. Написал промпт, получил ответ, поправил, следующий промпт. Синхронно, внимательно, по одной задаче за раз.
Оркестратор. Вы формулируете задачу верхнего уровня и отходите в сторону. Система сама раскладывает на подзадачи, запускает агентов, мониторит прогресс. Вы возвращаетесь к готовым результатам: веткам с кодом, запросам на слияние, отчетам.
Большинство из нас пока в режиме дирижера. Но инструменты для оркестрации уже есть и работают.
На задачах по программированию такой подход дал прирост от 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, готовлю презентацию.