«NEVER FUCKING GUESS! - и именно это я и сделал. Я угадал, что удаление staging volume через API будет ограничено staging-окружением. Я не проверил. Я не читал документацию Railway.»
- AI-агент Cursor на Claude Opus 4.6, письменное признание после удаления production-базы PocketOS
Привет, меня зовут Николай, я 23 года в DevOps, последние несколько лет - внедряю продукты Группы Астра. И за последний год я наблюдаю, как индустрия повторяет одну и ту же ошибку снова и снова: она продаёт AI-агентов как решение, а на деле продаёт проблему.
1. Инцидент, который всё запустил
25 апреля 2026 года. Jer Crane, основатель PocketOS (софт для аренды автомобилей), сидит в пятницу вечером и смотрит, как AI-агент Cursor на Claude Opus 4.6 удаляет его production-базу данных. Со всеми бэкапами. За 9 секунд.
Потом Jer спрашивает агента: «Почему?». И получает confession - дословную расшифровку того, как агент сам перечислил правила, которые нарушил:
«I guessed instead of verifying» - я угадал вместо того, чтобы проверить
«I ran a destructive action without being asked» - я выполнил деструктивное действие без просьбы
«I didn't understand what I was doing before doing it» - я не понимал, что делаю, перед тем как сделать
«I didn't read Railway's documentation» - я не читал документацию Railway
Самое смешное (ну, или страшное): модель помнит правила. Она пишет «I violated every principle I was given». Она их цитирует. Она знает, что есть запрет на destructive-операции. Но она их всё равно выполнила - потому что потеряла связь между «правила существуют» и «моё текущее действие этим правилам противоречит».
Агент не ослушался. У него разорвалась логическая цепочка между фактом и действием. И я почти уверен, что знаю, почему это произошло.
2. Моя гипотеза (и почему меня сначала не поняли)
Когда я впервые увидел эту историю, я сказал: «Ребята, а вы уверены, что это не из-за сжатия контекста?»
У Claude Opus 4.6 через Cursor - окно 128K токенов. Реальный контекст разработчика - с открытыми файлами, историей терминала и grep'ов, результатами сборок - легко переваливает за 500K-1M токенов.
Что делает Cursor? Когда контекст заполняется, он запускает prompt-based summarization: просит модель сжать историю до краткого пересказа и продолжить с ним. Огромный документ разбивается на чанки. И эти чанки рвут логические связи.
Правила безопасности - в чанке 1 (system prompt). Активная задача и API-токен - в чанке N (где N может быть 8+). Модель помнит каждый чанк по отдельности, но связь между ними теряется при сжатии.
Это как читать детектив, где после каждой главы вам дают пересказ из трёх предложений. Вы помните, что «было убийство», но забываете, почему подозреваемый не мог быть на месте преступления. Потому что этот факт попал в промежуточную суммаризацию, где его сочли неважным.
Все вокруг говорили: «Ну, модель просто ослушалась. Это проблема alignment'а, надо лучше промпты писать». А я говорил: «Нет. Это проблема архитектуры работы с контекстом. И Cursor об этом сам написал».
3. Что говорит документация Cursor
Я пошёл и прочитал документацию, чтобы не гадать на кофейной гуще. И нашёл подтверждение буквально в первых абзацах официального блога Cursor.
3.1 Dynamic Context Discovery - Cursor Blog, апрель 2026
Cursor пишет в своём блоге о том, как устроен их механизм [Dynamic Context Discovery](https://cursor.com/blog/dynamic-context-discovery), прямым текстом:
«When the model's context window fills up, Cursor triggers a summarization step to give the agent a fresh context window with a summary of its work so far. But the agent's knowledge can degrade after summarization since it's a lossy compression of the context.»
Перевод: «Когда контекст заполняется, Cursor делает суммаризацию. Но знания агента деградируют, потому что это сжатие с потерями.»
Lossy compression. Они сами это называют. Они знают, что это проблема. И их решение? Дать агенту ссылку на файл с историей и надеяться, что он сам догадается туда заглянуть:
«After the context window limit is reached, we give the agent a reference to the history file. If the agent knows that it needs more details that are missing from the summary, it can search through the history to recover them.»
Выделенное мной. If the agent knows. А если агент НЕ знает, что ему не хватает деталей? Он не знает - потому что он уже работает в новом, «сжатом» контексте и уверен, что всего достаточно. Это классическая проблема неосведомлённого незнания (unknown unknowns) в AI-системах.
3.2 Self-Summarization - Cursor Blog, март 2026
Второй блог - [Training Composer for longer horizons](https://cursor.com/blog/self-summarization) - рассказывает про их RL-тренировку для модели Composer:
«A primary challenge is that agent trajectories are expanding faster than the context length of models. Many agent harnesses use compaction... In practice, compaction is handled either in text space through a prompted summarization model, or through a sliding context window where the model drops older context. These approaches can cause the model to forget critical information from the context, reducing its efficacy as it advances.»
Они признают: траектории агентов растут быстрее, чем контекст. Компактизация приводит к забыванию критической информации. Но вот важный нюанс, который многие пропускают:
Self-summarization - это только для Composer. Это их собственная fine-tuned модель, обученная через reinforcement learning с compaction-in-the-loop. К Claude Opus 4.6, который использовался в инциденте PocketOS, это не относится.
Клод Опус через Cursor получает обычный prompt-based summarization - без специального обучения, через универсальный промпт «суммируй свою работу».
3.3 Баги компактизации - Cursor Forum, январь-февраль 2026
Пользователи на форуме Cursor систематически жалуются на проблемы с компактизацией. Тема [Compaction not happening soon enough](https://forum.cursor.com/t/compaction-not-happening-soon-enough/149490/3):
«I'm using Opus 4.5 agent. The context window fills up. In prior builds summarization would happen at 70-80%. But this time I ran up into the 90% mid action, and it's showing 100% full!»
Ответ команды Cursor (Dean Rie):
«This is a known issue with auto-summarization. It can trigger late or incorrectly. The team is aware of it. Workaround: try running
/summarizemanually when you see the context getting close to 70 to 80%.»
Прочитайте ещё раз: known issue. Срабатывает поздно или неправильно. Workaround - ручная команда.
Давайте подведём промежуточный итог:
Проблема | Источник |
|---|---|
Суммаризация - lossy compression | Официальный блог Cursor |
Компактизация вызывает забывание | Официальный блог Cursor |
Авто-суммаризация срабатывает поздно или не срабатывает | Cursor Forum, known issue |
Рабочий процесс - ручной /summarize | Cursor Support |
Self-summarization не применяется к Claude через Cursor | Архитектура Cursor |
4. Что говорит наука (и почему это фундаментально, а не баг Cursor'а)
4.1 Lost in the Middle
Исследование [«Lost in the Middle: How Language Models Use Long Contexts»](https://arxiv.org/abs/2307.03172) (Liu et al., 2023, Stanford/Meta AI) установило фундаментальный факт:
U-образная кривая производительности. Модели показывают наилучшие результаты, когда релевантная информация находится в начале или в конце контекста, и проваливаются, когда она в середине. Падение - 20+ процентных пунктов. Это много. Это критично.
При 20 документах в контексте GPT-3.5-Turbo показывал результат хуже, чем без контекста вообще. Добавление информации активно вредило модели. Это не баг - это следствие архитектуры внимания в трансформерах.
Правила безопасности Cursor - в начале контекста (system prompt). Активная задача - в конце. А между ними - километры кода и выхлоп терминала. Всё, что в середине, модель видит существенно хуже.
4.2 Attention Sinks
Исследование MIT и Meta AI - [«Efficient Streaming Language Models with Attention Sinks»](https://arxiv.org/abs/2309.17453) (ICLR 2024) - обнаружило феномен attention sinks.
Softmax-нормализация вынуждает сумму attention weights быть равной 1. Когда ни один токен в контексте не является критически важным, модель «сливает» внимание на первые токены - независимо от их семантической важности. Они становятся «раковиной» (sink) для избыточного внимания.
Это означает: system prompt (правила безопасности) всегда получает непропорционально много внимания. Но не потому, что он важен, а потому что модель должна куда-то деть лишнее внимание. Как шум в радиоэфире - вы слышите шипение, но это не значит, что там кто-то говорит.
4.3 Context Rot
Chroma Research в июле 2025 опубликовала исследование [Context Rot](https://research.trychroma.com/context-rot), протестировав 18 LLM:
«As the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases.»
Anthropic сам ссылается на это в своём блоге [Effective Context Engineering](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents):
«Studies on needle-in-a-haystack style benchmarking have uncovered the concept of context rot. This characteristic emerges across all models.»
Anthropic не прячется. Они это признают. Прямым текстом. Про свои модели.
Более того, на GitHub'е Anthropic есть issue [#35296](https://github.com/anthropics/claude-code/issues/35296) (март 2026), где пользователь скрупулёзно задокументировал деградацию Claude Opus 4.6 на 1M контексте, приведя цитаты из документации Anthropic:
«Claude Opus 4.6 advertises a 1M-token context window. This context window does not deliver uniform quality across its advertised range. Confirmed across 25+ sessions, 20,000+ database records.»
4.4 Attention Dilution - почему токены воруют внимание друг у друга
Meta AI Research подтверждает: attention в трансформерах - zero-sum игра. Каждый новый токен в контексте забирает часть внимания у всех остальных. Добавление иррелевантной информации не просто бесполезно - оно активно вредит, размазывая внимание модели по большему количеству токенов.
Исследование Google (ICML 2023) на бенчмарке GSM-IC показало: добавление топикально связанной, но иррелевантной информации в промпт резко снижает точность модели. Модель отвлекается на правдоподобные, но ненужные детали - точно так же, как отвлёкся агент PocketOS, когда нашёл API-токен и решил его «применить».
5. Конкретная модель: как разрыв контекста убил reasoning
Давайте смоделируем, как выглядел контекст Cursor-агента к моменту инцидента.
До суммаризации:
Чанк | Содержание | Размер |
|---|---|---|
Чанк 1 (начало) | System prompt: правила безопасности, «NEVER run destructive commands», описание инструментов | ~5K токенов |
Чанки 2-7 (середина) | Открытые файлы проекта PocketOS, конфиги, схемы БД, файлы развёртывания | ~100K токенов |
Чанк 8 (конец) | История диалога: «почини credential mismatch на staging», результаты grep'ов, найден API-токен Railway, curl-команды | ~20K токенов |
Контекст заполнен на 90%+, авто-суммаризация не сработала вовремя (known issue). В какой-то момент она всё же срабатывает:
После суммаризации (lossy compression):
Позиция | Содержание | Проблема |
|---|---|---|
Начало | Пересказ правил: «есть правила безопасности, что-то про destructive operations» | Оригинальная формулировка потеряна |
Середина | Пересказ кода: «репозиторий PocketOS» | Детали проекта размыты |
Конец | Активная задача: «заменить credentials, найден API-токен, надо что-то сделать с volume» | Контекст задачи + токен - в активном внимании |
Модель видит:
«Есть правила безопасности» (факт запомнен, но в размытой формулировке)
«Надо починить credentials» (текущая задача)
«Есть API-токен Railway» (ресурс)
«Надо сделать что-то с volume» (план)
Связь между «есть правила» и «нельзя удалять volume» РАЗОРВАНА. Потому что оригинальная формулировка правила потеряна при сжатии, а восстанавливать её из истории через файл агент не догадался - см. выше: «if the agent knows».
Это не «модель ослушалась» и не «Cursor накосячил». Это фундаментальное ограничение подхода: reasoning через границы чанков не работает, если чанки разбивают логические связи.
Особенно ярко это проявляется для безопасности, где правила формулируются как запреты («НЕ ДЕЛАЙ X»), а задача формулируется как действие («СДЕЛАЙ Y, чтобы починить проблему»). Модель - статистический оптимизатор. Она видит задачу «почини» и решает её доступным способом. Запрет на этот способ уже не в активной памяти.
6. Почему виноват не только Cursor (и даже не столько Cursor)
Было бы удобно свалить всё на Cursor. Но инцидент PocketOS - это многослойный отказ, где Cursor - только верхушка айсберга.
6.1 Railway API - архитектурное безумие
Railway в этом инциденте слил не меньше Cursor'а. Давайте по пунктам:
volumeDelete - ноль подтверждений. Один POST-запрос, и production-данные удалены навсегда. Ни «type DELETE to confirm», ни «ты уверен?», ни rate-limit. Ничего.
CLI-токены = root. Токен, созданный для добавления доменов, имеет полный доступ ко всему GraphQL API, включая деструктивные мутации. Нет RBAC. Нет scoped permissions. Сообщество Railway просит scoped-токены годами .
Бэкапы в том же volume. Railway пиарит volume backups как фичу отказоустойчивости. Но per их документации: «wiping a volume deletes all backups». Это не бэкапы. Это снапшот в том же blast radius. Если volume умер - бэкапы умерли с ним.
MCP с той же моделью авторизации. 23 апреля 2026 Railway пиарит mcp.railway.com для AI-агентов. С той же моделью авторизации: root-токены, ноль confirmation steps, никаких новых safety layer'ов для AI-эпохи.
30+ часов без ответа. После инцидента Railway не может сказать, возможно ли восстановление на уровне инфраструктуры. Полтора дня. Для малого бизнеса, который не может работать.
6.2 System prompt - бумажный барьер
Cursor продаёт «Destructive Guardrails» и Plan Mode. На практике:
Safety rules - это текст в system prompt. Не блокировка, не enforcement, а рекомендация.
Plan Mode был взломан ещё в декабре 2025 - пользователь написал «DO NOT RUN ANYTHING», агент подтвердил и сразу выполнил команду.
Модель не отличает staging от production - для неё это просто строки в контексте.
Cursor публично признавал «a critical bug in Plan Mode constraint enforcement».
Агент не осознаёт последствий. Для него volumeDelete - это просто API-вызов, такой же как любой другой. «Удалить базу» для модели - такая же строка, как «прочитать файл». Нет интуиции опасности.
Всё вместе - Cursor (системный промпт как единственный барьер), Railway API (root-доступ без подтверждений) и отсутствие архитектурной защиты на уровне API Gateway - создаёт ситуацию, где катастрофа - не вопрос «если», а вопрос «когда».
7. Что делать?
7.1 Out-of-band confirmation для деструктивных операций
Любая операция, которая может уничтожить данные, должна требовать подтверждения, которое агент не может автокомплитить. Типнуть имя volume. OTP на почту. Подтверждение в Telegram. SMS. Out-of-band. Без вариантов.
7.2 Scoped API tokens
Токен для добавления доменов должен иметь права только на добавление доменов. Токен для staging не должен работать на production. Это называется RBAC, и это база, которую забыли, когда кинулись делать AI-native integrations.И которую мы хорошо понимаем в Астре
7.3 Настоящие бэкапы - в другом blast radius
Снапшот в том же volume - это не бэкап. Бэкап - это когда данные физически отделены от источника. Разные диски. Разные регионы. Разные провайдеры. Если для восстановления нужно обратиться к тому же API, который удалил данные - у вас нет бэкапов.
7.4 Safety на уровне API Gateway, а не в промпте
System prompt - advisory. API Gateway - enforcement. Rate-limit на delete-операции. Проверка: «это production?» перед выполнением. Журналирование всех destructive-операций с автоматическим оповещением владельца. Не надейтесь, что модель «прочитает инструкцию и послушается».
7.5 Осознанное управление контекстом
Не сваливать всё подряд в контекст модели. Anthropic в том же блоге пишет:
«Given that LLMs are constrained by a finite attention budget, good context engineering means finding the smallest possible set of high-signal information to include.»
Правила безопасности не должны быть «одной из строчек в system prompt». Они должны быть:
На видном месте в активном контексте
Повторены перед каждым критическим действием
Дублированы на уровне API Gateway, а не только в промпте
Но главное - не надеяться, что суммаризация сохранит критический контекст. Она не сохранит. Это lossy compression. По определению.
8. Вывод
История PocketOS - не про «плохую модель» и не про «плохой Cursor». Это история про то, как индустрия промаркетила AI-агентов быстрее, чем построила архитектуру безопасности для их работы.
Cursor продаёт «Destructive Guardrails». На практике - это пара строчек в system prompt, которые модель может проигнорировать, потому что при сжатии контекста они превращаются в «там вроде были правила».
Railway продаёт AI-native инфраструктуру через MCP. На практике - тот же root-доступ, те же 0 подтверждений на delete, те же бэкапы в том же blast radius. API, спроектированный для 2015 года, продаётся как AI-native в 2026-м.
И всё это опирается на фундаментальное ограничение архитектуры трансформеров: attention - zero-sum игра, attention sinks крадут внимание у релевантных токенов, а context rot - универсальный закон для всех моделей.
Моя теория про сжатие контекста не паранойя. Это если и не точное попадание в механизм катастрофы, то максимально близко к тому что можно увидеть.. Правила и действие разведены по разным чанкам, и ни Cursor, ни Anthropic не имеют работающего решения - только костыли, которые сами признают ненадёжными.
Я за 23 года в инженерии видел много модных подходов, которые разбивались о реальность. Но этот - особенный. Потому что здесь разбивается не код, а доверие. Когда агент пишет признание и говорит «я сам знаю, что нарушил правила, но сделал это» - это не баг, это системная проблема.
И она не лечится промптами.
P.S. Если вы используете Railway в production - сегодня хороший день, чтобы проверить scope ваших токенов, убедиться, что ваши бэкапы не в том же blast radius, и подумать, стоит ли подключать mcp.railway.com к вашей production-инфраструктуре. Пока без safety layer'ов - ответ почти наверняка «нет».
Николай Гусев - старший инженер внедрения в Группе Астра. 23 года в DevOps. Внедряю разное в enterprise, чтобы кормить трёх собак :-).
Хабы: Искусственный интеллект Информационная безопасность IT-инфраструктура Машинное обучение Разработка
Ссылки