Агенты с управляющей оболочкой
Полезное различие проходит не между CLI, IDE и чатом. Это поверхности взаимодействия. Архитектурное различие — в том, где принимаются вероятностные решения. Обе архитектуры оборачивают LLM одного типа, но дают ей делать разные выборы: агенты с управляющей оболочкой (harness) позволяют модели выбирать многие следующие шаги; агенты рабочего процесса помещают оркестрацию в детерминированный код и вызывают модель в ограниченных точках.
Это расположение меняет характер агента. Агент с управляющей оболочкой усиливает намерение оператора быстрыми действиями через инструменты, но усиление никогда не бывает без потерь: каждый шаг модели по-прежнему представляет собой вероятностное предсказание токенов, поэтому даже хорошо ограниченная работа может накапливать едва заметный шум. Чем больше контроля архитектура отдаёт LLM, тем больше мест, где этот шум проникает в путь поиска, правки и выводы, и тем больше навыков оператора и предметных знаний нужно для управления. Агент рабочего процесса оставляет вероятностному предсказанию меньше решений. Он меняет свободу открытых действий на контроль, оптимизацию и точность, передавая окружающему ПО состояние, маршрутизацию, проверку и условия остановки. Но такой контроль требует больше инженерных усилий, и качественно реализовать его сложнее.
Интерактивные агенты программирования — Claude Code, терминалы в стиле Codex, Pi, OpenClaw, агентный режим Copilot в VS Code, Cursor, Zed — позволяют LLM принимать многие решения о следующем шаге через вызовы инструментов или запросы команд. Оболочка обеспечивает ограничения и выполнение, но именно модель часто выбирает следующий поиск, чтение, изменение, тест или вопрос.
Механика агентов
Оболочка превращает вызовы модели в управляемую работу
Агенты с управляющей оболочкой дают LLM больше автономии: оболочка обеспечивает соблюдение границ, но модель выбирает следующий поиск, чтение, правку или вопрос. Это делает их самой гибкой и самой простой для построения архитектурой: цикл, защитные ограничения и привязки инструментов.
Поэтому они ощущаются как усилитель возможностей. Оператор задаёт намерение, ограничения и оценку; оболочка даёт модели инструменты; модель превращает намерение в действия с машинной скоростью. Компромисс в том, что многие такие превращения проходят через вероятностное предсказание токенов. Ясное намерение и строгие ограничения сужают маршрут действий, но не делают его детерминированным. Чем шире пространство решений модели, тем лучше оператор должен уметь ограничивать, направлять и оценивать работу. Неоднозначное намерение усугубляет проблему: блуждание, лишние вызовы инструментов, слишком широкие правки или правдоподобные, но неверные выводы. И каждый обходной путь всё равно расходует токены.
Бюджет внимания управляющей оболочки
В главе «Эффективный контекст» мы установили, что LLM — машины с конечными ресурсами. Контекстное окно — фиксированный объём, и каждый обрабатываемый моделью токен конкурирует с остальными за влияние на следующее предсказание. Оболочка помогает модели действовать, но не бесплатно: определения инструментов, инструкции планирования, схемы вывода, разрешения, правила памяти и протоколы координации попадают в тот же контекст, что и задача пользователя.
Поэтому проектирование оболочки — решение о распределении внимания. Бенчмарки следования инструкциям, например IFScale, показывают одну закономерность под нагрузкой: с ростом числа одновременных инструкций модели пропускают больше ограничений, придают чрезмерный вес ранним инструкциям и в итоге отбрасывают требования, а не просто выполняют их неточно. Инструкции оболочки — часть этой нагрузки.
Развитые оболочки также требуют от модели управлять самой оболочкой. Модели может понадобиться вести план, выбирать инструменты, управлять субагентами, сводить историю, обновлять состояние задачи или формировать метаданные интерфейса. Часть этой работы повышает надёжность. Часть лишь улучшает внешний вид продукта. В обоих случаях она расходует токены и внимание, которых больше нет для задачи пользователя.
Спектр управляющих оболочек
Этот компромисс создаёт спектр продуктов с управляющей оболочкой. Разные продукты занимают разные позиции:
| Минимальная оболочка | Развитая оболочка | |
|---|---|---|
| Примеры | Pi, простые циклы поверх API | Claude Code, агенты в стиле Codex |
| Накладные расходы контекста | Низкие | Высокие |
| Стоимость токенов | Низкая | Высокая |
| Видимый интерфейс | Открытый процесс: видны исследования, ложные старты и возвраты | Структурированный: видны планирование, отслеживание прогресса, отточенное взаимодействие |
| Требуемые навыки оператора | Высокие: нужно направлять, ограничивать, проверять | Ниже: оболочка берёт на себя больше рабочего процесса |
| Внимание к задаче пользователя | Большая часть контекста может оставаться посвящённой задаче | Больше контекста расходуется на координацию, инструменты, безопасность и интерфейс |
Данные бенчмарков проще всего читать, когда меняется оболочка, а модель остаётся постоянной. Terminal-Bench 2.0 публикует несколько строк для одной и той же модели в разных оболочках программирования; разброс делает влияние оболочки заметным, даже если не позволяет выделить каждое её внутреннее проектное решение.
Механика агентов
Устройство оболочки меняет поведение агента
Результат GPT-5.5 на Terminal-Bench меняется от 66,1% с clnkr до 84,7% с NexAU-AHE.
Одинаковая группа моделей
| Модель | Оболочка | Разработчик агента | Дата | Результат | CI |
|---|---|---|---|---|---|
| GPT-5.5 | NexAU-AHE | china-qijizhifeng | 2026-05-14 | 84.7% | ±2.1 |
| GPT-5.5 | Capy | Capy | 2026-05-14 | 83.1% | ±2.1 |
| GPT-5.5 | Codex CLI | OpenAI | 2026-04-23 | 82.2% | ±2.2 |
| GPT-5.5 | clnkr | clnkr | 2026-05-14 | 66.1% | ±2.5 |
В менее структурированных оболочках цикл рассуждений заметнее. Агенты программирования в стиле ReAct решают задачи через наблюдение, пробное действие, чтение результата и пересмотр следующего шага; со стороны это может выглядеть как отклонения, ложные старты или противоречащие друг другу подходы. Такой цикл полезен лишь при ограничении проверками: тестами, сборками, diff, рецензированием, бюджетами или одобрением человека.
Более развитые оболочки делают ту же работу визуально управляемее, добавляя режимы планирования, структурированные инструменты, разрешения, сжатие контекста, субагентов и отображение прогресса. Эти структуры могут улучшать надёжность и опыт оператора, но также расходуют контекст и сужают пространство действий модели. Инженерный выбор — не между минимальной и развитой оболочкой. Он в том, сколько опорных механизмов нужно задаче, прежде чем сама опора превратится в накладные расходы.
Поддерживающая обвязка — один ответ на изменчивость. Другой — полностью вынести оркестрацию из модели.