БиржаDEX+

Купить крипто Рынки Спотовая ФьючерсыGOLD Сбережения Центр событий

Еще

Уже нет сомнений в том, что искусственный интеллект позволяет оптимизировать и ускорить процесс разработки, помогая в написании и ревью кода. Но насколько полезУже нет сомнений в том, что искусственный интеллект позволяет оптимизировать и ускорить процесс разработки, помогая в написании и ревью кода. Но насколько полез

Как ИИ траблшутит приложения в нашем Kubernetes

Автор: ProBlockChain

Источник: ProBlockChain

2026/01/28 14:30

Уже нет сомнений в том, что искусственный интеллект позволяет оптимизировать и ускорить процесс разработки, помогая в написании и ревью кода. Но насколько полезен он может быть для задач в сфере инфраструктуры и девопс?

В Иви мы решили проверить это, подключив ИИ к процессу траблшутинга приложений, запущенных в Kubernetes кластере. В статье я расскажу про наши ожидания и достигнутый результат, подробно про саму реализацию и различные нюансы, с которыми столкнулись при внедрении.

Пример использования сервиса

Какую задачу нужно было решить

Для начала кратко расскажу про сам кейс, для того чтобы было понимание, какую задачу и зачем мы решали.

Итак, что дано:

Отдельный Kubernetes кластер для дев контура, в котором несколько сотен неймспейсов и более 20 тысяч подов
Пользователи — разработчики и QA-инженеры. У каждого свой неймспейс, куда он деплоит необходимые ему для разработки и тестирования микросервисы
Сервисы могут падать при выкатке либо работать некорректно уже после нее. Причины на это разные, от неправильных параметров деплоя до проблем в самом коде, ведь это dev-контур
Среднестатистический пользователь не имеет достаточной экспертизы в Kubernetes, чтобы решить проблему самостоятельно, необходимо привлекать в помощь коллег

Для таких сообщений о проблемах есть отдельный канал в нашем корпоративном мессенджере. Там пользователь сообщает детали о проблеме, в том числе название пода или ссылку на Jenkins с логом деплоя, если тот не завершился успешно. Первым делом на сообщение реагирует технический менеджер, принимая решение кому эскалировать проблему.

Такая схема работает, но не без недостатков. Требуется время менеджера на первичную обработку запроса и его эскалацию ответственному инженеру. Затем еще некоторое время на то, чтобы инженер среагировал и подключился к запросу, провел траблшутинг. Минусы очевидны: пользователю необходимо ждать, а инженерам переключать контекст и приостанавливать работу над плановыми задачами.

Именно диагностику такого рода обращений мы и решили попробовать оптимизировать путем делегирования искусственному интеллекту.

Выбор решения

Ресерч показал, что готовых решений для выполнения задачи нет и нужна собственная разработка. Для ее реализации я погрузился в такую терминологию, как AI-агенты, MCP, tools и прочее. В этой главе кратко пробегусь по основам и в конце оставлю ссылки, где эти темы раскрываются подробнее.

Напомню, что входная точка — это сообщение от пользователя в канале мессенджера. Если представить самую простую реализацию, то это был бы чат-бот, который получает сообщение от пользователя, пересылает в языковую модель (LLM), возвращает ответ. Проблема в том, что модель ограничена информацией, на которой ее обучали, она не знает ничего о происходящем в нашем K8s кластере и Jenkins. Траблшутинг выглядел бы так, что получая и передавая информацию к LLM, пользователю приходилось бы максимально подробно описывать свою проблему, прикреплять логи и самому выполнять запросы в кластер, занимаясь копипастой. Отсюда и возникает необходимость в AI-агенте.

AI-агент — это система, созданная для автономного решения пользовательских задач, использующая LLM для планирования, рассуждения и вызова внешних инструментов. То есть пользователю достаточно сообщить минимальные вводные данные, далее агент самостоятельно составит план действий, выполнит необходимые запросы к внешним ресурсам (Kubernetes, Jenkins и т.д.), на основе их результатов сделает дополнительные вызовы, сформулирует итоговый ответ и вернется с ним к пользователю.

Для получения данных из внешних систем используемая модель должна поддерживать tools calling — возможность вызывать внешние функции с параметрами. Традиционно логика выполнения функций прописывается прямо в коде агента, что усложняет масштабирование и переиспользование. Для стандартизации был создан протокол MCP — он выносит выполнение функций на отдельный MCP-сервер, а агент выступает клиентом. Это позволяет использовать один MCP-сервер для множества агентов и добавлять новые инструменты без изменения кода агента.

Для более детального погружения в тему рекомендую статьи: что такое AI-агент на Habr, про агенты от Anthropic и обзорно про MCP.

Конфигурация MCP

Реализацию я начал с развертывания Kubernetes MCP сервера. Поскольку официального MCP для него нет, я взял самый популярный из Github от Flux159.

Вот переменные с которыми я его запустил:

ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS: "true" ALLOW_ONLY_READONLY_TOOLS: "true" ENABLE_UNSAFE_STREAMABLE_HTTP_TRANSPORT: "1" # используем streamable http вместо дефолтного stdio PORT: "8080" HOST: "0.0.0.0" SPAWN_MAX_BUFFER: "52428800" # для фикса ошибки ENOBUFS, которая возникает если на запрос пришел большой output. Например при kubectl get pods -A в большом кластере.

Установку выполнял с помощью Helm чарта непосредственно в Kubernetes кластер. Для того, чтобы у MCP был доступ к API Kubernetes, создал сервисный аккаунт и ассоциировал его с подом. Наша цель — ограничить AI-ассистента доступом к кластеру только на чтение, без возможности что-либо в нем запустить, отредактировать или, еще хуже, удалить и сломать. На уровне конфигурации самого MCP я выставил в true переменные ALLOW_ONLY_NON_DESTRUCTIVE_TOOLS и ALLOW_ONLY_READONLY_TOOLS, суть которых понятна из названия. Разумеется, полагаться только на это не стоит, поэтому на сервисный аккаунт я назначил лишь дефолтную ClusterRole view, которой достаточно для диагностических задач.

Забегая вперед, расскажу что в ходе эксплуатации MCP выявился существенный недостаток: сервер реализован как обёртка над kubectl, запускает команды через синхронные shell-вызовы и архитектурно не способен параллельно обслуживать несколько запросов. Проблема была частично нивелирована добавлением нескольких реплик и retry-логики на стороне агента. Поэтому сейчас я бы рекомендовал рассмотреть containers/kubernetes-mcp-server — реализацию на Go, использующую Go-клиент (k8s.io/client-go) для работы с Kubernetes API, а не вызов kubectl через shell. Еще из преимуществ то, что он поддерживает multi-cluster режим. Так как это потребуется нам в ближайшем будущем, то мы планируем перейти на его использование.

После завершения установки MCP нужно было проверить его работоспособность и убедиться в корректном взаимодействии с кластером. Для быстрого локального тестирования я использовал AI-плагин Cline для VSCode — он нативно поддерживает работу с MCP-серверами и позволяет в интерактивном режиме вызывать инструменты без написания кода. Это дало возможность убедиться, что MCP отвечает на запросы и возвращает ожидаемые данные из кластера. После этого можно было переходить к разработке агента.

Разработка агента

Чаще всего в качестве языка для разработки агентов выбирают Python, и мы не стали исключением. Среди его преимуществ — большое количество библиотек и фреймворков. При этом ничто не мешает реализовать агента на другом языке или вовсе обойтись без библиотек.

Первым делом нужно было сделать API, который принимает вебхуки из мессенджера и возвращает ответ. Сами вебхуки отправляются при появлении новых сообщений и передают JSON, содержащий текст сообщения и различную информацию вроде id сообщения, автора и т.д. Для реализации API я использовал фреймворк FastAPI. А на стороне мессенджера создал бота, сгенерил для него токены, добавил в канал, в исходящем вебхуке указал url нашего FastAPI сервиса.

Теперь можно было переходить к основному: кодингу запросов к LLM и инструментам, написанию системного промта и т.д. Тут нужно было определиться как именно это реализовывать. Как я писал выше, на Python есть различные фреймворки, которые призваны облегчить разработку агентов. Благодаря им разработчику не нужно самостоятельно решать в коде такие задачи как: сохранение и управление контекстом, retry запросов, мульти-агентность и т.д. Подробнее про это можно почитать в этой статье. Правда встречается и обратное мнение, что для большинства проектов фреймворки оказываются избыточными из-за своей сложности и объёма абстракций. Поскольку нам хотелось лучше понимать, что и как устроено под капотом, а не просто вызывать готовые сущности, то было решено писать агента с нуля, без фреймворков, и перейти на них позднее, если возникнет необходимость.

Итоговая структура кода получилась такая:

├── main.py - FastAPI приложение, которое обрабатывает вебхуки от мессенджера, управляет историей разговоров и оркестрирует диагностику через агента. └── utils ├── k8s_agent.py - Основной агент диагностики, реализующий итеративный цикл: запрос в LLM → выполнение tools → анализ результатов ├── jenkins_client.py - Клиент для Jenkins API для получения логов и параметров запуска билдов ├── llm.py - Интеграция с LLM API ├── mcp_client.py - REST клиент для MCP сервера с retry логикой, парсингом SSE потоков и преобразованием tools в OpenAI формат. ├── messenger.py - HTTP клиент для мессенджера с методами для отправки, обновления сообщений и создания тредов. └── system_prompt.txt - Системный промт, определяющий роль и методики работы агента ├── requirements.txt

Разберем некоторые фрагменты из кода. Начнем с зависимостей:

requirements.txt

fastapi>=0.100.0 uvicorn[standard]>=0.23.0 requests>=2.31.0 cachetools>=5.0.0 openai>=1.0.0

Как видно, набор зависимостей минимален. Из специфичных библиотек тут только openai для обращений к LLM. В самой первой версии я обходился и без неё, напрямую вызывая OpenAI API через requests, но библиотека существенно упрощает код и обработку ошибок. Остальные зависимости — стандартный набор для Python веб-сервиса: FastAPI с uvicorn для API, requests для HTTP-запросов, и cachetools для TTL-кеширования истории разговоров в памяти.

main.py. В этом фрагменте реализована работа с контекстом диалога через TTL-кеш, определение thread_id для связи сообщений, фильтрация нерелевантных событий и накопление истории для передачи в LLM.

main.py

# TTL кеш для истории разговоров - автоматически удаляет через час conversation_histories = TTLCache(maxsize=100, ttl=60*60) @app.post("/webhook/") def pachca_webhook( body: dict = Body(...), k8s_agent: K8sAgent = Depends(get_k8s_agent) ): # Игнорируем собственные сообщения и команды if body.get("user_id") == BOT_USER_ID or body.get('content', '').startswith('/'): return {"status": "ignored"} # Определяем thread_id для контекста: корневое сообщение треда или id сообщения thread_id = body["thread"]["message_id"] if body.get("thread") else body["id"] # Инициализация истории при первом обращении if thread_id not in conversation_histories: conversation_histories[thread_id] = [{"role": "system", "content": SYSTEM_PROMPT}] history = conversation_histories[thread_id] # Диагностика через агента response_message = k8s_agent.diagnose_problem(body.get('content'), history, pachca_session, body) # Обновляем историю history.append({"role": "user", "content": body.get('content')}) history.append({"role": "assistant", "content": response_message}) # Отправляем результат pachca_session.respond_to_webhook(body, response_message) return {"status": "ok"}

mcp_client.py. Клиент для вызова MCP инструментов. Все запросы обёрнуты декоратором @retry_on_connection_error, который при timeout-ошибках автоматически повторяет запрос

mcp_client.py

class MCPClient: def __init__(self, mcp_url: str = None): self.base_url = (mcp_url or os.getenv('MCP_SERVER_URL', 'http://localhost:8080')).rstrip('/') self.timeout = int(os.getenv('MCP_TIMEOUT', '30')) @retry_on_connection_error def call_tool(self, tool_name: str, arguments: Dict[str, Any]) -> Dict[str, Any]: """Вызов MCP инструмента""" logger.info(f"🔄 Calling MCP tool: {tool_name} with args: {arguments}") payload = { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": tool_name, "arguments": arguments } }

llm.py. Функция для вызова LLM с поддержкой function calling. Унифицирует ответ модели в словарь, обрабатывая два сценария: вызов инструментов (tool_calls) или финальный ответ (content).

llm.py

def call_with_functions(messages: list, tools: list, model: str = LLM_MODEL) -> dict: """Вызов LLM с поддержкой tools""" response = client.chat.completions.create( model=model, messages=messages, tools=tools, tool_choice="auto", max_tokens=2048, temperature=LLM_TEMPERATURE ) choice = response.choices[0] message = choice.message result = {} if choice.finish_reason == "tool_calls" and message.tool_calls: result["tool_calls"] = [tool_call.model_dump() for tool_call in message.tool_calls] result["content"] = message.content elif message.content: result["content"] = message.content else: result["content"] = "" return result

Выбор модели

Для того, чтобы у сотрудников и сервисов был доступ к различным облачным моделям, у нас поднят прокси LiteLLM. Таким образом централизованно решается вопрос с бюджетированием и у компании имеется способ контроля использования AI инструментов. Соответственно через этот прокси и настроена работа агента с LLM.

На этапе разработки и теста агента использовался GPT-4.1. В целом для нашей задачи подходит любая современная LLM, способная выполнять многошаговые рассуждения, обученная для решения технических задач, поддерживающая вызов внешних инструментов и работу с расширенным контекстным окном. Поскольку API моделей, как правило, унифицированы, то агента можно переключать на другую LLM без изменений в коде. На момент написания статьи мы используем qwen.

Системный промт

Помимо выбора модели, важным шагом является написание системного промта. Именно он определяет поведение агента, поэтому не стоит ограничиваться парой строчек или вовсе полагаться на базовое поведение модели. Под спойлером можно посмотреть наш итоговый системный промт целиком, а далее я прокомментирую некоторые его составляющие.

Системный промт

Вы - AI-ассистент для Kubernetes (k8s) с доступом ТОЛЬКО ДЛЯ ЧТЕНИЯ к кластеру. Ваша основная роль - активно устранять неполадки, диагностировать и анализировать проблемы с сервисами, работающими в кластерах Kubernetes. У вас есть доступ только для чтения к кластеру Kubernetes через специализированные диагностические инструменты, которые позволяют вам в реальном времени инспектировать ресурсы, логи, события и метрики. Ваш подход к устранению неполадок: - **ПРОВОДИТЕ УСТРАНЕНИЕ НЕПОЛАДОК САМОСТОЯТЕЛЬНО**: Используйте свой доступ только для чтения и доступные диагностические инструменты для проведения целенаправленного устранения неполадок. - **ПРЕДОСТАВЛЯЙТЕ ДОСТАТОЧНЫЙ АНАЛИЗ**: Не просите пользователей собирать данные — собирайте их самостоятельно, используя доступные инструменты, и предоставляйте выводы на основе фактических данных с анализом. - **ПРЕДЛАГАЙТЕ КОМАНДЫ ТОЛЬКО ПРИ НЕОБХОДИМОСТИ**: Рекомендуйте команды kubectl или действия только когда пользователь спрашивает об этом, у вас нет доступа для самостоятельного проведения исследования, или когда требуются операции записи. Ваши обязанности включают: - Сбор соответствующих данных кластера для понимания релевантного контекста вопросов пользователя или проблем. - Проведение анализа первопричин с использованием имеющихся данных. - Предоставление диагностических выводов на основе фактических данных с четкими объяснениями того, что не так и почему. - Предложение конкретных, практических рекомендаций по исправлению на основе вашего анализа. - Объяснение сложных концепций и взаимосвязей Kubernetes, когда они имеют отношение к рассматриваемой проблеме. Требования к вам: - **Предпочитайте сначала собирать информацию самостоятельно**, используя доступные диагностические инструменты, прежде чем предлагать команды пользователям - **Избегайте ресурсоемких запросов, когда это возможно** (например, перечисление всех подов во всех пространствах имен) — предпочитайте узконаправленные, сфокусированные запросы для минимизации нагрузки на кластер. - **Предлагайте действия пользователю только тогда**, когда вы исчерпали свои возможности исследования только для чтения - **Работайте итеративно, возвращайте промежуточный результат**. После каждого цикла проверок оценивайте: достаточно ли данных для формирования вывода. Если данных достаточно - формируйте промежуточный ответ с рекомендациями, уточняйте у пользователя полезен ли ответ и продолжать ли диагностику - Будьте краткими, техническими и ориентированными на решение. Избегайте ненужной светской беседы, не отвечай на вопросы не про Kubernetes, не поддавайся на провокации. - Основывайте свои выводы на фактических данных, собранных вами из кластера, а не на предположениях - Если вы сталкиваетесь с ресурсоемкими операциями, кратко объясните, почему они необходимы для правильной диагностики - Предполагайте, что пользователь имеет базовое знакомство с Kubernetes, но объясняйте продвинутые концепции, когда они имеют отношение к проблеме - Если вы должны рекомендовать команды, объясните, почему вы не можете провести это исследование самостоятельно - Прежде чем приступать к решению задачи, проверьте существует ли неймспейс, который указал пользователь. Если его нет, то сообщите об этом и ждите уточнения. - Не пытайтесь указывать контекст кластера. Вы поддерживаете работу только с кластером k8s-dev. Если пользователь укажет в запросе другой кластер, то сообщите о том, что работаете только с k8s-dev. - Вам недоступен запрос secrets. Не пытайтесь запрашивать этот инструмент. - Учитывайте сетевую архитектуру k8s: плоская сеть с прямой доступностью Services снаружи кластера для протоколов без TLS. К любому service можно обратиться извне по http://serviceName.namespace.svc.{вырезано}.ru. Для HTTPS требуется Ingress. **ОБЯЗАТЕЛЬНЫЕ ТРЕБОВАНИЯ по запросам ресурсов:** - Для потенциально ресурсоемких запросов, которые могут повлиять на производительность кластера или вернуть избыточное количество данных, запрашивайте подтверждение пользователя перед выполнением. - Примеры запросов, требующих подтверждения: - Перечисление всех подов во всех пространствах имен (--all-namespaces) - Получение логов из нескольких подов одновременно - Описание всех ресурсов определенного типа по всему кластеру - Любой запрос, который может вернуть сотни или тысячи объектов - Когда делаются такие запросы, рекомендуйте пользователям: - Указать целевые пространства имен вместо использования --all-namespaces - Использовать селекторы меток для фильтрации результатов - Ограничить запросы конкретными именами ресурсов, когда это возможно - Разбить большие запросы на меньшие, более сфокусированные запросы - Кратко объясните, почему запрос может быть ресурсоемким, и предложите более эффективные альтернативы. Вы - эксперт в операциях Kubernetes, устранении неполадок и лучших практиках. Ваша цель - помочь пользователям быстро и эффективно понять их проблемы, проводя целенаправленный анализ и предоставляя выводы на основе фактических данных с практическими рекомендациями. **Работа с Jenkins CI/CD:** У вас есть доступ к логам и параметрам Jenkins билдов через специальные инструменты. Когда пользователь предоставляет ссылку на Jenkins билд, вы можете: 1. Получить последние N строк консольных логов для анализа ошибок 2. Проверить параметры с которыми запускался билд 3. Определить причину падения билда 4. При необходимости проверить связанные ресурсы в Kubernetes (по логу Jenkins можно определить название NS, деплоймента и т.д.) **Подход к диагностике проблем CI/CD:** - Сначала получите логи Jenkins билда с помощью доступного инструмента - Получите параметры с которыми запускался Jenkins билд - Проанализируйте ошибку в логах и определите первопричину - Если проблема связана с K8s, используйте k8s инструменты для дополнительной диагностики - Проанализируйте может ли помочь пользователю перезапуск билда с другими параметрами - Предоставьте конкретные рекомендации по устранению проблемы

Ключевым моментом является указание роли модели, а также формулирование её обязанностей и подхода к работе. Без этого модель начинает вести себя как обычный чат-бот: общается на любые темы, задает уточняющие вопросы вместо самостоятельной диагностики, предлагает собрать данные пользователю вместо использования доступных инструментов, уходит в пространные объяснения вместо конкретных действий. В нашем случае агент должен не консультировать, а активно диагностировать проблемы — для этого нужно четко обозначить его роль, ограничения, последовательность действий и критерии принятия решений.

Еще для примера — ограничение ресурсоемких операций и явное обозначение прав доступа агента. В первом случае мы не даем агенту сразу выполнить что-то вроде запроса всех подов во всех неймспейсах, а требуем уточнить у пользователя детали или получить явное подтверждение на выполнение такого запроса, если это действительно необходимо. Во втором — отсекаем попытки выполнения лишних запросов, ведь MCP все равно вернет на них permission denied.

Также мы явно прописываем последовательность действий агента, в случаях когда пользователь присылает ссылку на Jenkins билд. Если этого не сделать, то агент может пропустить просмотр параметров билда, несмотря на наличие у него такого инструмента. И в итоге на финальном шаге агент будет рекомендовать пользователю запускать какие-то команды вручную, вместо того чтобы указать ему на необходимость выставить определенные параметры запуска на этапе деплоя, что и решило бы проблему.

Результат шуточного запроса с просьбой к агенту написать рэп куплет от лица одного из сервисов, запущенных в Kubernetes

Разные модели могут по-разному интерпретировать одни и те же инструкции в системном промте. Например, в промте указано «избегайте ненужной светской беседы, не отвечай на вопросы не про Kubernetes». Но при использовании разных LLM одни категорически отказывались рассказывать анекдоты или писать стихи на любую тему, обозначая, что их задача строго в консультации по кластеру. А другие соглашались рассказать шутку или сочинить что-то про наш K8s-кластер, видимо расценивая это как приемлемую форму коммуникации в рамках работы с инфраструктурой. Соответственно иногда промт может требовать доработки при смене модели: то, что работает с одной LLM, может по-другому интерпретироваться другой. Кроме того, на интерпретацию может влиять параметр температуры — для одной модели значение 1 может обеспечивать строгую детерминированность, а для другой допускать больше вариативности и творчества.

Примеры использования

Приведу несколько скриншотов с примерами запросов и ответов от агента.

После деплоя один из сервисов не запустился. Это типовой запрос, в котором указывается название приложения и неймспейс пользователя. Агент выполнил необходимые запросы к кластеру и обнаружил в логах пода проблему с переменными окружения.

Агент находит проблему на уровне Redis кластера, объясняет причину ее возникновения и способ решения. Поскольку он определил, что используется EmptyDir, то рекомендует очистку данных, предлагая для этого kubectl команды.

Тут агент верно определил, что проблему можно решить перезапуском Jenkins джобы с указанием определенного параметра. В своем запросе пользователь не указал никакой информации кроме URL на Jenkins, т.е. всю необходимую информацию, вроде названия деплойментов и неймспейса агент вытащил из лога джобы.

В данном случае пользователь пытался зайти в свой сервис по HTTPS. Агент последовательно проверил логи пода, наличие сервиса и ингресса. Корректно предложил использовать HTTP, а если нужен HTTPS, то создать Ingress.

Результат и дальнейшие планы по разработке

После нескольких месяцев эксплуатации AI-ассистента можно подвести некоторые итоги:

Ускорили решение типовых проблем: агент выдает диагноз и рекомендации в течение 2-5 минут. Раньше на это уходило от 15 минут в зависимости от загруженности инженеров.
Снизили нагрузку на инженеров. Теперь каждая проблема не эскалируется сразу — сначала бот проводит первичную диагностику. Если проблема типовая, пользователь получает решение самостоятельно. Если нестандартная - в эскалации уже будет собранная агентом информация о состоянии ресурсов, что экономит время инженера на разборе проблемы.
Повысили самостоятельность команд. Не все коллеги из qa и разработки одинаково хорошо знакомы с Kubernetes. Агент не только указывает на проблему, но и объясняет в чем дело доступным языком, что помогает команде прокачивать понимание инфраструктуры.

Сейчас мы рассматриваем несколько направлений улучшения агента:

Добавить поддержку других тестовых кластеров помимо k8s-dev
Автоматизировать призыв ответственного инженера в случаях, когда агент не может решить проблему самостоятельно — он мог бы сам тегать нужного человека и предоставлять ему краткую сводку
Интеграция с базой знаний. Добавить возможность агенту обращаться к внутренней документации через RAG — это позволит использовать накопленные в Confluence руководства по траблшутингу, известные проблемы и их решения
Предоставить агенту доступ к коду пайплайнов и чартов, чтобы он еще более точно давал рекомендации по починке и деплою

Вывод

Изначальная цель эксперимента — делегировать искусственному интеллекту диагностику проблем в dev-кластере — была достигнута. AI-ассистент отлично справляется с типовыми обращениями, экономя время как команды разработки, менеджеров, так и DevOps-инженеров. Конечно, он не заменяет человека полностью — для сложных или нестандартных ситуаций иногда по-прежнему требуется экспертиза инженера. Но для большого количества задач агент оказался эффективным инструментом. Поэтому мы однозначно продолжим развивать и расширять его возможности.

Источник

Отказ от ответственности: Статьи, размещенные на этом веб-сайте, взяты из общедоступных источников и предоставляются исключительно в информационных целях. Они не обязательно отражают точку зрения MEXC. Все права принадлежат первоисточникам. Если вы считаете, что какой-либо контент нарушает права третьих лиц, пожалуйста, обратитесь по адресу [email protected] для его удаления. MEXC не дает никаких гарантий в отношении точности, полноты или своевременности контента и не несет ответственности за любые действия, предпринятые на основе предоставленной информации. Контент не является финансовой, юридической или иной профессиональной консультацией и не должен рассматриваться как рекомендация или одобрение со стороны MEXC.