Transcription
[музыка] >> Давайте начнем, в интересах времени, верно? Итак, привет. Добро пожаловать. Сегодня поговорим о создании интерфейсов для агентов. Итак, позвольте мне начать с вопроса. Кто здесь уже использует MCP-серверы или CLI-инструменты на своем агенте? Хорошо, все? Это неудивительно, честно говоря. А кто здесь уже создал MCP-серверы и развернул их для эффекта? Хорошо, примерно половина людей. Ну, сегодня я поделюсь четырьмя инженерными уроками от команды Chrome DevTools о том, как мы создаем Chrome DevTools для агентов и как мы развернули его для эффекта. Краткое введение. Chrome DevTools для людей используется миллионами веб-разработчиков ежедневно для отладки веб-страниц. Он встроен непосредственно в Chrome, и разработчики используют его для отладки веб-страниц, поиска ошибок, аудита, профилирования производительности и так далее. Да. Итак, теперь поговорим немного больше о Chrome DevTools для агентов. Это специально разработанный Chrome DevTools, но для агентов. Как удивительно. Да, позвольте мне кратко показать, как это работает. Вы можете видеть слева Gemini CLI, и вводится запрос, и теперь Gemini CLI настраивает MCP-сервер, и это открывает Chrome справа, а затем выполняет отладку. Я думаю, да, это касается трассировки производительности. Он выполняет трассировку производительности, анализирует полученную трассировку или информацию о производительности, действует на нее, а затем делает веб-страницу быстрее, проверяет, действительно ли она стала быстрее после этого, и все. Вы должны закончить. Почти закончено. Извините, это видео. Неважно. Что я хотел сказать, так это то, что это будет работать в любом MCP-клиенте и любом агенте, который способен работать с MCP. Не имеет значения. Это был Gemini CLI, также работает в Cloud Code, Codex, Open Claw, неважно. Если вы хотите получить больше информации, перейдите по этому QR-коду, потому что этот QR-код приведет вас на веб-страницу, и там будет все о том, как вы можете его установить, настроить для вашего агента. Снова вопрос. Кто здесь уже пробовал? Хорошо, значит, 10%? Спасибо. Я люблю вас. Я также люблю всех остальных, но других я люблю больше. Итак, я был невежлив. Я не представился. Меня зовут Майкл Хаблих. Я менеджер по продукту Chrome DevTools в Google. А также я приглашенный лектор в университете неподалеку от того места, где я живу. У меня 20 лет опыта в сфере технологий: разработчик, тестировщик, QA-инженер, менеджер проектов, менеджер по продукту, менеджер программ и так далее. Если у вас возникнут вопросы позже, пожалуйста, поговорите со мной в коридоре или свяжитесь со мной через LinkedIn. QR-код приведет вас на мою страницу в LinkedIn. Оба варианта подходят. Пожалуйста, сделайте это. Мне было бы очень интересно поговорить с вами о MCP-серверах, инструментах автоматизации браузеров и тому подобном. Хорошо, но теперь достаточно рекламы. Перейдем дальше. Мы выпустили Chrome DevTools, потому что увидели, что кодирующие агенты работали вслепую. Примерно полтора года назад они были очень хороши в генерации кода, но не могли проверить, что они на самом деле делают, верно? И это просто отстойно. Но мы предполагали, что они будут в порядке, если мы дадим им много данных. Потому что, в конце концов, они машины, верно? Дело в том, что мы ошибались. Это заголовок файла трассировки. Файл трассировки содержит все данные о профиле производительности. И это файл размером в несколько мегабайт, это около 50 000 строк JSON, и мы дали это обычным агентам примерно полтора года назад, что-то вроде того. И, неудивительно, это слишком много данных для агента, для модели, чтобы реально осмыслить, и это вышло за пределы контекстного окна. И если вы видели доклад Мэтта о "dump zone", вы перемещаете агента в "dump zone" в этот момент. Так что я подумал: "Хорошо, мы сделали это неправильно. Это не сработает. Нам нужно что-то другое". Итак, в этом случае, например, то, что мы сделали, наши конечные точки трассировки производительности могут также возвращать данные для последующей обработки другими инструментами, но на самом деле они возвращают markdown и семантические сводки. Например, это пример такой семантической сводки, которая просто дает информацию о типичных метриках производительности, таких как Largest Contentful Paint, IMP и так далее. Я не буду утомлять вас всеми метриками производительности. И мы все равно будем говорить о них, потому что они являются очень хорошим примером того, как это работает. Ну, по сути, мы не заставляли агента читать всю книгу, трассировку, а вместо этого просто указывали ему на нужную строку, и это семантическая сводка. Это работает довольно хорошо. В итоге, или в начале, агенты — это другой класс пользователей. Вот тогда мне стало ясно: "Ага, они своего рода отдельный сегмент пользователей". Так как же нам это осмыслить? Дело в том, что агенты и люди разделяют намерение, разделяют цель, верно? В нашем случае, например, оба хотят выявить ошибки на странице и исправить эти ошибки. Но они думают по-разному. У них разные когнитивные узкие места, более или менее. Для людей это во многом связано с визуальной сложностью. Люди, как правило, очень визуальные существа, и нам нужен макет, нам нужен цвет, чтобы найти сигнал. И это, возможно, не лучший пример для эффективности. Звучит очень оптимистично, и, возможно, так и есть. Я не знаю. О чем это? Итак, эффективность заключается в том, выполняет ли агент весь пользовательский путь? Выполняется ли функциональное намерение на самом деле? Да или нет. А затем есть эффективность, которая, неудивительно, связана с затратами на токены, вызовами инструментов, продолжительностью. В конечном итоге, токены на успешный результат говорят вам о топливной эффективности вашего интерфейса, верно? И есть оговорка, потому что всегда есть оговорка. Топливная эффективность практически бесполезна, если вы не можете добраться до места назначения. Поэтому это называется "токены на успешный результат", а не "токены на результат". Так что убедитесь, что вы также измеряете эффективность, верно? И есть еще одна оговорка. И это то, что вы не можете измерить это глобально. Я имею в виду, вы можете это сделать, но, возможно, вы захотите это сделать, потому что это хорошая метрика, но она будет чрезвычайно отличаться между различными пользовательскими путями и классами задач. Так что не сравнивайте их глобально, сравнивайте их в рамках вашего пользовательского пути, который вы измеряете. И то, что я имею в виду, например, в Chrome DevTools у нас есть пользовательский путь веб-скрейпинга, верно? Агент заходит на веб-сайт и извлекает информацию. Это относительно дешево. Но есть и более сложные пользовательские пути, такие как отладка веб-сайта, выяснение, почему адаптивный макет не работает. Это потребует больше токенов, но это нормально, потому что это гораздо более сложная и интерактивная сессия, которая происходит. Хорошо, как это выглядит в реальной жизни? Вот как это выглядит на практике для внутреннего проекта, над которым мы работаем, и вы видите много неоновых полос, что отлично. Я люблю неоновые полосы. Но я не буду беспокоиться о деталях. Важно то, что неоновые полосы слева, чем длиннее полоса, тем эффективнее инструмент. Верно. Чем короче полоса, тем менее эффективен инструмент для конкретного случая использования. Так что каждая из этих полос слева относится к случаям использования. Это означает, что на меньших полосах, вероятно, нам следует сосредоточить нашу работу дальше, как улучшить это, как улучшить токены на успешный результат там. Да. Как вы, возможно, уже догадались, измерение токенов на успешный результат не является простым. Дело в том, что даже несовершенное измерение лучше, чем просто принятие решений на основе интуиции. И с этим вы, по крайней мере, можете принимать решения, основанные на данных. Верно. Иэн, извини. У меня был включен звук. В DevTools для агентов мы решаем проблему "сжигания токенов" с трех разных сторон. Во-первых, это категоризация инструментов. Очень просто, мы скрываем нишевые инструменты за параметрами командной строки. Например, у нас есть инструменты для отладки расширений Chrome. И не все разрабатывают расширения Chrome. Так зачем добавлять их в меню контекстного выбора по умолчанию? Нет смысла в этом. Затем есть "slim mode" (тонкий режим). И это интересно. Итак, "slim mode" доводит категоризацию инструментов до предела. Он предоставляет только, я думаю, три разных инструмента: "выбрать страницу", "перейти на страницу" и "выполнить скрипт". И это отлично для вашего контекстного окна, но есть компромисс. Я буду много говорить о компромиссах сегодня. Есть компромисс, потому что чем меньше инструментов вы предоставляете, тем меньше инструментов доступно для вашего агента, что означает, что ваш агент может совершать дополнительные ходы для достижения той же цели. У него может не быть нужных инструментов для выполнения чего-либо, например, для получения сетевых запросов. Вы не можете сделать это с помощью "выполнить скрипт". И тому подобное. Да, и есть также интерфейс командной строки. Извините, есть интерфейс командной строки, который мы предлагаем. Вы, возможно, видели предыдущий доклад о моделях кода и всем таком. Мы также это поддерживаем. Так что это MCP-сервер, да, но есть также интерфейс командной строки для того же самого, предоставляющий вам почти ту же функциональность. Что это позволяет вам, вы можете объединять команды агента для выполнения последующей обработки. Как в этом примере, я не думаю, что вы можете это увидеть. Дерево доступности извлекается с помощью команды grep, а затем результат, идентификатор элемента управления, передается в команду click. И это, конечно, экономит много токенов, потому что модели не нужно обрабатывать все токены. Последующая обработка токенов происходит на вашем компьютере. Верно. Эффективность бесполезна, если ваш агент застрял. Это подводит нас к восстановлению после ошибок. И да, потому что каждый раз, когда ваш агент сталкивается с ошибкой, это стоит вам токенов, потому что ему нужно повторить попытку, ему нужно понять, что происходит, и тому подобное. И это просто отстойно. О да. Восстановление после ошибок — это спектр, и давайте поговорим немного об этом, о том, что мы делаем здесь. Итак, во-первых, конечно, вы должны добавить полезные сообщения об ошибках. Это звучит очевидно. Для многих инструментов это не так. И это также не было очевидно для всех инструментов, которые мы фактически предлагали, поэтому мы также сделали несколько итераций по ним, чтобы сделать сообщения об ошибках хорошими. Например, здесь, невозможно вернуться на выбранную страницу для определенной записи истории навигации, потому что она не была найдена. Мы фактически добавили последнее предложение, и это позволило агенту самовосстанавливаться, что очень полезно, потому что тогда агенту не нужен человек, чтобы исправить проблемы, а агент может сам их исправить. Затем есть проактивные обходные пути. Итак, под каждым из агентов есть модель, и модель обучается на определенных данных. И иногда есть вещи, которые вы хотите противопоставить обучающим данным. И это то, что вы можете сделать с помощью проактивных обходных путей. Например, в этом примере мы направляем агента для профилирования производительности к нашему инструменту "start performance trace" (начать трассировку производительности), а не к аудиту Lighthouse. И есть диагностические руководства. Итак, мы также предлагаем навыки, конечно. И у нас есть навык под названием "troubleshooting" (устранение неполадок), и мы видим, что многие люди испытывают проблемы с правильной настройкой MCP-сервера Chrome DevTools, и этот навык устранения неполадок затем активируется и помогает человеку и агенту исправить проблемы с настройкой. Снова обеспечивая самовосстановление агента. И все это повышает устойчивость вашего продукта, агента, который вы создаете. И это хорошо и помогает вам в выявлении ошибок. А теперь поговорим об обнаруживаемости, которая заключается в предотвращении ошибок. Наш первоначальный дизайн имел один монолитный инструмент под названием "debug webpage" (отладить веб-страницу). У нас был только один инструмент, "debug webpage". И другой агент мог отправить туда запрос и сказать: "Эй, отлади эту веб-страницу. Есть какой-то адаптивный макет, который не работает". И это было удобно с инженерной точки зрения, но на самом деле не работало. Итак, мы разделили его на 25 различных инструментов. И решили ли мы проблему? Решили ли мы ее? Конечно, нет. Потому что мы переложили эту проблему на другую. И это было то, что у агентов теперь было 25 инструментов в их распоряжении. Как вы узнаете, какой из них использовать и когда? Давайте поговорим об этом. Согласно этой статье, 97% описаний инструментов MCP имеют "запахи качества". И это важно, потому что схема — это пользовательский интерфейс для агента. Так давайте сделаем пользовательский интерфейс лучше. И исправление этого — это компромисс, как я уже сказал. Это всегда компромисс. Потому что, конечно, вы можете улучшить описания, и это увеличит размер вашего контекстного окна. Так что, вероятно, вы не захотите этого. Или, возможно, захотите. А также, меньшие модели, в частности, не очень хорошо справляются с большим количеством описаний, потому что они предвзято относятся к использованию инструментов, которые они не должны использовать в первую очередь. Есть пространство для компромиссов. Прочтите статью. Очень интересно. Да. Но есть несколько вещей, которые вы действительно должны делать, которые относительно бесспорны, и это определение цели. Четко объясните, какова основная функция инструмента. Это работает? Да. Вот оно. Четко объясните основную функцию инструмента, и есть руководства по использованию, например, предоставьте четкие критерии активации. И как это выглядит, например, в Chrome DevTools для агентов? И снова, инструмент "start performance trace". В описании мы указываем: "используется для поиска проблем с производительностью фронтенда и основных веб-показателей: LCP, INP, CLS". Почему это важно? LCP, INP, CLS — это метрики производительности веб-сайтов, и агент может установить связь: "О, я буду использовать этот инструмент, если мне нужно, например, улучшить загрузку страницы". Мы далеки от оптимизации этого, потому что модели и агенты постоянно меняются, так что это своего рода бесконечный поиск минимально жизнеспособного описания. Да, но это то, что есть. Вы можете улучшить все это с помощью навыков. Как я уже сказал, у нас также есть навыки, и это отлично, особенно если у вас более сложные рабочие процессы. Но опять же, есть компромисс. Они не бесплатны. Если вы добавите слишком много навыков, вы сместите проблему и снова столкнетесь с той же проблемой. Агенты будут вызывать ваши навыки, даже если не должны. Размер вашего контекстного окна увеличится, и все такое. Компромисс смещается, он не исчезает. Итак, мы оптимизировали затраты, восстановление и обнаруживаемость. Давайте теперь поговорим о доверии, потому что вы не хотите иметь бэкдор в систему. Chrome DevTools для агентов имеет функцию под названием "автоподключение", и она позволяет вам, человеку, использующему вашего кодирующего агента, например, Cloud Code, делиться экраном с агентом, говоря: "Эй, я застрял здесь. Помоги мне отладить это и исправить проблему, которую я здесь вижу". Потрясающая функция. Мне она очень нравится. И пользователи, конечно, просили эту функцию: "Эй, почему мне приходится постоянно нажимать "разрешить"? Я не хочу этого делать. Пожалуйста, запомните мой выбор". И в традиционном дизайне пользовательского опыта это было бы явным преимуществом, верно? Потому что это просто устраняет трение, которое вы хотите устранить. В мире, где вы делегируете работу агентам и автоматизируете ее, вам нужно думать о границах доверия. И поэтому мы фактически разработали его так, чтобы трение было преднамеренным, потому что мы не хотели этого. И почему? Давайте поговорим об этом. Есть пост в блоге Саймона Уилсона о "смертельном три факторе". QR-код. Вам стоит его прочитать, он отличный. Я больше не буду об этом говорить. И используя это, есть три уровня, по крайней мере, три уровня, о которых я думаю в браузерных агентах, более или менее. У вас есть первый уровень, и это локальная среда разработки. В локальной среде разработки у вас есть человек в цикле, и человек хочет предоставить доступ к профилю Chrome по умолчанию к данным, к которым у вас уже есть доступ, агенту на ограниченное время. А затем у вас есть второй уровень, и второй уровень — это агенты, работающие в среде непрерывной интеграции. Это контролируемые среды, но они изолированы. В этот момент вы должны использовать средства разделения данных, такие как контейнеры, конечно, но также и другие вещи, такие как отдельные профили Chrome и тому подобное. Если вы хотите подключиться к ним, у нас также есть механизм для этого, и он называется "порт удаленной отладки". И третье — это агенты с полным доступом в Интернет, и это, по сути, режим YOLO, потому что любая веб-страница там способна выполнить какую-то цепочку текстовых запросов к вашему агенту. Так что убедитесь, что они делают то же самое, что и на втором уровне, но также и на третьем уровне, убедитесь, что у них есть список разрешенных доменов и средства предотвращения инъекций запросов, все это вместе. Возвращаясь к "смертельному три фактору", именно об этом мы в основном рассуждаем на первом уровне, и именно здесь все эти три вещи сходятся. Поэтому мы фактически говорим: "Нет, человек должен каждый раз давать согласие". Ключевой момент: локальный агент, первый уровень, и парк браузерных агентов, третий уровень, где могут быть ваши исследовательские агенты, могут совместно использовать такой инструмент, как Chrome DevTools для агентов, но они не должны совместно использовать ничего другого из вашей модели безопасности, верно? Хорошо. Давайте подведем итог. Пользовательский опыт развивается, чтобы включать опыт агентов. Агент — это просто еще один тип пользователя, сегмент пользователя, также с нефункциональными требованиями. Эффективность, обнаруживаемость, безопасность, стабильность и так далее. Я поделился четырьмя выводами из Chrome DevTools для агентов. При реализации этого мы измеряем топливную эффективность интерфейса с помощью токенов на успешный результат. Превращайте ошибки в руководства по восстановлению. Аудируйте описания на предмет намерений и никогда не жертвуйте доверием ради удобства. Агенты — наши следующие пользователи. Давайте поможем им помочь нам. И на этом я желаю вам приятного продолжения конференции. >> [аплодисменты] [музыка] [музыка]