Инвариантное проектирование: как балансировать между гибкостью и ограничениями ИИ-агентов

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

В этой статье рассматривается концепция инвариантного проектирования. Это метод настройки баланса между фиксированными инвариантами и свободным поведением модели. На примерах реальных сервисов, таких как Claude Code, разберем, как определять границы ответственности ИИ и программной оболочки, чтобы агент оставался полезным и при этом работал корректно.

 Больше об AI-агентах и внедрениях нейросетей рассказываю с своем Telegram-канале ДругОпенсурса. Заходите, чтобы читать свежие новости и разборы инструментов в числе первых.

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

Пример

Рассмотрим пример ИИ для страховой компании. При регистрации ДТП агент должен собрать данные в строгом порядке: номер полиса, дата происшествия, описание повреждений. Этот процесс фиксирован на 80%. Свободным может быть только то, как агент отвечает на уточняющие вопросы клиента между основными этапами.

Если просто поместить список вопросов в один промпт, модель может пропустить пункт или перепутать их местами. Чтобы этого избежать, последовательность действий должна контролироваться программной оболочкой. Процесс описывается как конечный автомат, который выдает модели только один текущий вопрос. Роль языковой модели сводится к тому, чтобы извлечь структурированную информацию из текста пользователя. Модель не решает, что спрашивать дальше, этим занимается система.

В техподдержке, где нужно диагностировать поломку интернета, заранее прописанного сценария быть не может. Здесь агент должен сам искать решение, изучать базу знаний и адаптироваться. Но и тут нужны инварианты, только другого уровня. Например, можно установить правило: агент обязан сначала провести поиск по документации и только потом предлагать решение. Это структурное ограничение

Инструменты и структура

Примером разделения прав служат инструменты в Claude. Инструмент bash технически способен выполнять любые операции с файлами. Однако в его описании для модели стоит запрет на такие действия. Для поиска, чтения и редактирования файлов созданы отдельные инструменты : glob, read, edit. Агент может комбинировать их в любом порядке, но он не может использовать Bash для задач, под которые выделены специализированные инструменты.

Как искать границы?

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

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