Как контролировать работу AI агентов

Как контролировать то, что делают ваши ИИ-агенты? Простой вопрос от Alexander Kos, на который нет простого ответа.

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

Для бытового уровня — бытовое решение. Ключевой тезис: разделите постановку и исполнение задач. Это не только упрощает управление, но и на порядок повышает контроль и безопасность.

Что? Разбираемся. Вспомните любые понятия вроде shared state, agent memory или second brain — их тысячи. Не важен конкретный термин, важна общая парадигма: ваш проект должен быть разложен в это общее состояние. Всё, над чем могут работать агенты, должно лежать там.

С текстом это тривиально, с базами данных — нет. Но я расскажу сам принцип.

Рассмотрим два слоя: агенты, которые работают над проектом локально, и агенты, которые общаются с внешним миром.

1. Локальные агенты.

Простой лайфхак: поместите весь проект под git, если ещё не сделали. Любое изменение любых файлов будет видно банальным `git diff`. Агент что-то сделал? Смотрите дифф. Нужно сообщить об изменении другому агенту? Скажите ему посмотреть дифф. Хотите понять, что агенты наворотили за день? Попросите Claude посмотреть дифф за сутки и выдать человеческий отчёт.

Хотите +1 уровень проверки? Сделайте агента-контролёра. Выставите ему требования, «чего не должно происходить в проекте», и пусть он смотрит дифф и шлёт вам алерты.

Хотите ещё +1 уровень? Прикрутите настоящие автотесты. Решать вам, но фундамент — версионирование всех проектных данных под гитом.

2. Агенты, работающие с внешним миром.

Напомню disclaimer — идеального решения нет. Поэтому рассказываю средне-прикладное.

Разделите постановку задачи и её исполнение. Для простых случаев вроде «погугли в интернете» это избыточно, но для задач класса «выстави счёт контрагенту X через банк-клиент» — критично.

Настройте так, чтобы сначала один скилл создавал md-файл в каталоге, например, `inputs/`. В нём — постановка задачи в простом текстовом формате: кому, сумма, валюта, за какую услугу. По факту создания — коммит в гит. Никаких реальных операций в реальном мире. Не давайте этому агенту никаких кредов и доступов.

И только затем запускайте второй, отдельный скилл. Он подхватывает файлик из `inputs/`, выполняет операцию во внешнем мире, складывает результат в другой файл в `outputs/` и тоже коммитит в гит.

Технически их лучше развязать в разные проекты, чтобы доступы и креды физически видел только второй агент. Никакого левого контекста, никакой лишней информации. Он видит строго один файл и делает строго одну операцию. Откуда она взялась — не его собачье дело. Прочесть чувствительную информацию о проекте он не может — она в другом каталоге под другим linux-юзером. Испортить входящий файл — тоже, он ридонли.

Уже из основного проекта вы можете вычитывать результат — хоть агентом, хоть скриптом с фильтрацией от prompt injection. Это уже тема для отдельного разговора.

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

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