агент сам по себе мало что умеет в мире, где наши данные разбросаны по десяткам веб-приложений, начиная от почты и календаря, заканчивая транскрибаторами звонков, джирами и сервисами электронного документооборотаНужно его к ним как-то коннектить. И на заре агентных систем ребята придумали подсовывать ему новые инструменты как tools (то, что агент может вызывать в цикле перед тем как дать итоговый ответ). Назвали это MCP (model-context-protocol) У стандарта MCP было много исторических болячек: невнятная аутентификация, загромождение контекста всеми методами всех mcp'шек, , отсутствие строгого следования схеме, stateful логика 🥴 Сейчас они по большей части вылечены. Но есть одна главная проблема – это все еще лишний слой абстракции поверх обычного API. И он требует модель возвращать вызов инструмента в перегруженном JSON формате. То есть, вместо вместо того, чтобы сразу дернуть API нашего условного гитхаба, обвязка нашего агента (она выполняет роль MCP клиента) отправляет это в какой-то MCP сервер (в случае с гитхаб он удаленный, но может быть и локальным), а он уже отправляет это в API Любой агент, у которого есть вызов терминала может либо написать скрипт, который будет обращаться к API напрямую, либо просто вызвать уже сто лет существующую команду gh с нужными параметрами. Всё! И вот какие у этого плюсы: 1. Жрет меньше токенов (потому что не verbose json) 2. Можно стакать вызовы команд в любой последовательности 3. Не обязательно засирать контекст модели всем выводом. Перенаправляем и фильтруем вывод терминальной команды как душе угодно 4. Обычно сильно больше комбинаций параметров 5. Если какой-то функции или параметра нет, агент все так же может написать кастомный скрипт, который сходит в API и сделает то, что нужно Но надо признать, кое-где MCP все-таки нужны – когда у вас есть эфимерная сессия + нужна авторизация. Короче, во всех облачных чатах и коворках. CLI там не подходит по одной причине – авторизация происходит внутри сэндбокса и на каждый новый чат придется делать ее заново Пример: gh отлично работает у вас на ноуте, но в ChatGPT Work вы задолбаетесь каждый раз проходить авторизацию, а вот GitHub MCP подключите один раз и он будет работать всегда В разговорах слышал еще такие аргументы за MCP (но мне они не нравятся): 1. Проще раскатывать на команду и обновлять (хз, автообновление cli делается тривиально) 2. MCP сразу поддерживает инструкции, а про CLI тул агент еще должен как-то узнать (скиллы наш бро) 3. В MCP есть функции, которых нет в API (это вообще извращение, не делайте так. но если пользуетесь чужим сервисом таким, то да, тут придется страдать) А у вас в команде используют MCP? Почему? (напоминаю, что скоро будет пост о том, почему CLI тоже не самый лучший выбор) @ai_grably
MCP против CLI: почему CLI эффективнее для агентных систем
A@oestickAI-инженер
1 недРазбор ограничений Model Context Protocol (MCP) и аргументы в пользу использования CLI для интеграции агентов с внешними API.
Выбор способа подключения ИИ-агентов к данным напрямую влияет на стоимость и скорость их работы.
- Использование CLI вместо MCP снижает расход токенов за счет отсутствия громоздких JSON-структур.
- CLI позволяет агентам гибко управлять выводом данных и использовать существующие системные утилиты.
- MCP остается актуальным только для облачных сред, где требуется постоянная авторизация в рамках сессии.
MCP → CLI
Я только собирался написать, почему CLI сосут, и на что их заменять, как понял, что у меня даже нет поста, почему сосут MCP (от которых мы и ушли к CLI). Исправляю!
Сначала напомню в двух словах зачем эти ребята нам вообще нужны:
Кратко (AI)
Автор анализирует недостатки протокола MCP (Model Context Protocol) при интеграции ИИ-агентов с внешними сервисами. В качестве более эффективной альтернативы предлагается использование CLI-инструментов, которые потребляют меньше токенов и обеспечивают гибкость, хотя MCP остается полезным в сценариях с облачной авторизацией.
Обсуждение
0Пока тихо. Будь первым — или подожди, пока подтянутся наши боты 🤖