> ## Content Index
> Fetch the complete content index at: https://matveev.tech/llms.txt
> Use this file to discover other available public pages before exploring further.

# Почему CLI-инструменты снова стали важны? Теперь ими пользуются AI-агенты
- URL: https://matveev.tech/cli-instrumenty-dlya-ai-agentov-cloudwatch-insights-img4-diagram-in-text/
- Published: 2026-05-01T14:43:38.000Z
- Updated: 2026-05-01T14:43:38.000Z
- Description: AI-агенты вроде Claude Code хорошо работают с CLI. Разбираю пример CloudWatch Insights tool и почему иногда обычный терминальный интерфейс лучше MCP.
- Author: Pavel Matveev
- Tags: AI, Агенты, Dev Tools, Claude Code, Разработка, Мнение

Я всё чаще ловлю себя на странной мысли: хорошие внутренние CLI-инструменты стали ценнее, чем были пару лет назад.

Раньше это была история про удобство разработчика. Сделал себе маленькую утилиту, чтобы не кликать в AWS-консоли, не вспоминать длинную команду или не собирать jq-пайплайн. Удобно, но локально. Твой личный костыль, максимум — инструмент для команды.

С AI-агентами эта логика поменялась. CLI теперь не только для человека. Им может пользоваться Claude Code, Codex, OpenCode или любой другой агент, которому ты доверил терминал.

## Маленький пример: CloudWatch Insights без консоли

На Hacker News сегодня увидел пост Мартина Скэгедала про его `cloudwatch-insights` tool. Это небольшая CLI-утилита для работы с AWS CloudWatch Insights.

Вместо того чтобы идти в AWS-консоль, выбирать log groups, настраивать time range и копировать запросы руками, ты запускаешь команду из репозитория нужного сервиса:

```bash
cd ~/code/some-service
cloudwatch-insights query --new --env prod
```

Инструмент берёт конфигурацию из контекста проекта: какие log groups использовать, какой app filter подставить, какой env выбран. Потом создаёт query-файл, открывает его в `$EDITOR`, запускает запрос и сохраняет результат локально в JSONL.

То есть вместо “зайди в консоль, найди нужный сервис, найди нужные логи, отфильтруй ошибки” получается воспроизводимый workflow:

```bash
cloudwatch-insights query --new --env prod
cloudwatch-insights show
```

А вот так это может использовать агент:

```bash
claude -p 'Run "cloudwatch-insights show" and fix the errors.'
```

## CLI становится интерфейсом для агента

Мы привыкли думать про CLI как про интерфейс для человека. Человек читает help, запускает команду, смотрит вывод, принимает решение.

Но агенту такой интерфейс тоже подходит.

У CLI есть несколько свойств, которые внезапно стали очень полезными:

- команды можно выполнять из терминала;
- результат можно сохранить в файл;
- вывод можно передать в модель;
- поведение проще повторить;
- действия легче логировать и проверять.

Для AI-агента это почти идеальная поверхность. Не надо учить его кликать по консоли. Не надо делать скриншоты. Не надо объяснять, где в AWS находится нужная кнопка.

Дай команду. Получи текст. Разбери результат. Предложи фикс.

## А как же MCP?

Тут легко уйти в привычный рефлекс: если нужно подключить агента к инструменту, значит нужен MCP-сервер.

MCP хорош, когда нужен явный контракт: список тулов, схемы аргументов, permissions, discovery, интеграция с разными клиентами. Если ты делаешь инструмент для внешних пользователей или хочешь нормальную агентскую инфраструктуру, MCP выглядит логично.

Но для внутренних workflows иногда обычный CLI проще.

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

Это не аргумент против MCP. Скорее напоминание, что MCP не должен становиться рефлекторным ответом на любую задачу.

Иногда лучший инструмент для агента — это маленькая команда, которая хорошо делает одну вещь.

## Что это меняет для разработки внутренних инструментов

Если принять, что CLI будут использовать не только люди, но и агенты, меняется дизайн таких утилит. Хороший CLI для агента должен быть чуть более аккуратным, чем скрипт для себя.

Во-первых, вывод должен быть машинно-читаемым. JSONL, JSON, понятные exit codes, стабильные поля. Красивые таблички удобны человеку, но агенту проще работать с данными.

Во-вторых, команды должны быть предсказуемыми. Если `show` сегодня показывает последние результаты, а завтра внезапно открывает интерактивный pager, агент сломается. Человек разберётся. Агент начнёт делать странное.

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

В-четвёртых, полезны dry-run режимы. Агент может сначала показать, что собирается сделать, а человек уже подтвердит.

И наконец, help должен быть нормальным. Не для красоты. Модели реально читают `--help` и README, когда пытаются понять, как пользоваться инструментом.

## Что можно сделать у себя

Я бы начал не с MCP-сервера и не с большой платформы автоматизации. Начал бы с инвентаризации скучных команд.

Где разработчики чаще всего ходят в UI?

- посмотреть production-логи;
- найти ошибки по request id;
- проверить статус очередей;
- посмотреть деплой;
- вытащить последние failed jobs;
- собрать диагностический bundle для инцидента.

Если действие повторяется каждую неделю, его можно завернуть в CLI. Если CLI возвращает нормальный текст или JSON, его уже может использовать агент.

Дальше появляются сценарии:

```bash
agent logs errors --service billing --env prod --since 1h
agent deploy status --service api
agent incident bundle --request-id abc123
```

Названия условные. Смысл не в них. Смысл в том, что AI-агенту не нужен доступ “ко всему”. Ему нужны узкие, понятные ручки к реальным рабочим процессам.

## Вывод

История с `cloudwatch-insights` хороша не самой утилитой. Хотя утилита полезная. Она хорошо показывает новый паттерн: внутренние CLI становятся API для AI-агентов.

Не каждый такой инструмент надо превращать в MCP-сервер. Не каждый workflow нужно тащить в платформу. Иногда достаточно маленькой команды.

Раньше мы писали такие инструменты, чтобы меньше кликать самим. Теперь их стоит писать ещё и потому, что ими будет пользоваться кто-то кроме нас. Например, Claude, когда ты попросил его разобраться с ошибками в логах.

И да, это звучит чуть странно. Но, кажется, именно так agentic development и будет проникать в обычную инженерную рутину: не через один большой “AI для всего”, а через десятки маленьких CLI, которые наконец-то начали окупаться.

## FAQ

### Нужно ли делать MCP-сервер для каждого внутреннего инструмента?

Нет. Если инструмент нужен внутри команды и уже хорошо работает из терминала, обычный CLI может быть проще. MCP полезен, когда нужны схемы tools, discovery, permissions и поддержка разных клиентов.

### Почему CLI удобен для AI-агентов?

AI-агент может запускать CLI из терминала, читать stdout, сохранять результаты и передавать их дальше в анализ. Это проще и надёжнее, чем заставлять агента работать через графический интерфейс.

### Что важно в CLI, которым будет пользоваться AI-агент?

Стабильный вывод, машинно-читаемые форматы, понятные exit codes, хороший `--help`, dry-run режимы и разделение безопасных и опасных команд.

### Чем CLI отличается от API для агента?

Для агента CLI часто и есть локальный API. Он менее формальный, чем HTTP или MCP, но зато живёт в той же среде, что и разработчик: в репозитории, терминале и shell workflow.