Рост сложности задач делает инфраструктуру узким местом, что требует создания полноценной агентной среды выполнения
Разработчики получили полноценную агентную среду выполнения с поддержкой долгосрочных задач, ориентированных на результат, возможностью остановки и возобновления, управлением контекстом, наблюдаемостью и топологией событий (пользователь, агент, сессия, диапазон)
Видео-источник
Рост сложности задач делает инфраструктуру узким местом, что требует создания полноценной агентной среды выполнения
Связка 1
Начальное состояние: Возможности моделей растут экспоненциально, задачи становятся сложнее и длиннее (от минут до часов и дней), но инфраструктура не успевает, что делает её узким местом вместо интеллекта
Преобразование: Создание Cloud Managed Agents — платформы, объединяющей инфраструктуру (разрешения для инструментов, выполнение инструментов, автоматическое управление контекстом, контрольные точки и повторные попытки) с фундаментальными строительными блоками и платформой для наблюдения
Конечное состояние: Разработчики получили полноценную агентную среду выполнения с поддержкой долгосрочных задач, ориентированных на результат, возможностью остановки и возобновления, управлением контекстом, наблюдаемостью и топологией событий (пользователь, агент, сессия, диапазон)
Итак, мы все знакомы с тем, как наши возможности моделей растут экспоненциально. Но по мере роста этих возможностей увеличиваются и горизонты задач, и сложность работы, которую мы делегируем нашим агентам. Мы видим, что узким местом всё чаще становится инфраструктура, а не интеллект. Так, пару лет назад вы могли попросить Opus написать и протестировать один компонент.
Возможно, вы тестировали нестабильный набор тестов для отладки, и это занимало минуты, может быть, час сосредоточенной работы. Вы постоянно направляли его и исправляли, когда он сбивался с курса. Совсем недавно, с нашими новейшими моделями, мы видим, что люди запускают задачи на ночь, уходят, просыпаются на следующее утро и видят, что весь их линейный бэклог был решён агентом. В не столь отдалённом будущем мы можем увидеть, как агенты берут на себя работу, на которую исторически у команд уходили кварталы. Многоагентные скоординированные команды будут выполнять полный цикл M&A от начала до конца.
И по мере того, как задачи эволюционируют от промптов к часам и дням работы, нам нужна — нам нужна не просто обвязка для промптинга, а настоящая агентная среда выполнения.
Спикер 2. Верно. С управляемыми агентами одна из главных вещей, которую мы решили, — это надежность и безопасность. При долгосрочных задачах эти проблемы становятся гораздо более серьезными. У вас есть агент, который работает часами, неделями или днями, и он должен быть надежным. Также необходимо обеспечить безопасность.
Кроме того, становятся возможными новые режимы взаимодействия, когда агенты работают в течение длительного времени. Например, с чат-ботами взаимодействие происходит практически мгновенно при краткосрочных задачах. Для долгосрочных агентов требуется то, что мы называем задачами, ориентированными на результат. Вы даете агенту задачу и ожидаемый результат, например, критерии, указывающие на завершение. Также нам нужна возможность для агентов останавливаться и возобновлять работу в ходе длительного выполнения, возможно, чтобы задавать вопросы для уточнения своей работы.
Спикер 1. Как известно, остановка и возобновление — это самый человеческий паттерн взаимодействия, потому что нет ничего более человечного, чем прокрастинация.
Спикер 2. Верно.
Спикер 1. Итак, очевидно, что мы многого ожидаем от наших агентов. А это значит, что исторически мы перекладывали это бремя на вас, разработчиков. Мы также многого ожидали от вас. В исследовании, которое мы провели перед запуском Managed Agents, мы обнаружили, что разработчики серьезно сталкиваются с трудностями. Так, каждый третий испытывал проблемы с управлением контекстом.
Контекст в нужное время может быть невероятно мощным. Это знания, необходимые агенту для работы. Но контекст в неподходящее время может стать огромным отвлекающим фактором. Половина наших разработчиков указали, что проблемы с инфраструктурой являются их главным блокирующим фактором в продакшене. Это те самые проблемы, о которых говорил Лэнс: управление учетными данными, безопасность и доступ, поддержание участия человека в процессе.
И наконец, большинство наших пользователей говорят, что их агенты работают без формальной наблюдаемости. Эти агенты работают на основе прогностических моделей, случайных результатов, и это сильно отличается от традиционной разработки ПО прошлого. Как узнать, что ваш агент делает что-то хорошее, если он выдает случайные или вероятностные результаты? Итак, представляем Cloud Managed Agents. Мы создали эту платформу, которая объединяет инфраструктуру и инструментарий: разрешения для инструментов, выполнение инструментов, автоматическое управление контекстом, контрольные точки и повторные попытки — с фундаментальными строительными блоками (о которых Лэнс расскажет чуть позже). Это позволяет легко быстро составить настраиваемого агента. И наконец, мы дополнили это богатой платформой для наблюдения. Мы не хотим, чтобы эти агенты работали на "вибрациях". Вы должны иметь возможность точно понимать, что делает ваш агент и как его улучшить.
Спикер 2. Да, верно. И использование Managed Agents на самом деле очень просто. Ментальная модель в основном следующая.
Вы определяете агента. Агента можно рассматривать как конфигурацию. У него есть определенная модель, есть промпт, есть инструменты, есть навыки. Вы это настраиваете, а затем позволяете агенту использовать среду, которую вы можете настроить. Вы можете настроить сеть, пакеты, и именно здесь агент может, например, писать код.
А любое выполнение агента — это сессия. Сессии могут иметь ресурсы, например, репозитории, или что-то вроде результата (outcome), о котором мы поговорим позже. И эти сессии генерируют события, которые Джесс кратко осветит, и которые вы можете обрабатывать и использовать для понимания того, что делает агент.
Спикер 1. Итак, давайте разберем топологию событий. По мере того как агенты выполняют все более сложные задачи, типы событий, которые они генерируют, также становятся все более сложными. Поэтому мы разделили их на четыре широкие категории.
-
События пользователя: Вы управляете агентом. Вы направляете его. Вы прерываете его. Вы определяете критерии завершения.
-
События агента: Они сообщают, что делает агент, какие инструменты запускает, как сжимает свой контекст со временем, кому делегирует задачи.
-
События сессии: Они помогают отслеживать жизненный цикл вашей работы. Работает ли агент? Простаивает ли он? Ожидает ли ваших вводных?
-
События диапазона: Это более широкая инструментация, позволяющая группировать связанные события вместе.
Мы перейдем к примеру агента, которого мы создали. Мы назвали его PASCAL. Он работает с набором данных гипотетического продуктового магазина под названием Just In Time и создает богатую аналитику и инсайты за считанные минуты, используя предварительно загруженный контейнер с набором Python-пакетов. Вы можете видеть каждое событие в консоли и даже диагностировать поток событий после завершения.
Итак, мы проведем небольшую демонстрацию. Мы запускаем выполнение агента прямо сейчас. Вы можете видеть, что события обновляются в реальном времени в консоли, и консоль поддерживает единое окно, позволяющее анализировать конфигурацию агента, а также его среду, пока вы просматриваете сгенерированные события. Pascal начал работу. Он начинает выдавать результаты.
- Сначала он начинает с анализа продуктов. Мы узнаем, что бананы очень популярны.
- Второй результат, который он создаст, — это анализ покупателей. И мы узнаем, что воскресное утро — пиковое время для покупок.
- И наконец, мой любимый результат — это прогностическая модель, где он анализирует вероятность повторного заказа для одного клиента с учетом его демографического профиля.
Теперь, когда агент завершил выполнение, полный поток событий доступен в консоли, и мы можем проанализировать его производительность. Мы предлагаем отладочного агента в консоли, чтобы вы могли просмотреть поток событий, проанализировать узкие места, найти способы улучшить агента в будущем и принять рекомендуемые действия. Похоже, он выявил несколько узких мест, которые мы затем можем исправить прямо в коде.