Универсальный пульт дистанционного управления для ИИ — Алекс Хэнкок, Block

AAI Engineer
컴퓨터/소프트웨어AI/미래기술

스크립트

00:00:00Алекс Хэнкок: Всем привет. Меня зовут Алекс Хэнкок. Сегодня я расскажу об универсальном
00:00:17пульте дистанционного управления для ИИ. И прежде чем начать, я хочу сказать, что предыдущий оратор
00:00:21упомянул, будто мейнтейнеры клиентов MCP не реализовали поддержку задач, потому что они умные. Я —
00:00:26мейнтейнер клиента MCP. И могу сказать, что я просто ленился. Я этого не сделал. Ладно,
00:00:33теперь немного о себе, прежде чем мы начнем. Я — инженер-программист в Block, материнской
00:00:37компании Cash App, Square и Tidal. Сейчас у нас развивается несколько разных направлений.
00:00:43Я работаю там уже давно: занимался продуктами Square и сервисом Cash App.
00:00:47Но последние пару лет я занимаюсь разработкой открытого ИИ. В частности, я работаю над проектом
00:00:51с открытым исходным кодом под названием Goose, который начинался как внутренний проект в Block.
00:00:56Да, среди вас есть фанаты Goose. И затем мы открыли исходный код и передали его
00:01:02в Linux Foundation. Теперь права принадлежат им, но многие из нас в Block продолжают над ним работать.
00:01:07Я также являюсь мейнтейнером MCP — протокола контекста модели. Я работаю над SDK для Rust в этом проекте.
00:01:14А совсем недавно я начал работу над ACP — протоколом клиент-агент, о котором я и
00:01:20собираюсь сегодня рассказать. Думаю, у нас есть проблема с харнасами (оболочками), которую я хочу
00:01:27обозначить перед вами сегодня, предложить в качестве проблемы, а затем порекомендовать решение. Итак, в последнее
00:01:35время я замечаю, что у нас появилось много отличных оболочек, верно? Есть решения от исследовательских лабораторий,
00:01:40от разных компаний, а также множество решений на базе открытых стандартов.
00:01:46Но я заметил, что интерфейс к ним часто бывает кастомным или специализированным. В худшем случае
00:01:52могут существовать такие оболочки, для управления которыми можно использовать буквально только одно клиентское приложение,
00:01:57понимаете? И я считаю, что с этим связано несколько проблем. Аналогия, которую я проведу
00:02:03с вебом: это выглядело бы так, будто для подключения к любому сайту вам нужно использовать
00:02:11только один браузер или один конкретный протокол, верно? Это бы просто не работало. У нас не было бы
00:02:16открытого веба, если бы браузеры работали так. И я думаю, мы можем сделать лучше. Главная особенность стандартов
00:02:22заключается в том, что они создают экосистемы и рынки. Я бы утверждал, что
00:02:28в сфере агентного ИИ у нас уже есть хороший стандарт для того, чтобы агент выходил во внешний мир и действовал,
00:02:35верно? Вызывал инструменты, совершал действия в других системах, читал ресурсы и данные. Все мы
00:02:41как сообщество выиграли от появления MCP, верно? И самое мощное в MCP
00:02:47даже не сам протокол, а то, что MCP используют абсолютно все. Именно поэтому у нас есть, знаете,
00:02:53тысячи или десятки тысяч серверов по всему миру, и все агенты могут подключаться к ним
00:02:58и выполнять задачи в этих сторонних системах. Я бы сказал, что у нас пока нет хорошего решения
00:03:05или стандарта для клиентского программного обеспечения, которое говорит агентам, что делать, ставит задачи, определяет фронт работ
00:03:13и получает обновления. И сегодня я хочу предложить вариант, который, как мне кажется, является отличным решением
00:03:20над которым наша команда работала, и мы считаем его хорошим подходом в сфере
00:03:26открытых стандартов. Этот проект называется ACP (Agent Client Protocol). Он появился благодаря компаниям-разработчикам редакторов.
00:03:32Если вы пользовались текстовым редактором Zed или какими-либо продуктами JetBrains,
00:03:39то разработчики из Zed и JetBrains объединили усилия и предложили стандарт для
00:03:45клиентов, позволяющий управлять оболочками. Это логично, если поставить себя на их место,
00:03:49верно? Они хотели иметь возможность написать единую высококачественную реализацию клиента
00:03:54внутри редактора — возможно, в Zed, IntelliJ или чем-то подобном — и с помощью этой единственной реализации клиента
00:04:00управлять любой оболочкой, отправляя задачи, получая результаты,
00:04:06видя, какие файлы редактируются, и т. д. Это имеет абсолютный смысл, если взглянуть на ситуацию их глазами,
00:04:10верно? Но мы в команде Goose увидели это и поняли, что полезность гораздо шире,
00:04:17чем просто редакторы, понимаете? Протокол относительно нейтрален и не перегружен функциями, специфичными для редакторов. Поэтому
00:04:22мы считаем, что его можно распространить на гораздо более широкий спектр клиентского ПО. Чтобы углубиться
00:04:30в детали дизайна ACP и того, что с его помощью можно делать: он позволяет устанавливать соединения между клиентами и
00:04:37оболочками агентов, обладающими определенным набором возможностей, связанных с соединением. Затем вы можете создавать
00:04:45сессии. В рамках сессий можно отправлять сообщения пользователя — то, что пользователь вводит в приложение
00:04:51или клиентское ПО хочет передать. В ответ агент может присылать текст, изображения или аудио,
00:04:59а также обновления о происходящем. Например, если вызывается инструмент, он может отправить уведомление о вызове инструмента
00:05:04и объяснить, какой инструмент был вызван и какими были метаданные. Он также может передавать запросы
00:05:10разрешений, так что если клиентскому ПО нужно показать пользователю вопрос вроде: «Стоит ли выполнять
00:05:16этот вызов инструмента, да или нет?», это можно сделать через данный протокол. Дизайн довольно прост. Он использует сообщения JSON-RPC.
00:05:24И то, что нам нравится больше всего — он также является расширяемым. Вы не ограничены
00:05:29только тем, что есть в базовом протоколе. Вы можете добавлять собственные методы. По соглашению, нужно поставить знак подчеркивания
00:05:37и затем указывать свои кастомные методы. Больше всего мне нравится в этом подход, при котором
00:05:41если достаточное количество проектов-оболочек или клиентских проектов примут его, мы начнем видеть, что у всех нас
00:05:46совпадает, верно? Например, если у команды кодекса есть кастомные методы, у команды goose есть кастомные методы,
00:05:52у команды клиента есть свои кастомные методы — мы сможем увидеть, что зарождается в экосистеме и
00:05:58что имеет смысл стандартизировать и перенести в сам протокол, чтобы он формировался
00:06:03на основе реального использования и сообщества. Я покажу демо стандартной версии ввода-вывода для этого.
00:06:12Итак, я открою Zed, у меня здесь есть очень простой проект, в котором я пишу: «Расскажи мне
00:06:18об этом проекте». Это единственный HTML-файл. Как видите, я смог ввести запрос в Zed,
00:06:25и задействованный здесь агент — это Goose. То есть используется интерфейс ACP от Goose. И как вы видите,
00:06:31он отправляет текст назад. Он отправляет информацию о вызовах инструментов — что он прочитал и что
00:06:36сделал. Затем он обнаружил, что это один HTML-файл, и объяснил его. И я сделаю еще один,
00:06:42еще один пример. Это инструмент от компании Poolside AI. Я скажу: «Расскажи мне об этом
00:06:50проекте» (в том же проекте). И это клиент на базе терминала, который получает точно такой же опыт
00:06:55от того же агента: одна реализация на стороне оболочки, и теперь вы можете использовать любой клиент, верно? И
00:07:01как вы видите, он сделал то же самое. Он показал мне текстовые результаты, показал вызов инструмента, а затем
00:07:06вывел потоком сводку. Это базовое демо, показывающее двух клиентов, общающихся с одним и тем же
00:07:13агентом через стандартный ввод-вывод локально в данном случае. Но локального режима, очевидно, недостаточно, верно? Если вы хотите, чтобы это
00:07:21получило широкое распространение, необходима и поддержка удаленной работы. Агенты будут запускаться в облаке. И поэтому,
00:07:25когда мы обратились к этому проекту, мы увидели, что в нем еще нет удаленной поддержки. Поэтому мы описали HTTP-
00:07:31транспорт: существует HTTP-версия и возможность апгрейда до WebSocket. Теперь сообщения те же самые,
00:07:37семантика протокола идентична, но появился новый транспорт, который как раз внедряется и позволяет работать
00:07:42удаленно. С точки зрения команды Goose, стек агентных технологий состоит из
00:07:49четырех важных компонентов, верно? У вас есть клиент — приложение, которым пользуется пользователь,
00:07:54или безголовое приложение, запущенное где-то на машине. Есть оболочка (harness) — программа,
00:07:59которая реализует цикл вызова инструментов. Есть сами инструменты, часто в виде MCP. И наконец, есть
00:08:04модель, верно? Если вы реализуете удаленный транспорт для протокола клиент-агент, а у MCP уже есть удаленный
00:08:13транспорт для вызова инструментов, и у моделей давно есть удаленные эндпоинты, вроде API ответов,
00:08:18то теперь вы получаете гибкость в перемещении всех этих четырех компонентов. Они
00:08:24могут находиться на одном компьютере. Оболочка может работать на другой машине, отличной от клиента.
00:08:29Модель может быть единственным удаленным компонентом. Или инструменты могут быть единственным удаленным компонентом.
00:08:34Согласование стандартов и обеспечение качественной поддержки транспортов — это то, что позволит нам
00:08:39перемещать части этого агентного стека. Я могу показать короткое демо и этого тоже.
00:08:46Это клиент, созданный просто чтобы показать, как легко писать клиенты для этого протокола. Я набросал его
00:08:53прошлой ночью и говорю: «Напиши стихотворение». Он снова подключается к тому же процессу на моей машине.
00:09:01В данном случае я запускаю его по сети, но он находится на моем компьютере.
00:09:03Он подключается и отправляет инструкции для goose о том, что делать удаленно. Это может быть в контейнере,
00:09:09это может быть в облаке, но сообщения и используемая библиотека остаются теми же.
00:09:15Так что вы можете очень-очень легко переключаться между локальным и удаленным режимами.
00:09:21Поэтому, если вы хотите подключиться к этой экосистеме, начните экспериментировать с поддержкой,
00:09:25создавая собственные клиенты или добавляя функционал в оболочки.
00:09:29Здесь вы найдете ссылку на сайт протокола клиент-агент с инструкциями по началу работы. Существует множество клиентов
00:09:34и серверов агентов. Это редакторы, десктопные приложения, мобильные приложения,
00:09:41терминальные решения. Наблюдается настоящий расцвет. И я думаю, варианты использования потенциально огромны,
00:09:49верно? Если мы добьемся здесь взаимозаменяемости, люди смогут создавать персональные
00:09:54клиенты именно так, как им удобно для оркестрации своих агентов. Вы можете создавать клиентов
00:10:00под определенные бизнес-домены, для конкретной компании или набора компаний. Вы можете кастомизировать
00:10:06white-label клиент так, чтобы он работал со всеми оболочками. Кроме того, я считаю, что если мы создадим здесь новую
00:10:12категорию, качество клиентских приложений вырастет, верно? Ведь когда появляется
00:10:17экосистема или рынок и есть множество вариантов, пользователи голосуют рублем и ногами, если
00:10:22клиенты не удовлетворяют их потребности. И тогда начнется конкуренция за качество пользовательского
00:10:26опыта. И в целом, я думаю, это должно повысить удобство использования ИИ.
00:10:33На этом у меня все. Большое спасибо. Если хотите пообщаться со мной, найдите меня
00:10:37после выступления или напишите на email. Я буду рад вовлечь вас в эту работу. Спасибо.

핵심 요약

Протокол клиент-агент (ACP) стандартизирует взаимодействие между клиентским ПО и ИИ-оболочками, обеспечивая взаимозаменяемость клиентов и поддержку удаленных сред через HTTP и WebSocket.

하이라이트

  • Проект Goose компании Block разработан как инструмент с открытым исходным кодом и передан в Linux Foundation.

  • Протокол клиент-агент (ACP) создан разработчиками текстового редактора Zed и продуктов JetBrains для стандартизации управления ИИ-оболочками.

  • ACP использует сообщения JSON-RPC и поддерживает расширяемость за счет пользовательских методов.

  • Добавление HTTP-транспорта и поддержки WebSocket в ACP позволяет использовать удаленных агентов в облаке или контейнерах.

  • Агентный стек состоит из четырех ключевых компонентов: клиентского приложения, оболочки (harness), инструментов (MCP) и языковой модели.

타임라인

Проблема фрагментации интерфейсов ИИ-агентов

  • Множество существующих оболочек для ИИ используют кастомные и специализированные интерфейсы.
  • Отсутствие открытого стандарта для клиентского ПО ограничивает гибкость работы с агентами так же, как веб требовал бы использования одного браузера.
  • Протокол контекста модели (MCP) успешно решил задачу стандартизации доступа агентов к внешним инструментам и данным.

Экосистема агентного ИИ столкнулась с появлением множества разрозненных оболочек от исследовательских лабораторий и компаний. В отличие от MCP, который стандартизировал вызовы инструментов и позволил тысячам серверов взаимодействовать с агентами, клиентское программное обеспечение не имело единого универсального стандарта. Создание открытых стандартов формирует полноценные рынки и экосистемы.

Архитектура и возможности протокола ACP

  • Протокол клиент-агент (ACP) был разработан объединенными усилиями создателей редактора Zed и продуктов JetBrains.
  • ACP позволяет единой реализации клиента управлять любой оболочкой, отправлять задачи, получать результаты и запрашивать разрешения.
  • Протокол построен на сообщениях JSON-RPC и поддерживает добавление пользовательских методов через символ подчеркивания.

Разработчики редакторов хотели получить возможность писать одну качественную реализацию клиента для управления любыми оболочками. Нейтральный дизайн ACP выходит далеко за рамки редакторов. Протокол управляет сессиями, передает текстовые сообщения, изображения, аудио, а также уведомления о вызовах инструментов и запросы разрешений от пользователя.

Демонстрация локальной и удаленной работы

  • Редакторы вроде Zed и терминальные клиенты используют единый интерфейс ACP для работы с агентом Goose.
  • Для поддержки удаленной работы в ACP внедрен HTTP-транспорт и возможность апгрейда до WebSocket при сохранении идентичной семантики.
  • Агентный стек включает четыре компонента: клиент, оболочку, инструменты MCP и модель.

Демонстрация показывает работу локального ввода-вывода, где разные клиенты взаимодействуют с одним агентом. Поскольку локального режима недостаточно, разработчики добавили HTTP-транспорт для облачных и контейнерных сред. Гибкость стека позволяет размещать клиент, оболочку, модель и инструменты на любых машинах.

Перспективы экосистемы и варианты использования

  • Открытые стандарты позволяют пользователям создавать персональные клиенты под конкретные бизнес-домены.
  • Развитие экосистемы стимулирует конкуренцию за качество пользовательского опыта в клиентских приложениях.

Взаимозаменяемость компонентов открывает возможности для создания кастомных white-label клиентов и специализированных решений для компаний. Появление стандартов повышает общее удобство использования искусственного интеллекта и улучшает качество клиентского программного обеспечения.

커뮤니티 글

아직 글이 없습니다. 이 영상에 대한 첫 번째 글을 작성해 보세요!

이 영상에 대해 글쓰기