Симптом: DeepSeek Harness долго показывает выполнение, но новых результатов нет.
Самое быстрое решение: сначала найдите подтверждение фактического LLM retry, затем отделите ошибку API или сети от сбоя конфигурации и блокировки инструмента. Если нового события старта нет, сохраните материалы диагностики — логи, сессию и состояние процесса — и отмените задачу вместо бесконечного ожидания или обновления страницы.

В документации DeepSeek API отдельно указано, что запрос может оставаться подключённым в ожидании ответа, а если инференс не начался в течение 10 минут, сервер закрывает соединение. Это не означает, что каждый долгий запрос является повторной попыткой. (api-docs.deepseek.com)

Кому нужна эта инструкция

Она предназначена для трёх групп:

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

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

Сначала отделите ожидание интерфейса от настоящего повтора

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

Это только гипотеза.

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

  1. система зафиксировала, что следующая попытка запланирована;
  2. новый запрос действительно начал выполняться.

В официальной структуре постоянных событий DeepSeek Harness эти стадии разделены. Поэтому запись о планировании нельзя считать доказательством отправки запроса. Если между ними нет события старта, возможны отмена ожидания, остановка процесса, потеря внутреннего воркера или блокировка очереди.

Что проверить в первую очередь

Откройте журнал сессии и найдите:

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

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

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

Когда прекращать ожидание

Остановите задачу и сохраните материалы диагностики, если одновременно выполняются два условия:

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

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

Шаг первый: проверьте, начался ли следующий запрос

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

Проверяйте пару событий:

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

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

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

Шаг второй: отделите ошибку API и сети от ошибки конфигурации

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

Официальная документация DeepSeek API требует Bearer-аутентификацию. Для актуальных моделей также нужно проверить допустимое имя модели и базовый URL. В текущей документации перечислены deepseek-v4-flash и deepseek-v4-pro, а адрес OpenAI-совместимого API указан как https://api.deepseek.com. (api-docs.deepseek.com)

Проверьте четыре значения:

  • переменную с API-ключом;
  • фактический Base URL, включая отсутствие лишнего пути;
  • имя модели в текущем Provider;
  • режим совместимости и формат запроса.

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

Минимальная проверка цепочки

После исправления конфигурации не запускайте сразу большую Agent-задачу. Используйте короткий запрос без инструментов:

curl https://api.deepseek.com/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -d '{
    "model": "deepseek-v4-flash",
    "messages": [
      {"role": "user", "content": "Ответьте одним словом: готово"}
    ],
    "stream": false,
    "max_tokens": 16
  }'

Параметры должны соответствовать вашей актуальной документации и конфигурации. Официальный справочник описывает формат сообщений, модели, max_tokens, потоковую выдачу и инструменты. (api-docs.deepseek.com)

В этой проверке вы не доказываете исправность всего Harness. Вы проверяете только связку «ключ — Base URL — Provider — модель — базовый запрос».

Учитывайте ограничение параллелизма

Превышение лимита параллельных запросов приводит к HTTP 429. В опубликованной таблице DeepSeek API текущие лимиты зависят от модели и аккаунта: для deepseek-v4-pro указано 500 одновременных подключений, для deepseek-v4-flash — 2 500. Эти значения нельзя переносить на другую дату или другой аккаунт без повторной проверки. (api-docs.deepseek.com)

Если несколько фоновых задач одновременно получают 429, увеличение LLM retry лишь растягивает очередь. Сначала уменьшите параллелизм, проверьте аккаунтный лимит и убедитесь, что несколько ключей не используются как способ обойти общий лимит аккаунта.

Шаг третий: проверьте ответ модели после успешного вызова

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

В документации DeepSeek API отдельно отмечено: при response_format с типом json_object нужно явно попросить модель сформировать JSON. Иначе она может выдавать бесконечный поток пробелов до достижения лимита генерации, что выглядит как зависший запрос. (api-docs.deepseek.com)

Проверьте:

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

Если API вернул ответ, но Harness снова отправляет тот же запрос, ищите причину в валидаторе результата, а не в доступности модели. Возможен цикл: ответ получен, парсер его отверг, задача повторила вызов, но исходная причина не изменилась.

Шаг четвёртый: найдите блокировку инструмента

Успешный ответ LLM не равен завершению Agent-задачи. Модель могла вернуть вызов Bash, Hook, внешнего API или этапа согласования. Пока инструмент не вернул результат, следующий запрос модели может не начаться.

Наблюдаемые сигналы:

  • есть событие завершения LLM;
  • есть событие вызова инструмента;
  • нет события завершения инструмента;
  • интерфейс продолжает показывать общий статус «выполняется»;
  • новых запросов к модели нет.

Проверяйте инструменты по одному:

  1. есть ли запись о передаче вызова в инструмент;
  2. был ли показан запрос на подтверждение;
  3. получил ли пользователь или оператор запрос на согласование;
  4. запустился ли дочерний процесс;
  5. вернул ли он код завершения и вывод;
  6. доступна ли рабочая директория;
  7. не ждёт ли Hook внешнего ресурса.

Опасная ошибка: не открывайте все разрешения «для проверки». Это может скрыть проблему согласования и одновременно дать Agent-у доступ к нежелательным командам или файлам. Сначала повторите один безопасный инструментальный вызов с минимальными правами.

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

Шаг пятый: проверьте удалённый процесс и окружение

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

Проверьте:

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

Разделяйте два случая.

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

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

Для удалённой работы полезно заранее определить процедуру приёмки фоновых задач DeepSeek Harness и отдельно зафиксировать условия проверки облачного Mac после восстановления. Это снижает риск принять живое соединение за живой процесс.

Как решать: ждать, отменять или переносить

Перед действием отметьте пункты ниже:

  • [ ] Найдено последнее подтверждённое событие ответа модели.
  • [ ] Проверено наличие пары «повтор запланирован — повтор начат».
  • [ ] Проверено состояние основного и дочерних процессов.
  • [ ] Сохранены журнал, версия, сессия и конфигурация Provider.
  • [ ] Проверены API-ключ, Base URL и имя модели.
  • [ ] Отделён ответ LLM от завершения инструмента.
  • [ ] Проверены Hook, Bash, согласование и рабочая директория.
  • [ ] Установлено, изменяется ли состояние задачи.
  • [ ] Выполнен минимальный запрос без инструментов.
  • [ ] Для удалённой среды проверены сон, перезагрузка и смена идентичности.

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

Три таблицы для фиксации решения

Сигнал Вероятная зона сбоя Следующая проверка Стоп-условие
Только индикатор выполнения Web UI или зависшее состояние сессии журнал событий и процесс нет новых событий
Планирование повтора без старта очередь, отмена или воркер состояние процесса и события ожидание неуправляемо
Одинаковый ответ API ключ, URL, модель или лимит минимальный запрос без инструментов ошибка повторяется
Ответ модели есть, результата нет парсер, инструмент или Hook событие завершения инструмента инструмент не отвечает
Соединение оборвалось сеть или удалённая среда процесс, путь, время файлов среда изменилась
Доказательство Что записать Зачем это нужно
Версия Harness точная строка версии или сборки исключить изменение поведения
Сессия идентификатор и время запуска связать события в одну цепочку
LLM retry планирование и фактический старт отличить намерение от запроса
API модель, Base URL без секрета, ответ проверить конфигурацию и лимиты
Инструмент имя, начало, завершение, вывод отделить Agent-блокировку от API
Окружение процесс, путь, сеть, перезапуск подтвердить состояние удалённой среды
Восстановление минимальный тест и результат не объявлять задачу исправной преждевременно
Условия Решение Почему
Есть новые события и жив процесс продолжать наблюдение работа подтверждается фактами
Нет старта повтора отменить после сохранения повтор не доказан
Ошибка одинакова после исправления остановить и исправить конфигурацию дополнительные попытки не меняют причину
LLM завершён, инструмент завис диагностировать инструмент модельный вызов уже выполнен
Среда перезапущена или изменилась создать новую задачу старая сессия может ссылаться на устаревшее окружение

Что выбрать вместо бесконечного ожидания

Если вы запускаете DeepSeek Harness локально, сначала проверьте процесс, журнал и короткий API-запрос на текущей машине. Такой вариант удобен для разовой диагностики, но требует ручного контроля сна, сетевого выхода, ключей и состояния рабочей директории.

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

MACCOME может быть полезен, когда вам нужен временный Mac для проверки длинной задачи, повторного запуска после сбоя сети или сравнения локального и удалённого окружения. Но для постоянной тяжёлой нагрузки, фиксированного физического оборудования или задач с обязательным локальным интерфейсом аренда подходит не всегда. В этих случаях разумнее оставить стабильный собственный контур, а MACCOME использовать для контролируемых тестов, резервного запуска и восстановления фоновых задач.

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