Коммуникация 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
👍7🔥2❤1
Главная проблема агентов: прототип сделать просто, а работающую систему на порядок сложнее
Когда мы работаем с ChatGPT, мы общаемся с ним как с ассистентом: задаём вопрос, получаем ответ, берём нужное, игнорируем лишнее. Если ответ не тот — переспрашиваем или корректируем.
Примерно то же самое происходит и при создании прототипа. Загружаем данные, смотрим, как отвечает система, убеждаемся, что «в целом работает» — и на этом этапе говорим, что прототип готов. При этом часто игнорируем ошибки, потому что в прототипе они кажутся незначительными.
Даже если система ошибается в 1 случае из 100 и точность правильных ответов — 99%, оставшийся 1% может нанести репутационный ущерб. А подобных типов ошибок может быть много.
Например: в 2023 году делали ИИ чат-бота для магазина. Клиент спрашивает у бота: «Где находится ближайший магазин?», а бот галюцинирует, ошибается с адресом, клиент приходит — магазина нет.
Поэтому требования к качеству резко возрастают, и простой «работающий прототип» уже не подходит. Исходя из этого, существует 2 стратегии внедрения:
1. Полностью автоматическая система.
ИИ сам отвечает и действует, человек не участвует. На практике 1 стратегия часто заканчивается провалом, так как внедряется ИИ, который работает хуже процесса с человеком, в результате принимается решение, что технология не зрелая, инициатива задвигается.
Сработать такая система может только там, где цена ошибки низкая.
Пример: бот, который продаёт бетон. Его задача — взять телефон и проконсультировать для дальнейших продаж. Он может ошибиться с деталями доставки, но в среднем даёт больше конверсии, чем человек за счёт скорости ответов.
2. Автоматизированная система с участием человека.
ИИ предлагает ответ, но окончательное решение принимает человек. Во 2 стратегии мы рассматриваем ИИ как ассистента. Он находит информацию, формирует готовый ответ. Человек может принять ответ, изменить или отклонить. Все действия логируются и накапливаются данные: вопросы, ИИ-ответы, поддержки, рейтинг удовлетворенности пользователя. На основании данных дообучаем систему: переписываем промпты, файнтюним модели, меняем архитектуру и тд.
Со временем человек всё реже редактирует ответы. Когда процент автоматических решений стабильно высокий и не уступает качеству работы оператора — только тогда возможен переход к первой стратегии и полной автоматизации.
Коллеги из Сбера пошли по второй стратегии: внедрили ассистента поддержки, который сократил среднее время ответа на 20% , а не пытались заменить операторов полностью.
Иногда переход от 2 стратегии к 1 происходит. Иногда технологическая зрелость не позволяет, и человек остаётся в цепочке. Но даже в этом случае он работает быстрее, а инвестиции в ИИ-систему окупаются.
#александр_опрышко
Когда мы работаем с ChatGPT, мы общаемся с ним как с ассистентом: задаём вопрос, получаем ответ, берём нужное, игнорируем лишнее. Если ответ не тот — переспрашиваем или корректируем.
Примерно то же самое происходит и при создании прототипа. Загружаем данные, смотрим, как отвечает система, убеждаемся, что «в целом работает» — и на этом этапе говорим, что прототип готов. При этом часто игнорируем ошибки, потому что в прототипе они кажутся незначительными.
Даже если система ошибается в 1 случае из 100 и точность правильных ответов — 99%, оставшийся 1% может нанести репутационный ущерб. А подобных типов ошибок может быть много.
Например: в 2023 году делали ИИ чат-бота для магазина. Клиент спрашивает у бота: «Где находится ближайший магазин?», а бот галюцинирует, ошибается с адресом, клиент приходит — магазина нет.
Поэтому требования к качеству резко возрастают, и простой «работающий прототип» уже не подходит. Исходя из этого, существует 2 стратегии внедрения:
1. Полностью автоматическая система.
ИИ сам отвечает и действует, человек не участвует. На практике 1 стратегия часто заканчивается провалом, так как внедряется ИИ, который работает хуже процесса с человеком, в результате принимается решение, что технология не зрелая, инициатива задвигается.
Сработать такая система может только там, где цена ошибки низкая.
Пример: бот, который продаёт бетон. Его задача — взять телефон и проконсультировать для дальнейших продаж. Он может ошибиться с деталями доставки, но в среднем даёт больше конверсии, чем человек за счёт скорости ответов.
2. Автоматизированная система с участием человека.
ИИ предлагает ответ, но окончательное решение принимает человек. Во 2 стратегии мы рассматриваем ИИ как ассистента. Он находит информацию, формирует готовый ответ. Человек может принять ответ, изменить или отклонить. Все действия логируются и накапливаются данные: вопросы, ИИ-ответы, поддержки, рейтинг удовлетворенности пользователя. На основании данных дообучаем систему: переписываем промпты, файнтюним модели, меняем архитектуру и тд.
Со временем человек всё реже редактирует ответы. Когда процент автоматических решений стабильно высокий и не уступает качеству работы оператора — только тогда возможен переход к первой стратегии и полной автоматизации.
Коллеги из Сбера пошли по второй стратегии: внедрили ассистента поддержки, который сократил среднее время ответа на 20% , а не пытались заменить операторов полностью.
Иногда переход от 2 стратегии к 1 происходит. Иногда технологическая зрелость не позволяет, и человек остаётся в цепочке. Но даже в этом случае он работает быстрее, а инвестиции в ИИ-систему окупаются.
#александр_опрышко
👍10🔥6❤5
Почему корпорации не любят n8n?
n8n — ноукод-инструмент для сборки LLM-агентов и интеграционных сценариев без программирования.
Но с точки зрения корпоративного внедрения у него есть серьёзные ограничения:
— Нет версионирования. В open source-версии нельзя отслеживать изменения и безопасно откатываться к предыдущим версиям.
— Нет поддержки уровня энтерпрайз. Компании хотят сопровождение, но вендоров, которые умеют эксплуатировать n8n, почти нет.
— Вендор-лок.Если он не подойдёт, перенести сценарии на что-то другое не получится, нужно будет переделывать.
— Сложное логирование. Агентная архитектура требует прослеживать шаги выполнения. Из коробки n8n этого не умеет. В коде трейсинг и логирование сделать проще.
— Ограниченные возможности для кастомных сценариев. Разработчику зачастую проще и быстрее реализовать логику на LangChain, чем собирать её в интерфейсе n8n.
Тем не менее, для Agent Platform мы сознательно выбрали n8n как один из «агентских фреймворков».
Несмотря на ограничения, такие инструменты нужны для массового использования в продуктовых командах. Продуктам, аналитикам, маркетологам важен простой способ быстро проверить гипотезу: можно ли переложить текущий процесс на LLM. Если можно — появляется рабочий прототип, с которым уже есть смысл идти к инженерам. Они смогут превратить его в продакшен-решение с метриками.
Пример: генерация рекламных изображений.
LLM умеют генерировать картинки, но дизайнеру важно ещё адаптировать их под разные площадки и бренд-гайдлайны. Вместо долгого цикла с ресерчем и итерациями от разработчиков, он может сам собрать прототип в n8n, потестировать гипотезу — и только потом подключить инженеров. Тогда они уже перенесут это решение в продакшен, готовый к масштабированию.
Наша практика внедрения агентов показывает, что придумывать промты должен product owner. А задача инженера — сделать так, чтобы результат, который получил product owner в режиме прототипа, стал стабильным.
Поэтому мы даем n8n в руки product owner”ов, помогая им разобраться в инструменте, а потом переносим результат прототипа на n8n в промышленное решение руками инженеров, которые доводят качество и воспроизводимость до нужного уровня.
n8n даёт быстрый результат — и этого достаточно, чтобы начать. Это гибкий agile-подход. Он помогает командам запускать инициативы с ИИ быстрее и внедрять LLM в реальную работу.
#александр_опрышко #n8n
n8n — ноукод-инструмент для сборки LLM-агентов и интеграционных сценариев без программирования.
Но с точки зрения корпоративного внедрения у него есть серьёзные ограничения:
— Нет версионирования. В open source-версии нельзя отслеживать изменения и безопасно откатываться к предыдущим версиям.
— Нет поддержки уровня энтерпрайз. Компании хотят сопровождение, но вендоров, которые умеют эксплуатировать n8n, почти нет.
— Вендор-лок.Если он не подойдёт, перенести сценарии на что-то другое не получится, нужно будет переделывать.
— Сложное логирование. Агентная архитектура требует прослеживать шаги выполнения. Из коробки n8n этого не умеет. В коде трейсинг и логирование сделать проще.
— Ограниченные возможности для кастомных сценариев. Разработчику зачастую проще и быстрее реализовать логику на LangChain, чем собирать её в интерфейсе n8n.
Тем не менее, для Agent Platform мы сознательно выбрали n8n как один из «агентских фреймворков».
Несмотря на ограничения, такие инструменты нужны для массового использования в продуктовых командах. Продуктам, аналитикам, маркетологам важен простой способ быстро проверить гипотезу: можно ли переложить текущий процесс на LLM. Если можно — появляется рабочий прототип, с которым уже есть смысл идти к инженерам. Они смогут превратить его в продакшен-решение с метриками.
Пример: генерация рекламных изображений.
LLM умеют генерировать картинки, но дизайнеру важно ещё адаптировать их под разные площадки и бренд-гайдлайны. Вместо долгого цикла с ресерчем и итерациями от разработчиков, он может сам собрать прототип в n8n, потестировать гипотезу — и только потом подключить инженеров. Тогда они уже перенесут это решение в продакшен, готовый к масштабированию.
Наша практика внедрения агентов показывает, что придумывать промты должен product owner. А задача инженера — сделать так, чтобы результат, который получил product owner в режиме прототипа, стал стабильным.
Поэтому мы даем n8n в руки product owner”ов, помогая им разобраться в инструменте, а потом переносим результат прототипа на n8n в промышленное решение руками инженеров, которые доводят качество и воспроизводимость до нужного уровня.
n8n даёт быстрый результат — и этого достаточно, чтобы начать. Это гибкий agile-подход. Он помогает командам запускать инициативы с ИИ быстрее и внедрять LLM в реальную работу.
#александр_опрышко #n8n
👍9🔥4
LLM-независимый подход: как снизить риски и расходы на внедрение ИИ
На рынке уже доступны state-of-the-art модели от OpenAI, Anthropic, Google и других разработчиков. Они отличаются по качеству, размеру и стоимости эксплуатации. Но в российских реалиях решения малодоступны из-за ограничений по безопасности и требованиям к инфраструктуре. Нужно использовать облачные решения вроде Яндекса и Сбера или разворачивать open source модели в своем контуре.
Часто на старте внедрения ИИ Агентов у команды есть только набор гипотез, но нет понимания, реально ли воплотить идею на доступных в России моделях, и насколько трудоемко реализовать инициативу.
Есть два базовых варианта, что можно делать на старте внедрения:
1. Сразу начинать с дешёвой, локальной open source модели.
Риск — потратить много времени, чтобы заставить систему работать. Если задача сложная, система может не справиться.
2. Сначала использовать лучшую доступную модель.
Протестировать гипотезу на публичных данных, быстро понять, достижим ли нужный результат. Если не получается на лучших моделях за короткое время — не стоит тратить ресурсы дальше и инвестировать в переезд на доступные модели. Рассмотрите другие инициативы, которые дадут быструю победу. Если результат вас устраивает — можно пробовать решить задачу компании open-source моделями или моделями, которые доступны в российских облаках.
Для этого нужно итерироваться по доступным моделям, опираясь на данные и метрики:
— Выбираем топовую модель для тестирования гипотезы. На публичных данных строим прототип и определяем метрики качества (про метрики качества ответов расскажем в следующем посте).
— Добиваемся стабильных метрик. Ответы прототипа доводим до стабильных метрик и проверяем репрезентативность: если ответ плохой — метрики плохие, хороший — хорошие.
— Итерируемся вниз по моделям. Постепенно заменяем модель на более дешёвую/маленькую. Оцениваем, как это влияет на метрики. Если результат сохраняется — продолжаем и брем модель еще дешевле. Если качество падает — адаптируем систему.
— Находим оптимальный баланс. Останавливаемся там, где сходится экономика процесса: оптимальный трейд-офф между количеством усилий для достижения результата и ценой инференса (генерации токена).
Для пошаговой итерации нужен гибкий инструмент, чтобы переключаться между моделями без изменений в логике приложения.
Один из таких инструментов — LiteLLM, который предоставляет унифицированный API и поддерживает разные LLM-провайдеры.
А для автоматизированной оптимизации агентов советуем DSPy.
Внутри Agent Platform мы добавили LiteLLM, который подключен к российским, американским и китайским провайдерам, чтобы можно было гибко менять модели подходы к оценке качества.
#александр_опрышко #llm
На рынке уже доступны state-of-the-art модели от OpenAI, Anthropic, Google и других разработчиков. Они отличаются по качеству, размеру и стоимости эксплуатации. Но в российских реалиях решения малодоступны из-за ограничений по безопасности и требованиям к инфраструктуре. Нужно использовать облачные решения вроде Яндекса и Сбера или разворачивать open source модели в своем контуре.
Часто на старте внедрения ИИ Агентов у команды есть только набор гипотез, но нет понимания, реально ли воплотить идею на доступных в России моделях, и насколько трудоемко реализовать инициативу.
Есть два базовых варианта, что можно делать на старте внедрения:
1. Сразу начинать с дешёвой, локальной open source модели.
Риск — потратить много времени, чтобы заставить систему работать. Если задача сложная, система может не справиться.
2. Сначала использовать лучшую доступную модель.
Протестировать гипотезу на публичных данных, быстро понять, достижим ли нужный результат. Если не получается на лучших моделях за короткое время — не стоит тратить ресурсы дальше и инвестировать в переезд на доступные модели. Рассмотрите другие инициативы, которые дадут быструю победу. Если результат вас устраивает — можно пробовать решить задачу компании open-source моделями или моделями, которые доступны в российских облаках.
Для этого нужно итерироваться по доступным моделям, опираясь на данные и метрики:
— Выбираем топовую модель для тестирования гипотезы. На публичных данных строим прототип и определяем метрики качества (про метрики качества ответов расскажем в следующем посте).
— Добиваемся стабильных метрик. Ответы прототипа доводим до стабильных метрик и проверяем репрезентативность: если ответ плохой — метрики плохие, хороший — хорошие.
— Итерируемся вниз по моделям. Постепенно заменяем модель на более дешёвую/маленькую. Оцениваем, как это влияет на метрики. Если результат сохраняется — продолжаем и брем модель еще дешевле. Если качество падает — адаптируем систему.
— Находим оптимальный баланс. Останавливаемся там, где сходится экономика процесса: оптимальный трейд-офф между количеством усилий для достижения результата и ценой инференса (генерации токена).
Для пошаговой итерации нужен гибкий инструмент, чтобы переключаться между моделями без изменений в логике приложения.
Один из таких инструментов — LiteLLM, который предоставляет унифицированный API и поддерживает разные LLM-провайдеры.
А для автоматизированной оптимизации агентов советуем DSPy.
Внутри Agent Platform мы добавили LiteLLM, который подключен к российским, американским и китайским провайдерам, чтобы можно было гибко менять модели подходы к оценке качества.
#александр_опрышко #llm
❤4🔥3