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

Александр начинает с различия между рейтингом агентов и исследованием их устройства. Авторы статьи фиксируют версии одиннадцати систем и читают исходный код, чтобы выделить семь обязанностей обвязки. Такой метод показывает, где хранится история, как вызываются инструменты и кто проверяет разрешения. Он не устанавливает, какая архитектура лучше решает задачи: одинакового прогона всех систем нет. Выборка тоже неоднородна — в ней соседствуют продукты поставщиков моделей, минималистичный исследовательский агент и шлюз-ассистент OpenClaw. Claude Code представлен мартовским снимком. Эти границы важны для интерпретации любого общего вывода, особенно утверждений об отсутствующих фреймворках и способах поиска по коду.

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

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

MCP, навыки и хуки рассматриваются как разные точки расширения. Ведущий возражает против вывода о большей популярности навыков по небольшому отличию в выбранной группе систем: универсальные продукты обычно поддерживают несколько механизмов одновременно. Старые инструкции стоит пересматривать при обновлении моделей и проверять отдельными оценками. Повторные срезы исходников показывают заимствование решений между проектами, а SDK, каталоги дополнений и корпоративные политики — движение к платформам. В финале Александр предлагает использовать атлас как набор гипотез: выбрать подсистему, изменить один подход и проверить результат на своих задачах. Архитектурная привлекательность не заменяет наблюдаемой пользы. Таймкоды составлены по аудиоверсии Podster; совпадение временной шкалы с YouTube отдельно не измерялось.