Двадцать третьего августа исследования разобрали популярную формулу «добавим ещё агента и tools» на реальные издержки. Второй агент приносит coordination tax. Валидный tool call не объясняет, был ли внешний effect закоммичен до потери ответа. Длинная траектория накапливает собственные ошибки, а большой artifact занимает context раньше, чем становится понятно, нужен ли он вообще.
Масштабирование агентной системы оказывается не умножением одинаковых исполнителей. Каждый новый участник, шаг и источник состояния требует отдельного контракта координации и восстановления.
Multi-agent systems
Два агента платят измеримый налог только за необходимость договориться
EMNLP-paper проверила 32 задачи, решаемые одной моделью, на 11 моделях семи providers. Авторы формализуют team-decentralisation loss и видят повторяющуюся цепочку: участник делает ungrounded claim, не запрашивает данные партнёра, не объединяет две позиции и принимает общий ответ без re-derivation.
Tax снижается с capability, а targeted prompt intervention закрывает часть разрыва. В heterogeneous pair результат тянется к более сильной модели, а не к простому среднему.
Задачи искусственные и two-player; production-система с shared state и детерминированными tools устроена иначе. Paper не доказывает, что один агент всегда лучше. Она доказывает более скромное: teamwork не бесплатен. Eval multi-agent схемы должен сравнивать её с сильным одиночным baseline после учёта coordination failures и дополнительных вызовов.
Источник: collaboration tax.
MCP-server становится не только tool, но и training environment
MCP-Universe RL разделяет environment orchestration и rollout orchestration. Первый слой поднимает и изолирует MCP environments через container backend, второй перекрывает длинные trajectories, чтобы GPU не простаивал в ожидании tools. Training backend заменяем: названы veRL и slime.
Авторы одной конфигурацией обучили software-engineering, deep-research и general tool-use agents на gpt-oss-20b и сообщают рост reward во всех трёх случаях. Abstract не даёт абсолютных результатов, throughput и стоимости. «Любой MCP tool» также не гарантирует безопасный reset и детерминированный grading.
Сдвиг важен: interface, созданный для runtime integration, превращается в substrate для RL. Но training требует от tool больше, чем production call: воспроизводимого initial state, изоляции side effects и возможности честно начать следующий rollout заново.
Источник: MCP-Universe RL.
MoE router traces используются как сигнал поведения software agent
Risa читает native MoE routing как behavioral-role signal. Внутри trajectory он стимулирует разные способы исследования и согласование перед patch, а между независимыми runs выбирает candidate по agreement на информативных позициях изменения.
На SWE-bench Verified macro resolved rate gpt-oss family вырос с 44,9% при uniform sampling до 48,2%. На полном наборе Qwen3.6 метод превзошёл uniform и сравнялся с text consensus.
Это preprint для open-weight sparse MoE; закрытые и dense модели не отдают такой сигнал. Разница 3,3 пункта не является универсальным «ростом на 7%». Интереснее, что внутренняя телеметрия router перестаёт быть деталью implementation и помогает управлять diversity и arbitration agent runs без отдельного внешнего judge.
Источник: Risa.
Tool interfaces и recovery
Синтаксически правильный tool call может оставить неразрешимое состояние
Agent-First Tooling различает callability и operability. Представим платёж: операция закоммичена, но response потерян. Та же transport error возникает и когда ничего не произошло, хотя безопасное продолжение противоположно.
Авторы предлагают selective capability discovery, execution lifecycle, явную семантику external effects, machine-readable results и postcondition verification. AFT-Bench фиксирует backend, initial state и injected failure, меняя только интерфейс. Итоговых scores в abstract нет.
Tool schema описывает аргументы, но не восстановление. Production contract нужны idempotency key, receipt, state inspection и точный ответ на вопрос, можно ли повторить действие. Без них агент либо дублирует side effect, либо навсегда застревает перед уже выполненным шагом.
Источник: Agent-First Tooling.
Benchmark может сделать recovery невозможным своим способом grading
Исследователи отделили правильный выбор tool от правильных arguments и сравнили teacher-forced context с free-running на пяти open-weight моделях и задачах глубиной до восьми шагов. К шестому шагу нормированные L6 около 0,686 означали потерю примерно 70% clean-context capability.
Но fixed-gold exact match сам скрывал восстановление: после первого расхождения модель могла попасть в допустимое новое состояние, где ожидаемые benchmark- константы ей больше не показывали. Conditional-on-state rescoring вернул измеримые оценки без новых model calls.
Это synthetic tasks и специальная метрика, не общий success rate всех агентов. Методический вывод сильнее headline: свободная траектория не обязана совпадать с единственной gold path. Eval должен проверять допустимость текущего состояния и продолжения, иначе объявит ошибкой реальное recovery.
Источник: invocation-level reliability.
Context и память
SparseRead решает, стоит ли пускать artifact в context до его чтения
SparseRead включает Read Gate, сменные Reader Backends и stateful protocol с refinement, verification, stopping и fallback. На шести frontier-моделях, пяти workloads и трёх frameworks авторы сообщают снижение token volume до 92,9% и wall time до 89% при сохранённом или улучшенном качестве.
«До» — максимум, а не среднее; workloads и graders определяют выигрыш. Но admission control поставлен в правильной точке. Post-hoc compression уже потратила время и context на лишний artifact. Read Gate сначала решает, какой фрагмент нужен, а полный источник оставляет доступным для проверки и fallback.
Большой tool result — не бесплатное знание. Он может вытеснить важные инструкции, увеличить latency и спрятать evidence в массе текста.
Источник: SparseRead.
Память фильтруют в момент записи, а не только при retrieval
Dual-layer memory классифицирует вход как no-write, write-new или write-update, отправляя сложные случаи из модели 1.7B в 8B. Затем часть внешней памяти можно периодически internalize через supervised fine-tuning.
Авторы заявляют до 68% удаления redundant memory, escalation менее половины входов и более 98% QA Exact Match относительно хранения всего. Code и data обещаны лишь после acceptance; parametric consolidation несёт риск forgetting и подходит не каждому production agent.
Сильная мысль — corpus растёт из-за плохой write policy. Если сохранять каждую переформулировку одного факта, retrieval позже тратит effort на уборку мусора. Memory governance начинается до записи: нужно решить, появилось ли новое знание, обновление или ничего долговечного.
Источник: dual-layer memory.
Robustness
Повтор одного prompt почти ничего не говорит об устойчивости формулировки
Audit проверил три tool-calling endpoints двух providers на BFCL multiple и parallel tasks. При temperature 0 ever-flip fractions были всего 0,7%, 2,0% и 2,7%, а correlations — 0,997, 0,966 и 0,961. Но семантически эквивалентные изменения prompt дали median paired standard deviation в 11–58 раз выше обычного rerun noise.
Всего три endpoints и один benchmark family; сам набор perturbations тоже нужно проверять на эквивалентность. Отношения нельзя переносить на любую agent-задачу.
Практический вывод: deterministic rerun одного текста измеряет repeatability, но не robustness. Production eval должен варьировать порядок, формулировку и неважные детали запроса. Иначе стабильная модель оказывается стабильной только для одной магической строки.
Источник: audit prompt robustness.
Главный технологический сдвиг выпуска
Двадцать третьего августа масштабирование агентов оказалось задачей контрактов.
Партнёры должны договориться, environment — честно сбрасываться, tool — сообщать external effect, benchmark — признавать допустимое recovery, reader — ограничить context, memory — решить, что вообще сохранять.
Добавление ещё одной модели не исправляет ни один из этих швов автоматически. Оно лишь создаёт ещё одного участника, чьё состояние и ошибки системе придётся понимать.
Что обсудить с технической командой
- Измеряли ли мы multi-agent схему против сильного одиночного baseline с учётом всех дополнительных вызовов?
- Может ли каждый training environment воспроизводимо сбросить side effects перед новым rollout?
- Есть ли у опасных tools idempotency key, receipt и postcondition check?
- Допускает ли eval альтернативную валидную trajectory и настоящее recovery?
- Какая write policy не даёт памяти бесконечно хранить дубликаты одного знания?