Что такое Governed Agent Runtime и какую проблему он решает
Governed Agent Runtime - среда исполнения, в которой языковая модель выбирает следующий шаг, а допустимость и выполнение операций контролирует детерминированный runtime. Модель предлагает действие, runtime проверяет, допустимо ли оно в текущем состоянии, и только потом меняет систему. Такой контур описан в разборе на Habr на примере локальной Qwen3.8:27b и синтетического платёжного сервиса.
Подключить агента к инструментам - лишь часть задачи. Сложнее организовать работу там, где уверенного ответа модели недостаточно: нужно соблюдать ограничения, контролировать действия и проверять последствия. Типичный вопрос из этого класса: агент предлагает восстановить деградировавший сервис, и кто-то должен проверить, выдержит ли инфраструктура переключение трафика, выполнены ли все необходимые условия и действительно ли сервис восстановился. В разобранной схеме на все три вопроса отвечает код, а не текст модели.
Главный вывод кейса неудобен для тех, кто читает рассуждения модели как отчёт о работе: корректное действие не гарантирует достоверного объяснения. Агент прошёл многошаговый сценарий, включая безопасную остановку при неудачной проверке восстановления, но в численных пояснениях ошибался.
Три роли: модель, runtime, человек
| Роль | Что делает | Чего не делает |
|---|---|---|
| Модель (Qwen3.8:27b) | Предлагает следующий шаг и пояснение к нему | Не исполняет операции и не решает, допустимы ли они |
| Детерминированный runtime | Проверяет допустимость, исполняет операцию, проверяет последствия | Не придумывает шаги и не достраивает контекст за модель |
| Человек-подтверждающий | Подтверждает изменяющие операции | Не заменяет проверки runtime |
Локальная модель усиливает аргумент в пользу такой схемы: контур не зависит от внешнего API, но и дополнительного доверия к тексту модели не появляется. Контроль держится на детерминированных проверках, которые можно перечитать в коде и воспроизвести в логах.
Почему уверенный ответ модели - плохая точка контроля
Подробная спецификация наперёд создаёт ощущение контроля над агентом: кажется, что достаточно описать всё детально, и модель пойдёт по букве. На практике агент всё равно выполняет не все инструкции, а часть выполняет слишком буквально - об этом прямо сказано в разборе паттерна «спецификация наперёд». Тот же разрыв виден в пояснениях: текст выглядит уверенно и при этом содержит неверные числа.
Практический вывод: проверять нужно операции и их последствия, а не текст объяснения. Объяснение полезно человеку, который принимает решение, но точкой контроля оно быть не может.
Эксперимент на синтетическом платёжном сервисе: что именно проверялось
Все эксперименты шли на синтетическом платёжном сервисе. Область работы начиналась с отдельных предложений и позже расширилась до многошагового исполнения, о чём сказано в исходном описании кейса. Деталь важна для оценки результатов: среда модельная, реальный трафик по ней не шёл.
Какие данные видит агент и runtime
Среда имитирует платёжный сервис и содержит:
- версии сервиса и их количество;
- состояние реплик: Ready, Healthy, Degraded;
- нагрузку сервиса и её распределение между версиями в RPS;
- метрики зависимостей и признаки деградации;
- ограничения мощности, отказоустойчивости N-1 и контракты доступности.
Каждое из этих полей годится как основание для проверки. Если критерий ссылается на данные, которых во входном контексте нет, он превращается в догадку. В разделе про evaluator это станет главной причиной переработки оценки.
Сценарий восстановления: масштабирование, переключение трафика, проверка
Задача одна: вернуть в норму деградировавшую версию сервиса. Последовательность шагов и проверок вокруг них:
- Масштабирование. До добавления ёмкости runtime сверяет предложение с ограничениями мощности и текущим состоянием реплик.
- Переключение трафика. Проверяются распределение RPS и способность выдержать смену направления нагрузки с учётом отказоустойчивости N-1.
- Проверка восстановления. После изменяющей операции runtime смотрит фактические метрики и состояние реплик, а не пояснение модели.
Изменяющие операции подтверждает человек. Подтверждение снимает вопрос «делать ли», но не отменяет проверки «можно ли» и «сработало ли».
Как детерминированный runtime проверяет шаги агента
Проверки делятся на два класса: до операции и после неё. Граница между ними отделяет намерение от результата, и путать их нельзя.
Проверки до операции: допустимость и предусловия
До исполнения runtime отвечает на три вопроса. Допустима ли операция в текущем состоянии сервиса? Соблюдены ли ограничения мощности и N-1? Не нарушает ли шаг контракты доступности? Если предложение модели не проходит хотя бы одну проверку, оно отклоняется: скажем, переключение трафика не выполняется, когда предусловия не выполнены. Пороги для этих проверок задаёт инженер в коде, а не модель в тексте.
Проверки после операции и безопасная остановка
После изменяющей операции runtime сверяет фактические метрики до и после. Проверка восстановления не прошла - исполнение останавливается безопасно, и цепочка не едет дальше по инерции. В кейсе многошаговое исполнение прошло успешно именно вместе с такой остановкой: это штатный исход, а не сбой.
Без пост-проверок агент продолжает рассуждать на устаревшей картине мира. Обратная сторона видна в лабораторном кейсе, где агент без прав на запись работал с HubSpot, а downstream-узел n8n всё равно выполнил PATCH и изменил не тот объект: разбор runtime-контроля на n8n, DeepSeek и HubSpot показывает, почему граница исполнения должна быть детерминированной.
Почему правильное действие не гарантирует достоверного объяснения
В кейсе модель допускала ошибки в численных пояснениях. На корректность действий это не влияло: исполнялись проверенные операции, а не текст о них. Результат верный, комментарий к результату - нет.
Где именно ошибалась Qwen3.8:27b
Источник фиксирует класс ошибки без конкретных значений: неверные числа в пояснениях при корректных шагах. Причина в том, что пояснение - отдельный генеративный акт. Runtime исполняет операцию, а не описание операции, и проверяет метрики, а не абзац вокруг них. В интерфейсе это выглядит так: шаг выполнен, рядом фактические значения из runtime, ниже абзац модели с числами, которые с этими значениями не сходятся. Читатель, доверяющий абзацу, получает неверную картину при верном результате.
Смежный класс сбоев у моделей Qwen описан отдельно: после вызова инструмента Qwen Flash Next иногда выдаёт reasoning-блок, будто задачи не было, и упоминает только системные инструкции - разбор симптомов и плана диагностики. Другая модель и другой симптом, но вывод совпадает: текст модели в момент tool call требует проверки, а не доверия.
Как отделять объяснение от факта в логах и отчётах
Правило простое: источник истины - данные runtime, текст модели - приложение с явной пометкой. Запись на каждый шаг стоит собирать из пяти частей:
- предложенный шаг и его аргументы;
- вердикт проверки до операции: пропущен или отклонён, с причиной;
- фактические метрики до и после: RPS, состояние реплик, метрики зависимостей;
- кто из людей подтвердил изменяющую операцию;
- пояснение модели отдельным полем с пометкой «сгенерировано, не проверено».
В постмортеме такая структура экономит часы: причина ищется в метриках и вердиктах, а не в пересказе событий.
Evaluation Traceability Gate: как пересобрать оценку агента
Отдельная часть работы касалась системы оценки: часть критериев evaluator не имела основания во входном контексте. Пришлось ввести механизм Evaluation Traceability Gate и пересмотреть оценку результатов, о чём сказано в описании работы.
Критерий без основания: как это ломает оценку
Если критерий ссылается на данные, которых в контексте нет, evaluator заполняет пробел догадкой. Оценка выглядит правдоподобно и при этом не воспроизводима: повторный прогон даёт другой балл по тому же поведению, а разбираться приходится не с агентом, а с критерием. Симптом тот же, что и с пояснениями модели: уверенный текст без опоры на факты.
Как устроен гейт трассируемости на практике
- Инвентаризация критериев: выписать все, включая унаследованные.
- Привязка к полю: каждый критерий получает ссылку на конкретное поле входного контекста - состояние реплик, RPS, ограничения N-1, контракты доступности.
- Отбраковка или переформулировка: критерий без опоры удаляется либо переписывается под данные, которые действительно есть.
- Повторный прогон оценки и сравнение с прежними результатами.
- Закрепление в спецификации оценки, чтобы новые критерии не появлялись без трассировки.
После этого оценка перестаёт быть мнением второй LLM и становится проверяемой. Тот же принцип лежит в основе паттерна с агентом-скептиком, воспроизводимыми тестами и трассировкой рассуждений, разобранного на проектах хакатона Anthropic.
Спецификации вместо иллюзии контроля: SDD, core specs и bounded changes
Разработка велась на основе спецификаций (SDD): базовая архитектура и логика runtime выстроены на core specs, развитие шло через bounded changes - ограниченные изменения с уточнением спецификаций, когда это требовалось.
Минимальный набор разделов спецификации
Исчерпывающая спецификация не спасает от произвола модели. Рабочая рекомендация из практики агентной разработки: ограничить спецификацию тем, без чего агент не начнёт - цель, ограничения, критерии готовности и что точно не входит в задачу.
Каждый раздел превращается в конкретную проверку:
- Цель задаёт формулировку задачи, от которой отталкиваются и runtime, и человек.
- Ограничения становятся проверками до операции: мощность, N-1, контракты доступности.
- Критерии готовности становятся пост-проверками: сервис действительно восстановлен.
- Что не входит в задачу работает стоп-листом для предложений, которые формально выглядят полезными.
Bounded changes: как менять систему, не теряя контроль
Bounded changes задают темп развития: изменение ограниченного объёма, при необходимости с уточнением спецификации. Поменялся критерий оценки - заново проверяется его трассировка. Появилось новое поле в контексте - возникает основание для нового критерия. Это процесс, а не разовая настройка перед запуском.
Ограничения подхода и что проверить перед переносом на реальную инфраструктуру
- Среда синтетическая. Платёжный сервис имитируется, реального трафика и настоящих зависимостей в кейсе не было.
- Одна модель. Использовалась локальная Qwen3.8:27b: другая модель даст другую частоту ошибок в пояснениях и другие предложения шагов.
- Один сценарий. Многошаговое исполнение проверено на восстановлении деградировавшей версии: масштабирование, переключение трафика, проверка восстановления.
Перед переносом стоит проверить три вещи: полноту входного контекста для каждого критерия, поведение при частичных отказах (метрики не пришли, подтверждение зависло, проверка вернула неопределённость) и нагрузку на человека-подтверждающего, чтобы подтверждения не превратились в формальность. Цена подхода - дисциплина в спецификациях и оценке, и платят её до первого инцидента.
Практический чек-лист: как собрать свой Governed Agent Runtime
- Тонкий сквозной срез. Проведите одну задачу от предложения модели до проверки последствий. Признак готовности: срез можно запустить и потрогать, неопределённость снята ранним прототипом, а не документом на двадцать страниц - этот приём описан в том же разборе паттернов.
- Минимальная спецификация: цель, ограничения, критерии готовности, что не входит в задачу. Признак: каждый пункт превращается в проверку runtime или в критерий evaluator.
- Проверки до операции. Признак: недопустимое предложение отклоняется, а причина отклонения попадает в лог.
- Проверки после операции и безопасная остановка. Признак: провал проверки останавливает цепочку, а не запускает следующий шаг.
- Подтверждение человеком для изменяющих операций. Признак: в записи шага видно, кто подтвердил и когда.
- Evaluator с трассировкой критериев. Признак: у каждого критерия есть поле входного контекста, на которое он опирается.
- Разделение фактов и пояснений в логах. Признак: метрики runtime и текст модели лежат в разных полях, и второе помечено как сгенерированное.
Контур собирается и на локальной модели: Qwen3.8:27b в этом кейсе справилась с последовательностью шагов, а слабое место нашлось в объяснениях и в критериях оценки. Контроль строится на разделении ответственности между моделью, runtime и человеком, а не на доверии к объяснениям. Проверяйте операции и последствия, а текст оставляйте человеку как комментарий, не как доказательство.