Transcription
[музыка] Жар. Жар. Жар. Жар. Н. Жар. Жар. Н. [музыка] Жар. Жар. Н. Жар. Жар. [музыка] Привет и добро пожаловать на стендап .NET AI сообщества. Эм, я Джон Гэллоуэй. Я ваш приглашенный ведущий сегодня, потому что Бруно в Бостоне. >> Да. О боже, ты заставляешь меня чувствовать себя так плохо. Вот как ты должен начинать шоу. Я всегда начинаю говорить что-то вроде: «Это потрясающе», а затем представляюсь и благодарю всех, а также Стива за то, что он здесь. Я очень жду возможности узнать больше об этом, и я буду здесь всего две минуты, а затем переключусь на чат, потому что, как вы видите, я не в стандартном офисе, я посреди поста, а также поддерживаю другое мероприятие. Так что большое спасибо Джону за помощь в проведении этого, потому что SDK — это супер круто, чувак, я создаю такие маленькие и паршивые приложения, получаю столько удовольствия от этого, и это потрясающе, мне это нравится. Хорошо. И мы оба очень рады, что к нам присоединился Стив сегодня, чтобы поговорить о CLI и SDK для разработчиков .NET. >> Привет. >> Отлично. Ну, у меня есть несколько ссылок сообщества, которыми я поделюсь, а затем мы передадим слово вам. Эм, так что позвольте мне поделиться своим экраном, и это вот этот. Хорошо. И добавить на сцену. Вот так. Хорошо. Итак, на прошлой неделе у нас было веселое и захватывающее объявление. Это было использование SDK с Work IQ. Эм, так что это действительно отличный пример подключения всех ваших коммуникаций и всей вашей бизнес-аналитики, знаете ли, будь то SharePoint или что-либо еще, вы можете подумать о Microsoft Graph. Так что это подключает весь этот контекст как сервер MCP, и вы увидите несколько отличных примеров. Есть демонстрационные видео, показывающие это, и, например, создание диаграммы архитектуры на основе разговоров, что просто сносит крышу. А затем у Берка есть действительно крутое видео, где он рассказывает о создании расширения VS Code, которое делает такие вещи, как получение предстоящих встреч и документов, и вещей, которые ему нужно будет просмотреть перед этими встречами. Так что это, мне нравится его сценарий, потому что он говорит: «Я погружен в это, знаете ли, я погружен в свой код. Я кодирую. Внезапно, нет, у меня скоро встреча, и внутри VS Code что-то всплывает, рассказывая вам об этом. Так что здесь есть информация о том, как настроить это. Эм, и вы увидите, что это настроено как сервер MCP. Я помогал за кулисами с этим постом, так что мне пришлось сделать небольшую пасхалку и убедиться, что мое имя было упомянуто хотя бы раз в посте. Так что это вот это. Эм, еще одна интересная вещь, у нас только что вышел пост в блоге сегодня утром. Это от Джереми. Эм, здесь он говорит о том, что начинает серию о строительных блоках .NET AI essentials. Так что он начинает здесь с MEAI, и он будет проходить через векторные данные, фреймворк агентов и MCP. Так что это, он сделал несколько других постов об этом, просто как бы отступая назад и глядя на основы. Очень часто мы получаем своего рода «вы знаете, мы говорим: «Вот новый релиз, он добавляет все эти отличные новые функции», и у нас есть люди, которые говорят: «Отступите немного и просто объясните больший контекст», и вот что делает эта серия. Так что я рад видеть остальные из них, когда они выйдут. Еще одна случайная вещь здесь. Это то, что я увидел вчера в чате. Это публичный PR, так что я думаю, что могу им поделиться. Но это, это интересная вещь. Добавление в фреймворк агентов, раскрывающее реализацию AI-агента SDK GitHub Copilot. Мне потребовалось некоторое время, чтобы разобраться в этом, но общая идея заключается в том, чтобы иметь возможность рассматривать SDK GitHub Copilot как агента, иметь возможность включать его в задачи и рабочие процессы и все такое прочее. Так что это просто слитый PR, он выйдет в какой-то момент, но я просто подумал, что это довольно интересная вещь. И эм, я закончил. [смех] Итак, Стив, я полагаю, нам передать слово тебе? >> Да. Хорошо. Отлично. Ну, я очень рад быть здесь и пообщаться со всеми об этом. Эм, так, мы поставили заголовок «Использование Copilot CLI и SDK для разработки .NET». И, конечно, мы поговорим об этом, но я также действительно хочу провести немного более широкую беседу. Так что довольно много из того, что я собираюсь показать и рассказать, на самом деле не будет специфичным для .NET, потому что это не обязательно так, как когда вы занимаетесь агентным кодированием, часто это не имеет никакого значения, какой язык вы используете, и иногда вы можете даже не знать или не заботиться об этом сами. Эм, так что, знаете, это более широкий набор концепций, которые, я думаю, сейчас, возможно, немного интереснее. И, честно говоря, кажется, что это большой момент во всей истории программного обеспечения, через который мы проходим, и я хочу открыть немного более широкую беседу с этой группой и узнать, что люди чувствуют по этому поводу, как и какие методы и советы у людей есть для успеха, поскольку этот новый мир развивается. Итак, позвольте мне поделиться своим экраном, и мы начнем обсуждать некоторые из этих вещей. И, Бруно и Джон, в любое время, когда вам захочется, пожалуйста, просто вмешивайтесь, и мы обсудим все, что вы хотите. Итак, у меня есть около получаса контента для рассмотрения. Эм, но, знаете, мы можем корректировать по ходу дела. Я пытаюсь поделиться своим экраном, но сейчас вот так. Весь экран. Пока ты это делаешь, я просто расскажу забавную побочную историю, но есть действительно интересная вещь, как ты говоришь, в этот момент, когда сам язык или код является своего рода артефактом. И я недавно создал одностраничное приложение, и я создал его с помощью React и Vit и разместил на GitHub Pages. Я не являюсь человеком .NET, я едва ли, я чувствую себя очень неуютно, создавая на этих языках, и это прекрасно работало, используя Copilot. Это было что-то, что было немного проще в этом, знаете ли, используя его с хостингом GitHub Pages, и я был шокирован тем, что, да, все работало, знаете ли, это было своего рода забавно. Итак, хорошо, позвольте мне показать вам экран. >> Хорошо. Хорошо. Итак, давайте подумаем о общей картине того, что происходит в индустрии, и, по сути, о том, что представляет собой наша индустрия, чем мы занимаемся весь день? Хорошо. Итак, давайте считать себя разработчиками программного обеспечения. Итак, эм, почему мы вообще этим занялись? Я полагаю, что у большинства людей в этом звонке есть что-то общее: мы любим компьютеры, это очень общий момент, но мы, вероятно, большинство из нас с детства, и мы любим решать проблемы, используя свой мозг, мы наслаждаемся всем процессом тщательного обдумывания вещей, придумывания решений и дизайнов и превращения этого в реальную вещь, которая радует людей во внешнем мире, и, знаете ли, это хороший образ жизни для нас. Мы можем тусоваться с нашими компьютерами, пить кофе, болтать с другими гиками и, знаете ли, решать интересные проблемы. Это здорово. Мы все, знаете ли, много от этого выиграли. Я знаю, что я выиграл. Эм, но сейчас все кажется немного меняющимся, потому что до этого момента мы могли делать это, потому что у нас была уникальная способность, которой не было у других людей. Мы могли создавать работающий код, а другие люди не могли. Но это уже не совсем так, потому что теперь не только люди могут создавать код, верно? Машины тоже могут создавать код. И поэтому ландшафт вокруг нас начинает меняться. Как это произошло? Ну, все произошло действительно за последние пару лет, и я уверен, что все здесь это видели. Итак, эм, куча продуктов появилась на рынке в довольно быстрой последовательности. Итак, сначала у нас была волна IDE и веб-систем кодирования, кодирующих агентов. Итак, Cursor показал нам, как можно добавить кучу инструментов кодирования на основе ИИ в IDE. Довольно быстро после этого VS Code добавил свой режим агента. Итак, VS Code уже имел функцию Copilot, но это был, по сути, просто автокомплит на основе ИИ. А затем появился режим агента, чтобы превратить это во что-то, что было способно решать большие проблемы и проходить многоэтапный процесс для решения ваших задач. И у нас также был GitHub Copilot в Интернете, вещь, которая может отвечать на ваши комментарии и создавать для вас PR против вашего репозитория. И это изменило то, как мы могли производить код впервые. Но затем пришла вторая волна, и, хотите верьте, хотите нет, это было всего около шести месяцев назад, появление CLI. Итак, у нас появился Claude code, который создал эту новую категорию продуктов — опыт агента внутри CLI, за которым довольно быстро последовали Gemini CLI и Codeex CLI, и GitHub Copilot. И эти вещи стали невероятно популярными. Они популярны, возможно, потому, что они дают такое ощущение непосредственности. Они не привязаны к конкретной IDE или конкретной концепции контроля версий или чему-либо еще. Они могут работать в любом каталоге. Вы просто открываете их, говорите им, что делать, и они просто начинают работать. И они очень затягивают. Некоторые люди считают их своего рода машинами дофамина. Вы просто даете им что-то, чтобы решить проблему для меня, и через 5 секунд у вас есть какой-то прогресс. Так что люди очень восторженно приняли такие вещи. Хорошо. Итак, я знаю, что существуют разные мнения по этому поводу. Некоторые люди в этом звонке будут очень увлечены всем этим и будут использовать это все время. Другие скажут: «О, я еще не пробовал». А некоторые, вероятно, подумают: «О, мне активно не нравится это направление, в котором движется наша индустрия». Итак, я думаю, что нам будет полезно пройти через некоторый опыт того, как это делается, и разобраться, как мы можем добиться успеха с этим, и какие вопросы это вызывает у нас о том, как мы выполняем свою работу, и какое будущее индустрии мы создаем для себя. Хорошо, люди говорят, что это дает им феноменальное повышение производительности. Теперь я не знаю, верите вы им или нет, но я дам вам несколько статистических данных от команды, в которой я работаю. Итак, я около трех-четырех месяцев назад получил доступ к ранней сборке Copilot CLI, и я был настолько убежден в этом, что в течение пары часов я начал узнавать о переходе и работе в этой команде. И вот что я делаю сейчас. Теперь я работаю в команде Copilot CLI, и мы, очевидно, очень активно используем наши собственные продукты для нашей работы, и это [смех] просто некоторая статистика, которую я собрал сегодня утром. Итак, у нас команда из примерно 7-10 человек, и мы выпустили более 200 вещей только за последнюю неделю. Теперь такой уровень прогресса для меня неслыханный до этого. Признаюсь, некоторые из этих PR — это просто однострочные исправления, изменения документации или что-то в этом роде, но я бы сказал, что реалистично мы выпустили более сотни нетривиальных вещей за последнюю неделю. Так что, да, это абсолютно производит радикальное изменение для нас. И для всех, кто еще не пробовал, я думаю, стоит попробовать, чтобы получить быстрый опыт того, каково это. Давайте представим, что мы сейчас в команде Copilot CLI и хотим добавить функцию в продукт. Насколько легко или сложно нам будет что-то выпустить? Итак, скажем, мы хотим иметь способ знать, какие модели, какие AI-модели можно использовать в Copilot CLI. И, возможно, мы хотели бы иметь команду вроде copilot show models. Сейчас такой команды нет. Если вы попытаетесь это сделать, вы просто получите ошибку. Итак, давайте попробуем реализовать эту функцию самостоятельно, используя Copilot, конечно. Итак, мы открываем это, получаем классическое представление CLI кодирующего агента, а затем даем ему инструкцию. Итак, скажем, добавьте команду show models в CLI, которая выводит список доступных моделей для обработки стандартного вывода. И мы позволим этому начаться. Очевидно, что это не очень сложная инструкция, которую мы дали. Он начнет работать над ее исследованием. Вы увидите, что изначально он решил использовать здесь под-агента под названием explore. Это функция, которую мы только что выпустили. Так что он может выполнять фоновые задачи, потенциально параллельно. Сейчас он выполняет только одну. Так что у него есть специализированный агент, который знает, как искать кодовую базу и выяснять, что делать. Это только что завершилось. Что он будет делать дальше? Он просматривает остальной код, чтобы выяснить, куда поместить вещи. Он решил, что ему нужно решить, куда добавить флаг. Он выясняет, как мы регистрируем флаги, и продолжает там. Он нашел пример чего-то похожего. Он решил, куда, хорошо, он уже внес правку в код, и теперь ему нужно добавить фактическую реализацию для этого. Так что давайте просто подождем, пока он завершится. Хорошо, он решил, что хочет собрать CLI, что он и делает. Что он будет делать дальше? Он проверит, работает ли это на самом деле. Так что он запускает его сам, чтобы увидеть, какой вывод получается. Он решил, что вывод правильный, и он закончил. Так что я вышел оттуда. Хорошо. Итак, давайте посмотрим, что у нас есть. Давайте сделаем get diff. Теперь у нас есть. Хорошо. Итак, он добавил этот show models и обработчик для него. Это очень, очень простой код. Но давайте посмотрим, работает ли он. Работает. Хорошо. Круто. Так что, знаете, за 30 секунд мы добавили нашу функцию. Теперь вы можете подумать: «Хорошо, но это всего лишь функция из шести строк». Это правда. Очевидно, это очень тривиально. Сложная часть — решить, куда добавить эти шесть строк, и знать, что вы правильно следуете всем существующим шаблонам, но я надеюсь, что это даст вам представление о том, как каждый разработчик может выпускать по 10 функций в день. Очевидно, большинство из них будут более сложными, чем это, но это определенно меняет опыт создания кода. Хорошо. Итак, это заставляет нас по-другому думать о том, как мы производим программное обеспечение. Некоторые правила, по которым мы работали всю нашу карьеру до этого момента, начинают казаться немного другими. Так что одно из больших изменений заключается в том, что теперь кажется, что вы можете производить любое количество кода, которое хотите, очень быстро. Так что вам не нужно быть щепетильным по поводу того, что я реализовал что-то, поэтому мы должны это выпустить. Мы постоянно реализуем вещи, а затем не выпускаем их, потому что, знаете ли, мы меняем свое мнение о вещах или находим лучший способ. Когда дело доходит до прототипирования, вам не нужно выделять три дня, чтобы создать прототип большинства вещей. Теперь вы можете сделать это за, знаете ли, полчаса, если вы просто делаете что-то на прототипном уровне. Это означает, что мы подходим к дизайну по-другому. В прошлом мы думали: «Хорошо, прежде чем вложить неделю работы во что-то, нам лучше провести серию встреч, чтобы убедиться, что у нас есть консенсус и мы все продумали». Мы больше этого не делаем. Мы просто реализуем это, возможно, несколько раз по-разному, чтобы увидеть, как это получится. И мы учимся, делая что-то. Когда у вас есть реализованная функция, вы можете подумать: «Ну, работает ли она хорошо? Вписывается ли она в остальную часть системы? Возникают ли у нас какие-либо странные проблемы, которые мы не предвидели?» И тогда мы можем просто выбросить ее, если это так, знаете ли. >> Не возражаете, если я вставлю быстрый вопрос? >> Многие знают вас как изобретателя Blazor, и я заинтригован этим контекстом, как бы вы думали о том, как вы прототипировали и создавали это, если бы у вас были Copilot и подобные инструменты, доступные тогда. >> Да, я имею в виду, я полагаю, это было бы намного быстрее и проще. Я не говорю, что все программное обеспечение стало быстрее и проще. Мы перейдем к некоторым способам, которыми это потенциально даже сложнее, и могут возникнуть новые проблемы. Это будет не просто чистая продажная речь. Я сразу же укажу на это. Но я бы сказал, что для этого конкретно [смех] задача создания прототипов, где вам не нужно заботиться о том, чтобы все детали были действительно правильными, тогда абсолютно это было бы намного, намного, намного быстрее. И, вероятно, многие детали, которые нам пришлось оставить, пока мы не смогли потратить много времени на их решение, мы могли бы просто решить их заранее. Например, знаете ли, нам потребовалось так много времени, чтобы получить поддержку отладчика в WebAssembly. Возможно, она была бы там на первой неделе, если бы, знаете ли, мы могли просто бросить кодирующего агента на это. Я не знаю. >> Вау. >> Круто. Хорошо. И эй, извините, я тоже собираюсь вмешаться. Кстати, это потрясающе. Это самая быстрая и самая потрясающая демонстрация, которую я видел за две секунды Copilot CLI. Так что мне это нравится. Мне нужно уйти. И последнее предложение: я проверю YouTube-канал и оставлю там комментарий. Мне нравится, что вы сказали, что это классический Copilot CLI, и он существует всего пару недель, но он уже [смех] классический. Все движется так быстро, что мне очень нравится, мне очень нравится, что это своего рода круто делать. Так что, эй, еще раз спасибо всем. Увидимся онлайн и до следующего раза. Отлично. Хорошо. Итак, это меняет то, как мы начинаем думать о вещах, но некоторые вещи могут стать для нас сложнее. И мы еще не знаем, чего мы не знаем. Давайте попробуем подумать о способах, которыми это может вызвать у нас проблемы, может сделать нашу работу даже не тем, чем мы хотим, чтобы она была, чтобы попытаться предвидеть, куда все движется, и попытаться направить вещи так, чтобы они были такими, какими мы хотим, и мы можем предвидеть проблемы, которые могут возникнуть. Итак, мы дойдем до этого по ходу этого разговора. Итак, происходит так много всего с кодирующими агентами. Очень трудно отслеживать все различные функции, возможности и стратегии и так далее, которые доступны людям, использующим их. Итак, некоторые из функций, которые мы перечислили, я вернусь к этому через минуту. Я собираюсь продемонстрировать под-агентов прямо сейчас, но это займет несколько минут. Так что я хочу запустить это, а затем мы вернемся к этому через секунду. Хорошо, давайте просто подумаем о сценарии обзора кода, это классическая вещь, которую нам всем приходится делать. Итак, если бы я мог просто открыть браузер. Итак, мне нужно придумать что-то для обзора кода. Итак, вот интересный проект .NET, о котором я не знаю, все ли вы знаете. Это реализация игрового движка Doom на .NET. И, эм, все это с открытым исходным кодом. Все написано на C. Это довольно сложная кодовая база. Это большая и сложная вещь. Вот PR, который пришел, ну, несколько недель назад. И если мы зайдем туда, мы скажем: «О, его будет довольно легко просмотреть, не так ли? Изменилось всего два файла». Но затем вы видите эти два измененных файла и думаете: «Боже мой, кто будет это просматривать? Как я разберусь во всем этом?» Хорошо, что если где-то в этой математике есть тонкая ошибка? Кто ее заметит? Хорошо. Итак, давайте попробуем использовать Copilot для этого. Итак, я нахожусь в исходном коде игрового движка и собираюсь перейти в Copilot, и я собираюсь попросить его сделать обзор для меня, но я сделаю это особым образом, который вы, возможно, раньше не видели. Итак, я скажу «review the PR». Я вставлю URL, но сделаю это параллельно через Opus, Haiku и Gemini. Итак, это три разные модели агентов, которые доступны. Итак, Opus и Haiku — это обе версии Claude, а Gemini — модель Google. Так что это начнет просматривать этот PR. Он будет использовать команды git для получения деталей с GitHub. Он начнет проверять diff. Он использует интересную технику обработки больших объемов данных. Так как мы получили большой блок данных из этого PR, 96 килобайт, он не будет помещать все это в контекстное окно, потому что это начнет, знаете ли, переполнять контекстное окно. Так что он сохраняет его на диск, а затем может читать разные части этого. И как только он разберется, он скажет: «Теперь я запущу параллельные обзоры кода с разными моделями». И он запустил агентов для Opus, Haiku и Gemini 3. Хорошо. Теперь им может потребоваться минута, чтобы пройти. Так что, пока это делается, давайте посмотрим на это снова. Хорошо. Итак, если вы занимаетесь кодирующими агентами более двух недель, вы будете знать, что все меняется очень быстро. Это набор функций, и, глядя на это, примерно половина или более половины из них были выпущены за последние две недели. Так что, знаете ли, все движется так быстро, что трудно уследить. Так что под-агенты — это способ, которым Copilot или другие кодирующие агенты могут запускать подпроцессы внутри себя, потенциально с разным контекстом, разными моделями и проверять результаты. Режим планирования я продемонстрирую, и это способ заранее спланировать большую работу. Навыки — это способ создания повторно используемого контекста, который вы можете скачать и поделиться, и получить возможность выполнять определенные задачи. Я приведу пример этого. Делегаты — это способ, которым мы можем начать работу локально и отправить ее в облако для продолжения, если вы не хотите использовать свои локальные ресурсы для этого. Память отслеживает контекст в разных сессиях и даже между разными разработчиками в вашей команде. Так что, когда один разработчик учит его чему-то вроде «вот как мы пишем тесты», эти знания будут подхвачены другими разработчиками в вашей команде. Хуки — это способ выполнения детерминированных обратных вызовов, когда агент делает что-то, чтобы вы могли вызвать свой собственный вспомогательный код, чтобы, знаете ли, проверить, довольны ли вы инструментами, которые он использует, или чем-то еще. MCP, я уверен, что большинство людей слышали об этом. Это способ подключения внешних инструментов. Бесконечные сессии — это способ никогда не исчерпать контекст, который мы выпустили всего около двух недель назад. Плагины — это способ получения таких вещей, как хуки и навыки, и так далее. Я продемонстрирую это через минуту. И это упоминание git — это осознание, к которому многие из нас пришли за последние несколько недель, что вам больше не нужно вызывать git самостоятельно. Вы никогда не решаете свои собственные конфликты слияния. Вам даже не нужно писать описания PR. Вы можете просто сказать агенту сделать это, и он сделает это. Это так освобождает — не писать описания PR и не иметь дела ни с чем, связанным с ветвлением и слиянием git и тому подобным. Агент просто делает все это. >> Хорошо. вы упомянули, что ранее был отличный комментарий по этому поводу. >> Да, позвольте мне посмотреть, от KJ Betts, говорящего об автоматизации агента с использованием GitHub CLI, и я не уверен, намеренно ли это, но есть GitHub CLI и GitHub Copilot CLI. Я использовал GitHub CLI для автоматизации и говорил, например, «используй GitHub CLI для создания проблемы или чего-то еще, верно?» и, как вы говорите, иметь эту абстракцию, возможность сказать, говорить не только с командной строкой git, но и с командной строкой GitHub, и просто сказать, например, «используй командную строку GitHub, создай эту проблему или что-то еще». >> Да, абсолютно. Да. Ну, я провожу все свое время в Copilot CLI. Так что я просто скажу что-то вроде «создай PR из этого». Я не говорю ему, как это сделать. Я не говорю: «Ты должен использовать команду GH» или что-то в этом роде. Он знает, он разберется в этом и сделает хорошую работу. >> Хорошо. Итак, наш многоагентный обзор завершен. Итак, мы получили отзывы от Claude Opus, от Haiku и от Gemini. И у них у всех немного разные мнения. И это отличный способ справиться с такими вещами, как риск галлюцинаций. Так что, просто потому, что один из них галлюцинирует, не значит, что другие будут, и они будут эффективно проверять друг друга. Итак, давайте спросим, чем отличаются результаты. Итак, я скажу: «Каковы были основные разногласия?» И мы спросим наш совет ИИ, какие разные мнения у них были по поводу этого конкретного массивного PR. Хорошо, он говорит: Opus обнаружил ошибку, в то время как Haiku заключил, что логика верна. Opus был более строгим. Gemini имеет архитектурную проблему, но является ли это реальной ошибкой, зависит от вещей. Бла-бла-бла. Haiku был самым снисходительным. Gemini был критичен. Opus был посередине. Так что это действительно имеет значение, что я часто вижу. Так что Gemini, как правило, немного более придирчив. Он укажет на множество проблем, даже на те, которые спорны, являются ли они действительно проблемами. Haiku — самый неумный из этих трех, а Opus просто фокусируется на вещах, которые действительно реальны. Так что это довольно хороший способ объединить способности разных агентов. Хорошо, это пример использования под-агентов. Хорошо, но дело не только в этих вещах, которые встроены в сами CLI и IDE. Люди начинают создавать свои собственные рабочие процессы поверх этого, которые становятся своего рода возможностями ИИ более высокого уровня. И вот где все становится действительно трудно отслеживать. Итак, за последние несколько недель мы видели такие вещи. Итак, Гас Таун, Стив Ягги — парень, который известен в индустрии программного обеспечения уже много лет, и он исследует этот способ создания этого, как бы, вымышленного города ИИ-агентов, где у вас есть мэр, и посыльные отправляют сообщения агентам, и, знаете ли, они все сотрудничают, чтобы работать вместе над вашими проектами. Это своего рода дико и экспериментально, но, знаете ли, люди интересуются такими вещами. И еще одна вещь, о которой вы, возможно, слышали, это было невероятно популярно около трех дней назад, около трех дней назад, это был Ральф Вигум. Я уверен, что многие из вас думают: «Что, черт возьми, происходит? Почему ты говоришь о Ральфе Вигуме в этом контексте?» Ну, Джеффри Хантли пришел к наблюдению, что ИИ-агенты, как правило, довольно ленивы, верно? Вы даете ему задачу, например, «сделай эти шесть вещей», и он сделает четыре из них и скажет: «Я сделал четыре из шести вещей. Я закончил». И вы говорите: «Что? Сделай остальные два». И он говорит: «Хорошо, конечно, я сделаю». А затем он говорит: «Остальные два довольно сложны. Оставим их как будущую задачу». И вы говорите: «Нет, я хочу, чтобы ты сделал их сейчас». И он говорит: «Ты прав. Я сделаю их». А затем он говорит: «Я добавил несколько комментариев to-do, чтобы сказать, что мы сделаем это в будущем». И это просто смешно и раздражает. Так что концепция Ральфа Вигана — это способ заставить агента просто никогда не сдаваться. Это буквально просто цикл while, который постоянно говорит: «Нет, продолжай работать. Нет, продолжай работать». И вы оставляете его работать на ночь, а затем, надеюсь, утром он проделал огромный объем работы. Люди говорят, что они сделали, например, большие проекты, вроде как перенесли целый веб-браузер на Rust или что-то в этом роде. Своего рода безумие. Но в любом случае, это то, что люди придумывают. Это действительно интересно, но также невозможно отслеживать, и вы никогда не знаете, о чем из этого действительно стоит узнать. И это создает это довольно трудное чувство давления на нас, разработчиков, как я собираюсь действительно оставаться в курсе всего этого? Знаете ли, если было достаточно трудно отслеживать все фреймворки JavaScript, это уже другой уровень. Так что, чтобы минимизировать эффект FOMO, давайте немного отступим и подумаем о некоторых основах и поймем, что действительно стоит делать среди всего этого. Извините, секунду. Джон, ты меня все еще слышишь? >> Я слышу. >> Ты слышишь? Хорошо. Хорошо. Извините. У меня на компьютере все стало странно. Хорошо. Давайте предположим, что все в порядке, и мы можем продолжать. Хорошо. Итак, давайте подумаем о некоторых основах, если вы хотите добиться успеха, работая с кодирующими агентами. Итак, вот некоторые вещи, которые, как мне кажется, мы наблюдали, действительно эффективны. Это своего рода сокровища среди множества различных инструментов и методов, и это, по сути, те же вещи, которые успешны, если вы хотите быть успешным как человек. Итак, в большинстве случаев, когда работа с ИИ-агентами терпит неудачу, это обычно потому, что задача, которую вы им дали, недостаточно специфицирована, а ИИ-агенты невероятно ленивы. Если есть какой-либо способ избежать работы и просто сделать ее плохо и дешево, они обычно это делают. Так что планирование — это процесс, через который проходят многие люди, чтобы гарантировать, что они действительно специфицировали то, что им нужно заранее, и он стал достаточно популярным, чтобы стать нативным инструментом во многих ИИ-инструментах CLI, и он есть в Copilot CLI. Так что я собираюсь показать вам пример этого прямо сейчас. Итак, здесь у меня есть другой проект .NET под названием Simple Commerce, и это самый классический мейнстримный бизнес-сценарий, который я только могу себе представить. Это классический сайт электронной коммерции. Так что это совершенно обычная электронная коммерция, за исключением того, что примерные цены совершенно возмутительны, и по какой-то причине он просто переключается между языками в середине. Кроме этого, это совершенно обычный веб-сайт электронной коммерции. Давайте скажем, я хочу добавить какую-то сложную функцию к этому. Вот как мы можем это сделать, используя функцию планирования, которая была выпущена пару недель назад. Итак, давайте перейдем в Copilot. Хорошо. Итак, вы увидите, что у нас теперь есть этот режим переключения Shift-Tab, который мы только что добавили. И если я нажму Shift-Tab, я переключусь в режим планирования. Хорошо. Итак, я теперь в режиме плана. И это означает, что когда я даю ему инструкцию, например, «добавить функцию настройки продукта», обычно он просто начинает писать код. Но поскольку я в режиме плана, он знает, что я просто хочу пройти процесс проектирования этого. Так что он начнет думать об этом. Он выяснит, что может означать это. Он проводит исследование кодовой базы и решил задать мне вопрос. Какой тип настройки продукта вы имеете в виду? У нас есть различные варианты. Я могу ввести свой собственный ответ, если хочу, но я выберу «создай свой собственный продукт». Так что он думает немного больше. И это, хорошо, он задает мне еще один вопрос. Каков сценарий использования? Давайте выберем «сборщик ПК на заказ». И что он делает теперь? Он будет думать немного больше. Следует ли нам обеспечить совместимость? Как насчет «больше никаких вопросов, пожалуйста»? Хорошо. Итак, он теперь начнет работать над планом. И он сделает это в виде markdown-документа, который мы сможем читать и редактировать. И это также будет способом отслеживания прогресса по мере его прохождения. Так что он создает этот план для нас. Он продумывает, как именно это сделать. Хорошо. Итак, он создал план, и он записывает детали для нас. И вы заметите, что у нас есть этот Control Y для просмотра/редактирования плана. Я сделал что-то странное. Хорошо. Итак, мы сделаем Control Y. И это открыло экземпляр кода здесь. Хорошо. Итак, мы можем увидеть план, который он написал. Это функция «создай свой собственный продукт». У него есть вся эта информация. У него есть этапы работы. У него есть пример влияния на файлы, схему базы данных и так далее. И если бы мы действительно работали над функцией такого размера, мы, вероятно, хотели бы потратить около часа на итерацию этого дизайна с агентом, чтобы довести его до чего-то, что, как мы уверены, даст желаемый результат. Одна вещь, которую я часто хочу сделать, это сказать ему, что я хочу знать, как проверять работу по мере ее выполнения, потому что иначе он просто вносит кучу изменений в код, и я не знаю, правильно ли это или нет. Так что я вернусь сюда. >> Пока вы это делаете, я просто хочу сказать, что это был такой совет, который я узнал от людей, и я рад, что он стал частью стандартного рабочего процесса, это план, просмотрите план. И это действительно то время, когда я больше всего вовлечен, действительно, это убедиться, что план — это то, что я хочу, верно? Потому что я вижу, как люди жалуются, что, эй, я сказал ИИ построить веб-сайт, и он построил его неправильно. Это как, ну, если ты просто говоришь «построй веб-сайт», ты не, что я имею в виду? Но если ты действительно дашь это, если ты потратишь время на план и подумаешь об этом, тогда ты работаешь на уровне выше. Так что я просто хочу, если люди как бы не понимают, насколько это важно. Я думаю, это действительно важный шаг, который вы показываете. >> 100% согласен. Хорошо. Итак, так вот одна вещь, которую я часто делаю: я говорю ему, что хочу знать, как проверять работу. Так что вы можете видеть, что он начал добавлять все эти записи о проверке в разных точках. Теперь некоторые из них я, вероятно, вернусь к нему и скажу: «Нет, я хочу иметь возможность проверять каждую вещь в пользовательском интерфейсе, как-то организуй свою работу так, чтобы я всегда мог видеть что-то, что пользователь мог бы видеть». В любом случае, как только вы доработаете это, вы скажете ему начать работать, и он будет обновлять план по мере его выполнения. Он будет отмечать вещи как сделанные, когда они будут сделаны, и это позволит вам действительно сохранять контекст в течение длительного блока работы. Так что, чтобы показать это, и это будет немного поддельно, но я скажу ему, для тестирования отметьте всю фазу один как выполненную. Так что он подумает об этом секунду, а затем, надеюсь, фаза один будет отмечена как выполненная, просто чтобы показать вам, что он может это сделать. Это как бы очевидно. Вот так. Итак, он отметил их все как выполненные, и он делал бы это, пока работал. Хорошо. Итак, это пример планирования, и мы вернемся к этому приложению чуть позже. Эм, так, давайте поговорим о некоторых других фундаментальных способностях. И мы перейдем к навыкам и обратной связи. Итак, чего вы не хотите тратить свое время на эти системы, так это на изобретение всего с нуля каждый раз, когда вы говорите ему, что делать. Вы хотите, чтобы он знал, как быть эффективным в контексте вашего приложения и с технологиями, которые вы уже используете, с готовыми возможностями, скриптами и помощниками и тому подобным. И это то, что могут позволить вам сделать навыки. Позвольте мне привести пример навыков. Это еще одна относительно новая функция, которая была выпущена за последние пару недель. Итак, я перейду сюда и начну с этого. Итак, я покажу вам, как установить навыки в первую очередь. Если я перечислю доступные навыки, вы увидите, что у меня есть только один навык прямо сейчас. Это из демо, к которому мы скоро перейдем. Так что пока просто проигнорируйте это. Представьте, что его нет. И я собираюсь установить некоторые готовые навыки, которые кто-то другой предоставил. Итак, я перейду в магазин плагинов и перечислю, какие магазины у меня есть. Магазины — это, по сути, просто репозитории git. Так что этот предоставлен Anthropics. И если я перейду в этот репозиторий, вы увидите, что они туда поместили. Так что Anthropic предоставил нам этот хороший набор образцов навыков. И мы можем зайти туда и увидеть их все. И мы можем увидеть, как все они реализованы. Я покажу вам немного, как они реализованы через минуту, но что такое навык, это набор файлов, который предоставляет контекст для агента. Так что это файл под названием skill.md, который содержит информацию о том, как что-то делать. И здесь есть немного заголовочного текста, это описание. И это важная и интересная часть. Модели ИИ имеют ограниченный объем контекста. Так что вместо того, чтобы помещать всю информацию о навыке в контекст, он помещает только эту заголовочную часть для каждого из навыков. И этого достаточно, чтобы агент обнаружил навыки и решил, когда его использовать. И когда он это делает, он может найти полные детали. Так что у вас может быть десятки, сотни или тысячи навыков, и это не переполнит контекстное окно. Он будет искать отдельные части информации по мере необходимости. >> Теперь мое понимание этого немного, я раньше помещал тонны информации в инструкции Copilot, и я включал фрагменты кода. Я включал всю эту информацию. Но тогда проблема в том, что это часть контекста. Это возвращается и уходит с каждым запросом. Хорошо, с этим вы просто говорите: «Вот как сгенерировать PDF, если он вам понадобится позже. Идите, прочитайте остальное», и тогда он сможет просто поместить эти метаданные в контекст. >> Точно. И это не просто контекст markdown. Это могут быть фактические помощники, такие как скрипты и тому подобное, которые он может вызывать. Я покажу вам это через секунду. Итак, давайте зарегистрируем навыки из этого магазина. Итак, я собираюсь установить что-то под названием «документные навыки». И как только я это сделаю, если я вернусь к списку навыков, вы увидите, что теперь у меня есть все эти вещи, которые вы только что видели в моем веб-браузере. И эти [смех] сохраняются между сессиями. Так что, если я создам новую сессию, а затем посмотрю на свои навыки, вы увидите, что у меня все еще есть все это здесь. Так что давайте попробуем использовать это. Я скажу: «Используй навык создателя GIF для Slack, чтобы сделать мне GIF об установке Copilot CLI». Хорошо. Итак, он подумает, и он будет использовать этот навык отсюда, создатель GIF для Slack, и это содержит утилиты, такие как эти скрипты Python, которые он может использовать для создания, и вы видите, что он читает их, так что он знает, как их использовать. Он теперь убеждается, что установил все необходимые зависимости, а затем сможет использовать это, чтобы создать мне GIF, надеюсь. Хорошо, он создал небольшой скрипт, который он теперь вызывает, и он проверяет вывод. Давайте просто выйдем из этого. Да. Хорошо. Итак, давайте посмотрим, что он только что создал. Хорошо. Итак, мы проверяем наши временные метки. Так что это было создано буквально только что, Copilot CLI.GIF. И если мы хотим просмотреть это, давайте откроем это в нашем браузере. И ничего. О, это файл нулевого байта. О нет, что-то пошло не так. Хорошо. Я не знаю, что там произошло. Хорошо. >> Если [смех] если навык работал правильно, он бы создал для нас файл, который бы работал. Вы можете видеть, что он пытался, но там явно что-то не так. >> Может быть, это был GIF отслеживания, где он один пиксель на один пиксель. [смех] >> Ну, он нулевой килобайт, так что я думаю, там ничего нет. Хорошо. В любом случае, вы поняли, как установить и использовать навык. Но более интересная часть — это создание собственных навыков. Так что давайте скажем, что мы хотим создать навык прямо сейчас. Так что давайте вернемся сюда и посмотрим, как это сделать. Итак, сначала у меня есть все эти навыки из предыдущего, но теперь я хочу использовать навык под названием «создатель навыков», чтобы создать навык. И я скажу ему, куда его поместить. Он должен спросить пользователя, какой проект. Мы сделаем .NET SPET Core или GitHub Copilot Copilot CLI, нет, Copilot SDK, и мы получим статус сборки для этого. Хорошо, так что это обнаружит, что у него есть навык создателя навыков. Надеюсь, так оно и есть. И он прочитает детали создания навыков, а затем начнет работу над этим. Надеюсь. Хорошо. Итак, он инициализирует навык. Теперь давайте посмотрим на код, который он производит, когда делает это. Так что он только что создал этот навык. О, это пустой файл. Ой. Снова что-то не так. Что происходит? Файл пуст. Да. О, хорошо, ладно. Он сделал это сейчас. Хорошо. Итак, он заполнил этот навык, и вы можете видеть, что у него есть это описание, и он делает то, о чем я говорил, как должны работать вещи. И мы можем прочитать это и отредактировать сами, если хотим изменить, как это работает. Например, скажем, я хочу, чтобы он получал статус сборки только из основной ветки. Я могу отредактировать его сам, или я могу просто вернуться и сказать: «На самом деле, получай статус только из основной ветки», и он редактирует его. Он закончил редактирование? О, он сделал это сейчас. Хорошо. Итак, вы можете видеть, что он только что добавил эту вещь здесь. Рабочий процесс запускает фильтр ветки main. Хорошо. Итак, теперь у нас есть наш навык. Хорошо. Итак, давайте выйдем отсюда и, наконец, мы можем попробовать использовать его. Итак, давайте посмотрим, если мы проверим, какие у нас есть навыки. Вы видите, что теперь у нас есть наш навык «статус сборки», и он хранится в системе контроля версий в нашем проекте в данном случае. Так что мы можем поделиться им с другими людьми в команде, и он также доступен как команда слэш. Так что вы можете получить к нему доступ очень быстро с автодополнением. Так что я спрашиваю «статус сборки», и он подумает, он поймет, что есть навык, который ему нужно загрузить в контекст, и он выбирает, чтобы спросить пользователя, как я и сказал: «Для какого проекта вы хотите его?» Давайте сделаем это для Copilot SDK, и теперь он будет следовать инструкциям, которые содержатся в этом навыке. О, он снова обрабатывает большие объемы данных. И >> так явно вызывая это, извините, что прерываю. >> Отлично, что вы можете явно вызвать его. Я заметил, что у MCP есть инструменты, но вы никогда по-настоящему, я имею в виду, вы никогда напрямую не вызываете инструмент. Вы можете намекнуть, но здесь вы действительно можете с помощью команды слэш сказать «вызвать этот навык». >> Да. В некоторых случаях некоторые вещи, поддерживающие MCP, позволяют вызывать их напрямую. VS Code имеет эквивалент команды слэш для MCP. Но да, я бы сказал, что это очень полезно в любом случае, будь то навык или MCP или что-то еще. Если вы знаете, что вы хотите, чтобы он сделал, то почему
Зачем набирать это, когда можно просто получить автодополнение по слэшу. >> Да. >> Это упрощает вам работу. >> Итак, просто к вашему сведению, у нас есть несколько хороших комментариев или вопросов, которые я хочу взять, но я не хочу прерывать то, где вы находитесь в потоке. Так что, если сейчас удобно, я возьму их, или позже тоже нормально. Хорошо, давайте просто закончим это, э, это дело о навыках, а затем перейдем к вопросам. Хорошо, мы рассматривали навыки композиции и специализированные инструменты, но другая часть этого — это цикл обратной связи. Итак, еще одна основная антипаттерн, в который попадают кодирующие агенты, это то, что вы говорите им сделать что-то, и они говорят: «Я сделал это». И вы пробуете, и это не работает, и вы говорите, что это не работает, и они говорят: «О, извините. Я исправлю это. Я исправил это сейчас». И вы пробуете, и это все еще не работает, и они говорят: «О, извините. Я исправлю это». И вы пробуете, и это все еще не работает. И это невероятно раздражает. Это похоже на то, как чувствуют себя другие люди, если они просят вас исправить ошибку в программном обеспечении, но они не очень хорошо ее описывают, и вы вносите какие-то изменения, а затем ошибка все еще присутствует. Они подумают, что вы не очень умны, потому что не исправили ошибку должным образом, но на самом деле это их вина за недостаточное описание или за то, что они не могут, вы знаете, показать вам, в чем на самом деле заключалась ошибка. Та же проблема возникает и с кодирующими агентами. Если они не могут фактически запустить ваше приложение, им очень трудно понять, правильно ли изменение, которое они внесли. Итак, все, что вы можете сделать, чтобы дать ему обратную связь, позволит ему быть более успешным. Позвольте ему вызывать компилятор, линтеры, тесты, что угодно. Но даже больше, чем это, возможность фактически запустить ваше приложение. Это то, чего мы также можем достичь с помощью навыков. Итак, я собираюсь попробовать сделать это для э, снова для этого простого коммерческого приложения. Э, я уже создал здесь навык под названием «Простая автоматизация коммерции», который учит его, как автоматизировать браузер с помощью Playwright и все о том, как работать с этим конкретным веб-приложением. Ну, очевидно, я не писал это сам. Я получил это из мастера создания навыков. Э, мне потребовалось около получаса или около того, чтобы итерировать, пока у него не появились возможности. Он знает, как войти в систему как администратор. Он знает, как настроить сайт. Он знает, как, э, вы знаете, заполнять вещи. Он знает, как запустить браузер в первую очередь. Он знает, как обнаружить, какие ссылки есть на странице, и тому подобное. Итак, используя этот навык, я могу сделать что-то вроде следующего. Хорошо. Итак, давайте сначала проверим, загружен ли наш навык, и он загружен. Вы можете видеть это там. Итак, в таком случае я могу запустить его, и давайте просто скажем «запустить браузер». Итак, он подумает, он загрузит навык в контекст, и, надеюсь, он должен знать, как запустить браузер сейчас. Итак, он запускает один из скриптов, которые там есть, и вы видите, что браузер появляется для нас. Хорошо, круто. Теперь этот браузер — это то, что он может автоматизировать. Так что я мог бы вернуться к нему и дать ему какую-то инструкцию, например, э, я хотел бы, чтобы вы зарегистрировали нового пользователя Стива. Хорошо. Итак, он думает, как это сделать. Он проверяет свои инструкции в навыке там, а затем, надеюсь, он сможет загрузить эту возможность. И вот он использует автоматизацию. Вот оно. Он сделал это. Это было немного быстро, но вы можете видеть, что там написано «Привет, Стив». Он успешно зарегистрировал пользователя. Теперь смысл этого не в том, чтобы вы давали ему инструкции вручную. Смысл в том, что если бы вы заставляли его работать над функцией, он мог бы сам решить открыть браузер и буквально попробовать его сам. И если это не сработает, он сможет увидеть, в чем была проблема, и вернуться и исправить это. Итак, например, если бы мы работали над чем-то, связанным с управлением заказами, мы могли бы сказать, э, как администратор, создать новый продукт. Э, скажем, супернаушники. затем разместить пять заказов на него от имени Стива. На самом деле, пять отдельных заказов. Хорошо. Итак, он подумает об этом. Это довольно сложный процесс для него. Э, но, надеюсь, используя этот навык, он сможет сделать все это. Итак, он сгенерировал скрипт. Что он делает сейчас? Он вошел в систему как администратор. Он собирается создать для нас продукт? О, да, он быстро создал продукт «Супернаушники». Теперь он вошел в систему как Стив и размещает серию заказов на него, и он может наблюдать за происходящим. Вы знаете, он может использовать протокол Chrome DevTools для чтения содержимого браузера. Э, если по какой-то причине размещение заказа не удастся, например, возникла ошибка проверки, что угодно, он сможет это увидеть. Он сможет вернуться к своему коду и начать исправлять то, что он делал. Итак, это имеет смысл? Эта идея подключения цикла обратной связи. >> Да, это очень круто. Мне очень нравится вся эта идея, вы показываете, как устранить повторяющийся характер, например, указать работу, протестировать ее вручную, все это, чтобы иметь возможность просто сказать: «Иди, автоматизируй все это». Так что это здорово. >> Отлично. >> Вау. >> Хорошо. Э, вы хотели задать какие-нибудь вопросы? >> Да. Хорошо. У нас здесь куча. Позвольте мне посмотреть. Хорошо. Э, я пройдусь по некоторым быстрым. Э, так построен ли CLI с помощью Spectre Console? >> Нет, CLI реализован как приложение Node с React Inc. >> Хорошо. Э, можем ли мы получить неограниченные запросы? >> Если у вас есть неограниченные деньги? Да. [смех] >> Хорошо, отлично. Э, позвольте мне посмотреть. Э, так это возвращается к тому, о чем мы говорили, э, автоматизация GitHub, GitHub CLI и т. д. Э, и просто упоминание здесь, например, э, Azure DevOps. Одна вещь, которую я использовал для этого, есть сервер Azure DevOps MCP, который был очень полезен. Так что просто делюсь. >> Круто. >> Э, посмотрите, э, как вы побуждаете его создать план для проверки, не заставляя его погружаться и начинать вносить изменения уже? Так что, по сути, что такое режим плана? >> Извините, продолжайте. >> О, извините, да, я говорил поверх вас. Э, да, это именно то, что такое режим плана. Режим плана — это режим, в котором, когда вы находитесь в нем, агент инструктирован не погружаться и не начинать реализовывать вещи, а только работать с вами над документом плана. Затем вы выходите из этого режима, когда хотите, чтобы он начал вносить другие изменения в код. >> Отлично. Хорошо. Э, устраняет ли режим плана необходимость в таких инструментах, как SpecKit? >> Режим плана в некотором смысле является очень легким эквивалентом SpecKit. Если вы используете SpecKit и вам нравится этот рабочий процесс, и вы считаете, что он вам подходит, нет причин прекращать его использовать. Но я думаю, что большинство людей в моей команде, по крайней мере, считают, что они хорошо работают, используя режим плана. Так что это зависит от вас. >> Хорошо. Отличный комментарий от Винтерфреда, который просто любит хранить планы внутри репозитория. Так что вы говорите ему создавать их в определенной папке. Приятно иметь это как артефакт. >> Да, это еще один хороший рабочий процесс. Многие люди так делают. Мы не делаем этого по умолчанию, потому что часто эти документы плана довольно эфемерны. Это просто: я хочу понять, как заставить тебя успешно выполнить работу в течение получаса. Это не значит, что это долгосрочная документация для проекта, но в некоторых случаях это может быть так, или это может быть так, что вы проходите через кучу планирования, используя эфемерный документ, а затем в конце вы говорите ему что-то вроде «добавить документацию для разработчиков на основе этого», а затем, знаете ли, он посмотрит на это и выяснит, какую долгосрочную информацию вы хотите хранить в системе контроля версий, и фактически запишет это в виде хорошего документа. Вы можете делать это так, как хотите. >> Мне это нравится. Это то, во что я как бы эволюционировал, именно это: я явно говорю: «Не создавай временные документы в формате Markdown», а затем в конце рабочего цикла говорю: «Обнови официальный документ о том, как мы это делаем» или >> круто >> э, используете ли вы Claude Opus 45 по какой-то конкретной причине? Это немного дорого для профессионального плана. >> э, Opus дает удивительно хорошие результаты. Я бы сказал, что если вы можете его использовать, это здорово. Sonnet тоже очень хорош. Я использую его, потому что это роскошь, к которой у нас есть доступ в нашей команде. Но я думаю, что ничто не помешает нам быть очень продуктивными с Sonnet. >> Итак, я знаю некоторые инструменты. Я не знаю, есть ли у CLI это, но есть своего рода автоматический режим, где он выполняет автоматический выбор. Есть ли у CLI это? >> Под этим вы подразумеваете, никогда не задавать мне никаких вопросов? Никогда не запрашивать, просто >> Нет, извините. Э, выбор модели. >> О, понял. Да. Э, ну, в некотором смысле мы это делаем, потому что мы выбираем модель по умолчанию для вас каждый раз, когда вы начинаете сеанс. >> но я не думаю, что есть явно модель под названием авто. Нет, ее нет. >> Но да, если есть причина, пожалуйста, отправьте нам запрос на функцию. >> Это то, что я заметил в, э, например, в SWE на GitHub. >> Да. или просто в целом: просто используйте автоматическую модель, а затем она будет повышаться только до Opus, когда ей понадобится это, вы знаете, продвинутое мышление. >> Э, вы всегда вызываете навыки явно? Я думаю, вы показали, что нет, но я просто хочу >> Да, вам не нужно вызывать их явно. Предполагается, что он сам принимает решения о том, когда их запускать. Но если я делаю демонстрацию навыка, я могу просто, или если я буквально знаю, что это будет конкретный навык, и я знаю, что для него есть команда слэш, то для меня это меньше нажатий клавиш, чем не >> или он случайно угадает неправильно и, знаете ли, выберет неправильный навык, и тому подобное. >> Э, позволяют ли команды слэш ссылаться на запросы? Я использую SpecKit и не могу видеть запросы так же, как я могу ссылаться на навыки. Я не думаю, что в Copilot CLI у нас есть концепция предопределенных запросов такого рода. Если это что-то, что вы находите полезным, снова отправьте нам запрос на функцию, и, знаете ли, мы можем очень быстро выпускать такие функции. >> Вот своего рода большой вопрос. Я думаю, вы говорили об этом в целом, но просто чтобы высказаться: в чем разница между навыками и MCP? >> Да, так MCP — это, по сути, протокол для связи с некоторым внешним процессом. В то время как навыки — это просто набор контекста. Хорошо, >> они просто разные технически. Например, MCP полезен, если вы, э, если у вас есть какая-то внешняя служба, с которой вы должны взаимодействовать, в то время как навыки полезны, если то, что вы пытаетесь заставить его сделать, может быть сведено к набору информации и скриптов Python и так далее. >> Хорошо. >> Позвольте мне посмотреть. Будет ли агент неявно вызывать навыки, если он считает, что это будет полезно? Я думаю, вы в основном покрыли это, но просто >> Да. >> Э, хорошо. А затем это просто своего рода общая идея. Сэрли Дев, давний зритель, говорит, что из-за политики программного обеспечения они использовали C-Pilot для создания пары утилит. Они говорят о том, чтобы, по сути, обернуть такие вещи, как SP who, а затем в следующем комментарии они сказали, что будут использовать, э, вы знаете, создать навык для этого с помощью Copilot Copilot CLI. >> Круто. >> Думаю, это все, что касается >> Позвольте мне посмотреть, хорошо. >> Хорошо, я знаю, что мы приближаемся к часу, и у меня все еще есть еще одна классная вещь, которую я хочу показать, так что немного вперед. Но я собираюсь потратить меньше времени на обсуждение, э, знаете ли, концептуальных вещей, и больше на, э, давайте поговорим об одной другой очень интересной технологии, которая выходит в данный момент. Итак, э, Copilot CLI или C-Pilot в веб-кодирующем агенте, что бы вы ни хотели, или другие кодирующие агенты, знаете ли, они все очень полезны, они дают вам очень полезные возможности в качестве разработчика, когда дело доходит до написания кода. Так что это здорово для вас, но это также то, что вы можете использовать, чтобы привнести дополнительные возможности в продукты, которые вы предлагаете своим клиентам. И чтобы обеспечить это, мы совсем недавно выпустили Copilot Coding Agent SDK. И это позволяет вам использовать нашего агента и все его запросы, инструменты и навыки и так далее в вашем приложении для выполнения всего этого. Итак, позвольте мне привести пример того, как это сделать. Итак, давайте вернемся к этому вопросу об управлении нашими собственными рабочими процессами. Допустим, я хочу создать небольшой инструмент под названием «Issue Sizer», и он будет чем-то, что оценивает сложность реализации конкретных проблем, которые были поданы против моего репозитория. И я собираюсь сделать это с помощью GitHub Copilot SDK. Итак, я установил текущую предварительную версию этого, а затем я смогу использовать ее из моего кода .NET. Теперь, из этого слайда, вы можете видеть, что у нас есть SDK в настоящее время для Node, Python, Net и Go. Это официальные SDK. Также есть SDK, предоставленные сообществом для Java, Rust и C++. Я уверен, что этот список будет расти со временем. Теперь, очевидно, я собираюсь использовать .NET прямо сейчас. И сделать это довольно просто. Я могу начать с создания экземпляра клиента Copilot здесь. И это будет использовать любую установленную на моей машине копию Copilot. У нас пока нет способа ее упаковать, но мы рассматриваем возможность сделать это. А затем я создам сеанс против этого, и затем я смогу использовать его для выполнения таких вещей, как «перечислить файлы в этом каталоге». Мне не нужно говорить ему, как это сделать, потому что это кодирующий агент. У него есть все инструменты, которые есть у кодирующего агента. Очевидно, он знает, как находить файлы на диске. Итак, если я запущу это сейчас, то, надеюсь, мы увидим, что это даст полезный результат. Если появится окно терминала, вот оно. Хорошо. Теперь это может занять некоторое время в первый раз, когда ему придется работать. Это всегда так в первый раз, когда я запускаю его. Это будет проходить через все потоки, которые кодирующий агент будет выполнять, чтобы просмотреть файлы на диске и решить, как вам ответить. И мы получим немного больше информации о том, как это работает через минуту, как только он закончит отвечать. Вот оно. Итак, вы видите, что это работало в контексте каталога вывода сборки. И поэтому он сообщает нам обо всех DLL и тому подобном, что ему удалось найти там. Хорошо. Но это заняло время, и мы не получили явной обратной связи на экране. Так что, чтобы получить немного больше информации, мы можем подписаться на события. Итак, у нас есть session.on, а затем мы будем получать события обратно. И есть около 20 различных типов событий. Все они имеют приятные сильно типизированные классы .NET для их представления. Пока что я буду смотреть только на выполнение инструментов и на все остальное. И я просто буду записывать все это в консоль, когда это произойдет. Так что, если я запущу это снова сейчас, то вместо того, чтобы показывать нам никакой выход во время работы, мы начнем видеть этот поток событий, которые происходят. Мы можем видеть, что он сообщает о своем намерении перечислить содержимое каталога. Он использует инструмент для просмотра файлов на диске, а затем в конечном итоге возвращает нам свой ответ. Хорошо, круто. Итак, это основы. Итак, вы можете использовать это, если хотите автоматизировать CLI, например, вы можете отправлять сообщения, получать сообщения обратно и автоматизировать вещи. Но вы также можете интегрировать свои собственные возможности еще лучшим способом, просто предоставляя функции, которые он может вызывать. Итак, здесь я собираюсь использовать обычную функцию C# для создания этой функции под названием get issue size label, которая будет принимать количество дней работы, а затем использовать этот совершенно возмутительный синтаксис. Что это вообще такое? Чтобы возвращать разные строки в зависимости от этого значения, и я могу подключить это к моему сеансу здесь. Итак, здесь я собираюсь сказать, я собираюсь использовать Microsoft Extensions AI Helpers здесь, чтобы преобразовать этот метод .NET в функцию ИИ, которую наш агент Copilot сможет вызывать. Итак, чтобы доказать, что он действительно это делает, давайте поставим точку останова там. И нам лучше изменить наш запрос, чтобы он использовал это. Какова метка для проблемы, которая занимает шесть дней? Я запущу это с отладчиком. И, надеюсь, он запустится. Он запустит сеанс. и он начнет думать, как удовлетворить запрос пользователя, и, предположительно, решит вызвать этот метод .NET. Вот оно. Он сделал это и передал шесть дней работы. Мы вернем размер m из этого, и он скажет, что проблема имеет размер m. Хорошо. Круто. Итак, это все хорошо. Но более важным здесь является то, что мы теперь можем объединить это со всеми другими возможностями, которые встроены в кодирующий агент по умолчанию. Например, я мог бы реализовать целую вещь, которая будет производить оценки того, сколько времени требуется для реализации вещей. Итак, теперь я дал ему этот запрос, говоря: «Ты инженер-программист. Проверь, соответствует ли проблема исходному коду в этом каталоге. Исследуй существующий код и предоставь точную оценку размера. Ответь в этом конкретном формате». Хорошо. Итак, давайте запустим это. Посмотрим, сработает ли. Мне понадобится проблема, чтобы оценить ее размер. Так что давайте найдем что-нибудь. Это не то. Где мой другой браузер? Вот он. Хорошо. Итак, я собираюсь перейти в Copilot SDK, который является открытым исходным кодом, и давайте найдем какую-нибудь проблему, которую мы можем оценить. Давайте подключимся к активному сеансу CLI. Это будет сложно. Так что я вставлю это. Вставить. Вот оно. Хорошо. И вы видите, что он начнет использовать весь свой агентский интеллект, чтобы решить, как получить информацию об этом. Он выполнит веб-запрос. Он будет сравнивать это с исходным кодом на диске, который даже не соответствует этому репозиторию. Так что он довольно быстро откажется от этого. И затем, в конечном итоге, надеюсь, он вызовет наш инструмент, чтобы получить метку размера, и он предоставит нам хороший ответ. Хорошо. Итак, он придумал размер «большой», реализация интерактивного инструмента diff — это «большой» и так далее. Да, это, вероятно, правда. Хорошо. Круто. Хорошо. Итак, общий смысл этого в том, что это более высокий уровень взаимодействия с ИИ, чем просто использование чего-то вроде обычного конечного узла чата. Вы можете использовать весь агентский цикл, который поставляется с Copilot, тот же, который используется в CLI и в Интернете, и все встроенные запросы, которые мы тщательно оптимизировали и тестировали в течение месяцев. И привнести такой интеллект в ваш проект. Круто. Этого достаточно. Э, да. Есть еще вопросы или что-то, что вы хотите поднять, Джон? >> Да, было несколько. Э, позвольте мне посмотреть. Там тонны вопросов. Я на самом деле пытаюсь выбрать лучшие. >> Есть ли инструмент, который может оценить планы? Это было связано, я думаю, с, знаете ли, с разными моделями и тому подобным. >> Оценить планы использования Copilot. Это так? >> Я думаю, да. Я не думаю, что у нас есть что-то подобное, но это было бы очень интересно сделать. С другой стороны, как бы вы это запустили, если бы у вас уже не было Copilot? Может быть, нам стоит разместить это где-нибудь в Интернете. Да, это интересная идея. Я не думаю, что у нас есть это. В идеале наша документация должна быть достаточно ясной, чтобы вам даже не нужен был ИИ, чтобы сказать вам, какой будет цена. Если это не так, пожалуйста, пожалуйтесь нам, и тогда мы начнем подталкивать людей к чему-то. Это звучит интересно, как взять метаданные о, э, разных вещах и сказать: «Вот мой документ плана для этой вещи, дайте мне некоторые оценки и помогите мне, знаете ли, сделать это», это звучит как навык или что-то вроде того. >> Да. >> Э, хорошо, это вопрос от Даниэля, который любит Copilot и SDK, интересуется фреймворком агентов. >> Да. >> Э, в чем ценностное предложение между разными вещами? >> Да. Итак, у нас есть своего рода стек более и менее низкоуровневых вещей, я полагаю, в .NET конкретно. Итак, самая низкоуровневая вещь в .NET для этих вещей — это библиотеки Microsoft Extensions AI, которые дают вам прямой доступ к конечным точкам завершения чата, что является довольно тонким слоем поверх самих языковых моделей. И у них нет мнений о том, какие задачи выполнять, какие инструменты должны быть доступны, какие запросы должны быть доступны, какие рабочие процессы они должны следовать или что-либо еще. У них нет мнений ни о чем. И если это то, что вы хотите, если вы хотите предоставить всю эту логику самостоятельно, то прямое обращение к уровню завершения чата — это то, что вам нужно. Более высокий уровень над этим — это фреймворк агентов, который определяет это понятие агентов, которые являются состоятельными, с которыми вы можете вести постоянный разговор, и которые потенциально знают, как взаимодействовать друг с другом для распределения работы между собой, но он по-прежнему не имеет мнения о том, какую работу они выполняют. И более высокий уровень над этим был бы, ну, это не над ним, это фактически реализовано отдельно, но более высокий уровень — это Copilot SDK, который является не просто агентом, а конкретно кодирующим агентом, который мы оптимизировали для решения реальных крупномасштабных сложных профессиональных задач по программному обеспечению, и у него есть все инструменты, необходимые для поиска файлов на диске, поиска информации на GitHub, знаете ли, возможности отслеживать, какие разрешения вы ему дали, возможность запускать серверы MCP и взаимодействовать с навыками, и, знаете ли, все то, что делает Copilot CLI, но ориентировано на сценарии кодирования. Вы можете фактически удалить все, связанное с кодированием, если хотите, когда создаете один из этих сеансов с этим материалом. В дополнение к передаче инструментов в него, вы также можете сказать «исключить инструменты», а затем вы можете удалить вещи, связанные с кодирующим агентом, если хотите. Вы также можете передать системное сообщение, и я задаюсь вопросом, помню ли я content=, и тогда мы могли бы сказать: mode=modereplace. Да. Итак, режим по умолчанию для системных сообщений — добавление. Так что это будет добавление дополнительного содержимого системного сообщения ко всему, что является значением по умолчанию для Copilot CLI. Но если вы измените его на замену, то он полностью отбросит все встроенные запросы, и, знаете ли, теперь ваши инструкции будут единственными инструкциями, которые он будет использовать. Так что на самом деле зависит от вас, хотите ли вы использовать эти вещи или нет. Было бы ли на простом уровне нормально сказать, что наиболее естественным для Copilot является роль агента больше в роли разработчика, в то время как Agent Framework я бы использовал его больше для интеграции в мое приложение. В то время как вы можете перемещаться, вы можете делать что угодно с чем угодно. Кажется, более естественное соответствие >> возможно. Теперь это зависит от того, сколько вещей вы хотите проработать самостоятельно. Создание какого-либо агента с нуля — это легко. Вы можете сделать это, вероятно, за 10 минут. Но будет ли он вести себя хорошо? В чем разница между тем, что ведет себя хорошо, и тем, что нет? Ну, это как мировой класс экспертизы в области инженерии запросов и месяцы очень дорогостоящего тестирования. И это то, что вошло во все, что мы выпускаем в Copilot SDK. Так что, если вы хотите сделать это самостоятельно, вперед. Но если вы хотите построить на этом невероятно хорошо зарекомендовавшем себя, проверенном в боях агенте, который знает, как принимать хорошие решения о том, сколько работы делать, и как выбирать между различными инструментами и тому подобным, тогда Copilot SDK — отличная отправная точка для этого. И это не так, хотя по умолчанию он ориентирован на задачи разработки программного обеспечения, это не большой шаг, чтобы дать ему инструкции делать другие вещи. Например, если вы хотите сделать что-то, что будет обрабатывать все ваши электронные письма и решать, какие важные задачи выполнять, или что-то в этом роде, кодирующий агент будет делать это очень хорошо практически сразу. Я не знаю о других людях в этом звонке, но я знаю, что я и все остальные люди в моей команде используем Copilot CLI для выполнения многих вещей, не связанных с кодированием. Например, если мне нужно что-то сделать на моем компьютере, что требует более нескольких кликов, я просто скажу C-Pilot CLI сделать это. Если мне нужно написать документацию, я скажу Copilot CLI сделать это. Если мне нужно, знаете ли, обработать много файлов любого рода по любой причине, опять же, я буду использовать CLI. Так что да, это очень гибкий инструмент. Еще один связанный вопрос здесь, и просто Уилфред говорит, что если вы интегрируете функции ИИ в продукты, и я думаю, что я думаю, если я выпускаю программное обеспечение или размещаю программное обеспечение на сервере, я бы скорее думал об этом как о фреймворке агентов, а не о Copilot CLI или SDK для запуска на моей машине локально для выполнения задачи для меня. >> Да, это может быть. Да. Так что, конечно, в настоящее время с Copilot SDK мы оптимизировали эту вещь вокруг вещей, которые просто работают для вас с вашими учетными данными на вашей машине. Это определенно не ориентировано на работу на сервере с, знаете ли, общими учетными данными и, знаете ли, сеансами, охватывающими нескольких пользователей и тому подобное. Я думаю, мы дойдем до этого момента, и, вероятно, очень скоро, но сейчас мы не в этом положении. Так что, конечно, в настоящее время вам лучше использовать фреймворк агентов для этого. Но я бы предположил, что эти вещи просто будут развиваться вместе, и, возможно, они в конечном итоге будут решать похожие проблемы в определенных случаях, и это нормально. Люди просто выберут то, что хорошо подходит для того, что они делают, и если вы используете наши вещи, мы не пытаемся подтолкнуть вас к одному или другому, как бы то ни было для вас хорошо. >> Хорошо. >> Последний вопрос, и в том же духе, в целом, потому что мы разговариваем с аудиторией разработчиков, которая, я думаю, более привычна к Visual Studio или VS Code. >> Да. >> Мне нравится это от Александра. В чем разница между CLI и Copilot в VS или VS Code? Итак, я хочу немного переформулировать это как вопрос к вам, вы говорите с разработчиками, которые, вероятно, имеют опыт использования Copilot в VS или VS Code. И вы показали тонну убедительных вещей, но как бы подвести итог: эй, попробуйте это, попробуйте. Как бы вы это подвели? >> Да, это то, что я бы сказал. Так что я бы сказал, что мой призыв к действию для всех из этого — просто попробовать, и особенно попробовать сделать что-то, чего вы обычно не делаете, потому что тогда вы получите представление об этом, как, о боже, я только что сделал это. Например, пример для меня на прошлой неделе был, я использовал это программное обеспечение для записи экрана, и у него была ошибка, из-за которой оно просто вылетало, когда я делал определенную вещь, что было довольно раздражающе. Я нашел его репозиторий Git, и я собирался подать проблему, потому что я не собирался делать с этим ничего сам. Он был написан на Rust, и я даже не говорю по-русски. Так что я собирался подать проблему, и я подумал: зачем подавать проблему? Давайте просто попробуем сделать это сами. Я открыл Copilot CLI. Я сказал ему клонировать, я даже не клонировал репозиторий. Я просто сказал «клонировать этот репозиторий, исправить эту ошибку и отправить запрос на слияние». И он буквально сделал это за менее чем 10 минут. Он клонировал репозиторий, диагностировал проблему, исправил ее, отправил запрос на слияние с хорошим описанием, и на следующий день это изменение было фактически объединено в проект. И это для меня был довольно удивительно расширяющий возможности момент. Я могу просто делать такие вещи сейчас. И поэтому, поэтому моя рекомендация — попробовать сделать что-то, чего вы обычно не делаете. Прототипируйте вещь, которую вы откладывали некоторое время. Реализуйте сумасшедшую функцию в вашем программном обеспечении, на которую вы бы не подумали, что у вас обычно есть время, просто попробуйте и просто посмотрите, как быстро вы сможете добиться прогресса. Если вы хотите делать вещи внутри VS или VS Code, это абсолютно нормально. Но я думаю, что стоит попробовать CLI. Это странно затягивает. Я не знаю, что это такое в том, как работает пользовательский интерфейс, как настроен агент. Что-то в этом просто кажется очень успешным. Так что попробуйте, и, э, посмотрите, как у вас получится. >> Последнее, последнее, можете ли вы показать нам, хорошо, я убежден, как нам начать? Где лучше всего узнать об установке и настройке Copilot CLI? >> Да. Да. Итак, вы можете перейти к этому репозиторию GitHub/copilot CLI, в настоящее время в публичной предварительной версии, и именно там вы найдете всю документацию и где вы найдете шаги для начала работы. Так что вы можете увидеть, какие платформы поддерживаются. Вы можете установить его через Winger, если хотите. Я думаю, Скотт Хансен только что разместил его и в магазине Windows. Или на всех платформах вы можете установить его через npm, если хотите. Так что есть много простых способов начать работу с этим, и, надеюсь, это проведет вас через весь процесс аутентификации и начала работы. >> Отлично. Хорошо, это было увлекательно. Спасибо за все потрясающие демонстрации. Э, э, отлично. Я отпущу вас. Спасибо всем за отличные вопросы. >> Отлично. >> Итак, и мы вернемся с нашим обычным ведущим Бруно на следующей неделе, и я сыграю песню «Спасибо за просмотр». Пока, народ. >> Пока.