# Один агент, который умеет всё, не умеет ничего Когда агент недостаточно хорош, инстинкт — дать ему больше: ещё инструмент, ещё инструкции, ещё контекста. От этого он становится хуже, и это измерено, а не дело вкуса. Починка — старейшее правило инженерии: Single Responsibility. Один агент, одна задача, пара инструментов, короткий контекст. God-агент — это десятитысячестрочная функция в плаще, и проваливается он по той же причине. - **Author:** Фёдор Чищин - **Published:** 2026-06-03 - **Tags:** agents, architecture, methodology - **Source:** https://fedorthinks.com/ru/blog/one-agent-that-does-everything --- Твой агент не дотягивает, и ты делаешь очевидное: даёшь ему больше. Ещё инструмент для того, что он не смог. Ещё пару строк в промпт под случай, в котором он ошибся. Ещё контекста, чтобы у него было всё, что может понадобиться. Каждое добавление разумно. Каждое делает агента чуть хуже. Это контринтуитивный результат, в который я не сразу поверил, и это не дело вкуса — это измерено. Путь к способному агенту идёт в обратную инстинкту сторону: не больше, а меньше. ## Больше делает хуже, и вот доказательство У языковой модели фиксированный бюджет внимания. Всё, что ты кладёшь в окно контекста — каждое описание инструмента, каждая инструкция, каждый найденный документ — соперничает за один и тот же бюджет. С какого-то момента добавление информации не даёт модели больше материала; оно разбавляет то, что уже было. Исследования об этом говорят прямо. Длинноконтекстные модели страдают от хорошо задокументированного эффекта [**«потерян в середине»**](https://medium.com/@999daza/why-your-ai-agents-fail-the-context-overload-problem-and-the-slice-framework-that-fixes-it-873653ce0db6): инструкции, зарытые в середину длинного промпта, исполняются хуже тех же инструкций в коротком. Один анализ нашёл падение точности [с **92% до 63%** чисто от перегруза контекстом](https://medium.com/@999daza/why-your-ai-agents-fail-the-context-overload-problem-and-the-slice-framework-that-fixes-it-873653ce0db6) — та же модель, та же задача, просто слишком много в окне. Инструменты ведут себя так же: навали двадцать на одного агента — и он начинает [звать не тот в половине случаев](https://dev.to/nebulagg/the-god-agent-mistake-why-one-mega-agent-always-fails-in-production-1fk1), забывать инструкцию из начала контекста к тому моменту, как зашёл вглубь задачи, и превращать один плохой вызов в каскад из трёх новых. Это паттерн **god-агента** (агент-бог), и у него есть подпись: он ослепляет в демо и рассыпается в проде. В демо ты прогоняешь один отрепетированный путь. В проде длинные, ветвящиеся, настоящие сценарии каждый раз бьются о стену разбавления. ## Починке сорок лет Лекарство — не хитрый промпт и не модель побольше. Это [**принцип единственной ответственности** (Single Responsibility)](https://www.alation.com/blog/general-vs-specialized-enterprise-ai-agents/), то же правило, что мы уже применяем к функциям и классам: **один агент, одна задача.** Дай каждому агенту единственную, чётко определённую ответственность, те три-четыре инструмента, которые этой задаче реально нужны, и только относящийся к ней контекст. Теперь ничто не соперничает за бюджет внимания, потому что в окне нет ничего лишнего. Каждый агент великолепен в своём одном деле именно потому, что не пытается быть хорош в девяти других. Числа движутся в эту сторону резко. Оценка Chroma нашла большой разрыв в точности между [сфокусированным промптом на ~300 токенов и раздутым на ~113K](https://medium.com/@stawils/more-agents-more-tools-worse-results-the-2026-evidence-for-radical-simplification-7bad6c1858a5); дженерик-агенты, растянутые на всё, измеренно срабатывают лишь примерно в 58% случаев, падая дальше по мере того, как задача расползается. Сузь зону — и та же модель под капотом становится драматически надёжнее, потому что ты перестал заставлять её выбирать. ## Этот урок мы уже выучили — для кода Вот часть, от которой каждый инженер должен кивнуть. Мы не пишем одну десятитысячестрочную функцию с двумя сотнями ветвлений и не зовём её мощной — мы зовём её неподдерживаемой и разбиваем на маленькие функции, каждая из которых делает одно. Мы не строим один класс, который делает всё; мы декомпозируем. God-агент — это ровно тот антипаттерн в плаще: один компонент, которого просят держать сразу все заботы, проваливающийся по той же причине, что и гигантская функция: слишком много в одном месте, нет разделения, каждая часть мешает каждой другой. Так что ход — тот, что мы уже знаем. Декомпозиция — не новая «агентная техника». Это тот же инстинкт, что породил [единственную ответственность, малые единицы и чистые границы](/blog/cheap-code-is-expensive), применённый к новому виду компонента. Причина, по которой это работает, конкретна, а не эстетична: у сфокусированного агента неразбавленный контекст, поэтому он держится задачи — так же, как сфокусированную функцию реально можно прочесть. И побочные эффекты — ровно те, что нужны. Агент-на-одну-задачу тестируем — ты можешь написать [eval](/blog/evals-or-it-didnt-ship) на «делает ли он своё одно дело», чего попросту нельзя сделать для агента-на-всё с двадцатью инструментами. Он дешевле, потому что узкая, чётко определённая работа часто [прекрасно идёт на модели поменьше](/blog/cheap-model-most-of-the-work). И он отлаживаем, потому что когда что-то ломается, ты знаешь, какой агент владел этой ответственностью. ## Честный подвох Разбив одного агента на десять, ты не заставляешь проблему исчезнуть — ты меняешь её на другую. Теперь у тебя десять сфокусированных агентов, которых надо координировать: что-то должно маршрутизировать работу, передавать результаты между ними и решать, что когда запускается. Этот слой координации — оркестрация — настоящая инженерия, и это тема для отдельного поста. Но заметь, какой обмен ты совершил. Ты поменял _«мой агент забыл инструкции и вызвал не тот инструмент»_ — сбой внутри чёрного ящика, который ты не можешь починить — на _«мне нужно координировать компоненты»_ — обычную инженерную задачу с обычными инженерными ответами. Одно из этого решаемо. Другое — это просто god-агент, которому становится хуже по мере того, как ты добавляешь ещё. Желание заставить одного агента делать всё — это желание пропустить декомпозицию, и оно проваливается у агентов по той же причине, по которой всегда проваливалось у кода. Сделай каждого агента достаточно маленьким, чтобы он был великолепен. Одно дело, сделанное хорошо, бьёт десять дел, сделанных на 58%.