← Все тексты · Все теги · Лента Atom

Равное право подводить итоги и почему сжатие от хоста — плохая опора

Длинный диалог с ассистентом упирается в лимит контекста. Отсюда почти всегда следует вопрос: что из переписки считать «сохранённым» — и кто имеет право это зафиксировать. Этот текст про два разных ответа: явное подведение итогов по договорённости и сжатие, которое делает хост (в нашем случае — Cursor и подобные среды). Первое можно сделать честным; второе почти неизбежно непрозрачно и плохо стыкуется с паритетом «человек ↔ агент».

Два смысла: подведение итогов и «суммаризация» среды

Подведение итогов по договорённости — это когда участники сознательно договариваются подвести итоги: что решили, что осталось открытым, какие следующие шаги. Её можно проверить: есть согласованный текст, экспорт или ссылка на файл. Инициировать её может и человек, и агент — это симметричное право, не «привилегия» одной стороны.

Сжатие истории как поведение среды (часто называют «суммаризацией») — другое: это когда модель или хост сжимает историю ради продолжения сессии. Внутри чата это может выглядеть как «короткое резюме» вместо полного треда. У этого резюме часто нет стабильного адреса на диске, его нельзя так же просто процитировать и оспорить построчно, как исходный лог или согласованный markdown.

Путать эти два типа — значит путать инструмент совместной работы и технический компромисс платформы.

Почему паритет требует явной итоговой дисциплины

Паритет в нашем смысле — не «равные голоса» в абстракции, а общая опора на проверяемые артефакты: тесты, логи, файлы репозитория, читаемый экспорт переписки. Когда итоги явно согласованы, можно отделить договорённость от воспоминания модели о том, что было в чате.

Если же итогом становится сжатие, которое делает хост, то:

  • источник правды смещается внутрь недоступного тебе контура;
  • пропорции (что важно, что выбросили) задаёт не твоя инженерная воля, а эвристика среды;
  • агенту в новой сессии подсовывают уже не «переписку», а посредника — с риском смещения смысла и потери нюансов.

То есть «паритет по фактам» ломается ровно там, где факт не извлекается из файла, а восстанавливается из сжатого представления.

Почему «сжатие от Cursor» — плохой главный план

Здесь не обвинение продукта: у любого хоста есть бюджет контекста, и без сжатия длинные сессии физически не живут. Проблема в том, полагаться на это сжатие как на память.

Оно непрозрачно: ты не контролируешь, какие фразы исчезнут, а какие останутся в «кратком пересказе для модели». Оно не подписано как твой документ: это не commit, не письмо себе, не согласованный с агентом текст. Оно не заменяет экспорт в файл, если тебе нужна цитируемость и воспроизводимость.

Отсюда практический вывод: сжатие хоста — допустимый риск инфраструктуры, но не доверенный канон для длинной дуги и для командных договорённостей.

Что с этим делать (рабочая схема)

  1. Сырой транскрипт на диске (*.jsonl в agent-transcripts) — то, что среда уже записала; его можно найти и не прогонять через глаз модели как единственный источник.
  2. Читаемый экспорт — скрипт или команда IDE, который превращает jsonl в markdown, пригодный для чтения и цитирования.
  3. Краткое резюме и согласование — кто что понял, что зафиксировать в репозитории или в KB.

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

Бэкап и границы

Здравый смысл простой: не ставить read-only на живой каталог, куда Cursor пишет транскрипты — иначе страдает сам процесс. Разумнее бэкапить наружу (git, архив, отдельный диск) и выносить важное в канон или в заметки, а не надеяться, что хост всегда сохранит длинную историю в удобоваримом виде.

См. также


Итого: равное право подводить итоги — это право инициировать и вести их явно и с опорой на файл; непрозрачное сжатие — это не замена этому слою, а ограничение платформы, которое стоит обходить дисциплиной экспорта, а не доверять как памяти.