Не каталог дополнений, а способ собрать сам рантайм

В привычном приложении плагин обычно означает необязательное расширение: интеграцию с календарём, экспорт отчёта или дополнительную панель. В DeepSeek Harness, или DSH, это понятие заметно шире. Официальная страница относит к заменяемым и перекомпонуемым возможностям модели, инструменты, навыки, сессии, песочницы, хранилища, циклы, планирование и UI. Модульной единицей становится не периферия готового агента, а почти вся среда, в которой он рассуждает, вызывает инструменты и сохраняет историю.

Техническая документация описывает эту модель через Cordis: плагины добавляют сервисы в общий контекст, типизированные события и обратимые эффекты. В контексте DSH предусмотрены адаптер модели ctx.llm, реестр и защищённый конвейер инструментов ctx.tools, сессии ctx.sessions, интерфейс агентов ctx.agents и стандартный цикл исполнения ctx.agentLoop. Отдельные точки расширения есть для конфигурации, учётных данных, телеметрии, песочницы и политик подтверждения действий.

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

  • Плагин в DSH может поставлять capability: конкретную возможность рантайма, например доступ к модели, файлам или shell.
  • Профиль определяет не одного универсального агента, а дерево подключаемых компонентов и конфигурационных слоёв.
  • Модульность работает, когда потребитель зависит от интерфейса сервиса, а не от внутреннего устройства единственной реализации.
Цитата в переводе

«Каждая возможность — это плагин, который можно заменить или перекомпоновать: модели, инструменты, навыки, сессии, песочницы, хранилища, циклы, планирование и UI.»

DeepSeekколлективный автор официальной страницы Harness

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

Документация DSH даёт предметную карту расширений. Новый провайдер модели подключается через ctx.llm; инструмент, доступный модели, регистрируется в ctx.tools; выполнение shell-команд обеспечивает backend-компонент ctx.shell. Для постоянного терминала предусмотрена связка backend для ctx.terminals и терминального инструмента. Правила доступа к файлам можно реализовать через провайдера ctx.fs или событийные точки семейства fs/*.

Эта схема особенно заметна на границе между агентом и инфраструктурой. Команда может отделить логику рассуждения модели от среды запуска subprocess, устройства файловой системы, правил подтверждения аргументов инструмента и места, куда поступает телеметрия. Документация указывает, что замена провайдеров файловой системы и subprocess позволяет перенести Bash, PTY и LSP в удалённую песочницу без отдельных форков всех зависимых провайдеров. Это описание возможностей архитектуры, а не гарантия готовой production-интеграции для каждого окружения.

Полезно различать три роли. Service Definition задаёт интерфейс, Service Provider его реализует, Consumer использует capability. Пока потребитель опирается на контракт, а не на конкретный backend, замена остаётся инженерно оправданной. Для агентных систем это критично: модельный endpoint, поиск, файловый доступ, sandbox и подагенты меняются с разной скоростью и требуют разных подходов к рискам.

  • Модельный backend подключается как адаптер в ctx.llm.
  • Инструменты для модели проходят регистрацию и policy pipeline в ctx.tools.
  • Файлы, shell, терминалы и sandbox выступают самостоятельными инфраструктурными capability.
  • Перехват вызовов и хода агента строится на событиях agent/* и tools/*.
  • Долговечные факты сессии и интерфейс остаются отдельными слоями событий и рендеринга.

Профили превращают архитектуру в разные продукты

DSH запускается как набор профилей, bundles и patch-слоёв, а не как единая неизменяемая конфигурация. Профиль задаёт дерево плагинов, к которому можно добавить внешние модули и пользовательский файл cordis.patch.yml. Документация описывает порядок наложения конфигурационных слоёв и позволяет вывести фактически загружаемое дерево командой dsh --profile web --dump-config.

На официальной странице DeepSeek описаны четыре режима: Standard, Code, Minimal и Creator. Standard рассчитан на обычную работу, Code добавляет среду для инженерных задач, Minimal оставляет небольшой набор возможностей, а Creator предназначен для разработки preset’ов, проверки рантайма и экспериментов с плагинами в памяти. Это не набор интерфейсных тем: режимы показывают, как одна база собирается в агентные контуры с разными полномочиями и уровнем сложности.

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

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

Где действительно может снизиться стоимость разработки

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

Потенциальная выгода возникает при локальной замене capability. Если команда уже провела устойчивую границу между интерфейсом и реализацией, ей не требуется переписывать весь рантайм из-за смены провайдера модели, политики файлового доступа или способа запуска команд. Вместо крупного форка остаётся работа с одним адаптером, профилем или провайдером. Так следует понимать архитектурное обещание DSH о заменяемости.

Цена при этом не исчезает, а переносится в другие области. Вместо сопровождения монолита команда проектирует граф зависимостей, проверяет совместимость плагинов, фиксирует версии, ведёт источники поставки, тестирует конфигурацию профиля целиком и выясняет, какой компонент предоставил конкретный сервис. До первого tagged release разработчики DSH предупреждают о возможных compatibility-breaking changes; формат сессии также пока не обещан как обратно совместимый. Для ранней платформы это разумная позиция, но production-потребителю она требует особенно осторожной стратегии обновлений.

  • Потенциально снижается цена замены отдельного слоя, а не цена всей агентной системы.
  • Растёт значение lockfile, реестра зависимостей и интеграционных тестов.
  • В developer preview обновление может быть архитектурно правильным, но операционно болезненным.

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

Ещё одна причина интереса к DSH связана с управляемостью. Профиль позволяет определить, какие bundles, сервисы и настройки войдут в конкретную сборку, а команда --dump-config помогает увидеть фактическую конфигурацию. Такой подход практичнее абстрактного представления, будто агент умеет всё: владелец системы может создавать разные наборы прав для анализа, разработки, автоматизации workflow и экспериментов.

DSH также заявляет append-only журнал сессии. По описанию DeepSeek, в нём сохраняется то, что видит модель: системные промпты, reasoning, вызовы и результаты инструментов, расписание подагентов и context injection. На едином потоке событий построены resume, fork, поиск и replay. Для расследования сбоев это полезнее разрозненных логов интерфейса и backend: можно связать ответ модели с конкретным tool-call и состоянием сессии. Хранение столь подробной трассы, однако, требует собственной политики доступа и сроков хранения.

Архитектура предусматривает policy seams: точки подключения sandbox, approval policy, события до и после запуска инструмента и guard, который может отклонить вызов. Эти механизмы позволяют встроить контроль в рантайм. Но они не гарантируют, что безопасные ограничения включены, корректно настроены или одинаково реализованы всеми внешними модулями.

  • Контроль состава: утверждённые profiles и явная конфигурация дерева компонентов.
  • Контроль расследования: журнал событий, replay и трассировка вызовов.
  • Контроль действий: allowlist инструментов, проверки аргументов, sandbox и обязательные подтверждения.
  • Контроль данных: отдельная политика доступа к журналам, credentials и артефактам сессии.

Почему «всё — плагин» не означает, что всем будет просто

Наиболее точный контраргумент сформулировал участник сообщества phinn в дискуссии #326: свобода композиции для конечного пользователя оборачивается сложностью конфигурации. Автор упоминает 49 packages, но это его оценка, а не официальная метрика DeepSeek. Практический смысл наблюдения очевиден: пользователю, которому нужен один надёжный помощник для кода, не обязательно разбираться в устройстве profile, bundle и provider.

Официальные режимы Standard и Minimal выглядят попыткой скрыть эту сложность за готовыми пресетами. Одновременно Creator mode, patch-слои и дерево расширений показывают, что основная ценность DSH рассчитана на разработчиков и операторов, способных управлять композицией. Хороший продукт на такой базе должен разделять два опыта: строго курируемую сборку для большинства и контролируемую площадку для тех, кто действительно расширяет систему.

Есть и более конкретное ограничение. В community-дискуссии #903 разработчик сообщил, что stock Web UI выводит пространства настроек из жёстко заданного allowlist: настройки стороннего плагина могут быть зарегистрированы на хосте, но не появиться в интерфейсе. Это не подтверждённый DeepSeek дефект и не обязательство его исправить. Однако пример показывает границу лозунга: компонент может быть модульным на уровне рантайма, но не получить равноправной поддержки во всех пользовательских поверхностях.

  • Готовый профиль должен иметь минимум изменяемых параметров и понятного владельца обновлений.
  • Свободную установку модулей следует отделять от пользовательского режима с предсказуемой поддержкой.
  • Равенство на уровне API не гарантирует равенства в UI, документации и жизненном цикле настройки.
Цитата в переводе

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

phinnавтор GitHub Discussion #326

Плагин с доступом к агенту: часть цепочки поставки

В агентной среде плагин нельзя считать безобидной настройкой. Он способен влиять на инструменты, конфигурацию, сетевое взаимодействие, обработку credentials и вызовы subprocess, если процесс Harness располагает такими полномочиями. Автор discussion #1804 предлагает добавить manifest разрешений, поскольку рассматривает установленный плагин как исполняемый код внутри процесса. Это предложение сообщества, а не реализованная функция DSH и не официальный план DeepSeek.

Внешний эмпирический контекст даёт работа Tencent Zhuque Lab. Исследователи оценивали не безопасность DSH вообще, а одну зафиксированную конфигурацию на commit 47f943859bef от 13 августа 2026 года: с одним модельным backend, одной агентной персоной и без включённого hardening-преобразования. В 14 560 контролируемых запусках rule-based judge зафиксировал 5,6% полных успехов indirect prompt injection, LLM-based judge: 5,3%. При этом simulated sinks не выполняли реальных внешних действий.

Эти цифры нельзя переносить на все версии DSH, модели, наборы tools и production-конфигурации. Но они подтверждают общий инженерный принцип: недоверенный текст из документа, веб-страницы или retrieval-канала может попасть в контекст модели и попытаться повлиять на действие. Критичные операции стоит ограничивать независимо от качества рассуждений модели: отдельными правами, проверкой аргументов, подтверждением человеком и изоляцией среды исполнения.

  • Проверяйте происхождение плагинов и фиксируйте версии так же, как для других зависимостей с исполняемым кодом.
  • Не выдавайте credentials, сеть, shell и запись во внешние API по умолчанию.
  • Разделяйте read-only и write-профили.
  • Тестируйте цепочку «контент → контекст модели → tool-call → внешний эффект» после изменений модели, skills, парсеров и политик.
Цитата в переводе

«Плагин = код с полными полномочиями, исполняемый внутри процесса Harness.»

truelove-dreamerавтор GitHub Discussion #1804

Практический паттерн: начинать с одного контура

Команде, которая хочет применить подход DSH, разумнее начать не с максимальной композиции, а с одного утверждённого профиля под конкретную задачу. Например, агент для внутреннего анализа может иметь read-only доступ к выделенному набору документов, ограниченный поиск и не получать доступа к shell и сетевым действиям. Инженерный профиль допустимо расширить файловыми операциями и терминалом, но только в изолированной среде и с отдельной политикой подтверждения опасных команд. Возможность выстраивать такие границы опирается на capability seams и профили DSH; за конкретную конфигурацию отвечает внедряющая команда.

Следующий шаг: сделать сборку воспроизводимой. Для этого нужны фиксированные версии плагинов, проверяемые источники, журнал изменений profile и регрессионные сценарии для ключевых tool-call. Статус developer preview и предупреждения о ломающих изменениях означают, что обновление следует рассматривать как изменение системы, а не как обычную установку патча. Перед релизом нового набора компонентов полезно повторно проверить права, формат сессий, трассировку и сценарии prompt injection.

Наблюдаемость должна стать операционной функцией. Сессионный журнал и события нужны не только для демонстрации replay: с их помощью разбирают расходы токенов, задержки, неожиданные вызовы инструментов, расхождения между профилями и последствия обновления плагина.

  • Выберите один use case и один профиль.
  • Зафиксируйте набор модулей и источники поставки.
  • Сократите инструменты до необходимых для задачи.
  • Изолируйте filesystem и subprocess там, где это возможно.
  • Ведите трассы сессий, но заранее определите правила хранения чувствительных данных.
  • Проводите регрессию после смены модели, plugins, prompts и policy.

Что это означает на практике

Ценность DSH не стоит измерять числом установленных плагинов. Важнее, можно ли заменить конкретный provider без изменения потребителей его интерфейса и без скрытой поломки рабочих сценариев. Модульная граница полезна только тогда, когда её можно проверить в реальной сборке.

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

Модульность и безопасность остаются разными задачами. Sandbox, approval policy и event hooks создают точки контроля, но не включают безопасную конфигурацию автоматически. Tools, skills и внешние плагины следует рассматривать как элементы цепочки поставки, особенно при доступе к shell, сети, credentials и внешним API.

  • Фиксируйте версии, источники и конфигурацию дерева плагинов.
  • После изменений модели, парсеров, tools и policy повторяйте тесты на indirect prompt injection и опасные действия.
  • Отдельно определяйте права на чтение, запись, сеть, shell и работу с внешними API.

Вывод

Концепция Everything is a Plugin делает DeepSeek Harness интересным не как очередной каталог расширений, а как попытку перенести заменяемость на фундаментальные слои агентного рантайма. При зрелой инженерной дисциплине это позволяет быстрее менять инфраструктурные решения, собирать несколько контуров под разные задачи и лучше расследовать поведение агента.

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

Источники

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

Чек-лист: первый контролируемый профиль DeepSeek Harness

Этот список можно использовать перед внутренним запуском одного агентного контура. Он не заменяет аудит безопасности и не подтверждает защищённость конкретной конфигурации.

Граница сценария

  • Выбран один конкретный use case и назначен владелец профиля.
  • Определено, какие документы, сервисы и результаты доступны агенту.
  • Read-only и write-сценарии разделены на разные профили.

Сборка и обновления

  • Зафиксированы версии плагинов и проверяемые источники поставки.
  • Сохранена конфигурация дерева компонентов и журнал её изменений.
  • Подготовлены регрессионные сценарии для ключевых tool-call перед обновлением модели или плагинов.

Полномочия и наблюдаемость

  • Shell, сеть, credentials и внешние API не выданы по умолчанию.
  • Filesystem и subprocess изолированы там, где это возможно.
  • Определены правила доступа и сроки хранения сессионных журналов.
  • Проверяется цепочка «контент → контекст модели → tool-call → внешний эффект».

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

Что DeepSeek подразумевает под принципом Everything is a Plugin?

В DeepSeek Harness плагинами считаются не только дополнительные инструменты, но и фундаментальные слои рантайма: модели, сессии, sandbox, storage, цикл агента, планирование и UI. Архитектура рассчитана на их подключение и перекомпоновку через сервисы, события и профили.

Можно ли считать DeepSeek Harness готовой production-платформой?

В доступных материалах проект описан как developer preview. До первого tagged release разработчики предупреждают о возможных ломающих изменениях, а формат сессии пока не обещан как обратно совместимый. Production-команде нужны фиксированные версии, регрессионные тесты и контролируемый процесс обновлений.

Снижает ли плагинная архитектура стоимость разработки агентной системы?

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

Почему внешний плагин в DSH нужно рассматривать как риск цепочки поставки?

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

С чего начать внедрение подхода DeepSeek Harness?

Начните с одного use case и одного утверждённого профиля. Ограничьте инструменты необходимым минимумом, разделите read-only и write-доступ, изолируйте filesystem и subprocess, зафиксируйте версии и подготовьте сценарии регрессионного тестирования.