Профили субагентов (Model Routing)

0. Прежде чем начать

Что такое профили субагентов?

Когда агент решает большую задачу, он может передавать часть работы субагентам — специализированным агентам (Code, Ask, Test, Review, Plan, Debug). По умолчанию субагент работает на той же модели, что и основной (родительский) агент.

Профили субагентов (функция Model Routing) позволяют заранее описать набор именованных профилей — например, fast, balanced, strong — и привязать к каждому из них конкретную модель и параметры рассуждения. Главный агент затем выбирает подходящий профиль для каждой подзадачи по его текстовому описанию.

Профиль состоит из:

• псевдонима (alias) — короткого имени, которым главный агент ссылается на профиль;
• описания (description) — инструкции на естественном языке, когда использовать профиль;
• (необязательно) конкретной модели провайдера, на которую профиль закрепляется;
• (необязательно) уровня рассуждения (reasoning) для этой модели.

Если модель у профиля не задана, он наследует модель родительского агента.

Зачем это нужно

Профили решают типичную проблему: на разных подзадачах оправданы разные модели.

• Дешёвая и быстрая модель — для простого поиска по коду, чтения файлов, кратких ответов.
• Сбалансированная модель — для рутинного анализа и генерации тестов.
• Самая мощная (и дорогая) модель — для сложной архитектуры, нетривиальных правок, глубокого ревью и трудного дебага.

Описывая профили, вы:

• экономите ресурсы — лёгкие подзадачи уходят на дешёвые/быстрые модели;
• повышаете качество на сложных подзадачах — они уходят на мощную модель;
• получаете предсказуемость — выбор модели управляется явными правилами, а не случайностью.

Встроенные профили

В системе присутствуют три профиля по умолчанию (fast, balanced, strong). Их нельзя удалить, но можно отредактировать (задать модель, изменить описание).

Профиль	Назначение по умолчанию
fast	Лёгкий поиск только на чтение, чтение файлов, суммаризация, простое изучение кодовой базы.
balanced	Обычный анализ, Q&A средней сложности, рутинная генерация тестов, типовая поддержка реализации.
strong	Сложный анализ архитектуры, нетривиальные правки кода, трудный дебаг и глубокое ревью.

По умолчанию у встроенных профилей модель не закреплена — они наследуют модель родительского агента (Inherit parent); чтобы профили начали маршрутизировать запросы на разные модели, закрепите за ними конкретные модели.

Помимо встроенных, вы можете создавать собственные профили с произвольными псевдонимами (например, second-reviewer, planner).

1. Настройка профилей в Settings

Профили настраиваются в Settings → Tools → Veai → Model Routing.

Область применения (Scope)

В верхней части окна выбирается область, к которой относятся профили:

• Project — профили, специфичные для проекта.
• Global — глобальные профили, общие для всех проектов на вашей машине.

Таблица профилей

В разделе Profiles отображается таблица из трёх колонок:

• Alias — псевдоним профиля;
• Description — описание (когда использовать профиль);
• Model — закреплённая модель и уровень reasoning, либо Inherit parent, если модель не задана.

Диалог создания и редактирования профиля

Добавить профиль — Add profile; отредактировать — Edit profile (или двойным кликом по строке); удалить — Remove profile.

В диалоге доступны поля: Alias, Description, Mode, Model и Reasoning.

2. Поля профиля

Alias

Короткое имя профиля, которым на него ссылается главный агент.

• Должен соответствовать шаблону [a-z][a-z0-9-]* — строчные латинские буквы, цифры и дефис, начинается с буквы (например, fast, gpt-5, reviewer).
• Должен быть уникальным в пределах области.
• У встроенных профилей псевдоним менять нельзя.

Description

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

• Не может быть пустым.
• Пишите его как короткую инструкцию по сценарию использования, например: «Use for lightweight read-only lookup and file reading».

Совет: если временно нужно «отговорить» агента от использования встроенного профиля, который нельзя удалить, задайте ему описание вроде «never use it».

Mode: Inherit parent и Model

Поле Mode задаёт, как профиль выбирает модель:

• Inherit parent — профиль не закрепляет модель; субагент работает на модели родительского агента. Поля Model и Reasoning при этом неактивны.
• Model — профиль закрепляется за конкретной моделью конкретного провайдера. Становятся активными поля Model и Reasoning.

3. Файл model-routing.yaml

Профили хранятся в YAML-файле model-routing.yaml:

• проектный — в .veai/model-routing.yaml в корне проекта;
• глобальный — в ~/.veai/model-routing.yaml.

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

Структура файла:

Совет: model-routing.yaml поддерживает редактирование в IDE, но во избежание ошибок рекомендуется все манипуляции производить через интерфейс настроек

5. Рекомендации

• Начните с того, что закрепите модели за встроенными fast/balanced/strong — этого уже достаточно, чтобы главный агент разводил подзадачи по разным моделям.
• Пишите описания как чёткие правила выбора: главный агент полагается именно на них. Чем конкретнее сценарий («только чтение», «генерация тестов», «глубокое ревью»), тем точнее маршрутизация.
• Используйте Project-область и коммитьте model-routing.yaml в репозиторий, чтобы команда работала с одинаковыми правилами маршрутизации.
• Дорогие модели закрепляйте за strong и редкими профилями, а массовые подзадачи направляйте на fast/balanced, чтобы контролировать расход токенов/минут.
• Если профиль временно не нужен, но удалить его нельзя (встроенный) — переведите его в режим Inherit parent или опишите как нежелательный для вызова.