Почему AI-агенту нельзя верить на слово: DeepSeek Harness и «ворота завершения»

Повод есть, готового продукта пока нет

Вокруг DeepSeek Harness появился сюжет о том, что в проекте якобы появился dsh-verification, переводящий состояние задачи из claimed-done в actually-done. Доступные материалы не позволяют подтвердить это как факт. В публичной истории изменений официального репозитория DeepSeek Harness есть релиз dsh версии 0.1.0-rc.7 от 17 августа 2026 года, но нет отдельного публичного компонента с таким названием и назначением.

Это не обесценивает саму тему, но меняет ее рамку. Архитектура DeepSeek Harness, или DSH, может давать разработчику точки для собственной проверки завершения. Однако расширяемость архитектуры не означает, что встроенная политика уже существует. Тем более она не доказывает, что система автоматически снизила число ложных завершений задач.

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

Сам DeepSeek Harness полезен как предмет разбора, потому что completion gate должен жить не в финальной реплике модели и не в зеленом статусе интерфейса. Его место в агентном runtime, который управляет циклом агента, вызовами инструментов, журналом событий, артефактами выполнения и правилами приемки.

• Подтверждено: DeepSeek Harness существует как публичный проект DeepSeek AI, а история его изменений доступна в GitHub.
• Не подтверждено: отдельный официальный плагин или пакет dsh-verification уже выпущен и включен в DSH.
• Практический вывод: текст модели не должен быть источником истины о финальном состоянии задачи.

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

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

Четыре разных смысла слова «готово»

Ложное завершение не обязательно связано с галлюцинацией. Агент может добросовестно принять слабый сигнал за успех: команда завершилась без ошибки, API вернул HTTP 200, в рабочем каталоге появился файл. Но ни один из этих признаков сам по себе не отвечает на главный вопрос: выполнен ли пользовательский критерий?

Полезно разделять как минимум четыре состояния. Claim означает, что модель сообщила о завершении. Attempt означает, что агент попытался выполнить действие, например вызвал инструмент или отправил команду. Receipt означает, что инструмент вернул наблюдаемый технический результат. Accepted означает, что независимая проверка сопоставила доказательства с заранее заданными условиями и допустила задачу к завершению.

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

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

• Claim: агент заявил о завершении; это намерение, а не доказательство.
• Attempt: вызов инструмента выполнен; это действие, но не обязательно результат.
• Receipt: есть ответ внешней системы или среды выполнения; его еще нужно интерпретировать.
• Accepted: проверка по правилам подтвердила критерии; только этот статус уместно показывать как завершение.

Почему ошибка лежит в runtime, а не только в модели

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

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

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

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

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

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

«Каждая часть продукта является плагином, включая адаптер модели, реестр инструментов, журнал сессии и сам агентный цикл.»

Как устроить completion gate: от заявления к доказательству

Completion gate не должен быть еще одним агентом, который спрашивает у первого, все ли в порядке. В минимально надежной реализации это детерминированный барьер перед финальным состоянием задачи. Он получает completion claim, читает правила приемки, собирает доказательства и возвращает одно из нескольких состояний: accepted, withheld, blocked или needs-human-review.

Withheld означает, что агент заявил о готовности, но проверка не получила достаточных подтверждений. Blocked означает, что проверить результат невозможно: нет доступа к среде, завис внешний сервис, отсутствуют секреты либо критерии приемки слишком расплывчаты. Это не эвфемизм для успеха. Честный blocked полезнее ложного done, потому что показывает место, где требуется решение человека.

Практический контур выглядит так. Модель завершает рабочий ход и формирует заявку. Runtime запускает верификатор: проверяет список измененных файлов и git diff, выполняет релевантные тесты, сверяет артефакты, читает состояние целевого сервиса. Затем он записывает итог и evidence bundle, то есть набор доказательств, в долговечный журнал. Только после этого интерфейс получает право показать завершение.

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

• Для кода нужны diff или commit SHA, команда целевого теста, код возврата, лог и сведения об окружении.
• Для сборки нужны конкретная build-команда, полный результат, идентификатор артефакта или его хэш.
• Для файла нужны путь, схема, размер или число записей, хэш и повторное чтение после записи.
• Для внешней операции нужны идентификатор в принимающей системе, устойчивый статус и при необходимости idempotency key.
• Для непроверенного исхода нужны явные состояния withheld или blocked, а не замаскированный успех.

Где ставить проверку в DeepSeek Harness

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

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

Нужна и обратная связь. Если gate отказал, модель должна получить структурированное объяснение: какой критерий не закрыт, какой лог отсутствует, какой тест завершился ошибкой и допустимо ли повторить действие. Формулировка «verification failed» почти бесполезна. Гораздо точнее указать, что изменен parser.ts, целевой тест npm test -- parser не запускался, а общий линтер не заменяет этот критерий.

Такой контур делает цикл агента строже: планирование, действие, наблюдение, проверка, затем принятие или возврат к работе. Это увеличивает задержку, но не требует полного набора end-to-end-тестов для каждого действия. Политика может выбирать уровень строгости по классу риска.

• Низкий риск: форматирование, статический анализ, проверка существования ожидаемого файла.
• Средний риск: целевые unit- и интеграционные тесты, проверка diff, контроль конфигурации.
• Высокий риск: миграции, публикации, операции с платежами или персональными данными; здесь нужны подтверждения целевой системы и часто проверка человеком.

«Exit code 0» не равен качеству: как выбирать критерии приемки

Распространенная ошибка при внедрении gate состоит в том, чтобы сделать его формально строгим, но содержательно пустым. Например, требовать только успешного запуска npm test. Такая команда может не включить новый тест, пропустить пакет из-за конфигурации или выполниться в среде с кэшем, скрывающим проблему. Проверка полезна, только если связана с конкретным требованием.

Критерии приемки стоит формулировать до запуска агента и по возможности в машиночитаемом виде. Не «почини авторизацию», а «при истекшем токене API возвращает 401, при валидном возвращает 200, добавлен регрессионный тест, тест запускается в указанном пакете». Не «загрузи отчет», а «в хранилище появился объект по заданному ключу, его SHA-256 совпадает с локальным, метаданные содержат ожидаемую версию».

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

Для команд, использующих DSH с реальными API, сохраняется отдельный контур ответственности. Локально можно проверять diff, логи, тесты и артефакты. Отправка исходного кода, пользовательских данных или секретов модельному провайдеру требует собственной оценки информационной безопасности и договорных условий. Completion gate не решает допустимость передачи данных: он контролирует приемку результата в рамках выбранного процесса.

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

Ложное завершение также является вопросом безопасности

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

Входные данные для verifier и правила принятия нельзя строить на доверии к произвольному тексту из контекста. Допустимые команды, обязательные проверки, пути к артефактам и формат evidence bundle должны задаваться политикой проекта. Результат веб-поиска или содержимое issue могут подсказать агенту дальнейшие действия, но не должны переписывать условия приемки.

Даже независимый LLM-судья не заменяет такой барьер. Вторая модель иногда полезна как вспомогательный анализатор логов или генератор гипотез, однако ее вывод остается вероятностным. Финальное решение о статусе разумнее основывать на детерминированных проверках, а сложные и неоднозначные случаи передавать человеку.

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

• Отделяйте policy-конфигурацию от контента, который агент прочитал во время работы.
• Не позволяйте инструментальному выводу менять критерии приемки без явного решения оркестратора.
• Ведите неизменяемый или append-only журнал заявок, проверок и итоговых статусов.
• Для неоднозначных операций используйте needs-human-review как нормальный продуктовый исход.

Что разработчик может внедрить уже сейчас

Даже без официального dsh-verification команда может собрать базовый completion gate поверх собственного агентного контура. Начать стоит с изменения семантики статусов: сообщение модели «готово» должно становиться claimed, а не completed. Одно это решение делает видимой разницу между отчетом агента и решением системы.

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

Наконец, измерять стоит не число зеленых карточек в интерфейсе, а качество доказательств. Полезны внутренние метрики: доля задач с полным evidence bundle, число заявок, удержанных gate, доля повторных попыток после отказа, количество случаев, когда проверка выявила расхождение между claim и фактическим состоянием.

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

• Переименуйте внутренний финальный сигнал модели в completion_claim.
• Опишите acceptance criteria для трех-пяти самых частых сценариев команды.
• Добавьте read-only verifier и сохранение evidence bundle.
• Разведите состояния accepted, withheld, blocked, failed и needs-human-review.
• Периодически разбирайте случаи, когда агент заявил о готовности до появления доказательств.

Практический чек-лист для команды

Этот чек-лист можно использовать при настройке приемки задач в агентном контуре. Его печатная версия должна быть собрана отдельным файлом downloads/deepseek-harness-completion-gate-checklist.pdf и добавлена на лист Downloads.

Семантика статусов

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

• Не переводите задачу в completed сразу после финальной реплики модели.
• Храните completion_claim отдельно от финального статуса задачи.
• Показывайте withheld и blocked как самостоятельные исходы, а не как успешное завершение.

Правила приемки

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

• Укажите целевые команды, ожидаемые артефакты и условия успеха.
• Свяжите проверку с конкретным риском и измененным компонентом.
• Задайте условия, при которых требуется needs-human-review.

Evidence bundle

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

• Сохраняйте diff или commit SHA, команды, коды возврата и логи.
• Фиксируйте версию окружения, время запуска и идентификаторы внешних операций.
• Проверяйте результат повторным чтением или запросом к целевой системе, если задача меняет внешний объект.

Вывод

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

Публичных оснований говорить о готовом официальном dsh-verification пока недостаточно. Однако расширяемый runtime, журналирование и событийный контур DSH дают практическую модель: completion gate должен работать там, где система видит действие и его доказательства, а не там, где модель формулирует отчет.

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

Источники

• DeepSeek AI: история изменений репозитория DeepSeek Harness
• DeepSeek GitHub: dsh-verification: a completion gate for agents — claimed-done becomes actually-done
• HologramSteve: deepseek-harness
• HenryZ838978: технический отчет deepseek-harness
• HenryZ838978: README deepseek-harness
• rjmurillo/ai-agents: issue 3016
• openclaw/openclaw: issue 14159
• microsoft/autogen: discussion 7763

Частые вопросы

Подтвержден ли официальный плагин dsh-verification для DeepSeek Harness?

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

Почему сообщение AI-агента «задача готова» нельзя считать результатом?

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

Какие статусы нужны вместо одного done?

Минимальная схема различает claim, attempt, receipt и accepted. Для неполной или невозможной проверки полезны отдельные исходы withheld, blocked, failed и needs-human-review.

Что должен содержать evidence bundle?

Состав зависит от задачи, но обычно включает diff или commit SHA, команды, коды возврата, логи, сведения об окружении, хэши артефактов и подтверждения от целевой внешней системы.

Может ли другая LLM выполнять финальную приемку?

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

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

Чек-лист: как внедрить completion gate для AI-агента

PDF для downloads должен повторять практический чек-лист статьи в компактном печатном формате: статусы, критерии приемки и состав evidence bundle.

Семантика статусов

• Не переводить задачу в completed после финальной реплики модели.
• Хранить completion_claim отдельно от финального статуса.
• Использовать самостоятельные исходы withheld, blocked, failed и needs-human-review.

Правила приемки

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

Доказательства

• Сохранять diff или commit SHA, команды, коды возврата и логи.
• Фиксировать окружение, время и идентификаторы внешних операций.
• Проверять внешний результат повторным чтением или запросом к целевой системе.