Глава 19. Субагент: когда помогает, когда мешает

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

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

Зачем вообще делегировать Настоящих причин две, и обе про контекст.

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

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

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

ГЛАВНОЕ ПРО ДЕЛЕГИРОВАНИЕ Делегирование это решение по дизайну исполнения, а не способ сэкономить контекст. Формулировка кажется придиркой, но она меняет подход. Делегируешь ради экономии, значит не считаешь издержки координации. А они есть всегда: передача задачи, потеря контекста, сборка результатов, разбор противоречий между ответами.

Что теряется при передаче Главная скрытая цена. Субагент получает не всё, что знает родитель, а только то, что родитель решил передать. И решает это родитель хуёво.

Типичные потери:

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

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

Оговорки в задании. Ты сказал пять уточнений, родитель передал одно.

Субагент: когда помогает, когда мешает

ЧТО ПРОИСХОДИТ С ЗАДАЧЕЙ ПРИ ДЕЛЕГИРОВАНИИ

Формулировка для Задача у тебя Понимание родителя Понимание субагента субагента

все нюансы часть нюансов часть от части результат

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

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

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

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

ОТДАВАТЬ ЛИ РАБОТУ СУБАГЕНТУ

Задача, которую хочется делегировать

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

контекст остаётся чистым результаты не сойдутся

Правило для роя Формулировка, закрывающая большинство вопросов: не делегируй агентам принятие решений. Говори им копай и возвращайся, решать будем вместе.

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

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

Субагент: когда помогает, когда мешает

Взрыв субагентов Инцидент, который стоит знать до того, как он случится у тебя.

Человек открыл свежий разговор в своём репозитории и задал безобидный вопрос: что это за проект и какие дальнейшие шаги. На максимальном уровне усилий.

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

Ещё через две минуты их было бы под три сотни.

ЗАЩИТА ОТ ВЗРЫВА 1. Проверь ограничение глубины экспериментом, а не чтением конфигурации. Оно может не работать. 2. Ограничь число одновременных субагентов явным числом. 3. Проверь, наследуется ли уровень усилий. Обычно да, и это дорого. 4. Заведи потолок расхода на одну задачу и остановку при его достижении. 5. Первый запуск делегирования проводи на дешёвой модели.

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

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

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

ЧТО ВЫБРАТЬ За одноразовых. Меньше сущностей, меньше состояния, проще отладка. Каждый запуск воспроизводим. За роли. Инструкция пишется один раз и переиспользуется. На повторяющемся процессе экономит заметно. Побочный эффект ролей, о котором предупреждают. Роли начинают жить своей жизнью: обрастают правилами, грызутся между собой и требуют отдельного сопровождения. Через полгода это отдельная система, которую надо тащить.

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

Субагент: когда помогает, когда мешает

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

Что запомнить Делегируй ради изоляции контекста и настоящей параллельности, а не ради экономии.

Считай издержки координации явно. Они есть всегда.

Тесно связанные решения оставляй у одного ответственного.

Правило для роя: копай и возвращайся, решать будем вместе.

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

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

← Поиск по коду и по документам · оглавление · Многоагентность и рои →

Спросить книгу может любой, кто вошёл в Neuraldeep Hub: агент ищет ответ по тексту и приводит цитату со ссылкой на главу.