Промпт-инжиниринг в ТЗ для Agentic AI: как правильно описать логику, RAG и работу с инструментами

В проектах с Agentic AI промпты перестают быть «экспериментом» и становятся частью архитектуры.

Если их не описать в ТЗ, команда будет интерпретировать поведение агента по-разному — это приводит к нестабильности, hallucinations и непредсказуемому UX.

Ключевая идея: промпт-инжиниринг — это не настройка, а спецификация поведения агента.

Почему промпты должны быть в ТЗ

В Agentic AI промпты управляют:

• логикой принятия решений
• использованием RAG
• вызовом tools
• стилем общения

Без формализации:

• агент «плывёт» по поведению
• разные окружения дают разный результат
• сложно масштабировать и тестировать

Базовая структура промптов в ТЗ

В ТЗ должны быть описаны 5 уровней:

1. System prompt (ядро поведения)
2. Role / persona
3. Контекст (RAG + память)
4. Инструкции по tools
5. Диалоговые правила (conversation policy)

Ключевые практики

System prompt (ядро)

Это главный слой, который задаёт рамки.

Что зафиксировать:

• цель агента
• границы компетенции
• правила принятия решений

Пример формализации:

Агент должен решать задачи пользователя, используя доступные инструменты. Если задача требует внешнего действия — сначала выбрать инструмент, затем выполнить.

Role и поведение

Определяет UX.

Что указать:

• стиль (эксперт, ассистент, продавец)
• уровень формальности
• проактивность

Пример:

Агент ведёт диалог как консультант: кратко, по делу, предлагает следующий шаг.

Контекст и RAG

Важно не просто «подключить базу», а описать правила:

• когда обращаться к RAG
• как выбирать источники
• приоритет данных

Пример:

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

Tool usage (работа с инструментами)

Критически важный блок для Agentic AI.

Что прописать:

• когда вызывать инструмент
• как выбирать между инструментами
• формат входа/выхода

Пример:

Если пользователь хочет выполнить действие (создать заказ, проверить статус), агент обязан использовать API, а не генерировать ответ.

Управление диалогом

Опишите правила:

• когда задавать уточняющие вопросы
• как обрабатывать неоднозначность
• когда завершать диалог

Пример:

При недостатке данных агент задаёт уточняющий вопрос перед вызовом инструмента.

Ошибки и fallback

Один из самых недооценённых блоков.

Что важно:

• поведение при ошибке API
• что делать при отсутствии данных
• как эскалировать на человека

Пример:

При ошибке инструмента агент сообщает пользователю и предлагает альтернативный путь или перевод на оператора.

Пример структуры в ТЗ

System Prompt:

• цель агента
• ограничения
• правила принятия решений

Role:

• стиль общения
• уровень формальности
• RAG Policy:
• источники
• приоритет
• правила использования

Tool Policy:

• список инструментов
• условия вызова
• ограничения

Conversation Rules:

• уточнения
• завершение диалога
• fallback

Частые ошибки

❌ «Написать один общий промпт»

❌ Нет разделения system / user / tool логики

❌ Отсутствие правил работы с RAG

❌ Неописанные сценарии ошибок

❌ Слишком общий стиль («будь полезным»)

Практические рекомендации

• Делайте промпты модульными (разные блоки)
• Тестируйте на реальных сценариях
• Фиксируйте версии промптов (prompt versioning)
• Добавляйте примеры (few-shot), если поведение критично
• Учитывайте канал (text ≠ voice ≠ avatar)

Вывод: чек-лист для ТЗ

Промпты в ТЗ готовы, если:

✔ есть system prompt с чёткими правилами

✔ описана роль и стиль

✔ формализован RAG

✔ есть логика вызова tools

✔ прописаны диалоговые правила

✔ учтены ошибки и fallback