Forter удалось привлечь около 200 человек к созданию ИИ-агентов в ходе двухнедельного практического спринта после того, как компания спроектировала среду, снижающую потребность в навыках программирования и позволяющую аналитикам и инженерам быстро проверять свои идеи. Ben Maraney, ведущий инженер компании, представляет этот опыт как урок по устранению ненужной сложности вместо попытки одновременно решить все задачи создания агентов.
Начало: практический спринт с пятинедельным сроком
Целью было обучить команды исследований и разработок создавать собственных агентов, включая аналитиков с юридическим, психологическим и научным образованием, некоторые из которых ранее никогда не писали SQL. Команде требовалось подготовить среду за пять недель, а затем провести двухнедельный спринт создания. Поэтому проектирование сосредоточили на трех направлениях: инструментах, платформах и устранении пользовательских барьеров.
Центральный MCP-сервер вместо разрозненных инструментов
Forter использовала внутренний сервер на базе протокола MCP, названный Toolchain. Сервер предоставлял единый интерфейс для обнаружения и тестирования инструментов, а также создания подключений для каждого агента. Он также позволял пользователю выбирать только необходимые агенту инструменты вместо предоставления широкого доступа, который мог бы запутать его или привести к использованию неподходящих инструментов.
Количество инструментов выросло примерно с 20 при создании команды до почти 60 к началу спринта, а затем примерно до 100 через две недели после его завершения. Унификация репозитория и наличие понятных примеров и конфигурационных файлов помогли быстро добавлять новые инструменты, одновременно обеспечивая возможности управления, такие как мониторинг потребления токенов и использования инструментов.
Вместо того чтобы за короткий срок создавать специализированную систему дополненной поиском генерации (RAG), компания подключила Toolchain к платформе Glean, использовавшейся для поиска во внутренних источниках, таких как Confluence, Asana, Jira, Slack и Salesforce. Были предоставлены три типа инструментов: поиск релевантных документов и фрагментов, чтение документа целиком и его суммирование по вопросу или теме, заданным агентом.
От платформы без программирования до настраиваемых решений
Forter использовала LibreChat, чтобы предоставить быстрый интерфейс с минимальным объемом программирования. Пользователи могли видеть инструменты, вызванные агентом, отправленные им запросы и параметры, а также полученные результаты. Это помогало понимать поведение агентов и рано обнаруживать проблемы, хотя интеграция MCP иногда была нестабильной, а возможности управления версиями и настройки были ограничены.
Для более сложных случаев компания предоставила шаблонные репозитории, дававшие разработчикам полный контроль над кодом, добавлением инструментов и дочерних агентов, однако их настройка и развертывание занимали больше времени, особенно для аналитиков. Позднее Forter создала внутренний интерфейс под названием AI Hub, позволявший выбрать модель, написать системное сообщение, определить инструменты, а затем поделиться агентом всего за несколько шагов.
Для неинтерактивных агентов использовалась платформа Strands вместе с Argo Workflows, чтобы запускать их по расписанию или в ответ на такие события, как создание тикетов в Jira и Asana. Maraney отмечает, что наличие уже работающей системы планирования и исполнения может устранить необходимость в новой специализированной инфраструктуре для агентов.
Что было создано на практике?
Среди вариантов использования были агенты, помогающие аналитикам формулировать более качественные гипотезы и эксперименты, проверяющие отчеты по итогам инцидентов и анализирующие снижение эффективности продавцов с использованием Snowflake и ноутбуков Databricks. Компания также разработала специализированных агентов, таких как Layla и Penny, для доступа к коду, конфигурациям и данным и ответов на вопросы, связанные с решениями по транзакциям и выставлению счетов. Использование Layla распространилось на команды по работе с клиентами и поддержки после того, как ее знания о системе стали шире, чем знания любого отдельного сотрудника.
Примерами неинтерактивных агентов были предложение первоначальных настроек для нового продавца на основе похожих продавцов, подготовка предварительных исследований при поступлении тикета поддержки, а также анализ уведомлений об аномалиях и их сопоставление с изменениями в коде. Forter также протестировала агента для реагирования на инциденты, но обнаружила, что его внешне превосходные результаты в основном зависели от копирования анализа первопричины, ранее написанного людьми в отчетах BetterNext.
Что меняется на практике?
Этот опыт показывает, что наблюдаемость не является второстепенной функцией. Отображение инструментов, параметров и результатов, на которые опирается агент, было необходимо, чтобы обнаружить: агент реагирования на инциденты фактически не выводил первопричину. Поэтому позднее Forter добавила Langfuse для отслеживания сеансов агентов, вызовов инструментов и рабочего процесса.
Опыт также показывает, что использование нескольких платформ может быть намеренным: платформы без программирования для быстрых экспериментов, программные решения для настройки и агенты, работающие по событиям или расписанию. При этом компания столкнулась с проблемами модели, при которой для каждого агента создавался отдельный репозиторий, и вернулась к меньшему количеству репозиториев, включающих связанных агентов, чтобы упростить внедрение общих возможностей, таких как трассировка.
Maraney также предупреждает, что общие показатели оценки, такие как релевантность, связность и безопасность, могут создавать ложное впечатление качества. Полезная оценка должна проверять правильность ответа, использование подходящих инструментов и извлечение правильного контекста; это более сложные задачи, требующие точного понимания того, что означает хороший ответ. Поэтому в рамках внутренних экспериментов, где человек остается частью процесса принятия решений, продвинутые оценки можно отложить, однако не следует считать это постоянной заменой оценке.
Инициативы по масштабированию также требуют раннего привлечения юридических команд и специалистов по безопасности, особенно по вопросам места обработки и хранения данных. Maraney отмечает, что использование облачного сервиса, такого как Amazon Bedrock, вместе с документированием политик отказа от хранения данных помогло решать эти вопросы в рамках корпоративных ограничений, вместо того чтобы превращать каждого агента в отдельный случай согласования.