> For the complete documentation index, see [llms.txt](https://docs.suvvy.ai/ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.suvvy.ai/ru/deistviya/multiagentnost/vyzov-podchinennogo-bota.md). # Вызов подчиненного агента ### Описание работы Предположим, в рамках задачи по настройке агента-продавца у вас имеются следующие исходные данные: * Компания продает окна * У компании существует 5 таблиц от разных поставщиков с прайсами * Необходимо вызывать 2 запроса в СРМ - об оформлении заказа, о статусе заказа * Инструкция имеет длинное описание на 3 листа А4 * База знаний содержит не менее 50 файлов В случае, такой ситуации, мы получим довольно большой объем контекста, т.к. у нас будет большая инструкция со своими условиями + 5 описанных функций для таблицы + 2 описанные функции для вызова веб-хуков и функция по работе с базой знаний. В рамках такого объема модель со 100% вероятностью будет забывать важные пункты либо инструкции, либо будет плохо работать с таблицами и веб-хуками допуская иногда не значительные, а иногда довольно значимые ошибки. За счет наличия ошибок вся "магия" работы с моделью будет теряться. Проблемы потери внимания могут здесь быть решены за счет следующего решения: 1. Для работы с таблицами создается отдельный агент, в котором эти таблицы создаются. В основном агенте таблиц не будет. 2. Для работы с веб-хуками создается тоже отдельный агент. 3. На некоторые блоки так же создаются свои агенты. 4. В случае, когда необходимо вызвать конкретных агентов они вызываются путем написания стандартных вызовов функций (подробнее в [статье о функциях](/ru/osnovnye-nastroiki/prompts/prompts-2.md)). Таким образом, вместо 8 больших функций у основного агента, мы получим только 3 лаконичные функции, или чуть больше, если решим выделить куски инструкции в отдельные блоки. Это со 100% вероятностью сразу повысит точность работы модели, а так же сократит себестоимость. Т.к. в первом случае, до оптимизации мы передавали бы большой объем функций при каждом запросе. А после оптимизации отдельные куски вызываются только в конкретный момент времени. ### Создание подчиненного агента На первом этапе нам необходимо создать стандартного агента:
Стандартную инструкцию для подчиненного агента нужно убрать, т.к. элементы приветствия, тональности, общие сведения и пр. могут не иметь функционального значения, и он должен ориентироваться только на выполнение конкретной задачи. Исходя из примера выше опишем ему персональную инструкцию:
1. **Время ожидания в секундах** ставим в 0, т.к. тут задержки нам не нужны. 2. Внутри инструкции максимально лаконично описываем суть конкретной задачи, которую агент должен выполнять. Можно даже добавить, что это технический агент, и его задача — возвращать ответ в конкретном формате, например, в JSON. В данном случае, мы описали, что задача агента — рассчитывать стоимость в таблицах. Теперь нужно разобраться, как главный агент будет вызывать подчиненного, об этом ниже. ### Добавление подчиненного агента главному Необходимо в основном агенте добавить подчиненного агента через раздел Действия:
**Название действия** - просто название для отображения в списке. **Название функции** - это название функции, которое будет видеть агент. Данное название указывается на английском без пробелов. Название должно отображать общий смысл действия. **Описание функции** - более подробное описание смысла действия. По данному описанию Савви будет понимать, когда ее нужно вызывать. ### Добавление шага Внутри **Действия** можно вызывать последовательность действий, используя разные типы вызовов, поэтому это называется шагами. При добавлении шага, мы можем выбрать один из трех вариантов: вызов веб-хука, вызов подчиненного агента, или вызов таблицы. Про первый вариант мы уже рассказывали в предыдущей главе, в данном случае нас интересует **Вызов подчиненного агента**:
При заполнении формы шага ваша задача только выбрать подчиненного агента:
### Вызов подчиненного агента В целом, заполнив описание и названия действия этого уже достаточно для того, чтобы агент автоматически вызывался из основного агента. Но на всякий случай, чтобы нивелировать возможные неочевидные для основного агента случаи, мы можем в инструкции прямо указать, в какой момент нам нужно вызывать подчиненного агента, обратившись к нему по названию функции, указанной в Действии:
### Анализ вызовов подчиненных агентов При внедрении Савви самый долгий процесс - это отладка и корректировка инструкций. Подробно по работе с отладкой мы разбирались в отдельном [разделе](/ru/osnovnye-nastroiki/prompts/prompts/otladka-instrukcii.md). Отладка подчиненных агентов работает по похожему принципу и мы рассмотрим два способа: через чат и через файл экспорта. #### Анализ через чат
В ответе, который ожидаемо был сформирован подчиненным агентом нажимаем на кнопку со значком i и смотрим в открывшееся модальное окно:
Здесь мы видим: * Выполняется функция - название функции, которая была вызвана * Инструмент - видим ответ от функции - в данном случае от подчиненного агента Ответ, который был получен от подчиненного агента изменяется главным агентом - это нормально и правильно. #### Анализ через экспортный файл 1. Находим нужный диалог с основным агентом через вкладку **История** и через пункт Действия -> Экспорт выгружаем файл:
Файл сохраняется в папку **Загрузки**, открываем его как обычный файл:
В файле экспорт в более удобном виде отображаются вызовы функций. По кнопке i можно получать информацию о результатах ответа функции:
А, если функция представляет из себя вызов подчиненного агента, то мы увидим рядом с иконкой i иконку в виде головы робота. При нажатии на нее у нас откроется отдельное модальное окно с отдельным экспортом именно по этому агенту:
Дальше анализ происходит аналогично, если он что-то вызывал, какие-то функции внутри себя, то мы это увидим так же ввиде служебных надписей (на скрине выше они отсутствуют). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.suvvy.ai/ru/deistviya/multiagentnost/vyzov-podchinennogo-bota.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.