Comments 15
Мисье, вы все изложили в заключении, где основное "Молодость протокола". В прод такое пихать страшно. Завтра наказание обновление langchain, он напишнь deprecated in next release, а послезавтра будет перелопачивать всё взаимодействие. А без обнов страшно. AI среда слишком уязвима.
Так же, сразу видно, что вы используете ai для написания статьи и кода. Текст похож на chatgpt, но по коду вроде бы claude sonnet 3.6.
Python 3.11, как пример. Знак "+" - это конечно хорошо, но 3.11 не надо использовать. Он уже не поддерживается и имеет не пофикшееные уязвимости. Так что по этому нужно использовать хотя бы 3.12-slim.
Про «молодость протокола» и прод. Я специально вынес это в минусы - чтобы сразу подсветить риски. Статья не инструкция «внедрять завтра в продакшен», а туториал для знакомства с подходом. Идея MCP (стандартный интерфейс агента с инструментами) выглядит перспективной, но самому протоколу ещё взрослеть и взрослеть.
Про LangChain.
В статье намеренно использовал langchain-mcp-adapters (официальную библиотеку) и LangGraph вместо старого AgentExecutor. Сейчас это «рекомендованный путь», и ломают его не так часто, как ранние версии LangChain. Ну и фиксация версий в requirements.txt.
«Видно, что AI писал».
Есть такое. Статья - результат совместной работы: структуру и логику выстраивал я, код тестировал руками, а черновики текста помогал готовить AI. Считаю такой подход рабочим: LLM берёт на себя рутину с формулировками и docstring'ами, а живой разработчик отвечает за то, чтобы всё было корректно и не галлюцинировало. В 2026-м я считаю это нормальным.
Python 3.11+.
Я написал «3.11+» по инерции, потому что многие консервативные проекты до сих пор сидят на 3.11 из-за старых зависимостей. Но для нового кода рекомендовать нужно минимум 3.12.
Если после прочтения ты такой «ну его в пень, пусть полежит годик» - значит, я свою задачу выполнил: предупредил о рисках. А когда протокол устаканится (а судя по тому, как Anthropic и другие его форсят, это вопрос времени), у тебя уже будет готовая ментальная модель.
В чём плюс использования MCP, если я, например, могу создать skill “create-github-issue”, где укажу, что агент может использовать уже настроенный gh cli tool и создавать issues?
Возьмите пример сложнее, где нет готового инструмента. И вам придется дописывать, додумывать внешнее апи, придумать обертку, процессы и логику.
И вы придете к тому что напиши свой mcp
Зачем? Нет одного готового инструмента - ну значит просто будет инструкция как вызывать несколько инструментов с парой тройкой примеров использования.
Да хоть тот же калькулятор. Мне кажется операцию извлечения квадратного корня без mcp уже не сделать. А возможно и сложения даже.
Квадратный корень (и вообще корни полинома) они и в уме считают правильно.
Но вообще за чем тут mcp если можно:
Use python to do math
А с mcp как вы это будете делать?
для одной задачи в пет-проекте CLI действительно проще. Но когда таких интеграций становится хотя бы десяток и они начинают жить в разных проекта?
MCP - это единый стандарт для подключения любых инструментов. Без него каждый скилл или функция превращается в уникальную интеграцию:
Где-то агент вызывает
subprocess.run(['gh', 'issue', 'create'])и парсит stdout.Где-то - дергает REST API.
Где-то - подключается к базе данных через SQL.
Когда таких инструментов 30, а моделей/агентов — 3, выходит30 × 3 = 90 уникальных связок, каждую из которых нужно писать, тестировать и поддерживать. MCP превращает это в 30 + 3 = 33 связки: каждый инструмент описывается один раз, и любой агент может его использовать по стандартной схеме.
подходы MCP и CLI не исключают друг друга. Для локальной разработки и быстрых итераций CLI бывает эффективнее (меньше накладных расходов). А для корпоративных систем, где на первый план выходят безопасность, аудит и переиспользование, MCP - это безальтернативный вариант.
У cli тоже логи есть не удаляйте их и будет вам аудит.
Если тула пойдёт в какой то сервис то аудит будет еше на стороне сервиса.
Про безопасности тоже не совсем понятно, как будто бы это пермиссиями решается, а ещё один микросервис в виде mcp как будто бы просто ещё одна точка отказа.
Создатель openclaw прямо говорит что mcp не нужен, агент лучше пусть юзает cli, а openclaw уже начинает появляться в enterprise.
Я тоже так думаю.
Смысл MCP готовых как раз в том, что они позволяют к агенту подключить популярные сервисы без написания с 0 функций. Просто в запрос с ИИ пихаешь название открытого MCP и указываешь свой api ключ. Если бы автор готовые MCP использовал для доступа к погоде, тогда вопросов нет - популярная технология использована должным образом.
А создавать свой MCP для СВОИХ же только что с 0 написанных функций - лишние телодвижения. Это разумно только если мы делаем MCP для пользователей по всему миру или своей компании/команды для внутреннего пользования.
Вообще статья довольно странная, чувствуется очень сильный шлейф нейронки, как будто я попросил дипсик кратко рассказать как мне сделать ИИ-агента. Некоторые фразы по типу « MCP — один из ключевых кирпичиков в этом фундаменте. Пора внедрять. » очень сильно сильно это чувство подпитывают.
Также тема агентов весьма поверхностно раскрыта, все задето очень по верхам. Непонятно для каких целей создается этот агент, потому что по факту он почти ничего полезного не умеет, даже код не напишет, ведь у него нет инструментов, которые дадут ему это сделать. MCP позиционируется как что то новое, но в рамках современной скорости развития нейронок он уже давно существует, почти столько же сколько все популярные агенты, а про такой подход как скилы (SKILL.md) вообще не озвучено. RAG зачем-то интегрирован в самого агента, хотя наиболее логично делать его подключаемым, как раз через MCP, автор же и сам пишет про «модульность» агентов.
Тот же RAG имеет кучу нюансов, к примеру если мы хотим индексировать код. MCP тоже имеет свои нюансы. Все это не раскрыто или написаны какие то очевидные плюсы\минусы
Того что в начале обещал автор: «Собираем AI-агента нового поколения» и «В этой статье мы соберём полноценного агента» я тут не увидел. Статье не хватает более глубокой проработки какой то конкретной темы, в целом гайд по сборке абстрактного агента не очень полезен.
Это мое субъективное мнение, никого обидеть не хочу, вполне возможно что я не прав и сам дурак, просто хочется чего то интересного, информацию из статьи на хабре уже много раз видел.
Да, я не скрываю, что использовал LLM для помощи с формулировками и черновиками. разжёвывание очевидных вещей и красивые обороты помогал накидывать ИИ. Итоговый текст вычитывал вручную, но «стиль нейронки» местами всё равно пробивается.
Статья задумывалась как вводный туториал для разработчиков, которые вообще не работали с MCP. Если читатель уже собрал десяток агентов и сам пишет SKILL.md, статья ему вряд ли откроет что-то новое. Но для того, кто только смотрит в сторону MCP и хочет понять «как это вообще склеивается в коде», такой уровень детализации в полне себе оправдан.
спасибо за развёрнутую критику. Если будет желание обсудить что-то из затронутого подробнее - я открыт к диалогу.
Собираем AI-агента нового поколения: Python, RAG и внешние инструменты через MCP (Model Context Protocol)