§7.03 Проектирование протоколов подключения
Время: 45 мин чтение + 30 мин
В одном предложении: Человек думает, что возможности агента ограничены тем, что заложили разработчики модели, а на самом деле агент расширяется через проектирование подключений: хороший MCP-сервер превращает агента из универсального помощника в специалиста по вашей задаче.
Мем, который снимается. «Агент умеет то, что умеет. Если ему не хватает функции — придётся ждать, пока разработчики добавят.» Это представление агента как закрытой коробки. На самом деле MCP (Model Context Protocol) позволяет подключать к агенту внешние инструменты: базы данных, API, файловые системы, специализированные сервисы. Агент не меняется, но его контекст и возможности расширяются через подключения. Проектирование MCP — это не программирование модели, это проектирование интерфейса между агентом и вашей специфической средой.
Понятия. MCP-дизайн — проектирование интерфейса взаимодействия агента с внешними инструментами через Model Context Protocol. Параметры вызова — аргументы, которые агент передаёт инструменту для выполнения задачи: входные данные, условия, ограничения. Обработка ошибок — стратегия поведения агента при сбое подключения: fallback-варианты, логирование, уведомление пилота. Хороший MCP-дизайн характеризуется тремя свойствами: простота (минимум параметров для основного сценария), безопасность (проверка прав доступа и валидация входных данных), документированность (описание параметров, ошибок и примеров вызова).
Объяснение. MCP расширяет возможности агента без изменения самой модели. Это принципиально: вы не переучиваете агента, вы даёте ему доступ к тому, что уже есть в вашей среде. Проектирование начинается с вопроса: «Какую задачу агент не может решить сейчас, но мог бы, если бы имел доступ к X?» X может быть база данных с историей проектов, API внешнего сервиса, файловая система с шаблонами или внутренняя база знаний команды. Следующий шаг — определение типа инструмента: чтение, запись, вычисление, поиск. Каждый тип требует своих параметров вызова и своей стратегии безопасности. Инструмент чтения безопасен: агент не может повредить данные. Инструмент записи требует валидации: что именно записываем, кто авторизовал, есть ли бэкап. Обработка ошибок критична: если подключение к базе данных упало, агент должен либо сообщить пилоту, либо переключиться на локальную копию, либо отложить задачу. Без обработки ошибок один сбой превращается в каскадный отказ. Хороший MCP-сервер проектируется как контракт: агент знает, что может ожидать от инструмента, а инструмент гарантирует предсказуемое поведение в пределах контракта.
На практике. Практика «Спроектируй свой MCP» (30 мин):
- Выберите одну задачу, которую вы регулярно делегируете агенту, но каждый раз приходится передавать контекст вручную. Опишите: что агенту не хватает для самостоятельного выполнения? (10 мин)
- Опишите потенциальный MCP-сервер: тип инструмента (чтение/запись/поиск), три ключевых параметра вызова, одну стратегию обработки ошибок, одно ограничение безопасности. (10 мин)
- Зафиксируйте описание в Pack в формате: название, тип, параметры, ошибки, безопасность. Если есть навык программирования — реализуйте прототип. Если нет — передайте описание разработчику или сохраните как спецификацию для будущего. (10 мин)
Типичный кейс. Руководитель команды ежедневно просил агента: «Посмотри статус задач в Linear, собери прогресс по каждому проекту и сформируй сводку.» Каждый раз агенту приходилось объяснять структуру проектов, приоритеты и формат сводки. Руководитель спроектировал MCP-сервер «Linear-Bridge»: тип — чтение с фильтрацией; параметры — project_id, date_range, status_filter; ошибка — если API недоступно, использовать последнюю закэшированную сводку; безопасность — только чтение, токен с доступом к конкретным проектам. После подключения агент сам формировал сводку по запросу «дай статус» без дополнительного контекста. Экономия — 15 минут в день, 75 часов в год.
Типичная ошибка. «MCP — это сложно, нужно быть программистом.» Люди склонны думать так, потому что путают реализацию и проектирование. Проектировать MCP может любой пилот, который понимает задачу. Реализация — да, требует кода, но спецификация — это половина работы, и без неё программист сделает не то. Другая ошибка: «Сделаю универсальный MCP на все случаи.» Универсальность размывает контракт: слишком много параметров, неясные границы, непредсказуемое поведение. Лучше три простых MCP для конкретных задач, чем один сложный на всё.
Степени мастерства:
- Объяснение. Могу объяснить, что такое MCP, и назвать три элемента его дизайна: тип, параметры, обработка ошибок. Критерий перехода: описал один потенциальный MCP-сервер для своей задачи.
- Умение. Проектирую MCP-серверы по шаблону: определяю тип, параметры, ошибки, безопасность. Критерий перехода: спроектированный MCP реализован и работает для одной задачи.
- Навык. Замечаю задачи, где агенту не хватает контекста, и автоматически думаю: «какой MCP здесь нужен?» Критерий перехода: создано три MCP-сервера, которые используются регулярно.
- Мастерство. Проектирую экосистему подключений: MCP-серверы работают в связке, данные перетекают из одного в другой, ошибки одного обрабатываются другим. Критерий перехода: другой пилот подключился к моей экосистеме MCP и заработал без моего участия.
Проверка себя.
- Могу описать один MCP-сервер для своей текущей задачи: тип, параметры, ошибки, безопасность
- В последнем месяце я спроектировал или использовал хотя бы одно новое подключение для агента
- Я замечаю, когда трачу время на передачу контекста агенту вручную, хотя можно было бы формализовать через MCP
- Мои описания MCP хранятся в Pack, а не только в голове
На практике. Возьмите задачу, которую сегодня делегировали агенту. Перечислите информацию, которую пришлось передать агенту вручную. Какую часть этой информации можно было бы сделать доступной через подключение? Опишите это как MCP. Это первый шаг к проектированию подключений.
См. также: Репозитории IWE — PD.GUIDE.3.S2.SS2, Множественные агенты — PD.GUIDE.3.S4.SS4.
Что дальше. Следующий подраздел — об извлечении и фиксации знания: как не терять то, что узнали, на рубеже каждого рабочего продукта.