DeepSeek Harness: приём изображений в 2026

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

Он также нужен платформенным инженерам, подключающим редакторы и внешние инструменты через MCP или ACP.

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

Дата последней проверки — 18 августа 2026 года. Факты сверены с текущей документацией Provider, официальной документацией API и спецификациями MCP. Возможности rc.7, связанные с постоянными изображениями для MCP и ACP и передачей вложенных изображений в PTC Mode, рассматриваются здесь как заявленная функция релиза. Фактическая совместимость по-прежнему зависит от модели, Provider и конкретной цепочки передачи.

У изображения в интерфейсе есть несколько разных состояний. Их нельзя смешивать.

Первое состояние — локальный выбор файла. Клиент увидел файл и построил миниатюру.

Второе — запись вложения в сообщение. Сессия запомнила имя, URI, MIME-тип или внутренний идентификатор.

Третье — передача ресурса по транспортному каналу. В запросе действительно присутствует бинарное содержимое, ссылка на ресурс или допустимый блок изображения.

Четвёртое — чтение изображения моделью. Выбранный endpoint способен принять изображение и реально использует его как вход.

Пятое — повторное чтение после обновления, переподключения или запуска дочерней задачи.

Ошибка возникает, когда проверяют только первое состояние. Миниатюра может быть результатом UI-кэша. Сессия может хранить текст задачи, но не сам файл. MCP-ресурс может иметь URI, который больше недоступен. ACP может передать метаданные, но не содержимое. Provider может принять запрос, проигнорировав неподдерживаемый блок.

В официальной спецификации MCP ресурсы могут содержать бинарные данные, включая изображение с MIME-типом и кодированным содержимым. Однако спецификация оставляет приложению решение о том, как ресурс выбирается, включается в контекст и сохраняется. Поэтому наличие формата в протоколе не означает, что конкретная сборка DeepSeek Harness сохранит файл после перезапуска. (modelcontextprotocol.io)

Начинайте приёмку не с загрузки файла, а с конфигурации модели.

Название вроде «vision», «multimodal» или «pro» не является доказательством. Нужна явная декларация поддержки изображений в профиле модели или Provider. Мы фиксируем три артефакта:

• снимок конфигурации с признаком поддержки изображений;
• запись клиентского решения — разрешил Harness вложение или заблокировал его;
• ответ upstream на контрольный запрос.

Особенно важно разделять собственную декларацию Provider и реальную поддержку upstream. Пользовательский Provider может сообщать, что принимает изображения, хотя подключённый endpoint поддерживает только текст. В таком случае конфигурация проходит формальную проверку, но рабочая цепочка должна получить статус «ограничено» или «отказ».

В текущей документации chat-completions указаны текстовые поля сообщения, инструменты и параметры вызова, но отдельный универсальный image input для этого маршрута не заявлен. Поэтому DeepSeek API нельзя автоматически считать визуальным API только потому, что в каталоге появилась новая модель. Для сравнения нужно сверять модельную документацию и фактическую схему запроса. (api-docs.deepseek.com)

Полезно вести собственную карточку проверки:

• модель и версия конфигурации;
• адрес Provider без секретного ключа;
• заявленные типы входа;
• фактический MIME-тип;
• ответ на изображение;
• причина отказа, если запрос остановлен до отправки.

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

После проверки capability используйте тестовую картинку, которую невозможно перепутать.

Мы рекомендуем подготовить безопасный искусственный скриншот с тремя различимыми признаками:

• крупная буква в левом верхнем углу;
• отдельный цветной прямоугольник справа;
• короткая тестовая метка без персональных данных в нижней части.

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

Пошаговая проверка выглядит так:

1. Переименуйте файлы нейтрально, например test-left и test-right, но не полагайтесь только на имя.
2. Отправьте два изображения в известном порядке.
3. Добавьте задание, которое требует назвать признак только на первом и только на втором изображении.
4. Сохраните исходное сообщение и журнал транспортного уровня.
5. Сравните порядок блоков, MIME-тип, URI или идентификатор ресурса.
6. Проверьте, что ответ относится к содержимому, а не просто повторяет имена файлов.

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

Спецификация MCP отдельно описывает изображения как допустимый тип содержимого результата инструмента. Она также подчёркивает необходимость проверять MIME-тип и фактическое содержимое, а не доверять одному объявлению формата. Это прямо переносится на приёмку: расширение файла и миниатюра не заменяют проверку полезной нагрузки. (modelcontextprotocol.io)

MCP и ACP проверяйте раздельно. Не засчитывайте один успешный канал как доказательство работоспособности другого.

Для MCP фиксируйте:

• объявленные capabilities;
• тип ресурса;
• URI или встроенное содержимое;
• ответ сервера на повторное чтение;
• доступность ресурса после переподключения.

MCP допускает URI-ресурсы и бинарные данные. Это создаёт две разные модели хранения. В первой сессия содержит всё изображение. Во второй сессия содержит только ссылку, а файл хранится отдельно. Вторая модель ломается при смене рабочей директории, истечении доступа или передаче задачи другому оператору.

Для ACP фиксируйте:

• наличие image в prompt capabilities;
• идентификатор сессии;
• содержимое сообщения;
• факт получения вложения на стороне клиента;
• результат повторной загрузки сессии.

В опубликованном описании ACP-профиля capability promptCapabilities.image отделена от loadSession. Это важная граница: клиент может уметь принимать изображения в новом prompt, но не уметь восстановить старое изображение из сохранённой сессии. Не объединяйте эти два результата в один флаг «ACP работает». (agentproto.sh)

Проверка постоянства должна включать минимум четыре состояния:

1. обычное продолжение текущей сессии;
2. обновление страницы или перезапуск клиента;
3. переподключение к MCP или ACP;
4. перезапуск процесса Harness.

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

Разделяйте три вида состояния:

• UI-кэш — картинка всё ещё видна оператору;
• история сессии — запись содержит сообщение и ссылку;
• доступный актив — процесс действительно может снова прочитать байты изображения.

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

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

Для PTC Mode нужен отдельный тест главного и вложенного контекста.

Создайте две картинки с разными признаками. Главная задача должна прочитать деталь первой картинки. Дочерняя задача — деталь второй. В описании нельзя повторять сами ответы, иначе тест проверит текстовый контекст, а не изображение.

Соберите следующие доказательства:

• идентификатор главной задачи;
• идентификатор дочерней задачи;
• список вложений каждой задачи;
• порядок передачи;
• ответ дочерней задачи;
• ошибка и узел отказа, если изображение не дошло.

Результаты трактуются так:

• дочерняя задача назвала уникальную деталь второй картинки — передача подтверждена;
• дочерняя задача получила только описание — визуальный контекст потерян;
• дочерняя задача получила первую картинку вместо второй — нарушен порядок или область видимости;
• дочерняя задача не получила ресурс, а главный процесс продолжил работу — цепочка имеет ограничение;
• отказ произошёл на Provider — проблема не обязательно находится в PTC Mode.

Функция rc.7, заявленная для передачи вложенных изображений в PTC Mode, должна поэтому проверяться не одной загрузкой, а именно различающимися главной и вложенной задачами. Один и тот же вопрос для обоих уровней не показывает, какой ресурс реально был прочитан.

Отдельный риск — бесконечное повторение старого запроса с изображением.

Сценарий проверки:

1. Создайте сессию с тестовой картинкой.
2. Добейтесь отказа upstream или временно выберите Provider без image input.
3. Закройте клиент.
4. Восстановите старую сессию.
5. Посчитайте повторные запросы.
6. Проверьте, появляется ли то же вложение снова.
7. Выполните безопасный откат.

Безопасные варианты отката:

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

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

В журнале должны быть видны не только ошибка, но и решение маршрутизатора: почему вложение снова попало в запрос, какой идентификатор сессии использован и на каком этапе был выбран Provider.

Удалённую среду проверяйте как отдельный контур ответственности.

Перед запуском зафиксируйте:

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

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

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

При передаче окружения новому инженеру повторите тест с чистой сессией. Доступ старого оператора не должен быть единственным способом восстановить вложение.

• [ ] В конфигурации модели явно заявлен image input.
• [ ] Сохранён снимок настройки без секретных значений.
• [ ] Зафиксировано решение Harness: разрешить или заблокировать вложение.
• [ ] Сохранён ответ upstream на контрольный запрос.
• [ ] Использована искусственная тестовая картинка с различимыми деталями.
• [ ] Проверены MIME-тип, порядок и идентификаторы ресурсов.
• [ ] MCP проверен отдельно от ACP.
• [ ] Для ACP проверены и image capability, и восстановление сессии.
• [ ] После обновления клиента картинка снова прочитана.
• [ ] После переподключения каналов картинка снова прочитана.
• [ ] После перезапуска процесса проверен доступ к активу.
• [ ] PTC Mode проверен разными деталями для главной и дочерней задач.
• [ ] Зафиксирован узел отказа при неуспешной вложенной передаче.
• [ ] После ошибки Provider исключён бесконтрольный повтор.
• [ ] Подготовлены откаты: удаление вложения, смена модели или новая сессия.
• [ ] На удалённом Mac проверены путь, права и передача окружения.
• [ ] В доказательствах нет ключей, cookies и клиентских данных.

Решение принимаем по трём уровням:

• Проходит — модель принимает изображение, канал передаёт его, ресурс восстанавливается, PTC Mode получает правильную картинку, повторов после отказа нет.
• Ограничено — работает только новый prompt, только один канал или только текущий процесс. Такой сценарий можно оставить для эксперимента, но не для командной приёмки.
• Отказ — модель не заявляет image input, Provider отклоняет запрос, вложение теряется после перезапуска или дочерняя задача получает неправильный ресурс.

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

Если DeepSeek Harness отклоняет картинку, сначала проверяйте capability выбранной модели и реальную схему upstream. Если MCP или ACP успешно передали ресурс, но модель не может его прочитать, транспортный тест пройден, а модельный — нет.

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

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

Финальная запись должна позволять другому инженеру повторить проверку без доступа к исходным секретам.

Укажите дату, версию Harness, модель, Provider, канал, тип тестовой картинки, контрольные признаки, этапы перезапуска и итоговое решение. Для каждого провала добавьте ответственную границу: модель, клиент, MCP, ACP, PTC Mode, хранилище, права или восстановление.

Не пишите только «картинка отображается» или «загрузка успешна». Эти формулировки описывают интерфейс, но не доказывают передачу и чтение. Гораздо полезнее запись: «миниатюра отображается; upstream отклонил image input; вложение удалено; текстовый сценарий разрешён».

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

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