Думаю, многие слышали про новый протокол Model-Context Protocol. По современным меркам он возник очень давно, аж осенью прошлого года, ха-ха. Сейчас, кажется, темп такой, что месяц примерно идет за год. 🙈
В общем, это протокол, который позволяет LLM пользоваться сторонними инструментами.
Идея на самом деле не нова. Это было внедрено Open AI еще с момента появления их Assistant API. Там это называется "functional calling". Сейчас просто этот подход стал стандартом, который постепенно внедряют все LLM, в том числе и Open AI (но уже для Response API).
1️⃣ Зачем это вообще нужно?
Суть в том, что LLM без доступа к внешним инструментам находится как бы в изоляции. Всё, что она может знать, она получает через своё контекстное окно или в простом случае через ваш промпт.
Ввиду такой изолированности LLM не сможет при необходимости, например, сделать запрос в вашу БД, загрузить документ по ссылке из Интернета или, скажем, что-то прочитать из документа на диске вашего сервера.
LLM под домашним арестом: без доступа в Интернет и гаджетов. Да, LLM умная, но польза ее сильно ограничена из-за изоляции от внешнего мира.
Чтобы решить эту проблему как раз и придумали functional calling, а теперь — MCP.
2️⃣ Суть MCP
MCP является новым стандартом (протоколом), по которому LLM может пользоваться внешними инструментами. Инструменты предоставляет MCP-сервер. То есть клиент MCP-сервера — это сама LLM.
MCP-сервер отвечает за две вещи:
отдает LLM схему, в которой описаны все доступные инструменты
обслуживает запросы LLM
LLM в свою очередь:
зная адрес MCP-сервера, получает от него схему с инструментами
если запрос пользователя подразумевает использование инструмента, посылает нужные запросы вашему MCP-серверу и благодаря ответам обогащает свой контекст по мере необходимости
Важный момент, что использовать инструменты или нет, решает LLM.
Стандарт MCP говорит о том, как инструменты должны быть описаны в схеме и как нужно посылать запросы/ответы между LLM и сервером.
Сейчас стандарт активно внедряется провайдерами LLM (OpenAI, Claude и др.) и похоже скоро все они будут уметь работать по MCP.
3️⃣ Как это выглядит глазами обычного юзера
Представьте, что у вас есть база данных клиентов.
Раньше, чтобы найти инфу о конкретном клиенте, вам нужно было:
Открыть админку
Найти нужную таблицу
Ввести параметры поиска
Проанализировать результат...
С MCP вы просто говорите LLM: "Найди всех клиентов из Тбилиси, которые не делали заказы последние 2 месяца" — и она сама сделает нужный запрос и выдаст результат.
4️⃣ Почему это круто и за этим будущее
Предоставив доступ LLM к серверному API, мы фактически открываем ящик пандоры возможности взаимодействия с API через текст.
Если раньше для взаимодействия с сервером вам нужен был интерфейс приложения с кнопочками или, на худой конец, нужно было посылать запросы через терминал ручками, то теперь вы можете просто говорить LLМ, что вам нужно и LLM сам всё сделает.
Именно поэтому недавно возникла новая мантра про "SaaS is dead". Типа, зачем пилить сложные интерфейсы, если достаточно подключить LLM, дать ей доступ к бекенду и она сама выполнит любые пожелания пользователей.
Во многом это так есть. Разговорный интерфейс — это гибкость и мощь одновременно. Традиционные интерфейсы же, напротив, ригидны и ограничены.
Как всегда, я думаю, истина будет где-то посередине и крутые приложения будут попадать в идеальный баланс между обычным и разговорными интерфейсами. Но то, что MCP сильно изменит то, как мы взаимодействуем с приложениями, думаю, бесспорно.
Как думаете, SaaS скорее жив, чем мертв или наоброт?
Моя мама — основатель и владелец компьютерного учебного центра. Это "локальный" оффлайн-бизнес с учебными классами и своей инфраструктурой. Основная аудитория — школьники 7-11 классов, коих обучается примерно 200-300 человек в год. Кстати, недавно центру исполнилось 25 лет!
В молодости я тоже там работал: помогал развивать бизнес и вел занятия по веб-технологиям. А сейчас я там кто-то вроде консультанта по IT.
Почти каждый год мама спрашивает меня, что сейчас происходит в IT, какие программы обучения стоит предлагать школьникам.
Я понял, что в этом году мне особенно трудно ответить!
Что сегодня изучать школьнику в IT, чтобы это помогло ему построить успешную карьеру в будущем? Вопрос сложный!
Раньше это всегда было программирование. Почти беспроигрышный вариант. Фундамент всего IT. Но по моему скромному мнению, 90% разработчиков скоро станут не нужны благодаря ИИ.
Появление мощного ИИ — это "механизация" интеллектуального труда. Всё как с механизацией сельского хозяйства в своё время. Пока не было тракторов, крестьяне были очень востребованы. Когда появились трактора, востребованными остались только те, кто стал трактористами 🚜.
Так и в IT сейчас. Программисты никуда не денутся, но изменятся инструменты и подходы к работе. Основная мысль в том, что ИИ не заменит всех, но те, кто умеют работать с ИИ, заменят тех, кто не умеет.
В итоге я посоветовал всё обучение школьников выстраивать вокруг ИИ.
Получился такой список приоритетных направлений:
1️⃣ программирование на Python (навык программирования = умение логически мыслить, кроме того Python — основной язык для машинного обучения и анализа данных)
2️⃣ веб-разработка по-прежнему актуальна (мой любимый JS/TS), потому что нужно будет интегрировать ИИ в интерфейсы и строить приложения поверх ИИ
3️⃣ учиться работать с данными (SQL, машинное обучение, анализ данных, визуализация, обучение ИИ-моделей)
Решил понять, как сейчас можно создавать ИИ-агентов. Вариантов так много, что голова может пойти кругом. Я попытаться увидеть в этом систему.
Принципиально есть три основных направления.
1. Засучить рукава и писать много кода самому
Нужно неплохо знать какой-нибудь язык программирования (сюрприз!).
Лучше всего — Python, потому что он используется для LLM и это как бы "родной" язык для работы с ИИ. Но и другие языки тоже вполне подойдут. У меня есть некоторый опыт с Node.js, поэтому я, например, использую его.
С точки зрения сложности проекта средний ИИ-агент — это довольно простая программа.
У вас может быть веб-сервер на базе Express или просто скрипт. Триггером (тем, что запускает агента) может выступать любой планировщик или внешняя система, которая вызывает агента через веб-хук.
Например, написал пользователь на сайте сообщение. Ваш сайт посылает запрос вашему серверу и там уже агент начинает свою работу.
Во варианте с написанием кода у вас максимум гибкости, возможностей и... кайфа от процесса, если вы любите кодить. Можно реализовать любую сложную логику.
Писать агентов реально интересно, потому что это не просто примитивный CRUD. Нужно продумывать воркфлоу и порой взаимодействие между агентами. Я уж не говорю про механизмы самообучения.
2. Писать меньше кода за счет использования фреймворков
Пожалуй, это самый оптимальный и адекватный подход, если вы планируете создавать сложные агенты.
Под "сложными" я имею ввиду автономные агенты и команды агентов.
Автономный агент может сам принимать решения, что дальше делать в зависимости от ситуации. То есть это не фиксированная if-else логика.
Например, в аутриче важно фокусироваться на ценных лидах. Чем лучше подобраны лиды, тем больше эффективность кампаний.
У вас может быть главный агент ("мозг") и команда вспомогательных агентов, отвечающих за определенные задачи, такие как обогащение данных о лиде, скоринг и категоризация, написание писем, личных сообщений.
Главный агент может использовать вспомогательные агенты в зависимости от ценности лида. Особо ценный лид может быть передан в обработку нескольким аутрич-агентам (e-mail, личные сообщения), а менее ценный — только e-mail-аутрич-агенту. E-mail-агент может поменять текст следующего письма, если в личных сообщениях лид что-то написал другому агенту и контекст поменялся.
Суть тут в том, что решение принимается динамично за счет LLM. И еще нужен общий контекст между агентами, чтобы все это работало в унисон.
Фреймворки тут могут быть очень полезны, потому что в них реализованы инструменты для всего этого, и вам не придется изобретать необходимую логику с нуля. Также фреймворки поддерживают интеграции со многими сервисами, поэтому опять же надо меньше кода писать самому.
Примеры подобных фреймворков: AutoGen (Python), CrewAI (Python), LangChain (Python, Node.js).
3. Писать минимум кода и создавать ИИ-агентов в конструкторах.
Сейчас есть много, так называемых, "no-code" решений для создания ИИ-агентов. Тут большой набор вариантов, начиная от тех, что попроще (Zapier, make.com) и заканчивая более продвинутыми (n8n, pipedream).
Все эти платформы — это что-то вроде Scratch для взрослых.
Суть сводится к тому, что вы создаете нужный вам воркфлоу и настраиваете интеграции через интерфейс приложения.
Простые агенты можно создавать вообще без единой строчки кода. Сложные агенты скорее всего не получится реализовать из-за ограничений.
Тут максимум хайпа, потому что люди, не умеющие писать код, получили возможность ✨ творить ✨ .
--- Некая матрица принятия решения, как я это вижу
💡 Хочу построить простого агента или не умею кодить (тогда сложного агента создать не получится). ➡️ Использовать конструкторы.
💡 Хочу сложного агента и умею кодить на Python. ➡️ Юзать фреймворк или писать с нуля. Скорее всего юзать фреймворк более оправдано, потому что есть из чего выбрать.
💡 Хочу сложного агента и умею кодить на др. языках (например, Node.js) ➡️ Писать с нуля.
Сейчас вокруг ИИ-агентов много хайпа. Но что именно скрывается за этим термином? До конца непонятно.
Люди понимают его по-разному. Кто-то называет агентом вообще всё, что выходит за рамки простого диалога с ChatGPT, а кто-то считает, что агент — это исключительно полностью автономная самообучающаяся система, движущаяся к цели.
Мне кажется, истина где-то посередине.
Ключевым фактором здесь является степень автономности системы. Под автономностью я имею в виду способность системы самостоятельно принимать решения.
Например, если у нас есть жёстко заданная логика if-else, основанная на выводе модели, — это не автономность. Потому что решение в таком случае принимает код, а не LLM.
А вот если LLM сам решает, что делать дальше, — это уже и есть автономность!
Я бы грубо разделил системы на следующие уровни автономности:
0️⃣ Скрипт с фиксированной логикой, выполняющий один или несколько шагов и делающий один или более запросов к LLM. 1️⃣ + ИИ предоставлены инструменты, которые он может использовать при необходимости (например, поиск или калькулятор). 2️⃣ + Порядок шагов определяет сам ИИ (например, получает сообщение от пользователя и решает — ответить на основе базы знаний или эскалировать человеку). 3️⃣ + Система самообучается и со временем повышает качество своей работы (ориентирована на достижение цели). 4️⃣ + Система может менять свою структуру во время работы (например, агент-папа может создавать или удалять других агентов).
Уровень 0 я бы не стал называть ИИ-агентом. Это скорее просто воркфлоу с использованием ИИ.
А вот начиная с уровня 1, уже можно говорить об ИИ-агенте, потому что в процесс включаются элементы автономности.
Это, в целом, соответствует подходу Anthropic: статья
