Agent-Ops 0.4.0: ИИ предлагает, человек решает, программа исполняет

Привет! Я Сергей Житинский, основатель Git in Sky. Мы занимаемся эксплуатацией и технической поддержкой ИТ-инфраструктуры. Agent-Ops — проект открытой отраслевой методологии совместной работы инженеров и ИИ-агентов. Мы начали разрабатывать его весной этого года и сейчас выложили первый кандидат версии 0.4.0 на GitHub и GitVerse. Одновременно, на конференции IT Elements 2026 мы договорились о совместной работе с инженерами из 2х других компаний, они стали у нас maintainers. Поэтому сегодня Agent-Ops - это не инициатива только одной компании, а совместной работа нескольких. Надеюсь, количество единомышленников будет увеличиваться. Приглашаем контрибуторов развивать этот проект вместе с нами.

Я ожидаю масштабных изменений в ИТ-отрасли, поэтому решил лично заняться этой работой внутри Git in Sky, а наши подходы и предложения вынести на обсуждение профессионального сообщества. Меняется сама организация работы: кто исследует проблему, на каком основании предлагает решение, кто разрешает изменение и кто отвечает, если оно привело к аварии.

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

Почему понадобилась методология

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

Но между «агент убедительно объяснил проблему» и «мы можем безопасно выполнить его рекомендацию» остаётся несколько вопросов.

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

Добавим сюда возможность подбросить агенту вредоносную инструкцию через обрабатываемые данные. Риски AI-интеграций мы уже обсуждали в статье «ИИ взломали. Кто бы мог подумать?». Для эксплуатации следующий шаг — превратить общие требования безопасности в конкретный порядок работы.

Есть и вопрос эффективности. Если после быстрого ответа модели инженер час восстанавливает основания её вывода, экономия сомнительна. Если агент повторяет неудачные попытки, создаёт новые отчёты, но не приближает проверенный результат, активность растёт, а польза — нет.

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

Человек остаётся в цикле принятия решений

У инфраструктуры есть владельцы, обязательства перед заказчиком и последствия простоя. Ответственность за решение должны нести люди: менеджеры, владельцы сервисов, инженеры в пределах своих полномочий. Переложить её на модель словами «так посоветовал ИИ» невозможно.

В Agent-Ops человек задаёт цель, ограничения и критерии успеха, а затем принимает решение о конкретном изменении. Например, владелец сервиса определяет допустимость простоя, инженер оценивает технический план. Кто именно вправе утвердить действие, должно быть определено для проекта заранее.

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

Рекомендация агента не является разрешением на изменение инфраструктуры. Это центральная граница методологии.

Почему обычные программы здесь так важны

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

Для обработки зафиксированных данных полезен идеал чистой функции: одинаковые входы дают одинаковый результат. Можно повторить расчёт, проверить код, написать тест на граничный случай и установить, почему правило сработало.

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

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

Отсюда разделение работы:

• Детерминированный сборщик получает факты в разрешённых границах и записывает машиночитаемые результаты.

• Агент сопоставляет факты, формулирует проверяемые гипотезы и предлагает план.

• Уполномоченный человек рассматривает план и принимает решение.

• Отдельный детерминированный исполнитель применяет утверждённое изменение через обязательные проверки допуска. В текущей редакции его запускает инженер.

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

Восемь шагов от задачи до проверенного результата

Методология описывает полный цикл эксплуатационной работы.

Схема из Agent-Ops White Paper v0.4.0. Подготовка плана, его утверждение и исполнение — отдельные шаги.

1. Намерение. Формулируем, чего хотим добиться, для какого сервиса, с какими ограничениями и как будем проверять успех. «Разобраться с диском» для этого недостаточно.

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

3. Диагностика. Агент предлагает гипотезы. Для каждой указывает подтверждающие и противоречащие факты, недостающие данные и способ опровержения. Уверенность модели сама по себе ничего не доказывает.

4. План. Готовим конкретные действия, оценку воздействия, предусловия, проверку результата и откат либо компенсацию. Если действие необратимо, называем это прямо: обещание «при необходимости откатим» не возвращает удалённые данные.

5. Утверждение. Уполномоченный человек одобряет или отклоняет конкретный план. Решение сохраняется как проверяемая запись.

6. Контролируемое изменение. Отдельный исполнитель проверяет актуальность разрешения, цель и условия, выполняет только допущенные действия и записывает результат каждого из них.

7. Проверка. Сравниваем фактический результат с исходными критериями. Успешное завершение команды ещё не означает, что сервис восстановлен.

8. Извлечение уроков. На основании проверенного результата готовим улучшения инструкций, проверок и политик. Изменение самих правил тоже проходит управляемый процесс; это не разрешение агенту самостоятельно переписать свои ограничения.

Цикл допускает возврат за дополнительными данными или уточнением задачи. Такие возвраты — нормальная часть расследования, и их основания должны оставаться в истории работы.

Неизвестное нельзя превращать в норму

Один из принципов Agent-Ops записан коротко: unknown ≠ OK.

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

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

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

Та же граница действует для контекста: текст обращения, внешний документ или вывод другого агента поступает как данные. Он не получает права командовать исполнителем только потому, что внутри написано «игнорируй предыдущие ограничения».

Три вопроса, на которые процесс должен ответить отдельно

Одной последовательности шагов недостаточно. На каждом переходе необходимо понимать, что нам известно, кто разрешает продолжение и чем подтверждена корректность происходящего.

В методологии это названо тремя плоскостями.

Данные, полномочия и независимая проверка связаны, но каждое из этих оснований нужно подтвердить отдельно.

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

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

Плоскость независимой проверки проверяет происхождение и свежесть данных, соблюдение правил, полномочия и соответствие результата цели. В Agent-Ops эта контрольная роль называется Guardian.

Guardian не обязательно является ещё одним ИИ-агентом. Форматы, сроки действия, ограничения и другие однозначные условия проверяются программно. Агент может участвовать в оценке смысловой непротиворечивости, но не заменяет эти проверки. Контролёр не утверждает собственную работу и не получает права исполнителя.

Мы также разделяем техническую возможность, автономность и воздействие. Способность агента подготовить изменение ничего не говорит о его праве применить его. А короткая команда может затронуть весь сервис. Поэтому эти свойства нельзя свести к одному «уровню доверия к ИИ».

Пример: на диске осталось 8%

В white paper есть учебный сценарий быстрого заполнения диска. Приведённые числа иллюстрируют процесс; это не результаты внедрения и не универсальные пороги для любой инфраструктуры.

Пример из методологии: цель включает свободное место, сохранность данных и непрерывность работы сервиса.

Владелец задаёт цель: восстановить запас свободного места выше 20%, не удаляя рабочие данные и не прерывая работу сервиса.

Сборщик фиксирует 8% свободного места и рост логов. Агент связывает ситуацию с правилами ротации и недавним релизом. Но ещё неизвестно, кто отвечает за правило срока хранения. Процесс возвращается за подтверждением: агент не назначает владельца по собственному предположению.

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

Уполномоченный владелец утверждает эти два действия и их порядок. Инженер запускает детерминированного исполнителя, который применяет согласованный пакет. Если проверки допуска не проходят, выполнение останавливается.

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

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

Как начать и как понять, что это полезно

Начинать предлагаем с ограниченного пилота: определить сервис, владельцев и запреты, наладить проверяемый сбор фактов, описать проектный контекст и критерии результата.

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

Эффективность имеет смысл считать по результатам. Сколько времени прошло до подтверждённого восстановления? Сколько времени инженер потратил на проверку и переделки? Сколько стоили модель, инструменты и повторные попытки? Не выросла ли доля неподтверждённых выводов?

В Agent-Ops есть показатель стоимости на один принятый успешный результат. В затратах остаются и неудачные попытки. Труд людей учитывается явно — в деньгах по объявленной методике или отдельно в человеко-часах. Быстрый первый ответ ещё не доказывает экономию.

Что мы открываем в версии 0.4.0

Agent-Ops задуман как отраслевой проект, который смогут обсуждать и применять разные команды эксплуатации. Спецификация описывает роли, контракты и границы полномочий без обязательной привязки к продуктам той или иной компнии или поставщику модели. Она дополняет существующие практики IaC, наблюдаемости и управления ИТ-услугами.

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

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

Мы выложили проект для совместной разработки и проверки на разных эксплуатационных сценариях. Приглашаем контрибуторов: инженеров, архитекторов, руководителей поддержки и владельцев сервисов. Можно предложить правку через pull request, завести issue с замечанием, добавить эксплуатационный сценарий или помочь с машиночитаемыми схемами и проверками. Нам важно вместе выяснить, где правила недостаточны, где слишком сложны и какие отказы или границы ответственности мы упустили.

Материалы проекта:

• Сайт методологии Agent-Ops/

• GitHub

• GitVerse

• Мой Telegram-блог, где я освещаю весь процесс создания Agent-Ops и трансформации эксплуатации в Git in Sky: решения, эксперименты, ошибки и следующие шаги

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