Универсальные руководства

#### §2.04 Агенты: модели и протоколы подключения

**Время:** 45 мин чтение + 30 мин

**В одном предложении:** Человек думает, что агент — это умный собеседник, который отвечает на вопросы, а на самом деле агент без протоколов подключения — это теоретик, который говорит, но не делает, и разница между декоративным чат-ботом и рабочим агентом определяется не моделью, а контуром действия.

**Мем, который снимается.** «У меня есть Claude Code, он умеет почти всё: писать код, анализировать тексты, искать ошибки. Я просто спрашиваю, и он делает.» На самом деле Claude Code без MCP — это умный собеседник внутри терминала. Он может предложить, но не может проверить. Может написать, но не может закоммитить. Может найти, но не может запустить. MCP — это протокол, который превращает теоретика в практика: агент получает доступ к файловой системе, к базе данных, к API, к Git. Без MCP агент работает в вакууме. С MCP он работает в вашем контуре.

**Понятия.** Агент — действующее лицо в IWE: модель ИИ + настройки + инструменты. Модель определяет способность мыслить, настройки — контекст и ограничения, инструменты — границы действия. MCP — Model Context Protocol, протокол связи между агентом и внешними системами. MCP делает агента способным действовать: читать файлы, выполнять команды, обращаться к базам данных, взаимодействовать с другими сервисами. Без MCP агент ограничен разговором. С MCP агент ограничен только контуром, который задал пилот. Контур — граница, внутри которой агент может действовать. За пределами контура агент не выходит, не запрашивает разрешения, не имеет доступа.

**Объяснение.** Различие между моделью и агентом критично. Модель — это мозг: GPT-4, Claude, Gemini. Один и тот же мозг может быть в разных агентах. Агент — это личность: Навигатор, который ведёт по траектории; Портной, который собирает personal-guide; Диагност, который оценивает состояние; Оркестратор, который управляет ритмом. Каждый агент использует одну и ту же модель, но с разными настройками, протоколами и инструментами. Навигатор имеет доступ к Pack и истории развития. Портной — к шаблонам и RCS-профилю. Диагност — к метрикам и чеклистам. Оркестратор — к календарю и трекеру. Разделение по контурам важно: если Навигатор получит доступ к метрикам Диагноста, он начнёт диагностировать вместо навигации. Если Портной получит доступ к календарю Оркестратора, он начнёт планировать вместо проектирования. Контур защищает агента от размывания роли. MCP — это не просто «подключение к интернету». Это архитектура разрешений: какие команды агент может выполнять, какие файлы читать, какие системы трогать. Пилот проектирует MCP так же осознанно, как проектирует Pack: каждое разрешение должно иметь функцию, каждая функция — поддерживать протокол.

**На практике.** Практика «Карта агентов» (30 мин):

1. Перечислите всех агентов, которых вы используете в IWE: Claude Code, веб-интерфейсы, специализированные боты. Не менее трёх. (5 мин)
2. Для каждого агента определите: какие MCP-серверы или инструменты подключены? Что агент может делать, а что — только предлагать? (15 мин)
3. Проверьте контур: есть ли агент, который имеет доступ к тому, что ему не нужно? Или, наоборот, не имеет доступа к тому, что нужно? Запишите одно изменение. (10 мин)

**Типичный кейс.** Менеджер продукта сорока лет использовал один и тот же чат GPT для всех задач: стратегия, анализ данных, переписка, планирование. Результат: агент путал контексты, предлагал решения из области анализа для стратегических задач, а стратегические рамки — для операционных. После разделения на агентов с разными MCP ситуация изменилась: стратегический агент имел доступ к Pack с принципами и истории решений, аналитический — к базе данных метрик, операционный — к календарю и таск-трекеру. Каждый агент работал в своём контуре. Качество выросло, а время на уточнение контекста сократилось вдвое.

**Типичная ошибка.** «Один агент на все задачи — проще, не нужно переключаться.» Это ловушка универсальности. Один агент в одном контуре не может быть и стратегом, и аналитиком, и секретарём. Результат — размывание роли, потеря контекста, средние решения. Другая ошибка: «Чем больше MCP у агента, тем лучше.» Нет. Избыточные разрешения создают риски: агент может случайно удалить данные, изменить конфигурацию, отправить сообщение. Контур должен быть минимально необходимым: агент делает то, для чего создан, и не более.

**Степени мастерства:**

1. Объяснение. Могу назвать трёх агентов в своей IWE и объяснить, чем они отличаются. Критерий перехода: составил список агентов с их ролями.
2. Умение. Настроил разделение контуров для двух агентов: каждый имеет доступ только к нужным инструментам. Критерий перехода: три дня работал с разделёнными агентами и заметил снижение путаницы.
3. Навык. Системно проверяю и корректирую контуры агентов: добавляю MCP при новых задачах, убираю при завершении. Критерий перехода: коллега заметила, что мои агенты «не путаются в контекстах».
4. Мастерство. Проектирую агентов под задачи: создаю новых агентов с нужными MCP, архивирую устаревших. Критерий перехода: другой человек использовал вашу архитектуру агентов для своей IWE.

**Проверка себя.**

- Могу назвать трёх агентов в своей IWE и для каждого сказать: какая модель, какие MCP, какой контур
- Знаю, какие команды может выполнять каждый агент, а какие — только предлагать
- Проверял контуры агентов за последний месяц: убрал лишнее, добавил нужное
- Агенты не путают контексты между задачами: стратегия не смешивается с операционкой
- Я могу создать нового агента под конкретную задачу за менее чем десять минут

**На практике.** Откройте вашего основного агента. Посмотрите на список подключенных инструментов или MCP. Задайте вопрос: «Если бы я дал этому агенту доступ только к трём вещам, какие бы я выбрал?» Ответьте. Затем спросите: «А что подключено сейчас лишнего?» Уберите одно лишнее разрешение. Это и есть проектирование контура.

**См. также:** AI-ассистенты: , Экзокортекс: .

**Что дальше.** Следующий подраздел — об обратной связи: как IWE оценивает свою работу и сигнализирует о проблемах.

← Предыдущий раздел Следующий раздел →