DeepSeek Harness har fyra körningslägen: Standard, Code, Minimal och Creator. De är inte fyra prestandanivåer, och valet av ett annat läge gör inte den underliggande DeepSeek-modellen i sig smartare eller svagare. I stället ändrar varje läge miljön runt modellen: vilka verktyg den kan använda, hur dessa verktyg orkestreras, hur mycket hjälp harness-systemet ger och om agenten utför arbete, utvärderas eller ändrar själva harness-systemet.
Det enklaste sättet att komma ihåg skillnaden är: Standard är till för att utföra arbetet, Code är till för att orkestrera arbetet, Minimal är till för att mäta modellen och Creator är till för att ändra harness-systemet. Den skillnaden är viktig eftersom agentens prestanda beror på mer än enbart modellvikterna. Verktygsytan, körningsloopen, minnet, behörigheterna, planeringssystemet och andra delar av harness-systemet påverkar allt vad en agent kan åstadkomma.
Om du jämför DeepSeek med en annan beständig agentmiljö visar vår guide till Hermes-pluginer för DeepSeek-agenter samma princip från ett annat håll: genom att ändra agentlagret kan man lägga till syn, minne, åtkomst till privata data och andra funktioner utan att ersätta basmodellen.
Varför behöver DeepSeek Harness fyra olika lägen?
DeepSeek Harness bygger på idén att en agent inte bara är en språkmodell med en kommandorad ansluten. Harness-systemet befinner sig mellan modellen och miljön och avgör vad modellen kan se, vilka verktyg som är tillgängliga, hur åtgärder utförs, hur sessioner registreras och vad som händer över flera steg. DeepSeek sammanfattar detta förhållande som att en agent består av en modell plus ett harness-system.
Det är också därför som DeepSeek Harness fyra körningslägen kan fungera så olika trots att de använder samma underliggande modell. Standard visar hela den vardagliga agentmiljön. Code bevarar dessa funktioner men ändrar hur modellen orkestrerar verktyg. Minimal tar medvetet bort det mesta av stödet från harness-systemet. Creator lägger till möjligheten att inspektera och omforma själva körningsmiljön.
Dessa lägen bör därför inte tolkas som en stege från grundläggande till avancerad nivå. Minimal är inte underläget Standard, och Creator är inte helt enkelt ett kraftfullare Standard-läge. Varje förinställning är optimerad för en annan fråga: Hur bör agenten arbeta? Hur bör den samordna verktyg? Hur stor del av resultatet kommer från själva modellen? Eller hur bör agentmiljön byggas om?
| DeepSeek Harness-läge | Kärnsyfte | Bäst för | Huvudskillnad |
|---|---|---|---|
| Standard | Fullständig vardaglig agentkörning | Kodning, research, arbete med kodförråd och uppgifter i flera steg | Fullständig verktygs- och agentmiljö |
| Code | Programmatisk verktygsorkestrering | Upprepade, villkorade eller flerstegsbaserade verktygsarbetsflöden | Verktyg komponeras genom genererad TypeScript |
| Minimal | Minska hjälp från ramverket | Benchmarktester och modelutvärdering | Endast beständig Bash och en filredigerare |
| Creator | Skapa eller ändra agentförinställningar | Pluginexperiment och anpassade ramverk | Lägger till runtime-inspektion och redigering av förinställningar |
1. Standardläge – Den fullständiga DeepSeek-agentmiljön som standard
Standardläget är den naturliga utgångspunkten när målet helt enkelt är att ge DeepSeek en uppgift och låta det slutföra den. Det innehåller hela kodningsagentmiljön: filredigering, skalåtkomst, fil- och webbsökning, färdigheter, planering, mål, delagenter och arbetsflöden. I stället för att kräva att du manuellt bestämmer varje nästa steg kan modellen inspektera miljön, agera, observera resultatet och fortsätta.
Det skapar den välbekanta agentloopen: inspektera ett kodförråd, sök efter relevanta filer, läs kod, gör en ändring, kör ett kommando, granska ett fel och revidera resultatet. Den viktiga förmågan är inte något enskilt verktyg i listan. Det är förmågan att fortsätta arbeta i miljön när ny information dyker upp. DeepSeeks pluginarkitektur gör dessa funktioner komponerbara i stället för att behandla agenten som ett enda fast program; rapporteringen om lanseringen har beskrivit det som en plugin-komponerbar agentkörmiljö.
För de flesta användare gör det Standardläget till det rätta standardvalet. Om du vill att DeepSeek ska undersöka ett fel, förstå ett kodförråd, implementera en funktion, granska flera filer eller samordna en vanlig kodningsuppgift i flera steg finns det få skäl att medvetet ta bort verktyg innan du vet att de orsakar problem.
Standardläget passar sämre när syftet med sessionen är utvärdering snarare än produktivitet. Om en modell lyckas eftersom sökning, planering, färdigheter, delagenter och andra delar av ramverket kompenserar för dess svagheter, visar slutresultatet hur väl agentsystemet presterade. Det visar inte på ett tydligt sätt hur väl grundmodellen skulle prestera med minimal extern hjälp.
2. Kodläge – Låt DeepSeek omvandla verktygsorkestrering till ett program
Code Mode är det enklaste av de fyra lägena att missförstå. Det betyder inte ”Standard Mode, men endast för kodningsuppgifter”. Enligt DeepSeeks aktuella definition behåller Code Mode alla funktioner i Standard Mode. Förändringen gäller hur verktygen exponeras för modellen: DeepSeek kan använda Code Mode SDK för att kombinera flera operationer i ett TypeScript-program som genereras av modellen.
I en normal agentloop kan en komplex uppgift kräva upprepade utbyten mellan modellen och enskilda verktyg. Agenten söker, tar emot ett resultat, avgör vad som ska läsas, läser det, bearbetar resultatet, anropar ett annat verktyg och fortsätter. Code Mode SDK flyttar en del av detta kontrollflöde till körbar kod, så att modellen kan uttrycka loopar, filtrering, förgreningar och flera beroende verktygsoperationer som ett program i stället för en lång sekvens av isolerade verktygsanrop.
Föreställ dig en uppgift som kräver att hundratals filer genomsöks, att träffar filtreras efter sökväg, att endast ett urval läses, att värden extraheras och att samma kontroll sedan körs mot varje resultat. Standard Mode kan fortfarande utföra det arbetsflödet, men en stor del av orkestreringen sker genom upprepade agentomgångar. Code Mode är attraktivt när själva orkestreringen börjar likna ett litet program.
sök i filer
→ filtrera matchande sökvägar
→ gå igenom resultaten i en loop
→ läs valda filer
→ bearbeta returnerade data
→ kör uppföljande åtgärder
Det viktiga ordet är komplexitet, inte ”kodning”. En enkel redigering blir inte automatiskt bättre bara för att Code Mode kan generera TypeScript runt den. Standard Mode kan vara lättare att följa när bara några få verktyg används. Code Mode blir mer intressant när upprepade åtgärder, strukturerade transformationer, villkorslogik eller bearbetning av verktygsresultat annars skulle skapa många fram- och återvändande modellanrop.
3. Minimal Mode — Ta bort Harness och se mer av modellen
Minimal Mode är inte ett lättviktsalternativ för långsammare datorer eller mindre hemservrar. Det är en avsiktligt begränsad agentmiljö. DeepSeek definierar det för närvarande som en kodningsagent med två verktyg, med beständig bash och str_replace_editor, vilket tar bort den bredare sök-, färdighets-, underagent- och arbetsflödesfunktionalitet som finns i Standard Mode.
Anledningen till den begränsningen är utvärdering. DeepSeek använde själv DeepSeek Harness Minimal Mode för offentliga Code Agent-benchmarktester som rapporterades med V4-Flash. Den användningen gör avsikten mycket tydligare: Minimal är utformat för att minska den omgivande agentinfrastrukturen när forskare vill få en snävare bild av vad modellen kan åstadkomma med en liten, kontrollerad uppsättning verktyg.
Denna skillnad är viktig eftersom moderna agentbenchmarktester kan mäta mer än bara modellen. En stark planerare, bättre kontextsammanställning, sökning i kodförråd, specialiserade färdigheter, policyer för nya försök eller delegering till underagenter kan alla påverka om en uppgift lyckas. Forskning om utvärdering av harnessar hävdar på liknande sätt att kapacitet bör tolkas på nivån för modell- och harnesskonfigurationen i stället för att automatiskt tillskriva hela resultatet enbart modellvikterna.
Det ger Minimal Mode ett helt annat optimeringsmål än Standard. Standard frågar: ”Vilken miljö ger den här agenten bäst chans att slutföra användbart arbete?” Minimal frågar: ”Vad händer när vi tar bort mycket av den miljön och lämnar modellen med en mindre exekveringsyta?”
För vardagligt arbete kan det vara kontraproduktivt att medvetet kasta bort användbara funktioner. Om målet är att åtgärda ett kodförråd så snabbt och tillförlitligt som möjligt löser Minimal Mode vanligtvis fel problem. Dess värde framträder när reproducerbarhet, jämförelser, felsökning eller förståelse av modellens råa beteende är viktigare än maximal uppgiftsgenomförande.
4. Creator Mode — använd DeepSeek Harness för att förändra harnessen
Creator Mode förändrar det objekt du arbetar med. Standard Mode använder främst en agentmiljö; Creator Mode är utformat för att skapa och experimentera med den miljön. Det innehåller funktionerna i Standard Mode och lägger dessutom till inspektion av körmiljön, experiment med plugin-program i minnet och vägledning för att skapa anpassade förinställningar.
Detta följer direkt av arkitekturen under DSH. DeepSeek beskriver modeller, verktyg, färdigheter, sessioner, sandlådor, lagring, loopar, schemaläggning och till och med användargränssnittet som plugin-program som kan väljas, ersättas eller komponeras om. Cordis-kärnan hanterar montering och avmontering av plugin-program samt deras beroenden, vilket innebär att en utökning av DSH inte nödvändigtvis kräver ändringar i en privilegierad monolitisk agentkärna. Det bredare designperspektivet är anledningen till att projektets påstående att ”allt är ett plugin-program” är viktigare än att det finns fyra förinställningar i sig.
Anta att du ville ha en agent särskilt för att hantera en hemmaserver. Dess användbara miljö skulle kunna omfatta skalåtkomst, begränsade filsystembehörigheter, Docker-åtgärder, infrastrukturdocumentation, övervakningsverktyg och några specialiserade färdigheter. Den kombinationen är inte identisk med en generell kodningsagent. Creator Mode är utformat för att experimentera med sådana funktioner och kombinera dem till en återanvändbar agentförinställning.
inspektera aktuell körmiljö
→ lägg till eller testa plugin-program
→ övervaka tjänster och beroenden
→ justera kompositionen
→ spara en specialiserad förinställning
→ starta den miljön igen
Det gör Creator-läget mer specialiserat än Standard-läget, men inte automatiskt bättre för daglig användning. Om du helt enkelt vill att DeepSeek ska ändra tre filer och köra en testsvit tillför runtime-inspektion och skapande av förinställningar inte mycket värde. Creator blir användbart när frågan ändras från ”Kan agenten utföra den här uppgiften?” till ”Vilka funktioner bör den här typen av agent ha?”
Standard kontra Code kontra Minimal kontra Creator: Vad förändras egentligen?
Det största misstaget är att ordna de fyra lägena som en utveckling, exempelvis Minimal → Standard → Code → Creator. Det antyder att varje steg helt enkelt tillför mer kraft. Den faktiska relationen är flerdimensionell: Standard betonar generell körning, Code förändrar orkestreringen, Minimal minskar avsiktligt stödet och Creator exponerar själva harnessen som något som kan konfigureras.
Jämförelsen blir tydligare när lägena utvärderas utifrån samma frågor i stället för antal funktioner. Standard och Code behåller båda den breda agentmiljön, men Code ändrar hur arbete med verktyg i flera steg kan uttryckas. Minimal rör sig avsiktligt i motsatt riktning genom att krympa verktygsutbudet. Creator utgår från Standard och lägger till funktioner för runtime-komposition, snarare än att bara lägga till ännu ett verktyg för vardagsproduktivitet.
| Fråga | Standard | Code | Minimal | Creator |
|---|---|---|---|---|
| Fullständig verktygsuppsättning för vardagsbruk? | Ja | Ja | Nej | Ja |
| Webb-/filsökning och färdigheter? | Ja | Ja | Begränsat / borttaget | Ja |
| Underagenter och arbetsflöden? | Ja | Ja | Nej | Ja |
| Programmatisk orkestrering av flera verktyg? | Agentloop | TypeScript-program | Grundläggande | Agentloop / experimenterande |
| Runtime-inspektion och skapande av förinställningar? | Inte huvudsyftet | Inte huvudsyftet | Nej | Ja |
| Bäst för dagligt agentarbete? | Ja | För komplex orkestrering | Nej | Endast vid uppbyggnad av miljön |
| Bäst för modellbenchmarking? | Nej | Nej | Ja | Nej |
Det är också därför två tester med samma DeepSeek-modell kan ge olika resultat om deras harness-konfigurationer skiljer sig åt. Tidiga analyser av DSH har redan visat hur viktigt det är att dokumentera modell- och harness-konfigurationen i stället för att bara jämföra modellnamn. Verktygsåtkomst, behörigheter, kontextkonstruktion, agentloopar och andra runtime-val kan alla ändra den väg modellen tar genom en uppgift.
Vilket DeepSeek Harness-läge bör du faktiskt använda?
För det mesta vanliga arbetet bör du börja med standardläget. Det ger tillgång till den breda uppsättning funktioner som DSH utformades för att samordna och låter dig upptäcka om en mer specialiserad runtime verkligen behövs. Att börja i minimalläget bara för att det låter enklare kan ta bort exakt de funktioner som gör en agent användbar.
Byt till Code Mode när själva verktygsarbetsflödet har blivit komplext. Upprepade sökningar, loopar över många filer, filtrering av verktygsresultat, strukturerade omvandlingar och villkorade åtgärder är starkare skäl att använda Code Mode än att uppgiften råkar handla om programvaruutveckling.
Använd Minimal Mode när frågan gäller modellen snarare än maximal produktivitet. Det passar bättre för kontrollerade jämförelser, reproduktion av benchmarkresultat, promptexperiment och situationer där du vill veta om framgången beror på modellen eller på ett mer omfattande harness-ramverk runt den.
Använd Creator Mode när du vill ändra agentmiljön. Det är avsett för pluginexperiment, specialiserade förinställningar och utvecklare som betraktar DeepSeek Harness som infrastruktur för att konstruera en ny agent, snarare än att bara använda standardagenten.
| Om ditt mål är... | Använd |
|---|---|
| Åtgärda ett kodförråd, undersök ett problem eller slutför normalt flerfasst arbete | Standard |
| Samordna många beroende eller upprepade verktygsåtgärder | Code |
| Utvärdera modellen med mindre stöd från harness-ramverket | Minimal |
| Bygg en specialiserad agentmiljö eller experimentera med plugin-program | Creator |
Om ditt övergripande mål är att bygga återanvändbara agentfunktioner kring privata data i stället för att ändra själva DSH, förklarar vår guide om AI-agentfunktioner för lokala kunskapsbaser hur funktioner kan paketera återanvändbara arbetsflöden för hämtning, tolkning, belägg och kunskap på ett självhostat system.
Plan Mode är inte ett femte körningsläge i DeepSeek Harness
Det finns en annan DSH-funktion som gör terminologin förvirrande: Plan Mode. Det låter som om det hör hemma bredvid Standard, Code, Minimal och Creator, men DeepSeeks nuvarande arkitektur behandlar det annorlunda. De fyra lägena ovan är körningsförinställningar eller sammansättningar. Plan Mode är ett valfritt planeringstillstånd per agent som ändrar den vägledning som skickas till modellen.
DeepSeeks delsystemdokumentation beskriver uttryckligen Plan Mode som mjuk vägledning. När det är aktivt inkluderas ett promptavsnitt med planeringsrelaterad vägledning i modellförfrågningar. Sandlådeläget och godkännandepolicyn tillämpar begränsningar oberoende av varandra, och agentloopen i sig är inte beroende av Plan Mode.
Det ger de två begreppen olika roller. Standard, Code, Minimal och Creator besvarar frågor om sammansättningen av körmiljön: vilka funktioner som finns och hur agenten arbetar. Plan Mode besvarar en beteendefråga: ska agenten förbli i ett planeringsinriktat samarbetsläge innan exekveringen fortsätter?
Standard / Code / Minimal / Creator
= sammansättning av körmiljö
Plan Mode
= planerings- och vägledningsläge
Om någon frågar om DeepSeek Harness har fyra eller fem lägen är det användbara svaret: DSH levereras för närvarande med fyra primära körlägen, medan Plan Mode är en separat valfri planeringsmekanism och inte ett femte likvärdigt körläge.
De fyra lägena avslöjar vad DeepSeek Harness faktiskt bygger
Det mest intressanta med DSH är inte att det ger användarna fyra knappar att välja mellan. Lägena visar fyra olika lager av agentteknik. Standard fokuserar på exekvering. Code fokuserar på orkestrering. Minimal fokuserar på utvärdering. Creator fokuserar på sammansättning. Tillsammans visar de att DeepSeek betraktar ramverket som en aktiv del av agentens beteende, snarare än som osynligt kitt runt modellen.
Detta är viktigt eftersom förbättringar i agentsystem inte behöver komma enbart från att träna en större modell. Genom att ändra hur verktyg presenteras, hur kontext hanteras, exekveringspolicyer, omförsöksbeteende, färdigheter, minne eller sammansättningen av körmiljön kan man förändra vad samma modell klarar av. Om du är intresserad av att utöka dessa funktioner i stället för att bygga om hela körmiljön är plugin-stacken för DeepSeek och Hermes ytterligare ett exempel på hur det omgivande agentsystemet kan tillföra helt nya funktioner.
Det innebär också att de fyra förinställningarna bör ses som startkonfigurationer snarare än universella lösningar. En benchmarkmiljö behöver mindre hjälp. En produktionsagent kan vilja ha fler verktyg och striktare behörigheter. Ett komplext verktygsarbetsflöde kan dra nytta av programmatisk orkestrering. En specialiserad hemserveragent kan så småningom behöva en egen förinställning.
DeepSeek Harness är fortfarande i utvecklarförhandsversion, och DeepSeek uppger att dess centrala plugin-program och API:er kommer att fortsätta utvecklas. De exakta förinställningarna och gränssnitten kan därför ändras. Men den arkitektoniska skillnaden är redan användbar: när en agent beter sig annorlunda ska du inte bara titta på modellen. Titta på det ramverk som avgör hur modellen kan agera.
Teknik- och AI-hubb
Mer att läsa

Vad är Plex-tillståndet och vilka delar måste bevaras?
Beständig Plex-tillståndsinformation är den information som bevarar serverupplevelsen efter omstarter och återuppbyggnad; media och tillfälliga omkodningsdata har separata funktioner.

Hur hanterar Plex autentisering för lokala och fjärranslutna sessioner?
Plex-autentisering börjar med serverns och kontots identitet, därefter avgör lokala eller fjärranslutna nätverksvägar åtkomligheten och hur säkra anslutningar fungerar.

Varför kan Plex-sökningar bli långsammare när biblioteksdata ökar?
Att biblioteket växer är inte i sig en diagnos. Testa frågeformen, indexen, cachetillståndet, lagringsfördröjningen och skrivaktiviteten innan du skyller på databasens storlek.

