Всё больше читателей вашей документации — не люди. Ассистенты для программирования открывают документацию, чтобы ответить на вопрос «как подключить X». Агенты поддержки читают статьи справки и отвечают на вопросы пользователей. Агенты-исследователи пересказывают журналы изменений, когда сравнивают поставщиков. Сервисы хостинга документации уже сообщают, что большая доля трафика к ней приходит от ИИ-агентов, а не из браузеров. Если ваш контент понятен только человеку, который листает готовую страницу, вас не видно там, где всё чаще решают, порекомендовать ваш продукт, встроить его или вычеркнуть из списка.
Чтобы контент был готов для агентов, нужны три слоя: индекс, который легко найти, протокол, с которым умеет работать машина, и контент с такой структурой, что его стоит читать.
Слой 1: llms.txt — индекс, который ищут агенты
llms.txt — соглашение по образцу robots.txt: Markdown-файл в корне сайта (yourapp.com/llms.txt), который объясняет агентам на языковых моделях, что это за сайт и где лежит важный контент. robots.txt говорит, чего краулерам делать нельзя, а llms.txt — что стоит прочитать: короткое описание продукта, а за ним отобранный список ссылок на главные страницы — разделы документации, справочник API, журнал изменений, цены.
У хорошего файла два свойства:
Отобран, а не склеен. Файл — это карта, а не свалка. Ссылайтесь на канонические страницы документации: агенты сами перейдут по ссылкам и прочитают страницы. (Есть и парное соглашение —
llms-full.txt: полный текст для агентов, которым нужно всё за один запрос. Оно полезно, но сначала стоит довести до ума индекс.)Генерируется, а не правится вручную. Как и карта сайта, llms.txt, который правят руками, устаревает. Генерируйте его из того же API контента, из которого строятся ваши страницы, — тогда опубликованная статья сама попадёт в индекс. Если контент живёт в контент-бэкенде, это небольшой серверный маршрут: получить списки, вывести ссылки в Markdown.
Затраты: полдня. Результат: ассистенты в IDE и агенты-исследователи, которые запрашивают /llms.txt (а они делают это уже сегодня), получают ваше описание продукта, а не догадку.
Слой 2: MCP — от чтения к действиям
Model Context Protocol (MCP) — протокол, который становится стандартом для подключения ИИ-агентов к внешним системам как к инструментам. llms.txt помогает ваш контент найти, а через MCP-сервер с ним работают: агент вызывает search_entries с вопросом пользователя, get_entry, чтобы получить статью целиком, или запрашивает список записей журнала изменений. Это структурированные операции со структурированными данными на выходе, а не разбор HTML.
Вот как это меняет круг тех, кто работает с вашим контентом:
Агент разработчика обращается к вашему центру помощи и журналу изменений прямо из редактора, пока тот подключает ваш API.
Агент-автор в команде пишет запись журнала изменений, сохраняет её черновиком, а публикует человек. Если сервер даёт инструменты для редактирования, работу с контентом можно поручить агенту.
Ваши внутренние агенты разбирают посты обратной связи или отвечают на вопросы поддержки, опираясь на тот же контент, без отдельной интеграции.
Рынок CMS быстро пришёл к этому: за последний год MCP-серверы выпустили несколько крупных контент-платформ, и при выборе платформы MCP-сервер уже стал пунктом в списке требований. В Kookee такой сервер есть: MCP-сервер над контентом проекта. Каждый участник команды подключает его своим личным токеном, и токен даёт только чтение, если участник сам не выберет «Чтение и запись». На сервере есть инструменты чтения (список, поиск, получение) и инструменты редактирования (создание, изменение, публикация, категории, разбор обратной связи), так что обе половины цикла работают сразу: агенты читают ваш контент и помогают его создавать. На какой бы платформе вы ни работали, при выборе вопрос один: может ли агент работать с моим контентом через инструменты, с правами того человека, от чьего имени он действует?
Слой 3: контент, который стоит потраченных токенов
Индексы и протоколы доставляют контент агентам, а от структуры зависит, что они с ним сделают. К счастью, агентам помогают те же привычки, что уже помогали людям и поисковым системам:
Один вопрос на статью, ответ в начале. Агенты извлекают фрагменты. Статья, которая начинается с ответа, даёт полезный фрагмент. Статья, где ответ спрятан под вступлением, даёт шум.
Настоящие заголовки и постоянные адреса. И поиск, и цитирование зависят от разделов, на которые можно сослаться. Если агент цитирует
yourapp.com/help/billing/refunds#timeline, пользователь может проверить его ответ.Поля вместо договорённостей в тексте. Запись журнала изменений с типом («Исправление») и полем версии — это данные, которые можно фильтровать. Если те же сведения спрятаны в абзаце, их сначала придётся оттуда извлечь.
Текст, а не скриншоты текста. Большинство конвейеров поиска не видят, что написано на картинке. Скриншот — иллюстрация, и шаг инструкции не должен держаться только на нём.
Честная свежесть. Устаревшая документация сбивает агентов (и их пользователей) с толку так же, как людей, только в больших масштабах. Даты у записей и живой журнал изменений подсказывают агентам, что новее, и они выбирают актуальный контент.
Один приём появился только вместе с агентами: статьи для внутреннего контекста. Часть знаний — известные ограничения, детали обходных путей, тонкости миграции — вы хотите отдать ИИ-поддержке, но не публиковать в центре помощи, который видят клиенты. Если контент-бэкенд умеет показывать статью только ИИ, ответы поддержки становятся точнее публичной документации, а сами статьи не попадают в публичный центр помощи.
Что это даёт на практике
Готовность к агентам звучит абстрактно, пока не разберёте один путь целиком. Разработчик спрашивает ассистента: «Как получить результаты постранично в {ваш продукт}?» Ассистент запрашивает /llms.txt, по ссылке переходит в документацию API, читает раздел о пагинации и выдаёт рабочий код со ссылкой на источник. Этот ответ построен либо на вашем контенте, либо на ответе со Stack Overflow двухлетней давности. Умножьте это на каждое решение об интеграции, каждое сравнение поставщиков и каждый вопрос в поддержку, которые теперь проходят через агента, и станет ясно, что на кону.
Практичный порядок действий
Сначала исправьте структуру: ответ в начале статьи, заголовки, поля с типами. Документация для людей станет лучше уже сейчас, а всё остальное строится на этом.
Запустите
/llms.txt, который генерируется из API контента.Добавьте MCP-сервер или возьмите готовый — у своей контент-платформы, если он у неё есть.
Следите в логах за user-agent агентов и запросами к llms.txt. Пусть реальный трафик подскажет, что развивать дальше.
Ни один из этих шагов не большой, и их эффект складывается. Тот же структурированный контент из API, из которого собираются ваши страницы и на котором работает поиск, делает вас понятными для аудитории, которая у вашей документации растёт быстрее всех.