DeepSeek Harness-Capability drei Rollen: Definition / Provider / Consumer
In der offiziellen Dokumentation werden häufig Dienstdefinition, Dienstanbieter und Konsument erwähnt. Zusammen bilden sie die Nahtstelle einer Fähigkeit – also die austauschbare Fähigkeitsschnittstelle.
Dieses Kapitel erklärt, was jeder der drei ist und warum eine Fähigkeit in drei Rollen aufgeteilt wird.
Die vollständige Fähigkeit bildet ihre Nahtstelle; eine einzelne Rolle ist keine Nahtstelle.
Was ist jede der drei Rollen?
Wenn eine Fähigkeit generisch genug ist und austauschbare Provider unterstützen muss (zum Beispiel die Bash-Ausführung), teilt der Harness die Fähigkeit in drei Rollen auf.
| Rolle | Wofür ist es verantwortlich? | Am Beispiel von Bash |
|---|---|---|
| Dienstdefinition Schnittstelle + Typen | Cordis-Dienst sowie die Typen von Request und Result definieren | dsh-shell (registriert als ctx.shell) |
| Dienstanbieter Implementierung | Diese Fähigkeit tatsächlich implementieren, typischerweise ausgerichtet auf eine bestimmte Laufzeitumgebung | dsh-bash-local (lokale Ausführung) |
| Consumer Modellorientierte Tools | Die Fähigkeit als Tool bereitstellen, das Modelle aufrufen können | dsh-tool-bash (Bash-Tool) |
Service Definition deklariert nur „welche Fähigkeiten existieren und wie sie aussehen“, ohne sich darum zu kümmern, wie sie implementiert werden.
Service Provider erbt von der abstrakten Klasse von Definition und implementiert das konkrete Verhalten.
Consumer ist dem Modell zugewandt und verpackt die Fähigkeit in Tool-Schemas, damit das Modell sie aufrufen kann.
Die drei Rollen können im selben Paket untergebracht oder auf verschiedene Pakete aufgeteilt werden.
Es gibt nur ein Kriterium: ob diese Rollen unabhängig voneinander weiterentwickelt oder ersetzt werden müssen.
Die drei Nahtstellen-Rollen mit einem Diagramm verstehen
Alle drei Rollen hängen von Definition ab, während Provider und Consumer nicht voneinander abhängen.
Der gestrichelte Kasten im Diagramm ist die vollständige Fähigkeit, d. h. die Nahtstelle.
Definition steht in der Mitte; sowohl Provider als auch Consumer hängen nur von ihr ab.
Provider erbt die Implementierung von Definition, Consumer hängt überinject: ['shell']von ihr ab.
Es gibt keine Abhängigkeit zwischen Provider und Consumer.
Daher muss beim Austauschen des Providers weder Definition noch Consumer eine einzige Zeile geändert werden.
Am Beispiel von Bash: die drei Rollen von ctx.shell
Die Bash-Ausführung ist die typischste Nahtstelle in dsh; jede der drei Rollen hat ihr eigenes Paket.
Die Service-Definition ist das Paket dsh-shell, registriert als Dienst ctx.shell.
Sie definiert den Request-Typ für BashShellExecRequestund den ErgebnistypShellRunResult。
Der Service-Provider ist dsh-bash-local, der Befehle auf dem lokalen Computer ausführt.
Dieselbe Definition hat andere Provider, wie z. B. dsh-bash-sandbox zur Ausführung in einer Sandbox und dsh-pwsh-local zur Ausführung von PowerShell.
Der Consumer ist dsh-tool-bash, der die Fähigkeit in ein Bash-Tool kapselt, das vom Modell aufgerufen werden kann.
tool-bash deklariert über inject die Abhängigkeit ctx.shell und ruft dann in execute ctx.shell.run(...) auf.
Das offizielle Referenzdokument „Capability Seam and Core Services“ verwendet eine Tabelle, um die Eigentümerschaft der drei Rollen von ctx.shell zu pflegen.
| ctx-Schlüssel | Rolle | Zugehöriges Paket (Definition) | Implementierung (Provider) | Direkter Konsument (Consumer) |
|---|---|---|---|---|
| ctx.shell | seam | shell | bash-local / bash-sandbox / pwsh-local | tool-bash / tool-pwsh / hooks-claude-code / hooks-codex |
Die Konsumenten umfassen außerdem zwei Hook-Bridge-Plugins: hooks-claude-code und hooks-codex.
Wie tool-bash erkennen sie nur die ctx.shell-Schnittstelle und kümmern sich nicht darum, welcher Executor dahintersteckt.
In der Bash-Schnittstelle wird die modellseitige Anfrage ShellExecRequest (workdir, timeoutMs optional) von der vollständig aufgelösten Spezifikation ShellExecSpec (Felder erforderlich) getrennt, die tatsächlich vom Executor verwendet wird.
Die Tool-Schicht ruft ctx.shell.resolve(request) zwischen den beiden auf – dies ist „Explizit ist besser als implizit an Paketgrenzen“.
Warum in drei Rollen aufteilen?
Der erste Vorteil der Aufteilung ist, dass Anbieter austauschbar sind.
Dieselbe Service-Definition kann mehrere Anbieter haben, ausgewählt über cordis.yml.
Beispiel
# Lokale Ausführung
- name: '@deepseek-ai/dsh-bash-local'
# Zum Wechseln der Anbieter ersetzen Sie einfach die obige Zeile.
# Ersetzen Sie sie durch die folgende Zeile, um zum Sandbox-Executor zu wechseln:
# - name: '@deepseek-ai/dsh-bash-sandbox'
Beim Wechseln der Anbieter bleiben sowohl die Service-Definition als auch der Konsument unverändert.
Der zweite Vorteil der Aufteilung ist, dass sich die drei Rollen unabhängig voneinander weiterentwickeln können.
| Rolle | Die Freiheit, sich unabhängig weiterzuentwickeln |
|---|---|
| Dienstdefinition | Sobald Aufrufer beginnen, sich auf ihre Konventionen zu verlassen, ändert sie sich selten. |
| Dienstanbieter | Kann Leistung und Sicherheit unabhängig optimieren |
| Konsument | Kann anpassen, wie die Fähigkeit dem Modell präsentiert wird |
Der dritte Vorteil der Aufteilung ist die Entkopplung von Abhängigkeiten.
Der Dienstanbieter hängt von der Dienstdefinition ab.
Der Konsument hängt von der Dienstdefinition ab.
Dienstanbieter und KonsumentGegenseitig unabhängig。
| Abhängigkeitsbeziehungen | Ob es zutrifft |
|---|---|
| Provider → Definition | Ja |
| Consumer → Definition | Ja |
| Provider → Consumer | nein |
| Consumer → Provider | nein |
Praktische Analyse: Finden Sie die drei Rollen des Seams, den Sie verwenden.
Das offizielle Referenzdokument „Capability Seam and Core Services“ führt eine vollständige Service-Liste.
Wählen Sie einen Seam, mit dem Sie vertraut sind, zum Beispiel ctx.fs oder ctx.llm, und schlüsseln Sie ihn in drei Schritten auf.
Schritt 1: Finden Sie sein Definition-Paket – das ist die Spalte „zugehöriges Paket“ in der Tabelle.
Schritt 2: Finden Sie sein Provider-Paket – das ist die Spalte „Implementierung“ in der Tabelle.
Schritt 3: Finden Sie seinen Consumer – das ist die Spalte „direkter Consumer“ in der Tabelle.
Zum Beispiel ist bei ctx.llm die Definition das llm-Paket, die Implementierung llm-deepseek und llm-pi-ai, der direkte Consumer agent-loop und compaction-basic.
Ein weiteres Beispiel ist ctx.fs: Die Definition ist das fs-Paket, die Implementierungen sind fs-local, fs-sandbox und fs-e2b, und der direkte Consumer ist tool-fs.
Sobald Sie sich an diese Denkweise gewöhnt haben, erkennen Sie auf einen Blick, welche Rolle jeder integrierte Dienst einnimmt.
Zusammenfassung und Selbsttest
Zusammenfassung in einem Satz: Eine Fähigkeit wird in drei Rollen aufgeteilt – Definition (Schnittstelle und Typen), Provider (Implementierung) und Consumer (modellzugewandte Tools) – und zusammen bilden sie die Nahtstelle.
Selbsttestfrage 1: Welchen Paketen entsprechen jeweils die Definition, der Provider und der Consumer der Bash-Fähigkeit?
Selbsttestfrage 2: Welche Pakete können unverändert bleiben, wenn der Provider von Bash ersetzt wird?
Selbsttestfrage 3: Warum heißt es, dass "eine einzelne Rolle keine Nahtstelle ist"?
Weitere Erweiterungen