Transcription
Привет, добро пожаловать обратно на "Архитекторы в креслах" в рамках шоу "Основы Azure". Итак, в мире агентов мы уже говорили о том, как вы строите эти вещи. Мы говорили о том, как вы управляете ими, но теперь у вас их целая куча, и теперь они должны работать вместе. И поэтому сейчас мы поговорим об интеграции. Мы поговорим о том, что происходит, когда вы хотите иметь эффективных агентов сохранения и как они общаются с другими вещами. Мы поговорим о протоколах для такого рода вещей. И есть о чем поговорить. Итак, давайте перейдем к архитекторам. Давайте присоединимся к ним прямо сейчас. Привет, добро пожаловать обратно, Ули и Эрик. Так здорово видеть вас в следующем выпуске. Итак, в прошлый раз мы говорили о том, что нужно для управления вещами, как ими управлять, и об аспектах управления, но мне пришло в голову, что мы говорили о вещах так, как будто они уже сделаны, верно? И дело в том, что в мире ИИ мы все находимся в середине, верно? Насколько я могу судить. Я имею в виду, возможно, кто-то закончил, и я еще не встречал их, но я утверждаю, что мы все в середине. Мы все пытаемся понять, как собрать воедино части, которые мы обсуждали в предыдущих выпусках, верно? И поэтому вопрос в том, чтобы не оставлять людей в таком положении, как будто: "Хорошо, круто. У меня на полу куча кусков пазла. Как мне их собрать?" Есть ли способ, которым мы можем объединить все это, чтобы дать им основу для размышлений о том, как собрать воедино части, о которых мы говорили, которые вы бы предложили? Я думаю, что >> возможно, возможно, я могу начать с корпоративной точки зрения, а затем, Эрик, ты перейдешь к строительной части, касающейся того, что происходит. Итак, одна из ключевых вещей, которую мы упомянули в прошлом выпуске, была идентичность. Um, и одна из вещей, которую мы видели в индустрии, и я этим не доволен, но мы начинаем видеть исправления для этого, заключается в том, что мы эффективно используем существующие механизмы идентификации для агентов, и, к сожалению, они были разработаны, как открытая идентификация и подобные вещи были разработаны для людей, и поэтому мы ожидаем управления рисками для людей и наблюдаемости для людей в плане понимания того, что делать, и так далее. У агентов этого нет. Они не люди. И поэтому то, что нам нужно сделать, это эффективно сказать два примера. Жизненный цикл токена для обычного сценария Open ID составляет 72 часа. Не очень хорошая идея. Вы хотите, чтобы программный агент имел токен идентификации ровно на то время, которое ему нужно для выполнения, а затем этот токен идентификации должен исчезнуть, потому что этот программный агент не должен возвращаться как зомби и все еще иметь права доступа к чему-либо. Итак, жизненный цикл токена — это один пример. Другой — это то, что токен Open ID содержит все ваши права как человека, а приложение выбирает то, что ему нужно. Ну, вы не хотите, чтобы программные агенты имели много прав. Вы хотите, чтобы у них было минимальное количество прав, которое им необходимо для выполнения работы. И поэтому идентификация — это инвестиция номер один, которую каждый должен сделать, когда думает об агентах и агентом ИИ. Хорошая новость заключается в том, что корпоративные игроки, такие как Microsoft с Entra ID, мы представляем идентификацию агента с специально адаптированной поддержкой сценариев для программных агентов, но все еще используя ту же открытую идентификацию и API, которые были установлены. Так что для меня идентификация — это основа всего >> верно >> потому что знания и память, а также инструменты также нуждаются в защите со стороны идентификации. Поэтому, когда программный агент приходит и говорит, что я хотел бы получить доступ к знаниям, которые вы можете ограничить, что этот программный агент может видеть, а что нет. То же самое с тем, какие инструменты разрешено использовать и так далее. Так что агенты — это супер, идентификация — это супер важный рычаг для нас для управления программными агентами и ограничения того, что они могут делать. Так что это своего рода вариант первый. Вторая вещь, которую мы обсуждали с Эриком, — это инструменты или слой действий. И опять же, мы еще не особо говорили о протоколах и технологиях. Но именно здесь появилась очень крутая технология от Anthropic под названием MCP. Um, и Дэвид, вы уже упомянули, что аббревиатура означает модель >> контроль. >> Да. Так что я просто, я MC. >> Я неправильно понял? Мне так жаль. >> Нет, нет, ты не понял. Я просто говорю, что ты должен это сказать. модель. >> Ну, это модель разделения протоколов, я почти уверен [смех] >> нам следует проверить факты, потому что я часто называю это протоколом контекста модели, и, возможно, люди просто >> ты, вероятно, прав, будучи очень добрым и не исправляя меня. >> Это контекст, это протокол контекста модели. >> Хорошо, спасибо. MCP. MCP — это то, о чем многие люди слышали, и для меня это ключевой строительный блок, который позволяет вам использовать ваши инвестиции в API и другие, и эффективно оборачивать ваши API в протокол MCP. Протокол MCP, если говорить просто, в конечном итоге является уровнем перевода между тем, что понимает языковая модель, и тем, что представляет API. Почти думайте об этом почти как о вложениях для вашего контекста, вашего контента. Это способ, которым языковая модель понимает реальный мир, действия, которые она может предпринять. И MCP очень сложен. Есть очень много людей, которые сегодня используют основы MCP, но когда вы переходите, например, к ресурсам, которые вы можете использовать, он становится очень богатым и мощным. И это также делает его опасным. То есть агент, у которого есть много доступных инструментов, может делать много всего хорошего и плохого, и поэтому вам нужно быть очень вдумчивым как корпоративный архитектор. Хорошо, я буду использовать MCP, я буду использовать идентификацию, а теперь я пойду и дам агенту ровно столько инструментов и столько прав, сколько ему нужно для выполнения работы, не больше. Итак, этот минимальный жизнеспособный принцип, о котором мы говорим в отношении безопасности и других вещей, очень важен для агентов. Итак, теперь у вас есть идентификация как основа всего. У вас есть MCP, использующий инструменты, API, думайте об этом так. И знания, мы уже говорили об этом, базы данных векторов, документы, что бы это ни было, которые существуют уже давно благодаря RAG. Память — это развивающаяся возможность. Настоящего стандарта еще нет, но я думаю, что MCP будет достаточно, чтобы раскрыть долгосрочную и среднесрочную память сеанса, о которой говорил Эрик. Так что я думаю, это еще одна часть. Опять же, идентификация здесь очень важна. Кто может получить доступ к этой вещи? Что это за программный агент, которому разрешено использовать что-либо и так далее, всегда помните, что у языковых моделей нет концепции авторизации. Поэтому все вокруг должно гарантировать, что программный агент имеет доступ только к тому, что он должен знать для конкретной задачи. Так что это очень важная часть. Хорошая новость заключается в том, что среды векторов, развивающиеся службы памяти, сервер MCP теперь имеют встроенную аутентификацию и авторизацию, так что вы можете ограничить ее с помощью этой масштабируемой модели. И прежде чем я позволю Эрику говорить об агентах, я думаю, что другая часть, в которую, по крайней мере, Microsoft очень сильно верит, заключается в том, что наблюдаемость может находиться поверх Open Telemetry. Open Telemetry — это открытый стандарт, который появляется для инструментирования программного обеспечения и телеметрических данных, и мы считаем, что, хотя нам нужны специфические схемы, то есть специфические модели данных для агентов, потому что они не являются микросервисами или службами, мы считаем, что Open Telemetry как формат кодирования и как первый шаг к тому, чтобы сказать: "Хорошо, вот как мы собираем данные, вот как мы объединяем все это", — это то, что еще не согласовано, но это, безусловно, то, что, я думаю, будет важно. Мы считаем, что Open Telemetry — это отличная отправная точка, и мы будем двигаться дальше. Эрик, почему бы тебе не рассказать немного об агентах и агентах друг с другом и тому подобном? >> Эрик, могу ли я что-нибудь добавить о MCP, прежде чем мы перейдем к агентам друг с другом? Просто то, что, как мне кажется, архитекторы тоже должны учитывать, это то, что MCP — это уровень перевода. Это то, что позволяет вам подключать другие вещи к вашей модели или иметь вашу модель взаимодействовать. И поэтому одно из решений, которое вам придется принять, когда вы будете делать это и выяснять, пишете ли вы свой собственный сервер MCP или что-то еще, это то, что вы решаете, насколько прозрачен этот уровень. Делает ли сервер MCP именно то, что ему говорит LLM? Или у него есть понятие, например: "О, я этого делать не буду". Или у него есть понятие ограничения скорости? Или у него есть понятие, например: "Я позабочусь о том, чтобы я не делал ничего", или вы думаете, что защитные механизмы должны быть на службе, к которой обращается сервер MCP, и говорить: "О, нет, сервер MCP, уходи. Ты задаешь мне слишком много вопросов слишком быстро." Правильно? Итак, это все вопросы, над которыми архитекторам придется подумать, когда они будут проектировать что-то, похожее на эту LLM MCP вещь, что бы это ни было, с чем вы разговариваете. И вам придется решить, где находится ваша бизнес-логика, где находится ваша защита, где находится ваша безопасность в дополнение к простому слою идентификации, потому что если он будет работать как вы или как человек, управляющий LLM, или как LLM, вы должны решить, например: хочу ли я убедиться, что он может делать все, и я просто не... он будет настолько простым, что просто передаст его, просто создаст правильную структуру данных и передаст ее другому API, и вашему API, который его получает, предстоит сделать правильные вещи. Так что это все, я думаю, действительно интересные открытые архитектурные вопросы, над которыми люди должны подумать, когда они используют аспект MCP. Эрик, теперь вернемся в страну агентов. Извините. Нет, мне нравится эта перспектива, потому что именно так я хотел представить следующие несколько пунктов, которые хотел сделать. Но прежде чем мы это сделаем, A2A часто говорят в одном предложении с MCP, но это две совершенно разные вещи. Итак, A2A, что означает агент-агент, которое изначально было предложено нашими друзьями из Google, регулирует способ взаимодействия агентов друг с другом, и существует несколько шаблонов, которые я еще не запомнил, но многие архитекторы могут подумать, что это одноранговая связь, как и с микросервисами. Ключевое — агенты не являются микросервисами. Поэтому одноранговая связь между агентами не обязательно является предпочтительным шаблоном. Итак, A2A — это протокол, который позволяет вам выразить, как агенты фактически общаются, какова структура сообщения, схема этого сообщения и как оно передается. Редко, когда это будет одноранговая связь. Скорее всего, это будет супервизор-рабочий. Скорее всего, это будет публикация и другие типы механизмов, которые на самом деле очень, очень открыты. Когда агенты начинают общаться напрямую через протокол агента, становится намного сложнее инструментировать, понимать и оркестрировать. Поэтому, учитывая это, важно то, как вы фактически заставляете агентов общаться друг с другом в многоагентной оркестрационной архитектуре. Но для наших друзей-архитекторов я хотел бы в основном вернуться к перспективе: "Эй, кто-то думает, что агент — это хорошая идея. Как его построить? Что вы делаете?" И это, конечно, есть инструменты и возможности, о которых мы все говорили, но процесс, с помощью которого вы сначала выясняете, стоит ли вам строить агента. Мы знаем, что можем, но стоит ли? >> Первая перспектива, которую должен рассмотреть архитектор, — заслуживает ли этот агент внимания. Другими словами, агент должен, по моей оценке, выбрать одну хорошую работу, чтобы делать ее хорошо, и он должен быть очень конкретным в отношении того, что это за работа. Когда вы пытаетесь сделать агента, как вы сказали в прошлом выпуске, Дэвид, вроде: "О, ты просто универсал в отношении этих 10 процессов, и ты эксперт," >> именно тогда все выходит из-под контроля. Это может выйти из-под контроля относительно легко. Поэтому моя точка зрения — выбрать одну хорошую работу, а затем, когда вы определяете эту работу, украсить ее ROI, метриками успеха и убедиться, что она измерима. Все умное применимо. Как только вы проверили, существует ли агент, теперь вы начинаете выяснять, каковы архитектурные компоненты. Итак, для меня я разбиваю эти вещи на этапы. Мы хотим убедиться, что мы перечисляем каталог инструментов. Мы хотим убедиться, что мы перечисляем источники знаний. Мы хотим убедиться, что мы определяем, как часто агент должен действовать в отношении этих источников знаний. Все то, о чем мы говорили в предыдущих выпусках, чтобы убедиться, что у нас нет утечки PII, и у нас нет знаний, которые становятся институционализированными знаниями, и что мы имеем внешних оценщиков и защитные механизмы и все такое прочее. Второе — это оценить, что вы знаете, эту перспективу памяти. Как мы на самом деле инструментируем память? Будет ли это краткосрочная, среднесрочная и долгосрочная память? Реализуем ли мы политики TTL, чтобы убедиться, что она постоянно обновляется? Как мы реализуем когнитивный мониторинг, чтобы убедиться, что она последовательно не выдумывает вещи и не обращается к авторитетной памяти? И затем это каркас рассуждений, который мы гарантируем, что как архитекторы он не сможет убежать. Итак, идея заключается в использовании простого планировщика с ограниченными шагами, явными точками отражения, логированием всей этой когнитивной деятельности, планов, возможно, даже потенциально попыткой убедиться, что когда мы обнаруживаем, что он выходит из строя, мы фактически сбрасываем его. Вы, конечно, не хотите рекурсии, потому что вы не хотите, чтобы агент работал долго. Но вы хотите убедиться, что я, как архитектор, знаю, когда объявить банкротство в выполнении моего агента. Он просто вышел из-под контроля, и я не собираюсь пытаться сбросить его 5, 6, 7, 8, 30 раз. Я просто запишу это как сбой. И теперь ваш процесс восстановления агента запускается, чтобы сказать: "Эй, это не удалось. Мне нужно уведомить человека." И затем есть наблюдаемость, которую вы фактически будете использовать, как Ули упомянул, журналы на основе отелей, метрики, трассировки в соответствии со всем, что мы обсуждали в прошлом выпуске. И затем безопасная отправка. Не просто, как микросервис, не просто выпускайте его в мир и говорите: "Эй, мой агент обработки заказов здесь. Бизнес-подразделения, бизнес-линии, пожалуйста, используйте его." >> Выполняйте поэтапные выпуски. Канареечный выпуск 5%. Расширяйте по разным кольцам. Убедитесь, что вы отслеживаете. Убедитесь, что вы отслеживаете затраты и производительность, убедитесь, что он предсказуем с точки зрения того, что ожидается от него. Итак, я хотел дать архитекторам путь от "должен ли этот объект существовать" до "вот как мы его успешно развертываем". Есть ли у вас есть некоторые сходства с сервисами, особенно в последней части, когда вы развертываете, как вы упомянули, Дэвид, например, ограничение скорости >> нам нужны уровни агентов для защиты, потому что они также могут быть перегружены, и это не только плохо с точки зрения времени отклика и тому подобного, но это также может быть очень дорого, если вы используете передовые модели и тому подобное. Поэтому продумывание того, как вы балансируете входящие запросы, время выполнения, стоимость выполнения, все это становится очень важным и даже более важным в мире агентов, чем в обычном программном мире. >> Итак, хорошо. Есть ли что-нибудь еще, что мы хотим сказать людям, потому что я думаю, что мы проделали отличную работу над тем, как должен выглядеть агенто-ориентированный стек? >> Единственное, на чем я хочу остановиться, Эрик уже указал на это, но давайте будем более явными. Итак, некоторые из вас могут помнить фильм "Терминатор" и концепцию Скайнета, и в конечном итоге Скайнет — это сеть автономных агентов, которые стали воплощением в конце концов для молодых детей, которые не видели >> архитектуру, что это крутая, это крутая тема. >> Да, если вы не видели, >> вы должны посмотреть этот фильм, потому что он потрясающий. И идея всезнающего и всепонимающего программного агента лично меня пугает. Итак, Эрик уже сказал: "Дайте только, заставьте агента делать только то, что ему нужно делать. Не пытайтесь создать супер-агента". Я иду на шаг дальше. Я бы предпочел, чтобы вы создали тысячу агентов с очень, очень ограниченной областью действия, которые знают только то, что им нужно делать, и решали проблему управления, чем одного, создающего одного агента, который не знает, что делали тысяча агентов, потому что опять же, я бы предпочел, чтобы мы понимали, что делает эта вещь, и она очень предсказуема. Я понимаю, что происходит, а затем оркестрирую тысячу агентов для достижения желаемого результата, а не имею одного агента, который знает все и делает все. Просто из соображений безопасности, из соображений безопасности, и опять же, это дает нам рычаги для обеспечения того, чтобы происходил только желаемый нами результат. Так что опять же, для тех, кто не смотрел "Терминатор", просто посмотрите его, и вы поймете, что я имею в виду. >> Да, я думаю, мы также смотрели "Терминатор 2". "Терминатор 2" — мой любимый. >> Ну, мы усвоили этот урок о минимальных привилегиях, верно? И у меня есть. Хорошо, если мы собираемся называть названия фильмов, я просто хочу сказать, что каждый раз, когда кто-то говорит MCP, я думаю о "Троне", но это тоже для детей. В любом случае, но это означает что-то другое. Это еще один набор инициалов, которые мы не будем упоминать. В любом случае, я думаю, это хорошее место для остановки, потому что я думаю, что мы проделали хорошую работу по объединению наших предыдущих эпизодов. Есть еще что сказать об агентах, и мы вернемся к этому, но мы закончили это и завязали бантиком, и я думаю, что это будет здорово, и я надеюсь, что вы присоединитесь к нам, потому что мы собираемся перейти в совершенно другое направление в следующий раз, когда поговорим. Так что спасибо, что пришли сюда на "Архитекторы в креслах" в рамках шоу "Основы Azure". И мы с нетерпением ждем встречи с вами в ближайшее время. Большое спасибо. >> Привет, спасибо, чувак. >> Спасибо всем. [музыка]