AI-разработка как совместно эволюционирующий стек: оборудование, модели, обвязка, инструменты и трассы

Формула Agent = Model + Harness полезна как первое приближение, но слишком быстро становится ловушкой. Она выносит за скобки стоимость вывода модели, реальную среду действий, идентичность, проверку результата и контур обратной связи. В итоге две команды могут купить одну контрольную точку и получить совершенно разный продукт: одна даст модели знакомое изменение, ограниченную оболочку и короткие результаты инструментов, другая — сотню новых схем JSON, шумный контекст и подтверждение каждого безопасного шага.010101Слово «стек» звучит слишком статично. Здесь полезнее думать о нескольких контурах управления, которые делят сигналы, но обновляются с разной скоростью.

У системы минимум шесть слоёв, и каждый отвечает на свой вопрос. Оценка модели описывает способность в заданном бенчмарке. Обвязка агента определяет, какой контекст и путь восстановления доступны. Среда выполнения превращает намерение в проверяемое изменение. Проверки показывают, пережило ли качество новый выпуск. Трассы дают материал для диагностики — но ещё не разрешение на обучение.

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

Ускоритель важен не только числом FLOPS. В Hopper Transformer Engine связывает FP8/FP16 с трансформерами, а NVLink — с ценой коммуникации между GPU. Blackwell развивает уже систему масштаба стойки, а в анонсе Vera Rubin NVIDIA прямо говорит о предельном совместном проектировании: CPU, GPU, соединения, хранение и сеть проектируются как один контур. Числа ускорения и TCO на этих страницах — заявления вендора; сам вектор проектирования наблюдается напрямую.

Самый наглядный сдвиг — расхождение обучения и вывода модели. Google TPU 8t и 8i стали двумя системами: первая оптимизирована под крупный предварительное обучение, вторая — под обслуживание, выборку и длинные рассуждения. Память, встроенная SRAM, сеть и коллективные операции меняются вместе с формой MoE и агентной нагрузки. Для CTO это означает, что тариф «за токен» скрывает решения поставщика о пакетной обработке, кеше, задержке и доступной ёмкости.

При этом полная вертикаль не является единственным путём. DeepSeek-V3 показывает обратное совместное проектирование: команда адаптировала FP8, MoE, балансировку экспертов и среду обучения к доступным H800. Отчёт о часах GPU остаётся самоотчётом, но архитектурная реакция на ограничение задокументирована. Anthropic и Annapurna Labs демонстрируют ещё один вариант — плотный партнёрский контур без владения облачным гиперскейлером.

Вызов функций проверяет способность сформировать запрос. Реальный агент должен ещё выбрать инструмент, пережить ошибку, продолжить после большого результата, проверить эффект и не расширить свои полномочия. Эти привычки формируются на распределении пространств действий, которое модель видела при дообучении.

Cursor описывает, как неделями адаптирует обвязку к новой модели: моделям OpenAI даёт знакомое редактирование изменениями, моделям Anthropic — замену строк. В отдельном разборе Codex команда меняла названия инструментов, преамбулу, обратную связь линтера и обработку трассы рассуждений, потому что модель была обучена сначала работать через оболочку. Это наблюдения компании, не открытый набор данных A/B, но они хорошо согласуются с природой дообучения.

Обвязка нужна не потому, что модель «недостаточно умна», а потому, что автономная работа требует протокола. Codex App Server включает жизненный цикл и постоянные ветки, конфигурацию и аутентификацию, изолированную среду, MCP и навыки под общей моделью политик. В экспериментах Anthropic с долго работающими агентами одной высокоуровневой подсказки и сжатия оказалось мало: понадобились инициализатор, список функций, артефакты прогресса, история Git и малые итерации.020202Мне нравится практическое определение: обвязка — временная теория слабостей текущей модели. Опасно лишь считать эту теорию вечной.

По мере роста надёжности ответственность перемещается. Cursor раньше жёстко перепроверял задачу, принудительно выполнял коммит и отправку и отдельно забирал журналы CI. Затем эти действия стали обычными инструментами под управлением модели. Но вокруг более слабого управления компьютером выросли отдельные маршрутизация, подагент и запись экрана. Обвязка не «заканчивается»: он перестаёт контролировать созревшую способность и начинает страховать новую.

MCP решает важную, но узкую задачу. Спецификация инструментов стандартизует обнаружение, схему и семантику вызова. Она не обещает, что модель видела похожую схему, выберет правильный инструмент среди десятков, получит компактный ответ или выполнит действие с корректной идентичностью.

Большой каталог может оказаться хуже нескольких знакомых примитивов. В кейсе code execution поверх MCP Anthropic показывает цену прямого подключения: схемы занимают контекст, а промежуточные результаты каждый раз проходят через модель. Пример с расшифровкой встречи добавлял около 50 тысяч токенов. Постепенное обнаружение и выполнение кода оставляют большие данные в изолированной среде, возвращая модели только нужный результат. Это не делает оболочку безопасной автоматически: вместе с композиционностью появляется новая поверхность политик пакетов, сети и секретов.

Поэтому внутренний инструментальный шлюз — не вспомогательный инфраструктурный проект. Это поведенческий продукт платформенной команды. Его преимущество находится не в числе подключённых серверов, а в качестве контрактов и в данных о том, как агенты ошибаются при выборе, аргументах, отказе и восстановлении.

Слово «трасса» часто используют как сокращение для магического самоулучшения. Полезнее развести четыре режима. Infrastructure telemetry оптимизирует обслуживание и таймауты. Продуктовая телеметрия показывает ошибки выбора инструментов, остановки из-за прав и сбои сжатия. Оценка результата связывает эпизод с тестами, слиянием, откатом или пользовательской коррекцией. Траектория обучения — специально отобранный и разрешённый поэтапный запуск с наградой или проверяющей программой.

Различие между траекторией и итогом принципиально. В методике Anthropic расшифровка — это последовательность шагов, а результат — состояние среды после работы. τ-bench добавляет надёжность серии прогонов: единичный успех не доказывает стабильность. GitHub отдельно проверяет выбор инструментов и аргументов MCP Server, а Databricks связывает сценарии, похожие на рабочие, трассы и регрессионные допуски. Всё это улучшает систему без изменения весов.

Даже если поставщик обучает модель в реалистичной среде, нельзя автоматически приписывать обучение всем клиентским сессиям. Cursor Privacy Mode запрещает использование клиентских данных для обучения; Anthropic отделяет коммерческие сессии от программ с явным согласием, а OpenAI по умолчанию не обучается на входах и выходах корпоративного API. Наблюдаемость, использование для оценки и обучение модели требуют разных политик, сроков хранения и правовых оснований.030303Самая дорогая зависимость от поставщика часто живёт не в API модели, а в закрытом формате эпизодов и результатов, которые нельзя воспроизвести у другого поставщика.

рабочий отказ → трасса + итоговое состояние → воспроизводимая проверка → изменение обвязки, инструмента или модели → повторный допуск → управляемый запуск

Общая схема телеметрии, например развивающиеся OpenTelemetry GenAI conventions, снижает стоимость экспорта. Но формат полей не определяет срок хранения, очистку и право обучения. Эти решения остаются у владельца системы.

Исходная гипотеза звучала провокационно: за 180 ± 60 дней половина значимой обвязки становится не нужна, заменяется или удаляется. Проверять её по текучести строк нельзя: большая разница интерфейса не обязательно меняет поведение агента. Поэтому в исследовании были зафиксированы десять механизмов — контекст, сжатие, планирование, редактирование, политики, обнаружение, изоляция, сохранение состояния, оркестрация и телеметрия с проверками — и просмотрена публичная история Codex, Gemini CLI и OpenCode.

Во всех трёх проектах за полгода существенно затронуты не менее семи механизмов. Но по строгому критерию — старый поведенческий путь действительно выведен, а не живёт рядом за флагом функции — достаточно ясная замена видна примерно у трёх-четырёх из десяти. Два независимых проекта с доказанными ≥ 5/10 не нашлись.

Погрешность здесь эпистемическая, а не статистическая. История Git не всегда показывает долю запуска, состояние развёртывания и роль флагов функций. Молодость проектов тоже увеличивает видимый темп. Зато стратегический вывод устойчив: собственная общая обвязка — не одноразовая сборка, а бессрочная программа совместимости.

Интеграция ускоряет обратную связь. Команда, которая одновременно видит поведение модели, продуктовые трассы и результат, быстрее связывает регрессию с нужным слоем. Высокая стоимость обучения передовых моделей, изоляции на нескольких ОС, ферм проверок и корпоративного архитектурного управления усиливает эффект масштаба. Но из этого не следует, что победит одна компания, владеющая всем.

Три разных пути к короткому циклу

• —Google связывает TPU, сеть, компилятор, модель, облако и распространение — это полная вертикаль от оборудования до продукта.
• —Anthropic владеет моделью и обвязкой, а совместное проектирование оборудования строит как партнёрство с AWS.
• —Cursor начал с рабочего процесса разработчика и распространения, накопил трассы и проверки, затем добавил собственное дообучение и модельный слой.

Контрсилы тоже реальны. Открытые веса DeepSeek, Qwen и GLM снижают барьер смены поставщика. Qwen Code и OpenCode выносят интерфейс сессии, разрешения и часть инструментов из-под контроля одной лаборатории. MCP и совместимые API уменьшают стоимость интеграции. RouteLLM показывает сам принцип маршрутизации между сильной и дешёвой моделями. А корпоративная среда может быть настолько специфична, что универсальный поставщик не видит ни полномочий, ни конечного результата.

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

Решение полезнее проводить не по логотипам поставщиков, а по двум осям: скорость изменения и уникальность для компании. Возможности передовых моделей меняются быстро и редко являются корпоративной спецификой. Идентичность, политики, доменные контракты действий и принятые результаты, наоборот, медленнее устаревают и определяют, что система вообще имеет право считать успехом.

Что не стоит строить по умолчанию

• —ещё один общий цикл агента разработки только ради смены конечной точки API;
• —собственное сжатие или оркестрация без регрессионного набора на реальных эпизодах;
• —каталог сотен MCP-инструментов без владельцев, ограничений ответа и телеметрии выбора;
• —«самообучение», в котором рабочие журналы автоматически считаются разрешёнными данными для обучения;
• —шлюз, приводящий всех поставщиков к общему минимуму и скрывающий их сильные стороны;
• —форк обвязки с открытым кодом без команды, отвечающей за слияние вышестоящих изменений, безопасность и совместимость с моделями.

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

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

Минимальная программа на один квартал

1. 01Выбрать 20–30 реальных эпизодов. Зафиксировать чистое исходное состояние, контракт задачи, допустимые инструменты и проверяемый результат.
2. 02Разделить режимы трасс. Отдельно определить рабочую телеметрию, проверку человеком, использование для оценки и допустимые траектории обучения.
3. 03Инвентаризировать контракты действий. Для каждого критичного инструмента записать идентичность, область доступа, идемпотентность, ограничение ответа, происхождение и владельца.
4. 04Собрать независимое от поставщика воспроизведение. Хранить эпизод, версию среды, версии модели, обвязки и инструментов и доказательство итогового состояния в переносимом формате.
5. 05Ввести повторные допуски к выпуску. Сравнивать не один удачный запуск, а качество, дисперсию, стоимость, безопасность и приёмку человеком.
6. 06Тестировать слой, а не бренд. При регрессии менять описание инструмента, контекст, политику, маршрутизацию или модель только через контролируемый эксперимент.

В этом контуре поставщик приносит быстро меняющуюся возможность, а компания сохраняет право выпуска. Новая модель может быть дешевле и сильнее в публичном бенчмарке — рабочий запуск всё равно проходит через внутренние эпизоды, проверки политик и сравнение принятых результатов. Это и есть практическая защита одновременно от технической и доказательной зависимости от поставщика.