Анатомия агента: семь обязанностей обвязки

Авторы изучают зафиксированные версии систем, в основном июльский срез 2026 года. Среди них Claude Code, Codex CLI, Gemini CLI, Mistral Vibe, OpenHands, Aider, mini-SWE-agent, Hermes, Pi, OpenCode и OpenClaw. Claude Code представлен мартовским снимком исходников. OpenClaw включён как контрастный пример шлюза-ассистента; Omnigent рассматривается отдельно как система, управляющая другими обвязками. Поэтому состав выборки влияет на выводы: это намеренно выбранные проекты с разными задачами, а не случайный срез рынка.

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

Агент складывается из модели и обвязки. Семь обязанностей обвязки — цикл работы, интеграция с моделью, инструменты, управление контекстом, безопасность и разрешения, координация, расширения. Фреймворк предоставляет библиотеку для сборки системы; обвязка становится средой, в которой агент действует. Такое разложение помогает обсуждать конкретный механизм, а не сравнивать продукты целиком по одному числу.

Минимальный цикл с bash уже способен решать задачи. Большой объём кода часто обслуживает другие потребности: восстановление после сбоев, взаимодействие с человеком, ограничения доступа и точки расширения. Различаются даже условия завершения работы. Aider проверяет изменения и возвращает ошибки модели, Hermes проверяет непроверенные изменения перед выходом, OpenHands использует дополнительную оценку. Исследование описывает эти варианты, но не выбирает победителя. Важно понять, какую ответственность оставляет человеку каждый из них.

Единый API не устраняет особенности моделей. Одни обвязки тесно связаны с протоколами своего поставщика, другие используют LiteLLM, собственные транспорты или SDK. Оптимизации кеширования, режимов рассуждения и инструкций доступны не только поставщикам моделей. Однако кто-то должен реализовать их, а затем поддерживать при каждом обновлении. Собственная обвязка означает постоянную работу над этим слоем совместимости.

Редактирование файлов делает проблему наглядной. Точное сопоставление текста, специальный формат патчей, каскад менее строгих замен и команды оболочки задают разные контракты действия. OpenCode, например, выбирает инструмент редактирования с учётом семейства модели. Перенести обвязку на новую модель — значит проверить не только доступность вызова, но и привычный ей способ менять код. Это лишь один инструмент, для которого возникают такие различия.

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

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

Откат разговора не гарантирует отката результата работы. Pi хранит ветвящуюся историю без восстановления файлов, Mistral Vibe позволяет восстанавливать их по контрольным точкам, OpenCode использует теневой git. Архитектура должна связывать состояние сессии с рабочей копией. Иначе после возврата к прежнему сообщению агент может видеть диалог об одном состоянии проекта, а работать уже с другим.

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

Проверка разрешений отвечает, можно ли выполнить конкретную операцию; изоляция ограничивает среду её выполнения. Это две самостоятельные части безопасности. В обзоре встречаются правила, классификаторы и обращение к пользователю, а отдельно — песочницы операционной системы и контейнеры. Размер кодовой базы не показывает, есть ли нужная граница доступа. Отсутствие встроенной изоляции может быть сознательным выбором, который переносит её организацию на пользователя.

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

MCP подключает инструменты, навык описывает способ выполнения работы, а хук позволяет детерминированно отреагировать на событие и проверить действие. Ведущий оспаривает попытку вывести большую популярность навыков из небольшого различия покрытия в выбранных системах. Универсальные продукты обычно поддерживают несколько таких механизмов сразу. Он также предлагает пересматривать старые пошаговые инструкции при смене модели и проверять пользу навыков отдельными оценками, а не хранить их неизменными.

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

Авторы не обнаружили общих агентных фреймворков и векторного поиска по коду в изученном корпусе. Это наблюдение ограничено выборкой: другие системы могут быть устроены иначе, а поиск по документации — отдельный случай. Зафиксированные версии позволяют повторить анализ, но не превращают отсутствие механизма в доказательство его бесполезности.

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