Transcription
ИИ-ассистенты захватили браузеры и редакторы кода. Но как насчет терминала? Место, где инженеры на самом деле живут. Сегодня я хочу взглянуть на Gemini CLI от Google с точки зрения DevOps S и платформенной инженерии. Итак, сегодня мы посмотрим, что такое Gemini CLI, как его запустить и что он может делать. Но самое главное для инженеров: мы будем использовать его для изучения функций ИИ. Что такое агент? Навыки, MCP, модели и все то, о чем инженеры должны знать сегодня. Gemini CLI — это агент, который работает в вашем терминале, что означает, что у него есть доступ ко всем вашим файлам, локальной операционной системе. Он может делать такие вещи, как запускать cubectl, выполнять команды CLI, запускать кластеры Kubernetes. Это как ваш личный DevOps-ассистент. Но что делает его лучше IDE, так это то, что он может работать в вашем терминале, и вы можете запускать несколько экземпляров, давать им задачи и работу. Но прежде всего, большинство из вас, кто смотрит, не подписаны. Так что, если вам понравилось видео, если вы нашли его полезным, поставьте лайк, подпишитесь, и без дальнейших церемоний, давайте начнем. [музыка] Итак, что это за ажиотаж вокруг ИИ CLI и почему CLI? Что он на самом деле может делать? Во-первых, мне нравится в Gemini CLI то, что он с открытым исходным кодом, и код находится на GitHub. И больше всего мне нравится в CLI то, что у него самый щедрый бесплатный тариф. Все, что вам нужно, это личная учетная запись Google. Теперь я думаю, что это отлично подходит для инженеров, потому что мы все учимся. И когда вы можете учиться бесплатно, это разрушает барьер для входа. Как инженер, я всегда призываю людей быть инструментно-агностическими. Мы не хотим создавать ИИ-агентов, которые могут работать только в Gemini. Все, что мы узнаем сегодня, мы можем сделать в Claude, Open Code и любом другом CLI. Итак, мы хотим расширить наши навыки. Узнать об агентах, инструментах, MCP, навыках, и Gemini CLI поможет нам сделать это сегодня. Чтобы начать, все, что вам нужно сделать, это перейти на studio.google.com. Войдите в свою учетную запись Google. Затем, в левом нижнем углу, вы можете получить API-ключ. Вы должны увидеть API-ключ для вашего проекта по умолчанию. Нажмите на него и получите ключ. Затем мы можем перейти в наш терминал и установить переменную под названием gemini_appi_key и вставить ключ туда как переменную окружения. Прямо на главной странице Gemini вы увидите команду npm, которую вы можете скопировать и выполнить. Для этого вам понадобится NodeJS. Это позволяет установить Gemini CLI непосредственно на вашу машину. Это один из способов сделать это. В документации Gemini также есть раздел установки, который дает вам несколько альтернативных способов установки CLI для вашей операционной системы. Вы даже можете запустить его в Docker, так как есть предоставленный образ Docker. И если вы сумасшедший, как я, вы можете даже создать свой собственный Dockerfile, а затем запустить Gemini внутри контейнера. Это просто помогает мне держать CLI в песочнице, чтобы мне не нужен был Node.js и все эти зависимости на моей машине. Как только вы установите Gemini, вы можете просто набрать Gemini, чтобы запустить его. И вот оно. С запущенным CLI в вашем терминале я хочу взглянуть на первые впечатления, что он может делать и как запуск ИИ в терминале может быть полезен. Во-первых, давайте посмотрим на команду справки. Итак, в этом интерактивном терминале я могу сказать /help. И это даст мне похожие советы, как и -help, которые вы находите в обычных CLI. Мы можем видеть важные команды, такие как агенты, как работать с агентами, как работать с аутентификацией, как просматривать ваши автосохраненные разговоры, очищать историю разговоров, как добавлять больше каталогов, такие функции, как хуки, команду init, MCP, память, модели, план, возобновление чат-разговора, получение статистики, изменение темы, доступ к инструментам, навыки, настройки, и это важные. Он также дает вам представление о том, как перемещаться по терминалу. Обычно, когда вы запускаете эти терминалы, первое, что вам нужно сделать, это войти в систему. Вы можете видеть, что я уже вошел в систему, потому что я установил эту переменную окружения. Если вы хотите выйти или войти другим способом, вы можете просто набрать /orth. Затем вы можете сказать sign in или sign out, если закончили. Вход предоставит вам различные методы аутентификации. Sign in with Google. Это вызовет браузер. Или просто используйте API-ключ. Чтобы отменить любое из этих меню, я просто нажимаю клавишу Escape. Затем мы возвращаемся к началу. Итак, навигация по CLI с помощью команды справки важна. Аутентификация — это первое. Третье, что мне нравится и что важно, — это выбор модели. Модель — это мозг агента, и она будет определять каждый результат. Это также влияет на стоимость. Так что, если вы используете дорогую модель, вам может быть выставлен счет или вы можете быть ограничены при использовании бесплатного тарифа, и у вас могут закончиться токены. Поэтому, чтобы поиграть с ИИ, я всегда рекомендую брать самую дешевую модель, потому что мы здесь только для того, чтобы изучать концепции. Нам сейчас не важна точность. Чтобы выбрать модель, я просто набираю /model. Затем нажимаю Enter. И здесь я могу просто автоматически выбрать Gemini 3 или Gemini 2.5, или я могу сказать manual. Нажимаю Enter. И здесь вы можете выбрать модель. Я просто выберу Gemini 2.5 flash на данный момент, так как мы просто играем. Вы также можете запустить сеанс Gemini, просто указав имя модели. Это автоматически запустит CLI с предварительно выбранной моделью. Вы также можете настроить это в своих настройках по умолчанию. Еще одна команда, которую я нахожу очень полезной, — это /resume. Это позволяет нам просматривать автосохраненные чаты. Так что я могу сказать list, у меня нет разговоров. Но обычно вы можете использовать эту опцию для выбора предыдущего разговора, который у вас был с Gemini. Это похоже на открытие ChatGPT в браузере, а затем выбор предыдущего разговора, который вы, возможно, захотите продолжить. Полезно иметь это и в CLI. Следующее, что я нахожу очень полезным для инженеров, потому что мы всегда работаем с файлами, будь то конфигурационные YAML-файлы или код, и вместо того, чтобы позволять ИИ искать файл, вы можете фактически указать ему ссылаться на файл. Это работает и с другими CLI. Это использование символа @. Итак, я могу сказать простое да или нет. Является ли этот манифест Kubernetes действительным? А затем я могу сказать @, и он начнет ссылаться на файлы. И в этом одном каталоге я могу просто начать печатать. У него есть автодополнение здесь, и я могу нажать Tab, чтобы выбрать один, просто используя Tab в терминале под моим каталогом Kubernetes. У меня есть каталог pod. Я могу просто сказать complete, и у меня есть pod.yaml. Это позволит мне отправить файл в Gemini в качестве ссылки. Gemini CLI загрузит его в контекст. Вы можете видеть, что он выполнил инструмент под названием read many files. Мы посмотрим на инструменты чуть позже. Он обработал файл и вернул ответ. Да, это действительный YAML, потому что он работает в моем CLI. У него есть доступ к моим папкам и каталогам. Если я не укажу это, он может даже искать и использовать такие вещи, как GP и команды Linux для поиска этого файла. Он может быть довольно умным. Ссылка на файл может помочь нам оптимизировать контекст. Мы посмотрим на контекст чуть позже. Теперь, прежде чем я перейду к командам CLI, важно понять режим без интерфейса. Это полезно для инженеров DevOps SRE и платформенных инженеров, когда вы хотите автоматизировать задачи, и вы можете захотеть включить Gemini CLI или ИИ-агента в этот поток, такой как конвейер CI/CD, конвейер сканирования безопасности или любую другую автоматизацию, которую вы можете рассматривать. Итак, я просто выйду из этого, нажав Ctrl C дважды. Это выведет меня из терминала Gemini. Затем я могу просто сказать Gemini -p и передать ему запрос. Это технически называется режимом без интерфейса. И я могу вставить сюда тот же запрос, что и раньше. Простое да или нет. Является ли этот манифест Kubernetes действительным? Нажимаю Enter, и Gemini сделает свое дело. И вот мы видим, что он вернул ответ. Это полезно, если вы просто хотите запустить CLI в конвейере автоматизации, чтобы он выполнил некоторую работу. Теперь важно знать, что, как и любой другой CLI в вашем каталоге пользователей, есть файл настроек или файл конфигурации. Мы можем настраивать параметры, набирая /settings. Здесь вы можете просматривать и редактировать настройки Gemini CLI. Все различные настройки можно найти здесь. Если вы хотите использовать терминал для включения функций, вы можете нажать Tab, чтобы перейти туда, где вы хотите, чтобы настройка применялась. Вы можете находиться в каталоге пользователя или для конкретного рабочего пространства, если у вас есть несколько репозиториев git или несколько проектов под этим каталогом, или по всей системе. Я обычно предпочитаю использовать пользовательские настройки. Я могу нажать Escape, чтобы выйти из этого. Если вы посмотрите документацию по настройкам Gemini CLI, вы увидите, что пользовательские настройки хранятся в каталоге .gemini под вашей папкой пользователей в файле settings.json или на уровне рабочего пространства. Вы можете пройти через справочник и посмотреть справочник настроек для всего, что вы можете изменить. Общие настройки, настройки вывода, настройки пользовательского интерфейса, IDE, биллинг, настройки моделей, настройки агентов, настройки контекста, настройки инструментов, безопасность и многое другое. Я покажу вам больше о настройках чуть позже, но вы также можете изменить свою тему. Если вы наберете /theme, вы можете выбрать разные темы для своего терминала. Это также будет сохранено в вашем файле настроек. Теперь одна из самых крутых функций, которую я нахожу в этих ИИ CLI, заключается в том, что все они поддерживают или большинство из них поддерживают режим CLI или режим оболочки. Это позволяет нам выполнять произвольные команды оболочки. Иногда вам может понадобиться выполнить ls или cat или любую другую команду Linux на вашей машине. и вам не придется выходить из этого CLI, а затем снова входить. Итак, чтобы включить режим оболочки, мы просто нажимаем восклицательный знак. И теперь мы в режиме оболочки. Я могу затем набрать ls -la, вы можете видеть, что у нас есть все наши файлы. И у него также есть автодополнение, как и у любого другого терминала. Так что, если я наберу cat и перейду в свой каталог пользователей и наберу gemini, посмотрите на всплывающее окно автодополнения. Так что я могу просто набрать Tab и набрать tabs и выполнить cat на моих настройках. И здесь вы можете видеть, что у меня есть некоторые настройки. Я могу нажать Ctrl O, чтобы показать все. И это содержимое моего файла настроек. У меня выбрана тема, и у меня включены некоторые экспериментальные функции. Я могу даже делать больше вещей, таких как запуск apt update и apt install чего-нибудь вроде nano, если мне нужен текстовый редактор. У меня есть полный доступ к моей базовой оболочке. Так что это позволяет мне делать более сложные вещи, если я захочу. Чтобы выйти из режима оболочки, я могу просто снова нажать восклицательный знак. Так что Shift и 1 в моем случае, и мы вернулись к обычному режиму команд ИИ. Я могу набрать /clear, чтобы очистить экран и историю разговоров. Просто сделаем все чисто. И еще одна интересная функция этих CLI называется /tools. Все эти ИИ CLI имеют базовые инструменты, и они используют их для команд и функциональности, которые часто повторяются. Вы видели ранее, как ИИ-агент автоматически читал файл. Это был инструмент read file. Иногда ему может понадобиться перечислить каталоги. Он может использовать инструмент команды оболочки. Если мы перейдем в терминал и выполним команду tools, вы увидите, что есть куча инструментов. Это инструменты, которые Gemini CLI использует довольно часто. Если мы попросим его проверить что-нибудь в Интернете, он выполнит веб-запрос. Он может искать документ, используя GP. Так что есть инструмент GP search. Список файлов, есть инструмент read folder, инструмент read file. Он может выполнять поиск в Google. Одна важная вещь заключается в том, что он также может активировать навыки. Мы посмотрим на навыки чуть позже. Инструменты — это, по сути, просто упакованные возможности для CLI. Обычные вещи, такие как поиск в Интернете, чтение файла, перечисление файлов в каталоге и тому подобное. Теперь, когда у нас есть базовое понимание команд, я просто не хочу перечислять все команды по одной. Итак, давайте посмотрим на некоторые варианты использования ИИ и концепции. Это означает, что независимо от того, используете ли вы copilot, open code или claude, все эти концепции применимы. Помните, что CLI — это просто агент. Если вы посмотрите мое видео по терминологии ИИ, у вас должно быть базовое понимание того, что такое агент и как он работает. Это означает, что мы можем переключать CLI в любое время. Обычно, когда мы начинаем, у нас есть репозиторий с некоторым кодом, будь то инфраструктурный код, скрипты или документация. Мы хотим, чтобы наш CLI-агент мог выполнять работу или помогать нам с работой. Базовый и обычный способ начать ИИ-путешествие — это инициализация. Здесь мы позволяем ИИ-агенту анализировать наш репозиторий и файлы, и он обобщает весь репозиторий, о чем он, любые стандарты и соглашения, которые он находит, структуру каталогов. Он обобщает это в файле markdown. Большинство, если не все CLI имеют команду init. Если я запущу Gemini CLI в репозитории GitHub нашей серии видеороликов по разработке Docker, я могу доверить папку. А затем я могу взглянуть на команду init. Это проанализирует проект и создаст индивидуальный файл Gemini MD. Итак, я собираюсь запустить это, а затем дам ему немного времени. Вы можете видеть, что он начинает выполнять некоторые инструменты для чтения файлов. Он думает и пытается понять наш репозиторий. Он попросит у меня разрешение на запись файла Gemini MD. Я могу просто сказать allow для этого сеанса. И вы можете видеть, что он начинает создавать обзор проекта, структуру каталогов, ключевые файлы и каталоги. По сути, все, о чем этот репозиторий. И это, по сути, весь этот репозиторий. Это образовательный репозиторий. У него есть обзор каталогов, ключевые файлы и просто некоторые базовые общие суммированные инструкции. В моем видео по терминологии ИИ я рассказывал о так называемом контекстном окне, краткосрочной памяти, когда мы разговариваем с ИИ-агентом. Это краткосрочная память модели, по сути. Но каждый запрос, который мы отправляем модели, и ответ туда и обратно — это, по сути, наш разговор. И все это проходит через так называемое контекстное окно. И контекстное окно имеет ограниченный размер. Когда мы задаем вопросы ИИ, он добавляется в конец контекстного окна. Это означает, что когда контекстное окно заполнено, самые старые разговоры вверху будут отсекаться первыми. Так что контекстное окно — это, по сути, движущаяся вещь, поскольку разговор растет и растет. Это означает, что чем дольше вы обсуждаете и разговариваете, тем больше контекста теряется. При работе с CLI и создании агентов и навыков понимание контекста очень важно. И контекстная инженерия — важная тема для изучения. И именно поэтому команда init так важна. Это важная команда для начала. Так что вместо того, чтобы мы разговаривали с агентом, который разговаривает с LLM с большим количеством запросов и ответов, мы можем дать ему более прямое внимание с помощью файла Gemini MD. В других технологиях, таких как Claude, это Claude MD. С Copilot это C-pilot instructions.mmd. Также есть agents.m MD. Но по сути, все это — системный запрос. Это инструкция MD, которую мы видим здесь, которая подается в контекстное окно перед началом разговора. Здесь есть несколько вещей. Во-первых, это сводит к минимуму запросы. Это помогает агенту понять репозиторий, с которым он работает, еще до начала разговора. Это дает модели больше внимания, а также рекомендации, и мы получаем лучшую точность и согласованность, когда другие разработчики или инженеры открывают тот же репозиторий и начинают разговор. Этот Gemini MD существует исключительно для руководства. Вы не хотите постоянно добавлять в него больше и больше и делать его слишком большим. Есть последствия слишком большого количества инструкций. Мы можем использовать команду memory в Gemini CLI для просмотра содержимого памяти. Если я запущу это и скажу list, вы увидите, что нет файлов Gemini MD в использовании. Я могу сказать memory reload, и вы увидите, что это заставило агента загрузить один файл. Затем я могу нажать вверх и вниз, чтобы просто выполнять старые команды, как и любой другой CLI. Если я скажу memory list, вы увидите, что он теперь обнаружил наш файл Gemini MD. Это означает, что мои разговоры с Gemini будут более адаптированы к моему репозиторию. Так что файл Gemini MD существует исключительно для получения сфокусированного контекста для вашего ИИ-агента. И важно помнить, что CLI, приложение командной строки, которое мы сейчас запускаем, является агентом. Это главный агент. Так что, если у вас есть репозиторий инфраструктурного кода, скажем, вы работаете с чем-то вроде модулей Terraform или шаблонов облака или манифестов Kubernetes. В этой инструкции вы можете направить ИИ, что делать, а что нет. Этот Gemini MD — это, по сути, просто файл агента, который попадает в контекст. Теперь мы не хотим засовывать все в контекст, потому что чем больше мы помещаем в контекст, тем больше внимания мы теряем. Вот почему существует концепция под названием суб-агенты, которая также является функцией Gemini, где вы можете иметь несколько агентов, и каждый из этих агентов имеет свой собственный контекст. Это означает, что вы можете иметь агента, который является экспертом по Kubernetes. Все в его контексте будет сосредоточено на Kubernetes. Вы можете иметь эксперта по Terraform, эксперта по безопасности, и это означает, что у вас есть более сфокусированный контекст для каждого из этих агентов. Итак, до сих пор у нас есть Gemini CLI, который действует как главный агент. Это наш интерфейс к контекстному окну и LLM. Мы можем разделить контекстное окно и иметь несколько суб-агентов. Итак, мы будем взаимодействовать с нашим главным агентом, которым является Gemini CLI. И на основе наших обсуждений Gemini CLI может вызывать суб-агентов. Так что у нас может быть что-то вроде агента Kubernetes здесь, который имеет свой собственный системный запрос. Так что у него может быть свой собственный файл Gemini MD. У нас также может быть агент DevOps или агент Terraform или агент безопасности со своим собственным контекстным окном. Важно то, что каждый агент имеет свой собственный контекст. Так что это означает, что он может быть более сфокусированным. Так что, если мы дадим агенту Gemini, нашему главному агенту, кучу инструкций, и ему нужно будет что-то сделать через агента Kubernetes, главный агент передаст сфокусированный контекст и только нужную информацию агенту Kubernetes. Это поможет нам получить немного больше точности и лучшую общую производительность от контекста. Важно знать, что на момент записи суб-агенты с Gemini CLI являются экспериментальной функцией. И чтобы получить к ним доступ, мне нужно включить пару настроек, а также запустить предварительную версию CLI. Итак, что такое суб-агенты? Вы можете рассматривать их как специалистов, которых главный агент Gemini или CLI может нанять для конкретной работы. У них более сфокусированный контекст. Итак, каждый агент имеет свой собственный системный запрос, свою персону и, по сути, свое собственное контекстное окно. У них всех могут быть специализированные инструменты. Итак, мы можем ограничить агентов определенным набором специализированных инструментов. И, как я уже упоминал ранее, у них есть независимое контекстное окно, которое позволяет нам экономить токены в истории основного разговора. Итак, как использовать суб-агентов? Есть два способа. Один — автоматическое делегирование. Это просто задать главному CLI какой-то вопрос, и главный агент может решить вызвать базовый суб-агент на основе вопроса, который вы задаете. Так что, если у меня есть главный агент и агент Kubernetes, и я задаю главному агенту вопрос о Kubernetes, он может автоматически делегировать эту задачу суб-агенту. Но здесь могут быть некоторые проблемы, потому что это просто чистый английский. Так что он может ошибиться и не делегировать его суб-агенту. Так что будьте осторожны с этим. Мы также можем принудительно использовать синтаксис @. Так что мы можем фактически упомянуть конкретного агента по имени. Так что здесь вы можете сказать @codebase investigator, иди и выполни следующую задачу, пожалуйста. Итак, два способа вызвать агента. Итак, чтобы проверить мои настройки, я могу выполнить некоторые из команд, которые мы узнали ранее. Я могу войти в режим оболочки и набрать nano, и когда я запущу это, откроется nano в режиме оболочки. И здесь я могу использовать nano, чтобы перейти и отредактировать некоторые настройки. И, по сути, нам нужно было включить экспериментальный раздел, включить агентов, а также включить суб-агентов. Затем я могу выйти из nano после сохранения и просто перезапустить CLI. Как только вы это сделаете, вы увидите, что у вас будет доступ к команде /agents. И здесь мы можем перечислить агентов, и у меня есть этот агент технического писателя, который является специализированным агентом для написания сценариев производства технических видео. Вы можете использовать agents reload, если вы только что создали нового пользовательского агента. Вы можете перечислить их. Вы можете включить, отключить или настроить агента. Документация точно говорит вам, как создать пользовательского агента. Во-первых, вам нужен предварительный режим, и вам также нужно включить экспериментальную настройку enable agent, как я показал ранее. Затем вы создаете файл определения агента. Это так же просто, как это. В вашем репозитории у вас есть папка Gemini, а под ней — папка agents, а затем любой файл MD. Имя файла MD, я обычно оставляю его как имя агента. Вы также можете иметь пользовательских агентов. Так что у вас могут быть свои личные агенты в вашей папке пользователя, или у вас может быть один в проекте или в репозитории git для создания файла агента, который должен существовать markdown, а затем содержимое — это, по сути, начало с YAML-форматировщика. Итак, у вас есть три тире, а внутри — два обязательных поля. Одно — это имя, так что имя нашего агента, а затем описание. Вам не нужны все эти другие поля, но есть некоторые дополнительные поля, которые он поддерживает. А затем у вас есть, по сути, то содержимое Gemini MD, которое мы видели ранее, все инструкции. Итак, здесь вы можете сказать, что вы аудитор безопасности. Ваша работа — анализировать код на предмет потенциальных уязвимостей, и на этом вы должны сосредоточиться. Так что это, по сути, файл markdown, аналогичный Gemini MD, который мы показали ранее, но он фокусируется исключительно на функциональности агента. Итак, в моем репозитории есть папка Gemini, и у меня есть папка agents здесь. Убедитесь, что вы правильно написали это, и оно должно заканчиваться на S. Здесь у меня есть мой агент технического писателя. Создав этот файл и дав ему имя и описание с индикаторами начала и конца YAML здесь, этого достаточно, чтобы агент появился в списке агентов. И здесь вы можете видеть, что я говорю ему, какую модель я хотел бы, чтобы он использовал. Это агент технического писателя, и он специализируется на написании сценариев производства технических видео. Так что я говорю ему, кто он, и даю ему некоторые основные обязанности. Итак, у него есть две обязанности. Одна — написание сценариев производства с использованием предоставленных доступных навыков. Другая — написание руководств по видеоконтенту с использованием предоставленных доступных навыков. Мы поговорим о навыках чуть позже. Но вы можете видеть, что у меня здесь не так много инструкций. Я старался свести их к минимуму. Так что, по сути, как это работает: когда я запускаю Gemini в своем репозитории, будет файл Gemini MD с рекомендациями для главного агента. Если я скажу: «Привет, пожалуйста, напиши мне руководство по производству видео для Terraform, и вот как должен выглядеть поток видео». Главный агент может посмотреть описания всех доступных суб-агентов и может автоматически вызвать и делегировать задачу агенту технического писателя, или я могу вручную заставить его использовать технического писателя, используя знак @, который мы видели ранее. Затем произойдет следующее: агент Gemini возьмет этот запрос и передаст более сфокусированный запрос суб-агенту, которым является технический писатель, а затем он выполнит свою работу. У технического писателя есть свой собственный файл MD с его собственными инструкциями, которые мы видели ранее. Так что у каждого агента есть свой собственный контекст и свои собственные инструкции. Но вы можете видеть в моем агенте технического писателя, я сказал, что при выполнении задачи я должен проверить, есть ли какие-либо доступные навыки в каталоге навыков агентов, которые относятся к данной задаче, и рассмотреть возможность их использования. Так что я сделал следующее: у меня есть специализированный агент, у которого есть свой собственный контекст, который фокусируется на написании видеоруководств и сценариев производства видео для съемок. Но я взял этот контекст инженерии на шаг дальше, с помощью того, что называется навыками. Теперь, вместо того, чтобы добавлять абсолютно все в файл markdown и добавлять его в контекст, мы можем использовать то, что называется навыками. Навыки полезны, потому что они являются новой формой контекстной инженерии. Это, по сути, набор инструкций, который загружается только при необходимости. Так что, когда мы обычно вызываем агента, файл markdown агента загружается в контекст. Навык работает немного иначе, потому что навык загружается только тогда, когда агенту нужен этот навык. Так что навык — это, по сути, простыми словами, способ разделить наши файлы инструкций и загружать их при необходимости, и агент решает это. Так что навыки агентов, по сути, позволяют нам расширять агентов и давать им более специализированную экспертизу. И здесь мы видим, что в отличие от общих файлов контекста, таких как Gemini MD, навыки загружаются по запросу. Важно знать, как работает навык. Прежде всего, у нас есть обнаружение. Так что, когда мы начинаем наш сеанс, Gemini сканирует наш каталог на наличие навыков. Теперь навыки могут храниться в папке агентов под папкой навыков. Так что в нашем репозитории git у нас может быть папка агентов, а также папка навыков под ней с кучей папок. Каждая из них представляет навык, и все они обнаруживаются при запуске Gemini. Мы можем запустить команду /skills, а затем сказать list, чтобы перечислить все доступные обнаруженные навыки. Если мы добавим новую папку, мы можем просто набрать skills reload, чтобы активировать новые навыки. Как вы можете видеть здесь, навыки могут быть активированы или деактивированы с помощью команд enable и disable. Но чтобы эти навыки были активны, нам нужно знать, как их включить. Чтобы Gemini мог обнаружить навыки, ему нужна папка агентов с папкой навыков внутри нее, а затем каталог для каждого навыка. Так что у меня есть несколько каталогов для нескольких навыков, которые я создал. И внутри них вы создаете файл, который точно написан так: Skill capital letters MD. У вас должен быть файл, подобный этому. Вы можете видеть, что в моем репозитории git у меня есть agents с навыками внутри. И затем у меня есть три навыка. Каждый из них имеет skill MD, как вы можете видеть здесь. Это очень важно, иначе ваш навык не будет активирован. Второе важное — это структура навыков. У вас должен быть skill MD в корневой папке навыка. Так что skill MD внутри. Затем у вас может быть три каталога. Один — это каталог scripts. Все они необязательны. У вас могут быть скрипты, исполняемые скрипты. References и assets позволяют немного лучше разбить контекст и просто организовать вещи, поместив примеры, документы и шаблоны и другие ресурсы в отдельные файлы. Это сделано для того, чтобы они не загромождали файл агента MD. Чтобы навык был загружен, у вас должно быть правильное содержимое. Так что он должен начинаться с YAML-форматировщика, за которым следует имя навыка и описание навыка. А затем вы должны закрыть YAML-форматировщик. Если у вас нет этого формата, ваш навык может быть не обнаружен. Итак, здесь у меня есть навык под названием Kubernetes local provisioner с skill MD. Так что, когда я создаю технические руководства и сценарии видео, я могу захотеть попросить своего агента запустить локальный кластер Kubernetes для тестирования. Теперь я не хочу добавлять все свои лучшие практики, команды и инструкции в свой агент MD, потому что мне не всегда нужен кластер Kubernetes. Так что вместо того, чтобы загрязнять файл инструкций моего агента, я просто добавляю новый навык. Преимущество этого в том, что если вы дадите ему хорошее, приятное описательное описание, вы, по сути, хотите указать в описании, когда агент должен использовать навык. Это очень важно. Когда агент запускается или CLI запускается, все навыки обнаруживаются и загружаются, но они еще не используются. Они не все загружены в контекст. Что ИИ сделает, так это, как правило, загрузит в контекст только имя и описание. Так что у меня может быть несколько навыков, и только описание и имя займут место в контекстном окне. Это означает, что ИИ-агент CLI активирует и вызовет навык на основе моего запроса, если он соответствует описанию. И только когда он соответствует, и агент CLI захочет вызвать навык, он затем загрузит все остальное в этом файле MD. Так что весь этот файл MD не загружается все время. Он загружается только тогда, когда ему нужно активировать навык. И это большое преимущество использования навыков. Так что я не буду загрязнять свое контекстное окно, если я никогда не попрошу предоставить локальный кластер Kubernetes. Я делаю то же самое для создания видеоруководств. У меня есть навык для создания видеоруководства. И этот навык загружается только тогда, когда я прошу агента создать видеоруководство. Так что, когда агент запускается, он загрузит только эту часть навыка. Как только я попрошу его создать видеоруководство, он придет и загрузит все эти дополнительные детали. Так что вы можете видеть, что у меня здесь много всего, что пойдет в контекстное окно. А затем у меня есть навык написания сценариев видео. Так что один навык для создания видеоруководства, другой для создания сценария производства видео. И вы можете видеть, что этот также имеет довольно много, что будет загружено в контекстное окно. Так что навыки — это здорово, потому что, когда я запускаю своего агента, ни одна часть тела навыков не загружается в контекст, и они загружаются только на основе того, что я прошу агента сделать. Теперь круто то, что в навыке вы также можете размещать статические документы и шаблоны. Так что вы можете поместить сюда несколько примеров. Это означает, что если у меня есть пример того, как должен выглядеть сценарий производства видео или руководство, я могу поместить его туда. Это помогает сделать мой основной файл инструкций или мой основной файл навыков немного аккуратнее. Но самое крутое, что я обнаружил, — это каталог scripts. Здесь я могу добавлять исполняемые скрипты. И круто то, что я обнаружил, что эти скрипты, которые вы добавляете сюда, не загружаются в контекст. Так что ИИ-агент, основываясь на имени скрипта, просто выполнит скрипт. Это действительно круто для детерминированного поведения. Так что, например, в моем навыке создания локального кластера Kubernetes я предоставляю агенту возможности, как это сделать. Например, чтобы предоставить локальный кластер Kubernetes, нам нужны несколько инструментов. Нам нужен curl, нам нужен kind, нам нужен cubectl, и нам нужен docker clli. Если какой-либо из этих инструментов не установлен, используйте предоставленные скрипты из навыка для их установки. И, как вы можете видеть в папке scripts, у меня есть несколько скриптов. Install curl, install docker cli, install kind, и install cubectl. И эти скрипты очень детерминированы, очень просты и прямолинейны. Так что вместо того, чтобы заставлять LLM разбираться, как выглядит установка kind или установка Docker, я могу иметь детерминированные скрипты, которые я протестировал. Так что я знаю, что они всегда работают. Это означает, что LLM не приходится угадывать. Он просто говорит: «Эй, мне нужен curl», он запустит скрипт curl. «Эй, мне нужен Docker», он запустит скрипт установки Docker. А затем LLM также достаточно умна, чтобы понять, что «Эй, мне нужно создать кластер, потому что пользователь попросил». Так что вот скрипт create cluster. А затем он будет использовать скрипт kind create cluster здесь. И здесь я могу добавить все параметры и убедиться, что каждый раз, когда он создает кластер, он идентичен. Так что у меня есть повторяемый процесс. И это круто то, что в навыках мы можем предоставить ИИ возможности, такие как скрипты или двоичные файлы или исполняемые файлы, которые, как мы знаем, дадут нам детерминированный результат. Это предотвращает угадывание LLM и ошибки. Так что, как вы можете видеть, если я наберу skills list, у нас есть наш Kubernetes local provisioner здесь. Так что я могу сказать своему агенту: «Эй, можешь, пожалуйста, создать кластер Kubernetes?» И вы можете видеть, что он немедленно просит активировать созданный нами навык. Так что я иду вперед и говорю allow once. Вы можете видеть, что он посмотрел в каталог. Теперь он понимает, что ему нужно проверить, установлены ли curl, kindl, docker и эти зависимости. Так что я могу сказать allow. Он поймет, что некоторые из них отсутствуют. Он разберется, если что-то отсутствует. Он видит, что curl установлен, kind отсутствует, cubectl и docker отсутствуют. И здесь он спрашивает, может ли он запустить наш скрипт. Так что он заметил, что у нас есть некоторые установочные скрипты в папке scripts. И он их выполнит. Так что вы можете видеть, что он устанавливает kind. Вы можете видеть, что он сейчас занят установкой docker. Ну, docker cli. И причина, по которой он устанавливает все эти зависимости, заключается в том, что у меня их нет на моей машине. На самом деле, у меня их нет внутри этого контейнера. Теперь он просит нас создать кластер Kubernetes, используя наш скрипт. и он запускает кластер kind. Так что вы можете видеть, почему навыки действительно полезны. LLM отлично справляется с определением того, какой навык активировать, а также какие скрипты загружать. Теперь нам не нужно беспокоиться о том, что LLM совершит ошибку. Он запустит наши скрипты, и они всегда будут работать, потому что мы можем писать тесты для этих скриптов. Итак, теперь вы можете видеть, что он закончил, и он создал наш локальный кластер Kubernetes kind. Я могу немедленно перейти в режим оболочки и набрать cubectl get nodes. И вы можете видеть, что наш кластер готов к работе. Обычно, когда вы используете CLI или IDE с помощью кодирования и ИИ, и вы задаете ему вопрос или проблему, он немедленно начнет искать решения и обычно начнет с реализаций. Проблема в том, что когда вы работаете над более сложным решением или сложной проблемой, скажем, вы создаете репозиторий, который использует модули Terraform или некоторые манифесты Kubernetes, вы будете возвращаться и вперед с ИИ, пока не придете к правильному решению с правильным технологическим стеком со всеми лучшими практиками и вещами, которым вы хотите, чтобы он следовал. ИИ в большинстве случаев будет ошибаться, что означает, что вам придется много раз возвращаться к нему. Чтобы достичь этого, вам придется потратить много токенов и загрязнить контекстное окно, прежде чем вы даже сможете начать. Вот почему все эти CLI имеют режим плана. Я не буду углубляться в режим плана, потому что он довольно самоочевиден, но режим плана — это способ для вас вернуться и вперед с ИИ и выработать план. Так что архитектура сложных решений требует точности. Режим плана позволяет вам, по сути, давать модели направление и своего рода рекомендации и обратную связь. заставить Gemini CLI провести исследование и дизайн, чтобы убедиться, что окончательная реализация именно то, что вам нужно. Это означает, что вы можете направлять исследования до начала работы. Так что вы можете исправить агента, если он совершает ошибки или пропускает какие-либо зависимости. Вы также можете предлагать различные архитектурные шаблоны, пока агент пишет план. И это значительно ускоряет цикл, потому что позволяет вам предоставить критически важный контекст. Так что перед началом сложной задачи вы можете сказать /plan, выполнить команду плана с вашим запросом. Затем вы можете направлять исследования. Пока идет обсуждение, вы можете начать задавать вопросы, говорить ему не забывать определенные вещи, и вы можете уточнить дизайн. Так что вы можете сказать: «На самом деле, давайте сделаем это вместо того, что вы делали». А затем Gemini CLI создаст файл MD с полным планом. И когда вам это понравится, вы можете сказать: «Это идеально. Давайте начнем с реализации». Вы можете войти в режим плана, набрав /pl, и вы в режиме плана. Вы можете начать задавать вопросы, и Gemini будет, по сути, обобщать, работать с вами туда и обратно, пока вы не доведете свой план до совершенства. Вы можете просто нажать Shift Tab, чтобы выйти из режима плана. MCP, или протокол контекста модели, дает нам возможность взаимодействовать с нашими системами с использованием естественного языка. Так что вместо того, чтобы просить LLM создавать команды cubectl, а затем предоставлять агенту доступ к кластеру, мы можем делать все это через так называемый MCP-сервер. Я немного подробнее освещал это в своем видео по терминологии ИИ. Так что, если мы хотим выполнять команды QCTL в нашем кластере, используя естественный язык, LLM может понять намерение. Затем он может запросить MCP-сервер для доступных инструментов и затем просто выполнить эти инструменты. Теперь каждый MCP немного отличается в своей работе. И существует множество MCP-серверов. Я могу перейти в этот контейнер и просто установить MCP-сервер для Kubernetes, используя npm. И после установки мне нужно его включить. Так что в файле настроек Gemini CLI нам нужно добавить новый раздел под названием MCP servers. А затем мы добавим MCP-сервер Kubernetes с его командой и аргументами. Я сохраняю этот файл, а затем перезапускаю Gemini. С загруженным MCP-сервером я могу набрать MCP list, и мы увидим, что MCP Kubernetes настроен. Он также имеет другие команды, такие как аутентификация, перезагрузка, включение и отключение. Теперь вы можете видеть, что есть куча доступных инструментов MCP, которые мы можем выполнить. [музыка] Теперь простой пример — сказать: «Можешь, пожалуйста, перечислить пространства имен Kubernetes в нашем кластере?» Идем вперед и запускаем это. Вы можете видеть, что он хочет выполнить cubectl get для ресурса namespace, используя MCP-сервер. Так что он просит у меня разрешения. Я говорю allow. Вы видите, что он получает ответ, и вот оно. Он перечислил наши пространства имен. Так что это очень простой пример использования MCP и Gemini CLI. Так что, надеюсь, это видео помогло вам начать работу с Gemini CLI и немного лучше понять ИИ CLI. Важно знать, что многие из этих концепций могут быть применены с использованием Claude, Open Code и других CLI. Дайте мне знать в комментариях ниже, какой CLI ваш любимый. [музыка] И помните, следуйте по дорожной карте Ultimate DevOps по ссылке ниже. И если вы хотите еще больше поддержать канал, обязательно нажмите кнопку «Присоединиться» ниже, чтобы стать участником YouTube. [музыка] И, как всегда, спасибо за просмотр, и до следующего раза, мир.