3. Архитектура и эксплуатация агентных систем
5. AlphaDiana: один и тот же reasoning model может отвечать хуже после добавления harness
Что произошло. Исследователи предложили AlphaDiana — измерительную систему для сравнения моделей и harness при контролируемых настройках tools, skills, памяти и повторного использования файлов. Она сохраняет собственный цикл выполнения каждого harness, но позволяет проводить компонентные вмешательства.
Почему важно. Показатель «агент решил X% задач» смешивает способности модели и влияние окружения. Дополнительный tool call может исправить ранее неверный ответ, но также испортить ответ, который модель уже знала.
Что показали данные. Академическая работа сравнивает три открытые модели и три открытых harness на пяти задачниках с проверяемыми ответами; для двух моделей добавлены два интерактивных benchmark. Универсального прироста от harness, skills или сохранённой истории не найдено. Авторы предлагают учитывать не просто токены на запуск, а токены на правильный ответ. Из-за различий задач результаты не означают, что любой конкретный harness бесполезен.
Что нужно уже понимать: ablation; harness-native execution; paired evaluation; answer accuracy; tokens per correct answer.
Что изменить. Для выбора agent framework запускать одну модель на одинаковых задачах без harness и с каждым вариантом harness; фиксировать как исправленные, так и испорченные ответы. Стоит провести внутренний эксперимент.
Дата и первоисточник: препринт 14 октября, новая подборка 16 октября; https://arxiv.org/abs/2610.20675
6. CODA: агент, обученный вместе с каталогом skills, может терять почти весь выигрыш после его редактирования
Что произошло. Исследование Evolving Together, Failing Apart ввело аудит CODA для совместно обученных policy и skill bank. Авторы имитируют обычную production-ситуацию: после обучения описания навыков переписывают, сокращают или частично портят.
Почему важно. Оптимизация модели под конкретный каталог создаёт скрытую зависимость от точных формулировок. Обновление инструкции без переобучения модели может быть фактическим изменением поведения системы.
Что показали данные. Четыре метода на пяти benchmarks (шесть настроек) теряли в худших проверенных вариантах 4,9–12,6 процентного пункта success rate относительно исходной связки. Это уничтожало 52–93% выигрыша skills относительно варианта без них. Даже семантически эквивалентная переформулировка меняла исходы заметно чаще, чем обычный шум генерации. Важно: худший вариант оставался лучше no-skill baseline; вывод не «skills вредны», а «их эффект хрупок».
Что нужно уже понимать: skill-policy co-evolution; distribution shift; worst-case success; regression eval; semantic perturbation.
Что изменить. Версионировать skills вместе с model/harness configuration и запускать регрессионные тесты на переформулировках. Не обновлять общий skill registry без оценки затронутых агентов.
Дата и первоисточник: препринт 14 октября, новая подборка 16 октября; https://arxiv.org/abs/2610.20845
7. ARIA: runtime-ремонт multi-agent систем вместо полного перезапуска
Что произошло. ARIA учит небольшую модель определять, когда вмешаться в уже работающую multi-agent систему и как заменить ошибочный фрагмент продолжения. Для обучения собраны более 24 тыс. траекторий четырёх frameworks, шести benchmarks и восьми базовых моделей; из них выделено 3 953 пары «сбой — проверенное исправление». Авторы опубликовали код.
Почему важно. В распределённой агентной системе ошибка одного участника распространяется на других. Внешний supervisor, работающий по traces, может предотвратить потерю всей многошаговой работы, но сам создаёт риск вредного вмешательства.
Что показали данные. Авторы отдельно измеряют success rate и harmful intervention rate, сравнивая post-hoc repair с вмешательством в живой запуск при одинаковом execution budget. ARIA показывает более выгодное сочетание успеха и вредных вмешательств на исследованных frameworks, включая проверки переноса на незнакомую систему. Это академический эксперимент, а не проверка на реальном корпоративном SLA.
Что нужно уже понимать: multi-agent coordination; runtime amendment; execution trace; harmful intervention; continuation replacement.
Что изменить. Для долгих multi-agent задач логировать точку принятия решения и возможность безопасного восстановления. Сначала сравнить supervisor с простым retry/rollback; дополнительная модель не обязана окупаться на коротких задачах.
Дата и первоисточники: препринт 14 октября, новая подборка 16 октября; https://arxiv.org/abs/2610.20780 ; код — https://github.com/LabRAI/ARIA
8. RealtimeBench: более сильная, но медленная модель проигрывает при движущемся времени
Что произошло. RealtimeBench проверяет 180 игровых задач шести типов, в которых среда продолжает меняться, пока агент думает. Авторы сравнили режим с остановленным временем и live clock, затем разделили систему на медленного teacher, улучшающего инструкции между попытками, и быстрого student, действующего во время игры.
Почему важно. Для голосовых, браузерных, торговых и операционных агентов правильное решение, полученное слишком поздно, может быть бесполезным. Latency здесь становится частью качества, а не только UX-метрикой.
Что показали данные. В live-режиме средний нормализованный прогресс GPT-6.1 Sol — 1,51/100 при средней задержке ответа 18,97 с; у более быстрого Jev — 13,51/100 при 0,52 с. В остановленной среде Sol был сильнее на большинстве игр. Два раунда офлайн-обучения инструкций подняли Jev с 13,51 до 24,19. Это игровой академический benchmark, а не доказательство преимуществ Jev для деловых задач.
Что нужно уже понимать: wall-clock evaluation; latency-quality trade-off; teacher-student architecture; offline adaptation; deadline.
Что изменить. Для задач с ограничением по времени вводить deadline-aware model routing: быстрая модель выполняет действие, сильная анализирует ошибки асинхронно. Проверять качество при реальных задержках API, а не только в статических evals.
Дата и первоисточник: препринт 14 октября, новая подборка 16 октября; https://arxiv.org/abs/2610.20665
9. Новые данные: старое рассуждение может мешать агенту принять свежие доказательства
Что произошло. Исследователи сравнили два способа ответа, когда сохранённая reasoning trace противоречит новым документам: продолжать прежнее рассуждение или сделать отдельный вызов модели с актуальными evidence.
Почему важно. В длинных задачах агент может продолжать защищать устаревший вывод даже после обновления retrieval. Это failure mode context engineering, особенно важный для финансовых, юридических и исследовательских систем.
Что показали данные. На HotpotQA и MuSiQue, для семейств gpt-oss, Gemma4 и Qwen3, отдельный answer call повышал долю следования текущим доказательствам на 29,9–60,6 процентного пункта относительно продолжения прежней цепочки. При этом удаление trace ухудшало точность в обеих конфигурациях: сохранение полезного контекста и отказ от устаревшего вывода — разные задачи.
Что нужно уже понимать: reasoning trace; evidence following; RAG; stale context; answer separation.
Что изменить. Для workflow с обновляющимися источниками отделять накопление гипотез от финального ответа по свежим данным; добавить тесты с намеренно противоречащими версиями документов.
Дата и первоисточник: препринт 14 октября, новая подборка 16 октября; https://arxiv.org/abs/2610.20805
10. Насыщенный benchmark ещё можно использовать — если оценивать траекторию, а не только pass/fail
Что произошло. Работа Evaluating Model Capabilities After Benchmark Saturation проверила, можно ли извлечь сигнал из успешных траекторий на тестах, где многие модели уже получают почти максимум. Сравнивались pairwise judging, абсолютные оценки трасс и автоматические признаки.
Почему важно. По мере насыщения leaderboard разница между моделями исчезает в конечном проценте успешных задач, хотя способы их решения и затраты остаются разными.
Что показали данные. В ретроспективной академической проверке попарная оценка успешных траекторий уменьшила ошибку предсказания результатов на ещё не насыщенных заданиях в 5,3 раза по сравнению с использованием одного итогового балла. Однако перенос ломался на некоторых сдвигах распределения, включая появление новых reasoning models. Это не новая универсальная шкала интеллекта.
Что нужно уже понимать: benchmark saturation; held-out evaluation; pairwise judge; trajectory; distribution shift.
Что изменить. При равных success rate моделей сравнивать traces, tool use, стоимость, задержку и устойчивость к новым задачам; не выбирать поставщика по одной насыщенной таблице.
Дата и первоисточник: препринт 14 октября, новая подборка 16 октября; https://arxiv.org/abs/2610.20667
11. Не каждый сложный вопрос требует ещё одного reasoning rollout
Что произошло. Авторы Confidence-Calibrated Inference Expansion предложили контроллер, который выбирает между завершением ответа, fallback и дополнительными вычислениями на основании калиброванной уверенности и цены продолжения.
Почему важно. Больше inference-time compute часто повышает качество, но расходы и latency растут на всех запросах, включая простые. Правильный routing решает, где дополнительное размышление действительно окупится.
Что показали данные. На отложенных тестах расширения и пересмотра ответов контроллер уменьшил нормализованный online compute примерно на 30% и 16% относительно настроенных фиксированных стратегий при более высокой измеренной utility. В сравнениях с fitted Q на четырёх seeds Qwen3-8B преимущество по utility было небольшим и неоднозначным. Это академическая оценка контроллера, не гарантированное снижение API-счёта.
Что нужно уже понимать: test-time compute; calibrated confidence; fallback policy; expected utility; model routing.
Что изменить. Для дорогих agent workloads измерить долю задач, где дополнительный verifier/retry реально исправляет ошибку, и ввести бюджеты вычислений по классу риска.
Дата и первоисточник: препринт 14 октября, новая подборка 16 октября; https://arxiv.org/abs/2610.20836
12. Саморазвитие skills без judge: проверка двумя независимыми вычислениями
Что произошло. Исследование A Self-Improving Agent that Grows its Own DSL описывает агента, который расширяет собственный язык точных операций над данными. Новый оператор допускается только после согласования независимых реализаций и проверки инвариантов, без LLM-as-judge и без готового ответа для каждого случая.
Почему важно. Для денежных сумм, реестров и структурированных операций правильность нельзя подменять убедительным объяснением модели. Ограниченный исполняемый язык и инварианты могут дать более надёжную архитектуру, чем свободный tool calling.
Что показали данные. Авторы сообщают, что механизм отклонил 138 из 138 намеренно ошибочных вариантов операторов в проверке с независимым эталоном; число решаемых вопросов в начальном домене примерно утроилось, в двух дополнительных доменах выросло более чем в 10 и почти 20 раз. Это исследование на ограниченных DSL и схемах, не доказательство безопасности произвольного самописного кода.
Что нужно уже понимать: domain-specific language; invariants; independent implementation; exact computation; operator induction.
Что изменить. Для финансовых и операционных агентов обсудить ограниченный набор проверяемых операций вместо прямого доступа к произвольным скриптам. Пока ранняя стадия.
Дата и первоисточник: препринт 14 октября, новая подборка 16 октября; https://arxiv.org/abs/2610.20809
