В последние годы слово «AI-агент» стало встречаться очень часто. Сначала оно казалось просто модным словечком, однако, сталкиваясь с различными клиентскими средами, я пришёл к выводу, что требования к созданию рабочего агента, безопасно функционирующего в нашей среде, явно возрастают.
С учётом этого фона мы начали размышлять о том, чтобы реализовать Ops-агента как единый бэкенд-сервис для задач, связанных с текущей работой в области DevOps. В процессе разработки мы использовали помощь таких кодирующих агентов, как OpenAI Codex.
Но когда я действительно пытаюсь создать это, возникают вопросы.
"Как позволить принимать решения самостоятельно, но в каких пределах?" "Как остановиться, если произошла ошибка?" "Можно ли наблюдать за промежуточным процессом так, чтобы ему можно было доверять?"
Сначала это просто начиналось как «вопрос → вызов инструмента → ответ», но по мере усложнения фактических запросов следующая проблема повторялась.
- Проверка проходит хорошо, но действия не переходят естественно.
- Неясно, было ли промежуточное суждение или просто использовался предписанный рецепт
- Выход выглядит правдоподобно, но немного не соответствует результатам выполнения
- Трудно проанализировать причины только по логам, когда вы снова углубляетесь в ту же проблему
Эта статья является записью о текущей архитектуре и механизме, которые были упорядочены в ходе этих проб и ошибок, а также о том, почему они были спроектированы именно так.
Принципы, которые мы хотим соблюдать в разработке
Сначала мы четко определили принципы. Если принципы колеблются, реализация может показаться быстрой, но в конечном итоге только увеличивается количество переработок (рефакторинга).
- Запрет на хардкодинг домена в основное тело (runtime/flow/resolver)
- Управление действиями должно иметь приоритет над декларативной внешней формализацией контрактов/политик перед ветвлением кода
- Действие должно быть автономным, но только в рамках поручения
- Необходимо проверять/наблюдать не только результаты, но и процесс
Суть состоит в том, чтобы не противопоставлять «автономию» и «контроль». Автономия — это гибкость суждений, а контроль — это механизм, уменьшающий круг неудач.
Резюме архитектуры
Собранные паттерны реализации следующие:
LLM + Tools + State + Control + Guardrails
И механизм работы рассматривается по следующим четырем осям.
Динамический план + строгий проверка + Состояние перехода Контракт + наблюдение/ФидБэк
Состояние Переход основание исполнение(Система состояний)ДиаграммаЛям
1) Динамическое программирование: 'Что делать' не фиксируется
Запрос пользователя не всегда приходит идеально структурированным. Например, "Проверь статус развертывания в разработческой среде и примени меры" охватывает широкий спектр, начиная от проверки состояния до смягчающих мер.
Важно понимать, что не нужно жестко кодировать все этапы с самого начала. Вместо этого Планировщик смотрит на текущий запрос и контекст, чтобы создать план и выбрать необходимые возможности.
Тем не менее, если оставить “выбор любого” на выбор, это опасно, поэтому ограничения возможностей следует установить через каталог. То есть, это будет динамично, но не безгранично.
Например, вы можете выбрать исполнение из заранее подготовленного каталога, например, способности запрашивать kubernetes.
2) Строгая проверка: план должен быть отфильтрован перед выполнением
План не реализуется сразу после его появления. На этапе предварительной проверки проводятся проверки контракта.
Точки проверки примерно такие.
- Есть ли в списке допустимых возможностей?
- Не пропущены ли обязательные предварительные возможности?
- Соответствует ли стиль выполнения (цикл/рецепт/условие и т.д.) условиям договора?
- Может ли ссылка на аргумент быть интерпретирована?
Причина, почему этот этап важен, заключается в том, что это может изменить «сбой во время выполнения» на «отказ/коррекция перед выполнением». На самом деле, проблемы, такие как несуществующая возможность или отсутствующий обязательный аргумент, должны быть отсеяны на этом этапе, чтобы снизить затраты.
3) Контракт перехода состояния: указывает пошаговые ворота
Запрос не рассматривается как одноразовое выполнение, а обрабатывается как машина состояний.
Пример потока:
- запланированный
- предполетная проверка пройдена
- исполнение
- завершено / ожидает одобрения / неудача / отклонено
Ключевым моментом здесь является указание в контракте “когда можно перейти к следующему состоянию”. Особенно запросы, содержащие действия, могут не соответствовать ожиданиям пользователя, если они завершены только на основе наблюдения в режиме только для чтения.
Поэтому, занимаясь разработкой и тестированием, мы постепенно усиливаем такие контракты.
- Если есть аномальный сигнал и пользователь включил намерение принять меры, это должно побудить перепланировать ветку действия.
- Высокий риск меры переданы в состояние waiting_approval
- Немедленный отказ в случае ошибки проверки целостности информации о подтверждении
4) Наблюдение/Обратная связь: судя по результатам, слишком поздно
Для оптимизации сводного анализа по запросам необходимо обеспечить систему логирования и постоянно улучшать её в соответствии с обновлениями функций.
- request-analysis: путь перехода состояния, причины отказа, количество вызовов LLM и т. д.
- request-answer: окончательный ответ
Преимуществом этого метода является низкая стоимость и возможность быстрой диагностики причин во время эксплуатации. Недостатком является сложность полной репликации промежуточных стрим-событий.
Тем не менее, это вполне эффективно для текущей цели (анализ эффективности/качества). Особенно для быстрого анализа проблем необходимо быстро ответить на нижеследующие вопросы.
- Почему произошел отказ/неудача?
- На каком из возможностей это было заблокировано?
- Почему увеличилось количество вызовов LLM
- Совпадает ли окончательный ответ с результатом выполнения
Конфликтует ли "контрактная основа" с автономией?
Я задумался над этим вопросом и, начиная с конца, скажу, что конфликта нет. Скорее, они взаимодополняют друг друга.
- Автономия: какой сочетание возможностей выбрать, в каком порядке перепланировать
- Контракт: что запрещено/обязательно, какие переходы состояний разрешены
Без контракта автономность легко становится импровизацией. Без автономии контракт просто становится статическим рабочим процессом.
На практике я считаю, что «автономная оркестрация на контрактных гвардейских линиях» является наиболее сбалансированной структурой.
Кратко о текущем состоянии процесса
Положительные изменения:
- Стало возможным анализировать переходы состояния/причины отказа/количество вызовов
- Границы между read-only/approval/action стали более четкими
- Некоторые повторяющиеся циклы и ненужные вызовы были сокращены.
Осталось еще:
- В запросах типа “Пожалуйста, примите меры” необходимо повысить уровень выполнения до принятия мер.
- Необходимо обеспечить большую согласованность формата ответа (особенно в границах секций).
- Необходимо повысить универсальность цикла повторного планирования на основе контракта.
То есть, мы движемся от «работает» к «работает стабильно, как и ожидалось».
Заключение
Когда вы создаете агента, легко говорить только о производительности модели. Но в работающем агенте более важным является структурный достоверностьЯ так думаю.
- План должен быть гибким в зависимости от ситуации
- Исполнение должно быть предварительно проверено
- Переходы состояния должны контролироваться контрактом
- Результат должен быть наблюдаемым, а также и процесс
Агент Ops прошел следующие этапы с целью создания универсального агента.
- Фиксированная стадия сценария
Сначала мы сосредоточились на стабильном выполнении заранее определенного потока, ориентируясь на scenarioId/scenarioType. Преимуществом был прогнозируемый результат, а ограничением - низкая гибкость к новым запросам.
- Этап централизованного контроля по контракту
Далее мы начали явно управлять "что можно/нельзя сделать", прикрепляя к каталогу возможностей, предвключенной верификации, контрольной точке одобрения и контракту на ответ. На этом этапе надежность возросла, но все еще были случаи, когда план напоминал рецепт.
- Текущее: барьер + контрактная автономная оркестрация
В данный момент основой является динамическое планирование, и выполнение контролируется через строгую проверку и контракты на переход состояния (например: запланирован → проверен → выполняется → ожидает одобрения/завершено). Также мы постепенно совершенствуем цикл повторного планирования, отслеживая причины неудач и повторяющиеся паттерны через журналы наблюдений.
Ещё предстоит долгий путь. Тем не менее, я думаю, что мы на шаг ближе к «объяснимому исполнению», начиная с фиксированного сценария, проходя через контрактно-центричный контроль и переходя к нынешней модели с ограничениями + основанной на контрактах автономной оркестрации.
Хотя это ближе к непрерывному улучшению, чем к завершённости, мы прилагаем усилия для создания основы и планируем дальше проверять на том же принципе, постепенно и уверенно расширяясь.
Энди