Prompt Engineering все еще остается ключевым элементом в разработке приложений на базе LLM. По мере того как индустрия движется от экспериментов к созданию продуктов, возникает потребность в лучших практиках и проверенных паттернах. Чтобы найти их, лучшим методом является постоянный анализ существующих топовых решений.

В ходе масштабного исследования были проанализированы системные промпты из публичного репозитория https://github.com/x1xhlol/system-prompts-and-models-of-ai-tools. Этот репозиторий представляет собой уникальную коллекцию самых современных prompts для ИИ-агентов. Моей целью было выявить общие подходы и, что особенно важно, скрытые паттерны, которые делают этих агентов по-настоящему работоспособными.

Анализ инструкций реально работающих и популярных ИИ-агентов, созданных в 2025 году, критически важен. Это не теоретические упражнения, а взгляд "под капот" производственных систем. Понимая, какие именно техники они используют, мы можем научиться создавать собственных, не менее эффективных ассистентов. Это, по сути, обратная инженерия того, что действительно работает на практике.

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

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

Паттерн: XML-теги как основа структуры

1. Насколько это распространенный подход?

Анализ показал, что использование XML-подобной разметки - это не редкое исключение, а широко распространенная практика среди зрелых агентских систем. Из 26 проанализированных проектов верхнего уровня, 15 проектов (то есть, почти 60%) в той или иной степени используют кастомные теги для структурирования своих инструкций.

Этот подход применяют такие ИИ-агенты и инструменты как:

• Devin AI: использует теги <execute_bash>, <replace_lines> и <thought> для формализации каждого шага.

• Manus Agent: вся архитектура промпта описана через семантические теги, такие как <background>, <role_definition> и <tools>.

• v0 от Vercel: применяет кастомные MDX-компоненты (по сути, те же теги) для декларативного описания UI-задач.

• Cursor, Replit, NotionAI, Qoder: все они активно используют теги для определения правил, контекста, доступных инструментов и формата ответа.

Такое широкое распространение говорит о том, что этот паттерн, возможно, решает некую проблему при создани агенских систем.

2. Почему именно XML-теги?

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

Причина 1: Улучшение семантической структуры

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

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

Причина 2: Инкапсуляция и модульность для сложных промптов

Системные промпты для ИИ-агентов могут достигать до 10000 токенов. Управлять таким объемом правил без строгой структуры невозможно. Теги позволяют инкапсулировать сложные наборы инструкций в логические блоки - это дает сразу два преимущества:

• Читаемость: Промпт становится легче читать и поддерживать человеку-разработчику.

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

Причина 3: Создание ссылочной архитектуры. 

XML-теги - это не просто контейнеры, а именованные сущности. Это позволяет ссылаться на один тегированный блок из другого, создавая внутри промпта сложную сеть взаимосвязей. Например, в промпте Cursor Prompts мы видели, как основной текст ссылается на спецификации, описанные в тегах <status_update_spec> или <summary_spec>. Модели дается инструкция: "сформируй отчет о статусе в соответствии с правилами из блока <status_update_spec>".

3. Гибридный подход XML и Markdown

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

Markdown остается незаменимым для внутреннего форматирования и повышения читаемости блоков текста. В то время как XML-теги служат внешним, структурным каркасом, который делит весь промпт на семантические контейнеры.

В качестве примера такого гибридного подхода можно рассмотреть фрагмент из системного промпта Replit Assistant.

<response_protocol>
Rules for proposing actions:

## File Edit

Each edit to an existing file should use a <proposed_file_replace_substring> tag with the following attributes:
- 'file_path': The path of the file.
- 'change_summary': A short summary of the proposed change. Do not be repetitive in explanations or summaries.

## File Replace
...
</response_protocol>

В этом примере:

• XML-тег <response_protocol>  выполняет роль семантического контейнера. Он говорит модели: "Всё, что находится внутри этого блока, относится к единой концепции". Он создает жесткую границу.

• Внутри XML-блока используются стандартные Markdown-заголовки. Они служат для визуального и логического разделения правил на подсекции. Заголовки и списки помогают модели лучше понять иерархию и взаимосвязь правил внутри одного большого семантического блока.

Лучшие практики тегирования: (на реальных примерах)

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

1. Использование осмысленных названий тегов

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

• Наблюдение: Промпты избегают общих названий, таких как <rules> или <info>. Вместо этого они используют максимально описательные и конкретные имена.

• Реальные примеры:

  • В промпте Manus вместо одного общего блока правил мы видим декомпозицию на:

    • <language_settings>

    • <system_capability>

    • <agent_loop>

    • <planner_module>

    • <writing_rules>

  • В промпте Cursor инструкции по общению с пользователем вынесены в отдельный, очень специфичный блок:

    • <status_update_spec>

    • <summary_spec>

  • В промпте Bolt ограничения среды четко инкапсулированы в тег:

    • <system_constraints>

2. Плоские и иерархические структуры тегов

Структура тегов определяет, как модель будет воспринимать взаимосвязь между разными блоками инструкций. Анализ показывает использование двух подходов.

• Плоская структура (Flat Structure)
  Это самый распространенный подход: простой список независимых, не вложенных друг в друга тегов. Он идеален для определения набора различных, но равнозначных концепций.

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

  • Реальный пример (из Same.dev):

    <service_policies>...</service_policies>
    <communication>...</communication>
    <tool_calling>...</tool_calling>
    <making_code_changes>...</making_code_changes>
    <web_development>...</web_development>
    <debugging>...</debugging>

    Здесь каждый тег представляет собой отдельный, верхнеуровневый аспект поведения агента.

• Иерархическая структура (Hierarchical Structure)
  Этот подход встречается реже, в более сложных промптах, и используется для группировки связанных правил и показа их взаимозависимости.

  • Когда используется: Когда есть общие правила и их более специфичные под-варианты.

  • Реальный пример (из Cluely Enterprise Prompt):

    <question_answering_priority>
        <primary_directive>...</primary_directive>
        <question_response_structure>...</question_response_structure>
        <intent_detection_guidelines>...</intent_detection_guidelines>
    </question_answering_priority>
    
    <term_definition_priority>
        <definition_directive>...</definition_directive>
        <definition_triggers>...</definition_triggers>
    </term_definition_priority>

    В этом примере из Cluely модель четко видит, что <primary_directive>  и <question_response_structure>  являются под-правилами более общей концепции question_answering_priority. Эта вложенность помогает модели лучше понимать контекст и применять наиболее специфичное правило в нужной ситуации.

Лучшая практика (наблюдаемая): Начинать с плоской структуры для основных разделов. Вводить иерархию только тогда, когда сложность правил действительно этого требует, как в примере с алгоритмом приоритетов у Cluely.

3. Размер блока: сколько токенов можно заключать в теги?

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

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

Наблюдение и лучшая практика: Вместо того чтобы иметь один гигантский блок <rules>, зрелые промпты разбивают его на несколько более мелких, как мы видели на примере Manus. Это не только помогает модели, но и делает сам промпт более читаемым и поддерживаемым.

• Пример плохого подхода (гипотетический, не найден в зрелых промптах):

  <rules>
      <!-- Тысячи токенов обо всем: общение, инструменты, безопасность, форматирование... -->
  </rules>

• Пример хорошего подхода (наблюдаемый в Codex CLI):

  <personality>...</personality>
  <planning>...</planning>
  <task_execution>...</task_execution>
  <testing_your_work>...</testing_your_work>
  <sandbox_and_approvals>...</sandbox_and_approvals>
  <ambition_vs_precision>...</ambition_vs_precision>

  Здесь Codex CLI разбивает то, что могло бы быть одним огромным блоком "правил", на шесть сфокусированных семантических блоков, каждый со своим сильным якорем. Это и есть ключевая стратегия для управления сложностью в больших системных промптах.

4. Еще несколько подходов к тегированию

Эта таблица обобщает некоторые практики использования XML-подобных тегов в системных промптах для ИИ-агентов. Она демонстрирует, как теги используются для определения ролей, структурирования мыслей, управления инструментами и интеграции с UI.

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

Мысли в качестве вывода

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

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

Обо всём об этом, без лишней воды и хайповых новостей в стиле - "вышла новая ChatGPT o56_turbo_MAX_better_than_yesterday" - в моем телеграмм канале Агент LLM