Как писать системные промпты для ИИ-агентов, которые не ломаются в продакшене

Содержание

Обновлено июль 2026.

TL;DR: Продакшн-системный промпт имеет пять уровней: идентичность (кто агент и что он не может делать), контекст (что он знает об окружении), задача (как выглядит успех пошагово), формат вывода (самый недооценённый уровень) и пограничные случаи (что делать при проблемных входных данных). Большинство промптов ломается, потому что пропускают уровни 4 и 5. Пишите формат вывода первым — это заставляет вас быть точными в том, что вы действительно хотите.

[Взгляд оператора] Я управляю более чем 30 ИИ-агентами в продакшене для своего консалтингового бренда и Pickleland — площадки для пиклбола в Пфлюгервиле, Техас. Я переписал больше системных промптов, чем написал — обычно потому, что первая версия хорошо работала на тестах, а потом тихо деградировала в продакшене. Вот что я узнал о написании промптов, которые держатся.

Проблема системных промптов, о которой никто не говорит

Большинство системных промптов для агентов пишутся примерно за 20 минут, тестируются на двух-трёх примерах и больше никогда не трогаются. Модель выходит в прод. Некоторое время всё работает. Потом что-то меняется — входные данные становятся грязнее, модель обновляется, появляется новый пограничный случай — и агент начинает выдавать мусор. Тихо. В масштабе.

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

Пять уровней продакшн-системного промпта

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

Уровень 1: Идентичность

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

Сильный уровень идентичности отвечает на три вопроса:

• За что отвечает этот агент?
• За что он явно НЕ отвечает (и должен эскалировать или отказывать)?
• Какие стандарты он соблюдает?

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

Уровень 2: Контекст

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

Большинство агентов, которые я просматриваю, бедны контекстом. Не предполагайте. Вводите.

Уровень 3: Задача

Уровень задачи описывает, что агент делает шаг за шагом. Не «помогать клиентам» — реальный поток принятия решений. Пишите его как блок-схему, а не как директиву. Блок-схемы более устойчивы, потому что уменьшают потребность модели в выведении того, что вы хотите, в неоднозначных случаях.

Уровень 4: Формат вывода

Это самый недооценённый уровень, и тот, что больше всего отвечает за тихие сбои.

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

Для высокорисковых агентов я использую структурированный вывод Claude с определённой JSON-схемой.

Уровень 5: Пограничные случаи

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

Как я поддерживаю системные промпты со временем

Продакшн-системный промпт — это живой документ:

1. Еженедельная точечная проверка. Я проверяю от пяти до десяти случайных выводов каждого высокорискового агента.
2. Обзор после обновления модели. Каждый раз, когда меняется версия базовой модели, я запускаю агента против полного золотого набора из моего фреймворка оценки.
3. Журнал пограничных случаев. Я веду журнал входных данных, с которыми агент справился плохо. Когда три или более записи разделяют паттерн, я добавляю явное правило.
4. Версионирование промпта. Каждое значимое изменение получает версионный комментарий.

Часто задаваемые вопросы

Насколько длинным должен быть продакшн-системный промпт?

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

Когда мне следует разбить сложную задачу на несколько агентов вместо одного длинного промпта?

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

Какова наиболее распространённая причина, по которой промпт, работавший на тестах, ломается в продакшене?

Тестовые входные данные не были репрезентативными для производственного распределения. Создавайте тестовый набор из реального продакшн-трафика, а не из воображаемых входных данных.