Как не потратить кучу денег на гуся. Про AI-агент Goose

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

Плохой промт - это когда вы перекладываете ответственность на модель. Хороший - когда вы подумали за неё и задали чёткие рамки.

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

Тот же самый смысл можно передать иначе: файл [путь до файла] , функция validate_token, строки 42–67. Найди уязвимости уровня timing attack или bypass. Ответ - список проблем, без объяснений. В этот момент мы экономим. Агент не ищет файл, не читает лишнее, не рассуждает. Он сразу идёт в нужную точку и делает ровно то, что нужно.

Та же история с тестами. Формулировка напиши тесты для UserService кажется безобидной, но она оставляет слишком много свободы. Модель начинает решать, какие методы важны, какие сценарии покрыть, и как вам это всё объяснить. В итоге вы получаете длинный ответ с комментариями, пояснениями и, возможно, лишними кейсами.

Если сказать иначе - файл [путь до файла], нужны pytest-тесты только для create_user и delete_user, покрыть успешный сценарий и дублирующий email, вернуть только код без комментариев - поведение меняется. Агент не философствует, не пишет учебник, не выходит за рамки. Он просто генерирует минимально достаточный результат. Экономия достигается не за счёт «хуже качества», а за счёт отсутствия лишнего.

Очень дорогой паттерн - сделать всё одним запросом. Например: отрефактори код, добавь типы, напиши тесты и проверь, что ничего не сломалось. Звучит как нормальная задача, но для модели это означает держать в контексте сразу несколько целей, постоянно переключаться и генерировать большой объём текста. Это автоматически увеличивает стоимость.

Если разбить это на шаги, поведение становится предсказуемым. Сначала вы просите добавить type hints в конкретный файл и вернуть только diff. Потом - отдельно сгенерировать тесты. Потом - отдельно проверить риски. Каждый шаг маленький, понятный и дешёвый. Плюс у вас появляется контроль: можно остановиться после любого этапа и не платить за лишнее.

Отдельно стоит сказать про роль. Если написать «посмотри код», модель сама решает, как на него смотреть. Она может начать объяснять стиль, предлагать рефакторинг, обсуждать архитектуру. Если же задать рамку вроде «ты senior QA, проверяешь backend перед релизом, смотри только на edge cases, негативные сценарии и безопасность», фокус резко сужается. Модель перестаёт распыляться и выдаёт более короткий и релевантный результат.

У тестировщиков особенно хорошо работает подход со строгим форматом ответа. Например, при генерации тест-кейсов можно сразу задать структуру: эндпоинт, входные данные, покрыть позитивные, негативные и граничные случаи, вернуть не больше десяти кейсов в виде таблицы. Ограничение количества и формата - это прямое управление стоимостью.

Похожий приём работает и для поиска багов. Если уточнить, что нужны только логические ошибки и игнорировать форматирование, она перестаёт тратить токены на второстепенные вещи.

Самый недооценённый инструмент - это постоянный профиль. В Goose можно один раз описать стек, правила и формат ответов, и модель будет учитывать это в каждом запросе. То есть вам не нужно каждый раз писать условия.Это даёт огромную экономию, потому что убирает повторяющийся текст из каждого промта.