Transcription
Давайте поговорим о том, как создавать лучшие инструменты для ваших агентов, потому что эффективность ваших агентов действительно зависит от доступных инструментов, а также от интеллекта модели. Поэтому я разберу это, и мы рассмотрим некоторые практические выводы, и в конце, надеюсь, это заставит вас переосмыслить, как вы думаете об использовании инструментов. Идея для этого видео возникла из этой статьи из Enthropic под названием «Создание эффективных инструментов для агентов с помощью агентов». Поэтому мы рассмотрим ключевые выводы и некоторые практические выводы. Но прежде чем мы это сделаем, нам нужно подумать о том, как меняется разработка программного обеспечения с помощью агентов. В традиционной разработке программного обеспечения вы реализуете основную функциональность инструмента, оборачивая ее в функцию. Теперь это детерминированные системы. Вы предоставляете входные данные, ожидаете детерминированный ответ. С инструментами все немного иначе. Обычно входные данные — это запрос на естественном языке. Затем агент, основываясь на своем плане, решит, какие шаги предпринять. Он может либо вызвать инструмент, использовать свои внутренние знания, либо даже задать вам уточняющий вопрос. И каждый раз, когда вы задаете один и тот же вопрос, вы будете видеть разные шаги, которые придумывает агент. И обычно эти агенты являются частью традиционного стека разработки программного обеспечения. Поэтому вам действительно нужно переосмыслить, как вы реализуете эти системы.
Сама статья говорит о четырехэтапном процессе создания хороших инструментов. Наше внимание будет сосредоточено в основном на ключевых принципах написания лучших инструментов. Но для полноты картины, вы хотите сначала начать с первоначального прототипа, который будет реализовывать основную функциональность. Затем вы хотите запускать эволюционные тесты для инструментов, которые вы реализуете. Затем вы хотите сотрудничать с кодирующим агентом. То есть, по сути, использовать интеллект кодирующих агентов, чтобы помочь вам улучшить описание и реализацию вашего инструмента, и в конечном итоге вы хотите запускать эволюционные тесты, потому что если вы не можете это измерить, вы не можете это улучшить, и это обычно итеративный процесс, но когда дело доходит до реализации самих инструментов, вот ключевые принципы, которые я рекомендую иметь в виду.
Первое — выбрать правильные инструменты для реализации. И не волнуйтесь, мы поговорим о деталях всего этого. Затем убедитесь, что вы можете группировать различные инструменты вместе. Это поможет агенту выбирать лучшие инструменты. Затем мы много поговорим о контекстном инжиниринге. Поэтому вы хотите убедиться, что входные данные для инструмента имеют смысл. Также, возвращаемые инструментами данные должны быть осмысленным контекстом, который мы можем передать в LLM. Это также обеспечит нам эффективность использования токенов, потому что мы не хотим просто заполнять контекст модели бесполезной информацией. Промпт-инжиниринг не мертв. Поэтому мы поговорим о том, как эффективно создавать описания инструментов с помощью промпт-инжиниринга, которые будут полезны для LLM при выборе соответствующего инструмента. И затем больше инструментов не всегда приводит к лучшим результатам. Как и в традиционной разработке программного обеспечения, небольшие улучшения дают драматические результаты.
Далее мы поговорим о каждом из них с более конкретной и подробной информацией. Но я хочу, чтобы вы посмотрели на этот поток. Итак, предположим, у вас есть задача, которая предоставляется агенту. Агент может выбрать ряд различных инструментов для каждой из подзадач. Теперь входные и выходные данные инструмента будут добавляться в контекстное окно модели, LLM или агента, и нам нужно будет тщательно подумать о том, как сохранить только полезную информацию в этом контекстном окне.
Действительно хорошим примером хороших инструментов для AI-агентов является BrowserBase. Они обеспечивают возможности веб-браузинга для ваших AI-агентов и приложений. Так что думайте о них как о облачной платформе, которая позволяет вам размещать такие инструменты, как Puppeteer и Playwright, которые могут взаимодействовать с вашими AI-агентами, и они также являются спонсорами сегодняшнего видео. Это чрезвычайно масштабируемая, быстрая и безопасная платформа, которая позволяет создавать собственных пользовательских агентов для автоматизации браузера. У них есть предварительно существующие инструменты для браузинга. Это обеспечивает автоматизацию рабочих процессов и также позволяет вам извлекать данные с веб-сайтов. Но функция, которая мне нравится больше всего, называется Stage hand. Это их фреймворк с открытым исходным кодом для автоматизации браузера с помощью ИИ. Таким образом, это обеспечивает автоматизацию браузера путем определения действий, а затем назначения задач агентам, и это поставляется с очень мощным SDK, который вы можете начать использовать в своих собственных приложениях. Этот SDK имеет ряд различных существующих агентов, включая агента использования компьютера, и полностью совместим с Playwright. Таким образом, автоматизация браузера чрезвычайно проста с Stage hand. Это позволяет вам взаимодействовать с Playwright через естественный язык. Например, если вы собираетесь перейти на веб-страницу, вот команда, которую вы будете использовать. Или если вы хотите, чтобы он предпринял действие, вы можете просто описать это на естественном языке. Также он обеспечивает агента использования компьютера. И самое приятное то, что если вы хотите извлечь данные с любого веб-сайта, вы можете определить свою собственную схему. Агент извлечет эти данные и вернет их вам. Это чрезвычайно полезный инструмент для агентов, которые будут взаимодействовать с вашим веб-браузером. Обязательно ознакомьтесь с ними. Ссылка будет в описании видео.
Теперь вернемся к видео. Итак, первый принцип — выбор правильного инструмента для задачи. Теперь больше инструментов не означает, что вы получите лучший результат. На самом деле они говорят, что видели распространенную ошибку, когда люди просто оборачивают существующую программную функциональность или API в инструмент и представляют это как инструмент для агента. Так не следует думать о реализации ваших инструментов. Вам нужно думать о контекстном окне вашего LLM. Таким образом, инструмент может иметь каскад из нескольких различных операций, и вы хотите просто генерировать осмысленные результаты, которые агент может использовать.
Хорошо, вот очень простой пример поиска в адресной книге. В традиционной разработке программного обеспечения вы могли бы реализовать систему, которая загружает все контакты в память. Затем перебирает каждый контакт, и если есть совпадение, результат возвращается вам. Теперь вы можете написать несколько различных инструментов для этого, если хотите использовать это с агентом. Например, есть один инструмент, который будет «список контактов». Он вернет вам все 500 контактов. Затем, если вы подумаете об этом, скажем, каждый контакт — это 50 токенов, вы смотрите примерно на 25 000 токенов, тогда вы можете либо позволить агенту проходить через каждый из них токен за токеном, либо у вас может быть другой инструмент, который проходит через него токен за токеном, в конечном итоге вы заполните контекстное окно агента бесполезной информацией.
Вместо этого хороший подход — это инструмент, который ищет, используя традиционную настройку разработки программного обеспечения, и возвращает только очень небольшую подгруппу контактов, которые, по его мнению, имеют смысл. Это может быть просто простая система поиска, а затем вы передаете этот результат агенту, потому что агент ищет только один или два контакта.
Таким образом, когда вы проектируете инструменты, вы должны думать о том, как люди взаимодействуют с этими инструментами. Например, вы хотите иметь механизм поиска, а не просмотр, фильтрацию, а не сканирование, и навигацию, а не итерацию по элементам.
Вот еще несколько примеров. Вместо реализации «список пользователей», «список событий», «создать события» — три разных отдельных инструмента — рассмотрите возможность реализации «запланировать событие», которое находит доступность и планирует событие. И, по сути, вы оборачиваете несколько различных шагов в один инструмент. Другой пример: вместо реализации инструмента «чтение логов» рассмотрите возможность реализации инструмента «поиск», который возвращает только релевантные логи и некоторый окружающий текст. Опять же, поиск, а не сканирование.
Еще одна идея — это неймспейсинг ваших инструментов. То есть вы хотите группировать похожие инструменты вместе. Сейчас у нас есть дюжина MCP, к которым агент может иметь доступ, и каждый из них может реализовывать очень похожую функциональность. Теперь, если агент должен решить, какой инструмент выбрать, высока вероятность, что он запутается. Итак, вот очень простое представление. Допустим, есть ряд различных серверов MCP. Каждый из них реализует поиск, создание, обновление, удаление и так далее. Верно? Теперь, без группировки их вместе на основе сервера MCP, если они используют похожие имена, агент запутается. Однако, если вы сгруппируете их вместе, например, есть неймспейс для сообщений Slack, затем есть инструменты, специфичные для Jira, вы добавляете эти префиксы к каждому инструменту, это действительно поможет агенту определить, какой инструмент использовать для какой задачи.
У них есть очень интересное наблюдение. Похоже, есть разница, используете ли вы префикс или суффикс, когда речь идет об оценке использования инструментов агентом, верно? Поэтому, вероятно, стоит поэкспериментировать с обоими. Так что поместите неймспейс до или после имени инструмента и посмотрите, повлияет ли это на использование инструмента или производительность вызова инструмента. Таким образом, даже несмотря на то, что эти системы становятся все умнее и умнее, их могут сбить с толку эти очень мелкие нюансы.
Хорошо. Следующий шаблон — как вы думаете о возврате информации из инструмента? Итак, всякий раз, когда у вас есть вызов инструмента, вы получаете результаты. Что именно вы добавляете в эти результаты? Общая логика — добавить как можно больше информации, но это может обернуться против вас. Поэтому они говорят, что реализация инструмента должна быть направлена на возврат только высокосигнальной информации агенту, и вы хотите убедиться, что эта информация действительно имеет смысл. Поэтому вместо возврата низкоуровневых технических идентификаторов, таких как UUID, или, возможно, URL-адреса зашифрованного изображения, вы хотите возвращать поля, такие как имя, URL изображения, которые более описательны. В некоторых случаях эти низкоуровневые технические идентификаторы также могут быть полезны. Поэтому вы хотите возвращать структурированные выходные данные или структурированные форматы, в которых вы сохраняете как низкоуровневые, так и высокоуровневые детали. По их словам, агенты, как правило, справляются с именами, терминами и идентификаторами на естественном языке значительно успешнее, чем с криптографическими идентификаторами.
Еще один вопрос: следует ли возвращать в формате XML, JSON, Markdown? На данный момент это действительно зависит от того, как были обучены ваши модели. Claude, например, любит формат XML, и модели OpenAI также, как правило, любят XML. Они раньше были довольно хороши в JSON, верно? Поэтому вам действительно нужно посмотреть на используемую вами модель и на основе этого решить, каким будет формат ваших выходных данных.
Далее, вы хотите подумать об оптимизации ответа инструмента с точки зрения количества возвращаемых токенов. Опять же, управление контекстом будет иметь решающее значение. Поэтому оптимизация качества контекста важна, но так же важна и оптимизация количества контекста, возвращаемого инструментом в качестве ответа. Они предлагают для более длинного контекста, который будет возвращен, использовать постраничную разбивку, выбор диапазона или какой-либо механизм фильтрации или создания. По умолчанию код ограничивает ответы инструментов 25 000 токенами. Имейте в виду, что если вы собираетесь сделать, скажем, 12 вызовов инструмента для выполнения операции, это будет суммироваться. Поэтому вам нужно быть очень осторожным с тем, сколько информации вы действительно хотите вернуть. Один из способов — просто создавать ответы для этого. Есть несколько стратегий. Например, вы можете напрямую побуждать агентов использовать более эффективные с точки зрения токенов стратегии, такие как выполнение небольших и целенаправленных поисков вместо одного широкого поиска для задач извлечения знаний. Очень похоже на пример адресной книги, о котором мы говорили.
Наконец, промпт-инжиниринг для описания инструментов. Это та часть, которую, как я часто замечаю, люди игнорируют, но я думаю, что ей нужно гораздо больше внимания. Итак, идея заключается в том, что если агент собирается выбрать инструмент, он в основном будет смотреть на описание инструмента и на входные/выходные данные. Вам нужно внимательно следить за тем, что должен делать инструмент. Также правильно называйте входные переменные и выходные данные из инструмента вместе со спецификациями функциональности. Простой способ думать об этом — это если вы нанимаете нового стажера, какую информацию ему понадобится, предполагая, что он ничего не знает о вашей системе или вашей настройке, верно? Имея это в виду, вы также хотите предоставить специализированные форматы запросов, определение нишевой терминологии, взаимосвязь между базовыми ресурсами и сделать это явным. Идея состоит в том, чтобы избежать любой двусмысленности, где агенту придется делать какие-либо предположения. Это критически важно. Коммуникация — это ключ к действительно хорошей агентовской системе и провальной агентовской системе, которая путается в выборе инструментов.
Остальная часть статьи в основном посвящена тому, как улучшить эти инструменты с помощью агентов. Идея очень проста. Вы создаете первоначальную реализацию вашего инструмента. Затем вам нужно разработать реальные тестовые случаи для эволюции. Это критически важно, потому что очень часто я видел, что люди придумывают синтетические примеры, которые не имеют ничего общего с реальным сценарием использования. И это очень печально, потому что эти системы очень хорошо работают на этих синтетических эволюционных тестах, но когда дело доходит до реальных тестов, они терпят неудачу. И причина в том, что когда вы создаете эти наборы тестов или эволюционные наборы, вы на самом деле не улавливаете реальные сценарии использования.
Поэтому, если вы следуете всем рекомендациям, то если вы хотите итерировать по этим инструментам с агентом, вы хотите предоставить как можно больше информации. Это будет включать всю необходимую документацию. И идея будет заключаться в том, что вы создадите эволюционный набор, где вы сможете протестировать агента. Также вы хотите убедиться, что вы хотите протестировать его в сложных сценариях, где вы комбинируете несколько различных инструментов, вместо того, чтобы тестировать инструменты по отдельности. Например, вот слабая задача для теста. Если вы спросите инструмент или агента: «Запланируй встречу с человеком на следующей неделе», верно? Агент может просто выбрать этот один инструмент и запланировать встречу. Однако ваш тест должен выглядеть примерно так: «Запланируй встречу с Джейн на следующей неделе, чтобы обсудить наш последний, скажем, проект. Прикрепи заметки с нашей последней встречи по планированию проекта и зарезервируй конференц-зал». Сейчас это потребует от агента планирования, а затем выбора нескольких различных инструментов для выполнения этого плана. Это, вероятно, более реалистичный реальный тестовый случай, чем наличие очень простого примера выбора одного инструмента в вашем наборе данных для оценки. И снова это критически важно. Я видел много неудач, когда люди запускают простые эволюционные тесты во время создания своих систем, и эти системы терпят неудачу из-за сложности в реальном мире.
После этого у вас может быть агентный цикл. То есть, с учетом заданного набора эволюционных тестов, вы запускаете это в цикле. Вы собираете информацию, также вы смотрите на обратную связь, которую генерирует система, а затем вы используете эту обратную связь вместе с агентами для улучшения ваших инструментов. Основываясь на их внутренних тестах, они показывают, что если вы используете агента для улучшения вашего инструмента, вы можете добиться значительно лучшей производительности.
Дайте мне знать, если вы хотите, чтобы я создал более подробные видео о настройке оценки. Есть пара ноутбуков. Я помещу их в описание видео. Но я надеюсь, что это видео было вам полезно, и если вам нужна помощь в создании лучших систем, вы можете связаться со мной. Подробности будут в описании видео. В любом случае, я надеюсь, что это видео было вам полезно. Спасибо за просмотр, и, как всегда, до встречи в следующем.