Как собрать контекст для ИИ-агента: MCP, ресурсы, инструменты и границы
ИИ-агенту не нужен "весь контекст вообще". Если дать ему все документы, все таблицы, все переписки и все инструменты, он не станет умнее автоматически. Он станет опаснее, медленнее и менее управляемым. Хороший контекст устроен иначе: агент получает нужные ресурсы, понятные инструменты, подсказки к работе и границы, где он обязан остановиться.
Именно так полезно смотреть на MCP, Model Context Protocol. Не как на модную аббревиатуру, а как на язык подключения агента к миру: вот что можно читать, вот какие действия можно выполнять, вот какие подсказки доступны, вот где нужны права и проверка. Официальная документация MCP server concepts описывает сервер как слой, который может предоставлять агентам контекст и возможности через ресурсы, инструменты и шаблоны подсказок.
Для бизнеса это означает простую вещь: компания постепенно становится не только набором людей и файлов, но и набором интерфейсов для ИИ-агентов. Не обязательно сразу строить публичный MCP-сервер. Сначала достаточно описать, какие данные и действия вообще должны быть доступны агенту.
Почему папки и чаты не равны контексту
Обычная ошибка звучит так: "мы загрузим агенту всю базу знаний". Но база знаний без структуры быстро превращается в шум. Агенту трудно понять, что актуально, что устарело, чему можно доверять, где черновик, где финальный документ, какие действия разрешены, а какие только обсуждаются.
Контекст должен отвечать на рабочие вопросы: где лежит источник правды, как получить свежие данные, какой инструмент можно вызвать, что делать при конфликте, какую операцию нельзя выполнять без человека. Тогда агент работает не с кучей файлов, а с понятным рабочим окружением.
Главное:MCP важен не тем, что добавляет еще один технический слой. Он заставляет описать компанию как набор ресурсов, инструментов и границ. Это ровно то, что нужно агенту для нормальной работы.
Из каких частей собрать агентный контекст
В MCP есть полезное разделение. Ресурсы дают агенту данные. Инструменты позволяют выполнить действие. Подсказки помогают начать типовой сценарий. Спецификация MCP tools отдельно подчеркивает инструментальный слой: модель может не только читать, но и вызывать операции через описанные интерфейсы.
Для практической работы это можно перевести в такую карту.
| Слой | Что это в реальной компании | Пример |
|---|---|---|
| Ресурсы | данные, которые агент может читать | регламент, карточка клиента, статья, таблица, лог |
| Инструменты | действия, которые агент может выполнить | найти письмо, создать задачу, проверить очередь, собрать отчет |
| Подсказки | типовые рабочие сценарии | "подготовь ревью статьи", "собери handoff", "найди риск" |
| Права | кто и когда может выполнять действие | читать можно всем агентам, публиковать только после ревью |
| Границы | зоны, где агент должен остановиться | деньги, договоры, персональные данные, публичная отправка |
Если такой карты нет, агент будет каждый раз изобретать процесс. Если карта есть, человек может улучшать не только один ответ, а саму рабочую среду.
Как применить это без большого проекта
Начать можно с одной функции. Например, "агент помогает редакции готовить статью". Ему не нужен весь бизнес. Ему нужны источники, черновик, правила языка, список запрещенных утечек, команда ревью, публикационный лог и запрет на прямую отправку в социальные каналы без прохождения gates.
В ONFF это уже похоже на живую практику. Есть отдельные файлы состояния, источники, черновик, SEO-поля, манифест медиа, ревью текста, аудит публичного тела и очередь ArticleFactory. Это можно воспринимать как локальный контекстный интерфейс для агента: не вся память мира, а ровно те поверхности, через которые работа становится проверяемой.
Рабочая карточка
Когда использовать: когда ИИ-агент должен регулярно работать с проектом, документами, клиентами, публикациями, кодом или операционными данными.
Что подать на вход: список источников правды, доступные действия, запреты, типовые сценарии, правила обновления.
Что сделать по шагам:
- Выбрать один рабочий сценарий, а не всю компанию сразу.
- Выписать ресурсы, которые агенту можно читать.
- Выписать инструменты, которые агенту можно вызывать.
- Описать подсказки для типовых запусков.
- Отдельно назвать запретные зоны и действия только после ревью.
- Добавить лог: что агент сделал, когда и на основании чего.
Какой результат получить: агентный контекст, который можно подключать повторно и улучшать без пересказа с нуля.
Как проверить качество: агент делает задачу по правилам, не просит лишний контекст, не лезет в закрытые зоны, оставляет понятный след работы.
Когда не использовать: если задача разовая, маленькая и не требует доступа к данным или инструментам.
Какой навык из этого собрать: навык проектирования контекста для агента. Человек учится давать не "все подряд", а нужные рабочие поверхности.
Где граница
Важно не романтизировать MCP. Протокол не решает сам по себе качество данных, права доступа, ответственность и безопасность. Если внутренняя база грязная, агент получит грязный контекст. Если инструмент опасный, агент сможет опасно ошибиться. Если нет ревью, публичный результат может уйти раньше проверки.
Поэтому первый слой всегда организационный: какие данные считаются источником правды, какие действия безопасны, где человек нужен обязательно. Уже потом это можно превращать в MCP-сервер, локальный набор tools, папку ресурсов или навык Codex. В статье про память ИИ-агента мы разбирали похожую мысль: агенту важна не просто память, а проверяемая структура опыта.
Хороший контекст похож на рабочее место. На столе лежат нужные документы, рядом есть инструменты, на опасных кнопках стоят крышки, а после работы остается след. Именно так ИИ-агент превращается из собеседника в участника процесса.
