Transcription
Добро пожаловать в первую часть для всех. Подождите, подождите, подождите. [смех] Вы готовы? Добро пожаловать в контекстную инженерию. Э, и как делать это правильно, как делать это со всеми новыми вещами, которые вы видели на ключевом докладе. Попытка объединить все это. И это не просто для того, чтобы вы поручали больше своих повседневных дел ИИ, а для того, чтобы в целом правильно решать эти задачи означало, что вы можете выполнять более длительные, более сложные задачи с помощью LM. Я работаю над VS Code. Так что первый раунд будет посвящен тому, как мы в команде VS Code это делаем. Там играет отличная музыка. Это потрясающе. Мне нравится эта сцена. Э, это вступительная музыка для меня. А позже мы займемся контекстной инженерией в действии и выйдем за рамки, чтобы показать больше практических примеров. Итак, чтобы понять контекстную инженерию, вам нужно понять, что агент видит "из коробки", и в основном понять, что это ваш кодовая база. Так что же на самом деле означает смотреть на вашу кодовую базу и что еще она видит? В VS Code агент, который вы знаете и любите, — это Copilot. Он понимает не только контекст вашей кодовой базы с репозиторием. Он может находить код, используя основанный на векторах семантический поисковый индекс, что означает, что он может выполнять гораздо более широкие запросы, чем просто конкретные файлы и имена функций. Но также понимает, если вы ищете аутентификацию, если она называется "login", он все равно сможет ее найти. И это один из ключевых принципов того, почему этот агентский поток работает так хорошо. Он также может выполнять команды терминала и искать окончательное выполнение, которое вы все видели во многих ваших агентских потоках. Но он также может искать ошибки в этих агентских потоках. Задачи. Сколько из вас настроили FBS Code с задачами? У вас есть быстрая задача сборки, задача линтинга и все остальное. Это ключевой ингредиент для агента, потому что агент понимает, какие задачи выполняются в фоновом режиме в VS Code, и может реагировать и искать их по мере внесения изменений. Если у вас выполняется задача, которая отслеживает ваш код, пересобирает его и потенциально прерывает при ошибках, цикл агента Copilot может знать об этом и проверять его после каждого хода. Мы фактически используем это в VS Code. Я покажу, что у нас также есть поиск символов и шаблонов, и это выполняется встроенным в VS Code средством анализа языка. Что это значит для вас, так это то, что вы должны убедиться, что для каждого языка, который вы используете в своем проекте, установлены правильные расширения и серверы языка. Так что, если вы не видите красных загогулин или видите слишком много красных загогулин, потому что ваш линтинг не настроен должным образом, это сбивает с толку людей, а также сбивает с толку агентов. Далее у нас тесты. Итак, вы можете настроить тесты для выполнения в VS Code. Вы можете настроить их для выполнения в терминале, но VS Code имеет встроенный средство запуска тестов, которое также доступно агенту. Он может не только запускать наборы тестов, но и запускать частичные тесты, и у него есть доступ к любым неудачным тестам. Так что инвестируйте в правильную настройку тестов и всего этого, и агент и ваши люди, использующие VS Code, получат выгоду. Наконец, проблемы, и это снова связано с анализом языка. Все, что имеет ошибки линтинга, снова доступно агенту, и это часто происходит в реальном времени после внесения изменений, он получает это в качестве обратной связи. Если вы внесли изменение, и функция не существует, линтинг укажет на это, и агент немедленно узнает об этом. И это не то, что вы легко получите в командной строке. Но в VS Code, поскольку вы можете вводить код и получать эти красные загогулины, агент получает ту же выгоду. Опять же, убедитесь, что у вас установлены правильные расширения, и вы даже делаете больше линтинга. Классический пример, который я рекомендую, — это линтинг доступности. Существует несколько расширений доступности, которые фактически ставят красные загогулины под всем, что не соответствует правилам доступности, и это просто языковой инструмент. Так что вы можете даже расширить это. Итак, все отмеченные элементы, вы должны убедиться, что они настроены в VS Code, чтобы принести пользу агенту и получить этот контекст "из коробки". Просто коснувшись обновлений поиска кода, которые мы сделали. Существует новая модель встраивания, и все это из сообщения в блоге, которое вышло в прошлом месяце, с лучшим качеством поиска, где мы видим более высокие показатели принятия и более быструю пропускную способность. Это пользовательская модель. Ранее мы использовали модели GPT для этого, и это реальные преимущества, которые вы видите: вещи работают быстрее или надежнее, и это действительно помогает агенту совершать меньше ходов, чтобы найти правильный код, но также помогает вам, что вы можете иметь большую неопределенность в своем запросе, и агент все равно обнаруживает правильные части кода для внесения изменений. Хорошо, давайте погрузимся в фактическую кодовую базу VS. Итак, это github.com/microsvs code. Если вы хотите увидеть, что я показываю, просто откройте репозиторий VS Code, так как все это открыто. Так что это репозиторий VS Code, и даже мы как команда исследовали это пространство, что такое контекстная инженерия. Нет жестких правил. Нет конкретных файлов для добавления. Это скорее техника того, как оптимизировать контекст, сжать его достаточно и сделать его достаточно доступным для агента, чтобы он мог его извлекать по мере необходимости. И лучшая отправная точка, и это то, что я рекомендую всем, — это инструкции Copilot. Так что инструкции Copilot вы также можете использовать agents.mmd как кросс-агентную систему, по сути, это мини-карта вашей кодовой базы. Вы говорите агенту, где что находится. Так что он тратит меньше времени на просмотр кода и попытки выяснить, где ему нужно внести изменения. Вы указываете, как его запустить, как найти связанный код, какие инструменты лучше всего работают в этой кодовой базе — это общее правило. Как проводить проверку — это конкретные инструменты линтинга, которые он должен запускать, как он должен запускать тесты. В данном случае мы используем задачи. Так что мы указали на вывод задач. Так что в любое время, когда он вносит изменения, он должен проверять задачи. Снова возвращаясь к тому, что делает каждый разработчик в команде VS Code и что работает. Да. Так что все это теперь находится в репозитории и помогает каждому разработчику, каждому участнику, работающему над этим репозиторием, "из коробки". Эти правила включены по умолчанию. Далее у нас есть эти предметно-ориентированные инструкции. Это инструкции, которые включаются агентом при просмотре описания и извлечении их по мере необходимости. Здесь мы описываем небольшие микроконцепции, которые разделяются по всей кодовой базе и часто основаны на том, что агент делает неправильно. У нас, например, есть наблюдаемый шаблон, который довольно специфичен для нашей кодовой базы, и где агент постоянно предлагает новые API или новые шаблоны для использования этой системы, которых не существует. Так что мы просто хотим направить его к тому, чтобы мы хотели бы правильно развивать использование наблюдаемых элементов, и предоставление ему этого небольшого фрагмента информации достаточно, чтобы он получал его правильно чаще. Так что в любое время, когда он знает, что мне нужно использовать наблюдаемые элементы, агент будет извлекать инструкции по наблюдаемым элементам и в конечном итоге придет к лучшей системе. Далее у нас есть подсказки, и в конце есть сводка. Э, одна из моих любимых, над которой я работал, — это подсказка данных. Так что мы собираем телеметрию в VS Code, и она открыта, так что вы можете видеть, что мы собираем. Вы даже можете получить команду CLI, чтобы получить все события телеметрии, которые мы отправляем. Обычно это касается того, какие функции используются и какие высокоуровневые детали. Но мы, как команда, также хотим демократизировать доступ к обучению на этих данных. Если вы работаете над функцией, можете ли вы убедиться, что она достаточно быстрая, что у вас есть правильные точки входа, люди действительно находят ее. и не иметь необходимости ее маркетизировать — это на самом деле отличный способ поместить что-то, что не является кодом, в агент, который вы затем можете формализовать как подсказку, чтобы каждый мог ее запустить, не изучая пользовательские и все инструменты данных, которые вам понадобятся для доступа к данным. В данном случае у нас есть MCP, Azure MCP, работающий за этим, и доступ к репозиторию GitHub для доступа к другому отдельному репозиторию, и он просто описывает поток того, как писать пользовательские на основе данных и какой типичный поток мы хотим. У нас есть несколько других вещей. Э, я хотел показать режим планирования, который мы используем, но они фактически уже выпустили его. Так что, позвольте мне показать вам режим планирования, который теперь встроен. Кто видел материалы с ключевого доклада о планировании? Так что, очень интересно. Э, так что режим планирования теперь здесь. Раньше он был здесь, но вы можете фактически увидеть его. Если вы когда-нибудь задавались вопросом, как он выглядит, вы можете просто открыть и посмотреть. Э, к каким инструментам у него есть доступ, и сделать свои собственные. Я очень призываю вас подумать о том, как вы хотите планировать. Это создание ветки? Это просмотр Confluence? Это создание черновика, которым вы хотите поделиться в Slack или обратно в проблему? Есть много способов, которыми люди разбираются в планировании и, как и в случае с переполнением помощи в первую очередь с помощью ИИ. Так что для вас очень важно выяснить, что это значит. Так что у нас есть, э, важные части здесь, э, есть некоторые элементы пользовательского интерфейса, описание и подсказка аргументов, которые делают его приятным в использовании, к каким инструментам он ограничен. Это четкий шаблон контекстной инженерии, ограничивающий количество вещей, к которым LM может получить доступ, что агент может сделать, а затем передать. Если вы сейчас начнете планирование здесь, э, редактируемый список дел, вы перейдете в режим планирования, и в конце, возможно, мы сделаем один здесь. Давайте скажем, вы видите другой шаблон контекстной инженерии, который используется здесь, — это запуск под-агента. И это здесь, вы можете фактически упоминать инструменты в описании, и изолированный под-агент в данном случае выполнит все обнаружение. Этот маленький шаблон пользовательского интерфейса здесь означает, что этот агент теперь запускает поиски в своем собственном агентском цикле и просто возвращает нужное количество данных родительскому процессу. Так что я использовал это во всех своих подсказках. Теперь, когда я провожу исследования, я просто направляю его к пользовательскому под-агенту, провожу много исследований, углубляюсь и просто возвращаю то, что нужно для ответа на вопрос. И таким образом у меня есть чрезвычайно длительные агентские разговоры, потому что они продолжают сокращать объем контекста, который накапливается, до самых существенных элементов. Так что он читает много файлов, много исследований, но возвращает только то, что нужно для реализации этого запроса на функцию. Итак, наконец, э, мы говорили о подсказках, мы говорили об инструкциях. Давайте просто посмотрим, как это выглядит в реальном мире. Так что пользовательские инструкции — это своего рода правила взаимодействия, всегда включенные и стандарты кодирования. Это идеальное место. Не играйте роли. Не давайте ему роль эксперта по TypeScript. Э, просто сосредоточьтесь на том, как писать хороший код, какой плохой код следует избегать, какие инструменты использовать и где вообще находятся вещи в кодовой базе. В лучшем случае вы просто позволите Copilot написать это для вас. Здесь есть кнопка "Сгенерировать инструкции чата" прямо здесь. Это команда. У нас есть красиво настроенная подсказка, которая будет повторно запускаться для вас, и мы генерируем инструкции в вашей кодовой базе, которые вы должны просмотреть, но это живой документ. Вы продолжаете обновлять. Следующее — подсказки. Я упомянул, что это одноразовые многоразовые команды. Подумайте о том, что вы хотите автоматизировать. У меня много. У меня есть одна вещь, которая просто фиксирует изменения, просто берет все изменения, которые у меня есть, создает из них коммит и отправляет его. Одна вещь, которая фиксирует и создает PR из него с базовой точки зрения. Так что все, на что я не хочу тратить время в командной строке, все, на что я не хочу тратить время на исследования, я начал помещать в свои личные подсказки, и именно с этого я рекомендую начать. А затем пользовательские агенты — это эти действительно богатые персоны, рабочие процессы, где вы хотите проводить больше времени, итерируя в рабочем процессе, который становится многошаговым, ограниченным инструментами и своим собственным системным промптом и рабочим процессом. Хорошо, давайте быстро перейдем к более конкретным рабочим процессам. Э, так что один, который я хочу показать, — это рабочий процесс разработки, управляемой тестами. У меня есть TDD red, который пишет неудачные тесты. У меня есть TD green, который пишет проходящие тесты, которые делают тесты быстрее, добавляя реализацию, а затем TD refactor, который делает реализацию приятнее и доводит ее до совершенства, потому что вы просто хотите иметь MVP в зеленой фазе. Так что все это связано с передачами, и вы видите это здесь. Просто сделаю это больше. Так что это подсказка TD, которая является точкой входа. Позвольте мне быстро показать ее. Она просто говорит TD start с TD red, начните новую функцию, опишите функцию, мы перейдем к TD red. Так что вы можете думать о подсказках и режимах как о компонуемых примитивах, которые дают вам разные виды точек входа. Если вы посмотрите на это, она начала TDD. Она заметила, что артефакта TDD еще нет, где было задокументировано, что она должна реализовать. Она создает его, просматривая кодовую базу, создавая документы TDD. Давайте быстро посмотрим, как это выглядит. Так что это обычно просто закрытие вещей. >> Это список тестов, крайние случаи, дизайнерские заметки и где это необходимо, а затем список выполненных будет медленно формироваться, и именно так эти режимы работают вместе. TDD теперь выбирает следующий тест, а затем просит пользователя перейти к реализации. Теперь, если вы посмотрите на мои тесты, у меня есть один неудачный тест, который он только что создал в TDD red, и это то, что я могу просмотреть сейчас, и именно здесь режимы действительно сияют, и передачи, что вы можете иметь момент для сотрудничества человека и агента, просматривая тест как контракт, что это имеет смысл, а затем двигаясь дальше. Так что подумайте о том, что вы можете автоматизировать в многошаговых потоках, где человек в середине все еще может просматривать и принимать и переходить к следующему шагу по сравнению с другими агентами, которые более оркестрованы и просто двигаются дальше без вас. Вы хотите иметь этот контроль. Далее у нас есть более визуальные потоки. Э, просто хочу показать, если вы думаете о режиме планирования, он теперь встроен. Это не значит, что вы застряли с ним. Подумайте о том, каковы точки входа и как вы можете масштабировать планы "из коробки". В данном случае я написал запланированную проблему для исследования, которая действительно направлена на проверку концепции архитектуры. Я не хочу, чтобы вы создавали целую функцию и писали тесты. Я просто хочу подумать, как будет работать бэкенд. Каковы критические точки в этом плане, о которых мне нужно чаще размышлять, часто это либо бэкенд, либо инфраструктура, или у меня также есть одна, потому что у меня постоянно возникают проблемы с планами. Я не могу представить, как выглядит пользовательский интерфейс из большой собаки Markdown. Так что подумайте о том, как режимы и планы могут работать вместе, чтобы сместить планирование в сторону того, что является наиболее критичным, что вам нужно выяснить. И, наконец, подумайте о том, как вы можете работать над пользовательским интерфейсом, как этот, где он теперь может перейти в режим дизайнера, а затем начать, а затем позволить ему поиграть с тем, что фактически реализуется, и в реальном времени выяснять, что происходит. Так что разбивая на более интерактивные шаги, которые вы можете контролировать. Так что это может работать, вы можете связаться со мной позже, чтобы увидеть, как это выглядит в конце. Так что начните с левой стороны, пользовательские инструкции, загрузите минимальное исправление агента, автоматизируйте рутину, а затем перейдите к рабочим процессам. Так что это то, как вы начинаете, много документации в наших документах VS Code. Есть также документ о контекстной инженерии. Если вы хотите прочитать больше, он написан мной. Если у вас есть отзывы, пожалуйста, открывайте проблемы. В противном случае, счастливой контекстной инженерии.