Почему агент ломается не из-за модели, а из-за плохого контура

AI-агенты быстро выглядят впечатляюще в демо. Они читают задачу, вызывают инструменты, пишут код, открывают pull request или собирают отчёт. Но production-сценарии быстро показывают другую сторону: агент теряет контекст, делает лишние действия, повторяет ошибку, не понимает границы полномочий и оставляет команду без понятного лога.

Надёжность агента определяется не только качеством LLM. Модель — это один компонент. Вокруг неё нужен инженерный контур: входные ограничения, инструменты, память, наблюдаемость, политика действий, тесты и rollback. Без этого агент остаётся интерактивной игрушкой, которую страшно подпускать к инфраструктуре.

Для backend, DevOps и homelab-задач это особенно важно. Агент может работать с репозиторием, CI/CD, Kubernetes, облачными API, базами данных и секретами. Ошибка здесь стоит дороже, чем неправильный текст в чате.

Чёткая роль важнее длинного prompt

Первый принцип — агент должен иметь понятную роль. Не «помоги с проектом», а «проверь Terraform plan и найди рискованные изменения», «собери статью из RSS», «создай PR с обновлением зависимости», «проанализируй алерты Prometheus за последний час».

Чем уже роль, тем проще определить:

какие инструменты разрешены;
какие файлы можно читать;
какие действия требуют подтверждения;
что считается успешным результатом;
какие ошибки нужно вернуть человеку.

Большой системный prompt не заменяет границы. Если агенту доступны все инструменты и нет политики действий, он рано или поздно сделает слишком много.

Инструменты должны быть typed и ограниченными

Агент с доступом к shell — мощный, но опасный инструмент. Лучше давать специализированные actions: прочитать файл, выполнить тесты, получить статус deployment, создать issue, проверить diff. Чем уже инструмент, тем проще валидировать вход и логировать результат.

Хороший tool interface должен иметь:

явную схему параметров;
ограничение по путям и окружениям;
таймауты;
понятные ошибки;
dry-run там, где возможно;
аудит вызовов.

Если агент вызывает kubectl delete через общий shell, контролировать последствия сложно. Если он вызывает отдельный tool restartDeployment с namespace allowlist и подтверждением — риск ниже.

Контекст нужно собирать, а не надеяться на память

LLM не должна помнить критичные факты «примерно». Агенту нужен контекст, собранный из источников истины: репозиторий, документация, tickets, runbooks, метрики, состояние кластера. Причём контекст должен быть свежим и проверяемым.

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

Для RAG и памяти важно хранить provenance. Агент должен понимать, откуда взята информация, и уметь показать ссылку или файл. Иначе человек не сможет проверить решение.

Планирование и выполнение лучше разделять

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

понять задачу;
собрать контекст;
предложить план;
выполнить безопасные шаги;
запросить подтверждение для рискованных действий;
проверить результат;
отчитаться.

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

Наблюдаемость агента — это не лог чата

Чатовая история полезна, но недостаточна. Нужны структурированные события:

какая задача запущена;
какой агент и версия prompt использованы;
какие tools вызваны;
какие параметры переданы;
какие файлы изменены;
сколько стоили запросы;
где были ошибки;
какой итоговый артефакт создан.

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

Безопасная деградация лучше уверенной галлюцинации

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

Это особенно важно в автоматизации публикаций, деплоя и incident response. Лучше пропустить один запуск, чем опубликовать выдуманный материал или выполнить неверную команду в кластере.

Полезные механизмы:

confidence gates;
allowlist источников;
обязательная проверка build/test;
запрет на действия при грязном git status;
лимиты на количество попыток;
явный режим read-only.

Память должна быть управляемой

Долгосрочная память агента удобна, но опасна. Если агент запомнил неверное правило, он будет повторять ошибку. Если в память попал секрет, это уже инцидент.

Память должна иметь:

область видимости;
владельца;
срок жизни;
возможность удаления;
фильтрацию секретов;
механизм ревью важных фактов.

Для многих production-задач лучше хранить не свободный текст, а структурированные настройки: репозиторий, команды проверки, разрешённые ветки, формат отчёта, policy для инструментов.

Проверки должны быть частью workflow

Если агент пишет код, он должен запускать тесты. Если меняет инфраструктуру — plan и policy checks. Если публикует статью — build сайта. Если анализирует инцидент — прикладывать ссылки на метрики и логи.

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

Также важно проверять самих агентов: regression-наборы, тестовые задачи, golden files, оценка tool-calls. Prompt тоже является кодом и должен проходить ревью.

Практический вывод

Хороший AI-агент — это не самая умная модель с самым длинным prompt. Это управляемая система с ограниченными инструментами, явной ролью, свежим контекстом, проверками, наблюдаемостью и безопасной остановкой.

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