Один агент, который умеет всё, не умеет ничего

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

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

Больше делает хуже, и вот доказательство

У языковой модели фиксированный бюджет внимания. Всё, что ты кладёшь в окно контекста — каждое описание инструмента, каждая инструкция, каждый найденный документ — соперничает за один и тот же бюджет. С какого-то момента добавление информации не даёт модели больше материала; оно разбавляет то, что уже было.

Исследования об этом говорят прямо. Длинноконтекстные модели страдают от хорошо задокументированного эффекта «потерян в середине»: инструкции, зарытые в середину длинного промпта, исполняются хуже тех же инструкций в коротком. Один анализ нашёл падение точности с 92% до 63% чисто от перегруза контекстом — та же модель, та же задача, просто слишком много в окне. Инструменты ведут себя так же: навали двадцать на одного агента — и он начинает звать не тот в половине случаев, забывать инструкцию из начала контекста к тому моменту, как зашёл вглубь задачи, и превращать один плохой вызов в каскад из трёх новых.

Это паттерн god-агента (агент-бог), и у него есть подпись: он ослепляет в демо и рассыпается в проде. В демо ты прогоняешь один отрепетированный путь. В проде длинные, ветвящиеся, настоящие сценарии каждый раз бьются о стену разбавления.

Починке сорок лет

Лекарство — не хитрый промпт и не модель побольше. Это принцип единственной ответственности (Single Responsibility), то же правило, что мы уже применяем к функциям и классам: один агент, одна задача. Дай каждому агенту единственную, чётко определённую ответственность, те три-четыре инструмента, которые этой задаче реально нужны, и только относящийся к ней контекст. Теперь ничто не соперничает за бюджет внимания, потому что в окне нет ничего лишнего. Каждый агент великолепен в своём одном деле именно потому, что не пытается быть хорош в девяти других.

Числа движутся в эту сторону резко. Оценка Chroma нашла большой разрыв в точности между сфокусированным промптом на ~300 токенов и раздутым на ~113K; дженерик-агенты, растянутые на всё, измеренно срабатывают лишь примерно в 58% случаев, падая дальше по мере того, как задача расползается. Сузь зону — и та же модель под капотом становится драматически надёжнее, потому что ты перестал заставлять её выбирать.

Этот урок мы уже выучили — для кода

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

Так что ход — тот, что мы уже знаем. Декомпозиция — не новая «агентная техника». Это тот же инстинкт, что породил единственную ответственность, малые единицы и чистые границы, применённый к новому виду компонента. Причина, по которой это работает, конкретна, а не эстетична: у сфокусированного агента неразбавленный контекст, поэтому он держится задачи — так же, как сфокусированную функцию реально можно прочесть.

И побочные эффекты — ровно те, что нужны. Агент-на-одну-задачу тестируем — ты можешь написать eval на «делает ли он своё одно дело», чего попросту нельзя сделать для агента-на-всё с двадцатью инструментами. Он дешевле, потому что узкая, чётко определённая работа часто прекрасно идёт на модели поменьше. И он отлаживаем, потому что когда что-то ломается, ты знаешь, какой агент владел этой ответственностью.

Честный подвох

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

Но заметь, какой обмен ты совершил. Ты поменял «мой агент забыл инструкции и вызвал не тот инструмент» — сбой внутри чёрного ящика, который ты не можешь починить — на «мне нужно координировать компоненты» — обычную инженерную задачу с обычными инженерными ответами. Одно из этого решаемо. Другое — это просто god-агент, которому становится хуже по мере того, как ты добавляешь ещё.

Желание заставить одного агента делать всё — это желание пропустить декомпозицию, и оно проваливается у агентов по той же причине, по которой всегда проваливалось у кода. Сделай каждого агента достаточно маленьким, чтобы он был великолепен. Одно дело, сделанное хорошо, бьёт десять дел, сделанных на 58%.