Source: https://aiprimetech.io/ru/blog/claude-code-cli-guide/ 19 июня, 2026 · 6 мин · Инструменты # Claude Code и новая волна терминальных ИИ-инструментов для программирования A Автор: [AI Prime Tech](https://aiprimetech.io/ru/) · При участии ИИ В 2:13 утра я наблюдал, как терминальный агент для программирования потратил 1.8 миллионов входных токенов, пытаясь «просто исправить падающий тест». Настоящая ошибка заключалась в несоответствии схемы на трёх строках. Агент не был глупым; ему плохо задали ограничения. Он продолжал перечитывать репозиторий, повторно запускать команды тестирования с широким охватом, отправлять огромные трассировки стека обратно в модель и запрашивать переписывание файлов целиком там, где хватило бы точечного изменения. Этот случай изменил мой подход к запуску агентов для программирования в CLI. Такие инструменты, как Claude Code, Aider, Cline и OpenCode, — это не просто чат-боты с кнопкой git diff . Это циклы управления на основе API, работающие с вашей оболочкой, редактором, файловой системой, а иногда и браузером. Они могут быть чрезвычайно продуктивными, особенно с мощными моделями вроде Claude Opus 4.8, Sonnet 4.6, GPT-5.5, Gemini 3 и системами с длинным контекстом вроде Fable 5. Но они также могут незаметно расходовать токены со скоростью, которая удивляет команды, привыкшие к одиночным вызовам API. Эта статья посвящена практике: что на самом деле делают терминальные агенты для программирования, как они используют API моделей, почему агентные циклы меняют экономику токенов и как я настраиваю их, чтобы длительный сеанс оставался полезным, а не превращался в дорогостоящую имитацию работы. ## Что на самом деле представляют собой агенты для программирования в CLI Терминальный агент для программирования обычно объединяет пять компонентов: - Цикл диалога с передовой или открытой моделью - Индексатор репозитория или слой поиска файлов - Слой выполнения инструментов для команд оболочки и редактирования файлов - Механизм применения патчей - Слой хранения истории диалога и состояния сеанса Ключевое отличие от автодополнения — самостоятельность действий. Автодополнение предсказывает код в позиции курсора. Агент может решить изучить файлы, запустить тесты, изменить код, разобраться в сбоях и повторить цикл. Типичный цикл выглядит так: ``` User task ↓ Agent builds prompt from instructions + repo context + prior messages ↓ Model proposes actions: read file, edit file, run command ↓ CLI executes allowed actions ↓ Results are added back into context ↓ Model plans next step ↓ Repeat until done or stopped ``` Именно благодаря этому циклу инструменты кажутся мощными. По той же причине стоимость и задержки ведут себя иначе, чем при обычном использовании API по принципу «задать один вопрос — получить один ответ». На практике большинство неожиданных расходов связано с обратной связью: вывод команд, содержимое файлов, предыдущие сообщения и различия в коде многократно включаются в последующие обращения. ## Claude Code, Aider, Cline и OpenCode: разные формы одного подхода У инструментов разные способы взаимодействия, но основная инженерная схема похожа. | Инструмент | Основной интерфейс | Типичное преимущество | Распространённый риск роста затрат | Claude Code | Агент, созданный для работы в терминале | Тесная интеграция работы с оболочкой и репозиторием, эффективный цикл планирования и редактирования | Длительные автономные сеансы с накоплением контекста | Aider | Напарник для программирования в CLI с поддержкой Git | Редактирование на основе различий, явный выбор файлов | Добавление слишком большого числа файлов в контекст | Cline | Агент, ориентированный на работу в редакторе | Интеграция с VS Code, наглядное использование инструментов | Попадание большого объёма вывода терминала или браузера в контекст | OpenCode | Рабочий процесс с агентом в терминале и редакторе | Гибкий выбор моделей и контроль локального рабочего процесса | Неверная настройка провайдеров или сканирование репозитория с широким охватом Важное различие — не в том, «какой из них умнее». Оно в том, сколько контекста отправляет инструмент, как он выбирает файлы, как сжимает историю и насколько вы контролируете выполнение команд оболочки. Aider, например, обычно хорошо работает, когда вы целенаправленно добавляете нужные файлы. Claude Code действует более самостоятельно и может напоминать опытного инженера, работающего с разными частями репозитория, но такая автономность требует осознанного подхода к разрешениям и границам задачи. Cline удобен внутри редактора, особенно если вы хотите наблюдать за действиями, однако удобство редактора может привести к тому, что вы с лёгкостью одобрите слишком много дорогостоящих шагов. Рабочие процессы в стиле OpenCode привлекают команды, которым нужна гибкость в выборе провайдеров: Claude для сложной архитектурной работы, GPT для реализации, Gemini для анализа большого контекста или открытые модели вроде Qwen, DeepSeek, Kimi, MiniMax и Llama для более дешёвых проходов локально или на собственной инфраструктуре. ## Как эти агенты используют API Один запрос «исправь эту ошибку» может обернуться десятками вызовов API. Упрощённое тело запроса для одного шага агента выглядит так: ``` { "model": "claude-sonnet-4.6", "messages": [ { "role": "system", "content": "You are a coding agent. Follow repo instructions. Use tools safely." }, { "role": "user", "content": "Fix the failing invoice total test." }, { "role": "assistant", "content": "I will inspect the test and related invoice code." }, { "role": "tool", "name": "read_file", "content": "tests/test_invoice_totals.py contents..." } ], "tools": [ { "name": "read_file" }, { "name": "apply_patch" }, { "name": "run_shell" } ] } ``` Конкретные реализации различаются, но схема остаётся одной и той же: - CLI собирает контекст. - Модель определяет следующую операцию. - CLI выполняет операцию. - Результат передаётся обратно модели. - Модель продолжает работу. Обычно инструменты предоставляются двумя способами. ### Текстовые протоколы работы с инструментами Некоторые агенты просят модель выдавать структурированный текст: ``` RUN: pytest tests/test_invoice_totals.py -q ``` CLI разбирает его и выполняет указанное действие. Это простой и переносимый подход, но он хрупок. Если модель необычным образом оформит команду, управляющей обвязке понадобятся защитные механизмы. ### Встроенный вызов функций Другие агенты используют вызов инструментов или функций через API модели. Модель возвращает структурированный вызов инструмента: ``` { "tool_name": "run_shell", "arguments": { "command": "pytest tests/test_invoice_totals.py -q", "timeout_seconds": 60 } } ``` Такой вызов проще проверить. Агент может отклонять команды, соответствующие опасным шаблонам, требовать разрешения на доступ к сети или ограничивать запись рабочей областью. В обоих подходах основная затратная часть — не сама команда оболочки, а растущий промпт вокруг неё. ## Почему циклы работы агента меняют экономику токенов Обычная интеграция с API может отправить 2,000 входных токенов и получить 500 выходных токенов. Сеанс программирования с агентом может выглядеть так: | Шаг | Что происходит | Характер входных токенов | Характер выходных токенов | 1 | Пользователь просит исправить ошибку | Небольшой объём | План | 2 | Агент читает файлы | Средний объём | Запрос на вызов инструмента | 3 | Агент редактирует код | Объём от среднего до большого | Патч | 4 | Тест завершается ошибкой | Большой объём, если включены полные логи | Диагностика | 5 | Агент читает дополнительные файлы | Объём растёт из-за истории | Запрос на вызов инструмента | 6 | Агент повторяет попытку | Объём снова растёт | Патч | 7 | Полный прогон тестов выявляет ошибку в другом месте | Очень большой объём, если вывод вставлен без обработки | Сводка и разбор ошибок Подводный камень: входные токены часто составляют основную часть расхода. На каждой итерации могут повторно отправляться системные инструкции, история диалога, выбранные файлы, результаты инструментов и сводки. Даже с кешированием или сжатием контекста длительные автономные сеансы могут обходиться дорого, поскольку модели нужно достаточно информации о текущем состоянии, чтобы не действовать вслепую. Есть четыре распространённых фактора, увеличивающих расход токенов: - Контекст из полных файлов: отправка файлов на 900 строк, когда важны лишь две функции. - Подробный вывод тестов: включение предупреждений о зависимостях, индикаторов прогресса и ошибок, не связанных с задачей. - Повторные сканирования репозитория: запуск find, treeили rg с широким охватом и повторное добавление вывода в контекст. - Неограниченная история диалога: сохранение каждой неудачной попытки вместо краткого изложения принятых решений. В запутанном сеансе происходит вовсе не то, что «агент думает усерднее». Часто он просто видит больше устаревшего контекста. Избыток токенов может сделать модель медленнее и менее точной, если важная информация теряется в общем объёме. ## Модель расчёта: бюджет на итерацию, а не на промпт Оценивая расходы, я считаю итерации. Небольшая задача с чёткой целью может выглядеть так: ``` 8 turns × 12k input tokens average = 96k input tokens 8 turns × 1.5k output tokens average = 12k output tokens ``` Задача, в которой агент отклоняется от цели, может выглядеть так: ``` 35 turns × 55k input tokens average = 1.9M input tokens 35 turns × 3k output tokens average = 105k output tokens ``` Один и тот же пользовательский промпт. Совершенно разные затраты. Точные цены не нужны, чтобы понять суть проблемы. Масштаб сеансов работы с агентом зависит от: ``` total cost ≈ Σ(input_tokens_per_step × input_price) + Σ(output_tokens_per_step × output_price) + tool/runtime overhead ``` Выходные токены видны, потому что вы наблюдаете, как агент печатает. Входные токены скрыты, потому что их собирает CLI. Именно на этой скрытой стороне важна дисциплина расходования бюджета. ## Выбор моделей для работы агента Я редко использую одну модель для всего. Для терминальных агентов выбор модели должен соответствовать этапу работы: | Этап | Оптимальный тип модели | Почему | Первичное изучение репозитория | Модель с длинным контекстом или более дешёвая модель с достаточными возможностями | Требуется изучить много материалов, а не внести идеальные правки | Архитектурное решение | Модель с сильными способностями к рассуждению | Требуется оценить компромиссы | Создание патча | Модель, сильная в программировании | Требуются точные изменения | Разбор ошибок тестов | Быстрая модель среднего уровня | Часто достаточно распознавания типовых закономерностей | Механический рефакторинг | Дешёвая или открытая модель с защитными ограничениями | Повторяющаяся работа с проверяемым результатом На практике можно использовать модели класса Sonnet для большинства задач программирования, модели класса Opus/GPT-5.5 для сложной отладки или проектирования, модели с длинным контекстом типа Gemini/Fable для анализа больших объёмов данных и открытые модели для локального рефакторинга по правилам линтера. Конкретные названия будут меняться; подход останется тем же. Распространённая ошибка — использовать самую дорогую модель на протяжении всего цикла. Тогда дорогая модель тратит токены по премиальной цене на чтение node_modulesи сопутствующего информационного шума, предупреждений тестов и сгенерированных файлов. Приберегите самую сильную модель для решений, которым она действительно нужна. ## Важные советы по настройке Лучшая настройка — не «максимальная автономность», а «быстрая обратная связь с ограниченными разрешениями». ### 1. Игнорируйте сгенерированные файлы и файлы сторонних зависимостей У каждого агента для программирования должен быть список игнорирования. Начните с того, что вы исключаете из поиска и проверки кода: ``` node_modules/ dist/ build/ coverage/ .venv/ __pycache__/ target/ vendor/ *.lock *.min.js *.map ``` Обычно я не исключаю файлы фиксации версий зависимостей глобально, если задача связана с разрешением зависимостей, но исключаю их из контекста по умолчанию. При необходимости такой файл можно добавить явно. ### 2. Используйте узконаправленные команды запуска тестов Не позволяйте агенту по умолчанию запускать весь набор тестов на каждой итерации. Задайте ему последовательность команд с постепенно расширяющимся охватом: ``` # First loop: fastest relevant test pytest tests/billing/test_invoice_totals.py -q # Second loop: nearby package pytest tests/billing -q # Final confidence check pytest -q ``` Для JavaScript или TypeScript: ``` pnpm test invoice-total.test.ts -- --runInBand pnpm lint src/billing pnpm test ``` Дело не только во времени выполнения. Чем меньше вывод, тем меньше промпт на следующей итерации. ### 3. Ограничивайте объём вывода команд Если ваш агент поддерживает ограничения вывода, используйте их. Если нет, самостоятельно добавьте обвязку к командам: ``` pytest tests/billing -q 2>&1 | tail -120 ``` Или для сборок с большим объёмом вывода: ``` pnpm test 2>&1 | grep -E "FAIL|Error|Expected|Received|at " | head -200 ``` Будьте осторожны: фильтрация может скрыть полезный контекст. Я использую её после первого сбоя, а не до него. Сначала выясните характер сбоя, затем ограничьте вывод повторных запусков. ### 4. Просите точечные изменения, а не полную перезапись Для больших файлов явно укажите агенту: ``` Make the smallest safe patch. Do not rewrite unrelated functions. Show a concise diff summary before running tests. ``` Это снижает риск и обычно уменьшает число выходных токенов. Что ещё важнее, так проверка кода остаётся разумной по объёму. ### 5. Отделяйте планирование от выполнения Для нетривиальных изменений я часто начинаю с такого запроса: ``` Inspect the relevant files and propose a plan. Do not edit yet. Limit repo inspection to payment, invoice, and tax modules unless needed. ``` Затем я утверждаю план и позволяю агенту реализовать его. Это помогает избежать ситуации, когда агент вносит изменения, не разобравшись в задаче. ## Контроль расходов во время длительных сессий Именно в длительных сессиях CLI-агенты раскрывают свои возможности — и становятся опасными. Вот контрольный список для управления расходами, который я использую в реальной работе: - Задайте цель сессии: «Добейся, чтобы test_invoice_rounding проходил», а не «исправь биллинг». - По возможности явно указывайте файлы: указывайте точные пути вместо того, чтобы просить агента самостоятельно всё найти. - Сбрасывайте контекст при смене направления: когда задача меняется, начинайте новую сессию с кратким изложением текущего состояния. - Вручную обобщайте ошибки: вставляйте важные 30 строк, а не лог на 3,000 строк. - Осознанно переходите к более мощным моделям: используйте более мощную модель только после того, как возникло явное препятствие. - Останавливайтесь при повторении неудачных циклов: если агент дважды терпит неудачу одним и тем же способом, вмешайтесь. Хороший запрос для перезапуска выглядит так: ``` We are fixing invoice rounding. Known facts: - Failure is in tests/billing/test_invoice_totals.py::test_round_half_even - Expected 10.24, actual 10.25 - Decimal quantization happens in src/billing/money.py - Tax calculation calls round_money() from src/billing/tax.py Continue from this summary. Inspect only those files first. ``` Такой запрос может обойтись дешевле и быть понятнее, чем перенос всей неудачной переписки. ## Ключи API, провайдеры и маршрутизация Большинство CLI-агентов могут обращаться к API провайдера моделей напрямую или через совместимый шлюз. Ключевые инженерные вопросы: - Аутентификация: где хранятся ключи API и не попадают ли они в историю команд оболочки или логи. - Маршрутизация моделей: какая модель отвечает за какой этап. - Ограничения частоты запросов: циклы работы агента могут быстро создавать всплески запросов. - Наблюдаемость: отчётность по токенам и стоимости для каждой сессии. - Границы передачи данных: можно ли отправлять код во внешние API. Минимальная настройка окружения часто выглядит так: ``` export ANTHROPIC_API_KEY="..." export OPENAI_API_KEY="..." export GEMINI_API_KEY="..." ``` Для команд я предпочитаю скрипт-обёртку, который выбирает модели и записывает данные об использовании: ``` #!/usr/bin/env bash set -euo pipefail export AGENT_MODEL="${AGENT_MODEL:-sonnet}" export AGENT_MAX_OUTPUT_TOKENS="${AGENT_MAX_OUTPUT_TOKENS:-4096}" export AGENT_SESSION_BUDGET_USD="${AGENT_SESSION_BUDGET_USD:-10}" coding-agent "$@" ``` Если вы используете шлюз для нескольких моделей, он может пригодиться для маршрутизации запросов к Claude, GPT, Gemini или открытым моделям через единый интерфейс. Важен не список логотипов, а наличие надёжного учёта использования и средств управления на уровне моделей. ## Что я включаю в инструкции репозитория Большинство агентов учитывают ту или иную форму файла с инструкциями репозитория. Мои инструкции короткие и практичные: ``` ## Agent Instructions - Prefer minimal diffs over rewrites. - Do not run full test suites until targeted tests pass. - Never edit generated files in `dist/`, `build/`, or `coverage/`. - Use `rg` for search. - Before large refactors, propose a plan and wait. - If a command emits more than 200 lines, rerun with a narrower command. ``` Дело не в вежливости. Инструкции определяют рабочий цикл. Агент всё равно будет ошибаться, но хорошие инструкции сокращают повторные бесполезные затраты. Распространённая ловушка: слишком длинные файлы инструкций превращаются в фоновый шум. Если ваши инструкции для агента — это 300 строк рассуждений о стиле, модель может пропустить три важных рабочих ограничения. Размещайте наиболее ценные правила в начале. ## Задержка: ещё одна составляющая затрат Даже при приемлемых расходах на токены задержки могут разрушить рабочий ритм. Задержка при работе агента складывается из: - Времени выполнения модели - Времени выполнения инструментов - Времени индексации файлов - Времени выполнения тестов - Пауз на одобрение человеком Для коротких рабочих циклов я оптимизирую «время до следующего полезного результата». Целевой тест за 15 секунд лучше полной имитации CI за 6 минут. Менее мощная модель, которая правильно определяет синтаксическую ошибку за 4 секунд, лучше премиальной модели, которая тратит 45 секунд на красивое объяснение. Лучшие сессии напоминают парное программирование: ``` inspect → patch → targeted test → inspect failure → patch → targeted test → final suite ``` Худшие сессии напоминают косплей CI: ``` scan repo → edit many files → run everything → drown in logs → repeat ``` ## Ограничения и типичные сбои Терминальные агенты полезны, но не творят чудес. Они испытывают трудности, когда: - В репозитории есть скрытые зависимости времени выполнения, не охваченные тестами. - Задача требует продуктовых решений, а не преобразования кода. - Ошибка зависит от внешних сервисов или нестабильного состояния. - В кодовой базе есть вводящие в заблуждение абстракции или устаревшая документация. - Агент не может выполнить нужную команду проверки. Они также могут предлагать правдоподобные, но неверные исправления. Это особенно часто случается при слабых тестах. Если агент не может проверить поведение, относитесь к его результату как к непроверенному патчу младшего инженера: он может быть полезен, но автоматически доверять ему нельзя. Безопасность тоже важна. Не предоставляйте агенту неограниченный доступ к оболочке в репозитории с чувствительными данными, не разобравшись в механизме одобрения действий инструмента. Возможность «выполнять команды» включает вывод переменных окружения, изменение файлов, установку пакетов и обращения к сети, если это не ограничено. ## Практические рекомендации - Рассматривайте CLI-инструменты для программирования как циклы управления через API, а не как отдельные запросы. - Оптимизируйте затраты, сокращая число циклов и размер контекста, особенно вывод команд. - Используйте мощные модели для сложных рассуждений, а не для каждого механического шага. - Делайте инструкции репозитория короткими, практичными и ориентированными на поведение агента. - Сначала запускайте целевые тесты, а в конце — более широкую проверку. - Перезапускайте длительные сессии с краткими сводками вместо переноса устаревшей истории. - Следите за входными токенами: это скрытый источник затрат при программировании с агентами. - Останавливайтесь и вмешивайтесь, когда агент повторяет одну и ту же неудачную стратегию. Claude Code, Aider, Cline и OpenCode — часть реальных перемен: помощь в программировании переходит от механизмов подсказок к полноценным помощникам, работающим в терминале. Больше всего выиграют команды, которые не просто «включат агентов», а спроектируют рабочий цикл: ограниченный контекст, безопасные инструменты, прозрачные расходы и проверка на каждом шаге. [Программирование](/ru/blog/tag/coding/)[Claude](/ru/blog/tag/claude/)[Агенты](/ru/blog/tag/agents/) A [AI Prime Tech](https://aiprimetech.io/ru/) Этот блог публикует AI Prime Tech. Статьи готовятся с помощью ИИ; прежде чем полагаться на сведения, зависящие от версии, такие как идентификаторы моделей, цены и лимиты, сверяйте их с официальной документацией. Получите более дешёвый доступ к API Claude Один ключ API для Claude Opus 5.5, Sonnet 5, Haiku 4.5 и Fable 5.1, а также GPT-6 моделей. Оплата по мере использования, без подписки. [Получить ключ API →](/register) AI Prime Tech — независимый сторонний API-шлюз. Claude™ и Anthropic® — товарные знаки Anthropic, PBC. Связь с этой компанией или одобрение с её стороны не подразумеваются.