При создании ИИ-агентов разработчики часто сталкиваются с проблемой контроля. Если дать языковой модели полную свободу действий, система становится непредсказуемой и склонной к ошибкам. Если же ограничить её слишком жестко, агент теряет свои преимущества и превращается в обычный скрипт.
Концепция инвариантного проектирования помогает найти баланс между фиксированными правилами и свободой поведения модели. Она заключается в выделении ключевых инвариантов — неизменных правил, которые агент не может нарушать — и оставлении гибкости в остальных аспектах.
Часто команды допускают одну из двух ошибок: либо чрезмерно ограничивают агента, делая его бесполезным, либо дают слишком много свободы, что приводит к сбоям. Например, чат-бот авиакомпании может случайно продать билет за 1 доллар. Главная сложность — в правильном выборе ограничений.
Фиксированные процессы и гибкое взаимодействие
Рассмотрим ИИ-агента для страховой компании. При регистрации ДТП он должен собрать данные в строгом порядке: номер полиса, дата происшествия, описание повреждений. Этот процесс фиксирован на 80%.
Если просто передать список вопросов в промпт, модель может пропустить пункт или изменить последовательность. Чтобы избежать этого, порядок шагов должен контролироваться программной оболочкой.
Процесс можно реализовать как конечный автомат, который на каждом этапе передаёт модели только один вопрос. Роль языковой модели — извлекать структурированную информацию из ответа пользователя. Решение о следующем шаге остаётся за системой.
Адаптивность с ограничениями
В других случаях, например, в техподдержке интернета, заранее заданный сценарий невозможен. Агент должен самостоятельно искать решение, изучать базу знаний и адаптироваться к ситуации.
Но и здесь нужны инварианты. Например, можно ввести правило: агент обязан сначала выполнить поиск по документации, прежде чем предлагать решение. Это структурное ограничение обеспечивает надёжность, не убивая гибкость.
Инструменты и структура
Пример разделения прав — использование инструментов в Claude. Инструмент bash технически способен выполнять любые операции с файлами. Однако в его описании модели указан запрет на такие действия.
Для поиска, чтения и редактирования файлов созданы специализированные инструменты: glob, read, edit. Агент может комбинировать их в любом порядке, но не может использовать bash для задач, для которых выделены отдельные инструменты. Это обеспечивает безопасность и предсказуемость.
Как искать границы?
Разработку лучше начинать с одной модели и одного промпта, добавляя ограничения по мере выявления ошибок. Для тестирования можно использовать другую языковую модель, имитирующую пользователя. Это помогает быстро находить проблемы — например, пропуск обязательных полей или выдумывание несуществующих правил.
Со временем число ограничений растёт, и система может стать излишне жёсткой. В этом случае нужен аудит. Если ошибка модели обходится дорого, а правильный алгоритм можно чётко описать, это должно стать инвариантом.
Если же в этом месте важна креативность, а ошибки легко исправить, стоит оставить модели больше свободы. С появлением более умных моделей такие границы необходимо регулярно пересматривать.