Пять компонентов создания «корпоративного каркаса»

Как создать корпоративный каркас?

Мы создали внутренних агентов в LangChain для отделов маркетинга, продаж и разработки, и они полностью изменили то, как работают эти команды. Настроить их было непросто. Мы потратили много времени на решение проблем, связанных с многопользовательским каркасом, и каждая команда пришла к одним и тем же базовым примитивам:

• Он работает там, где люди уже привыкли трудиться (для нас это Slack)
• Он знает, кто задает вопрос, и действует от имени этого человека для одних сервисов и под собственной учетной записью для других
• У него есть память с глобальной областью видимости и/или на уровне пользователя
• Код выполняется в изолированной среде (песочнице) и может отправлять запросы к сервисам, требующим аутентификации
• Большой процент запусков происходит по расписанию, а не по явному запросу пользователя (фоновые агенты!)

Спасибо @caspar_br за помощь в подготовке этого блога

Внутренние агенты LangChain

Для контекста приведем краткий обзор трех основных агентов, используемых в LangChain:

GTM-агент: проактивный, постоянно работающий агент, который помогает в деятельности по выходу на рынок (GTM). Он отслеживает электронные письма и отвечает на них, обрабатывает новые квалифицированные лиды, отправляет ежедневные сводки, может отвечать на вопросы об учетных записях и запускать исходящие кампании

OpenSWE: наш инженерный агент, который может работать над запросами на слияние (PR) и создавать их черновики, а также проводить код-ревью всех PR

Content Studio: наш маркетинговый агент, который может создавать материалы (блоги, изображения, презентации PowerPoint, видео) в нашем стиле и с учетом нашего позиционирования

Все эти агенты созданы по единому принципу. Мы считаем это универсальным рецептом создания корпоративных каркасов.

Проблема: Пользовательский опыт

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

Удобным нововведением стала концепция «ответвления» разговора в Slack. Часто бывает так, что идет отличная беседа, и вы хотите подключить агента, чтобы узнать его мнение или поручить ему какое-то дело. Но если бы он работал прямо в этой ветке, это замусорило бы человеческое общение и отвлекло бы внимание. Поэтому мы добавили простой способ для агентов создавать «ответвления» в виде собственной ветки на канале.

Существуют сценарии взаимодействия, которые лучше НЕ реализовывать в Slack. Например, когда GTM-агент проверяет письма, которые я хочу отправить, это вполне удобно делать в виде разовой задачи в Slack, но если накапливается большой объем, отслеживать их через сообщения в Slack становится крайне утомительно. Для таких задач мы в итоге создали специализированный пользовательский интерфейс.

Проблема: Идентичность

Самой сложной и запутанной задачей, с которой мы столкнулись, стала проблема идентичности, а именно: когда эти агенты совершают действия, от чьего имени они их выполняют?

В индустрии существует два основных подхода к ее решению:

• От имени пользователя: агент действует от имени пользователя, который его вызывает
• Фиксированные учетные данные: существует фиксированный набор учетных данных, который агент использует независимо от того, кто его вызывает (например, служебная учетная запись)

Вот как мы подошли к этому для каждого агента (документация: Add identity to Managed Deep Agents, Manage connections):

OpenSWE:

• Когда вы пишете ему, он действует от вашего имени (например, открывает PR с вашим дескриптором GitHub)
• Когда он работает в фоновом режиме (например, в качестве агента для код-ревью), он использует собственную учетную запись (приложение GitHub)

GTM-агент:

• У него есть инструменты (например, доступ к Salesforce), где он использует фиксированную учетную запись, чтобы не заставлять авторизоваться каждого пользователя
• У него есть инструменты (например, электронная почта), где он действует от имени пользователя, вызвавшего агента. Эти инструменты доступны ТОЛЬКО в личных сообщениях. В общих каналах они недоступны

Content Studio:

• У него есть инструменты (например, Notion), где он действует от имени вызвавшего его пользователя
• У него есть инструменты (например, Twitter), где он использует фиксированный набор учетных данных — в данном случае для аккаунта нашей компании в Twitter. При этом определенные операции здесь могут вызывать только пользователи из белого списка. Например, не каждый может публиковать записи в Twitter (им может быть доступно только чтение или создание черновиков)

Проблема: Память

У всех агентов есть два уровня памяти:

• Глобальная память: память, которая применяется ко всем пользователям
• Память пользователя: память, которая относится только к конкретному пользователю

Агенты сами решают, какие факты они хотят запомнить и на каком уровне памяти.

Это, пожалуй, наименее изученная область на данный момент — нам предстоит проделать здесь огромную работу!

Проблема: Выполнение кода

Все три наших агента умеют писать и выполнять код, и часто это необходимо для решения задач. Все они работают по принципу запуска вне изолированной среды с последующим подключением к ней и выполнением кода внутри. У них немного различаются базовые образы с разными зависимостями. OpenSWE (агент, наиболее тесно связанный с написанием кода) разумно подходит к выбору базового образа для запуска (он отличается в зависимости от канала или пользователя). Все они используют прокси секретов в LangSmith Sandboxes (см. также Add a sandbox to Managed Deep Agents), что позволяет агенту безопасно подключаться к сервисам прямо из изолированной среды.

Проблема: Запуски по расписанию

Большой процент запусков планируется заранее или инициируется в фоновом режиме событиями, а не запускается пользователем напрямую.

Некоторые из них настраиваются разработчиком агента. Например: OpenSWE отслеживает появление PR, и когда создается новый, он проводит его ревью.

Другие настраиваются самим пользователем путем отправки соответствующего запроса агенту. Например: я попросил GTM-агента присылать мне ежедневную сводку, и он создал собственный планировщик (cron) для этой задачи.

Все создано на базе Managed Deep Agents

Все эти агенты построены на базе Managed Deep Agents, которая работает поверх каркаса с открытым исходным кодом Deep Agents. Она предоставляет инфраструктуру для решения всех этих задач (каналы, планировщики cron, изолированные среды, память, идентичность) и при этом обладает достаточной гибкостью для настройки поведения агентов по мере необходимости. Оцените ее в деле с помощью краткого руководства!