теория
Механика обманчиво проста, но в ней три роли — и путать их нельзя.
Схема — контракт. Каждый инструмент описывается формально: имя, параметры с типами, короткое описание — что делает и когда его звать. Это единственное, что модель видит: не код, не базу, только описание. По сути это API-контракт, у которого появился новый тип потребителя — недетерминированный.
Модель — выбиратель. Получив вопрос «где заказ 9315?», модель не лезет в базу. Она возвращает намерение: «вызовите getOrderStatus с параметром 9315». Это называется : модель заполняет форму, а не совершает действие.
Код — исполнитель. Оркестратор — обычный детерминированный код — получает намерение, валидирует параметры (номер заказа существует? клиент имеет к нему отношение?), исполняет настоящую функцию и возвращает результат модели. Модель продолжает рассуждать уже со свежими фактами.
Так крутится цикл : рассуждение → действие → наблюдение → снова рассуждение. Заметь, где проходит граница: модель никогда не трогает систему сама. Всё, что она может, — попросить; всё, что исполняется, проходит через код, который валидирует и решает. Значит, поверхность возможного вреда определяется не «умом» модели, а списком инструментов и строгостью исполнителя — то есть архитектурой.
Отсюда два правила. Первое: — агенту дают ровно те инструменты, без которых его задача не решается, а не «всё, вдруг пригодится». Второе: чем волатильнее и интимнее знание, тем уже инструмент. «Статус заказа по номеру» переживёт три миграции базы; «выполни SQL» не переживёт ни одной.
Сплошные линии — инструменты-контракты: узко, валидируемо, переживает миграции. Пунктир — отвергнутый путь: вся схема базы в голове у модели.