Рассмотрим проектирование агента поиска товаров в маркетплейсе по бенчмарку Store с ERC3. Попробуем подойти к проектированию агента с точки зрения структурного анализа.
Сначала посмотрим на схему #1 — из каких компонентов состоит Агент. Не буду их описывать, думаю вы и так понимаете, что они означают… НО что-то это напоминает… хм…
Да это вылитая схема
IDEF0 (см. схему #2 для понимания) по описанию бизнес-функций! Слева вход — запрос пользователя или другого агента, сверху инструкции, правила поведения и навыки, снизу инструментарий для выполнения бизнес-функции, ну а справа выход.Если смотрели выступление Ильи у Валеры, то вспомните: он применил схему оркестратора с саб-агентами для решения бенчмарка store, и один из таких агентов был агент по поиску товаров, использующий ручку API
/products/list (см. схему #3).Давайте теперь опишем данного саб-агента с помощью методологии IDEF0:
1. Определим бизнес-функцию нашего агента как
«Подобрать товар» — анализ каталога товаров и выявление позиции, соответствующей запросу. Мы выбираем «Подобрать», а не просто «Найти» или «Сканировать», потому что агент выполняет сложную когнитивную работу: он не просто делает запрос в базу (как поисковик), а итеративно сканирует каталог, фильтрует результаты в памяти и валидирует их на соответствие нечетким критериям пользователя.
2. На вход нашему агенту мы предоставляем
«поисковый запрос с критериями фильтрации» — текстовая строка на естественном языке, содержащая как намерение («найди»), так и ограничения («дешевле 500», «красный»). Пример: «Нужна игровая видеокарта не дороже 60000 рублей, желательно Asus».
На этом этапе можно размышлять над краевыми случаями и собрать
Evaluation Dataset.3. Для функции «Подобрать товар» механизм представляет собой tool, назовем ее
get_product_list. В нашем случае это будет простая обертка вокруг API /products/list. Мы осознанно не упоминаем в механизмах LLM, так как это больше НФТ (нефункциональное требование), нежели бизнес-требование.
4. В классическом менеджменте сверху находятся должностные инструкции, регламенты, ГОСТы и законы, но в нашем случае это будет Ролевая модель, Процедура поиска и Политики безопасности.
Важно: мы не отбираем у исследователей работу с промптом, но указываем в требованиях общие рекомендации.
5. Ну и Вывод — это продукт или информация, полученная в результате работы функции. Это то, ради чего функция существует. В классическом чат-боте выводом считается текстовое сообщение пользователю. В инженерии автономных агентов выводом является структурированный ответ, передающий ответственность оркестратору.
Рекомендую сразу размышлять над негативными сценариями: как мы будем обрабатывать ошибки.
Зачем это нужно?
Такая детализация позволяет еще до написания первой строки кода и промпта наглядно увидеть «дыры» в логике. Если вы не можете описать агента в этой схеме — значит, вы пока не знаете, что именно строите.
Хотите пример требований и кода по методологии? Поставьте реакцию, чтобы я знал, что вам это интересно 👇