Один Claude, разные Cursor: как Agent Harness меняет поведение LLM — VogueTech

Что нового

Кодовые ассистенты вроде Cursor, Claude Code, Codex и других давно стали рабочим инструментом разработчиков. Многие из них используют одни и те же языковые модели — например, Claude 3.5 Sonnet или GPT‑4‑класса — но ведут себя по‑разному.

Автор вводит важное понятие для этого рынка — agent harness (харнесс агента). Это не новая модель и не ещё один ассистент, а способ описать всё, что окружает LLM и превращает её из «болталки» в рабочего агента:

инструменты (shell, поиск по проекту, запуск тестов и т.д.);
память и работа с контекстом;
системные промпты и правила поведения;
цикл планирования и верификации;
изолированная среда исполнения кода.

Главная мысль: «агент = модель + харнесс». Именно харнесс объясняет, почему одна и та же LLM пишет UI лучше в Cursor, а архитектуру — лучше в Claude Code.

Конкретных бенчмарков, скоростей, цен и размеров контекста в материале нет. Фокус — на архитектуре и инженерных решениях вокруг модели.

Как это работает

LLM как «мозг» без тела

Большая языковая модель по своей природе делает одну вещь: по последовательности токенов предсказывает следующий токен. У неё:

нет состояния между запросами;
нет встроенной долговременной памяти;
нет доступа к файловой системе и инструментам;
каждое обращение — отдельный, независимый вызов.

Все «умные» возможности, которые мы ассоциируем с агентами, — результат кода вокруг модели.

ReAct: базовый цикл агента

Чтобы LLM решала сложные задачи, её оборачивают в архитектуру агента. Один из базовых шаблонов — ReAct (Reason + Act). Цикл выглядит так:

Reason — модель получает запрос и решает, что делать дальше.
Act — агент вызывает нужный инструмент: запускает тесты, читает файл, делает запрос в базу знаний.
Observe — результат работы инструмента возвращается в модель как часть контекста.
Repeat — модель анализирует новые данные и снова планирует следующий шаг, пока задача не будет решена.

Пользователь общается не напрямую с LLM, а с этим циклом. Диалоговый чат‑бот просто отвечает на текст. Агент действует, проверяет себя, корректирует план и только потом выдаёт результат.

Что такое Agent Harness

Команда LangChain формулирует это так: агент = модель + харнесс.

Харнесс — это вся программная инфраструктура вокруг LLM:

системные промпты и конфигурация поведения;
код, который управляет циклами Reason–Act–Observe–Repeat;
подключение инструментов (bash, поиск по коду, HTTP‑запросы и т.п.);
работа с памятью и контекстным окном;
механизмы верификации и обратной связи;
управление состоянием сессии и правами доступа.

Сама по себе LLM — это только «мозг». Харнесс даёт ей «тело», органы чувств и правила игры. Один и тот же Claude 3.5 Sonnet в разных харнессах превращается то в код‑ассистента, то в шоппинг‑агента, то в исследовательскую систему.

Почему один и тот же Claude ведёт себя по‑разному

Когда вы переключаетесь, например, с Claude Code на Cursor, вы меняете не только интерфейс. Меняется весь харнесс вокруг модели:

Системные промпты
Каждый продукт задаёт свои инструкции:
- насколько агент автономен;
- как сильно он декомпозирует задачи;
- как много он объясняет;
- насколько агрессивно переписывает код.
Управление контекстным окном
Контекст ограничен, и разные агенты по‑разному его используют:
- саммаризуют старые части диалога;
- выгружают фрагменты на диск и подгружают по запросу;
- строят индекс проекта и подмешивают только релевантные файлы.
Набор инструментов
Разные команды по‑разному проектируют арсенал:
- bash, git, запуск тестов;
- навигация по проекту и поиск по файлам;
- генерация и применение патчей.
Уровень автономности
Он задаётся промптами и логикой цикла:
- один агент старается всё делать сам, пока не дойдёт до результата;
- другой постоянно «подбрасывает» промежуточные шаги пользователю и ждёт подтверждения.
Механизмы верификации
Создатель Claude Code Борис Черный формулирует ключевой принцип:

«Самое важное для получения отличных результатов — дать Claude способ верифицировать свою работу. Если у Claude есть петля обратной связи, качество финального результата вырастет в 2–3 раза».

Это может быть:
- автозапуск тестов после правки;
- проверка компиляции;
- повторный анализ сгенерированного кода с новым промптом «проверь себя».
Изолированная среда исполнения кода
Разработчики агента сами решают:
- какие команды можно выполнять;
- какие ресурсы доступны внутри песочницы;
- какие ограничения по времени и ресурсам у запусков.
Цикл планирования
Агент может:
- строить подробный план и идти по нему шаг за шагом;
- или решать всё «на лету», постоянно перепланируя.

Именно эти инженерные решения и образуют харнесс. На их основе формируется «характер» ассистента — от «тихого помощника в IDE» до почти автономного разработчика.

Иерархия LLM‑инжиниринга

Автор предлагает смотреть на развитие проектов с LLM как на три уровня:

Промпт‑инжиниринг
Первая волна: учимся правильно формулировать запросы.
- подробные инструкции;
- примеры формата ответа;
- цепочки размышлений «подумай шаг за шагом».
Инжиниринг контекста
Следующий шаг — работа с памятью и данными:
- саммаризация длинных диалогов;
- перенос знаний между сессиями;
- подготовка релевантного контекста для RAG‑систем.
Харнесс‑инжиниринг
Здесь складывается полная картина агента:
- цикл планирования и выполнения действий;
- подключение инструментов и проверок;
- управление состоянием, правами, ресурсами.

Именно на этом уровне рождаются продукты вроде Cursor или Claude Code.

Что это значит для вас

Если вы разработчик и выбираете код‑ассистента

Не имеет смысла спрашивать «какая модель лучше для кода», если вы сравниваете готовые агенты. Важно другое:

Cursor, Claude Code, WindSurf и другие могут использовать одну и ту же LLM, но:
- по‑разному видят структуру проекта;
- по‑разному режут и подмешивают контекст;
- по‑разному проверяют результат.

Практический вывод:

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

Если вы строите своего агента

Полезные ориентиры:

Не зацикливайтесь на выборе LLM. Существенная часть качества — в харнессе:
- какие инструменты вы дадите модели;
- как будете управлять контекстом;
- как организуете самопроверку.
Добавьте петлю верификации. Даже простая проверка «собери, запусти тесты, проанализируй логи» даёт прирост качества. Цитата Бориса Черного про 2–3‑кратное улучшение — хороший ориентир.
Проектируйте харнесс под задачу.
- кодинг‑агенту нужны инструменты работы с репозиторием, тестами и CI;
- шоппинг‑агенту — доступ к каталогу товаров и пользовательскому профилю;
- исследовательскому агенту — поиск по статьям, цитирование и управление источниками.

Если вы продукт‑менеджер или тимлид

Когда вы выбираете AI‑ассистента для команды, смотрите не только на название модели, но и на:

как агент интегрируется в текущий стек (IDE, репозитории, CI);
какие ограничения по безопасности и среде исполнения заложены в харнесс;
как он работает с памятью проекта и длинными задачами.

Это объясняет, почему два продукта с одной и той же LLM дают разный опыт и разные результаты в одной и той же команде.

Доступность и ограничения

В материале нет информации о доступности конкретных ассистентов в России, требованиях к VPN или тарифах. Если вы работаете в российской юрисдикции, эти параметры придётся проверять отдельно для каждого продукта — Cursor, Claude Code, Codex и других.

Место на рынке

Agent Harness — это не отдельный сервис, а способ описать класс продуктов, к которым относятся:

Claude Code — делает ставку на автономность и самопроверку (через тесты и другие петли верификации);
Cursor — тесно встраивается в IDE и активно работает с контекстом проекта;
Codex, OpenCode, WindSurf и другие — свои варианты харнесса вокруг сходных моделей.

Общая тенденция рынка код‑ассистентов:

инженерная ценность всё меньше зависит от «какую LLM вы выбрали»;
и всё больше — от того, как именно вы её обвязали:
- какие инструменты дали;
- как организовали планирование и верификацию;
- как решаете проблему контекстного окна.

Прямых числовых сравнений между этими продуктами в материале нет. Автор акцентирует внимание на архитектурном уровне: почему одна и та же модель в разных харнессах даёт разные результаты и как это использовать при выборе или разработке собственного агента.