Инженерные документы

Формирование системного промта агента

#1. Цель

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

Агент должен самостоятельно выбирать траекторию решения задачи на основании:

поставленной задачи;
доступных инструментов;
окружения;
подключённых skills;
релевантных знаний Temporality;
полученных в ходе работы свидетельств.

Пользователь не должен вручную составлять сложный структурированный prompt или YAML-конфигурацию.

#2. Принцип формирования

Системный промт состоит из двух частей:

#Постоянная часть

Формируется из определения агента и меняется редко:

кто такой агент;
за что он отвечает;
что ему разрешено и запрещено;
что считается успешно выполненной работой.

#Контекстная часть

Формируется Temporality автоматически для конкретной операции:

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

Пользователь не редактирует контекстную часть системного промта напрямую.

#3. Пользовательский интерфейс

#3.1. Не использовать YAML как пользовательский интерфейс

Необходимо исключить сценарий:

role:
  identity: ...
  responsibilities:
    - ...
  constraints:
    - ...
  completion:
    - ...

YAML или другая структурированная модель может использоваться внутри системы как формат хранения или компиляции.

Для пользователя должна существовать обычная форма.

#3.2. Минимальная форма создания агента

Форма должна содержать:

#Название

Например:

Coder

#Назначение

Одно обычное текстовое поле:

Для каких задач нужен этот агент?

Например:

Реализует изменения в коде, исправляет ошибки и проверяет результат.

Это основное поле.

#Возможности

Понятные переключатели:

Читать файлы
Изменять файлы
Выполнять команды
Использовать интернет
Использовать подключённые skills
Использовать накопленные знания

При этом доступность отдельных возможностей определяется конфигурацией окружения и правами агента.

#Ограничения

Необязательное поле:

Есть ли что-то, что агенту запрещено делать?

Например:

Не изменять инфраструктуру и не удалять файлы.

#Проверка результата

Необязательное поле:

Что агент должен проверить перед завершением работы?

Например:

Запустить соответствующие тесты и убедиться, что сборка проходит.

#4. AI-формирование

Пользователь может просто описать агента естественным языком.

Например:

Нужен агент, который занимается backend-разработкой на C#. Может менять код и запускать тесты, но не должен трогать инфраструктуру.

После нажатия «Сформировать агента» Temporality должен:

интерпретировать описание;
определить предполагаемую роль;
предложить структурированное определение агента;
сформировать системный промт;
показать пользователю результат;
дать возможность его скорректировать.

Пользователь не обязан знать устройство системного промта.

#5. Пользователь должен видеть не prompt, а смысл

После формирования необходимо показывать человеку понятное резюме:

#Coder

Назначение

Разработка и исправление backend-кода.

Может

читать и изменять код;
выполнять команды;
запускать тесты.

Не может

изменять инфраструктуру.

Перед завершением

проверяет изменённый код;
запускает релевантные тесты;
сообщает о непроверенных предположениях.

И только при необходимости должна быть доступна вкладка:

Системный промт

для просмотра и ручной корректировки итогового текста.

#6. Системный промт должен генерироваться, а не собираться вручную

Внутренняя модель должна позволять компилировать системный промт из отдельных смысловых компонентов:

Базовый контракт агента
        +
Роль
        +
Ответственность
        +
Ограничения
        +
Критерии завершения
        +
Политика окружения

Пользователь при этом работает с человеческими формулировками, а не с этими техническими компонентами.

#7. Не превращать системный промт в инструкцию по шагам

Генератор должен избегать инструкций вида:

1. Сначала прочитай README.
2. Затем найди нужный файл.
3. Потом запусти тесты.
4. После этого внеси изменения.
5. Затем снова запусти тесты.

Вместо этого должны формироваться требования уровня поведения:

Understand the existing implementation before modifying it.

Prefer existing project conventions.

Verify important changes using relevant available checks.

Это позволяет сильной модели самостоятельно выбирать оптимальную траекторию.

#8. Не дублировать возможности инструментов

Системный промт не должен подробно описывать инструменты, если Temporality уже передаёт модели их схемы.

Плохо:

Для чтения файла используй инструмент X с параметром path...

Хорошо:

Use the available tools to inspect and modify the workspace.

Конкретное описание инструментов должно приходить из tool definitions.

#9. Не дублировать skills

Системный промт не должен содержать инструкции конкретных skills.

Например, Coder не должен иметь внутри системного промта:

При работе с React используй...

или:

При работе с <продуктом заказчика> обязательно...

Такие знания должны находиться в skills и подключаться только тогда, когда они релевантны операции.

#10. Не заставлять агента использовать память

Не следует помещать в системный промт обязательную инструкцию:

Always use available memories.

Temporality сам выбирает релевантные знания и передаёт их агенту в подходящий момент.

Агенту достаточно общего правила:

Use provided prior knowledge when it is relevant, but prefer current evidence when the two conflict.

Это предотвращает превращение памяти в обязательный RAG-контекст.

#11. Обязательный контракт доказательности

Для всех автономных агентов системный промт должен содержать общий принцип:

Не утверждай, что результат достигнут, если это не подтверждено доступными свидетельствами.

Агент должен различать:

выполненное и проверенное;
выполненное, но не проверенное;
предполагаемое;
невозможное для проверки.

Это особенно важно для Reviewer, DevOps и агентов, работающих с долгими задачами.

#12. Роль должна определять ответственность, а не стиль

Например:

#Coder

Отвечает за изменение программного кода и проверку результата.

#Reviewer

Отвечает за поиск дефектов и оценку достаточности доказательств.

#Researcher

Отвечает за получение и синтезирование информации из доступных источников.

#DevOps

Отвечает за изменение, диагностику и проверку инфраструктуры.

Не следует добавлять в role prompt инструкции вроде:

Be extremely careful, thoughtful, proactive, concise and intelligent.

Такие формулировки не должны заменять конкретные поведенческие требования.

#13. Предусмотреть режим «Сформировать заново»

Если пользователь существенно изменил описание агента, он должен иметь возможность нажать:

Переформировать

Temporality повторно анализирует описание и формирует новую версию определения.

При этом ручные изменения пользователя не должны молча теряться.

Перед заменой необходимо показать:

что изменится;
какие пользовательские настройки затронуты;
возможность принять или отменить изменения.

#14. Версионирование

Каждое изменение системного промта должно создавать версию.

Версия должна хранить:

пользовательское описание;
сформированное определение;
итоговый системный промт;
модель, которая выполняла формирование;
дату изменения;
автора изменения.

Это необходимо для последующего анализа поведения агента.

#15. Эволюция агента

В карточке агента должна существовать отдельная вкладка:

Эволюция

Она должна позволять сопоставлять изменения определения агента с результатами его работы.

Минимально:

Версия 3
↓
изменён критерий завершения
↓
следующие операции
↓
изменение качества / ошибок / траектории

В дальнейшем это может быть связано с evaluation и накопленными свидетельствами Temporality.

#16. Встроенные агенты

Temporality поставляется с кураторскими шаблонами агентов:

Coder
Reviewer
QA
Researcher
DevOps

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

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

Пользователь не должен видеть YAML или внутреннюю структуру определения.

Агенты — кросс-функциональные и глобальные: они не привязываются к проектам. Специфика проекта не хранится в определении агента — она доставляется контекстной частью системного промта: релевантными знаниями (memory/knowledge), навыками и MCP-серверами того проекта, в котором происходит запуск.

#17. Требование к генератору

Генератор системного промта должен оптимизировать результат не по длине или полноте инструкции, а по следующим критериям:

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

#18. Итоговая концепция

Пользователь должен думать:

«Я создаю специалиста и объясняю ему, чем он занимается».

а не:

«Я программирую YAML-конфигурацию автономного агента».

Temporality должен сам превратить человеческое описание в технический контракт агента и затем скомпилировать из него системный промт.

Главная единица пользовательского интерфейса — агент и его ответственность, а не системный промт.