Модель — не главное

Качество работы с кодящим агентом почти не зависит от того, какая под капотом модель. Я довольно долго в это не верил — менял модели, крутил промпты, ждал следующий релиз. Казалось, что стоит взять чуть более мощную модель или правильнее написать системный промпт — и всё заработает как надо.

Оказалось — нет. Разница не в модели. Она в том, что вокруг модели: есть ли у агента память между сессиями, карта проекта, правила, инструменты и место под результат. Голая модель — это эрудит без рабочего места. Каждый разговор она начинает с чистого листа, не помня ни структуры кодовой базы, ни договорённостей из прошлых сессий, ни того, что уже было сделано и что пошло не так.

Что такое харнесс

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

Ниже — разбор моего харнесса целиком, слой за слоем, на одном реальном проекте: пять сервисов, Kubernetes, прод. Не идеальная схема из README и не теоретическая архитектура — а то, что реально видно в логах: что вызывается каждый день, а что я нагородил и давно забыл.

Что показали 98 сессий

Спойлер: половина подключённых MCP-серверов (MCP, Model Context Protocol — стандартный протокол для подключения внешних инструментов к языковым моделям) за 98 сессий не вызвалась ни разу. Это не теоретическое предположение — это то, что видно в логах конкретного проекта.

Сразу оговорюсь: сессии сохранились не все — у Claude Code, похоже, есть ротация логов, часть истории потерялась. Так что мои числа — это нижняя граница, реальные ещё выше. Но даже этих данных достаточно, чтобы поставить под сомнение то, что принято считать «правильной» конфигурацией агента: значительная часть подключённых инструментов на практике оказывается мёртвым грузом.