Коммуникация Agent <-> Agent : чем полезна и куда развивается
ИИ-агенты уже умеют ставить встречи, выдавать доступы, проводить онбординг, искать и анализировать информацию. На наш взгляд, больше 80% задач может решать один агент, работающий в конкретной предметной области. Однако есть задачи, которые охватывают сразу несколько процессов или систем и требуют участия нескольких агентов.
Например, онбординг нового сотрудника, которому нужно создать учетную запись, выдать доступы, завести почту и познакомить его с документацией.
В простом случае этим управляет агент-оркестратор: он поочередно вызывает агентов, передаёт им входные данные и собирает результат.
Но если нужно, чтобы агенты координировали работу между собой, встает вопрос о создании межагентного взаимодействия. Например, один агент вызывает другого, передаёт ему задачу, получает артефакт и инициирует следующий шаг, агенты отслеживают прогресс друг друга и доводят процесс до завершения.
И здесь напрашивается некоторая стандартизация коммуникации агентов, в которую должны быть заложены базовые принципы:
— Обнаружение агентов. Каждый агент декларирует свои возможности в каком-то формате и это позволяет другим агентам или оркестратору находить подходящего исполнителя под конкретную задачу.
— Управление заданиями. Агент получает задачу, отслеживает её статус и возвращает результат — артефакт. Если задача длительная, агенты синхронизируют статусы и сохраняют контекст.
— Коллаборация. Агенты могут передавать друг другу инструкции, промежуточные артефакты, ответы и контекст. Это позволяет выстраивать сложные цепочки действий.
На 2025 год уже существуют протоколы, реализующих эти принципы. В свежем обзоре исследователей из университета Shanghai Jiao Tong проведено детальное сравнение и категоризация таких протоколов (и не только).
Наиболее нашумевшие в последнее время:
A2A от Google — протокол и библиотека ADK, ориентированные на промышленное применение. ADK доступен на GitHub и позволяет быстро строить системы взаимодействия агентов на основе A2A.
ACP от IBM — так же протокол взаимодействия агентов между собой, который немного отличается от A2A выбором технологий и форматом общения агентов.
Главная проблема всех протоколов на данный момент — отсутствие широкого adoption в индустрии, и как следствие, фрагментированность в сообществе.
В интеграции LLM с внешними системами роль стандарта уже выполняет MCP и на наш (и не только) взгляд может в будущем стать основой стандартизации даже и в системах агентного взаимодействия.
В следующих постах разберём, можно ли считать MCP агентным протоколом и в каких сценариях это применимо.
#игорь_латкин #MCP #Agents
ИИ-агенты уже умеют ставить встречи, выдавать доступы, проводить онбординг, искать и анализировать информацию. На наш взгляд, больше 80% задач может решать один агент, работающий в конкретной предметной области. Однако есть задачи, которые охватывают сразу несколько процессов или систем и требуют участия нескольких агентов.
Например, онбординг нового сотрудника, которому нужно создать учетную запись, выдать доступы, завести почту и познакомить его с документацией.
В простом случае этим управляет агент-оркестратор: он поочередно вызывает агентов, передаёт им входные данные и собирает результат.
Но если нужно, чтобы агенты координировали работу между собой, встает вопрос о создании межагентного взаимодействия. Например, один агент вызывает другого, передаёт ему задачу, получает артефакт и инициирует следующий шаг, агенты отслеживают прогресс друг друга и доводят процесс до завершения.
И здесь напрашивается некоторая стандартизация коммуникации агентов, в которую должны быть заложены базовые принципы:
— Обнаружение агентов. Каждый агент декларирует свои возможности в каком-то формате и это позволяет другим агентам или оркестратору находить подходящего исполнителя под конкретную задачу.
— Управление заданиями. Агент получает задачу, отслеживает её статус и возвращает результат — артефакт. Если задача длительная, агенты синхронизируют статусы и сохраняют контекст.
— Коллаборация. Агенты могут передавать друг другу инструкции, промежуточные артефакты, ответы и контекст. Это позволяет выстраивать сложные цепочки действий.
На 2025 год уже существуют протоколы, реализующих эти принципы. В свежем обзоре исследователей из университета Shanghai Jiao Tong проведено детальное сравнение и категоризация таких протоколов (и не только).
Наиболее нашумевшие в последнее время:
A2A от Google — протокол и библиотека ADK, ориентированные на промышленное применение. ADK доступен на GitHub и позволяет быстро строить системы взаимодействия агентов на основе A2A.
ACP от IBM — так же протокол взаимодействия агентов между собой, который немного отличается от A2A выбором технологий и форматом общения агентов.
Главная проблема всех протоколов на данный момент — отсутствие широкого adoption в индустрии, и как следствие, фрагментированность в сообществе.
В интеграции LLM с внешними системами роль стандарта уже выполняет MCP и на наш (и не только) взгляд может в будущем стать основой стандартизации даже и в системах агентного взаимодействия.
В следующих постах разберём, можно ли считать MCP агентным протоколом и в каких сценариях это применимо.
#игорь_латкин #MCP #Agents
👍8🔥2❤1
Официальный MCP Registry?
В начале сентября команда, занимающаяся разработкой Model Context Protocol анонсировала запуск собственного реджистри. Разбираемся, чем он отличается от уже существующих.
Если понаблюдать, то с момента анонса MCP в ноябре прошлого года запустилось много реестров MCP-серверов:
— smithery.io
— mcp.so
— MCP Market
— Docker MCP Catalog
— Cursor MCP Registry
— GitHub MCP Registry
— даже реестр реестров
Так чем же примечателен запуск нового реестра от команды MCP? На мой взгляд 3-мя вещами:
1) Это официальный реестр в виде API от команды-разработчика протокола.
2) Новый проект унифицирует доступ к существующим реестрам под открытым API.
3) Цель реестра — стать динамическим каталогом для MCP-клиентов.
Первые два пункта понятны. Разберёмся с третьим.
Из описания места реестра в экосистеме понятно, что его основная цель — анонсировать, что где-то доступен MCP-сервер: в PyPI, NPM, DockerHub или просто развернутый по HTTP Streaming, который можно запускать определённым образом.
Ключевым является то, что MCP-клиенты, такие как Cursor, Claude Code, ChatGPT и другие, при должной поддержке могут автоматически найти подходящий под запрос пользователя MCP-сервер, самостоятельно его установить, настроить и осуществить через него запрос.
На мой взгляд, цель кажется утопичной. Но если упростить такую идею и представлять подобный реестр только как универсальный способ получения каталога MCP-серверов — это существенно сокращает порог входа в поиск серверов и в целом их дискавери и использование.
Кроме того, этот проект — опенсорсный и компании могут совершенно спокойно запускать собственные внутренние MCP-реестры, дав сотрудникам прямой и единообразный доступ к MCP-серверам компании.
В общем, конечно, пока, никакой революции не случилось, но в любом случае — очень интересно наблюдать и пробовать уже сегодня.
#игорь_латкин #mcp
В начале сентября команда, занимающаяся разработкой Model Context Protocol анонсировала запуск собственного реджистри. Разбираемся, чем он отличается от уже существующих.
Если понаблюдать, то с момента анонса MCP в ноябре прошлого года запустилось много реестров MCP-серверов:
— smithery.io
— mcp.so
— MCP Market
— Docker MCP Catalog
— Cursor MCP Registry
— GitHub MCP Registry
— даже реестр реестров
Так чем же примечателен запуск нового реестра от команды MCP? На мой взгляд 3-мя вещами:
1) Это официальный реестр в виде API от команды-разработчика протокола.
2) Новый проект унифицирует доступ к существующим реестрам под открытым API.
3) Цель реестра — стать динамическим каталогом для MCP-клиентов.
Первые два пункта понятны. Разберёмся с третьим.
Из описания места реестра в экосистеме понятно, что его основная цель — анонсировать, что где-то доступен MCP-сервер: в PyPI, NPM, DockerHub или просто развернутый по HTTP Streaming, который можно запускать определённым образом.
Ключевым является то, что MCP-клиенты, такие как Cursor, Claude Code, ChatGPT и другие, при должной поддержке могут автоматически найти подходящий под запрос пользователя MCP-сервер, самостоятельно его установить, настроить и осуществить через него запрос.
На мой взгляд, цель кажется утопичной. Но если упростить такую идею и представлять подобный реестр только как универсальный способ получения каталога MCP-серверов — это существенно сокращает порог входа в поиск серверов и в целом их дискавери и использование.
Кроме того, этот проект — опенсорсный и компании могут совершенно спокойно запускать собственные внутренние MCP-реестры, дав сотрудникам прямой и единообразный доступ к MCP-серверам компании.
В общем, конечно, пока, никакой революции не случилось, но в любом случае — очень интересно наблюдать и пробовать уже сегодня.
#игорь_латкин #mcp
👍6