Выход, который предлагает ряд практиков, звучит контринтуитивно: давать ИИ меньше контекста за раз, но правильно структурированного и в правильный момент. MCP — Model Context Protocol — обсуждается в этом ключе не как очередной способ вызывать инструменты, а как транспорт для поэтапной доставки знаний и рабочих правил. Разберём, почему это разграничение важно и где оно может не сработать.
Как файлы инструкций превращаются в свалку
Паттерн знаком многим, кто работал с AI-ассистентами в команде. Сначала появляется AGENTS.md или CLAUDE.md с несколькими лаконичными правилами. Потом кто-то добавляет соглашения по коду. Потом архитектурные ограничения. Потом доменные знания, workflow-заметки, правила тестирования, предупреждения о рисках. Через несколько месяцев файл разрастается до нескольких сотен строк, и команда вынуждена регулярно «сжимать» его, чтобы ИИ вообще мог с ним работать.
Это не техническая проблема конкретного инструмента — это структурная ловушка. Чем больше контекста вы заливаете в одно место, тем ниже сигнал на единицу текста. Важные правила тонут рядом с устаревшими заметками. Стабильные инварианты смешиваются с волатильным состоянием проекта. ИИ получает всё сразу и вынужден самостоятельно решать, что из этого сейчас релевантно — задача, с которой он справляется хуже, чем принято думать.
Результат предсказуем: качество вывода начинает зависеть не от возможностей модели, а от того, насколько тщательно конкретный пользователь поддерживает свой локальный промпт. Это не масштабируемая командная система.
Четыре слоя, которые часто путают
Прежде чем говорить о решениях, полезно развести по смыслу четыре механики, которые в обсуждениях нередко смешиваются в одну кашу:
| Слой | Что делает | Типичный вопрос, который решает | Что не решает |
|---|---|---|---|
| RAG | Ищет и подставляет релевантные фрагменты из базы знаний | «Какой документ отвечает на этот вопрос?» | Рабочие правила, критерии завершения задачи |
| Tool calling / RPC | Позволяет ИИ вызывать внешние функции и API | «Как выполнить конкретную операцию?» | Доменные суждения, контекст о том, зачем это делается |
| MCP | Транспорт для структурированной доставки контекста, документов, скиллов и операционных контрактов | «Какой контекст нужен именно сейчас для этой задачи?» | Сам по себе не маршрутизирует и не знает, что выбрать |
| Semantic routing | Маршрутизация по смыслу запроса к нужному скиллу или workflow | «К какому типу работы относится этот запрос?» | Не заменяет человека-редактора процесса |
RAG и MCP в прикладных сценариях не конкурируют напрямую: RAG лучше работает со статичными знаниями, MCP — с живыми данными и операциями, требующими управляемого доступа. Путаница возникает, когда MCP воспринимают просто как «RAG, только через другой протокол», хотя структурная идея другая.
Bootloader вместо базы знаний
Центральный тезис подхода, который заслуживает внимания: AGENTS.md должен быть загрузчиком, а не хранилищем знаний. Его работа — сообщить ИИ-клиенту, где живёт контекст проекта, к какому MCP-серверу подключиться и что загрузить при старте. Не более.
Детальные знания, рабочие правила и доменные скиллы должны жить в управляемом, подключаемом слое. Когда контекст доставляется через MCP, архитектура меняется принципиально: пользователь больше не обязан локально поддерживать гигантский промпт, копировать актуальные правила и следить за версионированием инструкций. Клиент обращается к серверу и получает нужный пакет.
Критически важна идея пакетов, а не дампов. Вместо того чтобы залить всё сразу, контекст доставляется порциями с чёткой ролью каждой:
flowchart LR A[Bootloader\nAGENTS.md] --> B[Startup context\nинварианты] B --> C[Semantic routing\nопределение типа задачи] C --> D[Domain Skill\nзнания + правила] D --> E[On-demand state\nволатильные данные] E --> F[Closure rules\nкритерии завершения]
Каждый этап загружает только то, что нужно именно сейчас. Startup context содержит только инварианты. Скилл — знания и процедуру для конкретного типа работы. Runtime-инструменты подтягивают волатильное состояние только по запросу. Closure rules определяют, когда задачу можно считать завершённой.
Автоматизация команд против распределения суждений
Здесь возникает разграничение, которое легко пропустить: разница между автоматизацией команд и распределением суждений.
Большинство современных AI-скиллов командно-ориентированы: выполни команду, проверь файл, сгенерируй diff, вызови API. Это полезно, но это микроменеджмент с другим интерфейсом. Человек по-прежнему решает, какую команду запустить, что считать достаточным результатом и завершена ли задача.
Настоящая сложность профессиональной работы редко в исполнении. Она в суждениях: совместимо ли это изменение с существующим дизайном? Полностью ли понято требование? Какие документы авторитетны? Что ещё неизвестно? Безопасно ли продолжать?
Доменный скилл, спроектированный как бизнес-единица работы, отвечает на эти вопросы структурно. Он содержит не только инструкции, но и критерии неизвестного, которое останавливает работу; требования к доказательствам перед закрытием; правила эскалации; запрещённые допущения. Скилл распределяет суждения, а не только команды. Это делает вывод более предсказуемым, потому что правила завершения и критерии качества едины для всей команды, а не зависят от того, насколько хорошо поддерживает промпт конкретный пользователь.
Где semantic routing вписывается в схему
Если скиллы — это бизнес-единицы работы, следующий вопрос: как система понимает, какой скилл нужен сейчас? Именно здесь появляется semantic routing — маршрутизация по смыслу запроса, а не по точному совпадению команды.
Разница принципиальная. Командная маршрутизация спрашивает: «Какой инструмент вызвать?» Семантическая — «К какому типу работы относится этот запрос?» Если пользователь описывает намерение, а система сама определяет подходящий скилл, уровень делегирования становится выше: человек управляет целью, а не каждым шагом.
Важная оговорка: semantic routing в текущем виде — это не магия и не отраслевой стандарт. Существующие реализации, включая отдельные библиотеки для маршрутизации, требуют тонкой настройки и не устраняют потребность в человеке, который следит за качеством процесса. Это decision layer, который работает лучше при хорошо спроектированных скиллах и хуже при размытых границах между ними.
Практический чеклист: когда локальный промпт уже стал проблемой
Несколько признаков того, что файл инструкций превратился в плохо управляемую базу знаний:
- Вы регулярно «сжимаете» промпт, чтобы он вместился в контекстное окно
- Разные члены команды поддерживают разные версии одних и тех же правил локально
- Новый участник команды не понимает, какие правила актуальны, без объяснений старожилов
- ИИ игнорирует правила, которые есть в файле, но находятся далеко от начала
- Нет чётких критериев завершения задачи — решение принимается ситуативно каждый раз
Если несколько пунктов совпадают, структурная проблема уже есть. MCP с доменными скиллами — один из возможных ответов, но не единственный и не универсальный. Польза подхода существенно зависит от зрелости процессов команды и от того, есть ли ресурсы на спроектированные скиллы. Небольшой команде с простыми задачами хорошо написанный локальный промпт может быть дешевле и надёжнее.
Что реально меняется, а что остаётся открытым
MCP как протокол существует, и базовое разграничение — RAG для статичных знаний, MCP для живых данных и управляемых операций — имеет практическую ценность. Идея bootloader-файла, который указывает на систему контекста, а не является ею, выглядит здраво.
Но честный анализ требует признать: нет независимых сравнений, показывающих, насколько staged context delivery стабильно лучше альтернатив в реальных командах. MCP не стал доминирующим стандартом для командной работы с ИИ. Semantic routing в текущих реализациях требует ручной настройки и не устраняет вариативность вывода сам по себе.
Ключевой вывод скромнее, чем маркетинговые заявления вокруг темы: ИИ-инфраструктура становится полезнее не тогда, когда ей дают больше текста, а когда ей дают правильный текст в правильный момент с ясными правилами завершения. Это верно независимо от того, реализовано ли это через MCP, хорошо структурированный RAG или тщательно спроектированные локальные промпты. MCP предлагает архитектурно чистый способ это организовать — но архитектура без дисциплины управления контекстом не решает проблему, она только меняет место, где проблема накапливается.
