выполнение инструментов DeepSeek Harness начинается с предложения от помощника, а не с разрешения на действие. Официальный конвейер регистрирует значение tool/call перед выполнением, а затем передает вызов через политику, защитные механизмы и обработку результатов. Это важно, когда агент может воздействовать на файлы, процессы или другие системы.
Это руководство охватывает документированный конвейер стороннего проекта с открытым исходным кодом DeepSeek Harness. В сведениях о публичном выпуске указано, что dsh-v0.1.0-rc.7 является предварительной версией, опубликованной 17 августа 2026 года, а в репозитории заявлена лицензия MIT. Эти факты дают контекст о проекте. Они не гарантируют стабильность в производственной среде, совместимость с OdiRouter или поддержку OdiRouter.
Начинайте с записи о вызове, а не с решения о выполнении
справка о выполнении инструментов начинается, когда сообщение ассистента содержит блок вызова инструмента. Перед выполнением он записывает tool/call. Пользовательский интерфейс может показать предлагаемое действие, пока среда выполнения его оценивает.
Сохраняйте в этой записи достаточно устойчивых идентифицирующих данных, чтобы связать последующие решения политики и результат с тем же запросом. Разобранные имя и аргументы не доказывают безопасность действия. Разбор отвечает на вопрос о том, что было запрошено. Авторизация определяет, может ли запрос быть выполнен в текущем контексте.
Применяйте политику до тела инструмента
DeepSeek Harness документирует каскад tools/pre-execute перед зарегистрированными монотонными защитными проверками. Этап перед выполнением может разрешить, запретить или запросить подтверждение. Зарегистрированные проверки затем сохраняют защищённую идентичность выполнения и могут запретить выполнение или воздержаться от решения. Документированный маршрут запрета пропускает тело инструмента.
Для операций, требующих участия человека или другого уполномоченного лица, принимающего решения, используйте документированный путь ctx.approval. справка об одобрении определяет allowed-once как единственное разрешение. Отклонение, отмена, недоступность лица, предоставляющего ответ, и ответ, не соответствующий требованиям, не открывают доступ. Отсутствие или невозможность получить ответ на запрос об одобрении должны приводить к отклонению вызова, а не к резервному варианту, достигающему того же результата другим способом.
В системе утверждения также различаются идентификаторы аудита, вызовов инструментов и сессий. Сохраняйте это разделение в собственных журналах. Это позволяет показать, кто одобрил конкретное действие, не смешивая запись об одобрении с самим действием.
Ограничивайте воздействие минимально необходимыми правами
Одобрение не заменяет изоляцию. В справке о песочнице указано, что read-only, workspace-write и danger-full-access являются режимами, ограничивающими воздействие на файловую систему. read-only запрещает запись, кроме необходимых приемников. workspace-write разрешает запись в пределах разрешенного рабочего пространства и временной области, определенной поставщиком. danger-full-access обходит ограничение доступа.
Эти режимы не определяют доступ к сети или видимость процессов. Развертывание, которому необходимы эти границы, должно реализовать и проверить их отдельно. В документации также указаны коды принудительного исполнения: full или partial. Если среда выполнения сообщает о частичном применении ограничений, не представляйте это как абсолютную границу. Сузьте запрашиваемую область, явно укажите ограничение или отклоните работу, требующую полной гарантии.
Изменение файловой системы требует дополнительной точки принятия решения. Конвейер связывает fs/write-intent и fs/edit-intent с изменениями tool-fs. Для операции записи или редактирования должны быть определены конкретная цель, документированное обоснование, граница разрешенного рабочего пространства и запись о том, что применимая политика ее одобрила. Обеспечьте различимость операций чтения, редактирования и внешних воздействий в аудиторском журнале.
Выполняйте через контролируемый уровень диспетчеризации.
После того как политика и защитные механизмы перед выполнением разрешают вызов, документированный каскад tools/execute оборачивает диспетчеризацию. В справочном материале тайм-аут, повторные попытки и метрики названы аспектами, сопровождающими диспетчеризацию. Тело инструмента всё равно следует писать так, чтобы оно отслеживало сигнал отмены и корректно завершало собственную работу.
Не превращайте политику повторных попыток в обход разрешений. Повторная попытка может быть целесообразна только в том случае, если уже санкционированное действие можно безопасно повторить и причина сбоя понятна. Отказ, отклоненное одобрение или отсутствие утверждающего лица не являются временной ошибкой выполнения. Сохраняйте этот результат и требуйте нового явного решения для существенно нового запроса.
Нормализуйте результаты и сохраняйте смысл сбоев
Документированный каскад tools/post-execute может принять, заблокировать, заменить результат или добавить контекст. Затем реестр нормализует ошибки конвейера или снимки результатов в результат isError, прежде чем ToolDefinition.finalizeContent применит свой окончательный инвариант, содержащий только содержимое. Наконец, tools/result фиксирует итоговый неизменяемый результат, а соответствующее событие сессии tool/result становится результатом, доступным модели.
Поток результатов поддерживает следующую политику обработки сбоев:
Сохраняйте исходную идентичность вызова и результат применения политики.
Сообщите об отказе как об отказе, без скрытого выполнения.
Сообщайте о сбоях выполнения и обёртки как о сбоях, не преобразуя их в текст об успехе.
Ограничивайте переписывание результатов и дополнительный контекст документированными для них этапами.
Фиксируйте окончательный результат до добавления последующего контекста модели.
В справочнике по инструментам также указано, что схемы, доступные модели, содержат только объявленные имя, описание и параметры. Обратные вызовы выполнения, определения вывода, метаданные тайм-аутов и UI-представления не включаются в запрос к модели. Такое разделение снижает вероятность того, что внутренние механизмы управления станут изменяемой частью интерфейса вызова инструмента.
Контрольный список перед вводом в эксплуатацию
Перед включением пути инструмента в реальной среде проверьте следующее:
Каждый вызов регистрируется до выполнения.
Политика и одобрение оцениваются до выполнения тела инструмента.
Только
allowed-onceоткрывает вызов, требующий одобрения.Отказ, отмена или недоступность утверждающего лица прекращают текущий вызов.
Для разрешений файловой системы используется наименее привилегированный режим, удовлетворяющий задаче.
Сетевые и процессные ограничения оцениваются отдельно от режима песочницы файловой системы.
Частичное применение песочницы явно отображается и не считается полной изоляцией.
Тайм-ауты и повторные попытки сохраняют семантику авторизации.
Окончательный результат достаточно неизменяем для аудита и анализа сбоев.
OdiRouter и указание авторства проекта
В этом руководстве документация DeepSeek Harness используется как сторонний технический источник. Это руководство не означает, что DeepSeek Harness является продуктом OdiRouter, партнёрством, встроенной интеграцией или официально поддерживаемой функцией. Информацию о самом OdiRouter можно найти на https://odirouter.ai/.