Владелец интернет-магазина просит подрядчика подключить нейросеть к CRM, складу и почте, чтобы она сама отвечала клиентам. Подрядчик берёт готовый промт для ИИ-агента из шаблона чат-бота, дописывает в конец список функций и подключает его к реальным данным. Через два дня агент меняет статус заказа без подтверждения, отправляет письмо не тому клиенту и по кругу переспрашивает один и тот же вопрос, не находя повода остановиться.
Причина не в модели и не в наборе инструментов. Промт для чат-бота описывает тон и формат одного ответа: пользователь спросил, модель ответила, диалог сохранился только как история сообщений. Промт для автономного агента описывает поведение в цикле из множества шагов: агент получает задачу, выбирает инструмент, смотрит на результат, решает, что делать дальше, и повторяет это, пока не выполнит условие остановки или не передаст решение человеку.
Дальше: из каких блоков состоит промт для ИИ-агента, чем роль агента отличается от персоны чат-бота, как описывать инструменты и границы, что агенту стоит помнить между запусками, и шаблон, который можно адаптировать за вечер для пилотного запуска.
Чем промт для ИИ-агента отличается от промта для чат-бота
У чат-бота задача одна: по сообщению пользователя и системной инструкции сформировать ответ. Всё, что нужно промту, это роль, тон и формат вывода. Агент работает иначе: модель вызывается в цикле, на каждом шаге у неё есть доступ к инструментам, и промт должен описывать не только стиль ответа, а правила принятия решений на каждой итерации.
Отсюда и разница в содержании. У чат-бота почти нет смысла описывать, что происходит при ошибке: ошибся, значит, пользователь переспросит. У агента ошибка инструмента, тайм-аут запроса к базе или пустой результат поиска это штатная ситуация, которую нужно обработать внутри цикла, иначе агент либо зависнет, либо придумает ответ без данных.
| Параметр | Промт чат-бота | Промт агента |
|---|---|---|
| Сколько шагов модели на один запрос | Один | От нескольких до десятков |
| Что хранится между шагами | История переписки | История, результаты инструментов, промежуточные решения |
| Кто решает, когда закончить | Пользователь читает ответ | Сам агент, по условию остановки в промте |
| Что при ошибке | Пользователь переформулирует | Нужен прописанный сценарий: повтор, пропуск шага, передача человеку |
| Что при неправильном действии | Неверный текст | Может быть необратимое действие в реальной системе |
Роль и зона ответственности агента
«Ты полезный ассистент» работает для чат-бота и почти не работает для агента с доступом к инструментам. Роль агента нужно описывать через зону ответственности: что он делает сам, что передаёт человеку и где его полномочия заканчиваются. Сначала стоит определить результат, который агент должен выдать, и только потом персону и тон.
- Зона ответственности. Какие задачи агент решает без участия человека: например, формирует статус заказа по данным склада.
- Исключения. Что агент никогда не делает сам: не меняет цену, не отменяет заказ, не пишет клиенту без шаблона.
- Передача человеку. При каком условии агент останавливается и передаёт задачу: сумма сделки выше порога, жалоба клиента, противоречивые данные в системах.
Если промт не отвечает на вопрос «а что агент делает, когда не уверен», агент решит этот вопрос сам, и не всегда так, как хотелось бы. Конкретные сигналы вместо общих пожеланий работают одинаково и для чат-бота, и для агента, подробнее об этом мы писали в материале о том, как написать промпт для нейросети, если он не сработал.
Инструменты: как описывать и ограничивать доступ
Соблазн подключить агенту сразу все API, которые есть в системе: список клиентов, обновление статусов, отправку писем, работу со складом. На практике это усложняет работу модели: чем больше инструментов с похожими названиями, тем выше шанс, что агент выберет не тот. Лучше дать несколько инструментов, которые закрывают целые рабочие сценарии, чем десяток узких функций.
Для каждого инструмента в промте стоит описать не только название и параметры, а когда его вызывать, что делать с результатом и как себя вести, если вызов завершился ошибкой или вернул пустой ответ. Отдельно стоит разделить инструменты по уровню риска:
- Инструменты только для чтения: поиск, проверка статуса, запрос остатков на складе.
- Обратимые действия: черновик письма, заметка в карточке клиента, статус «на согласовании».
- Необратимые действия: отправка письма клиенту, списание со склада, возврат денег.
Для необратимых действий промт должен требовать подтверждение, но запрет в тексте инструкции не заменяет техническое ограничение: если инструмент физически может списать товар без дополнительного шага, рано или поздно агент это сделает, даже если в промте написано «спрашивай разрешение». Подтверждение нужно вынести в саму логику инструмента, а не оставлять только в тексте промта. Как собрать такой набор инструментов на практике, например через узел AI Agent, разобрано в статье про настройку ИИ-агента в n8n.
Границы: что агент никогда не делает сам
Границы агента это не одна фраза «не делай плохого», а несколько разных типов ограничений, и в промте их стоит разделять:
- Данные. Какие источники и поля агент видит: например, только заказы своего региона, без доступа к финансовым отчётам.
- Действия. Что можно выполнить без подтверждения и что требует согласования человека.
- Темы. Какие вопросы вне компетенции агента: юридические консультации, медицинские рекомендации, обещания от имени компании.
- Эскалация. При каком сигнале агент прекращает попытки и передаёт диалог человеку: несколько неудачных вызовов инструмента подряд, явное недовольство клиента, запрос, который не покрыт инструкцией.
Текст промта задаёт намерение, но не гарантирует поведение: если агенту всё-таки доступен инструмент удаления записей, запрет «не удаляй данные» в инструкции не остановит его в нестандартной ситуации. Границы, которые важны для безопасности и денег, нужно закладывать на уровне доступа к инструментам и прав системы, а промт использовать для границ, которые не требуют жёсткого технического барьера: тон общения, темы разговора, порядок действий.
Память агента: что хранить и что забывать между запусками
У чат-бота память это, по сути, окно диалога: закрыли вкладку, история исчезла. Агенту для многошаговой задачи нужна память внутри одного запуска: что уже проверено, какой инструмент вызывался и с каким результатом, какое решение принято на предыдущем шаге. Без этого агент повторяет уже сделанные шаги или теряет контекст на десятом вызове инструмента.
Отдельный вопрос: что агент помнит между разными запусками, то есть после того, как задача закрыта. Для пилота стоит хранить минимум: ключевые факты, которые влияют на будущие решения, например предпочтения клиента или статус незавершённого обращения. Полную историю переписки каждый раз подгружать в промт не нужно: это раздувает объём контекста, увеличивает стоимость каждого вызова модели и не прибавляет агенту точности. Правило простое: если факт не меняет решение на следующем шаге, его не нужно держать в памяти агента постоянно.
Типичные ошибки при проектировании промта для агента
- Берут готовый промт чат-бота и просто дописывают список инструментов в конец, без правил принятия решений.
- Не задают условие остановки: цикл «подумал, вызвал инструмент, посмотрел результат» не ограничен ни числом шагов, ни признаком завершения задачи.
- Надеются на запрет в тексте промта там, где нужен технический барьер: ограничение доступа, подтверждение в коде, а не инструкция «будь осторожен».
- Делают промт слишком общим: «отвечай полезно и аккуратно» не даёт модели сигналов, что конкретно делать в спорной ситуации.
- Или наоборот зашивают в промт жёсткую логику под один частный случай, и агент разваливается, как только сценарий чуть отличается от описанного.
- Не разделяют обратимые и необратимые действия: отправка письма и удаление записи получают одинаковый уровень доверия.
Как проверить промт перед запуском пилота
Прежде чем подключать агента к реальным данным, промт стоит прогнать через несколько проверок. Первая: показать системный промт и описания инструментов самой модели и спросить, какие формулировки можно понять двояко, какой инструмент она выбрала бы в конкретном сценарии и почему. Модель, для которой писали инструкцию, часто точно указывает на расплывчатые места.
Вторая проверка: прогнать агента по трём-пяти сценариям вручную, шаг за шагом, включая заведомо сложные случаи: инструмент вернул ошибку, данных не хватает, запрос выходит за пределы роли агента. Если на любом из этих шагов агент продолжает работу вместо остановки или передачи человеку, в промте не хватает условия остановки или правила эскалации.
Шаблон системного промта для пилота
Рабочий промт для пилотного запуска агента можно собрать из семи блоков. Не все нужно расписывать подробно с первого раза, но пропускать блок целиком не стоит:
- Роль и результат. Что агент делает, для кого, и какой результат считается выполненной задачей.
- Зона ответственности. Какие задачи агент решает сам, без участия человека.
- Инструменты. Список с описанием: имя, когда вызывать, что делать с результатом, что делать при ошибке.
- Границы. Какие данные доступны, какие действия требуют подтверждения, какие темы вне компетенции.
- Условие остановки. Когда задача считается завершённой и когда агент обязан прекратить попытки.
- Эскалация. При каком сигнале передавать диалог или задачу человеку.
- Память. Какие факты агент переносит в следующий запуск, а что хранит только для текущей задачи.
Полный путь от такого шаблона до рабочего прототипа, с подключением инструментов и тестовыми сценариями, описан в материале о создании ИИ-агента для бизнеса.
Частые вопросы
Чем промт для ИИ-агента отличается от промта для чат-бота?
Промт чат-бота описывает тон и формат одного ответа на одно сообщение. Промт агента описывает поведение в цикле из многих шагов: какие инструменты доступны, когда их вызывать, что делать при ошибке и когда остановиться. Агенту, в отличие от чат-бота, нужны условия остановки и правила эскалации к человеку, иначе цикл «подумал, вызвал инструмент» не ограничен по числу шагов.
Нужно ли агенту сразу давать доступ ко всем инструментам системы?
Нет. Чем больше похожих по названию инструментов доступно модели, тем выше шанс, что она вызовет не тот. Лучше дать несколько инструментов, каждый из которых закрывает целый рабочий сценарий, чем десяток узких функций под отдельные API-методы. Доступ стоит расширять постепенно, после того как пилот показал стабильное поведение на базовом наборе задач.
Как агент должен реагировать на ошибку инструмента?
Промт должен прямо описывать сценарий для каждого инструмента: повторить вызов, пропустить шаг и продолжить с доступными данными, или остановиться и передать задачу человеку. Без этого правила агент на ошибке инструмента либо зависает в повторных попытках, либо придумывает ответ без реальных данных, что для бизнес-задач опаснее, чем честное «не нашёл информацию».
Сколько истории диалога агенту нужно хранить между запусками?
Для пилота достаточно держать только факты, которые влияют на будущие решения: статус обращения, предпочтения клиента, принятые ранее решения. Хранить и каждый раз подгружать полную переписку не нужно: это увеличивает объём контекста и стоимость каждого вызова модели, но не повышает точность ответа, если факт не влияет на следующий шаг.
Достаточно ли текста промта, чтобы ограничить действия агента?
Нет. Промт задаёт намерение, но не гарантирует поведение: если инструмент технически может выполнить необратимое действие без подтверждения, запрет в тексте инструкции не остановит агента в нестандартной ситуации. Жёсткие границы, связанные с деньгами, данными и безопасностью, нужно закладывать на уровне доступа к инструментам и прав системы, а не только в формулировках промта.
С чего начать
Собрать рабочий промт для пилота можно за несколько шагов:
- Опишите роль и зону ответственности агента одним абзацем: что он делает сам и в какой момент передаёт задачу человеку.
- Соберите список инструментов, которые нужны для этой задачи, и не больше, разделив их на инструменты для чтения, обратимые и необратимые действия.
- Пропишите условие остановки и правило подтверждения для необратимых действий, закрепив его технически, а не только в тексте промта.
- Прогоните промт на трёх-пяти сценариях, включая ошибку инструмента, прежде чем подключать реальные данные клиентов.
Если собирать и тестировать это самостоятельно некогда, промты, инструменты и границы агента под конкретный бизнес-процесс настраивают специалисты по автоматизации на базе ИИ.
