3. Архитектура и эксплуатация агентных систем
Anthropic использовала около 950 параллельных агентов для поиска новой биологической системы
Что произошло. Anthropic открыла life-sciences research group и лабораторию и описала один из первых экспериментов: Claude-agents искали необычные reverse transcriptase systems в больших базах DNA. При высокоуровневом human prompt агенты собирали семейства белков, анализировали genomic neighborhood, фильтровали кандидатов и писали human-readable reports. В результате был найден ранее нехарактеризованный system, получивший название array-associated reverse transcriptases (ART), с repeat-array, напоминающим CRISPR.
Почему это важно. Это редкий пример, где massive multi-agent fan-out приводит не к benchmark score, а к новой научной гипотезе, которую затем можно проверить физическим экспериментом. Архитектура хорошо подходит для embarrassingly parallel search: сотни агентов исследуют разные ветки, а expensive human verification остаётся на финальных кандидатах.
Что показали данные. Примерно 950 агентов работали 21 час и использовали 210 млн токенов. Они собрали более 200 тыс. RT, выделили 3 500 новых candidate systems и сузили их до 20 отчётов для human review. Первые лабораторные данные показывают, что ART repeat array экспрессируется как набор коротких RNA, но функция ART пока неизвестна. Все wet-lab эксперименты выполняют люди; Anthropic прямо называет результат ранним.
Что нужно уже понимать: multi-agent fan-out, genome mining, hypothesis triage, wet-lab validation, human verifier.
Что это может изменить. Для R&D workflows имеет смысл искать задачи, где дешёвое параллельное исследование пространства гипотез можно отделить от дорогого физического или экспертного verifier. Метрика здесь — не число agent outputs, а стоимость одного кандидата, прошедшего независимую проверку.
Дата: 23 сентября.
Первоисточник: https://www.anthropic.com/news/claude-discovers-novel-enzyme-system
Grow the Harness, Not the Context: повторяющееся reasoning можно превратить в исполняемый control logic
Что произошло. Исследователи предложили Growing Harness: agent начинает с почти strategy-free scaffold, а failures локализуются по execution traces и используются для небольших правок executable harness code. Новая версия принимается только если held-out regression gate не ломает ранее успешные capabilities.
Почему это важно. Большинство agents снова и снова тратят токены на одинаковые control decisions: как искать, в каком порядке вызывать tools, когда retry. Работа предлагает переносить устойчивые решения из prompt/context в код и оставлять LLM task-specific semantic reasoning.
Что показали данные. На BrowseComp-Plus и WebArena-Verified с deployment models от 4B до 120B Growing Harness дал лучший mean success в 5 из 6 model/benchmark combinations, а в шестом отстал на 0,7 п.п. Относительно обычного Tool-Calling agent число LLM calls снизилось на 76,0–91,8%, inference cost — на 74,4–98,6%. На WebArena-Verified success оставался 44,7–45,3% на разных размерах моделей, тогда как Tool-Calling baseline падал до 6,7% на 4B model. Это preprint, не peer-reviewed.
Что нужно уже понимать: agent harness, execution trace, failure-guided repair, held-out regression gate, WebArena.
Что это может изменить. Если agent много раз решает одинаковые control problems, стоит искать, какие решения можно вынести в deterministic/reusable code. Это может снизить стоимость сильнее, чем переход на более дешёвую модель.
Дата: 22 сентября; свежий research release текущего окна.
Первоисточник: https://arxiv.org/abs/2609.26760
Agensh: количество агентов становится отдельной scaling axis — вплоть до 1 024 workers
Что произошло. Agensh убирает центрального orchestrator. Workers асинхронно читают общий workspace, сами claim'ят subtasks, обмениваются findings, проверяют результаты и merge'ят progress. Shared context хранит reusable findings и intentions.
Почему это важно. Центральный planner сам может стать bottleneck при большом fan-out. Decentralized coordination предлагает масштабировать wall-clock intelligence количеством параллельных workers, а не только моделью или длиной context.
Что показали данные. На пяти самых сложных задачах ProgramBench с GPT-5.6 Sol (high) рост от 1 до 128 агентов увеличил mean final test-pass rate с 19,31% до 28,78% — около +49% относительно. На задаче pandoc рост от 1 до 1 024 агентов поднял final pass rate с 33,89% до 55,06%. Ограничение существенное: всего пять задач и один model family; paper — preprint.
Что нужно уже понимать: decentralized orchestration, asynchronous workers, shared workspace, fan-out, ProgramBench.
Что это может изменить. Multi-agent scaling стоит тестировать только на задачах, которые действительно можно декомпозировать. Помимо quality нужно считать wall-clock, duplicate work, conflicts, token spend и merge overhead.
Дата: 22 сентября; свежий research release текущего окна.
Первоисточник: https://arxiv.org/abs/2609.26781
CliffCompaction: context management становится алгоритмом, а не просто summary prompt
Что произошло. CliffCompaction предлагает autocompaction для long-horizon coding agents: система только удаляет или обрезает старый content, но не перефразирует его, и никогда не compact'ит уже compacted output. Цель — уменьшить накопление context drift между сессиями.
Почему это важно. Длинная работа агента часто упирается не в maximum context window, а в стоимость многократного повторения истории и ошибки summary. Compaction policy становится самостоятельным quality/cost layer.
Что показали данные. Авторы сообщают до 50% снижения стоимости при ограниченном context без деградации Terminal-Bench; более дешёвые rollouts позволили получить свыше +10 п.п. на Terminal-Bench менее чем за стоимость двух full-context runs. В parallel test-time scaling Kimi K2.6 с CliffCompaction в экспериментах авторов сравнялась с Opus 4.7 и обошла Opus 4.6/GPT-5.3 Codex при меньшей стоимости. На KernelBench kernel speedup вырос до 2,23× после 200 steps и 3,58× после 400. Это preprint; сравнения зависят от harness и pricing assumptions.
Что нужно уже понимать: context compaction, context drift, test-time scaling, Terminal-Bench, state persistence.
Что это может изменить. Если coding agent регулярно пересекает несколько context windows, стоит benchmark'ить compaction strategy отдельно от модели. Critical state лучше хранить структурированно вне свободного conversation summary.
Дата: 22 сентября; свежий research release текущего окна.
Первоисточник: https://arxiv.org/abs/2609.26779
Tool-use benchmark может измерять serving stack, а не модель
Что произошло. Работа Measuring the Serving Stack Instead of the Model показывает, что одинаковая model/tool schema ведёт себя по-разному в Ollama, llama.cpp, vLLM и SGLang. Часть stacks возвращает native tool_calls, часть — text, а некоторые модели в определённых конфигурациях отвергаются ещё до inference.
Почему это важно. Если harness не различает «модель не вызвала tool», «сервер отклонил запрос», «parser сломался» и «retry закончился», leaderboard может приписать модели ошибку инфраструктуры. Для open/local models serving configuration — часть evaluated system.
Что показали данные. Авторы показывают, что constrained decoding может убрать parse failures, но вызвать non-termination; turn-pooled и per-instance оценки в их experiments расходились до примерно 55 процентных пунктов. В одном harness server rejection и retry exhaustion могли ошибочно превращаться в кажущиеся 0% model fidelity. Это preprint.
Что нужно уже понимать: tool-call protocol, serving stack, constrained decoding, structured failure metadata, evaluation confound.
Что это может изменить. Во внутренних evals фиксируйте version/configuration serving layer, tool protocol и failure taxonomy. Для self-hosted models полезно прогонять одну и ту же модель через несколько serving stacks до вывода о её tool-use quality.
Дата: 22 сентября; свежий research release текущего окна.
Первоисточник: https://arxiv.org/abs/2609.26693
