DeepSeek V4 и AI harness: почему важна цена эксперимента, а не токена

AI harness: управляющий слой, а не новая модель

South China Morning Post сообщает, что DeepSeek тестирует направление AI harness на фоне эффекта дешёвой V4 для рынка ИИ-разработки. Сам по себе этот сигнал не означает, что у компании уже есть готовый корпоративный продукт для заказчиков. Однако он показывает сдвиг в конкуренции: важны не только качество отдельного ответа модели, но и стоимость с надёжностью длинного цикла, в котором система понимает задачу, вызывает инструмент, проверяет результат и исправляет ошибку.

В таком цикле модель является только одним компонентом. Ей нужны контекст, доступ к разрешённым действиям, правила остановки, журналирование и проверка результата. Эту связку обычно называют AI harness. Именно она определяет, станет ли дешёвый вызов модели контролируемым рабочим процессом или серией непредсказуемых попыток.

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

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

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

Публикацию SCMP корректно рассматривать как свидетельство интереса DeepSeek к агентной обвязке. Она не подтверждает публичный выпуск готовой enterprise-платформы.

• Контекст: инструкции, история задачи, результаты предыдущих действий и данные, нужные для текущего шага.
• Инструменты: поиск, API, терминал, базы знаний, среды тестирования и другие разрешённые операции.
• Оркестрация: цикл «модель → действие → наблюдение → следующий шаг».
• Контроль: права доступа, лимиты, аудит, изоляция рискованных операций и условия остановки.
• Оценка: измерение результата, ошибок, повторов, задержки и стоимости выполнения.

Цитата в переводе

«Я каждый день собеседую кандидатов и размещаю вакансии на разных платформах.»

Почему дешёвая модель меняет экономику эксперимента

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

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

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

Документация DeepSeek публикует сведения о моделях и тарифах API. Это исходные параметры, а не готовый бизнес-кейс. Для конкретной команды важнее стоимость успешного результата: сколько вызовов потребовалось, сколько раз агент ошибся, сколько токенов ушло на вывод, понадобился ли человек и пришлось ли запускать процесс заново.

Именно здесь дешёвая V4, о которой пишет SCMP, способна создавать давление в дорогих сценариях крупных игроков. Причина не в том, что любая недорогая модель превосходит флагманскую. Массовые вспомогательные шаги в агентном контуре перестают автоматически требовать самого дорогого варианта. Премиальный стек должен подтверждать свою ценность качеством сложных ответов, надёжностью, безопасностью, интеграциями и условиями обслуживания.

• Сравнивайте не цену токена, а цену верно завершённой задачи.
• Включайте в расчёт повторы, ошибки инструментов, выходные токены и ручные исправления.
• Дешёвые прогоны позволяют чаще проверять изменения, но не отменяют оценку качества.
• Более дорогая модель может оказаться выгоднее, если решает сложный случай за меньшее число попыток.

Кэширование: экономия зависит от структуры контекста

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

Harness может выстраивать запрос так, чтобы повторяемая часть была отделена от динамической. В стабильный слой помещают общие правила и неизменяемые определения. Затем добавляют конкретный запрос, свежие результаты поиска, содержимое файлов, данные текущей операции и ответы инструментов.

Такая организация полезна не только для потенциального кэширования. Она облегчает аудит контекста и поиск причин ошибки. Команда может увидеть, какие данные получили модель и инструмент на конкретном шаге, а затем воспроизвести проблемную траекторию.

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

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

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

Маршрутизация: дешёвый поток не должен быть единым

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

Более сильную модель разумно оставлять для сложных исключений, нетипичных задач и финальной проверки, где ошибка обходится дороже. Это не готовая универсальная схема, а гипотеза, которую нужно измерять на собственном рабочем наборе.

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

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

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

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

В агентных сценариях harness отвечает за корректность протокола

Обвязка важна не только как финансовый контролёр. В документации DeepSeek для thinking mode описаны требования к продолжению диалога после вызовов инструментов: приложение должно корректно передавать связанное с рассуждением содержимое. Нарушение этого порядка может привести к ошибке API.

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

Чем длиннее траектория и чем больше в ней ветвлений, тем выше цена ошибки в этой логике. Задача может не только дать слабый ответ, но и оборваться либо начать повторять бесполезные действия. Поэтому многоходовые tool calls нужно тестировать отдельно от обычного чата.

Thinking mode требует отдельной политики расходов и качества. Его нельзя считать автоматическим улучшением для любой операции. Для части рутинных задач рациональнее использовать более простой маршрут, а сложный режим оставлять для случаев, где его польза подтверждена проверкой. Иначе экономию на входе перекроют объём вывода и дополнительные циклы.

Сторонний репозиторий deepseek-harness показывает, что сообщество выделяет этот слой в самостоятельный объект разработки, с библиотечными компонентами, интерфейсами командной строки и тестовой практикой. Это не официальный продукт DeepSeek и не сертификат надёжности. Однако такие проекты подчёркивают, что агентный контур следует тестировать системно, а не оценивать по одному удачному диалогу.

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

Где эффект заметнее всего

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

В корпоративном поиске по внутренним знаниям повторяются правила ответа, ограничения доступа и форматирование. Поэтому структура контекста здесь особенно важна. Сам по себе RAG не гарантирует достоверности: отдельно нужно контролировать качество поиска, актуальность источников, права на документы и поведение модели при недостатке данных.

В пакетной обработке тикетов, документов и журналов событий важна предсказуемость типового потока. Модель может извлекать данные или формировать структурированный JSON, а harness валидирует схему, ограничивает повторные попытки и передаёт сомнительные случаи на другой маршрут либо человеку. Документация DeepSeek описывает режим JSON-ответов, но техническая возможность формата не заменяет проверку бизнес-правил.

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

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

Российский контекст: начинать следует с данных и контроля

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

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

Материалы DeepSeek и его экосистемы на GitHub дают разработчикам точки входа для интеграций, а документация описывает API-интерфейсы. Это может упростить создание адаптера между бизнес-логикой и поставщиком модели. Однако совместимость интерфейса необходимо проверять на реальных сценариях, особенно при использовании инструментов, режимов рассуждений и структурированных ответов.

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

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

Цитата в переводе

«Это означало бы, что тестирование, которое проводят сами разработчики модели, может не отражать её фактическое поведение после внедрения.»

Как проверять эффект до масштабирования

Пилот harness-проекта следует оценивать по рабочим задачам, а не по сравнению двух удачных ответов в чате. Для каждой задачи полезно заранее определить критерий успеха: корректный структурированный результат, пройденная проверка, верно обработанное исключение или действие, подтверждённое оператором. Затем фиксируют стоимость, время, число модельных вызовов, tool calls, повторы и ручные вмешательства.

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

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

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

• Определите критерий успеха до запуска теста.
• Измеряйте стоимость успешной задачи, а не среднюю стоимость запроса.
• Проверяйте сбои инструментов, остановку агента и сценарии с несколькими шагами.
• Сравнивайте маршруты на одинаковом наборе и сохраняйте результаты для регрессий.

Практический чек-лист пилота

Перед масштабированием сохраните результаты пилота и пройдите чек-лист на реальных задачах. Материал подходит для отдельного файла PDF в папке downloads.

Что это означает на практике

Главный эффект дешёвой модели, о которой SCMP пишет применительно к DeepSeek V4, не в автоматической отмене дорогих моделей. Часть повторяемой агентной работы можно чаще запускать, проверять и улучшать при более низкой предельной цене эксперимента.

Экономия реализуется только через качественный harness. Он определяет, какой контекст увидит модель, какие инструменты она сможет вызвать, когда процесс остановится, как будут ограничены расходы и можно ли воспроизвести ошибку.

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

• AI harness является слоем управления контекстом, инструментами, доступами, лимитами, аудитом и тестами, а не новой языковой моделью.
• Низкую цену модели следует оценивать через стоимость успешно завершённой задачи, включая повторы, ошибки инструментов, выходные токены и ручную доработку.
• Стабильная структура контекста может улучшить экономику входных токенов при cache hit, но не отменяет стоимость вывода и не гарантирует попадание в кэш.
• Практичная гипотеза для пилота: дешёвый маршрут для массовых вспомогательных операций, более сильный для сложных исключений, человек для рискованных действий.
• До масштабирования отдельно проверьте многоходовые tool calls, передачу reasoning content, ограничение повторов и реакцию на сбой инструмента.
• Для российского внедрения исходной точкой должны быть классификация данных, права агента и требования к журналированию, а не только выбор поставщика модели.

Источники

• South China Morning Post, China’s DeepSeek tests AI ‘harness’ as cheap V4 model jolts Silicon Valley
• GitHub, deepseek-harness
• Документация DeepSeek API, Thinking mode
• Документация DeepSeek API, Updates
• Документация DeepSeek API, Pricing
• Документация DeepSeek API, JSON mode
• GitHub, deepseek-ai/awesome-deepseek-agent
• GitHub, DeepSeek AI

Практический чек-лист

Чек-лист пилота AI harness

Содержимое этого чек-листа предназначено для отдельного PDF-файла downloads/deepseek-ai-harness-pilot-checklist.pdf. В DOCX общий заголовок должен иметь стиль «Заголовок 3», названия блоков «Заголовок 4», а пункты должны быть штатными маркированными списками Word.

Цель и метрики

• Выберите рабочие задачи, а не демонстрационные диалоги.
• Определите критерий успеха для каждой задачи до запуска теста.
• Фиксируйте стоимость, время, число вызовов модели, tool calls, повторы и ручные вмешательства.
• Считайте стоимость успешно завершённой задачи, а не среднюю цену запроса.

Контекст и кэширование

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

Маршрутизация и безопасность

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

Надёжность агентного цикла

• Тестируйте многоходовые вызовы инструментов отдельно от обычного чата.
• Проверяйте неполные данные, длинный контекст, ошибки инструментов и обязательную остановку агента.
• Логируйте решения маршрутизатора, вызовы инструментов, ошибки и финальное состояние задачи.
• Добавьте проблемные случаи в регрессионный набор после каждого выявленного сбоя.