Переосмысление ценности MCP
На всякий случай, MCP — это стандартный протокол подключения тулов к агентам.
Идея достаточно очевидна: унифицировать интеграции с LLM, чтобы можно было подключать знания из разных систем. Но на практике возникают проблемы:
1) Если API возвращает большой ответ, то нужно как-то предобрабатывать запрос. Следовательно, интерфейс уже не такой универсальный, и на практике он порождает слой проксей, которые подготавливают данные для конкретной задачи.
2) Возникает дополнительное препятствие для внедрения агентов, так как нужно строить платформу для MCP и продумывать им ролевые модели. Из-за этого приходится делать ооочень много технических приседаний и проходить не меньше согласований, а по итогу выхлоп может быть нулевым.
До недавнего времени я был убежден в том, что для этой вашей «ИИ-трансформации» компаниям нужно в обязательном порядке строить MCP-хабы, но переосмыслил эту гипотезу из-за одного практического примера.
Мы занимались автоматизацией тестирования приложения на Dev-среде, а для этого нужно было научить агента катить на Dev. У нас настроены динамические окружения, так что каждая ветка может существовать изолированно. Мы подключили GitLab MCP к агенту с выделенным пользователем с ролью developer на проекте. Вот только в MCP не оказалось возможности запускать пайплайны, и сам агент в процессе размышления попытался найти GitLab-токен с правами запуска пайпов. И это натолкнуло меня на мысль: а что, если агенту просто дать GitLab-токен пользователя с ограниченными правами и вызвать API напрямую из агента? Очевидно, это решение сработало.
В этот момент и произошло переосмысление: а зачем нам вообще нужен MCP? Почему мы не можем использовать текущие API для интеграции с уже продуманной (и, главное, принятой) ролевой моделью? Агенты поумнее вообще могут в реальном времени писать скрипты интеграции и сразу готовить формат, как себе нужно, а для агентов потупее можно заранее писать набор тулов для интеграции. С помощью агентов поумнее, само собой.
В итоге MCP-хаб (маркетплейс интеграций) превращается в набор скиллов (.md-файликов), который описывает, каким образом и с какой системой интегрироваться. Так в итоге еще и появляется самоактуализирующаяся документация. Актуализация происходит в момент, когда агент пытается написать интеграцию: если API не работает как описано, то он может сделать PR на обновление скилла, а овнеры уже могут принять или отклонить этот запрос.
#александр_опрышко
На всякий случай, MCP — это стандартный протокол подключения тулов к агентам.
Идея достаточно очевидна: унифицировать интеграции с LLM, чтобы можно было подключать знания из разных систем. Но на практике возникают проблемы:
1) Если API возвращает большой ответ, то нужно как-то предобрабатывать запрос. Следовательно, интерфейс уже не такой универсальный, и на практике он порождает слой проксей, которые подготавливают данные для конкретной задачи.
2) Возникает дополнительное препятствие для внедрения агентов, так как нужно строить платформу для MCP и продумывать им ролевые модели. Из-за этого приходится делать ооочень много технических приседаний и проходить не меньше согласований, а по итогу выхлоп может быть нулевым.
До недавнего времени я был убежден в том, что для этой вашей «ИИ-трансформации» компаниям нужно в обязательном порядке строить MCP-хабы, но переосмыслил эту гипотезу из-за одного практического примера.
Мы занимались автоматизацией тестирования приложения на Dev-среде, а для этого нужно было научить агента катить на Dev. У нас настроены динамические окружения, так что каждая ветка может существовать изолированно. Мы подключили GitLab MCP к агенту с выделенным пользователем с ролью developer на проекте. Вот только в MCP не оказалось возможности запускать пайплайны, и сам агент в процессе размышления попытался найти GitLab-токен с правами запуска пайпов. И это натолкнуло меня на мысль: а что, если агенту просто дать GitLab-токен пользователя с ограниченными правами и вызвать API напрямую из агента? Очевидно, это решение сработало.
В этот момент и произошло переосмысление: а зачем нам вообще нужен MCP? Почему мы не можем использовать текущие API для интеграции с уже продуманной (и, главное, принятой) ролевой моделью? Агенты поумнее вообще могут в реальном времени писать скрипты интеграции и сразу готовить формат, как себе нужно, а для агентов потупее можно заранее писать набор тулов для интеграции. С помощью агентов поумнее, само собой.
В итоге MCP-хаб (маркетплейс интеграций) превращается в набор скиллов (.md-файликов), который описывает, каким образом и с какой системой интегрироваться. Так в итоге еще и появляется самоактуализирующаяся документация. Актуализация происходит в момент, когда агент пытается написать интеграцию: если API не работает как описано, то он может сделать PR на обновление скилла, а овнеры уже могут принять или отклонить этот запрос.
#александр_опрышко