Payload CMS 4 научится объяснять ИИ, как работать с вашим проектом

В Payload CMS 4 появилась возможность задавать инструкции для ИИ непосредственно в конфигурации коллекций и редактировать их через административную панель. Эти инструкции автоматически передаются ИИ-агентам через MCP и CLI вместе со схемой данных.

Изменение появилось в двух пулл-реквестах, принятых 6 октября 2026 года, и вошло в предварительную версию Payload 4.0.0-canary.38, опубликованную 7 октября. На первый взгляд это небольшое дополнение к конфигурации CMS, но оно решает вполне конкретную проблему, возникающую при работе ИИ-агентов с реальными проектами.

Агент знает структуру базы, но не знает правил проекта

Предположим, у нас есть сайт на Payload CMS. В нём несколько коллекций: статьи, категории, авторы, страницы и медиатека.

Мы подключили к проекту ИИ-агента через официальный MCP-плагин. Теперь агент может получить описание коллекций, узнать доступные поля, прочитать существующие документы и, если позволяют права, создавать новые.

Технически у него есть всё необходимое для работы.

Но представим, что мы просим его опубликовать статью.

Агент получает схему коллекции posts и видит поля title, slug, content, excerpt, category и status. Он понимает типы данных, обязательность полей и допустимые значения.

Чего он не знает, так это внутренних правил редакции.

Например, что статьи должны начинаться с вводного абзаца без заголовка, изображения загружаются в отдельную коллекцию, а публикация возможна только после проверки редактором. Или что для определённого типа материала необходимо использовать конкретные блоки Lexical.

В схеме коллекции этих правил нет. Разработчик может прописать их в системном промпте агента, положить в AGENTS.md или объяснять при каждом обращении.

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

В Payload 4 предлагают другой подход: хранить инструкции рядом с описанием коллекции и отдавать их агенту вместе со схемой. Именно такую задачу решают изменения, вошедшие в canary.38.

Инструкции становятся частью конфигурации коллекции

У коллекций и глобальных сущностей Payload 4 появляется новое свойство llmInstructions. Оно принимает текст в формате Markdown.

Например, для коллекции статей можно задать такие правила:

import type { CollectionConfig } from 'payload'

export const Posts: CollectionConfig = {
  slug: 'posts',
  llmInstructions: `
# Правила работы со статьями

При создании статьи:
- Используй существующие категории, не создавай новые без явного запроса.
- Заполняй excerpt кратким описанием материала.
- Создавай новые материалы как черновики.
- Не публикуй статью без явного разрешения.

При редактировании:
- Сохраняй существующие изображения и автора.
- Не изменяй slug опубликованной статьи.
- Не удаляй блоки, которые не относятся к задаче.
`,
  fields: [
    {
      name: 'title',
      type: 'text',
      required: true,
    },
    {
      name: 'excerpt',
      type: 'textarea',
    },
    {
      name: 'content',
      type: 'richText',
    },
  ],
}

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

Принципиально важно другое: агенту больше не требуется заранее знать, где искать эти сведения.

Когда он запрашивает схему коллекции, Payload возвращает не только описание полей, но и рекомендации по работе с ними.

Поддержка реализована для getCollectionSchema и getGlobalSchema. Инструкции передаются через CLI и MCP, причём в MCP они доступны как в структурированном ответе, так и в текстовом блоке. Пустые инструкции в ответ не добавляются.

Редактор может изменить инструкции без участия разработчика

Следующее изменение интереснее с точки зрения повседневной эксплуатации.

Разработчики Payload добавили возможность управлять инструкциями непосредственно из административной панели. Для коллекций и глобальных сущностей появляется пункт Edit LLM instructions. Он открывает документ, связанный с соответствующей сущностью.

При этом инструкции разделены на две части.

Первая задаётся разработчиком в конфигурации Payload. В административной панели она доступна для чтения на отдельной вкладке, но изменить её нельзя ни через интерфейс, ни через API.

Вторая часть редактируется через интерфейс CMS. Она предназначена для дополнительных правил, которые могут меняться в процессе работы.

При формировании ответа для агента Payload объединяет обе части в Markdown.

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

Рассмотрим практический пример.

Разработчик один раз задаёт технические ограничения: какие поля нельзя изменять, как использовать блоки содержимого, какие операции запрещены без подтверждения.

Редактор сайта дополняет их собственными требованиями:

В октябре все публикации о новой линейке продукции должны содержать ссылку на страницу каталога. Не использовать старые названия моделей. Для анонсов в социальных сетях готовить отдельное описание длиной до 300 символов.

Теперь редактору не нужно обращаться к разработчику с просьбой изменить промпт агента.

При следующем получении схемы коллекции агент увидит актуальные инструкции.

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

Что получает агент через MCP

MCP позволяет подключать внешние инструменты и источники данных к ИИ-агентам.

Официальный MCP-плагин Payload предоставляет инструменты для чтения схем коллекций, поиска документов, создания и изменения записей, работы с глобальными сущностями и других операций. При этом доступные действия ограничиваются настройками плагина и системой Access Control самого Payload.

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

С появлением llmInstructions второй шаг становится значительно полезнее. Вместе с техническим описанием коллекции агент получает контекст, необходимый для корректного использования этой структуры.

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

В результате работа агента может выглядеть следующим образом:

1. Пользователь просит подготовить новую статью.
2. Агент запрашивает схему коллекции posts.
3. Payload возвращает описание полей и инструкции редакции.
4. Агент находит подходящую категорию и необходимые изображения.
5. Создаёт документ, учитывая правила проекта.
6. Оставляет материал черновиком, если этого требуют инструкции.

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

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

Инструкции не заменяют Access Control

Здесь важно разделять рекомендации агенту и реальные ограничения системы.

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

Если удаление опубликованных документов действительно должно быть запрещено, ограничение необходимо реализовать через Access Control, хуки или другую серверную логику Payload. То же относится к публикации, изменению пользователей, доступу к закрытым полям и операциям с конфиденциальными данными.

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

А всё, что связано с безопасностью и целостностью данных, по-прежнему должно контролироваться сервером.

Почему инструкции не стоит хранить только в AGENTS.md

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

Но представим систему, где разработчик работает с исходниками через Codex, редактор управляет материалами через другого агента, а менеджер обращается к Payload через MCP.

Не все эти агенты имеют доступ к репозиторию. Некоторые вообще не работают с файловой системой проекта.

Если правила публикации существуют только в AGENTS.md, их придётся отдельно передавать каждому клиенту.

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

Кроме того, у инструкций появляется понятный владелец. Технические ограничения поддерживает разработчик, редакционные требования — сотрудники, отвечающие за содержимое сайта.

Что ещё предусмотрели разработчики

В реализации есть несколько деталей, которые показывают, что думали не только о хранении текста.

Для каждой доступной коллекции или глобальной сущности Payload создаёт управляемый документ инструкций. Пользователи не могут произвольно создавать такие документы, удалять их или переназначать на другую коллекцию.

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

Управление инструкциями настраивается через корневой параметр llmInstructions в конфигурации Payload:

export default buildConfig({
  // ...
  llmInstructions: {
    // кому разрешено редактировать инструкции
    access: ({ req }) => req.user?.roles?.includes('admin') ?? false,
  },
})

Этим же параметром можно подменить редактор или вовсе отключить управление, передав llmInstructions: false, — тогда Payload не создаёт коллекцию-хранилище и пункты меню, а инструкции из конфигураций коллекций всё равно уходят агентам через CLI и MCP.

Есть и защита от ситуации, когда сохранённые инструкции по какой-то причине не удалось прочитать. В таком случае Payload возвращает инструкции, определённые в конфигурации, чтобы ошибка хранилища не мешала агенту получить схему.

Эти особенности описаны в реализации пулл-реквеста «Manage LLM instructions in the admin» и в новой странице документации LLM Instructions — ссылки в конце статьи.

Payload постепенно готовится к работе с ИИ-агентами

Новая возможность хорошо вписывается в общее направление развития Payload.

Разработчики уже поддерживают официальный MCP-плагин, инструменты CLI для получения схем, а также файл AGENTS.md с инструкциями для агентов, работающих с исходным кодом самого Payload.

В официальном анонсе Payload 4 команда отдельно описывает планы на MCP: сегодня настройка требует слишком много ручных шагов — включение инструментов, создание API-ключей, проверка прав, обновление MCP JSON. Цель для четвёртой версии — сделать инструменты отключаемыми по умолчанию, улучшить работу с API-ключами и правами, сократить количество действий до «добавь плагин, укажи MCP JSON — и работай», чтобы свежий проект работал с MCP сразу из коробки.

На этом фоне llmInstructions выглядит логичным продолжением — и, что характерно, «поддержка инструкций конкретного проекта» в этом списке планов уже реализована.

Раньше агент мог получить описание того, какие данные существуют и какие операции доступны. Теперь Payload начинает предоставлять ему ещё и сведения о том, как принято работать с этими данными в конкретном проекте.

Разница существенная.

Для небольшого сайта с десятком статей это может оказаться избыточным. Но если Payload используется как основа информационной системы с несколькими ролями, сложной структурой документов и автоматизированными процессами, возможность централизованно управлять инструкциями становится весьма полезной.

Когда можно попробовать

Функциональность появилась в Payload 4.0.0-canary.38 от 7 октября 2026 года. Это предварительная версия четвёртой ветки. Для рабочих проектов на Payload 3 переходить на неё ради новой функции пока не стоит.

Однако на отдельном тестовом стенде уже можно изучать конфигурацию llmInstructions, управление инструкциями в административной панели и их передачу через MCP.

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

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

И здесь, пожалуй, самое интересное в Payload 4: правила работы с содержимым постепенно становятся частью самой CMS, а не набором промптов, разбросанных по разным агентам и приложениям. Для систем, в которых ИИ уже участвует в создании и изменении данных, это вполне практическое направление развития.

Правило: инструкции для ИИ-агентов (llmInstructions) описывают принятый порядок работы с контентом, а не безопасность: редакционные правила и предпочтения — в llmInstructions, всё, что должно быть запрещено гарантированно, — через Access Control, хуки и серверную логику.

Источники