Signadot спонсировал этот пост.
Давайте на минутку будем честны сами с собой. Если вы посмотрите на циклы ажиотажа, вирусные демонстрации в Твиттере и астрономические оценки компаний-основателей, вы заметите явный пробел в сфере ИИ.
Мы невероятно рано, и наша инфраструктура нас подводит.
Хотя каждая SaaS-компания добавила боковую панель второго пилота в свой пользовательский интерфейс, настоящие автономные агенты встречаются редко. Я имею в виду программное обеспечение, которое надежно выполняет сложные и многоэтапные задачи без участия человека. Большинство агентов сегодня представляют собой внутренние инструменты, склеенные инженерами-энтузиастами для обобщения потоков Slack или запроса к базе данных SQL. Они живут в безопасной гавани внутреннего использования, где 20% отказов — это скорее неприятное раздражение, чем отток клиентов.
Почему эти агенты еще не работают с клиентами? Это не потому, что моделям не хватает интеллекта. Это потому, что нашим конвейерам доставки не хватает строгости. Превращение агента от классной демо-версии к надежности производственного уровня — это инженерный кошмар, который мало кто решил, поскольку традиционные конвейеры CI/CD просто не были предназначены для недетерминированного программного обеспечения.
Мы на собственном горьком опыте понимаем, что экспедиторы не являются проблемой ИИ. Это проблема системной инженерии. В частности, это проблема инфраструктуры тестирования.
Смерть «Подскажи и молись»
Весь последний год индустрия была одержима фреймворками, обещающими волшебство. Вы даете системе цель, а она решает все остальное. Это была эпоха «подскажи и молись».
Но, как показывают недавние дискуссии в инженерном сообществе, особенно содержательный разговор о 12-факторных агентах, производственная реальность скучно детерминистична. Разработчики, поставляющие надежные агенты, отказываются от идеи полной автономии. Вместо этого они создают надежные и детерминированные рабочие процессы, в которых большие языковые модели (LLM) рассматриваются как нечеткие вызовы функций, внедряемые в определенные точки воздействия.
Если убрать магию блок-бокса LLM, агент производственного уровня станет во многом напоминать обычный микросервис. Он имеет поток управления, состояние и зависимости. Чтобы быть полезным, ему необходимо взаимодействовать с миром.
Философия 12 факторов правильно утверждает, что вы должны владеть своим потоком управления. Вы не можете передать свой логический цикл вероятностной модели. Если вы это сделаете, вы получите систему, которая работает 80% времени и галлюцинирует себя в угол остальные 20%.
Итак, мы создаем агента как рабочий процесс. Мы рассматриваем LLM как компонент, а не как архитектора. Но как только мы остановимся на этой архитектуре, мы натолкнемся на стену, которую традиционная разработка программного обеспечения решила десять лет назад, но которую вновь открыл ИИ. Эта стена — интеграционное тестирование.
Ловушка Эвалов
Когда команды начинают тестировать агентов, они почти всегда начинают с оценок.
Оценки имеют решающее значение. Вам нужны системы для оценки результатов LLM на предмет релевантности, токсичности и галлюцинаций. Вам необходимо знать, не вызвали ли ваши быстрые изменения регресс в рассуждениях.
Однако в контексте поставки продукта оценки по сути представляют собой модульные тесты. Они проверяют логику узла, но не проверяют целостность графа.
В производственной среде ваш агент не болтает в пустоте. Это актерство. Это вызов инструментов. Он извлекает данные из CRM, обновляет билет в Jira или запускает развертывание через сервер MCP (Model Context Protocol).
Надежность вашего агента определяется не только тем, насколько хорошо он пишет текст или код. Он определяется тем, насколько последовательно он обрабатывает беспорядочные и структурированные данные, возвращаемые этими внешними зависимостями.
Кошмар интеграции
Вот тут-то и начинается головная боль при проектировании платформы.
Представьте, что у вас есть агент, предназначенный для устранения сбоев модулей Kubernetes. Чтобы протестировать этот агент, вы не можете просто отправить ему текстовую подсказку. Вам нужно поместить его в среду, где он сможет делать несколько вещей. Он должен вызвать API Kubernetes или сервер MCP, который его обертывает. Он должен получить полезную нагрузку JSON, описывающую CrashLoopBackOff. Он должен проанализировать эту полезную нагрузку. Он должен решить проверить журналы. Наконец, он должен вызвать службу журналов.
Если структура этой полезной нагрузки JSON изменится, или если задержка службы журнала резко увеличится, или если сервер MCP вернет немного другую схему ошибок, ваш агент может выйти из строя. У него может появиться галлюцинация о решении, потому что входной контекст не соответствует обучающим примерам.
Чтобы проверить это надежно, вам необходимо интеграционное тестирование. Но интеграционное тестирование агентов значительно сложнее, чем стандартное веб-приложение.
Почему традиционное тестирование дает «хвост»
При традиционной разработке программного обеспечения мы имитируем зависимости. Мы отключаем базу данных и сторонние API.
Но для агентов LLM данные представляют собой поток управления. Если вы имитируете ответ сервера MCP, вы передаете LLM идеальный и очищенный сценарий. Вы испытываете счастливый путь. Но LLM наиболее опасны на несчастном пути.
Вам необходимо знать, как агент реагирует, когда сервер MCP возвращает ошибку 500, пустой список или схему с отсутствующими полями. Если вы высмеиваете эти взаимодействия, вы пишете тест для прохождения, а не для поиска ошибок. Вы не проверяете способность агента рассуждать. Вы проверяете свою способность писать моки.
Альтернативой макетированию обычно является полноценная промежуточная среда, в которой вы запускаете агент, серверы MCP, базы данных и очереди сообщений.
Но в современной архитектуре микросервисов создание дублирующего стека для каждого запроса на включение непомерно дорого и медленно. Вы не можете ждать 45 минут для полной подготовки среды только для того, чтобы проверить, правильно ли настройка системного приглашения обрабатывает ошибку базы данных.
Потребность в эфемерных песочницах
Чтобы выпускать агенты промышленного уровня, нам необходимо переосмыслить наш конвейер CI/CD. Нам нужна инфраструктура, которая позволит нам проводить высокоточное интеграционное тестирование на ранних этапах жизненного цикла разработки программного обеспечения.
Нам нужны эфемерные песочницы.
Инженер платформы должен предоставить разработчику ИИ возможность создать легкую изолированную среду, которая содержит:
- Версия тестируемого агента.
- От конкретных серверов MCP и микросервисов это зависит.
- Доступ к реальным (или реалистичным) хранилищам данных.
Важно отметить, что нам не нужно дублировать всю платформу. Нам нужна система, которая позволит нам разворачивать измененные компоненты, одновременно разумно маршрутизируя трафик к общим и стабильным базовым показателям для остальной части стека.
Такой подход решает проблему точности данных. Агент взаимодействует с реальными серверами MCP, использующими реальную логику. Если сервер MCP возвращает сложный объект JSON, агент должен его принять. Если агент выполняет вызов, изменяющий состояние, например модуль перезапуска, он фактически обращается к службе или ее изолированной версии. Это гарантирует замыкание петли.
Это единственный способ убедиться в работоспособности рабочего процесса.
Сдвиг влево в отношении агентной надежности
Будущее агентов ИИ — это не просто лучшие модели. Это лучше DevOps.
Если мы признаем, что производственные агенты — это просто программное обеспечение с нечеткой логикой, мы должны признать, что они требуют такой же строгости при интеграционном тестировании, как платежный шлюз или система управления полетами.
Мы движемся к миру, где агент — это всего лишь один микросервис в кластере Kubernetes. Он обменивается данными через MCP с другими службами. Задача разработчиков платформ — дать разработчикам уверенность в возможности объединения кода.
Эта уверенность не возникает из-за зеленой галочки при быстрой оценке. Это происходит благодаря наблюдению за тем, как агент перемещается по живой среде, запрашивает работающий сервер MCP и успешно выполняет рабочий процесс.
Заключение
Создание агента — самая простая часть. Создание стека для надежного тестирования агента — это то, где битва выиграна или проиграна.
По мере того, как мы переходим от внутренних игрушек и контролируемых демонстраций к продуктам, ориентированным на клиента, победят те команды, которые смогут быстро выполнять итерации, не ломая ничего. Это будут команды, которые откажутся от идеи «подсказывать и молиться» и вместо этого будут обеспечивать производственную точность при проверке запросов на извлечение (PR). Для этого требуется определенный тип инфраструктуры, ориентированный на изоляцию на уровне запросов и среды временного тестирования, которые изначально работают в Kubernetes.
Устранение этого инфраструктурного пробела — наша основная миссия в Signadot. Мы позволяем командам платформы создавать облегченные песочницы для тестирования агентов на предмет реальных зависимостей без сложных сред. Если вы совершенствуете архитектуру своих рабочих процессов ИИ, вы можете узнать больше об этом шаблоне тестирования на сайте Signadot.com.
Signadot — это собственная платформа Kubernetes для тестирования микросервисов. Используя Signadot, команды разработчиков «смещают влево» тестирование, чтобы выявить проблемы раньше и повысить уверенность в выпуске. Узнайте больше Последние новости от Signadot ТЕНДЕНЦИОННЫЕ ИСТОРИИ YOUTUBE.COM/THENEWSTACK Технологии развиваются быстро, не пропустите ни одной серии. Подпишитесь на наш канал YouTube, чтобы смотреть все наши подкасты, интервью, демонстрации и многое другое. ПОДПИСАТЬСЯ Группа, созданная в Sketch. Арджун Айер, генеральный директор Signadot, — опытный эксперт в области облачных технологий, страстно желающий улучшить опыт разработчиков. Обладая более чем 25-летним опытом работы в отрасли, Арджун имеет богатую историю разработки программного обеспечения для Интернет-масштабов и… Подробнее от Арджуна Айера
