Transcription
В этой серии командных строк ИИ мы запускали ИИ-агентов прямо в терминале. Gemini, Claude Code, Copilot. Каждый из них по-своему подходит к одной и той же идее. Терминал — это то, где инженеры реально живут, а командные строки ИИ меняют то, как мы работаем с терминалом. Сегодня мы рассмотрим Open Code, бесплатное приложение с открытым исходным кодом для командной строки ИИ. Что делает его таким особенным? Ну, оно полностью с открытым исходным кодом. Вам не нужна никакая учетная запись. Вам не нужна подписка. Оно не зависит от модели, что означает, что вы можете использовать любую модель, которую хотите. Вы можете использовать модель облачного провайдера. Вы можете использовать свою подписку Claude или свою подписку GitHub Copilot. Вы можете подключить его к Azure и AWS, или вы можете даже подключить его к локальной модели, что означает, что оно также не зависит от провайдера. Таким образом, любой провайдер, который использует ваша компания, вы можете взаимодействовать с ним, используя Open Code. Итак, сегодня мы рассмотрим, что такое Open Code, как его установить и запустить, поймем важные команды, изучим контекстную инженерию, как создавать агентов и навыки, и работать с MCP. Мы сделаем все это прямо из терминала, потому что в терминале мы можем получить доступ к локальным файлам. Мы можем получить доступ к нашей операционной системе и инструментам. Это похоже на наличие вашего собственного персонального инженера-платформы. Но прежде всего, большинство из вас, кто смотрит, не подписаны. Так что, если вам понравилось видео, нажмите кнопку "Нравится", подпишитесь, и без дальнейших церемоний, давайте начнем. Open Code — это агент по написанию кода с открытым исходным кодом, и Open Code не зависит от модели, что означает, что вы можете запускать любую модель, включая локальные модели, что здесь является главным. Оно также не зависит от провайдера, поэтому вы можете использовать любого провайдера, включая Claude Code, GPT от OpenAI, Gemini и другие. Таким образом, вы можете войти с любым провайдером и использовать модель по вашему выбору. Установка очень проста. Это одна строка скрипта, и есть другие поддерживаемые способы его установки, включая Windows с использованием Docker, а также Mac и Linux. Эти инструменты CLI очень портативны, потому что они обычно работают как статический бинарный файл, что означает, что вы можете создать файл Docker, и это означает, что вы можете использовать Docker для сборки и запуска его в портативном легком контейнере Docker. Теперь, когда я смотрел на GitHub Copilot, Claude Code и Gemini в тех видео, первое, что мы проверяли, — это цены, потому что для всех них вам нужна какая-то форма учетной записи для входа. А для некоторых из них вам нужна кредитная карта, особенно для Claude Code. Чтобы это было полезно, к вашей учетной записи должен быть привязан способ оплаты. С Gemini и Copilot вы можете использовать свои личные учетные записи, и вы можете использовать их бесплатный уровень. У них щедрый бесплатный уровень, так что вы можете приступить к изучению концепций ИИ и опробовать приложение командной строки. Теперь Open Code меняет правила игры, потому что, когда вы запускаете его в первый раз, он подключается к бесплатным моделям, так что вы можете начать немедленно. Это особенно полезно, потому что мне не нужно входить в систему. Мне не нужна никакая учетная запись или кредитная карта. Open Code также поддерживает различные провайдеры. Таким образом, вы можете использовать свою учетную запись OpenAI, свою учетную запись GitHub Copilot, свою учетную запись Claude Code или свою учетную запись Google. Это означает, что вы можете использовать подписки, которые у вас уже есть, и одно приложение CLI для управления всем. Теперь, после установки Open Code, я был весьма впечатлен внешним видом и чрезвычайно низким порогом входа. Как и для любого инструмента командной строки, мы можем начать с флага справки, и Open Code поддерживает различные команды. Вы можете управлять серверами MCP. Вы можете запускать Open Code в безголовом режиме. Полезно для автоматизации. Вы можете управлять провайдерами, потому что мы не зависим от провайдера. Таким образом, мы можем входить в такие вещи, как учетные записи Claude или учетные записи GitHub. Мы можем управлять агентами, моделями. У него есть веб-интерфейс, и мы можем управлять нашими сеансами разговоров, а также плагинами. Обычно вы запускаете эти CLI в интерактивном режиме. Так что, если вы запустите Open Code, он запустит CLI в интерактивном режиме с очень полезным приятным внешним видом. Вы можете набрать слэш, чтобы начать доступ к различным командам, к которым у вас есть доступ. Теперь с Claude, Gemini и Copilot у них всегда была команда /auth или /login. С Open Code нам не нужно входить в систему. Мы можем немедленно начать использовать его, так как он подключен к бесплатным моделям. Мы можем проверить это, набрав /models. Таким образом, мы можем увидеть, к каким моделям у нас есть доступ. И есть три модели, которые мы можем выбрать, которые бесплатны. Это означает, что мы можем начать использовать нашего ИИ-агента немедленно. И я могу использовать клавишу Escape, чтобы выйти из любого меню. Чтобы подключиться к существующему провайдеру, мы можем использовать /connect. Мы можем выбрать некоторые из популярных провайдеров. Так что, если у вас уже есть учетная запись OpenAI, учетная запись GitHub Copilot, подписка Claude или платная подписка Google, вы можете подключить этих провайдеров. Так что, если я хочу подключить свою учетную запись OpenAI, я нажимаю на нее и могу предоставить API-ключ или использовать браузер или безголовый режим для аутентификации. GitHub Copilot я могу использовать либо github.com public, либо мою учетную запись GitHub Enterprise. Это обычно даст вам URL-адрес для кода устройства, который вы можете использовать в браузере для аутентификации, или для Anthropic мы можем использовать API-ключ, а для Google мы также можем использовать API-ключ. Определенные модели, которые вы выбираете, такие как Neatron 3, имеют разные варианты. Так что есть команда /variance, чтобы выбрать вариант модели. Теперь, согласно подсказке здесь, вы можете набрать /sessions, чтобы продолжить предыдущие обсуждения и разговоры. Таким образом, вы можете продолжить с того места, где остановились, или вы можете сделать /new, чтобы начать совершенно новый сеанс с новым контекстным окном. Теперь, аналогично другим CLI, вы можете использовать символ @ или символ для ссылки на агентов, а также на локальные файлы. Это вызовет небольшое меню автодополнения, и вы можете выбрать агента или файл и использовать Tab для автодополнения. Таким образом, я могу набрать что-то вроде простого "да или нет". Является ли этот манифест Kubernetes синтаксически правильным? И я могу начать набирать. Затем я могу использовать клавиши со стрелками, чтобы выбрать файл. И вот как вы ссылаетесь на файлы или агентов в подсказке. Я нажимаю Enter. И вы можете видеть, что теперь запущена модель ИИ. Она думает. Так что она показывает нам, о чем она думает, и вот наш ответ. Наш манифест YAML Kubernetes действителен. Он также дает нам немного информации здесь сбоку и детали о нашем контексте, который включает количество использованных токенов. Теперь работа с CLI таким образом называется интерактивным режимом. Одна вещь, которую мы могли бы сделать, если выйдем из интерактивного режима, — это запустить Open Code в так называемом безголовом режиме. Так что мы можем сказать Open Code run, за которым следует подсказка. Так что я мог бы передать то же самое сообщение, включая ссылки на файлы или агентов, как я делал раньше. Но запуск этого в безголовом режиме отлично подходит для конвейеров автоматизации. Так что, если вы хотите запустить Open Code как часть CI/CD или любой автоматизации рабочего процесса, которую вы имеете, это позволяет вам запустить агента Open Code, дать ему некоторую работу и получить результат. Теперь в документации есть раздел конфигурации с целым разделом о том, как настроить Open Code в формате JSON. Он поддерживает как JSON, так и JSON с комментариями. И вот пример того, как выглядит файл настроек Open Code. Он может храниться в нескольких разных местах и извлекается в соответствии с определенным порядком. Вы можете получить конфигурацию из удаленного местоположения, наиболее популярным из которых является глобальная конфигурация в вашей системе. Так что в папке config есть папка open-code, а внутри нее — файл open-code.json. Здесь вы можете установить все свои пользовательские предпочтения, такие как предпочтительные модели, агенты по умолчанию, тема для использования и многое другое. И в боковом меню здесь вы можете увидеть все, что можно настроить. Различные инструменты, различные модели, темы, агенты, команды, плагины, серверы MCP и многое другое. Одна вещь, которую я нахожу особенно полезной с ИИ в командной строке, — это возможность переключаться между различными режимами. Так что прямо сейчас мы находимся в режиме подсказки. Так что вы можете просто набрать сообщение. Но если вы хотите получить доступ к обычным командам оболочки, вам придется выйти. Вам придется выйти, чтобы запустить оболочку. Но круто то, что CLI поддерживает режим оболочки, нажимая символ восклицательного знака. Вы можете видеть, что режим переключился на shell. И мы можем делать такие вещи, как ls. Я также могу снова войти в режим оболочки и посмотреть содержимое файла. Так что я могу посмотреть содержимое моего файла open-code.json. И вы можете видеть, что он прямо там. Так что у меня есть доступ к оболочке, не покидая интерактивного терминала. И я могу даже запускать более продвинутые команды, такие как apt get update, и я могу устанавливать вещи, делать всю мою работу по Linux и DevOps, не покидая Open Code. Теперь вместо того, чтобы просто проходить через все команды, я хотел сосредоточиться на важных концепциях ИИ. Независимо от того, будете ли вы использовать Open Code или Gemini CLI, Copilot или Claude, CLI технически взаимозаменяемы, а концепции ИИ — это то, что вы должны взять с собой. Вы можете заменить CLI в любое время. Теперь, когда вы начинаете использовать ИИ в терминале, обычно ваша цель — работать с некоторыми файлами, будь то кодовая база, инфраструктура как код, конфигурация, документация или что-либо еще. Так что первое, что вам обычно нужно сделать, — это рассказать ИИ о вашем репозитории. Именно поэтому все эти ИИ-агенты обычно имеют команду init. Это способ обучить агента или агента CLI кодовой базе, чтобы вы не тратили много токенов. Так что, если я выйду из Open Code и перейду в репозиторий канала на GitHub и запущу Open Code там, а затем наберу init. Это, по сути, способ создать управляемый файл agents.md. Теперь все концепции ИИ имеют это. В Copilot это co-pilot instructions.md. В Claude это Claude.md. С Gemini это Gemini.md. С Open Code это agents.md. Когда я запущу это, Open Code использует модель, которую я использую, и попытается изучить репозиторий. Он может сканировать файлы, смотреть структуру каталогов, выяснять, о чем этот репозиторий. Как вы можете видеть здесь, у нас есть куча выполнений инструментов, потому что, по сути, он пытается понять файлы, структуру каталогов и все в этом репозитории. Он проверяет, существуют ли уже какие-либо другие agents.md. И это займет некоторое время. Так что мы оставим его готовиться. Причина, по которой эта инициализация важна, заключается в фундаментальном способе работы LLM и агентов. Когда пользователь разговаривает с моделью LLM, мы отправляем подсказки модели и получаем ответы. Это то, что формирует наше обсуждение. Теперь кратковременная память модели в основном называется ее контекстным окном. Так что весь обмен сообщениями между нами и агентом сохраняется и заполняет это контекстное окно. Теперь, когда это контекстное окно заполняется, самые старые сообщения удаляются, чтобы освободить место для новых сообщений. Вот почему контекстное окно и контекстная инженерия очень важны. Потому что, если у нас было много обсуждений туда и обратно об архитектуре нашего приложения, и, скажем, затем у нас возникла проблема с кодом, и мы начали отладку, мы заполним наш контекст всевозможной информацией об отладке, и важное архитектурное обсуждение будет потеряно в какой-то момент, когда контекстное окно заполнится. Так что мы не хотим тратить много времени, рассказывая ИИ-агенту о нашем git-репозитории. Вот почему существуют системные подсказки. Мы говорили об этом в нашем видео по терминологии ИИ, но этот файл agents.md, который мы готовим в фоновом режиме, — это, по сути, системная подсказка. Он будет передан модели и, по сути, будет первой подсказкой в нашем контекстном окне и всегда будет там. Так что все ваши важные архитектурные шаблоны, лучшие практики и проектные решения, вы хотите как бы сохранить это в этой инструкции, чтобы, во-первых, оно никогда не терялось, и вы не заполняли контекстное окно большим количеством обсуждений туда и обратно. Затем вы можете сосредоточиться на проблеме, которую пытаетесь решить. Так что контекстная инженерия — это оптимизация этого контекстного окна. Другое дело, что если мы остановим сеанс и возобновим его на другом компьютере или другой разработчик откроет новый сеанс, они получат согласованность, потому что они будут использовать тот же файл инструкций. Так что это помогает с согласованностью ответов, а также с точностью и пытается минимизировать контекстное окно. Итак, возвращаясь к Open Code, вы можете видеть, что он прочитал кучу файлов. Это все выполнения инструментов, и вы можете видеть, что он думает. Так что он узнает, что этот репозиторий представляет собой коллекцию учебных пособий по Docker и Kubernetes с примерами. Он выясняет, что он происходит из серии YouTube. Он выясняет, что это не развертываемое приложение. Это просто пример исходного кода для серии YouTube. И вот agents.md, который он написал. Так что он, по сути, говорит, о чем этот репозиторий и о чем нет. Структура репозитория. Так что структура каталогов, как работать с этим репозиторием. Говорит о назначении репозитория. Всегда хорошо иметь ИИ-агента, который генерирует этот файл. Затем мы можем внести в него правки, добавить больше контекста и удалить некоторую неуместную информацию, но идея в том, что когда мы начинаем взаимодействовать с ИИ, будь то создание приложения, работа с инфраструктурой как кодом, работа с манифестами Kubernetes, агент будет очень сфокусирован, потому что у него есть системная инструкция, у него есть значения по умолчанию, с чего начать. И вы можете видеть на боковой панели здесь с Open Code, у нас есть информация о контексте. И он показывает, сколько токенов мы использовали. Цель этого agents.md, очевидно, заключается в том, что он будет использовать много токенов для его генерации, но как только у нас будет это, идея в том, что системные подсказки помогают нам снизить общее потребление токенов с течением времени, потому что мы генерируем этот файл только один раз, и ИИ-агент не должен сканировать наш репозиторий каждый раз. Теперь он будет использовать это как основу. В других инструментах, таких как Claude, Gemini и GitHub Copilot, у нас была функция под названием context. Важно знать, что в Open Code ее нет. Была также функция stats, которой у нас нет. Это потому, что у нас есть информация о контексте, отображаемая здесь сбоку. Так что технически нам не нужна эта команда. Другая полезная команда, касающаяся контекста, — это /export, где мы можем экспортировать полную стенограмму сеанса. Так что, если у вас есть очень важное обсуждение, вы можете захотеть экспортировать его. Это означает, что вы можете взять часть этой информации и создать обновленный agents.md или импортировать части этого обсуждения в новый сеанс. У нас также есть другая команда под названием compact, которая, по сути, сжимает наш сеанс, суммируя текущий сеанс. Одна вещь, которая мне нравится в Open Code, — это то, что он следует соглашению agents.md, которое технически является файлом readme для агентов, тот, который мы только что сгенерировали. Идея с agents.md заключается в том, чтобы вместо введения нового проприетарного файла, такого как Claude.md, Gemini.md и один для каждого ИИ-провайдера, они выбрали имя и формат, которые могут работать для кого угодно. Что мне нравится в этом стандарте, так это наличие одного agents.md и направление вашего Claude или GitHub Copilot или Gemini CLI на этот единственный MD, чтобы вы не дублировали все эти MD-файлы, и это делает вашего ИИ-агента очень портативным. Так что контекстная инженерия очень важна, потому что она дает нашему агенту фокус. Она помогает нам с точностью, а также с управлением затратами на токены. Но, как я уже упоминал ранее, CLI — это просто агент, и я люблю называть его основным агентом. Теперь все эти инструменты командной строки, такие как Claude, C-Piler, Gemini или Open Code, все они поддерживают возможность создания так называемых пользовательских агентов или субагентов. И далее мы увидим, почему это так важно, потому что это помогает нам еще больше оптимизировать контекст. Таким образом, интерфейс командной строки, по сути, позволяет пользователю общаться с моделью, отправляя подсказки и получая ответы. CLI или основной агент, по сути, облегчает это. Чтобы дать вам более точное представление, вот как это выглядит. Когда вы вводите подсказки в терминал, CLI действует как основной агент. Он берет системную подсказку и все подсказки, которые вы ему передаете, формируют ваше обсуждение, которое попадает в контекстное окно. Теперь, когда дело доходит до контекстной инженерии, существует несколько проблем. Во-первых, наша системная подсказка может стать очень большой. Наше обсуждение может стать очень большим, что означает, что мы можем заполнить контекстное окно, и большее контекстное окно не обязательно лучше. Это компромисс. Чем больше контекстное окно, тем более расплывчатыми могут стать ответы ИИ. Так что вся суть контекстного окна — держать его маленьким, компактным, держать ваши системные подсказки очень узкими и сфокусированными, что помогает направлять модель и давать ей правильное сфокусированное руководство. Теперь, как я уже упоминал ранее, когда у вас идет важное архитектурное обсуждение с агентом, по мере роста и заполнения контекстного окна, а позже вы можете начать развертывать приложение и затем получать, скажем, ошибки Kubernetes, вы будете устранять неполадки Kubernetes, и все эти подсказки kubectl туда и обратно начнут еще больше заполнять контекстное окно, а наши проектные решения, о которых мы говорили, будут потеряны и удалены из контекстного окна. Вот где субагенты могут действительно помочь, потому что субагенты, по сути, позволяют нам разбить, вместо использования одного основного агента, теперь у нас есть несколько агентов. Так что в моем предыдущем случае, вместо того, чтобы контекстное окно моего основного агента заполнялось проблемами Kubernetes, я мог бы создать агента Kubernetes или агента для устранения неполадок. Как вы можете видеть здесь, у каждого агента есть свои контекстные окна и свои системные подсказки. Так что у меня может быть агент Kubernetes, который специализируется на устранении неполадок и развертывании в средах Kubernetes. У меня может быть агент DevOps или Terraform или инфраструктуры как кода, агент тестирования или QA. И это означает, что когда у меня возникнут проблемы, скажем, с Kubernetes, мой агент Kubernetes может специализироваться на решении этой проблемы и заполнять свое контекстное окно. Это помогает мне сохранить контекстное окно моего основного агента чистым. Теперь Open Code также поддерживает агентов. Как мы узнали, агенты — это специализированные ИИ-помощники, которые могут быть настроены для конкретных задач и рабочих процессов. Важно то, что они более сфокусированы. У них есть свои инструменты, свои системные подсказки или файлы agents.md. У них могут быть свои модели и доступ к инструментам. Теперь, в документации по агентам, когда мы прокручиваем вниз, есть два типа агентов. Основные агенты, которые являются основными помощниками, с которыми вы напрямую взаимодействуете. Это, по сути, когда мы запускаем Open Code в первый раз. Когда вы начинаете с ним разговаривать, вы разговариваете с основным агентом, а затем у вас есть так называемые субагенты, а субагенты — это специализированные помощники. Так что у нас может быть субагент Kubernetes, который работает с кластером, или субагент DevOps, или что-то еще. Теперь, как и другие CLI, основной агент будет решать, когда вызывать конкретный субагент для конкретной задачи. Все это делается путем формулирования вашей подсказки. Так что, если я сформулирую свою подсказку таким образом, что скажу: "Я хотел бы устранить проблему с Kubernetes", основной агент может решить вызвать субагент Kubernetes и передать задачу субагенту. Но эти ИИ-инструменты также предоставляют нам способ вручную или явно вызывать агентов, используя символ @, который мы видели ранее. Так что я могу просто сказать @Kubernetes agent, а затем дать свое конкретное сообщение. Если мы находимся в Open Code CLI, мы можем нажать Tab, чтобы переключить агентов. Вы можете видеть, что в Open Code есть агент сборки и агент планирования. В других CLI, таких как Copilot и Gemini, у нас была команда /plan, чтобы переключиться в режим планирования. В Open Code этого нет. Вам нужно переключаться между агентами. Как вы можете видеть здесь, у меня нет команды plan, но вместо этого у меня есть /agents. И вы можете видеть, что у меня есть агент сборки, который является основным агентом, который CLI использует для взаимодействия. А затем у нас есть агент планирования, на который мы можем переключиться. Так что вы можете просто использовать клавиши со стрелками, чтобы перейти в режим планирования. Теперь немного позже я покажу вам, как создать агента, как и в другом CLI, где мы создавали с помощью файлов markdown. Но Open Code также позволяет нам настраивать агентов, настраивая наш файл open-code.json. Так что мы можем определить агентов в узле agent в JSON. Здесь есть агент сборки и агент планирования, которые мы видели ранее. Вы можете передавать конкретные модели каждому агенту, а также его режим. Это полезно, потому что вы можете использовать более дешевую модель для сборки, а более дорогую модель для планирования. А затем вы можете указать инструменты, к которым вы хотите предоставить доступ каждой модели. Так что здесь вы можете видеть, что агенты сборки и планирования являются основными агентами, а пользовательский агент проверки кода — субагентом. И самый популярный способ создания агентов — использование файлов markdown, аналогично тому, как мы создаем agents.md. Каждый из этих CLI ищет определения агентов в разных местах. В Open Code вы можете поместить свои определения в папку config в вашей пользовательской директории. Вы можете создать папку open-code, а в ней папку agent, или вы можете сделать это для каждого проекта, просто указав это в папке code. И агент всегда начинается со следующего формата. Вы всегда начинаете с MD-файла. Это агент проверки. Так что вы можете видеть его местоположение. Он начинается с синтаксиса форматировщика YAML. Так что он начинается и заканчивается им, а затем у вас есть описание, и обычно у вас есть имя агента. Так что описание и имя, и вы можете иметь пользовательские поля, такие как режим, модель, температура, инструменты и многое другое. Важные поля — это описание и имя агента, а затем содержимое. Так что это определение markdown и инструкции для агента. По сути, как и agents.md, который мы видели ранее, где вы описываете, о чем ваш агент и что он может делать. Теперь в моем репозитории есть папка open-code и папка agents, и здесь у меня есть агент, который мы рассмотрим в этом видео. Это, по сути, агент технического писателя, который помогает мне писать лаконичные сценарии YouTube-производства, а также руководства. Теперь, если вы следили за этой серией, я люблю делать своих агентов портативными. Так что с Gemini, Claude и Copilot у них есть свои места, где они ищут определения агентов. Так что я сделал папку code-agents для агентов Open Code. У меня есть одна для Gemini. У меня есть одна для Claude, и у меня есть одна для GitHub. Но вместо того, чтобы дублировать мои файлы везде, все, что я сделал, — это дал инструкцию, что как агент технического писателя, ваши инструкции находятся в директории agents. Так что вместо создания сложных символических ссылок, чтобы обмануть CLI, я просто создаю эти файлы как прокси-файлы, сообщая агенту, где найти определение моего агента. Так что определение моего агента находится в папке agents, и здесь у меня есть мой агент технического писателя и его файл определения. Вы можете видеть, что у меня есть имя для моего агента и описание. А затем у вас есть markdown, который, по сути, дает вам инструкции для вашего агента. Что мой агент может и не может делать. С определением агента, созданным в директории open-code-agents. Если мы наберем /agents, наш агент автоматически появится в меню выбора агентов. Затем я могу переключиться на своего агента и начать с ним взаимодействовать. Так что, как это работает: когда Open Code запускается, он ищет в директории open-code-agents определения моих агентов. Он обрабатывает эти файлы и включает их в контекст, когда я начинаю использовать этого агента. Так что у моего агента довольно много возможностей. Он имеет возможность планировать новый технический контент из идей, а затем мозговым штурмом и помогать в обучении. Как только у него есть эта информация, он имеет возможность создавать техническое руководство. Как только у него есть руководство, он имеет возможность создавать сценарий производства с углами камеры, временными метками и сценами, а также сценариями. А затем он также имеет возможность развернуть тестовый кластер Kubernetes. Это много инструкций. Это означает, что у вас может получиться гигантская системная инструкция. Так как же мне оптимизировать это еще больше? Так что даже с несколькими субагентами ваш файл инструкций все равно может стать довольно большим. Так что у моего технического писателя есть несколько основных обязанностей. Он может планировать и мозговым штурмом видеоконтент, руководства. Затем он может создавать эти руководства, а также создавать сценарии видеопроизводства, а также предоставлять тестовую инфраструктуру Kubernetes для тестирования этих технических руководств. Но когда вы посмотрите на мой MD-файл, он все еще довольно короткий. Как я оптимизировал это дальше? Я не хочу загружать все эти инструкции каждый раз, когда я взаимодействую со своим агентом, потому что я не буду использовать все возможности агента. Я могу взаимодействовать с ним один раз и мозговым штурмом нескольких идей. Так что, если вы посмотрите на эти основные обязанности или инструкции, вы увидите, что я постоянно ссылаюсь на использование предоставленного доступного навыка. Я поместил это в каждую возможность или обязанность. Так что я, по сути, говорю своему агенту, что ему нужно использовать концепцию под названием навыки, когда ему нужно выполнить конкретную задачу. Так что вместо того, чтобы добавлять все эти инструкции для различных возможностей моего агента в один гигантский markdown, который всегда попадает в контекст, даже когда вы не используете некоторые из инструкций, я решил ссылаться на навыки. Так что я инструктирую своего агента ссылаться на свои возможности, ища конкретные навыки. Теперь, что такое навыки? В двух словах, навык — это просто отдельный файл markdown, который находится в другом месте и загружается по требованию. Это означает, что если у меня есть четыре навыка, но на основе моих подсказок агенту нужен только один из них, он загрузит только этот markdown в контекст. Так что навыки — это, по сути, системные подсказки по требованию. Так что, как мы видели ранее, у меня есть агент с примерно четырьмя возможностями или навыками. Один из них — предоставление тестовой инфраструктуры Kubernetes. Если мне нужно создать инфраструктуру Kubernetes, все, что мне нужно сделать, — это попросить моего агента вызвать этот навык. Так что он загрузит только этот markdown в контекст. Так что мы загружаем в контекст только то, что нужно. Так что это помогает с затратами. Это помогает с точностью и фокусом. Но есть и кое-что еще. Так что Open Code поддерживает навыки агентов, которые являются повторно используемыми определениями markdown. Прежде всего, где разместить файл навыка? Вы можете иметь его на уровне проекта или глобально. Так что мы можем разместить наши навыки в папке skills под директорией open-code или на уровне проекта под директорией open-code. Но есть также глобальный формат, совместимый с агентами, который находится в директории agents. Вы создаете папку skills, за которой следует папка с именем вашего навыка. Это очень важно. Так что каждый навык имеет свою собственную папку, а затем файл skill.md. Важно, чтобы файл skill.md назывался skill.md или в верхнем регистре, и он должен начинаться с форматировщиков YAML. Вам нужно имя для навыка, а также описание. И вот пример навыка. У него есть имя и описание, за которыми следуют инструкции или markdown о том, что такое навык. Так что навыки сначала обнаруживаются, будучи в правильной директории, как показано выше. Так что, если у вас есть навыки в skill.md в правильном месте, вы должны увидеть эти навыки немедленно, набрав /skills. Если вы их здесь не видите, у вас либо опечатка в MD, либо они находятся в неправильном месте. Важно отметить, что навыки обнаруживаются, как я уже упоминал ранее, но весь навык не загружается, что, по сути, означает, что содержимое навыка не загружается в контекст. Вот где навыки становятся действительно мощными. Так что, если мы посмотрим на мою директорию agents, у меня есть папка skills, и здесь у меня есть мои навыки. У меня есть четыре навыка, и здесь у меня есть навык для предоставления локального кластера Kubernetes. Если я разверну его, вы увидите, что у меня есть skill.md. У меня есть обязательные форматировщики YAML. Это важно, иначе ваш навык не появится в списке. У него есть имя, которое также важно и обязательно, а также описание. Важно знать, что в контекст загружаются только данные в форматировщике YAML, когда запускается наш агент. Так что агент имеет только те детали, которые мы видим здесь. У него есть имя и описание. Все детали о моем навыке, которые у меня есть в инструкциях здесь, не загружаются в контекст, если навык не активирован. Это сила навыков. Агент загрузит весь markdown только тогда, когда это потребуется. Так что, если я явно попрошу своего агента предоставить кластер Kubernetes, он загрузит весь файл markdown. И это экономит контекстное окно. Вот почему это очень важно, и я часто вижу эту ошибку. Важно поместить инструкции о том, когда использовать навык, в описание. И здесь я явно указываю использовать навык для предоставления локальных кластеров Kubernetes. Так что, по сути, "когда использовать" должно быть в описании, чтобы агент знал, когда его использовать. "Как использовать" должно быть в инструкциях. И я часто вижу, как люди совершают здесь ошибку. Они добавляют "когда использовать" или "когда активировать" в тело markdown, и это не имеет никакого эффекта. Так что это первое важное, что касается навыков, — это как активировать их при необходимости. Теперь, если вы посмотрите на мой навык, я, по сути, говорю, что навык позволяет агенту предоставлять локальный кластер Kubernetes. Я говорю о требованиях. Так что я говорю, что для предоставления локального кластера вам нужен curl, kind, kubectl и docker cli. Так что это некоторые из зависимостей, которые вам нужны. И тогда я также говорю, что если эти инструменты не установлены, используйте предоставленные скрипты из навыка для их установки. И преимущество навыков в том, что я могу фактически включить папку скриптов. Так что здесь у меня есть скрипты для установки curl, установки docker cli, установки kind и установки kubectl. Вместо того, чтобы встраивать всю эту информацию в файл инструкций, у меня есть осмысленные скрипты. Так что модели, как правило, очень умны, глядя на имена скриптов, зная, что означает скрипт, и модель просто выполнит скрипт. Так что здесь есть несколько преимуществ. Во-первых, я получаю большую точность и согласованный результат. Если я попрошу кластер Kubernetes сегодня или завтра, я получу согласованный результат, потому что я могу тестировать свои скрипты, и модель не угадывает. Так что есть согласованность, но мы также дополнительно оптимизируем контекст, потому что, когда модели нужно выполнить эти скрипты, она не загружает скрипты в контекст. С навыками модель просто заставит агента выполнить скрипты без загрузки скриптов в контекст. Так что, если бы я поместил все эти инструкции в MD-файлы, они попали бы в контекстное окно, и модели пришлось бы выяснять, как установить Docker, как установить kubectl и kind. Во-первых, она могла бы угадать, получить несогласованные результаты, и все это заполнило бы контекстное окно. Так что это круто в навыках. Модель очень хорошо определяет, какие скрипты запускать. Она запустит эти скрипты без загрузки скриптов в контекст. Так что с выбранным агентом я могу просто сказать: "Эй, пожалуйста, предоставь локальный кластер Kubernetes". Затем модель выяснит, нужно ли ей активировать навык. Она увидит, что есть навык для этого, вызовет его и загрузит навык, выяснит, что нужно сделать, и выполнит мои скрипты. Или я могу явно вызвать навык, набрав /skills, а затем выбрать свой навык provisioner и сказать: "Пожалуйста, создайте кластер Kubernetes". Это более явно, потому что я точно говорю модели, что я хочу. Так что я нажимаю Enter. Мы можем видеть, что он ссылается на навык. Он выясняет, что ему нужно проверить, установлены ли инструменты, или нет. Так что он проверит, установлен ли curl, установлен ли kind, установлен ли kubectl, установлен ли docker. Так что вы можете видеть здесь, что он запускает скрипт install kind, устанавливает kubectl, docker cli. Затем он проверяет инструменты. И после проверки того, все ли инструменты установлены и установлены ли они, вы можете видеть, что теперь он наконец запускает наш скрипт create cluster для предоставления нашего локального кластера Kubernetes. Он проверяет, что кластер работает. И здесь вы можете видеть, что наш кластер готов к работе. Чтобы доказать это дальше, я могу перейти в режим оболочки, набрать kubectl get nodes, и наш кластер был успешно создан. Теперь, как правило, при работе с ИИ, модель очень быстро делает выводы. Она быстро предлагает решения. Это означает, что когда вы начинаете инженерию подсказок, я заметил, что ИИ очень быстро придумывает решения и реализацию. Проблема в том, что когда у вас есть сложные решения, вам приходится обмениваться подсказками и ответами, чтобы исправить ИИ-агента и точно сказать ему, что вы хотите с точки зрения лучших практик, безопасности, ваших личных архитектурных предпочтений, какой технологический стек вы любите использовать и тому подобное. Доходит до того, что вы фактически тратите много токенов, обмениваясь сообщениями туда и обратно при создании более крупного решения. Вот почему у многих этих ИИ CLI есть так называемый режим планирования. Теперь, взглянув на документацию Open Code, план — это, как правило, ограниченный режим для планирования и анализа. В режиме планирования, как правило, ИИ-агенты не будут писать новые файлы или редактировать файлы, и они не будут выполнять команды оболочки. Это, как правило, режим только для чтения. Режим полезен, когда вы хотите, чтобы ИИ анализировал код, предлагал изменения, создавал планы без фактического внесения изменений в кодовую базу. Теперь также важно знать, что опция режима для Open Code теперь устарела. Вы также заметите, что в Open Code у нас нет /plan. При взгляде на Gemini Copilot и Claude у нас была команда /plan. В Open Code этого нет. Однако помните, когда я набирал /agents, есть агент сборки и агент планирования. Так что это технически режим планирования для Open Code. Open Code технически встроил свой режим планирования в своего агента. Так что есть два нативных агента, как мы видели ранее. Один называется build, который является основным агентом, с которым вы работаете со всеми включенными инструментами, а затем агент планирования, который ограничен и предназначен для планирования и анализа. Планирование позволяет вам начать планирование вашего нового решения с помощью ИИ. Так что вы можете общаться с ним, и, по сути, вся концепция планирования заключается в создании файла markdown со всем планом, включая ваш технологический стек, лучшие архитектурные практики, проблемы безопасности, чтобы вы могли убедиться, что ИИ создаст наиболее точное желаемое решение, которое вы хотите. Он, как правило, будет создавать план в директории open-code/plans и создавать там файл markdown, который вы можете просмотреть. Как только вы будете довольны планом, вы можете переключиться на нативный агент сборки или свой собственный пользовательский агент и начать сборку. Затем у нас есть еще одна важная тема для инженеров, которую нужно знать, и это называется MCP, что означает Model Context Protocol. MCP позволяет нам взаимодействовать с системами с использованием естественного языка. Так что мы можем начать набирать такие вещи, как "выбрать топ-100 записей из таблицы базы данных" или "перечислить все поды в данном пространстве имен" вместо того, чтобы просить LLM работать со сложной командой, такой как команда kubectl или SQL-запрос. Вместо этого агент перечислит инструменты на сервере MCP и затем просто выполнит их. И Open Code поддерживает серверы MCP. Сервер MCP — это просто бинарный файл. Это технически просто исполняемый файл. Этот исполняемый файл может работать локально. Так что у нас может быть установлен MCP в нашей локальной файловой системе как приложение, или он может работать как веб-сервер. Так что, чтобы привести пример, вы можете добавить GitHub MCP, а затем в вашем интерфейсе командной строки вы можете запрашивать свои pull-запросы или создавать проблемы и взаимодействовать с GitHub. Это, как правило, общение с сервером MCP по HTTP. Но у вас также может быть он запущен как бинарный файл локально, что-то вроде MCP для Kubernetes или Docker, который общается с вашим сервером Docker или вашим кластером Kubernetes. Это важно знать, потому что команды могут обращаться к вашей инженерной команде с просьбой запустить собственные серверы MCP, и они могут быть размещены на веб-серверах, запускающих такие вещи, как Python, Flask или NodeJS или .NET, и вы можете разместить их за ingress или API-шлюзом. Так что вам нужно обеспечить аналогичную защиту для веб-сервера HTTPS. Теперь серверы MCP включены в вашу конфигурацию Open Code. Так что в вашем файле open-code.json есть раздел для MCP, и здесь вы можете определить все серверы MCP, и вы можете включать или отключать их. Так что мы можем добавить MCP напрямую в JSON-файлы, если захотим. Так что я могу установить локальный сервер MCP, который позволяет нам общаться с нашим кластером Kubernetes. Теперь существует тысячи различных типов серверов MCP, и каждый из них имеет свой собственный метод установки. Большинство из них доступны на npm. Так что npm install mcp-server-kubernetes. Я запускаю это, и это установит локальный сервер MCP для Kubernetes, и я могу добавить это определение в свой файл open-code.json, и наш CLI сможет начать вызывать эти инструменты MCP. Итак, вот оно. Он установил его. Теперь, возвращаясь к Open Code, обычно эти инструменты командной строки ИИ имеют /mcp. Теперь, если мы вызовем это, вы увидите, что в настоящее время не найдено ни одного MCP. Это потому, что мы установили только бинарный файл. Мы не настроили JSON. Так что у него есть только механизм для переключения MCP. Я не могу сказать MCP add или list или что-то в этом роде. Так что, чтобы добавить MCP в Open Code, это немного отличается. Вы выходите. И на самом деле есть подкоманда Open Code. Так что, если я наберу open-code --help, вы увидите, что есть подкоманда MCP для управления серверами MCP. Так что я могу сказать open-code mcp --help. И вы можете видеть здесь, что мы можем добавлять, перечислять и, по сути, настраивать серверы MCP. Так что я могу сказать mcp add. Нажимаю Enter. Он спросит меня имя. Я могу просто сказать Kubernetes. Здесь вы можете выбрать, является ли это удаленным HTTP-сервером. Помните, я сказал, что MCP могут быть размещены за веб-сервером. В данном случае это просто локальный. Затем вам нужно предоставить документированную команду о том, как запустить сервер MCP. Это команда, найденная на их веб-сайте. И MCP теперь успешно добавлен. Я могу сказать open-code mcp list. И мы видим, что сервер MCP работает. Kubernetes работает и подключен. Затем я могу вернуться в Open Code. Теперь я могу сказать /mcp. И вы можете видеть, что сервер MCP прямо здесь. Так вот как вы добавляете и управляете серверами MCP в Open Code. Мы также можем увидеть, что он сделал, войдя в режим оболочки и просто набрав cat на нашей конфигурации. И здесь вы можете видеть, что он добавил новый сервер MCP под названием Kubernetes. Тип — локальный, и это стандартный формат, которому следуют все CLI. И при выполнении и использовании MCP, вам либо нужно быть очень конкретным в своей подсказке, если у вас более дешевая модель, но, как правило, последние модели очень хорошо понимают, что вы хотите сделать, и ваше намерение, и они вызовут эти инструменты MCP. Затем я могу сказать своему техническому писателю, используя MCP, перечислить пространства имен в нашем локальном кластере Kubernetes. Иду и запускаю это. Вы можете видеть, что он делегирует, и он перечислил пространства имен в нашем локальном кластере Kubernetes успешно. Так что мне действительно нравится в Open Code то, что у него чрезвычайно низкий порог входа. Вам не нужны никакие учетные записи, никаких платных подписок, и у вас есть гибкость повторного использования ваших существующих провайдеров. Так что, если у вас есть существующий план оплаты с провайдером, вы можете использовать его. Терминал очень настраиваемый, и круто то, что как инженер, вы также можете исследовать локальные модели. Так что вы можете начать смотреть на такие вещи, как Gemma 4 и другие новые модели. Так что вы можете запускать ИИ бесплатно на своей рабочей станции. Дайте мне знать в комментариях ниже, какой ваш любимый терминал ИИ. Если вам понравилось видео, обязательно поставьте лайк, подпишитесь, нажмите на колокольчик. Не забудьте проверить ссылку ниже на дорожную карту Ultimate DevOps и как следовать ей. И если вы хотите поддержать канал еще больше, нажмите кнопку "Присоединиться" ниже, чтобы стать участником YouTube. И, как всегда, спасибо за просмотр, и до следующего раза, мир.