Разбор DeepSeek Harness: 3 архитектурных решения для агентов, которые стоит позаимствовать

Короткий ответ

Взрывной рост DeepSeek Harness (dsh) — 20K+ звёзд за первый час, 28K–31K к концу первого дня — это не маркетинг, а суммарный эффект нескольких контринтуитивных архитектурных решений. Если почитать официальный репозиторий (12 293 коммита, 54 npm-пакета, ~591K строк TypeScript), внимания заслуживает не количество инструментов, а четыре вещи:

• Нет привилегированного ядра: даже сам цикл агента — это плагин; любую возможность можно целиком заменить через конфигурацию.
• Журнал сессии — единственный источник истины: форк, возобновление, сжатие контекста и воспроизведение — бесплатные побочные продукты журнала.
• Агент может пересобрать себя на ходу: самореферентный набор инструментов позволяет работающему агенту описать новый плагин и сразу же отдать его инструменты модели.
• Песочница — это матрица: для Linux / macOS / Windows / облака есть свой бэкенд, а уровень принудительной изоляции сообщается честно.

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

Что на самом деле представляет собой этот «технический отчёт»

Сначала внесём ясность: у DeepSeek Harness сейчас нет единой формальной «статьи» — но обоснование дизайна, исходный код и справочная документация вместе читаются как полноценный архитектурный документ. Этот разбор основан на официальном репозитории и справочной документации (версия 0.1.0-rc.5):

• Репозиторий: https://github.com/deepseek-ai/deepseek-harness
• Справочная документация: https://deepseek-harness.github.io/deepseek-harness/reference/
• Базовый фреймворк: Cordis (https://github.com/cordiverse/cordis), спроектированный вокруг статьи A Programming Paradigm for Spatiotemporal Composability

Каждое решение ниже рассмотрим с двух сторон: почему оно важно и как его позаимствовать.

Решение 1: нет привилегированного ядра — всё является плагином

Это самая чёткая граница между dsh и остальными фреймворками. Большинство агентных фреймворков устроены по схеме «ядро + плагины»: неприкосновенное ядро с циклом агента, расширяемое только через те хуки, которые заранее просверлил вендор.

dsh переворачивает эту схему:

Каждая часть продукта — плагин: адаптер модели, реестр инструментов, журнал сессии и даже сам цикл агента.

В основе лежит встроенный в репозиторий (vendored) плагинный фреймворк Cordis. Это обещание обеспечивают три механизма:

1. Плагин — это обратимый побочный эффект. Регистрация чего угодно (фрагмента промпта, схемы инструмента, адаптера, обработчика событий) — побочный эффект; выгрузка плагина автоматически его отменяет; перезагрузка / HMR чисто повторяет всё в порядке объявления. Никакого остаточного состояния в духе «установил и не могу удалить».
2. Зависимости объявляются, а не оркестрируются. Плагин объявляет нужные ему сервисы через inject (ctx.tools, ctx.llm, ctx.sessions…), а фреймворк сам вычисляет порядок загрузки по зависимостям. Вы никогда не импортируете конкретную реализацию — вы ищете сервис по ключу. Поэтому любой сервис можно целиком заменить через конфигурацию.
3. У событий четыре режима диспетчеризации: emit (наблюдение), waterfall (оборачивающий middleware, который обязан делегировать дальше через next()), parallel (веерная рассылка) и serial (по порядку). Перехват, подтверждение и переписывание — всё это «повесить waterfall-обработчик», без правок в самом цикле.

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

Решение 2: журнал сессии — единственный источник истины

Это самый радикальный ход dsh — и настоящий источник заявлений о том, что он «экономит токены».

Он возводит одну фразу в ранг инварианта времени выполнения:

Всё, что попадает в запрос к модели, должно восстанавливаться из журнала.

Конкретно: журнал сессии (журнал SessionEvent) — единственный источник истины. Всё, что видит модель, — сообщения пользователя, чанки ассистента, вызовы инструментов и их результаты, внедрённый контекст — это события в журнале, работающем только на дозапись; deriveMessages() проецирует историю для модели из журнала, а сырые события assistant/chunk гарантируют точность воспроизведения и отображения в UI.

Каскадный выигрыш достаётся практически даром:

Опирается всё это на хранилище spill: слишком большой вывод инструментов пишется на диск, а модель получает только указатель на него, так что контекст больше не раздувается огромными текстовыми блоками.

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

Решение 3: три роли заменяемого компонента — интерфейс, реализация и потребитель

Заменяемость в dsh — это не просто «плагинная система»: она опирается на конкретный набор абстракций — три роли: интерфейс, реализация, потребитель (Service Definition / Provider / Consumer).

Самый наглядный пример — песочница. Песочница процессов — это seam, то есть интерфейс, позволяющий заменить реализацию отдельной возможности (ctx.sandbox), а бэкенд выбирается под платформу:

Ключевая мысль: файловая система и запуск процессов используют одну и ту же абстракцию провайдера. Поэтому, если направить fs / subprocess на E2B, Bash, PTY и LSP целиком переезжают в удалённую песочницу — без платформенных развилок под каждую возможность. В этом и сила заменяемого компонента (seam): меняете одного провайдера — и вся цепочка исполнения следует за ним.

В песочнице заложена и инженерная позиция, которую стоит отметить отдельно: уровень принудительной изоляции сообщается честно. Различаются full и partial (старый ABI Landlock, Windows ACL Everyone и граничные случаи с жёсткими ссылками считаются partial), и прямо ожидается, что «потребители, требующие абсолютных гарантий, откажутся от partial». Безопасность здесь не имитируют — так и должна вести себя зрелая система.

Взгляд разработчика: для обычных пользователей seam означает низкую стоимость миграции. Перевести dsh с локальной песочницы на облачную E2B или бэкенд модели с официального API на другой OpenAI-совместимый эндпоинт — это правка одной строки в конфигурации. Для тех, кто строит собственную агентную платформу, эти три роли — готовый паттерн проектирования, который можно забрать напрямую: сначала определите интерфейс возможности, сделайте провайдеров подключаемыми, а потребители пусть зависят от интерфейса, а не от реализации.

Самое дерзкое: агент может пересобрать себя

В dsh входит набор самореферентных инструментов: cordis_define / cordis_run / cordis_stop / cordis_undefine / cordis_inspect_*.

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

Это не игрушка. За набором инструментов стоят vm-песочница dsh-cordis-host-runner и реестр определений; запущенный пакет может даже регистрировать дополнительные видимые модели инструменты, пока его не остановят, не удалят определение или не перезапустится процесс. По умолчанию этот набор намеренно не входит ни в одно релизное дерево (включается только явно — ведь код динамического пакета попадает в живой рантайм), но сам механизм образует замкнутый цикл:

использовать фреймворк → определить новый компонент внутри него → изменить свой набор инструментов → продолжить работу

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

Инженерная культура: почему проекту можно доверять

Помимо архитектуры, сам репозиторий говорит об инженерной культуре, на которую стоит обратить внимание:

• Культура постмортемов: в репозитории четыре формальных разбора инцидентов. Самый известный: когда все 178 тестов, работающих без ключа, были зелёными, реальная сессия ACP-клиента упала вживую — после этого команда построила отдельный e2e CI на реальном API с секретами (настоящие вызовы модели, настоящий bash, многоходовые диалоги, возобновление сессий на продакшен-API DeepSeek) и записала в документацию по тестам: «тесты без ключа доказывают работоспособность конвейера, а не продукта».
• Реестр инвариантов времени выполнения: ctx.invariants — каждый пакет рабочего пространства обязан поставлять сопутствующий плагин ./invariant; если проверок нет, нужно написать комментарий с объяснением почему, а verify-package-invariants механически отклоняет пустые установщики.
• Генерируемая документация + механическая проверка: каталог API Cordis и каталог схем инструментов генерируются скриптами из исходников и побайтно сверяются в CI, так что документация не может разойтись с кодом.
• Агенты строят агентов: 1 386 агентских заметок (.agents/notes) и git-ветки, в основном названные codex/…, agent/…, worktree/…, — этот фреймворк в значительной мере написан ИИ-агентами для кода, и та же агентная машинерия, в свою очередь, обеспечивает их ежедневную работу. Догфудинг, замкнувшийся в полный круг.

Взгляд разработчика: в open source «отношение к делу» само по себе сигнал надёжности. Четыре постмортема, побайтно проверяемая генерируемая документация и реестр инвариантов, механически отклоняющий пустые проверки, — всё это конкретные свидетельства того, что проект будут поддерживать долго.

Проверка реальностью: направление настоящее, версия — предварительная

Несколько ограничений, о которых стоит знать:

1. Это явно developer preview — официальная позиция: ломающие изменения будут. Если взять его сегодня как продакшен-зависимость, закладывайте время на погоню за версиями.
2. Каждый релиз — это подъём версии в 222 файлах: механическая суета от того, что 54 пакета выходят синхронно.
3. Cordis встроен в репозиторий (vendored), а не разработан самим dsh — доверие к Cordis должно быть частью вашей технической оценки.
4. Матрица песочниц сильная, но уровни изоляции partial действительно существуют — проверяйте полноту изоляции для своей платформы в каждом конкретном случае.
5. «Убийца Claude Code» — это медийный нарратив; называть превью rc.5 «заменой» преждевременно, но архитектурное направление настоящее.

FAQ

Есть ли у DeepSeek Harness официальная статья / технический отчёт?

Единой формальной «статьи» сегодня нет. Обоснование дизайна — это статья о Cordis A Programming Paradigm for Spatiotemporal Composability, а собственный архитектурный документ dsh — это, по сути, исходный код + справочная документация. Этот пост — прочтение такого неявного технического отчёта.

Какое из трёх решений стоит позаимствовать в первую очередь?

Если вы строите собственную агентную платформу: три роли заменяемого компонента (seam) — самый прямой вариант: сначала определите интерфейсы возможностей, сделайте провайдеров подключаемыми. Если вам нужна более надёжная агентная система: больше всего окупается журнал как единственный источник истины — восстанавливайте состояние сессии из журнала, и форк / возобновление / аудит достанутся бесплатно.

Какую конкретную пользу эти решения дают обычным пользователям?

Объяснимость (воспроизведите журнал и посмотрите, что делал агент), возобновляемость (форк / продолжение любой сессии), контроль затрат (выгрузка на диск через spill + дешёвые модели) и низкая стоимость миграции (смена провайдера — это правка конфигурации). Чтобы попробовать недорого, подключите DeepSeek V4 одним ключом.

Когда стоит всерьёз следить за dsh?

Если вам нужна глубокая кастомизация агента, вы исследуете агентные архитектуры или хотите «дёшево запускать агентов в больших масштабах», следить можно уже сейчас — при условии, что вас устраивает нестабильность developer preview. Прежде чем погружаться, прочитайте Что такое DeepSeek Harness.

Чтобы проверить эту архитектуру на практике, запустив агента на DeepSeek V4 с минимальными затратами, получите ключ в TeamoRouter и укажите его адрес в DEEPSEEK_BASE_URL. Чтобы увидеть фреймворк в реальном мультиагентном сценарии, переходите к статье Мультиагентная совместная работа на DeepSeek Harness (на китайском языке).