Моше Самбол, вице-президент по решению задач клиентов в Lightrun – Интервью

Моше Самбол, вице-президент по решению задач клиентов в Lightrun, имеет более двух десятилетий опыта в области разработки программного обеспечения, архитектуры, облачной инфраструктуры и технического лидерства, ориентированного на клиентов. До того, как присоединиться к Lightrun в 2022 году, он провел почти десятилетие в Google, где занимал различные руководящие должности, включая менеджера по инженерии облачного клиента, помогая организациям принять и масштабировать технологии Google Cloud. Ранее в своей карьере Самбол занимал инженерные и руководящие должности в Oracle, Sun Microsystems, BMC Software и JPMorgan Chase. В Lightrun он первоначально возглавлял глобальную инженерию решений, а затем стал вице-президентом по решению задач клиентов, где он фокусируется на помощи клиентам в принятии технологии Runtime Insights компании и переводе ее возможностей в измеримые бизнес- и разработческие выгоды.

Lightrun – это платформа инженерной надежности, основанная на ИИ, предназначенная для предоставления разработчикам и агентам ИИ прямой видимости того, как программное обеспечение работает во время его выполнения. Ее технология может динамически захватывать журналы, снимки, метрики, трассировки, значения переменных и контекст выполнения из живых приложений без необходимости изменений в коде или повторных развертываний. Компания все больше расширяет эту информацию о времени выполнения до ИИ-ассистированной разработки программного обеспечения через Lightrun MCP, которая использует Протокол контекста модели для предоставления помощников по кодированию и инструментов агентов с живым контекстом приложения, а не полагаясь исключительно на статический исходный код. Это позволяет системам ИИ исследовать проблемы производства, проверять гипотезы против фактического поведения выполнения и поддерживать анализ коренной причины, включая корпоративные контроли, такие как роль-ориентированный доступ и редактирование конфиденциальных данных.

Ваша карьера охватывает разработку программного обеспечения и архитектуру, облачную инженерию клиентов в Google, глобальную инженерию решений и сейчас решение задач клиентов в Lightrun. Как это сочетание построения программного обеспечения и прямой работы с клиентами предприятий сформировало ваше понимание того, что отличает впечатляющую демонстрацию агента ИИ от системы, которую можно доверять в производстве?

Большая разница между демонстрацией того, что может сделать агент ИИ, и доказательством того, что он может быть доверен в среде предприятия. Это связано с тем, что агенты являются только частью системы, готовой к производству. Фреймворк вокруг него столь же важен. Он должен обеспечивать доступ с минимальными привилегиями, контролировать активность, сохранять аудиторский след, предотвращать неприемлемо рискованные действия и привлекать человека, когда это необходимо.

Системы агентов фундаментально отличаются от традиционного программного обеспечения, поскольку разработчики не указывают точно, как система будет работать. Мы устанавливаем цель, предоставляем инструменты и руководство, и модель определяет, как продолжить. Эта гибкость мощна, но она также делает поведение системы труднее предсказать.

Для предприятий, особенно тех, которые находятся в регулируемых отраслях, производственные рабочие процессы, которые обычно работают или занимают непредсказуемое количество времени для завершения, являются неприемлемыми. Производственные среды содержат конфиденциальные данные, исходный код и интеллектуальную собственность, поэтому организации должны быть в состоянии предотвратить раскрытие этой информации агентами или принятие творческих, но неприемлемых путей для достижения своих целей. Это становится все более важным, поскольку каждая неделя приносит новый пример системы ИИ, которая, стремясь достичь цели, оказывается уязвимой для или вызывает уязвимость безопасности.

Большинство лидеров, с которыми я говорю, все еще оценивают агентов так же, как они оценивали бы нового сотрудника: по способностям, суждению и результатам. Реальный вопрос не в том, достаточно ли умён агент. Это в том, может ли система вокруг него поймать и сдержать моменты, когда он не является таковым.

Многие предприятия первоначально считали, что построение агента ИИ было в основном вопросом написания эффективного запроса. Что организации неправильно понимали об инженерных, архитектурных и эксплуатационных требованиях к агентам, готовым к производству?

Я думаю, что самое большое недоразумение было почти наивной верой в силу ИИ решить любую задачу, если только ему дать хорошо написанный запрос, актуальный контекст и подходящие инструменты. Команды подключали свой LLM к коду, документации, тикетам и исторической телеметрии, а затем ожидали, что он найдет правильное решение.

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

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

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

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

Это указывает на более фундаментальный сдвиг, и это то, о чем мы постоянно говорим в Lightrun, помогая клиентам строить агентные автоматизации для своих инженерных организаций. Командам нужно перестроить сам поток агента и поставить ворота на действия агента, чтобы обеспечить, что его использование инструментов подвергается надзору, аудиту и рассмотрению. Предоставление агенту сильной обратной связи – включая живую наблюдаемость во время выполнения – фокусирует его контекст на том, что происходит прямо сейчас. Этот доступ позволяет агенту проверить свои собственные решения по проектированию, анализ коренной причины и рекомендации по смягчению ошибок против производственной реальности, а не против предположений, основанных на статическом анализе кода или старой телеметрии.

Драматическая перестройка не является единственным вариантом. Что можно сделать инкрементально, и это не является революционным, но это важно, – это инвестиции в навыки, которые руководят поведением агента. Тщательно разработанные и оцененные навыки толкают агента в сторону детерминированного рабочего процесса. Командам не нужно перестраивать всю систему, чтобы получить эту выгоду. Им нужно относиться к проектированию навыков с той же строгостью, которую они бы дали любой другой части логики производства.

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

Контролируемые тесты удаляют большинство изменчивости, которые будут определять производственную реальность, с которой ИИ должен столкнуться. Данные отбираются, поведение инструментов предсказуемо, разрешения известны, и мы покрываем путь, который мы предвидели. Когда вы выпускаете агента, чтобы он взаимодействовал с реальными пользователями и их эффектами в живых системах, вы не сравниваете подобное с подобным.

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

Опасная часть заключается в том, что агент может продолжать казаться работающим правильно, производя неправильные, но правдоподобные ответы, построенные на частичных данных или на предположениях, основанных на устаревшей информации. Это почему производственные агенты нуждаются в непрерывной оценке, которая продолжает работать после запуска, явном xửлении отсутствующих данных и инструментальных сбоев, а также живой верификации решения перед его завершением.

Lightrun уделяет значительное внимание предоставлению системам ИИ доступа к контексту выполнения. Какую информацию предоставляет контекст выполнения, которую могут пропустить традиционные журналы, метрики и трассировки, и почему эта информация особенно важна для диагностики неисправностей агентов?

Традиционная наблюдаемость показывает внешние симптомы поведения системы, часто агрегированные, отобранные или отфильтрованные через панели управления и оповещения, которые срабатывают на порогах. Они обычно зависят от решений, принятых разработчиками в момент написания кода: какая информация будет интересна в будущем? Что стоит логировать или измерять? Контекст выполнения отделяет видимость от этой необходимости знать заранее, что может быть интересно, и предоставляет подробные данные, показывающие, что происходит под капотом, и как мы туда попали.

Настоящая разница заключается в статических и динамических данных. Традиционные журналы, метрики и трассировки статичны и производят исторический отчет о том, что произошло. Контекст выполнения Lightrun динамичен. Он дает агенту возможность вставить новую инструментацию в работающий код, по требованию, и наблюдать точные значения переменных, аргументы функций, состояние объекта, стек вызовов или условия ветвления, когда они происходят.

Эта разница особенно важна для диагностики неисправностей в коде, сгенерированном агентом, поскольку они часто бессимптомны. Агент может выбрать неправильный инструмент, передать неправильный аргумент или действовать на основе устаревшего предположения и все равно выполнить свою задачу без срабатывания каких-либо ошибок. Неисправность такого типа не будет показана в статической телеметрии, поскольку никто не знал заранее, что нужно инструментировать для этого. Неожиданное поведение требует динамического расследования непосредственно на работающей системе, размещая новую инструментацию точно там, где модель агента мира отклонилась от реальности, а не полагаясь на то, что уже было записано.

Это то, что делает динамический контекст выполнения естественным слоем верификации для решений ИИ в инженерии.

Как Протокол контекста модели (MCP) и подобные слои интеграции могут позволить агентам кодирования учиться на реальном поведении выполнения без предоставления им чрезмерного или небезопасного доступа к производственным системам?

MCP и другие контролируемые доступы к внешним инструментам (например, обертки CLI) позволяют агенту вызвать конкретную, ограниченную возможность, а не предоставляют ему широкий доступ к системе и доверяют ему, чтобы он вел себя правильно. Агент, подключенный через сервер MCP для контекста выполнения, может запросить только чтение доказательств, значение переменной, путь вызова, превышение порога, без доступа к записи, без возможности повторного развертывания и без необходимости постоянных учетных данных для основной среды.

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

Вы не можете прикрепить эти части независимо, поскольку каждая из них меняет другие. Лучшие места для начала – это фреймворк, упряжка, которая контролирует цикл агента, и общая оркестрация рабочего процесса, которая связывает вместе несколько агентов и других участников. Например, для рабочего процесса анализа коренной причины команды должны решить, какое доказательство требуется, какие системы агент может осмотреть, может ли он опубликовать вывод или только черновик, когда человек должен одобрить следующий шаг, и что происходит, если доказательство из времени выполнения недоступно.

Как только этот контракт ясен, упряжка и фреймворк предоставляют механизмы, с помощью которых можно обеспечить соблюдение этих руководящих принципов. Шлюзы MCP можно использовать для ограничения доступа агента к конкретным возможностям, соответствующим его цели. Инструменты можно предоставить с минимальными привилегиями. Память можно контролировать, с чувствительными данными, редактированными детерминированно. Извлечение можно спроектировать вокруг доказательств, необходимых для рабочего процесса.

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

Какие меры предосторожности должны окружать агентов, которые могут осматривать живые приложения или участвовать в рабочих процессах инженерии надежности сайта, особенно в регулируемых средах, где контроли доступа, конфиденциальность, аудитность и операционная стабильность являются критическими?

Это был один из центральных вопросов проектирования, когда мы построили Lightrun AI SRE. AI SRE работает рядом с некоторыми из самых чувствительных систем в организации, поэтому мы спроектировали его как привилегированного операционного участника, а не чат-ассистента. Одним из важных решений было разделение плоскости осмотра и плоскости действия. AI SRE собирает доказательства через интеграции только для чтения и инструментацию времени выполнения Lightrun, с доступом, ограниченным идентификатором, арендатором, сервисом и средой. Он может осматривать живое выполнение и генерировать отсутствующие доказательства, но слой осмотра времени выполнения не может изменить состояние приложения.

В регулируемой среде эта граница должна быть поддержана RBAC, SSO, изоляцией арендатора, редактированием ПИИ, контролями хранения и записью аудита, показывающей, какие инструменты и доказательства поддержали каждый вывод. Нам также нужны операционные ограничения вокруг того, сколько данных можно собрать, как часто можно запросить время выполнения и какие действия требуют одобрения. Если доказательства отсутствуют или вывод не может быть проверен, AI SRE должен сказать об этом и передать решение человеку, а не действовать так, как если бы он знал больше, чем он знает. Цель – контролируемая автономия: достаточно полезная, чтобы ускорить расследование, но ограниченная достаточно, чтобы остаться безопасной для живой системы.

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

Я бы оценил готовность к производству по частоте, с которой действия агента ИИ производят желаемые результаты, его выводы выдерживают проверку на то, что было фактически истинным в производстве, выводы, не поддержанные доказательствами, пойманы до действия, и агент видимо и безопасно терпит неудачу, когда доказательства отсутствуют. Для агентов инженерии проверенная точность результата, покрытие доказательств, время подтверждения коренной причины, успешная скорость отступления и пост-действенные результаты являются основными метриками, на которые мы должны фокусироваться.

В течение следующих нескольких лет я ожидаю, что агенты будут брать на себя больше сбора доказательств и первого прохода расследования, а также надзора за агентными рабочими процессами и непрерывного обучения из опыта и обратной связи, в то время как инженеры устанавливают политику, решают неоднозначность, одобряют высокорисковые действия и направляют самосовершенствующиеся агентные системы. Доверие будет расширять рабочий процесс за рабочим процессом. Агенты, которые могут отслеживать свои выводы обратно к живым доказательствам и четко раскрывать, что они не смогли проверить, заработают большую автономию. Те, которые не могут, останутся ограниченными узкими, низкорисковыми задачами, независимо от того, насколько они звучат плавно.

Спасибо за отличное интервью, читатели, которые хотят узнать больше, должны посетить Lightrun.