В инструментах для разработки всё чаще появляется соблазнительная настройка: одну модель использовать для планирования, другую для кода, третью для ревью, четвёртую для тестов. На первый взгляд это выглядит разумно. Claude хорошо рассуждает, GPT точно следует инструкциям, локальная модель дешевле, значит можно собрать «команду» из лучших частей.
На практике всё сложнее. Свежий разбор Cursor про agent harness показывает: агент это не только модель. Качество рождается в связке модели, инструментов, системных инструкций, формата редактирования, управления контекстом, кэша, обработки ошибок и метрик. Если поменять модель внутри той же сессии, можно получить не усиление, а потерю качества, рост стоимости и больше ошибок tool-use.
Для бизнеса это важный вывод. Когда мы внедряем ИИ-агентов, нельзя оценивать только название модели в выпадающем списке. Нужно оценивать всю обвязку вокруг неё.
Что такое harness
Harness, или агентная обвязка, это инфраструктурный слой вокруг LLM. Он определяет, как модель получает контекст, какие инструменты может вызывать, в каком формате редактирует файлы, как видит ошибки, как работает с кэшем и когда должна остановиться.
В кодовом агенте harness обычно включает:
- системный prompt;
- описание инструментов;
- формат редактирования файлов;
- стратегию чтения репозитория;
- правила запуска тестов;
- обработку ошибок tool calls;
- summarization длинной истории;
- кэширование контекста;
- метрики качества;
- маршрутизацию между агентами и моделями.
Поэтому фраза «модель X пишет код лучше модели Y» часто неполная. Правильнее спрашивать: в каком harness, с какими инструментами, с каким контекстом, на каких задачах и по какой метрике.
Почему формат инструментов важнее, чем кажется
Cursor приводит очень показательный пример. Модели OpenAI лучше привыкли к patch-based редактированию файлов, то есть к формату, похожему на diff. Модели Anthropic лучше привыкли к string replacement, где нужно найти конкретный фрагмент текста и заменить его.
Обе модели могут пользоваться чужим форматом. Но это не бесплатно. Если Claude заставить работать через patch-инструмент, модель тратит больше reasoning-токенов и чаще ошибается. Если GPT заставить работать через непривычный формат замены строк, возникает похожая проблема.
Это объясняет странный эффект, который многие видели на практике: одна и та же модель в одном редакторе кажется сильной, а в другом ведёт себя заметно хуже. Изменилась не только модель. Изменился harness.
Почему Cursor настраивает harness под каждую модель
Cursor пишет, что не делает одну универсальную среду для всех моделей. Вместо этого они отдельно настраивают prompt-ы, инструменты и поведение под конкретного провайдера и даже под конкретную версию модели.
Это похоже на настройку производственного процесса. Можно поставить один и тот же двигатель в разные машины, но итоговая управляемость зависит от трансмиссии, шин, электроники и тормозов. В агентных системах роль этой инженерной части играет harness.
Для нас это важный сигнал. Если компания строит своего ИИ-агента, ей недостаточно «подключить сильную модель». Нужно проектировать среду, в которой эта модель работает.
Динамический контекст вместо набивки prompt-а
Старый подход к coding agents был простым: положить в контекст всё, что может пригодиться. Но у этого есть две проблемы.
Если контекста мало, модель не видит нужный файл, зависимость или предыдущую ошибку. Если контекста слишком много, растёт стоимость, падает точность внимания и появляется шум. Большой контекст сам по себе не гарантирует понимание.
Cursor описывает другой подход: агент должен сам добирать контекст в процессе работы. Он читает нужные файлы, проверяет ошибки, смотрит соседние участки кода, запускает инструменты и уточняет картину по мере продвижения.
Это близко к тому, как мы проектируем RAG и tool-use в корпоративных агентах. Модель не должна получать случайный мешок документов. Она должна уметь искать, проверять и добирать недостающие данные. Подробнее этот подход мы разбирали в статье ИИ-агенты с tool-use: как модель сама ищет данные и добирает контекст.
Ошибки инструментов нужно считать отдельно
В агентной системе tool-use ошибки неизбежны. Модель может вызвать инструмент с неправильными аргументами. Может попытаться прочитать файл, которого нет. Может опереться на контекст, который уже устарел. Может столкнуться со сбоем API провайдера.
Cursor делит такие ошибки на классы:
InvalidArguments, модель неправильно сформировала вызов;UnexpectedEnvironment, окружение противоречит тому, что модель ожидает;ProviderError, сбой на стороне внешнего API;Timeout, превышение лимита времени;UserAborted, действие остановил пользователь.
Это не академическая классификация. Если не разделять причины, невозможно улучшать агента. Ошибка модели, ошибка инструмента и ошибка провайдера требуют разных исправлений.
Cursor пишет, что во время отдельного спринта снизил unexpected tool call errors примерно на порядок. Это сильный пример того, что качество агента улучшается не только заменой модели, но и инженерией вокруг неё.
Keep Rate вместо красивых бенчмарков
Главная метрика Cursor называется Keep Rate. Она показывает, какая доля кода, предложенного агентом, остаётся в кодовой базе пользователя через фиксированный промежуток времени.
Это очень здоровая метрика. Если код остался, значит он хотя бы прошёл первичный фильтр реального использования. Если пользователь удалил, переписал или долго исправлял результат, значит красивый ответ модели не превратился в рабочую пользу.
Обычные бенчмарки тоже нужны, но они часто измеряют стерильную задачу. В production важнее другое:
- сколько кода осталось;
- сколько раз агенту пришлось переделывать результат;
- сколько tool calls завершилось ошибкой;
- сколько стоил успешный результат;
- сколько времени ушло до merge;
- сколько ручной правки сделал разработчик.
Для корпоративных внедрений это особенно важно. Нам не нужен агент, который красиво решает демо. Нужен агент, чья работа остаётся в реальном процессе.
Почему смена модели посреди чата опасна
Самая неприятная часть для пользователей мультимодельных агентов: смена модели внутри одного чата почти всегда имеет скрытую цену.
Первая проблема: новая модель получает историю, которую создала другая модель. В этой истории могут быть вызовы инструментов, формат ответов, промежуточные рассуждения и ожидания, которые не совпадают с её собственным harness.
Cursor прямо пишет, что при mid-chat switching приходится добавлять специальные инструкции: новая модель должна понимать, что она продолжает чужую сессию, и не пытаться вызывать инструменты из истории, которых уже нет в её текущем наборе.
Вторая проблема: кэш. Кэши привязаны к провайдеру и модели. При переключении почти всегда возникает cache miss. Первый запрос после смены модели становится медленнее и дороже.
Третья проблема: потеря деталей при summarization. Можно попытаться пересобрать историю для новой модели в чистое резюме. Но если задача сложная, резюме легко потеряет важные мелочи: имя теста, точный путь файла, маленькое ограничение из предыдущего сообщения.
Поэтому рекомендация Cursor звучит спокойно, но жёстко: лучше оставаться на одной модели в рамках одной сложной сессии, если нет понятной причины переключаться.
Почему бенчмарки без harness вводят в заблуждение
SWE-bench Verified, SWE-bench Pro и похожие тесты полезны, но их нельзя читать как простой рейтинг моделей. Результат зависит от того, с какой обвязкой модель решает задачу.
Одна и та же модель может показать разные результаты в разных средах. Где-то ей дают кастомные инструменты, хороший поиск по репозиторию, аккуратный формат патча и тестовый цикл. Где-то она работает почти в минимальной среде, где есть только bash и ограниченный набор шагов.
Именно поэтому цифра в leaderboard не отвечает на главный вопрос: как эта модель будет работать в вашем контуре, с вашими репозиториями, вашими тестами, вашими ограничениями доступа и вашими правилами безопасности.
Для AI Platforms это принципиально. Мы оцениваем не только модель, но и весь рабочий контур: RAG, tool-use, MCP-инструменты, sandbox, права доступа, логирование, метрики и human approval.
Multi-agent системы: не бесплатное усиление
Многоагентный подход действительно может быть мощным. Anthropic в материале про multi-agent research system показывает orchestrator-worker архитектуру: главный агент планирует работу и создаёт субагентов, которые параллельно исследуют разные направления.
Но multi-agent не является автоматическим усилителем качества. Он увеличивает стоимость, усложняет маршрутизацию и добавляет новые точки отказа.
Простая математика хорошо показывает риск. Если один агент выполняет свой шаг с надёжностью 95%, цепочка из пяти последовательных агентов даст общую надёжность около 77%. Не потому, что агенты плохие, а потому что ошибки перемножаются.
Поэтому multi-agent система требует ещё более сильного harness:
- кто решает, когда нужен субагент;
- как формулируется задача для субагента;
- какой контекст ему передаётся;
- как проверяется результат;
- кто отвечает за финальное решение;
- что делать, если агенты противоречат друг другу;
- где остановить цикл, чтобы стоимость не ушла в бесконечность.
Без этого многоагентность легко превращается в дорогую имитацию продуктивности.
Что это значит для бизнеса
Для компаний, которые внедряют ИИ-агентов, главный вывод простой: конкурентное преимущество всё меньше лежит в доступе к «самой умной модели». Доступ к сильным API есть у многих. Разница появляется в том, как вы строите harness.
Практически это означает:
- не переключать модель внутри длинной задачи без причины;
- подбирать формат инструментов под конкретную модель;
- измерять Keep Rate, tool error rate, latency, cost per successful task;
- отдельно учитывать ошибки модели, окружения и провайдера;
- давать агенту динамический доступ к контексту, а не набивать prompt всем подряд;
- вводить human approval для рискованных действий;
- тестировать не только модель, но и весь агентный контур.
В локальных и on-prem системах это ещё важнее. Там нужно учитывать не только качество ответа, но и безопасность данных, доступы, логи, права на инструменты и стоимость GPU-инференса.
Как мы подходим к этому в AI Platforms
Когда мы проектируем ИИ-агентов для бизнеса, мы не начинаем с вопроса «какую модель поставить». Мы сначала разбираем процесс.
Нам важно понять:
- какие данные агент должен видеть;
- какие инструменты он может вызывать;
- какие действия требуют подтверждения;
- какие ошибки считаются допустимыми;
- какая метрика показывает реальную пользу;
- где нужен один агент, а где лучше subagent;
- какие части можно держать локально в частной LLM;
- какие задачи всё ещё разумнее отдавать в облачную frontier-модель.
И только после этого выбирается модель, RAG, MCP-инструменты, orchestration и мониторинг. Модель важна, но без harness она остаётся просто сильным движком без шасси.
Вывод
Смена моделей «на лету» выглядит как свобода выбора, но в сложных агентных задачах часто ломает контекст, кэш, формат инструментов и предсказуемость поведения. Это не значит, что мультимодельные системы плохие. Это значит, что ими должен управлять harness, а не случайное выпадающее меню.
Настоящая инженерия ИИ-агентов находится не только в prompt-ах и не только в выборе модели. Она находится в обвязке: инструментах, контексте, ошибках, метриках, кэше, правах доступа и правилах остановки.
Для бизнеса это хорошая новость. Качественный агент можно построить не только за счёт покупки самого дорогого API, но и за счёт аккуратной системной инженерии вокруг модели.