Короткий ответ: промт для агента - это письменное задание сотруднику, разложенное на части. Роль и рамка, что приходит на вход, шаги по порядку, формат ответа и правило на случай, когда данных не хватает. Разложенное задание даёт повторяемость. Расплывчатое «сделай красиво про это» даёт лотерею.
Я собираю агентов под конкретные операции бизнеса и вижу одну и ту же картину. Человек слышит, что агент хорош ровно настолько, насколько хорошо ему написано задание. Садится писать и получает одно из трёх: агент отвечает не на то, выдумывает несуществующее или отказывается. Почти всегда причина не в «тупой нейросети». Просто задание собрано как одна общая фраза, без частей.
Эта статья для владельца обычного бизнеса, не для программиста. Разберём, из чего состоит рабочее задание модели, почему постоянные правила держат отдельно от конкретного запроса и как прямо в тексте задания снизить выдумки. Если нужно сначала понять, из чего вообще собран ИИ-агент, прочитайте отдельный разбор - промт там одна из частей.
Что такое промт агента и почему от него столько зависит
Промт - это написанные словами инструкции для модели. В руководстве разработчиков это так и названо: работа над промтом есть «процесс написания эффективных инструкций для модели, чтобы она стабильно выдавала то, что вам нужно» (перевод мой). Ключевое слово - «стабильно». Одну задачу агент может сделать правильно с первого раза случайно. Повторяемо, день за днём, он делает её только тогда, когда задание не оставляет места для догадок.
Проще держать в голове такой образ. Модель - это толковый, но новый сотрудник без контекста ваших порядков. В тех же руководствах советуют прямо: «Думайте о модели как о блестящем, но новом сотруднике, которому не хватает контекста о ваших нормах и порядках. Чем точнее вы объясните, что хотите, тем лучше результат» (перевод мой). Новому человеку вы не скажете «разбери там заявки». Вы скажете, что считать заявкой, куда смотреть, что сделать с каждой и куда записать итог. С моделью то же самое.
Есть и техническая причина. Такие модели устроены так, что лучше работают с точными инструкциями, где прямо дана логика и данные для задачи. В руководстве сказано, что модели этого типа «выигрывают от точных инструкций, которые явно дают логику и данные, нужные для выполнения задачи, прямо в промте» (перевод мой). Поэтому «напиши пост» и «напиши пост по этим трём фактам, в таком-то тоне, не длиннее пяти предложений» дают разный результат не случайно, а закономерно.
Отсюда простой вывод. Качество агента - это не только выбранная модель и платформа, на которой вы его собираете. Это ещё и то, насколько аккуратно вы написали задание. Хорошая новость: задание пишется по понятной структуре, а не по наитию.
Пять частей рабочего задания
Рабочее задание агенту складывается из пяти частей: роль, вход, шаги, формат ответа и правило при нехватке данных. Это сборка принципов из руководств разработчиков моделей, а не волшебная формула. Но она закрывает ровно те дыры, через которые агент «уезжает».

Часть 1. Роль и рамка. Первая строка задаёт, кто этот агент и чего он не делает. В руководстве советуют описать «назначение, стиль общения и общие цели помощника» (перевод мой). И отдельно отмечают: роль «фокусирует поведение и тон модели; даже одно предложение уже меняет результат» (перевод мой). Для бизнеса это звучит так: «Ты помощник по разбору входящих заявок. Ты не обещаешь клиенту сроки и цены, только классифицируешь обращение». Рамка «чего не делаешь» важна не меньше самой роли.
Часть 2. Вход. Что именно приходит агенту на обработку. Одно письмо? Выгрузка за день? Текст звонка? В руководстве это называют контекстом: «дайте модели дополнительные сведения, нужные для ответа: закрытые данные и то, что особенно уместно к задаче» (перевод мой). Если агент должен работать по вашему прайсу или регламенту, этот материал кладут во вход, а не надеются, что модель «и так знает».
Часть 3. Шаги по порядку. Что сделать с входом, по пунктам. Когда важен порядок или полнота, инструкции дают «последовательными шагами, нумерованным списком» (перевод мой). Раздел инструкций говорит, «какие правила соблюдать, что модель должна делать и чего не должна делать никогда» (перевод мой). Пронумерованные шаги не для красоты: они не дают агенту пропустить проверку или перескочить через условие.
Часть 4. Формат ответа. Куда и в каком виде агент кладёт итог. Руководство прямо требует: «будьте конкретны про желаемый формат ответа и ограничения» (перевод мой). Если вам нужна строка в таблице с тремя полями, так и напишите: какие поля, в каком порядке, что писать, если поле пустое. Без этого один и тот же агент сегодня ответит абзацем, завтра списком, и свести его работу в систему не выйдет.
Часть 5. Что делать при нехватке данных. Самая пропускаемая часть и причина большинства выдумок. Про неё отдельный раздел ниже, но в задании она стоит прямо: «если данных для ответа нет, так и напиши, не придумывай».
Две вещи усиливают любую из частей. Первая - объяснять причину правила. «Указание причины или мотива инструкции помогает модели лучше понять ваши цели и дать более точный ответ» (перевод мой). Не просто «отвечай коротко», а «отвечай коротко, ответ уходит менеджеру в мессенджер». Вторая - примеры. Несколько примеров «вход и желаемый ответ» в задании считаются «одним из самых надёжных способов задать формат, тон и структуру ответа» (перевод мой). Такой приём направляет модель на новую задачу «без дообучения» (перевод мой). Два-три живых примера работают лучше трёх абзацев объяснений.
Остановимся на минуту. Если вы уже поняли, что ваша задача тянет на отдельного агента, а не на разовую подсказку в чате, разобрать её можно со мной. Четыре вопроса, полминуты, в ответ карта: где агент снимет работу, а где принесёт пустую цифру.
Почему постоянные правила и конкретный запрос держат отдельно
Здесь прячется самая частая ошибка новичка. Человек пишет одно большое сообщение, где смешаны и постоянные правила агента, и конкретный сегодняшний вопрос. Через неделю он меняет вопрос, случайно задевает правило, и агент начинает вести себя иначе. Он «поехал» не сам по себе: сдвинули фундамент.

У модели эти два слоя разделены по устройству. Есть постоянная часть - её называют системной инструкцией или заданием приложения. И есть конкретный запрос пользователя. В руководстве это сравнивают с программированием: «о постоянных правилах и запросе пользователя можно думать как о функции и её аргументах в языке программирования» (перевод мой). Правила - это функция, вход - аргументы. Меняете аргумент, функция остаётся на месте.
У слоёв разный вес. Правила приложения «ставятся выше по приоритету, чем сообщения пользователя» (перевод мой), а сообщения пользователя «идут приоритетом ниже» (перевод мой). На практике это значит простую вещь: запреты и рамку агента кладут в постоянную часть, где случайная формулировка в сегодняшнем запросе их не перебьёт. Если вы встроили в системную инструкцию «никогда не называй клиенту цену», разовое «ну скажи примерно» не должно это ломать.
Чтобы куски задания не слипались, их помечают. «Теги-пометки помогают модели однозначно разобрать сложный промт, где смешаны инструкции, контекст, примеры и переменный вход; каждый кусок в своём теге снижает путаницу» (перевод мой). Второе руководство добавляет, что теги помогают «очертить, где один кусок, например справочный документ, начинается и заканчивается» (перевод мой). Вам не нужно знать язык разметки. Достаточно отбивать разделы понятными заголовками: «Правила», «Данные на вход», «Примеры». Машине так же легче, как и человеку.
Если термин «задание модели» всё ещё расплывчатый, у меня есть короткое определение в словаре - можно держать рядом, пока читаете.
Как не дать агенту выдумывать
Выдумка - это уверенно сказанная неправда: число, ссылка или факт, которых не было. Опаснее обычной ошибки, потому что выглядит как правда. И именно от неё в задании есть два прямых рычага.
Первый. Разрешите агенту сказать «не знаю». Это звучит странно, но в руководстве по снижению выдумок первым пунктом идёт: «Разрешите модели сказать "я не знаю": явно дайте ей право признать неуверенность. Этот простой приём способен резко снизить ложную информацию» (перевод мой). По умолчанию модель старается ответить всегда, даже когда ответа у неё нет, и тогда достраивает правдоподобное. Одна строка в задании снимает это давление.
Второй. Ограничьте агента вашими данными. В том же руководстве советуют «прямо указать модели пользоваться только сведениями из переданных документов, а не общими знаниями» (перевод мой). Для бизнеса это снимает частую головную боль: агент по вашему прайсу не должен «вспоминать» цены вообще, он отвечает только по тому файлу, что вы ему дали. Нет позиции в файле - смотри правило из первого рычага.
Есть ещё приём про формулировки. Говорить модели лучше через то, что делать, а не через то, чего не делать. В руководстве это прямо советуют: «скажите, что делать, вместо того что не делать» (перевод мой). Вместо «не выдумывай контакты» надёжнее «бери контакты только из блока Данные; если их там нет, напиши: контакт не найден».
Но границу надо понимать трезво. Эти правила снижают выдумки, но не отменяют их полностью: в источнике сказано «способен резко снизить», а не «убрать». Поэтому ответственный участок работы агента всё равно проходит через проверку человеком. Промт уменьшает частоту ошибок, но не снимает с вас решение.
Пример: задание агенту на разбор входящих заявок
Соберём всё вместе на простой задаче. Допустим, в бизнес приходят заявки с сайта и из мессенджера, и менеджер тратит утро на то, чтобы рассортировать их и ответить, что чего не хватает. Это узкая, повторяемая операция - как раз под агента, по тому же принципу, что агент для документов. Вот как выглядит задание по пяти частям.
Роль.
Ты помощник по разбору входящих заявок. Ты классифицируешь заявку и проверяешь,
что в ней хватает данных. Ты не обещаешь клиенту сроки, цены и скидки.
Данные на вход.
Текст одной заявки. Список наших услуг и обязательных полей - в блоке "Справочник".
Шаги.
1. Определи тип заявки по "Справочнику": монтаж, ремонт, консультация или другое.
2. Проверь обязательные поля: имя, телефон, город, суть задачи.
3. Если какого-то поля нет, перечисли, чего не хватает.
4. Если тип не определяется по "Справочнику", поставь тип "другое".
Формат ответа.
Три строки:
- Тип: <из "Справочника" или "другое">
- Чего не хватает: <перечисли или "все поля на месте">
- Короткий вопрос клиенту: <одна фраза или "не требуется">
Если данных для шага нет.
Не додумывай. Для поля пиши "нет данных". Бери сведения только из заявки
и "Справочника", не из общих знаний.Разберём, что тут сработало. Роль сузила поведение и сразу закрыла опасное - обещания клиенту. Вход назвал, с чем агент работает, и куда положен справочник. Шаги не дали пропустить проверку полей. Формат сделал ответ одинаковым от заявки к заявке, его можно сразу вставить в таблицу. Последний блок убрал выдумки: нет данных - так и написано, а не изобретён телефон.
Заметьте, чего в задании нет. Нет просьбы «будь умным», нет пафоса и нет попытки объяснить агенту весь ваш бизнес. Есть одна операция, расписанная так, что по ней может пройти и человек, и машина.
Частые ошибки и чего промт не чинит
Разберём, на чём чаще всего спотыкаются, и где граница возможностей задания.
Ошибка первая - одна общая фраза вместо структуры. «Разбирай заявки и отвечай нормально» не содержит ни роли, ни формата, ни правила на нехватку данных. Агент заполнит пустоты сам, и каждый раз по-разному.
Ошибка вторая - запреты вместо инструкций. Длинный список «не делай того, не пиши этого» работает хуже, чем короткое «делай так». Проще и надёжнее сказать, что делать: формулировать лучше через действие, а не через запрет.
Ошибка третья - смешать правила и сегодняшний вопрос в одном сообщении. Постоянную рамку кладут в системную часть, разовый вопрос - отдельно. Иначе случайная фраза сдвинет поведение агента.
Ошибка четвёртая - проверять задание только на себе. У вас в голове весь контекст, у агента его нет. Здесь помогает золотое правило из руководства: «Покажите промт коллеге с минимальным контекстом по задаче и попросите выполнить. Если он запутается, запутается и модель» (перевод мой). Дайте задание человеку со стороны. Там, где переспросит он, ошибётся и агент.
И честная граница. Промт управляет поведением модели, но не делает её всеведущей и не заменяет проверку. Он не починит плохие или устаревшие данные на входе: мусор на входе - мусор на выходе. Он не гарантирует результат и не превращает агента в сотрудника, которому можно отдать ответственность. Хорошее задание снижает частоту ошибок и делает работу агента повторяемой. Решение и контроль остаются за вами. Если хотите заранее понять, как агент входит в работу и что проверяют в первый месяц, это отдельный разбор.
Источники
- Claude Platform Docs, «Prompting best practices»: роль, явные инструкции, шаги, формат, примеры, структура, золотое правило.
- Claude Platform Docs, «Reduce hallucinations»: разрешить «не знаю», отвечать только по переданным данным.
- OpenAI API, «Prompt engineering»: определение промта, разделы задания, роли и приоритеты, примеры.
Допустим, после статьи понятно, что задачу стоит снять с людей. Но непонятно, где это окупится, а где даст пустую цифру. Разберём вашу задачу: четыре вопроса, полминуты, в ответ карта автоматизации.
