Orchestrator-worker и контекст

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

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

Orchestrator-worker решает это разделением памяти. Оркестратор держит только тонкий долгий слой: кто пользователь, о чём договорились, какая цель. Воркеры получают чистое изолированное окно под одну подзадачу и возвращают не сырую выдачу, а сжатый отчёт. Шум остаётся внутри воркера.

Плюсы: контекст оркестратора живёт долго и остаётся читаемым, воркеры взаимозаменяемы за счёт фиксированной структуры отчёта, оркестратор можно держать на сильной модели, а воркеров – на дешёвой.

Честно: токенов уходит кратно больше (пук), оркестратор становится единой точкой отказа, а нечёткий план-файл = воркер уверенно делает не то. Так что схема не «лучше», а уместна там, где подзадачи реально независимы.
Разбираем сейчас, что должно жить в долгой памяти, а что выбрасывать после отчёта. Протестируем – расскажу, что выжило.

Encyclopedia of Agentic Coding Patterns