Представители компании Resolve на лекции Stanford CS229 представили концепцию и архитектуру ИИ-агентов, способных выполнять сложную аналитическую работу инженеров по обеспечению доступности сервисов (SRE) и разработчиков. Спикеры Спирос, Бхарат и Габор продемонстрировали эволюцию систем автоматизации от простых изолированных запросов к языковым моделям до распределенных мультиагентных комплексов. В центре внимания лекции — практические подходы к проектированию автономных систем, проблемы эффективного управления контекстом и фундаментальные ограничения современных технологий искусственного интеллекта.
🚀 От мониторинга к автономии: Демонстрация ИИ-инженера Resolve 0:05
Развитие систем искусственного интеллекта в области разработки программного обеспечения стремительно переходит от автодополнения строк кода к созданию полноценных автономных инженеров. Как отметил Спирос, реальное программирование в индустрии включает в себя не только написание кода, но и поддержание крупных масштабируемых систем в рабочем состоянии. Практический опыт команды показывает, что в крупных ИТ-организациях инженеры тратят подавляющую часть своего времени на обслуживание существующей кодовой базы и обеспечение надежности инфраструктуры, а не на создание новых функций. При этом пользователи мгновенно реагируют на недоступность сервиса, в то время как небольшие задержки релизов обычно остаются незамеченными.
Современный технический стек инженера перегружен разнородными интерфейсами: от облачных платформ (AWS, Google Cloud) до сложных систем телеметрии и мониторинга (Datadog, Splunk). В традиционной схеме человек вынужден выступать в роли «клея», вручную перенося данные между этими утилитами для решения конкретной задачи. Платформа Resolve предлагает ИИ-альтернативу, переводящую человека на уровень стратегического контроля над группой автономных агентов.
В рамках практической демонстрации Спирос передал системе высокоуровневую жалобу пользователей: «Этим утром интерфейс работает медленно». На основе этой неконкретной директивы ИИ-агент самостоятельно выполнил комплекс действий:
- Идентифицировал целевой фронтенд-сервис в динамической облачной среде.
- Изучил метрики, логи и события в Kubernetes, Datadog и Slack.
- Обнаружил аномальные всплески задержек и временный поток ошибок при поиске продуктов.
По запросу о поиске первопричины (root cause) агент установил, что деградация была вызвана намеренно запущенным Cron-заданием в рамках хаос-инженерии. В более сложном сценарии агент работал полностью в фоновом режиме, самостоятельно формируя пул гипотез и проверяя логи через специализированные поисковые запросы к системе Loki. По итогам анализа ИИ сгенерировал точные команды для отключения дефектного флага функции (feature flag). Подобная система способна интегрироваться непосредственно в Slack, перехватывать алерты PagerDuty, локализовать неэффективные SQL-запросы (например, проблему N+1) и предлагать готовый патч для кодовой базы.
По словам Спироса, данный процесс полностью автоматизирован. Тем не менее, из-за склонности современных моделей уходить в непредсказуемое русло, разработчики Resolve жестко ограничивают фазу планирования ИИ с помощью программных guardrails (ограничителей).
📊 Лестница сложности: От простого LLM-запроса до агента 16:46
Бхарат сформулировал фундаментальный принцип проектирования интеллектуальных систем: «Сохраняйте простоту, поскольку далеко не каждая задача требует мультиагентной архитектуры». В условиях реального производства простейшее работающее решение всегда является экономически оптимальным. Чтобы наглядно показать технологические границы, Бхарат детально разобрал эволюцию подходов на примере ликвидации сбоя в платежном шлюзе.
Нижняя ступень эволюции — однократный изолированный запрос к большой языковой модели (Single Pass). В этом сценарии дежурный инженер в 2 часа ночи собирает около 1000 строк логов из PagerDuty и отправляет их в LLM с вопросом о причинах падения транзакций. Модель сканирует текст, находит строку card expired и указывает на просроченную карту. Ограничения подхода очевидны:
- Отсутствие внутренних циклов обратной связи и механизмов самопроверки.
- Высокий риск принять случайный шум за истину (ИИ игнорирует тот факт, что 80% платежей падают из-за скрытого сетевого таймаута).
- Полное отсутствие у модели концепции собственной неуверенности.
Вторая ступень — архитектура «Актер-Критик» (Actor-Critic), добавляющая в систему петлю обратной связи. Модель-актер предлагает гипотезу, а модель-критик оценивает ее на основе системного промпта. Если Актер заявляет о просроченной карте, Критик возражает, что единичные истекшие карты не могут объяснить массовый отказ платежей по всей системе. Актер корректирует ответ, признавая аномалию. Однако система все еще заперта внутри тех данных, которые пользователь передал изначально.
Третья ступень — использование внешних инструментов (Tool Use). Инструментом для ИИ выступает любая внешняя программная функция: калькулятор, API базы данных или поисковый интерфейс. Через структурированное описание параметров в JSON-формате модель получает протокол взаимодействия со средой. В этом случае пользователю достаточно написать: «Платежи падают, разберись». Модель сама конструирует сложный синтаксис запроса к Loki, извлекает логи и точечно диагностирует проблемы на стороне Stripe. Минус подхода — реактивность ИИ; модель лишь отвечает на текущие результаты выполнения инструментов, но не имеет глобального плана действий.
Полноценный автономный ИИ-агент формируется тогда, когда к использованию инструментов добавляется долгосрочный цикл планирования, рефлексия, память и внутреннее целеполагание. Такой агент декомпозирует сложную директиву на подзадачи и стратегически двигается к результату, корректируя план при программных ошибках.
🧠 Архитектура мультиагентных систем и распределенное программирование 38:15
При масштабировании задач одиночный агент сталкивается с непреодолимыми барьерами: хрупкостью длинных планов, перегрузкой доступными инструментами и стремительным исчерпанием окна контекста. Габор предложил проводить прямую аналогию между ИИ-архитектурой и классической программной инженерией: «Если представить агента как функцию или сервис, то мультиагентная система — это полноценная программа или распределенная система».
Разделение обязанностей между специализированными узлами (один агент глубоко сфокусирован на логах, второй — на дашбордах, третий — на коде) устраняет проблему «централизованного бутылочного горлышка». Габор выделил три базовых паттерна межагентского взаимодействия:
- Scatter-Gather (аналог MapReduce): Управляющий узел параллельно запускает подзадачи для сбора улик со всех систем мониторинга, агрегирует ответы и формирует итоговое резюме для пользователя.
- Orchestrator Loops: Динамический цикл, в рамках которого оркестратор вызывает конкретных субагентов, анализирует их результаты и на их основе решает, кого из специалистов задействовать на следующем шаге.
- Free-for-all (Актерная модель): Свободный обмен сообщениями в общей среде, где агенты хаотично и напрямую передают задачи друг другу по мере необходимости.
Ключевой вызов при проектировании таких комплексов — управление общим контекстом (Multi-agent context). Направление всей истории разработки (глобальный контекст) каждому агенту гарантирует сохранность деталей, но мгновенно забивает память модели гигантскими объемами нерелевантных технических данных. Полная изоляция субагентов по принципу RPC (модель видит исключительно точечный входящий запрос) упрощает локальную отладку, но требует от оркестратора идеального и исчерпывающего описания задачи. По мнению Габора, наиболее перспективным является подход «стека вызовов» (Call Stack), при котором агент видит только цепочку вышестоящих запросов, приведших к его активации.
🔄 Обучение агентов и эволюция промпт-инжиниринга 1:02:28
Важнейший аспект эксплуатации ИИ-инженеров — их способность извлекать уроки из совершенных ошибок. По своей природе большие языковые модели функциональны и статичны: при фиксированной температуре на один и тот же инпут они возвращают идентичный аутпут, что неприемлемо при повторении инцидентов в продакшене. Если ИИ некорректно интерпретировал сетевой алерт, у разработчиков есть два пути оптимизации его поведения:
- Дообучение (Post-training / SFT / RL): Прямое изменение весов базовой модели путем ее тренировки на новых специфических датасетах. Этот классический ML-подход гарантирует высокую стабильность реакций, но обходится дорого с точки зрения GPU-ресурсов и сопряжен с риском «катастрофического забывания» — веса могут сдвинуться так, что модель улучшит работу с инфраструктурой, но потеряет общие логические навыки или способность писать качественные тексты.
- Использование динамической памяти (Memory): Накопление знаний во внешней базе данных, откуда релевантная информация о прошлых инцидентах динамически подмешивается в контекст промпта при обнаружении похожих паттернов. Метод дешев, гибок и не привязан к конкретной архитектуре нейросети, однако он жестко лимитирован размером окна контекста и способностью модели точно следовать абстрактным текстовым инструкциям.
Габор констатировал, что современный промпт-инжиниринг все еще находится в зачаточном состоянии и напоминает «черную магию». Тем не менее, индустрия постепенно переходит к строгой инженерной дисциплине, напоминающей feature-инжиниринг в традиционном машинном обучении, внедряя воспроизводимые циклы тестирования изменений промптов на фиксированных тестовых наборах данных.
🔮 Будущее ИИ-разработки: Ограничения и новые барьеры 1:09:45
Несмотря на непрерывный выход обновлений (прямо в день лекции состоялся релиз GPT-5 с расширенным окном контекста), разработчики продолжают сталкиваться с фундаментальными ограничениями архитектуры трансформеров. Механизм внимания обладает квадратичной сложностью, из-за чего реальная когнитивная глубина моделей при обработке сверхдлинных контекстов неуклонно падает. Модели по-прежнему не умеют рефлексировать над уровнем собственной уверенности и склонны уверенно транслировать ошибочные выводы.
Серьезным барьером является и то, что текущие инженерные инструменты изначально создавались под физический интерфейс человека. У них низкая пропускная способность и часто отсутствуют API, что вынуждает использовать неэффективные технологии эмуляции действий пользователя (Computer Use). Спирос спрогнозировал масштабный инфраструктурный сдвиг: человеческие утилиты мониторинга неизбежно будут вытеснены специализированными агентскими интерфейсами, оптимизированными под параллельную проверку сотен гипотез на сверхвысоких скоростях.
В конечном итоге профессия инженера поднимется на более высокий уровень абстракции. По мнению авторов, знание конкретного синтаксиса языков программирования и особенностей инструментов отойдет на второй план, уступив место системному мышлению, долгосрочному планированию архитектур и развитию продуктового вкуса. На смену написанию кода придет управление выравниванием (alignment) ИИ, а естественный язык из-за своей структурной двусмысленности уступит место строгим протоколам межагентского взаимодействия.
