Один агент, множество специалистов: почему персональный ИИ должен распределять работу, а не выполнять всё сам.
Личный ИИ-ассистент лучше функционирует в роли оркестратора: он направляет задачи к кодирующим агентам, моделям и простым скриптам, предоставляя постепенно увеличивающиеся права.
Источники: I Stopped Trying to Build One AI Agent That Does Everything
Qwen, Nemotron, Gemma, DeepSeek. Локальная обработка данных, AWS Bedrock, Azure. Разные среды выполнения, разный размер, разные цены, разная степень разочарования. Длительные эксперименты с Hermes, Codex, OpenCode, локальными моделями и облачными API обычно начинаются с предположения, что существует едина правильная модель, которую нужно найти. Рано или поздно оказывается, что это неверная проблема. За этим скрывается второе предположение, более интересное: почему личный агент должен делать всё сам?
Мечта о Jarvis
Первая архитектура настолько проста, что это почти стыдно: человек, затем один агент, и всё остальное.
Сообщения для этого агента могут звучать так: проверить проекты, устранить проблему в одном из репозиториев, составить календарь на завтра, доложить о состоянии Linux-сервера, изучить тему и предоставить важные части информации. Агент должен справляться со всем этим.
Звучит замечательно, но именно здесь начинаются проблемы, потому что всё это представляет собой огромную поверхность API.
Для некоторых задач уже существуют лучшие инструменты
Самым ярким примером является программирование. Codex и OpenCode — это не просто окна чата, привязанные к модели; они работают в среде программирования. Они понимают структуру репозиториев, читают и ищут файлы, редактируют несколько файлов одновременно, выполняют команды, анализируют ошибки, запускают тесты, смотрят различия между версиями и вносят коррективы. Это действительно мощные специализированные инструменты.
Теперь предположим, что персональному агенту поручили реализовать новую функцию в проекте. Существуют два возможных подхода.
Подход А. Предоставьте агенту очень мощную модель, доступ к файловой системе и к оболочке. Научите его работе с репозиториями. Разработайте механизмы управления контекстом, обработки различий, выполнения команд, циклов тестирования и восстановления при ошибках. Продолжайте совершенствовать процесс программирования. Поздравляем: агент для программирования создается заново с нуля.
Подход Б. Агент распознаёт задачу по программированию и передаёт её Codex или OpenCode. Это явно более разумно.
Помощнику не обязательно быть лучшим во всём
Это настоящий сдвиг в мышлении. Личному помощнику не нужно быть лучшим программистом, исследователем, инженером DevOps, планировщиком и системой знаний в мире. Ему достаточно знать, кто должен выполнять работу. Это другая ответственность, и, возможно, более важная.
Человеческие организации функционируют по тому же принципу. Генеральный директор не пишет каждую функцию серверной части, не настраивает каждый кластер Kubernetes, не исследует каждый рынок, не создаёт каждую таблицу в электронной таблице, не планирует каждую встречу и не отвечает на каждый запрос поддержки. Их ценность частично заключается в понимании того, что должно быть сделано, кто должен этим заняться и является ли результат приемлемым. Личный оркестратор на основе ИИ можно рассматривать именно в этих терминах. Он не выполняет каждую задачу, но достаточно хорошо понимает намерения, чтобы правильно распределять работу.
Иная форма системы
Замените цепочку «человек — агент — одна огромная модель» на что-то вроде этого:
┌──────────────┐
│ Me │
└──────┬───────┘
│
▼
┌─────────────────┐
│ Google Chat │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Hermes │
│ Orchestrator │
└────────┬────────┘
│
┌─────────────────┼──────────────────┐
│ │ │
▼ ▼ ▼
Coding Agents AI Models Tools
Codex/OpenCode Local / Cloud APIs / Servers
│ │ │
└─────────────────┼──────────────────┘
│
▼
Final Result
Задача агента становится гораздо более понятной. Он понимает человека, осознаёт имеющиеся возможности, выбирает подходящий вариант, предоставляет необходимый контекст, отслеживает результат и докладывает об этом. Вот что действительно делает помощника желанным.
Чат как единый вход
В такой концепции приложение для чата, такое как Google Chat, обретает смысл. Оно не должно показывать скрытую сложность. С точки зрения пользователя существует один диалог. Запрос вроде «Проверьте, произошло ли сегодня что-нибудь важное с проектом X» может побудить агента обратиться к системе задач, посмотреть на GitHub, проверить состояние сервера, прочитать соответствующие материалы, возможно, попросить другую модель что-то проанализировать, а затем подвести итоги. Пользователю не нужно знать ничего из этого или открывать пять приложений. Интерфейс определяет цель, а всё остальное — это реализация.
Кодирование как пример работы модели
Изображение показывает ситуацию, когда человек находится вдали от компьютера. В сообщении по телефону говорится о проблеме в процессе аутентификации проекта X и просится устранить её, если это возможно. В принципе процесс выглядит следующим образом: агент определяет, какой проект имеется в виду, собирает достаточно информации для поиска репозитория, понимает, что код необходимо изменить, и передаёт задачу агенту по программированию. Codex или OpenCode открывает репозиторий, изучает его, редактирует соответствующие файлы, запускает тесты, проверяет изменения и возвращает результат. Оркестратор получает этот результат и сообщает что-то вроде: при проверке токена обновления было использовано неверное условие истечения срока действия, агент по программированию устранил проблему, соответствующие тесты прошли, и вот что было изменено.
Практически не имеет значения, какая модель генерировала токен на каждом этапе. Важно лишь то, что задача была выполнена правильно.
Модели превращаются в инфраструктуру
Когда агент становится элементом слоя оркестрации, вопросы о том, использовать ли Qwen, DeepSeek, локальную модель, Bedrock или Azure, перестают исключать друг друга. Ответ на них может быть простым — да, причем для разных задач требуется разный уровень интеллекта. Небольшая локальная модель обрабатывает простую рутину. Дешевая облачная модель составляет краткие краткости. Более мощная модель для рассуждений принимает сложные решения. Агент для программирования управляет репозиториями. Другой специалист занимается другими задачами. Модели превращаются в инфраструктуру, а инфраструктура должна быть заменяемой.
Избегание зависимости от одного поставщика
Модели меняются с невероятной скоростью. То, что сегодня кажется очевидным выбором, через шесть месяцев может показаться посредственным. Изменяются цены, меняются поставщики, совершенствуются открытые модели, растут окна контекста, улучшается возможность вызова инструментов, появляются новые архитектуры инференса. Если вся личная настройка основана на предположении, что модель X может сделать всё, смена её приводит к проблемам. Лучшим подходом является следующий:
Task
↓
Router
↓
Best available capability
Сегодня последним шагом может быть работа с одним поставщиком услуг, а завтра — с другим, и рабочий процесс не должен этим зависеть.
Роутер может оказаться важнее модели
Много времени тратится на сравнение моделей: у модели А оценка 74, у модели B — 78, у модели C — миллион токенов контекста, у модели D стоимость на 60 процентов ниже. Эта информация полезна. Теперь представьте систему, которая знает, что модель A лучше всего подходит для выполнения определённых задач по кодированию, модель B быстра и дешева для классификации, модель C не нужна, поскольку запрос можно обработать локально, другой запрос вообще не требует использования большой языковой модели, достаточно просто вызова API, один запрос должен направляться непосредственно в Codex, а для другого необходимо сначала задать вопрос пользователю.
Здесь часть «интеллекта» находится в самой системе, которая решает, как им пользоваться, что гораздо интереснее, чем ещё один топ-лист.
Не каждый шаг требует использования большой языковой модели
Агенты делают это слишком простым для запоминания. Когда задаётся вопрос о том, онлайн ли сервер, агенту не нужна модель рассуждений с 200 миллиардами параметров, чтобы понять, существует ли сервер. Он выполняет проверку работоспособности, интерпретирует результат и отвечает. При вопросе о том, сколько свободного места на диске, он выполняет следующее:
df -h
Затем он анализирует полученный результат и отвечает. Использование дорогостоящей модели рассуждений на каждом шаге — это не проявление интеллекта. Иногда это просто плохая инженерная практика.
Разрешения
Как только агент может делегировать действия, возникает более сложная проблема: что он может делать? Чтение календаря отличается от отправки электронного письма. Чтение репозитория отличается от слияния pull-запроса. Проверка сервера сильно отличается от удаления файлов. Поэтому полезному личному агенту необходима модель разрешений вместе с его инструментами, примерно такая:
- Чтение происходит без запроса.
- Подготовка черновиков и планов происходит без запроса.
- Действия с низким риском могут выполняться автоматически.
- Любые значимые действия требуют согласия человека.
Когда агента просят выяснить причину сбоя сервиса, он может сразу приступить к работе. Если он приходит к выводу, что база данных повреждена, и планирует её удалить и воссоздать, сначала должно поступить подтверждение. Автономия не должна быть дихотомичной — она должна варьироваться в зависимости от уровня риска.
Память и контекст
Ещё одной причиной против превращения каждого специализированного инструмента в персонального ассистента является контекст. Codex должен понимать структуру хранилища, но не всю жизнь пользователя. Инструмент инфраструктуры должен знать серверы, но не каждый из когда-либо ведённых разговоров. Календарь отслеживает встречи, а менеджер задач — задачи. Оркестратор может стать слоем, который понимает, как связаны между собой эти системы.
Рассмотрим вопрос о том, что происходит с конкретным проектом. Ни один запрос к базе данных не может дать на него ответа. Хороший ответ основывается на недавних работах над проектом, активности в GitHub, задачах, принятых ранее решениях, статусе развертывания и планах пользователя на будущее. Именно в этом межсистемном контексте личный слой оркестрации становится по-настоящему ценным.
Ловушка чрезмерной инженерии
Опасность очевидна. Такой подход позволяет легко нарисовать что-то вроде этой диаграммы:
User
↓
Intent Classifier
↓
Planning Agent
↓
Model Router
↓
Memory Agent
↓
Permission Agent
↓
Coding Agent
↓
Validation Agent
↓
Reflection Agent
↓
Supervisor Agent
↓
Another Agent Watching the Other Agents
А затем тратить три месяца на создание организации ИИ, чтобы можно было спросить, что запланировано на сегодня — это никому не помогает. Урок всего этого эксперимента в том, что сложность должна заслужить своё место. Двенадцать агентов лишь потому, что схема архитектуры выглядит круто, — плохая причина; способности, которые постоянно экономят время, — хорошая причина.
Делегирование перед автономией
Полностью автономные агенты привлекают много внимания: даёшь им цель, оставляешь их работать часами, позволяешь агентам общаться и принимать решения между собой, а затем возвращаешься, когда всё готово. Это интересно, но это не лучший старт для личной системы. Высоконадёжное делегирование должно предшествовать максимальной автономии. Цель — указать выполнить действие X, чтобы система надёжно выбирала подходящий инструмент или агента и сообщала о результатах. Как только это будет работать исключительно хорошо, автономия может постепенно увеличиваться.
Более специализированные инструменты, а не меньше
Изначально цель кажется следующей: консолидация — слишком много инструментов искусственного интеллекта, поэтому нужно создать один ИИ, который заменит их все. Однако это оказывается неверным подходом. Конечным результатом, скорее всего, станут более специализированные системы ИИ, причем они больше не потребуют отдельного управления, что и решает слой оркестрации. В будущем, возможно, не будет одного ИИ, управляющего всеми, а будет один интерфейс для их координации. Разница тонкая, но значительная.
Для чего нужен агент
После того, как вы запустите такую систему, нарушите её работу, настроите интерфейс чата, протестируете различные модели и серьёзно подумаете о специализированных кодирующих агентах, становится ясной роль личного агента. Ему не обязательно быть самым умным ИИ в всей системе. Главное — чтобы он знал человека и его системы. Он должен понимать, о чём идёт речь, какой контекст важен, какая функция подходит, что он может сделать, когда ему нужна подтверждение и как вернуть результат. Этого достаточно, а всё остальное можно делегировать.
Архитектура, которую стоит желать
Целевая структура выглядит примерно так:
ME
│
▼
GOOGLE CHAT
│
▼
┌─────────────────┐
│ HERMES │
│ │
│ Intent │
│ Context │
│ Memory │
│ Permissions │
│ Orchestration │
└────────┬────────┘
│
┌──────────────────┼───────────────────┐
│ │ │
▼ ▼ ▼
AI MODELS CODING AGENTS TOOLS
│ │ │
Local / Cloud Codex/OpenCode GitHub/APIs
Fast / Strong Servers/Tasks
│ │ │
└──────────────────┼───────────────────┘
│
▼
HERMES
│
▼
ME
Само по себе отдельное ячейка не имеет значения. Всё, что находится под управлением оркестратора, в конечном итоге должно быть заменяемым. Появляется более совершенный инструмент для программирования — его просто заменяют. Появляется более качественная локальная модель — её тоже заменяют. Обработка данных в облаке становится дешевле — туда направляют больше задач. Поставщик услуг становится ненадёжным — трафик перенаправляют в обход него. Переделывать способ использования ассистента каждый раз, когда меняется индустрия ИИ, не должно быть необходимостью.
Личный ИИ, возможно, в обратном порядке
Большинство продуктов искусственного интеллекта соревнуются в том, насколько умным является их модель, что вполне понятно. Однако по мере совершенствования моделей возрастает значение ещё одного аспекта — координации. Это означает понимание того, что имеет в виду человек, контекста ситуации, какие системы важны, какие инструменты существуют, какая модель подходит, какие действия безопасны, когда стоит задать вопрос и когда вообще не следует использовать искусственный интеллект. Полезный помощник — это не обязательно тот, у кого самый высокий показатель в тестах, а тот, благодаря которому вся интеллектуальная база и программное обеспечение вокруг человека кажутся единой системой.
Краткое резюме
Начальной точкой является желание иметь личного ИИ-агента. Внедрение такого агента показывает, что наличие постоянного помощника на самом деле связано с проблемами инфраструктуры. Поиск идеальной модели указывает на то, что выбор модели на самом деле представляет собой проблему маршрутизации. Определение того, что должен делать агент, показывает, что личный помощник по сути может быть проблемой оркестрации действий. Архитектура меняется от поиска самой умной модели и предоставления ей всех необходимых инструментов к системе, которая понимает намерения и направляет задачи в соответствующее место. Это гораздо менее фантастическое описание Jarvis, но гораздо более близкое к тому, что действительно можно создать и использовать каждый день.
Связанные материалы
- Создание агента планирования в LangGraph: планирование, выполнение, перепланирование, отчёт — агент планирования из четырёх узлов в LangGraph для финансовых исследований: структурированные планы, реестр инструментов с учётом пространства имён, ограничения на перепланирование и пример выполнения с отслеживанием.
- MiniCPM5-2B против конкурентов 4B: почему подход с агентами даёт другие результаты — модель объёмом 2,5 млрд параметров, превосходящая конкурентов 4B по результатам однократных тестов, отстаёт в два-три раза при использовании подхода с агентами. Проблемы с версиями индексов, локальная производительность и ситуации, когда такой подход уместен.