Из чего на самом деле состоят кодинг-агенты

Claude Code, Codex CLI и подобные инструменты ощущаются на голову выше обычного чата с LLM. Но дело не в магии и даже не всегда в качестве модели. Главная причина в том, что вокруг модели выстроена целая инженерная обвязка, так называемый coding harness. Себастьян Рашка (автор книги Build a Large Language Model From Scratch) разложил эту обвязку на шесть ключевых компонентов, а мы разберемся, зачем каждый из них нужен и почему без них агент превращается в обычного чат-бота.

Модель, reasoning-модель и агент: в чем разница

Прежде чем нырять в компоненты, стоит развести понятия. LLM – это базовый движок, модель, предсказывающая следующий токен. Reasoning-модель – тот же LLM, но обученный или настроенный тратить больше вычислений на промежуточные рассуждения, проверку гипотез и перебор вариантов. Агент – это управляющий цикл поверх модели: он решает, что исследовать дальше, какие инструменты вызвать, как обновить состояние и когда остановиться.

Если LLM – это двигатель, то reasoning-модель – форсированный двигатель (мощнее, но дороже), а агентская обвязка (harness) – это трансмиссия, рулевое и подвеска, которые позволяют этот двигатель эффективно использовать. Именно поэтому одна и та же модель через Claude Code выдает результат, который в обычном чате кажется недостижимым.

Шесть компонентов кодинг-агента

1. Живой контекст репозитория

Когда пользователь говорит «почини тесты» или «реализуй фичу X», модель должна понимать, находится ли она внутри Git-репозитория, на какой ветке, какие файлы проекта содержат инструкции. Без этого контекста запрос «почини тесты» повисает в воздухе: непонятно, какой тестовый фреймворк используется, где лежат конфиги, что вообще сломалось.

Поэтому первое, что делает хороший кодинг-агент, – собирает «стабильные факты» о проекте: git branch, статус, последние коммиты, наличие AGENTS.md, README и прочих проектных документов. Эта сводка (workspace summary) подклеивается к каждому запросу, чтобы агент никогда не стартовал с нуля.

2. Форма промпта и переиспользование кеша

Собрать контекст недостаточно – надо еще грамотно упаковать его для модели. Кодинг-сессии повторяются: правила агента не меняются, описания инструментов не меняются, сводка по репозиторию тоже остается почти той же. Меняется только последний запрос пользователя и недавняя история диалога.

Умные рантаймы не пересобирают гигантский промпт с нуля на каждом шаге. Вместо этого формируется стабильный префикс (инструкции, инструменты, workspace summary), который кешируется и переиспользуется. Динамические части – свежая память, последний транскрипт, новый запрос – добавляются к нему. Это экономит и время, и деньги на inference.

3. Инструменты и их вызов

Здесь агент перестает быть чатом и начинает действовать. Обычная модель может в прозе предложить «запустите такую-то команду». Модель внутри кодинг-обвязки реально выполняет эту команду и получает результат обратно в контекст.

Но вместо того чтобы давать модели полную свободу, обвязка предоставляет заранее определенный набор именованных инструментов с четкими входами и границами: чтение файлов, поиск, запуск shell-команд, запись файлов и так далее. Когда модель хочет что-то сделать, рантайм проверяет: известен ли этот инструмент? Валидны ли аргументы? Нужно ли одобрение пользователя? Находится ли запрашиваемый путь внутри рабочего пространства? Только после всех проверок действие выполняется. Парадокс в том, что ограничение свободы модели одновременно повышает надежность и полезность.

4. Борьба с раздуванием контекста

Контекстное окно не бесконечно, а кодинг-агенты особенно быстро его забивают: повторные чтения файлов, длинные логи, вывод инструментов. Если рантайм хранит все это без сжатия, токены закончатся очень быстро.

Хорошая обвязка использует минимум две стратегии компактификации. Первая – обрезка (clipping): длинные сниппеты, результаты инструментов и записи транскрипта укорачиваются, чтобы ни один фрагмент не сожрал весь бюджет промпта. Вторая – сжатие транскрипта: полная история сессии превращается в краткую сводку. Свежие события остаются подробными (они важнее для текущего шага), старые сжимаются агрессивнее. Плюс дедупликация повторных чтений одних и тех же файлов. Это одна из самых недооцененных частей проектирования агентов: часто то, что кажется «качеством модели», на самом деле является качеством контекста.

5. Структурированная память сессии

Кодинг-агент разделяет состояние как минимум на два слоя. Первый – рабочая память (working memory): маленькое, дистиллированное состояние с самым важным (текущая задача, ключевые файлы, заметки). Второй – полный транскрипт: все запросы пользователя, ответы модели, результаты инструментов.

Полный транскрипт хранится на диске как JSON и позволяет возобновить сессию после закрытия агента. Рабочая память – это более компактная и постоянно обновляемая выжимка того, что сейчас важно. Они похожи на компактный транскрипт из предыдущего раздела, но задачи у них разные: компактный транскрипт нужен для реконструкции промпта, а рабочая память – для непрерывности задачи между ходами.

6. Делегирование и ограниченные субагенты

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

Хитрость в том, что субагент наследует достаточно контекста, чтобы быть полезным, но работает в более жестких рамках, чем основной агент, например в режиме только для чтения или с ограничением глубины рекурсии. Claude Code поддерживает субагентов давно, Codex добавил их позже. Codex не форсирует read-only режим, но ограничивает субагентов по скоупу задачи, контексту и глубине.

Почему это важно

Ванильные версии топовых LLM сегодня по возможностям очень близки друг к другу. Рашка высказывает гипотезу, что если взять сильную открытую модель и поместить ее в качественную кодинг-обвязку, она может выступить наравне с проприетарными решениями. Другими словами, обвязка часто оказывается тем самым фактором, который отличает «просто хорошую модель» от «инструмента, с которым реально можно работать».

Для тех, кто хочет разобраться на уровне кода, Рашка выложил свой мини-агент на Python без зависимостей, где все шесть компонентов размечены комментариями: github.com/rasbt/mini-coding-agent

Оригинал статьи: magazine.sebastianraschka.com

t.me/ai_machinelearning_big_data