🙇‍♂️ "Умные" вызовы "умных" агентов (smart calling)


Продолжим серию постов с "азбукой" агентных процессов - нам нужно выучить некоторые новые "буквы". Сегодня поговорим о "smart calling" - практическом приёме "умного" вызова "умного" агента. Этот приём пригодится для выстраивания сложных агентных процессов, и сможет некоторым образом повышать надёжность и usability работы.

▶️ Напомним базу

Оркестратор и агент общаются через контекст и промпты. Оркестратор при вызове пишет промпт для вызова агента, агент отрабатывает и пишет "сообщение" оркестратору с результатами работы.

Несмотря на явную аналогию с вызовом функции в классических алгоритмах, мы имеем нюансы: схема "вызова" никак не типизирована и ничем особенным не ограничена - просто текстовое сообщение. Впрочем, ровно как и ответ агента! Это имеет свои последствия.

ℹ️ Аргументы "вызова" - проверка, верификация

Первое, при старте агента если он специализирован на выполнении какой то работы, лучше верифицировать что ему сообщил оркестратор. "Проверить аргументы вызова", так сказать, а может быть ещё и верифицировать - формат, и наличие. То есть посмотреть, например, существует указанный файл или нет.

🛑 "Выбрасывание ошибки"

Что делаем если что то не в порядке и это критично, мы не можем исправить? Например, сказано что необходимо анализировать отчёт, а отчёта по указанному пути мы не нашли.

Мы "выбрасываем ошибку" - инструктируем агента что в таком случае мы прекращаем работу и пишем ясное сообщение о причинах.

🔃 Возврат результатов

Мы уже обсудили с вами на темах "agentic memory" и "папка задачи" важность беречь контекст оркестратора. Объёмные результаты мы помещаем в папку задачи. Короткие результаты возвращаем текстом, проинструктировав агента что при завершении работы он их должен сообщить.

🤓 Где же тут "умное" (smart)?

Достаточно вспомнить что мы с вами работаем не с простым детерминированным процессором компьютера, который выполняет только структурированные и детерминированные инструкции.

Тут инструкцию исполняет агент, а значит он может использовать всю свою нечёткую логику и когнитивные способности - нужно только попросить.

В контекст "агента" мы можем подгрузить описание блока функциональности с логикой работы. Допустим, у вас создан специальный агент по работе с базой документации в проекте (спецификации - описание эпиков и фич). Вы можете подгрузить правила оформления эпиков и фич в такого агента, и проинструктировать чтобы оркестратор сохранял описание эпиков и фич не через тул Writefile, а через этого специализированного агента.

Агент, получив в контекст правила оформления эпиков и фич, проведёт "на лету" своеобразный smart "линтинг" переданного файла. А если попросить его "выявить ошибки" и логические несостыковки, ещё и будет проверять то, о чем вы не подумали при проектировании этого процесса. Важно просто сформировать правильный контекст и правильные инструкции: правила оформления документации, описания статусов, и инструкции агенту все это использовать.

Также можно применить приём "умные результаты": когда мы не только вернули запрошенные данные, но и дали пояснения к ним относительно их использования, а также контекста. Например, возвращаем статус эпика и говорим что с ним можно делать дальше (это специализированный агент возьмёт из описания ваших процессов работы с эпиком). Или агент создания папки задач вернёт подсказку, что папка задач создана с "точкой" в начале имени, это делает её "невидимой" среди обычных файлов, поэтому нужно применять специальные опции для bash команд для её обнаружения. Интересные результаты можно получить от инструкции в промпте агента "а также добавь в итоги работы то, что считаешь важным и необходимым".

☝️ Согласитесь, выстраивать алгоритм из "функций", которые стараются сделать порученную им работу наиболее разумным способом, которые комментируют переданные аргументы при ошибках и советуют относительно сформированных ими результатов - это интересный поворот и требует некоторого "сдвига" восприятия для использования.

␄
#post
@deksden_notes