Что известно о Discussion #5003

В публичном обсуждении Discussion #5003 репозитория DeepSeek Harness описана предполагаемая проблема в связке с MCP. По сообщению автора, пакет @deepseek-ai/dsh-mcp-client@0.1.1-rc.2 получает из MCP-соединения список инструментов, но не передаёт модели поле instructions, которое сервер может вернуть на этапе инициализации. Сведения актуальны по материалам, предоставленным для статьи и проверенным 29 августа 2026 года.

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

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

Документация MCP-клиента DeepSeek Harness описывает мост, который делает MCP-tools доступными модели в формате mcp__<serverName>__<tool>. Если общие серверные инструкции не передаются дальше, функции останутся технически доступными, но агент лишится части правил их корректного применения.

  • Подтверждено: публичная Discussion #5003 описывает предполагаемый разрыв между MCP-handshake и контекстом модели.
  • Не подтверждено: затронуты ли все версии DeepSeek Harness и существует ли исправление.
  • Наличие обсуждения не характеризует качество конкретной LLM и не доказывает нарушение спецификации MCP.
Цитата в переводе

«dsh-mcp-client потребляет из MCP-соединения ровно одну вещь: список инструментов.»

CNSeniorious000автор Discussion #5003, публичная должность не указана

MCP handshake: не только список кнопок

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

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

Документация TypeScript SDK рекомендует использовать instructions для связей между инструментами, рабочих шаблонов и ограничений, которые нецелесообразно повторять в описании каждого tool. Это особенно важно, когда отдельные корректные вызовы могут образовать некорректную последовательность.

Например, сервер способен предложить инструменты prepare и execute. Параметры обеих функций понятны по отдельности, но обязательный запуск prepare перед execute должен быть явно доведён до агента. Если это правило находится только в instructions и не попадает в контекст модели, доступность обеих функций не делает сценарий безопасным или корректным.

  • Handshake согласует параметры соединения и возможности сторон.
  • tools/list предоставляет перечень инструментов и их схемы.
  • instructions представляют собой опциональные рекомендации сервера по использованию его возможностей и инструментов.
  • Спецификация допускает добавление instructions в системный промпт, но не требует такого поведения во всех случаях.
Цитата в переводе

«Клиент может добавить эти инструкции в системный промпт.»

Model Context Protocol Specificationспецификация протокола

Инструкция может исчезнуть между сервером и моделью

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

Поэтому успешный handshake не доказывает, что модель увидела всё, что получил клиент. Сервер мог вернуть instructions, транспорт мог без ошибок доставить ответ, а клиент мог успешно загрузить tools/list. Если при сборке model-facing контекста инструкции не добавлены, LLM их не получит. Именно такой сценарий применительно к dsh-mcp-client описан в Discussion #5003.

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

Схема риска выглядит так: initialize передаёт instructions клиенту, tools/list передаёт definitions модели, а ветка instructions в model context может отсутствовать. В таком случае причину нужно искать не только на сервере и не только в поведении модели, но и в связующем слое между протоколом и агентским рантаймом.

  • Успешное подключение не подтверждает полноту модельного контекста.
  • Видимый список tools не равен всем данным, которые влияют на решение агента.
  • Tools, resources, prompts и instructions следует проверять как независимые возможности интеграции.

Почему проблема остаётся тихой и сложной в диагностике

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

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

Одного статуса «MCP OK» недостаточно. Обычно он отвечает лишь на вопрос, доступен ли сервер. Агентской системе требуется отдельная проверка: получил ли LLM необходимый контекст до выбора действия. Нужен и следующий вопрос: последовала ли модель этому правилу. Наличие инструкции в контексте и её соблюдение являются разными проверками.

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

  • Доступность показывает, подключён ли сервер.
  • Целостность контекста показывает, получила ли модель необходимые данные handshake.
  • Поведенческий тест показывает, соблюдает ли агент правило при вызове tools.

Инструкции сервера не равны системной политике агента

Первое очевидное решение состоит в том, чтобы автоматически добавлять instructions из initialize в system prompt. Такой подход обсуждается в Discussion #5003, а спецификация MCP допускает добавление инструкций в системный промпт. Но доставка текста в контекст и присвоение этому тексту наивысшего приоритета остаются разными инженерными решениями.

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

Документация DeepSeek Harness отдельно предупреждает о необходимости валидировать данные, поступающие от внешнего MCP-сервера через сетевую доверительную границу. Это не означает, что server instructions следует игнорировать. Практический вывод другой: происхождение текста, режим доверия и его место в иерархии инструкций должны быть определены явно.

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

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

Как проверить связку до продакшена

Контрактный тест можно подготовить без доступа к рабочей CRM, базе данных или другой чувствительной инфраструктуре. Достаточно тестового MCP-сервера с двумя инструментами: prepare и execute. Правило «сначала вызови prepare» следует разместить только в instructions ответа initialize, не добавляя его в описания инструментов.

Такой сценарий проверяет доставку межинструментного правила, а не способность модели вывести его из карточки функции. Полезно сохранять три артефакта: исходный ответ handshake, итоговое представление контекста для модели и журнал tool calls. Уникальный тестовый маркер в инструкции позволит сопоставить первый и второй артефакты.

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

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

  • Создайте правило, которое нельзя вывести из описаний tools.
  • Сопоставляйте raw-ответ initialize со снимком model-facing контекста.
  • Проверяйте первичное подключение и reconnect.
  • Отдельно фиксируйте вызовы tools, аргументы, результаты и сервер-источник.

Чек-лист: три слоя наблюдаемости

Вместо одного зелёного статуса полезно разделять как минимум три слоя наблюдаемости. Они отвечают на разные вопросы и не могут подменять друг друга.

Transport

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

  • Записывайте события подключения и повторного подключения.
  • Фиксируйте ошибки авторизации, тайм-ауты и время ответа.
  • Проверяйте, как меняется набор доступных инструментов после reconnect.

Целостность контекста

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

  • Сохраняйте raw-ответ initialize.
  • Снимайте фактический контекст, переданный LLM.
  • Сравнивайте наличие тестового маркера в handshake и model-facing контексте.
  • Проверяйте обработку instructions отдельно от tools, resources и prompts.

Поведение агента и контракт владельцев

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

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

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

Что меняет этот кейс для зрелости агентских систем

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

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

Тестовые материалы из репозитория modelcontextprotocol/servers помогают изучить структуру и запуск MCP-серверов. Они не заменяют проверку прикладного сервера и конкретной сборки агента. Разрыв между протокольным ответом и действиями LLM возникает именно в адаптерах, конфигурации и оркестрации.

Главный вывод не в том, что от server instructions следует отказаться. Они полезны для правил, которые описывают работу набора инструментов целиком. Их доставку необходимо сделать наблюдаемой, а влияние управляемым. Агент нельзя считать готовым к продакшену лишь потому, что он умеет перечислять и вызывать functions.

  • Стандартизация сокращает число адаптеров, но не отменяет интеграционного тестирования.
  • Примеры и конфигурация помогают настроить MCP, но не заменяют проверку конкретного контракта.
  • Проверять следует полный маршрут: инструкция, контекст, решение, действие.

Вывод

Discussion #5003 в DeepSeek Harness не даёт оснований заявлять о признанном массовом баге или готовом исправлении. Однако она показывает реальную инженерную проблему: инструмент может быть технически подключён, а правила его применения не попасть туда, где агент принимает решение.

MCP handshake, список tools и системный контекст модели являются разными этапами одного конвейера. Для каждого нужны отдельные логи, контрактные тесты и контроль доверия. Перед продакшеном важен не только вопрос, может ли агент вызвать инструмент, но и вопрос, получил ли он правило, по которому обязан этот инструмент применять.

На этой границе проходит различие между демонстрацией агента и надёжной рабочей интеграцией.

Источники

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

Чек-лист проверки MCP-инструкций перед продакшеном

Сохраняемая версия чек-листа должна быть подготовлена как PDF в downloads/checklist-mcp-instructions.pdf. В DOCX используется штатный список Word, а ссылка на скачивание не вставляется вручную.

Доставка контекста

  • Создайте правило, которое нельзя вывести из описаний tools.
  • Сохраните raw-ответ initialize.
  • Сохраните фактический model-facing контекст.
  • Проверьте наличие уникального тестового маркера в обоих артефактах.

Поведение агента

  • Проверьте порядок вызовов prepare и execute.
  • Зафиксируйте аргументы, результаты и обработку ошибок.
  • Повторите тест после reconnect.
  • Повторите проверку после изменения SDK, конфигурации, модели или прокси.

Доверие и контракт

  • Определите доверенные MCP-серверы.
  • Зафиксируйте, какие instructions критичны для корректной последовательности действий.
  • Определите режим передачи инструкций в контекст модели.
  • Назначьте порядок аудита изменений серверных инструкций.

Вопросы и ответы

Означает ли Discussion #5003, что DeepSeek Harness массово работает с ошибкой?

Нет. Публичное обсуждение описывает предполагаемую проблему для пакета @deepseek-ai/dsh-mcp-client@0.1.1-rc.2. Оно не подтверждает массовый инцидент, перечень затронутых версий или наличие исправления.

Чем instructions отличаются от списка MCP-инструментов?

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

Почему успешное MCP-подключение не гарантирует правильное поведение агента?

Подключение и tools/list подтверждают доступность канала и инструментов, но не доказывают, что instructions попали в model-facing контекст. Даже присутствие инструкции в контексте отдельно проверяется от того, следует ли ей модель.

Как проверить, доходят ли MCP-инструкции до модели?

Создайте тестовый сервер с инструментами prepare и execute, поместите обязательное правило порядка только в instructions ответа initialize и сохраните raw-handshake, снимок контекста LLM и журнал tool calls. Тестовый маркер позволит локализовать разрыв.

Нужно ли автоматически доверять instructions внешнего MCP-сервера?

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