Три минуты на планирование, десять на исполнение. Да, в масштабах человека это быстро, но уже хочется еще быстрее!
Судя по всему, я не одна такая. Посмотрите на провайдеров, которые за доплату дают ответы в два-три раза быстрее. Спрос есть, значит желание такое имеется не только у меня.
Но платить за скорость — не единственный выход. Параллельное исполнение чего-либо как идея существует давно: в языках программирования, в реальной жизни. Аналогию придумать несложно. Теперь она добралась и до агентов — в виде субагентов. Передовые агенты начали поддерживать идею с параллельным выполнением чего-либо не так давно, но кажется идея всем откликается и быстро набирает обороты.
Ну и сценариев применения у этой фичи много. Исследовать разные участки кодовой базы одновременно, писать в слабо связанные файлы параллельно, запускать независимые проверки — думаю, вы сами можете набросать с десяток таких кейсов.
Мы решили не оставаться в стороне. В Veai 5.9 появился режим Оркестратора. Все инструменты сейчас так или иначе движутся в сторону автоматического выбора — когда агент сам решает, что делегировать, а что делать последовательно. Получается на наш взгляд сейчас у всех не вот чтобы супер круто.
Довольно часто приходится агента буквально заставлять НЕ делать задачу последовательно. Мы решили попробовать сделать лучше :).
НО! Фича в бете, и честно говоря, очень хотелось бы услышать от вас, насколько хорошо у нас это вышло. Будем крайне благодарны за фидбек тут или в нашем телеграмм-чатике.
Вместе с оркестратором на главном экране появились три скилла:
Plan — исполняемый план с конкретными задачами, файлами и входными данными, без написания кода
Code with subagents — берёт задачу или готовый план, запускает сабагентов на реализацию, тестирование и ревью, триажит проблемы и фиксит подтверждённые
Code review orchestrated — три независимых прохода ревью с разных углов, итоговая классификация находок
Помимо этой фичи, в недавнем релизе Veai 5.9 мы добавили генерацию тестов по исполнению, глобальные Skills, обновленный вид истории чатов и много чего еще. Но про них мы расскажем в следующих статьях.
Veai – это AI-агент для JetBrains IDE с доступом к Sonnet, Opus, GPT и другим передовым моделям, без проблем с оплатой и подключением из РФ. Для всех, кому интересно следить за продуктом, новостями из мира AI и техниками использования AI в разработке, оставляем ссылку на наш телеграм-канал.
Комментарии (9)
inkognito1331
23.04.2026 08:08Ничего, там сейчас в Испании датацентров настроят (предыдущую статью буквально прочитал) и все начнет летать за счет паразитирования на ресурсах, а не каких-то разумных решениях ☺️
Granulex
Статья верно указывает на параллелизм, но пропускает главный источник задержки: не LLM-инференс, а последовательные вызовы инструментов. Каждый read_file, bash-команда или API-запрос – отдельный round-trip. Читаешь 5 файлов последовательно – получаешь 5 задержек вместо одной. Настоящий выигрыш – батчинг инструментов: дать агенту запросить всё нужное за один вызов. Sub-агенты решают параллелизм задач, но I/O-латентность внутри каждого остаётся нетронутой.
Gromilo
Kilo читает файлы пачкой, мне нравится
headliner1985
В кило к сожалению контекст засирается за минуту, плюс он не нативный и жутко глючит отрисовка. Сейчас перешёл на veai и почти все задачи через него делаю, хотя иногда и в кило запускаю.
Gromilo
С отрисовкой пока не сталкивался.
Реализация одного метода круда с тестами по спеке занимает 50-70к токенов контекста из 200к доступных. Меня устраивает.
Дискавери работает через субагента, тоже бережёт основной контекст.
За счёт чего экономия контекста?
DaniilStepanov
наш инструмент, о котором говорится в статье, умеет в батчевый вызов тулов :)
DaniilStepanov
А в целом, режим оркестрации это не только про эффективность с точки зрения временных затрат, но и про бОльшую автономность и экономию контекстного окна при выполнении больших задач. Мы постарались сделать решение "в один клик", где в рамках одного чата можно спланировать фичу (спроектировать спеку вместе с агентом) и сразу ее реализовать с помощью разработанного пайплайна (code wave + test + (review + triage + fix))
Если ваша задача небольшая, выполнима в рамках одного чата и нужно ручное управление (вы постоянно общаетесь с агентом), то оркестратор тут, скорее всего, сделает только хуже
Granulex
Отлично, что батчинг уже есть. Осталось решить классическую задачу: что делать с самым медленным в пачке? Это как оптимизировать SELECT N+1 до batch-запроса, но забыть про индекс – задержка смещается, а не исчезает.
DaniilStepanov
Справедливое замечание, отвечу:
1. Большинство тулов действительно может работать параллельно, max уже сильно лучше sum.
2. Мы очень много работаем над производительностью тулов (в том числе используем индексацию, да :))
3. Может показаться, что асинхронный вызов тулов решит проблему, но на практике модели начинают путаться — они обучены на строгую последовательность user → assistant(tool_call) → tool_result → assistant