Знакомая ситуация: две компании запускают AI-агента на одной и той же модели. У одной он месяцами стабильно обрабатывает заявки, у другой — сегодня отвечает блестяще, а завтра выдаёт ерунду. Владелец делает вывод «AI ещё сырой». На самом деле разница не в модели, а в трёх слоях вокруг неё: системе ограничений, формулировке инструкций и доступе к свежей документации. Разберём каждый — а в конце будет чек-лист вопросов к подрядчику.
Модель — это двигатель, harness — это машина
Princeton исследовал 14 моделей и обнаружил неприятную закономерность: точность (accuracy) растёт от поколения к поколению, а надёжность (reliability) — нет. Модель становится умнее, но не становится предсказуемее. Это разные свойства, и одно не влечёт за собой другое автоматически.
Поэтому команды, которые всерьёз строят агентов, вкладываются не в «лучшую модель», а в harness — систему ограничений вокруг неё. Manus переписывали свой harness пять раз за шесть месяцев: те же модели, пять разных архитектур ограничений — и каждая итерация улучшала результат. Vercel убрал у своего агента 80% инструментов — и агент заработал лучше: меньше опций, меньше места для ошибки. У меня в ежедневной работе 17 агентов, и стабильны они не благодаря самой крутой модели или «магическим промптам», а благодаря строгим ограничениям, где шаг в сторону невозможен.
На практике harness — это skill: чёткая инструкция из пяти элементов. Что делать (один абзац, без воды). Как делать (максимум три шага). Критерии приёмки (не выполнены — результат не засчитывается). Точный формат ответа. И запреты (чего не делать никогда). Один skill — одна задача; если задача слишком широкая, её делят на две.
Звучит контринтуитивно, но больше ограничений означает более стабильный результат: сужение задачи и чёткие критерии поднимают долю успешных выполнений примерно до 90%. Посредственная модель в строгом harness надёжнее самой умной в хаосе. Это, кстати, не только про AI: вспомните лучшего сотрудника без чёткого ТЗ — результат каждый раз разный.
Почему «ты — опытный сеньор» не работает
Второй слой — сами инструкции. Популярный рецепт «дай модели роль — и она станет умнее» не работает. Anthropic описали эту ошибку мышления и назвали её «Claude Mythos Problem».
Роль не добавляет модели знаний — она активирует стереотип из обучающих данных. «Опытный senior engineer» в датасете — это не опыт конкретного инженера, а LinkedIn-посты про work-life balance, осторожные корпоративные вики и средние ответы с форумов. Агент будет звучать именно так: усреднённо, предсказуемо, неинтересно.
Вместо этого работает функциональная роль:
❌ «Ты — лучший code reviewer с 20 годами опыта»
✅ «Ты code reviewer. Получаешь изменения кода. Возвращаешь максимум 5 замечаний с пометками: критично / предупреждение / мелочь»
Первое — идентичность: ноль новой информации для модели. Второе — цель, инструкции и критерии приёмки. Модели не нужно знать, «кто она». Ей нужно знать, что она получает на вход, что возвращает на выход и где граница качества.
Агент, который живёт в прошлом
Третий слой лучше всего виден на примере из разработки. Claude написал getServerSideProps — подход, от которого проект отказался три года назад. Агент внимательно читает код, понимает архитектуру, помнит контекст — и при этом застрял в 2023 году, если речь о документации.
У каждой модели есть cutoff date — дата, после которой она не знает ничего. Вышел Next.js 14 — у модели ещё 13. React 19 принёс новые инструменты — модель предлагает старые. И это не «иногда ошибается», а систематическое поведение: с каждой популярной библиотекой приходится проверять, актуален ли ещё метод. Технарь, привыкший доверять подсказкам агента, теряет на таких проверках час в день.
Решение простое. Context7 от Upstash — MCP-сервер, который подключается к Claude Code (Cursor и Codex тоже) и даёт агенту свежую документацию библиотек в реальном времени, прямо из источника, а не из памяти модели. Настройка — пять минут: одна команда, дальше достаточно добавить «use context7» в запрос. Реальный пример: свежая документация библиотеки за 30 секунд, модуль переписан на новый API — ни одной выдуманной функции, код заработал с первого раза.
Чек-лист: что спросить у подрядчика
Эти три слоя не видны в демо — на презентации агент всегда работает. Зато их легко проверить вопросами:
Вопрос | Ответ, который стоит услышать |
|---|---|
Как вы ограничиваете агента? | У каждого есть skill: цель, шаги, критерии приёмки, формат, запреты |
Сколько задач выполняет один агент? | Одну. Широкие задачи делим между несколькими агентами |
Что будет с неправильным результатом? | Не прошёл критерии приёмки — не засчитывается |
Пишете ли в промптах «ты — лучший эксперт»? | Нет, роли функциональные: вход, выход, граница качества |
Откуда агент берёт документацию? | Живая документация в реальном времени (MCP), не только память модели |
Результаты нестабильны — ваши действия? | Сужаем задачу и усиливаем ограничения, а не меняем модель |
Если на последний вопрос звучит «перейдём на более мощную модель» — это красный флаг: замена двигателя там, где не хватает руля и тормозов. Нестабильность — признак слабого harness, а не слабой модели.
Хотите понять, почему ваш агент работает нестабильно? AI-аудит Grow2.ai разбирает это на конкретном процессе. Базовый гайд: AI-агенты для МСБ. Если агенту предстоит жить в ваших процессах и CRM — это домен сестринского Auspex; стратегический взгляд на AI — у Andrew Maryasov.