"🙇‍♂️ ""Умные"" вызовы ""умных"" агентов (smart calling) Продолжим серию постов с ""азбукой"" агентных процессов - нам нужно выучить некоторые новые ""буквы"". Сегодня поговорим о ""smart calling"" - практическом приёме ""умного"" вызова ""умного"" агента. Этот приём пригодится для выстраивания сложных агентных процессов, и сможет некоторым образом повышать надёжность и usability работы. ▶️ Напомним базу Оркестратор и агент общаются через контекст и промпты. Оркестратор при вызове пишет промпт для вызова агента, агент отрабатывает и пишет ""сообщение"" оркестратору с результатами работы. Несмотря на явную аналогию с вызовом функции в классических алгоритмах, мы имеем нюансы: схема ""вызова"" никак не типизирована и ничем особенным не ограничена - просто текстовое сообщение. Впрочем, ровно как и ответ агента! Это имеет свои последствия. ℹ️ Аргументы ""вызова"" - проверка, верификация Первое, при старте агента если он специализирован на выполнении какой то работы, лучше верифицировать что ему сообщил оркестратор. ""Проверить аргументы вызова"", так сказать, а может быть ещё и верифицировать - формат, и наличие. То есть посмотреть, например, существует указанный файл или нет. 🛑 ""Выбрасывание ошибки"" Что делаем если что то не в порядке и это критично, мы не можем исправить? Например, сказано что необходимо анализировать отчёт, а отчёта по указанному пути мы не нашли. Мы ""выбрасываем ошибку"" - инструктируем агента что в таком случае мы прекращаем работу и пишем ясное сообщение о причинах. 🔃 Возврат результатов Мы уже обсудили с вами на темах ""agentic memory"" и ""папка задачи"" важность беречь контекст оркестратора. Объёмные результаты мы помещаем в папку задачи. Короткие результаты возвращаем текстом, проинструктировав агента что при завершении работы он их должен сообщить. 🤓 Где же тут ""умное"" (smart)? Достаточно вспомнить что мы с вами работаем не с простым детерминированным процессором компьютера, который выполняет только структурированные и детерминированные инструкции. Тут инструкцию исполняет агент, а значит он может использовать всю свою нечёткую логику и когнитивные способности - нужно только попросить. В контекст ""агента"" мы можем подгрузить описание блока функциональности с логикой работы. Допустим, у вас создан специальный агент по работе с базой документации в проекте (спецификации - описание эпиков и фич). Вы можете подгрузить правила оформления эпиков и фич в такого агента, и проинструктировать чтобы оркестратор сохранял описание эпиков и фич не через тул Writefile, а через этого специализированного агента. Агент, получив в контекст правила оформления эпиков и фич, проведёт ""на лету"" своеобразный smart ""линтинг"" переданного файла. А если попросить его ""выявить ошибки"" и логические несостыковки, ещё и будет проверять то, о чем вы не подумали при проектировании этого процесса. Важно просто сформировать правильный контекст и правильные инструкции: правила оформления документации, описания статусов, и инструкции агенту все это использовать. Также можно применить приём ""умные результаты"": когда мы не только вернули запрошенные данные, но и дали пояснения к ним относительно их использования, а также контекста. Например, возвращаем статус эпика и говорим что с ним можно делать дальше (это специализированный агент возьмёт из описания ваших процессов работы с эпиком). Или агент создания папки задач вернёт подсказку, что папка задач создана с ""точкой"" в начале имени, это делает её ""невидимой"" среди обычных файлов, поэтому нужно применять специальные опции для bash команд для её обнаружения. Интересные результаты можно получить от инструкции в промпте агента ""а также добавь в итоги работы то, что считаешь важным и необходимым"". ☝️ Согласитесь, выстраивать алгоритм из ""функций"", которые стараются сделать порученную им работу наиболее разумным способом, которые комментируют переданные аргументы при ошибках и советуют относительно сформированных ими результатов - это интересный поворот и требует некоторого ""сдвига"" восприятия для использования. ␄ #post @deksden_notes"