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 поддерживает режим оболочки, нажимая символ восклицательного знака. Вы можете видеть, что режим переключился на оболочку. И мы можем делать такие вещи, как 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 в правильном месте, вы должны увидеть эти навыки немедленно. Если вы их здесь не видите, у вас либо опечатка в вашем 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, а затем выбрав свой навык подготовки и сказав: "Пожалуйста, создай кластер 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 и другие новые модели. Так что вы можете запускать ИИ бесплатно на своей рабочей станции. Дайте мне знать в комментариях ниже, какой ваш любимый терминал ИИ. Если вам понравилось видео, обязательно поставьте лайк, подпишитесь, нажмите на колокольчик. Не забудьте проверить ссылку ниже на полную дорожную карту DevOps и как следовать ей. И если вы хотите поддержать канал еще больше, нажмите кнопку "Присоединиться" ниже, чтобы стать участником YouTube. И, как всегда, спасибо за просмотр, и до следующего раза, мир.