Вы попросили своего ИИ-агента для программирования отладить простую ошибку в тесте, а он каким-то образом начал рекурсивно считывать всю историю вашего репозитория .git/objects. Если ваши счета за API растут, пока агент, по-видимому, просто просматривает вашу кодовую базу, вы не одиноки.
Разработчики часто винят выбор модели LLM или плохо составленный системный промпт. Но настоящий убийца бюджета — это входной контекст. Ваш агент платит не за размышления, он платит за повторное чтение 4000 строк вывода grep, которые он уже понял шесть итераций назад. Самые главные виновники — это повседневные команды оболочки, которые разработчики использовали десятилетиями, не задумываясь.
Почему команды оболочки разоряют бюджеты ИИ-агентов?
Команды оболочки, такие как ls, find и grep, были созданы для людей, а человеческий мозг автоматически отфильтровывает терминальный шум, чтобы найти нужную строку. У ИИ-агентов нет такого фильтра. Они обрабатывают необработанный вывод терминала как оплачиваемый контекст. Даже если агент позже суммирует свою историю, начальное поглощение этих огромных, нефильтрованных данных вызывает резкие скачки потребления токенов.
По мере того как автономные агенты для программирования переходят от простого автодополнения к планированию и выполнению многошаговых рабочих процессов через терминал, они вызывают эти команды снова и снова. Каждый вызов добавляет токены, которые быстро накапливаются, пока сессия не завершится или агент не сожмет свою историю. Разрыв между человеком, бегло просматривающим вывод, и агентом, поглощающим каждый его символ, — это то место, где сгорает ваш бюджет.
Три повседневных виновника
Наряду с подробными логами тестов, эти три обычные команды оболочки являются частыми источниками неконтролируемых расходов, которые могут накапливать агентные рабочие процессы. Их распознавание — первый шаг к контролю над ними.
- ls, дамп директории: Агент спрашивает, что находится в директории, и запускает ls -la. В маленькой папке это безобидно. В корне монорепозитория эта единственная команда может выдать десятки тысяч токенов с правами доступа, временными метками, размерами файлов и скрытыми файлами, о которых никто не просил.
- find, бесконечное дерево: На вопрос «где находится конфигурация базы данных?», агент запускает find . -name "*.yaml". Без ограничений глубины find рекурсивно обходит каждую скрытую папку, кэш-директорию и путь к артефактам сборки, до которых может дотянуться.
- grep, убийца контекста: Агент, охотящийся за вызовом функции, запускает grep -r "processPayment". Если его не ограничить, он может вернуть минифицированный JavaScript, бинарный мусор и бесконечные данные тестовых заглушек. Хуже того, если он находит совпадение в строке длиной 10 000 символов в сгенерированном JSON-файле, вся эта строка попадает в промпт.
Каждая из этих команд безопасна в изоляции и дорога в масштабе, именно поэтому они остаются незамеченными при проверке кода.
Почему слепое усечение не решает проблему?
Слепое усечение вывода оболочки (т.е. просто ограничение каждой команды 1000 токенами) звучит как быстрое решение, но оно незаметно нарушает способность агента рассуждать о том, что он видит.
Если вы молча усекаете вывод grep, агент может не узнать, что получил частичные результаты. Он может предположить, что результатов не существует. Отсюда он может начать гадать, галлюцинировать или зациклиться. В нашем внутреннем тестировании агенты перезапускали одну и ту же команду ls до шести раз, пытаясь восстановить свое местоположение в файловой системе.
Оптимизатор, который агент не может обнаружить, — это оптимизатор, который вы не можете отладить. Любой уровень сжатия, который вы создаете, должен сообщать агенту, чего он не видит, иначе вы променяете проблему стоимости на проблему корректности. Это именно тот режим сбоя, которого призван избежать инструмент сжатия токенов, такой как JFrog Boost. Он сжимает вывод и сообщает агенту, когда это сделал, чтобы агент мог запросить полный вывод.
Эффект снежного кома: как одна плохая команда приумножает расходы
Это наиболее легко упускаемая из виду статья расходов в агентных рабочих процессах: за плохую команду платят не один раз. Из-за того, как обычно работают многоходовые диалоги с LLM, токены предыдущих итераций пересылаются с каждым новым сообщением, пока сессия не закончится, агент не сожмет свою историю или сессия не достигнет лимита контекста.
Такое поведение при пересылке превращает небольшие потери в совокупные. Ценность обрезки вывода команды заключается не только в сэкономленных токенах, но и в том, что эти токены умножаются на количество итераций, в течение которых они в противном случае оставались бы в контексте. Например, лог на 3000 токенов, удаленный на четвертом шаге 40-шаговой сессии, — это не экономия 3000 токенов. До кэширования промптов или сжатия истории это более 100 000 входных токенов, сэкономленных за время жизни этой сессии.
Иллюстративный расчет. Предполагается отсутствие кэширования промптов или сжатия истории.
Чем раньше оптимизируется вывод команды, тем ценнее эта оптимизация, поскольку она позволяет избежать повторной обработки на каждой последующей итерации, а не только на текущей. Примечание: кэширование промптов может снизить некоторые расходы на повторную обработку, но время жизни кэша и скидки варьируются в зависимости от провайдера и модели, а кэшированные токены все равно оплачиваются. На наш взгляд, кэширование дополняет оптимизацию вывода, а не заменяет ее.
По прейскурантным ценам на октябрь 2026 года 100 000 входных токенов стоят примерно от 0,15 до 0,30 доллара США для таких моделей, как GPT-5 или Claude Sonnet 5, до учета кэширования или пакетных скидок. Это звучит дешево, пока не начинает повторяться. Если каждая из 50 ежедневных сессий отладки тратит около 100 000 входных токенов на шум, это составляет примерно от 200 до 300 долларов в месяц по этим ставкам. Внезапно команда начинает тратить сотни долларов в месяц, позволяя ИИ-агенту «смотреть» на скрытые кэш-директории.
Ключевой вывод: экономия 2000 токенов на ранней команде grep может сэкономить гораздо больше, чем такое же сокращение в конце сессии, потому что эти 2000 токенов в противном случае перерабатывались бы на каждой последующей итерации.
Как остановить команды оболочки от истощения вашего бюджета токенов?
Если вы создаете агентные рабочие процессы, MCP-серверы или пользовательские инструменты для разработчиков, вам нужен уровень оптимизации, который устраняет шум, не ослепляя LLM относительно того, что она упускает. JFrog Boost, бесплатная оболочка CLI, находящаяся в настоящее время в публичном предварительном просмотре, построена на четырех правилах оптимизации, которые может принять любая команда, даже без использования самого инструмента.
- Принудительно устанавливайте ограничения по умолчанию. Там, где настройки вашего агента позволяют это, направляйте команды оболочки через обернутые версии вместо необработанных команд. Предоставляйте обернутые версии или псевдонимы, которые автоматически применяют ограничения — безопасный ls, который принудительно использует ls -1 (только имена) вместо ls -la, и безопасный find, который применяет ограничения глубины, такие как find . -maxdepth 2 -name "*.ts".
- Сообщайте агенту, что вы отфильтровали. Если лог из 10 000 строк должен быть усечен, не делайте этого молча. Добавьте системное сообщение к выводу, чтобы агент знал, что перед ним сводка, а не полная картина.
- Предоставьте путь для восстановления. Дайте агенту специальный инструмент, такой как cat_full_file <path>, чтобы он мог явно запросить отброшенные данные вместо того, чтобы галлюцинировать ответ.
- Инструментируйте путь восстановления. Отслеживайте, как часто агент действительно использует этот путь восстановления. На наш взгляд, частота извлечения данных является лучшим показателем удобства использования инструмента, чем просто коэффициент сжатия.
Последовательное применение этих правил помогает поддерживать контекст агента в компактном состоянии, не заставляя его гадать о том, чего он не видит.
Создание более безопасной оболочки для инструментов, снижающей риск инъекций
Чтобы разобрать это на конкретном примере, давайте посмотрим, как реализовать Правило 1 (принудительное применение безопасных ограничений). Вместо того чтобы позволять ИИ-агенту выполнять grep напрямую в вашей операционной системе, мы создаем функцию Python, которая действует как «обертка» (wrapper) вокруг этой команды.
Эта обертка перехватывает запрос агента, делает команду безопасной, запускает ее, а затем фильтрует вывод перед отправкой обратно в LLM. Вот как JFrog Boost и аналогичные инструменты создают эти базовые шаблоны, шаг за шагом:
Шаг 1: Передача аргументов команды в виде списка. Сначала мы формируем команду. Вместо передачи одной строки в командную оболочку (что может сделать вас уязвимым для инъекций команд), мы передаем список раздельных аргументов. Мы также принудительно заставляем grep игнорировать такие известные пожиратели токенов, как папки .git и node_modules.
Шаг 2: Безопасное выполнение и перехват вывода. Затем мы запускаем команду. Мы явно устанавливаем check=False, чтобы в случае, если grep ничего не найдет (что возвращает ненулевой код выхода), она просто возвращала пустую строку, а не аварийно завершала весь цикл нашего агента.
Шаг 3: Введение лимитов и добавление аварийного люка для восстановления. Наконец, мы проверяем длину вывода. Если она превышает наш лимит токенов (примерно 8 000 символов), мы усекаем его. Что особенно важно, мы добавляем системное примечание [System] прямо к выводу. Это точно сообщает LLM о том, что произошло, и дает ей точную команду инструмента (cat_file), которую она может использовать, если ей действительно нужно прочитать остальную часть файла.
Эта обертка передает аргументы в виде списка, а не строки командной оболочки, что снижает риск внедрения команд в оболочку, а также связывает каждое усечение с явным примечанием, на которое агент может отреагировать. Рабочие версии также должны ограничивать пути, которые агент может искать, и запускаться с минимально необходимыми привилегиями. Результаты работы агента заслуживают доверия и эффективны по стоимости ровно настолько, насколько то, что ему разрешено потреблять; не позволяйте случайной команде оболочки разрушить это доверие.
Как помогает JFrog Boost: создание и масштабирование агентов с уверенностью
Ручное оборачивание каждой команды оболочки — неплохая отправная точка, но это не масштабируется для команды, которая запускает десятки агентных рабочих процессов в день. JFrog Boost, находящийся в настоящее время в стадии публичного предварительного просмотра, разработан для автоматического применения этих правил: это бесплатный интерфейсный CLI-инструмент (CLI wrapper), который сжимает шумный вывод команд до того, как он попадет к таким агентам, как Cursor, Claude Code или GitHub Copilot. JFrog Boost создан для удаления нерелевантного шума из тестовых прогонов и поисковых запросов с сохранением сбоев, сводок и других полезных данных, которые обычно необходимы агентам.
Именно поэтому JFrog Boost нацелен на сжатие на уровне команд — именно там, где вывод впервые попадает в контекст, — вместо попыток очистить диалог после того, как проблемы накопились.
В паре с таким уровнем сжатия платформа JFrog Software Supply Chain Platform предоставляет командам единую систему учета артефактов, пакетов и бинарных файлов, с которыми работают их агенты.
Чтобы попробовать JFrog Boost, установите его бесплатно на сайте boost.jfrog.com. Чтобы узнать, как платформа JFrog управляет артефактами и пакетами, используемыми вашими агентами, запланируйте демонстрацию, пройдите онлайн-тур или начните бесплатный пробный период.
Эта публикация предоставляется исключительно в общеинформационных целях. Она не является юридической, нормативной или консультационной помощью по безопасности и не гарантирует никаких результатов в области безопасности. Результаты зависят от вашего окружения и конфигурации. Возможности продуктов различаются в зависимости от редакции и модели развертывания и регулируются вашим соглашением с JFrog. JFrog не является автором и не дает гарантий в отношении сторонних ИИ-ресурсов, перечисленных в его продуктах или регулируемых ими.
JFrog является зарегистрированным товарным знаком JFrog Ltd. в Соединенных Штатах. Cursor, Claude, Claude Code, GitHub Copilot, GPT-5 и Python являются товарными знаками соответствующих владельцев. Все остальные товарные знаки, упоминаемые в этом документе, являются собственностью соответствующих владельцев. Использование этих наименований не подразумевает какой-либо связи с ними или их одобрения.
Примеры кода представляют собой упрощенные иллюстрации, предоставляемые по принципу «как есть» в образовательных целях. Протестируйте и адаптируйте их перед использованием в рабочей среде.
