Это перевод хорошей статьи про базу того, как устроены кодинг-ассистенты и что для них важно: что такоехарнесси харнесс-инжиниринг,в чем разница просто агентной обвязки и кодинговой, что такое компактизация и почему та же самая модель в консольке ощущается мощнее, чем просто в веб-чате.
Сильного хардкора и больших откровений в ней нет, но это отличный материал для старта изучения архитектуры кодинг-ассистентов и лучшего понимания, как оно работает внутри.
В этой статье я хочу разобрать общую архитектуру кодинг-агентов и агентныххарнессов: что это такое, как они работают и как разные части складываются в единую систему на практике. Мои читатели часто спрашивают об агентах — решил написать справочный материал, на который смогу ссылаться.
Агенты стали важной темой, потому что большая часть прогресса в практических LLM-системах связана не только с улучшением самих моделей, а тем, как мы их используем. Во многих реальных приложениях система вокруг LLM — инструменты, управление контекстом, память — играет не меньшую роль, чем сама модель. Этим и объясняется, почему такие системы, как Claude Code или Codex, в консоли ощущаются значительно мощнее, чем те же модели в обычном чат-интерфейсе.
В этой статье я опишу шесть основных строительных блоков кодинг-агента.
Claude Code, Codex CLI и другие кодинг-агенты
Скорее всего, вы знакомы с Claude Code или Codex CLI. Если коротко: это агентные инструменты для написания кода, которые оборачивают вокруг LLM в прикладной слой, называемыйагентный харнесс(agenticharness) — чтобы работа с кодом была удобнее и эффективнее.
Кодинг-агенты заточены под задачи разработки. Ключевое здесь — не только выбор модели, но и все окружение: контекст репозитория, дизайн инструментов, стабильность кэша промптов, память и непрерывность долгих сессий.
Это важно различать. Когда речь заходит о способностях LLM к написанию кода, люди нередко смешивают воедино и саму модель, и ее поведение при рассуждениях, и готовый агентный продукт. Прежде чем углубляться в детали кодинг-агентов, кратко поясню разницу между более широкими понятиями: LLM, рассуждающими моделями(reasoning-моделями)и агентами.
О связи между LLM, reasoning-моделями и агентами
LLM — это базовая модель предсказания следующего токена. Рассуждающая модель — тоже LLM, но обученная и/или настраиваемая через промпт тратить больше вычислений при инференсе: на промежуточные рассуждения, их верификацию и перебор вариантов ответа.
Агент — это слой поверх модели, а по сути — управляющий цикл вокруг нее. Получив цель, агентный слой(или харнесс)решает: что проверить следующим, какие инструменты вызвать, как обновить состояние и когда остановиться.
Грубо говоря, связь такова: LLM — это двигатель, reasoning-модель — прокачанный двигатель (мощнее, но дороже в эксплуатации), а агентный харнесс помогает нам этот двигатель использовать. Аналогия неточная, потому что обычные и reasoning-LLM можно применять и напрямую (в чат-интерфейсе или python-сессии), но суть идеи она передает.
Иными словами, агент — это система, которая многократно вызывает модель внутри некоторой среды.
Итого, коротко:
- LLM: сырая модель
- Reasoning-модель: LLM, оптимизированная для вывода промежуточных цепочек рассуждений и более частой самопроверки
- Агент: цикл, использующий модель вместе с инструментами, памятью и обратной связью от среды
- Агентный харнесс: программный каркас вокруг агента, который управляет контекстом, инструментами, промптами, состоянием и потоком управления
- Кодинг-харнесс: частный случай агентного харнесса; то есть специализированный харнесс для разработки ПО, который управляет контекстом кода, инструментами, исполнением и итеративной обратной связью
В этом же контексте встречаются еще два популярных термина: агентный харнесс и (агентный) кодинг-харнесс. Кодинг-харнесс — это программный каркас вокруг модели, помогающий ей эффективно писать и редактировать код. Агентный харнесс — понятие пошире, не привязанное к коду (например, OpenClaw). Codex и Claude Code можно считать кодинг-харнессами.
В общем, лучшая LLM дает лучшую основу для reasoning-модели (которая требует дополнительного обучения), а харнесс позволяет выжать из этой reasoning-модели максимум.
Конечно, LLM и reasoning-модели способны решать задачи по написанию кода и без харнесса, но кодинг — это лишь отчасти про предсказание следующего токена. Значительная часть работы разработки — это навигация по репозиторию, поиск по коду, просмотр определений функций, применение диффов, запуск тестов, изучение ошибок и удержание всего нужного в контексте. (все разработчики знают, что это серьезная умственная работа — и именно поэтому нас так раздражают отвлечения во время кодинга :)).
Главный вывод: хороший кодинг-харнесс за счет управления контекстом и многим другим вещам способен сделать как обычную, так и рассуждающую модель значительно мощнее по сравнению с работой в режиме веб-чата.
Кодинг-харнесс
Под харнессом обычно понимается сложный программный слой вокруг модели, который собирает промпты, открывает доступ к инструментам, отслеживает состояние файлов, применяет правки, выполняет команды, управляет разрешениями, кэширует стабильные префиксы, хранит память и многое другое.
Сегодня именно этот слой во многом определяет пользовательский опыт — значительно больше, чем прямое обращение к модели или веб-чат-интерфейс (который ближе к «чату с загруженными файлами»).
Поскольку базовые версии современных LLM имеют очень схожие возможности (например, базовые GPT-5.4, Opus 4.6, GLM-5 и им подобные), харнесс нередко становится тем фактором, который делает одну LLM лучше другой.
Это лишь мое предположение, но я подозреваю: если взять одну из самых мощных современных open-weight LLM — например GLM-5 — и запустить ее в аналогичном харнессе, она, скорее всего, покажет результаты на уровне GPT-5.4 в Codex или Claude Opus 4.6 в Claude Code. Правда, дообучение под конкретный харнесс всё равно полезно. Например, OpenAI исторически поддерживала отдельные варианты GPT-5.3 и GPT-5.3-Codex.
В следующем разделе я хочу подробнее рассмотреть основные компоненты кодинг-харнесса на примере моегоMini Coding Agent:
Кстати, в этой статье я использую термины «кодинг-агент» и «кодинг-харнесс» как взаимозаменяемые — для простоты.(но строго говоря, агент — это управляемый моделью цикл принятия решений, а харнесс — окружающий программный каркас, предоставляющий контекст, инструменты и среду исполнения)
Ниже — шесть основных компонентов кодинг-агентов. Конкретные примеры кода можно посмотреть в исходниках моего минималистичного и написанного с нуля на питонеMini Coding Agent. В коде эти шесть компонентов отмечены комментариями:
1. Живой контекст репозитория
Пожалуй, это самый очевидный компонент — и одновременно один из важнейших.
Когда пользователь говорит «исправь тесты» или «реализуй xyz», модель должна знать: находится ли она внутри Git-репозитория, на какой ветке, есть ли в проекте документы с инструкциями — и так далее.
Все это важно, потому что подобные детали меняются и определяют, какое действие будет правильным. Например, «исправь тесты» — не самодостаточная инструкция. Если агент видит AGENTS.md или README проекта, он может узнать, какую команду запустить для тестов. Зная корневую папку и структуру репозитория, агент смотрит в нужных местах, а не гадает.
Ветка git, статус и коммиты тоже дают полезный контекст: какие изменения сейчас в работе и на чем стоит сосредоточиться.
Вывод: кодинг-агент заранее собирает информацию («стабильные факты» в виде сводки рабочего пространства), чтобы не начинать с нуля, без контекста, при каждом новом промпте или запуске.
2. Структура промпта и повторное использование кэша
Как только агент получил представление о репозитории, встает следующий вопрос: как передавать эту информацию модели. На предыдущем рисунке была упрощенная схема («объединенный промпт: префикс + запрос»), но на практике заново собирать и обрабатывать сводку рабочего пространства при каждом запросе довольно расточительно.
В кодинг-сессиях многое повторяется: правила для агента остаются теми же, описания инструментов — тоже. И даже сводка рабочего пространства по большей части не меняется. Что действительно меняется — это последний запрос пользователя, недавняя история диалога и, возможно, краткосрочная память.
«Умные» рантаймы не пересобирают все как один гигантский монолитный промпт при каждом обращении — как показано на рисунке ниже.
Главное отличие от раздела 1 в том, что там речь шла о сборе фактов о репозитории. Здесь же нас интересует эффективная упаковка и кэширование этих фактов для повторных вызовов модели.
«Стабильный префикс промпта» означает, что содержащаяся там информация почти не меняется. Как правило, это общие инструкции, описания инструментов и сводка рабочего пространства. Тратить вычисления на пересборку этого блока с нуля при каждом взаимодействии, если ничего существенного не изменилось, не нужно.
Остальные компоненты обновляются чаще — обычно при каждом обращении. Это краткосрочная память, недавняя история диалога и последний запрос пользователя.
Кэширование «стабильного префикса промпта» устроено просто: умный рантайм старается повторно использовать эту часть, не пересобирая ее заново.
3. Доступ к инструментам и их использование
Именно здесь система начинает ощущаться не как чат, а как настоящий агент.
Обычная модель может предложить команду в виде текста, но LLM в кодинг-харнессе должна делать кое-что более узкое и полезное:реальновыполнять команду и получать результат (вместо того чтобы мы вручную вводили команду и вставляли результат обратно в чат).
Вместо того чтобы позволять модели импровизировать произвольный синтаксис, харнесс обычно предоставляет фиксированный список именованных инструментов — с понятными входами и чёткими ограничениями.(но, конечно, что-то вроде Python-функции subprocess.call может входить в этот список — и тогда агент сможет выполнять широкий набор произвольных shell-команд)
Процесс использования инструментов показан на рисунке ниже.
Для наглядности — пример того, как это выглядит для пользователя в моем Mini Coding Agent.(он выглядит скромнее, чем Claude Code или Codex: это очень минималистичная реализация на чистом Python без внешних зависимостей)
Модель должна выбрать действие, которое харнесс распознает: список файлов, чтение файла, поиск, выполнение shell-команды, запись файла и многие другие. Аргументы нужно передать в форме, которую харнесс может проверить.
Когда модель просит что-то сделать, рантайм может остановиться и выполнить программные проверки:
- «Это известный инструмент?»- «Аргументы корректны?»- «Нужно ли подтверждение пользователя?»- «Запрашиваемый путь вообще находится внутри рабочего пространства?»
Только после успешного прохождения всех проверок что-либо реально выполняется.
Работа с кодинг-агентами, конечно, несет определённые риски, но проверки харнесса ещё и повышают надежность: модель не выполняет совершенно произвольные команды.
Харнесс не только отклоняет некорректные действия и запрашивает подтверждения — он еще и ограничивает доступ к файлам пределами репозитория, проверяя пути. В каком-то смысле харнесс дает модели меньше свободы — но одновременно и делает систему удобнее.
4. Борьба с раздуванием контекста
Раздувание контекста — не уникальная проблема кодинг-агентов, это вообще общая проблема всех LLM. Да, модели сегодня поддерживают все более длинные контекстные окна (янедавно писало вариантах внимания, которые снижают вычислительные затраты), но длинные контексты все равно дороги и могут вносить дополнительный шум (если там много нерелевантной информации).
Кодинг-агенты еще сильнее подвержены раздуванию контекста, чем обычные LLM в многошаговых диалогах — из-за повторных чтений файлов, объемных выводов инструментов, логов и прочего.
Если рантайм хранит все это без потери деталей, доступные токены контекста быстро закончатся. Поэтому хороший кодинг-харнесс обычно довольно изощренно управляет раздуванием контекста — значительно сложнее, чем простая обрезка или суммаризация в обычных чат-интерфейсах.
Концептуально сжатие контекста в кодинг-агентах можно представить так, как показано на рисунке ниже. По сути, мы смотрим подробнее на шаг clip (шаг 6) из рисунка 8 в предыдущем разделе.
Минималистичный харнесс использует хотя бы две стратегии сжатия. У процесса сжатия еще есть синоним — компактизация.
Первая — обрезка(clipping): укорачивание длинных фрагментов документов, объемных выводов инструментов, заметок памяти и записей истории. Иными словами, это не позволяет отдельному куску текста поглотить весь бюджет промпта только потому, что он оказался многословным.
Вторая стратегия — сокращение или суммаризация истории: преобразование полной истории сессии (подробнее об этом в следующем разделе) в более компактное резюме для последующего промпта.
Ключевой прием здесь — оставлять больше деталей в последних событиях, поскольку они, скорее всего, важнее для последующего шага. А более старые события сжимаются агрессивнее — они, вероятно, менее релевантны.
Помимо этого, мы дедуплицируем старые чтения файлов, чтобы модель не видела одно и то же содержимое снова и снова только потому, что файл несколько раз читался в ходе сессии.
В целом, на мой взгляд, это один из недооцененных, «скучных» аспектов хорошего проектирования кодинг-агента. Многое из того, что воспринимается как «качество модели», на деле — качество контекста.
5. Структурированная память сессии
На практике все шесть концепций тесно переплетены, и разные разделы и рисунки освещают их с разных точек зрения или с разным уровнем детализации. В предыдущем разделе мы говорили об использовании истории в момент формирования промпта и о том, как строить компактное представление взаимодействия. Там главный вопрос такой: сколько прошлого нужно возвращать в модель при следующем обращении? Акцент — на сжатии, обрезке, дедупликации и приоритете недавних событий.
В этом разделе — структурированная память сессии — речь именно о структуре хранения истории. При общей схожести здесь вопрос другой: что агент сохраняет как постоянную запись? Акцент тое другой: рантайм ведет полный транскрипт как долговременное хранилище, а рядом — легкий слой памяти, который не просто пополняется, а перерабатывается и уплотняется.
Итого, кодинг-агент разделяет состояние на (как минимум) два уровня:
- рабочая память: небольшое, дистиллированное состояние, которое агент явно поддерживает
- полный транскрипт: охватывает все запросы пользователя, выводы инструментов и ответы LLM
На рисунке выше показаны два основных файла сессии: полный транскрипт и рабочая память, которые обычно хранятся как JSON-файлы на диске. Как уже говорилось, полный транскрипт хранит всю историю и позволяет возобновить работу после закрытия агента. Рабочая память — это более дистиллированная версия с наиболее важной наданныймомент информацией; она несколько похожа на компактный транскрипт.
Но у компактного транскрипта и рабочей памяти немного разные задачи. Компактный транскрипт нужен для реконструкции промпта: его задача — дать модели сжатое представление о недавней истории, чтобы она могла продолжить диалог, не видя всего полного диалога при каждом обращении. Рабочая память больше ориентирована на непрерывность задачи: ее задача — поддерживать небольшое, явно обновляемое резюме того, что важно между шагами: текущая задача, ключевые файлы, последние заметки.
После шага 4 на рисунке выше последний запрос пользователя вместе с ответом LLM и выводом инструмента будет записан как «новое событие» и в полный транскрипт, и в рабочую память — в следующем раунде. Это не показано на рисунке, чтобы не загромождать его.
6. Делегирование и (ограниченные) субагенты
Как только у агента появляются инструменты и состояние, следующая полезная возможность — делегирование.
Оно позволяет распараллелить часть работы на подзадачи через субагентов и ускорить выполнение основной задачи. Например, основной агент может решать поставленную задачу, но при этом нуждаться в ответе на побочный вопрос: в каком файле определен символ, что говорит конфиг, почему падает тест. Полезнее выделить это в ограниченную подзадачу, чем заставлять в основном цикле доставать все необходимое.
(в моем mini coding agent реализация проще, и дочерний агент всё ещё работает синхронно, но основная идея та же)
Субагент полезен, только если он наследует достаточно контекста для реальной работы(не больше и не меньше). Но если его не ограничивать, у нас появляются несколько агентов, которые дублируют работу, трогают одни и те же файлы или порождают еще субагентов — и так далее.
Поэтому настоящая задача проектирования — не только какзапустить(spawn)субагента, но и как егообуздать(bind).
Хитрость в том, что субагент наследует достаточно контекста, чтобы быть полезным, но при этом заранее ограничен рамками (например, режим только для чтения и ограничение на глубину рекурсии).
Claude Code поддерживает субагентов уже давно, Codex добавил их относительно недавно. Codex, как правило, не заставляет субагентов работать в режиме только для чтения. Вместо этого они обычно наследуют большую часть sandbox-окружения основного агента и настройки подтверждений. Так что граница там — скорее по масштабу задачи, контексту и глубине вложенности.
Как это соотносится с OpenClaw?
OpenClaw — интересный случай для сравнения, но это не совсем та же система.
OpenClaw больше похож на локальную платформу для агентов общего назначения, которая в том числе умеет писать код, — а не на специализированный терминальный помощник по кодингу.
Есть несколько точек пересечения с кодинг-харнессом:
- он использует файлы промптов и инструкций в рабочем пространстве, такие как AGENTS.md, SOUL.md и TOOLS.md
- он ведёт JSONL-файлы сессий, включает сжатие транскриптов и управление сессиями
- он может порождать вспомогательные сессии и субагенты
Но, как уже говорилось, акцент другой. Кодинг-агенты оптимизированы для разработчика, который работает в репозитории и просит помощника просматривать файлы, редактировать код и эффективно использовать локальные инструменты. OpenClaw оптимизирован под запуск множества долгоживущих локальных агентов в чатах, каналах и рабочих пространствах — при этом кодинг — лишь одна из важных задач.
Итог по компонентам
В разделах выше я постарался охватить основные компоненты кодинг-агентов. Как я уже говорил, в реализации они более или менее тесно переплетены. Тем не менее надеюсь, что разбор по одному помогает сформировать общее представление о том, как работают кодинг-харнессы и почему они делают LLM более полезными по сравнению с обычными многошаговыми диалогами.
Если вам интересно посмотреть на реализацию в чистом, минималистичном коде на Python — загляните в мойMini Coding Agent.
Спасибо! Я делаю переводы хороших статей, потому что считаю, что уже готовый качественный контент про агентов и LLM должен быть и на русском языке, а автоперевод хоть и решает задачу прочтения, но не справляется так, как мне хотелось бы. Помимо этого я делюсь своими заметками на ту же тему в тг-канальчикеAgentic Worldи пишу свои крафтовые статейки:
- Русский культурный код как оценка генеративных моделей
- Разработка после разработчиков. Что оставит AI?
- Как я делаю своего голосового AI-ассистента: роботы пишут код и работают, когда я отдыхаю
