DeepSeek Harness vs Claude Code vs Codex vs Muse Code: open-source framework agentów AI w 2026 roku

W sierpniu 2026 roku DeepSeek udostępnił DeepSeek Harness (dsh) w trybie developer preview. Projekt jest open source na licencji MIT i nie jest wyłącznie kolejnym terminalowym agentem do pisania kodu. DeepSeek projektuje go jako agent harness, czyli warstwę, która łączy model z narzędziami, pamięcią sesji, sandboxem, approval policy, subagentami, web search, skills, workflowami i interfejsem użytkownika.^[1][2]

Najbardziej charakterystycznym założeniem projektu jest:

Everything is a plugin.

Modele, tools, skills, sessions, sandboxes, storage, agent loop, scheduling, subagents, a nawet UI są komponowane jako pluginy oparte na frameworku Cordis.^[1][3][11]

To odróżnia DeepSeek Harness od typowego produktu typu:

model
+
zamknięty agent loop
+
ustalony zestaw narzędzi
+
jeden interfejs

W dsh sam agent loop jest elementem wymiennym z konfiguracji.^[3]

Jednocześnie nie należy wyciągać z tego wniosku, że DeepSeek Harness jest dziś bardziej dojrzały od Claude Code, Codex czy Muse Code. Oficjalny plik bezpieczeństwa projektu mówi wprost, że jest to experimental developer-preview software, które nie przeszło audytu bezpieczeństwa i nie powinno być traktowane jako secure ani production-ready.^[6]

Aktualna publiczna wersja pakietu @deepseek-ai/dsh sprawdzona 31 sierpnia to 0.1.1-rc.2.^[10]

Najkrótszy wniosek: DeepSeek Harness jest dziś bardziej interesujący jako otwarta, wymienna infrastruktura do budowania własnych agentów niż jako bezpośredni zamiennik Claude Code lub Codex dla każdego developera. Co więcej, potrafi delegować pracę do prawdziwego Claude Code i Codex jako subagentów, więc może być również warstwą znajdującą się ponad nimi.^[8][9]

Stan informacji: 31 sierpnia 2026 roku.

TL;DR

Pytanie	Zweryfikowana odpowiedź
Co to jest DeepSeek Harness?	Open-source agent harness i środowisko uruchomieniowe agentów
Licencja	MIT
Status	Developer preview
Aktualna wersja npm	0.1.1-rc.2
Czy jest production-ready?	Nie według oficjalnego SAFETY.md
Czy przeszedł security audit?	Projekt mówi, że nie
Główna architektura	Everything is a plugin
Framework pod spodem	Cordis
Czy działa tylko z modelami DeepSeek?	Nie
Inni providerzy	m.in. Anthropic, OpenAI, Bedrock, Vertex, Azure i custom endpoints
Czy można dodać własny model?	Tak, przez adapter/provider
Interfejs	Web UI, headless, SDK i profile runtime
Czy ma subagentów?	Tak
Czy potrafi uruchamiać Claude Code jako subagenta?	Tak
Czy potrafi uruchamiać Codex jako subagenta?	Tak
Czy Codex CLI jest open source?	Tak, Apache-2.0
Czy Claude Code jest open source na podobnych zasadach?	Nie, repo wskazuje Anthropic Commercial Terms
Czy Muse Code jest beta?	Tak
Czy istnieje uczciwy wspólny benchmark tych harnessów?	Nie znaleźliśmy publicznego, harness-identical benchmarku
Największa przewaga DSH	Composability i wymienność praktycznie całego runtime
Największe ryzyko	Niedojrzałość developer preview i szerokie uprawnienia lokalnego agenta

Czym właściwie jest „agent harness”?

Sam model językowy nie jest pełnym agentem.

Model potrafi wygenerować:

tekst
kod
plan
tool call

ale potrzebuje warstwy, która odpowie na pytania:

• jakie narzędzia są dostępne,
• jak wykonywać komendy,
• gdzie agent może pisać,
• kiedy ma zapytać o zgodę,
• gdzie przechowywana jest historia,
• jak wznowić pracę,
• jak delegować zadania,
• jak zarządzać wieloma agentami,
• jak podłączać zewnętrzne modele,
• jak pokazać wszystko użytkownikowi.

DeepSeek opisuje tę zależność jako:

Agent = Model + Harness

^[1]

Harness jest więc częścią systemu, która sprawia, że model może działać w realnym środowisku.

Dlaczego DeepSeek nie zbudował po prostu kolejnego CLI?

DeepSeek Harness posiada CLI, Web UI i tryb headless, ale architektura jest projektowana szerzej niż pojedynczy coding assistant.^[1][3][5]

Główne założenie brzmi:

nie hardcoduj funkcji w agent loop,
tylko montuj je jako wymienne capabilities

W praktyce jako plugin można traktować między innymi:

• model adapter,
• tools,
• filesystem,
• shell,
• sandbox,
• skills,
• web access,
• session persistence,
• compaction,
• subagents,
• jobs,
• scheduling,
• approvals,
• UI.^[1][3]

To przypomina bardziej framework/runtime do konstruowania agentów niż pojedynczego asystenta.

„Everything is a plugin” naprawdę obejmuje agent loop

Oficjalna dokumentacja architektury mówi, że pluginami są nawet:

• model adapter,
• tool registry,
• session log,
• agent loop.^[3]

To ważniejsze niż zwykły marketplace z dodatkami.

W typowym produkcie można doinstalować tool, ale wewnętrzna pętla:

prompt
→ model
→ tool
→ model
→ finish

jest własnością produktu.

W DeepSeek Harness nawet ta pętla jest capability, którą można zastąpić.

Nie ma według dokumentacji „privileged core”, który trzeba patchować w celu dodania zachowania. Rozszerzenie ma zostać zamontowane obok istniejących pluginów.^[3]

Cordis: fundament całej architektury

DeepSeek Harness jest zbudowany na Cordis.^[1][3]

26 sierpnia 2026 autorzy związani z Peking University i DeepSeek-AI opublikowali pracę:

A Programming Paradigm for Spatiotemporal Composability.^[11]

Cordis ma wspierać dwa rodzaje composability:

Temporal composability

Komponent powinien móc zostać usunięty razem ze swoimi efektami ubocznymi.

Spatial composability

Komponent deklaruje zależności i może być aktywowany lub dezaktywowany, gdy otoczenie się zmienia.

W implementacji Cordis oznacza to m.in.:

• effect tracking,
• dependency resolution,
• declarative component loader,
• configuration reconciliation,
• hot module replacement.^[11]

To nie jest tylko marketingowa nazwa warstwy pluginów. Framework ma własną formalizację i 92-stronicową pracę techniczną.

Profile i bundles

Uruchomiony dsh jest drzewem pluginów komponowanym przy starcie.^[3]

Profile

Profil jest nazwaną konfiguracją runtime.

Domyślnie dokumentacja opisuje między innymi:

web
headless

Bundle

Bundle dostarcza zestaw wpisów konfiguracji Cordis i kod, który te wpisy montują.

Każdy profil zaczyna się od dsh-base, który wnosi między innymi:

• model adapters,
• tools,
• persistence,
• sandbox,
• approval policy,
• settings,
• credentials,
• telemetry.^[3]

dsh-web-app dodaje aplikację przeglądarkową.

dsh-headless dodaje one-shot runner bez serwera.

Konfigurację można nadpisywać warstwowo

Warstwy konfiguracji nakładają się kolejno.^[3]

W uproszczeniu:

bundle
↓
profile cordis.patch.yml
↓
home-level cordis.patch.yml
↓
--patch overlay

Aktualne drzewo można sprawdzić:

dsh --profile web --dump-config

^[3]

Dla zespołów budujących własny harness jest to duża różnica względem modyfikowania źródeł produktu.

Web UI: DeepSeek Harness nie jest tylko terminalem

Quick start wygląda następująco:

npx @deepseek-ai/dsh web

^[1][2]

Domyślnie Web UI działa lokalnie pod adresem:

http://127.0.0.1:3080

^[2]

Po uruchomieniu użytkownik:

1. konfiguruje model,
2. wybiera workspace,
3. tworzy session,
4. wydaje zadanie.

Agent może:

• czytać pliki,
• edytować pliki,
• uruchamiać polecenia,
• delegować pracę,
• utrzymywać plan.^[5]

Operacje wymagające approval są zatrzymywane według aktywnej policy.

DeepSeek Harness nie jest przywiązany do DeepSeek API

To jedna z jego najważniejszych cech.

W Settings → Models można skonfigurować nie tylko DeepSeek.^[4]

Oficjalna dokumentacja wymienia katalogowych providerów, takich jak:

• Anthropic,
• OpenAI,

oraz integracje wymagające natywnych credentiali, w tym:

• Amazon Bedrock,
• Google Vertex,
• Azure,
• Codex.^[4]

Można też dodać własny provider:

company gateway
self-hosted server
custom OpenAI-compatible endpoint

^[4]

Czyli:

DeepSeek Harness
≠
DeepSeek-model-only Harness

Własny model można podłączyć przez LLM adapter

Warstwa ctx.llm jest registry adapterów modeli.^[3][4]

Dokumentacja pokazuje wzorzec:

class MyAdapter extends LlmAdapter {
  async *stream(options) {
    // provider implementation
  }
}

Adapter rejestruje provider route i tłumaczy:

Harness request
↔
API konkretnego providera

^[4]

To pozwala budować jeden harness nad kilkoma backendami modeli.

Model można zmienić bez restartu Web UI

W oficjalnym guide ustawienie providerów i modeli działa na kolejne requesty bez restartu serwera.^[4]

Model wybrany w pickerze staje się też domyślnym modelem nowych sesji.

Sesja, która już wykonała request, zachowuje model zapisany w swoim logu.^[4]

To ważne z punktu widzenia reproducibility.

Cztery runtime modes

DeepSeek opisuje cztery główne tryby.^[1]

Standard mode

Pełny coding agent:

• file editing,
• shell,
• file search,
• web search,
• skills,
• planning,
• goals,
• subagents,
• workflows.

Code mode

Ma funkcje Standard mode, ale tools są wystawiane przez Code Mode SDK, dzięki czemu model może połączyć wieloetapowe operacje w jeden program TypeScript.^[1]

Minimal mode

Tylko:

persistent bash
str_replace_editor

DeepSeek wskazuje ten tryb między innymi do benchmarkowania modeli w minimalnym środowisku.^[1]

Creator mode

Służy do:

• inspekcji runtime,
• eksperymentów z pluginami,
• budowania custom presets.^[1]

Append-only session log

Jedną z najmocniejszych koncepcji dsh jest event-sourced session log.

Oficjalna strona mówi:

Everything the model sees is recorded in an append-only session log.^[1]

Log obejmuje między innymi:

• system prompts,
• reasoning,
• tool calls,
• tool results,
• subagent scheduling,
• context injections.^[1][3]

Z tego samego event stream korzystają:

• resume,
• fork,
• search,
• replay,
• transcript,
• persistence.^[1][3]

To jest ważne dla audytu agentów.

Model-visible oznacza logged

Dokumentacja architektury formułuje bardzo mocną zasadę:

Model-visible means logged.

^[3]

Jeżeli coś trafia do requestu modelu, powinno dać się odtworzyć z session log.

To ułatwia analizę:

• dlaczego agent podjął decyzję,
• jaki context dostał,
• który tool result zobaczył,
• kiedy pojawił się subagent report.

W praktyce reproducibility nadal zależy od samego modelu i zewnętrznych systemów, ale log dostarcza znacznie lepszą podstawę do rekonstrukcji runu.

Subagenci są capability, a nie hardcodowaną częścią loopa

ctx.subagents jest registry providerów subagentów.^[8]

Oficjalna dokumentacja wymienia implementacje:

spawn-in-process
fork
ACP
Codex
Claude Code
dsh-sdk

^[8]

To oznacza, że parent agent może delegować zadanie bez wiedzy, w jaki sposób child agent jest fizycznie uruchamiany.

DeepSeek Harness może uruchamiać prawdziwy Codex

To nie jest emulacja API modelu Codex.

Oficjalna nota implementacyjna opisuje provider:

@deepseek-ai/dsh-subagent-codex

który uruchamia prawdziwy produkt Codex jako osobny proces.^[9]

Aktualnie opisana implementacja korzysta z przypiętego:

@openai/[email protected]

i komunikuje się z jego app-server --stdio.^[9]

Każde wywołanie tworzy:

• świeży proces produktu,
• ephemeral thread,
• one-shot task.^[9]

To ważne, bo DeepSeek Harness może być orchestrator nad Codex, a nie tylko konkurencją Codex.

Tak samo może delegować do Claude Code

Drugi first-party provider integruje prawdziwy Claude Code.^[8][9]

Z perspektywy parent agenta interfejs jest podobny:

subagent task
→ provider
→ external coding product
→ final result

DeepSeek projektuje delegację tak, aby produkt zewnętrzny nie stawał się właścicielem całej sesji parenta.

Provider otrzymuje samodzielne zadanie i workspace, ale nie kopiuje pełnej konwersacji parenta.^[9]

To zmienia sens porównania z Claude Code i Codex

Najprostsza narracja:

DeepSeek Harness
VS
Claude Code
VS
Codex

jest niepełna.

Lepszy model:

DeepSeek Harness
├── własny agent
├── własne modele/providers
├── Claude Code jako subagent
└── Codex jako subagent

Oczywiście to nie sprawia automatycznie, że dsh jest lepszy.

Dodaje:

• więcej zależności,
• więcej procesów,
• więcej konfiguracji,
• szerszy threat surface.

Ale pozwala budować własną warstwę orkiestracji ponad produktami różnych vendorów.

Agent Teams są eksperymentalne

Repozytorium zawiera rozwijany mechanizm Agent Teams z:

• durable roster,
• wspólnym task board,
• mailbox,
• child sessions.^[3]

Jednak dokumentacja zaznacza, że to experimental private opt-in coordination seam.^[3]

Nie należy więc opisywać Agent Teams jako stabilnej publicznej funkcji o takim samym statusie jak główny runtime.

To przykład szybkości rozwoju projektu, ale również jego niedojrzałości.

DeepSeek Harness vs Claude Code

Claude Code jest gotowym produktem Anthropic skupionym na coding workflow.

Potrafi między innymi:

• eksplorować codebase,
• edytować pliki,
• uruchamiać komendy,
• wykonywać testy,
• obsługiwać Git,
• korzystać z MCP,
• pracować interaktywnie i programatycznie.^[12]

Główna różnica filozoficzna

Claude Code:

produkt coding agent
z szeroką konfiguracją i rozszerzeniami

DeepSeek Harness:

framework/runtime,
w którym nawet agent loop jest pluginem

Licencja

Repo Claude Code zawiera:

© Anthropic PBC. All rights reserved.
Use is subject to Anthropic's Commercial Terms of Service.

^[12]

DeepSeek Harness:

MIT

^[1][2]

To realna różnica dla zespołów, które chcą forkować lub przebudowywać runtime.

DeepSeek Harness vs OpenAI Codex

Tu trzeba skorygować częsty błąd.

Codex CLI również jest open source.

Repo openai/codex jest licencjonowane na:

Apache-2.0

^[13]

Dlatego nieprawidłowe jest zdanie:

DeepSeek Harness jest open-source alternatywą dla zamkniętego Codex CLI.

Oba projekty udostępniają kod, ale ich zakres jest inny.

Codex

Jest przede wszystkim produktem coding-agentowym z:

• CLI,
• IDE,
• desktop app,
• cloud execution,
• sandboxing,
• approvals,
• managed network policy,
• telemetry i audit controls.^[13]

DeepSeek Harness

Jest bardziej ogólną warstwą składania własnych agentów i capabilities.

Co ciekawe, jego subagent provider może uruchomić Codex jako child product.^[9]

DeepSeek Harness vs Muse Code

Meta wydała Muse Code 5 sierpnia 2026 jako beta terminal coding agent napędzany przez Muse Spark 1.2.^[14]

Muse Code został współtrenowany z modelem pod:

• planning,
• tool use,
• context compaction,
• subagents,
• długie coding tasks.^[14]

Ma również persistent async background agents.

Najważniejsza różnica

Muse Code jest silnie zoptymalizowany jako:

Muse Spark 1.2
+
Muse Code

DeepSeek Harness stawia na:

model swappability
+
capability swappability
+
plugin composition

To dwa różne podejścia.

Jedno optymalizuje model i harness jako parę.

Drugie próbuje maksymalnie rozdzielić model od runtime.

Tabela porównawcza

Cecha	DeepSeek Harness	Claude Code	OpenAI Codex	Muse Code
Główny charakter	agent framework/runtime	coding agent	coding agent/platform	coding agent
Status 31.08.2026	developer preview	produkcyjny produkt	produkcyjny produkt	beta
Kod harnessu	MIT	commercial terms	Apache-2.0	brak podstaw, by traktować CLI jako otwarty framework
Multi-model	Tak, natywnie projektowane	przede wszystkim Claude	przede wszystkim modele OpenAI	Muse Spark
Custom provider	Tak	przez obsługiwane integracje/gatewaye	ekosystem OpenAI	brak porównywalnej warstwy pluginowej opisanej w launchu
Web UI	Tak	głównie terminal/IDE	CLI, IDE, desktop, cloud	terminal
Headless	Tak	Tak	Tak	agent CLI
Plugin-first core	Tak	Nie w takim samym zakresie	Nie w takim samym zakresie	Nie w takim samym zakresie
Wymienny agent loop	Tak	Nie jako główny contract produktu	Nie jako główny contract produktu	Nie jako główny contract produktu
Subagents	Tak	Tak / agentic workflows	Tak	Tak
Potrafi uruchomić Claude Code child	Tak	N/A	Nie jako główny cel	Nie
Potrafi uruchomić Codex child	Tak	Nie jako główny cel	N/A	Nie
Oficjalny security warning „not production-ready”	Tak	Nie	Nie	Beta
Sandbox	Tak, capability	Tak	Tak	Tak

Tabela opisuje powierzchnię produktu, a nie ranking jakości.

Dlaczego nie podajemy benchmarku „DSH vs Claude Code vs Codex”?

Bo nie znaleźliśmy publicznego testu, który spełniałby jednocześnie:

ten sam model
ten sam prompt
ten sam repo
te same tools
ten sam sandbox
te same limity
ten sam czas
ten sam budżet
ten sam grading

Jeśli uruchomimy:

Claude Opus 5 + Claude Code

i porównamy z:

DeepSeek model + DeepSeek Harness

mierzymy jednocześnie:

• model,
• harness,
• system prompt,
• tool design,
• context management,
• policy,
• retry strategy.

Nie da się wtedy uczciwie powiedzieć:

Harness A jest o 7% lepszy.

Jak uczciwie benchmarkować harness?

Najlepiej wykonać dwa poziomy.

Test A: ten sam model

Na przykład:

ten sam model przez API
+
DeepSeek Harness

vs

ten sam model
+
własny minimalny harness

Mierzymy wpływ infrastruktury.

Test B: produkt end-to-end

Claude + Claude Code
OpenAI model + Codex
Muse Spark + Muse Code
wybrany model + DeepSeek Harness

Mierzymy realny produkt.

Metryki

• task completion rate,
• pass@1 na testach projektu,
• koszt,
• wall-clock time,
• tool calls,
• manual interventions,
• regresje,
• liczba zmian poza scope,
• bezpieczeństwo,
• restart recovery.

DeepSeek Harness i bezpieczeństwo: najważniejsza sekcja

Oficjalny SAFETY.md jest bardzo jednoznaczny.^[6]

Projekt:

• wykonuje model-generated code,
• wykonuje commands,
• może ładować third-party plugins,
• może korzystać z network,
• processes,
• credentials,
• files.

Autorzy ostrzegają, że:

• błędny model output,
• bug,
• misconfiguration,
• malicious input,
• untrusted plugin

mogą:

• zmienić lub usunąć pliki,
• ujawnić dane,
• ujawnić credentials,
• uszkodzić hosta.^[6]

Sandbox nie jest gwarancją izolacji

Oficjalna dokumentacja bezpieczeństwa mówi:

Sandboxing, approval prompts, and permission controls can reduce risk, but they do not guarantee isolation or prevent damage.^[6]

To zdanie powinno być czytane przed instalacją community plugins.

DeepSeek zaleca:

• least privilege,
• disposable VM/container,
• backups,
• ograniczenie sekretów,
• review pluginów i komend.^[6]

Nie należy używać dsh jako jedynej warstwy bezpieczeństwa dla nieufnego workloadu.

Local-first nie oznacza „żadne dane nigdy nie wychodzą”

DeepSeek opisuje Harness jako local-first.^[7]

Domyślnie lokalnie przechowywane są między innymi:

• user inputs,
• model outputs,
• session context,
• tool call records,
• attachments,
• file paths,
• runtime logs,
• credentials configuration.^[7]

Ale gdy użytkownik aktywnie konfiguruje:

• external model provider,
• web tool,
• MCP server,
• plugin,
• inną usługę,

dane mogą zostać przesłane do tego providera zgodnie z jego własną polityką.^[7]

To jest bardzo ważne.

local-first harness
≠
local-only AI system

Telemetry: stan jest bardziej zniuansowany niż „off”

W sierpniu repozytorium zmieniło zachowanie telemetry.^[16]

Aktualna dokumentacja implementacyjna wskazuje, że FULL wymaga jawnego ustawienia, a świeże profile nie wykonują pełnego uploadu session log bez aktywnego wyboru. Feedback może uruchomić ograniczoną ścieżkę reporting zależnie od trybu.^[16]

Data Processing Statement mówi również o możliwości raportowania zanonimizowanych informacji konfiguracyjnych i project lists, z możliwością wyłączenia lub zmiany adresu raportowania.^[7]

Dlatego nie będziemy upraszczać tego do:

DeepSeek Harness wysyła wszystko

ani:

DeepSeek Harness nigdy nic nie wysyła

Przed wdrożeniem trzeba sprawdzić aktualną konfigurację konkretnej wersji.

Developer preview oznacza realne compatibility breaks

README ostrzega:

THERE WILL BE COMPATIBILITY-BREAKING CHANGES.

^[2]

To nie jest zwykły disclaimer.

W sierpniu pakiety były publikowane bardzo szybko, a aktualny CLI przeszedł przez serię RC do 0.1.1-rc.2.^[10]

W publicznych GitHub Discussions pojawiły się również zgłoszenia dotyczące między innymi niespójnych npm dist-tags dla plugin packages przy 0.1.1-rc.2.^[15]

To są zgłoszenia społeczności, a nie oficjalny komunikat, że każdy użytkownik ma taki problem.

Jednak wzmacniają oficjalne ostrzeżenie:

nie traktuj developer preview jak stabilnego API.

Czy warto budować własne pluginy już teraz?

Tak, jeśli akceptujesz churn.

Dokumentacja oferuje oficjalne extension points dla:

• własnego toola,
• LLM adaptera,
• settings card,
• capability,
• conversation node,
• storage,
• filesystem,
• sandbox,
• subagent provider.^[3][4]

Dla zespołu R&D to bardzo interesujące.

Dla firmy oczekującej:

API stability na 24 miesiące

obecny etap jest za wczesny.

Dla kogo DeepSeek Harness ma najwięcej sensu?

Agent platform team

Gdy firma chce budować własną wewnętrzną platformę agentów i nie chce związać się z jednym modelem.

AI infrastructure R&D

Gdy badamy:

• nowe agent loops,
• context policies,
• model routing,
• subagent strategies,
• sandbox providers.

Multi-model environments

Gdy potrzebujemy jednego control plane nad:

• DeepSeek,
• Anthropic,
• OpenAI,
• własnym gatewayem,
• self-hosted model.

Agent benchmarking

Minimal mode może być użyteczny, jeśli chcemy ograniczyć tool surface i badać sam model.^[1]

Kiedy lepiej wybrać Claude Code, Codex albo Muse Code?

Claude Code

Jeśli chcesz gotowego, dopracowanego coding agenta i cenisz ekosystem Claude, MCP, hooks i workflow terminalowy.

Codex

Jeśli jesteś w ekosystemie OpenAI i chcesz gotową platformę obejmującą CLI, IDE, desktop i cloud oraz rozbudowane mechanizmy sandbox/policy.^[13]

Muse Code

Jeśli chcesz harness współtrenowany z Muse Spark 1.2, persistent background agents i rozwiązanie zoptymalizowane jako jedna para model + agent.^[14]

DeepSeek Harness

Jeśli głównym celem jest:

budowa własnego harnessa
a nie tylko użycie gotowego agenta

Produkcyjna checklista przed uruchomieniem dsh

Wersja i supply chain

• Przypięto konkretną wersję @deepseek-ai/dsh.
• Sprawdzono, że pakiet pochodzi ze scope @deepseek-ai.
• Zweryfikowano repo deepseek-ai/deepseek-harness.
• Nie instalujemy losowych desktop wrapperów zamiast upstream.
• Pluginy mają przypięte wersje.
• Sprawdzono zgodność wersji pluginów z CLI.

Runtime

• Harness działa w dedykowanym user account.
• Workspace jest minimalny.
• Sekrety poza workspace.
• Backup istnieje.
• Destructive commands wymagają approval.
• Network access jest ograniczony.
• Sandbox jest zweryfikowany testem negatywnym.
• Nie zakładamy, że sandbox jest doskonałą granicą.

Modele

• Wiemy, do którego providera trafia kod.
• Znamy politykę retencji providera.
• Custom gateway ma TLS i auth.
• API keys mają minimalny scope.
• Model routing jest logowany.
• Testujemy przynajmniej dwa modele.

Pluginy

• Każdy third-party plugin przeszedł review.
• Plugin nie dostaje więcej capabilities niż potrzebuje.
• MCP servers są zaufane.
• Skills są przeglądane jak kod.
• Aktualizacja pluginu nie odbywa się bez review.

Agent quality

• Zadania mają acceptance tests.
• Agent uruchamia testy.
• Finalny diff jest reviewowany.
• Mierzymy regresje.
• Mierzymy koszt task completion.
• Długie sesje testujemy po restartach.
• Subagents mają jasne granice.

Werdykt POLPROG

DeepSeek Harness jest jednym z najciekawszych projektów agentowych sierpnia 2026 nie dlatego, że „DeepSeek zrobił własnego Claude Code”.

To byłoby zbyt płytkie.

Najciekawsza jest architektura:

model
jest pluginem

tools
są pluginami

sandbox
jest pluginem

session log
jest pluginem

subagent provider
jest pluginem

agent loop
jest pluginem

UI
jest pluginem

Do tego parent agent może delegować zadania do prawdziwego Codex lub Claude Code.^[8][9]

To zmienia pytanie.

Nie:

Czy DeepSeek Harness zabije Claude Code?

Tylko:

Czy firmy zaczną oddzielać model od harnessa i budować własny control plane nad wieloma agentami?

Taki kierunek ma sens.

Model frontier zmienia się co kilka tygodni. Harness może przeżyć kilka generacji modeli.

DeepSeek próbuje stworzyć warstwę, w której:

model można wymienić
provider można wymienić
sandbox można wymienić
tool można wymienić
agent loop można wymienić
UI można wymienić

To bardzo mocna idea architektoniczna.

Ale na 31 sierpnia 2026 projekt pozostaje developer preview. Oficjalnie nie przeszedł security audit i sam zespół ostrzega, aby nie uznawać go za production-ready.^[6]

Dlatego nasza ocena jest dwuczęściowa:

Do R&D i eksperymentów

Zdecydowanie warto sprawdzić.

Jako bezpośrednia podstawa krytycznej produkcji

Jeszcze nie bez własnego hardeningu, sandboxingu, pinowania wersji, review pluginów i pełnego POC.

Największą zaletą DeepSeek Harness jest dziś nie to, że ma „lepszy model”.

Jego największą zaletą jest to, że próbuje sprawić, aby model przestał być architektonicznym centrum całego agenta.

npx @deepseek-ai/dsh web