У агентных систем понемногу появляется собственная архитектурная дисциплина. Два свежих исследования показывают это с разных сторон, и вместе они складываются в довольно ясную картину.
Разные команды приходят к одному устройству
Первая работа разбирает три независимые реализации агентного харнесса и находит между ними неожиданное сходство. Зрелые системы приходят к одному и тому же набору: воспроизводимая история выполнения, явное состояние, постепенная подача контекста, отдельные профили под конкретные модели и внятные точки расширения.
Конвергенция такого рода обычно означает, что люди нащупали не удачный приём, а свойство самой задачи. Харнесс перестал быть обвязкой вокруг модели. Он стал управляющим слоем.
Здесь же видно, где этот слой пока не достроен. Наблюдаемость не равна доказуемости. Сохранить трассу выполнения мы умеем. А вот независимо показать, что именно эта версия модели, эта память, эта политика и этот набор инструментов породили конкретное действие, получается далеко не всегда. Разница между «у нас есть логи» и «мы можем доказать» становится заметной ровно в тот момент, когда кто-то спрашивает, почему агент так решил.
Модель выбирается не один раз
Вторая работа заходит с другой стороны. Её авторы предлагают выбирать модель не единожды на всю задачу, а на каждом шаге, ориентируясь на прогресс и оставшийся бюджет.
Логика простая: сложность внутри длинной агентной задачи не постоянна. Разобрать входные данные, свести таблицу, придумать план, проверить чужой результат это работа разного веса. Закреплять за агентом одну модель на весь путь означает переплачивать на простых шагах и недотягивать на сложных.
Привычная схема выглядела так:
- агент А работает на сильной модели;
- агент Б работает на дешёвой.
Предлагаемая устроена иначе: текущее состояние, прогресс, бюджет и сложность шага определяют, какая модель отвечает именно сейчас.
Что из этого следует
Обе работы про одно и то же смещение. Архитектура агента всё меньше зависит от конкретной языковой модели и всё больше от качества управляющего слоя.
Модель становится вычислительным ресурсом. Харнесс становится системой управления этим ресурсом. Примерно так же когда-то перестали выбирать процессор под задачу и начали писать планировщик.
Отсюда и следующий круг вопросов. Не «какая модель лучше», а:
- как хранить состояние;
- как маршрутизировать шаги;
- как менять модель по ходу работы;
- как воспроизвести выполнение;
- как объяснить принятое решение;
- как ограничить и проверить автономию.
Если совсем коротко, направление движения такое: сначала архитектура строилась вокруг модели, потом вокруг агента, теперь вокруг харнесса.
Чем это полезно на практике
Я бы не спешил переписывать работающие системы под пошаговую маршрутизацию. Выигрыш от неё появляется там, где задачи длинные и разнородные, а счёт за модели заметен в бюджете. На коротких сценариях это усложнение ради усложнения.
А вот доказуемость стоит поднять раньше, чем захочется. Она ничего не стоит на старте и почти неподъёмна потом. Записывать вместе с результатом версию модели, снимок политики, состав инструментов и то, что лежало в контексте, дешевле в первый день, чем восстанавливать это через полгода по чужим логам.
Проверить себя можно одним вопросом: сумеете ли вы повторить вчерашний прогон и объяснить, почему агент выбрал именно это действие. Пока ответа нет, разговор о смене моделей на каждом шаге преждевременный.
Работы
- The Empire, Long Divided, Must Unite: Architectural Convergence in Three LLM Agent Harnesses, arxiv.org/abs/2608.23953
- ProgRouter: Online Progress-Guided Orchestration for Multi-Agent LLM Workflows, arxiv.org/abs/2608.25992