Принципы vs инструкции для AI-агентов: почему жёсткие скрипты устаревают быстрее, чем вы успеваете их написать

Несколько недель назад в подкасте прозвучала фраза, которую я записал на полях и потом ещё раз перечитал вечером. Смысл примерно такой: когда вы даёте AI-агенту список инструкций, вы программируете его под вчерашний день. Когда вы даёте ему принципы — вы готовите его к завтрашнему. Я проверил это в реальной жизни: у меня 19 ботов, они управляют 16 виллами и делают ещё много всего. И я несколько месяцев подряд делал именно то, что нужно было делать — только осознал это недавно.

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

Что такое инструкция и почему она устаревает

Инструкция — это конкретный набор шагов для конкретной ситуации. "Если клиент спрашивает о цене — ответь X. Если спрашивает о доступности — проверь в таблице Y. Если задаёт вопрос про Z — передай менеджеру." Очень конкретно, очень понятно, легко проверить.

Проблема в том, что инструкции предполагают, что вы знаете все возможные ситуации заранее. А ещё предполагают, что мир не меняется. Когда вы меняете цену — нужно обновить инструкцию. Когда появляется новая услуга — нужно добавить новую ветку в сценарий. Когда меняется платформа — нужно переписать логику под новый интерфейс.

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

Есть ещё одна особенность, которую я не ожидал. Модели умнеют. Каждые несколько месяцев выходят новые версии — и то, что раньше требовало детальных шагов в инструкции, новая модель делает самостоятельно по общему описанию. Инструкции, написанные под GPT-3.5, выглядят избыточными для GPT-4o. А инструкции под GPT-4 становятся частично лишними для Claude. Если вы написали жёсткую инструкцию под конкретную модель — при смене модели вам нужно переписывать, потому что лишние шаги теперь мешают, а не помогают.

Что такое принцип и как он выглядит на практике

Принцип — это не шаг, а ориентир. Не "делай X в ситуации Y", а "когда ситуация непонятна, делай то, что причиняет меньший вред". Не "публикуй в 10:00 по московскому времени", а "публикуй тогда, когда аудитория активна, и не публикуй во время кризисных событий". Принцип работает в ситуациях, которые вы не предвидели.

Возьму конкретный пример из своей системы. У меня есть watchdog — служба, которая следит за здоровьем других сервисов. Я мог бы написать ей инструкцию: "Если fb-messenger упал — перезапусти через 15 минут. Если telegram-broadcaster молчит 4 часа — отправь алерт. Если сервис упал 3 раза за день — не перезапускай, напиши мне."

Или мог написать принцип: "Твоя задача — поддерживать работоспособность сервисов с минимальным вмешательством человека. Перезапускай то, что можно перезапустить безопасно. Не трогай то, что может навредить данным при перезапуске. Алертируй только тогда, когда человек действительно нужен — не по каждому чиху."

Разница в том, что инструкция хрупкая: она не покрывает ситуацию, когда fb-messenger упал и вернулся 2 раза за 3 часа, а потом снова упал — что тогда? Принцип покрывает: "минимальное вмешательство, безопасность данных, алерт только когда нужен". Служба сама применяет это к новой ситуации.

В реальности я пишу для каждого агента что-то среднее: несколько жёстких запретов (что никогда не делать — это инструкции), несколько жёстких обязательств (что всегда делать), и большое пространство принципов для всего остального. Запреты и обязательства — это контур безопасности. Принципы — это пространство действия внутри контура.

День, когда я увидел разницу в действии

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

Facebook Messenger ушёл в error-loop ночью: 5 ошибок за полчаса, ноль успешных операций. Watchdog поймал это и перезапустил сервис молча. Никаких уведомлений в 3 ночи. В логах всё аккуратно: детектор словил паттерн, выполнил рестарт, записал счётчик. Утром я прочитал лог как дневник — не как набор алертов, требующих реакции.

Второй бот тем временем провёл аудит Telegram-групп. Из 103 активных групп 39 оказались мёртвыми: в одних бота выкинули из администраторов, в других запретили отправлять медиа, в третьих группа вообще прекратила существование. Бот самостоятельно деактивировал все 39, записал причины в базу и продолжил работу только с живыми. Успешность рассылок выросла, потому что система перестала тратить ресурсы на заведомо мёртвые попытки.

Что интересно: у меня никогда не было инструкции "деактивируй группы с 3 и более ошибками за 7 дней". У меня был принцип: "поддерживай только то, что работает, и не трать ресурсы на то, что не работает уже больше недели". Бот сам выбрал конкретную метрику и конкретный порог.

Мог ли я написать эту метрику в инструкции? Да. Но тогда бы я жёстко закрепил "7 дней и 3 ошибки" — и при любом изменении (например, если нужно стало 5 дней или 5 ошибок) мне пришлось бы обновлять инструкцию. С принципом система сама подстраивает порог под реальное поведение и реальные потери.

Почему инструкции нужны: случаи, когда принцип не работает

Я не говорю, что инструкции плохи. Я говорю, что их нужно применять там, где они действительно нужны — и не применять там, где достаточно принципа. Давайте разберём, где без инструкций нельзя.

Финансовые операции и необратимые действия. Если бот может списать деньги, отправить платёж или удалить данные — это должна быть жёсткая инструкция: никогда не делать X без явного подтверждения от конкретного человека. Принцип "действуй разумно в интересах компании" здесь недостаточен. Разумность — понятие интерпретируемое, а удалённые данные не восстановятся.

Внешние коммуникации с клиентами. Когда бот отвечает реальному клиенту — ошибка видна сразу и стоит репутации. Здесь я предпочитаю инструкции: конкретные фразы, конкретные сценарии, конкретные ограничения. Принцип "будь полезным и вежливым" создаёт слишком широкое пространство для интерпретаций в ситуации, когда цена ошибки высока.

Платформенные ограничения. Instagram позволяет максимум Х символов в подписи. Telegram ограничивает размер файла до Y мегабайт. Airbnb требует конкретного формата заголовка объявления. Это не принципы — это факты о внешней среде, которые должны быть зафиксированы как жёсткие ограничения. Принцип не поможет, если бот просто не знает лимит платформы.

Правовые и налоговые требования. Балийские правила для аренды недвижимости, требования к налоговой отчётности, условия лицензий — всё это инструкции, а не принципы. "Следуй законодательству" — принцип, который без конкретных правил бесполезен.

Хорошая архитектура управления агентами — это слои. Внешний слой — жёсткие запреты и требования (инструкции). Внутренний слой — пространство принципов для самостоятельного принятия решений. Граница между ними — это место, где заканчивается ваша уверенность в предсказуемости ситуации и начинается доверие к суждению системы.

Как писать принципы: практический подход

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

Разберём на примере бота, который публикует контент в соцсети.

Плохой принцип: "Публикуй хороший контент своевременно." Это звучит красиво, но не даёт агенту ничего. Что такое хороший? Что такое своевременно? Как выбрать, если два поста готовы одновременно?

Лучший принцип: "Публикуй контент тогда, когда аудитория активна — для нашей аудитории это утром по балийскому времени и вечером по московскому. Не публикуй одновременно более одного поста в одну соцсеть. Не публикуй во время явно кризисных событий (это определяется по тональности последних сообщений в чате команды). Если есть два готовых поста — публикуй тот, что ждёт дольше."

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

Ещё один важный момент: принцип должен явно говорить, что делать при неопределённости. "Если не уверен — не делай и спроси" — это принцип. "Если не уверен — делай минимальное из возможных действий" — это тоже принцип. Оба правомерны, но для разных типов задач. Первый подходит для публичных коммуникаций, второй — для технических операций, где промедление хуже небольшой ошибки.

Тест: инструкция или принцип?

Когда я задумываюсь над тем, как описать правило для агента, я использую несколько вопросов.

Эти четыре вопроса помогают мне принять решение за несколько минут, а не размышлять над ним часами.

Пример из практики: как я переписал систему рассылок

Конкретный кейс — система рассылок в Telegram-каналы. Изначально у меня была детальная инструкция: публиковать в каналы из списка X, в такое-то время, с таким-то текстом, с такими-то хештегами, если объявление содержит фото — прикреплять фото, если без фото — добавлять заглушку.

Эта инструкция работала ровно до тех пор, пока не менялось ничего. Но менялось постоянно: появлялись новые каналы, старые умирали, менялся формат объявлений, менялось время пиковой активности в разных каналах. Каждое изменение требовало обновления инструкции. Я тратил час в неделю только на актуализацию правил рассылки.

Переписал на принципы: "Рассылай в каналы, где твои сообщения получают хотя бы один отклик (репост, реакция, ответ) за последние 14 дней. Не рассылай в каналы, где три последних сообщения не дошли. Публикуй тогда, когда в канале была последняя активность — не посреди ночи. Если канал исчез или изменились права — не трать попытки, запиши в лог, подожди неделю и проверь снова."

После перехода на принципы система сама вычищает мёртвые каналы и сама находит лучшее время для публикации. Я не трогал правила рассылки уже несколько месяцев — а система при этом работает лучше, чем когда я её настраивал вручную.

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

Система умнеет — и ваши инструкции устаревают

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

Если ваша система управления агентами построена на детальных инструкциях — вы застреваете в прошлом. Инструкции, написанные под более слабую модель, становятся балластом при переходе на более сильную. Они не дают системе использовать новые возможности, потому что жёстко предписывают старые шаги.

Принципы, напротив, масштабируются вверх. Принцип "минимальное вмешательство, безопасность данных, алерт только когда нужен" работает и с GPT-3.5, и с Claude, и с любой следующей моделью — просто каждая следующая модель реализует его лучше. Вы не переписываете принцип при смене модели. Вы просто получаете лучший результат.

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

Принципы как документ: как их хранить и обновлять

Практический вопрос: где хранить принципы и как их обновлять? Я пробовал несколько подходов и остановился на следующем.

Для каждого агента есть файл конфигурации (я называю его "конституция") — это не код, это текст. В нём три раздела: запрещено (жёсткие инструкции-запреты), обязательно (жёсткие инструкции-требования) и принципы действия (пространство для самостоятельных решений).

Запрещено: никогда не удалять данные без явного подтверждения, никогда не публиковать в внешние каналы без согласования, никогда не выходить за пределы своего домена (агент по виллам не трогает финансы, финансовый агент не трогает контент).

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

Принципы: здесь уже текстовое описание того, как агент должен подходить к своей зоне ответственности, как расставлять приоритеты, как разрешать конфликтующие требования.

Обновление принципов — это редкая операция. Если принцип написан правильно, он работает долго без изменений. Если мне приходится обновлять принцип чаще, чем раз в месяц — это сигнал, что я написал инструкцию, замаскированную под принцип.

Переход от исполнителя к архитектору

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

С инструкциями вы остаётесь исполнителем: каждое изменение в бизнесе требует вашего участия, чтобы обновить правила. Бот не знает, как делать шаг 4b, потому что вы его не описали — и ждёт вас. Вы нужны системе как операционный менеджер каждую неделю.

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

Это не просто удобнее — это другое качество жизни как предпринимателя. Я просыпаюсь и читаю лог как газету. Не как список задач, требующих моей реакции, а как отчёт о том, что уже сделалось. Альтрон не просит разрешения на каждый шаг. Он действует по принципам, докладывает результат и просит вмешательства только тогда, когда принципы явно недостаточны.

Один совет напоследок: начните с одного агента

Если вы только строите систему автоматизации или хотите переосмыслить существующую — не пытайтесь сразу переписать всё на принципы. Возьмите одного агента, с которым у вас больше всего проблем с устаревшими инструкциями. Перепишите его конфигурацию: уберите детальные шаги, оставьте запреты и требования, добавьте три-пять принципов для остального. Запустите. Посмотрите, что изменится через две недели.

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

Мониторинг результатов при этом становится особенно важным: вы должны видеть, когда агент на принципах делает что-то неожиданное. Не чтобы наказать — чтобы уточнить принцип. Это итеративный процесс, и он намного эффективнее, чем попытка написать идеальную инструкцию с нуля.

У вас своим ботам вы пишете инструкции или принципы? Интересно, где вы провели границу — и что мотивировало это решение.