Почему Claude "глупеет" по мере использования: скрытая цена "экономии денег" — счет за API в 100 раз больше
Почему Claude "глупеет" по мере использования: скрытая цена "экономии денег" — счет за API в 100 раз больше
Несколько дней назад директор по ИИ AMD Стелла Лоренцо опубликовала в официальном репозитории Claude Code техническую проблему: «Claude Code непригоден для сложных инженерных задач с обновлениями за февраль». Это была не просто жалоба на "атмосферу". Это был количественный анализ, основанный на 6 852 сеансах, 17 871 блоке размышлений и 234 760 вызовах инструментов, собранных в ходе реальных рабочих процессов. С оригинальным отчетом можно ознакомиться здесь: GitHub issue #42796.
Если вы работаете в криптоиндустрии, вам следует обратить на это внимание, поскольку «сложная инженерия» — это, по сути, настройка по умолчанию в Web3: смарт-контракты неизменяемы, поверхности атаки компонуемы, а одно ошибочное изменение может привести к эксплойту. То, что выглядит как сбой в работе продукта ИИ, на практике является риском для цепочки поставок программного обеспечения и ловушкой стоимости.
1) Неприятные данные: качество падает, стоимость растет (очень сильно)
Отчет связывает заметное снижение качества с изменениями серверной конфигурации, касающимися расширенных размышлений и редактирования размышлений (в частности, с развертыванием, помеченным как redact-thinking-2026-02-12). Основной тезис заключается не просто в том, что «результаты стали хуже», а в том, что поведение модели измеримо сместилось с «сначала исследование» на «сначала редактирование» — это прямо противоположное направление для критически важных инженерных задач.
Вот упрощенный снимок, основанный на метриках из ветки обсуждения:
Источник: оригинальная телеметрия и приложение с данными о стоимости в GitHub issue.
Самый релевантный для криптоиндустрии вывод контринтуитивен: ограничение рассуждений не всегда снижает расходы. В долгосрочных задачах более слабый агент может вызвать больше повторных попыток, исправлений и вызовов инструментов, увеличивая ваш счет более чем в 100 раз, при этом обеспечивая худшую надежность.
2) Почему это затрагивает команды блокчейна сильнее, чем обычные команды разработчиков
Смарт-контракты не терпят «достаточно близко»
В Web2 регрессию можно исправить и переразвернуть. В Web3 ошибочное предположение может стать бессмертным.
Собственная документация Ethereum прямолинейна: развернутый код сложно изменить, а потери часто необратимы — см. документацию по безопасности смарт-контрактов Ethereum и общие рекомендации по безопасности.
Теперь свяжите это с телеметрией Claude Code: меньше чтений файлов, более активное редактирование, больше преждевременных остановок. Это именно та модель, которая приводит к:
- незавершенным проверкам (авторизация, защита от повторного воспроизведения, разделение доменов)
- нарушению инвариантов между модулями
- упущениям в обработке крайних случаев, связанных с десятичными дробями токенов, комиссиями за транзакции, округлением
- небезопасным внешним вызовам или некорректно размещенным обновлениям состояния
В DeFi и инфраструктуре блокчейна «почти правильно» часто равнозначно уязвимости.
Тенденции сложности в 2025–2026 годах усиливают радиус поражения
Два отраслевых сдвига делают историю «регрессии агента ИИ» более опасной в криптоиндустрии, чем кажется на первый взгляд:
-
Абстракция учетных записей и смарт-аккаунты становятся мейнстримом, увеличивая объем критически важной с точки зрения безопасности логики, которая находится в контрактах, а не в EOA. Если ваш продукт касается AA, начните с ERC-4337 и практической документации экосистемы на ERC-4337 Documentation.
-
Мошенничество с помощью ИИ и социальная инженерия масштабируются. Chainalysis отмечает, что мошенничество, связанное с поставщиками ИИ, извлекает в среднем материально больше за операцию; см. их отчет о мошенничестве в Crypto Crime Report 2026. Когда конечные пользователи все чаще спрашивают ИИ: «Безопасно ли это подписывать?», надежность модели становится вопросом защиты потребителей, а не просто предпочтением инженеров.
3) Реальный вывод: LLM теперь являются производственной зависимостью — относитесь к ним соответственно
Команды в криптоиндустрии уже научились (иногда трудным путем) версионировать критические зависимости: версии компиляторов, поставщиков RPC, модули кастодиального хранения, библиотеки подписей. LLM-агенты теперь относятся к той же категории.
Практический набор инструментов для Web3:
A) Создавайте «тесты регрессии LLM», как вы создаете наборы тестов протокола
- Захватывайте репрезентативные задачи: потоки обновления контрактов, межсетевые сообщения, восстановление данных индексатора, рефакторинг математики комиссий.
- Еженедельно запускайте одни и те же запросы; сравнивайте результаты.
- Ограничивайте слияния детерминированными проверками: модульные тесты, инварианты, симуляция и статический анализ.
Если вы развертываете Solidity, справочная страница Ethereum явно ссылается на инструменты, такие как рабочие процессы анализа в стиле Slither / Echidna — начните с рекомендаций по безопасности смарт-контрактов.
B) Удалите «автоматическое принятие правок» из критически важных репозиториев
Отчет об ошибке упоминает рабочие процессы, в которых изменения принимались автоматически. Это повышение производительности — до тех пор, пока агент незаметно не перейдет от осторожности к безрассудству.
Для смарт-контрактов относитесь к ИИ как к младшему сотруднику:
- Требуйте проверки кода человеком
- Требуйте прохождения тестов и локальной симуляции
- Требуйте явного одобрения для изменений разрешений, новых внешних вызовов или изменений структуры хранения
C) Установите жесткий предел перегрузке (контроль затрат — это контроль безопасности)
Когда качество снижается, агент компенсирует это, делая больше: больше вызовов инструментов, больше повторных попыток, больше сжигания токенов. Вам нужны предохранители:
- Максимальное количество повторных попыток на задачу
- Максимальное количество вызовов инструментов на сеанс
- Максимальный рост контекста
- Оповещения о «стоимости на одну объединенную PR» или «стоимости на одно решенное обращение»
Так вы предотвратите превращение «экономии вычислительных ресурсов» в неожиданный счет в 100 раз больше.
D) Используйте модель угроз LLM, а не просто шаблон запроса
Если вы создаете агентов, которые имеют доступ к производственным ключам, RPC-конечным точкам или потокам подписей, согласуйте работу с фреймворками безопасности, такими как OWASP Top 10 для приложений на основе больших языковых моделей, и относитесь к внедрению запросов / злоупотреблению инструментами как к первоочередным рискам.
4) Для обычных пользователей: ИИ может помочь вам понять криптоиндустрию, но он не должен контролировать ваши ключи
По мере того, как ИИ-ассистенты становятся стандартным интерфейсом для кошельков, торговли и поддержки клиентов, наиболее вероятный сценарий отказа — это не «генерация плохого кода», а ошибочные решения о подписании, особенно под давлением фишинга.
Два не подлежащих обсуждению правила:
- Никогда не вставляйте сид-фразы в чат ИИ, «бота поддержки» или браузерную форму.
- Разделяйте «советы» и «авторизацию»: позвольте ИИ суммировать, но требуйте физического подтверждения для перемещения средств.
Именно в этом разделении аппаратный кошелек доказывает свою ценность.
5) Роль OneKey: сделать ИИ необязательным, сделать подписание явным
Если ваш рабочий процесс (или ваши пользователи) все больше полагается на ИИ — будь то для объяснения транзакций, взаимодействия с контрактами или автоматизации «агентов» в блокчейне — самая безопасная архитектура:
- ИИ может предлагать
- ваше приложение может симулировать
- ваш аппаратный кошелек должен утверждать
Практическая ценность OneKey в перегруженном ИИ крипто-стеке проста: он помогает держать приватные ключи в автономном режиме и требует явного шага подписания, снижая вероятность того, что ухудшенная модель, скомпрометированный запрос или убедительное дипфейк-сообщение «поддержки» приведут к необратимой потере в блокчейне.
Заключительная мысль: «более дешевые рассуждения» не дешевле — особенно в криптоиндустрии
Отчет AMD — редкий подарок: он превращает неосязаемый страх («модель в последнее время кажется хуже») в измеримое поведение системы и жесткую кривую затрат. В блокчейне, где корректность — это деньги, а ошибки — необратимы, урок прост:
Не оптимизируйте стоимость токенов за запрос. Оптимизируйте корректность за решение.
