|
2 | 2 |
|
3 | 3 | Der Qwen Code Core (`packages/core`) bietet ein robustes System zum Definieren, Registrieren und Ausführen von Tools. Diese Tools erweitern die Fähigkeiten des Modells, sodass es mit der lokalen Umgebung interagieren, Webinhalte abrufen und verschiedene Aktionen jenseits der einfachen Textgenerierung durchführen kann. |
4 | 4 |
|
5 | | -## Core Concepts |
| 5 | +## Kernkonzepte |
6 | 6 |
|
7 | 7 | - **Tool (`tools.ts`)**: Ein Interface und eine Basisklasse (`BaseTool`), die den Vertrag für alle Tools definiert. Jedes Tool muss folgende Eigenschaften haben: |
8 | 8 | - `name`: Ein eindeutiger interner Name (wird in API-Aufrufen an das Modell verwendet). |
9 | 9 | - `displayName`: Ein benutzerfreundlicher Name. |
10 | 10 | - `description`: Eine klare Erklärung dessen, was das Tool tut – diese wird dem Modell zur Verfügung gestellt. |
11 | | - - `parameterSchema`: Ein JSON-Schema, das die Parameter definiert, die das Tool akzeptiert. Dies ist entscheidend, damit das Modell weiß, wie es das Tool korrekt aufrufen kann. |
| 11 | + - `parameterSchema`: Ein JSON-Schema, das die Parameter beschreibt, die das Tool akzeptiert. Dies ist entscheidend dafür, dass das Modell weiß, wie es das Tool korrekt aufrufen kann. |
12 | 12 | - `validateToolParams()`: Eine Methode zur Validierung eingehender Parameter. |
13 | | - - `getDescription()`: Eine Methode, die eine menschenlesbare Beschreibung liefert, was das Tool mit bestimmten Parametern vor der Ausführung tun wird. |
| 13 | + - `getDescription()`: Eine Methode, um eine menschenlesbare Beschreibung dessen bereitzustellen, was das Tool mit bestimmten Parametern tun wird – vor der Ausführung. |
14 | 14 | - `shouldConfirmExecute()`: Eine Methode, um festzustellen, ob eine Bestätigung durch den Benutzer vor der Ausführung erforderlich ist (z. B. bei potenziell destruktiven Operationen). |
15 | 15 | - `execute()`: Die Kernmethode, die die Aktion des Tools ausführt und ein `ToolResult` zurückgibt. |
16 | 16 |
|
17 | 17 | - **`ToolResult` (`tools.ts`)**: Ein Interface, das die Struktur des Ergebnisses einer Toolausführung definiert: |
18 | | - - `llmContent`: Der faktische Inhalt, der in den Verlauf aufgenommen wird, der an das LLM zurückgesendet wird, um Kontext bereitzustellen. Dies kann ein einfacher String oder ein `PartListUnion` (ein Array aus `Part`-Objekten und Strings) für Rich Content sein. |
19 | | - - `returnDisplay`: Ein benutzerfreundlicher String (häufig Markdown) oder ein spezielles Objekt (wie `FileDiff`) zur Anzeige in der CLI. |
| 18 | + - `llmContent`: Der faktische Inhalt, der in den Verlauf aufgenommen wird, der an das LLM zurückgesendet wird, um Kontext zu liefern. Kann ein einfacher String oder ein `PartListUnion` (ein Array aus `Part`-Objekten und Strings) für Rich Content sein. |
| 19 | + - `returnDisplay`: Ein benutzerfreundlicher String (häufig Markdown) oder ein spezielles Objekt (wie `FileDiff`) zur Darstellung in der CLI. |
20 | 20 |
|
21 | | -- **Rich Content zurückgeben**: Tools sind nicht darauf beschränkt, einfachen Text zurückzugeben. Der `llmContent` kann ein `PartListUnion` sein – also ein Array, das sowohl `Part`-Objekte (für Bilder, Audio usw.) als auch `string`s enthalten kann. Dadurch kann eine einzelne Toolausführung mehrere Rich Content-Elemente zurückgeben. |
| 21 | +- **Rückgabe von Rich Content**: Tools sind nicht darauf beschränkt, einfachen Text zurückzugeben. Der `llmContent` kann ein `PartListUnion` sein – also ein Array, das sowohl `Part`-Objekte (für Bilder, Audio usw.) als auch `string`s enthalten kann. Dadurch kann eine einzelne Toolausführung mehrere Rich-Content-Elemente zurückgeben. |
22 | 22 |
|
23 | 23 | - **Tool Registry (`tool-registry.ts`)**: Eine Klasse (`ToolRegistry`), die folgende Aufgaben übernimmt: |
24 | | - - **Tools registrieren**: Hält eine Sammlung aller verfügbaren Built-in-Tools (z. B. `ReadFileTool`, `ShellTool`). |
25 | | - - **Tools entdecken**: Kann auch dynamisch Tools entdecken: |
26 | | - - **Befehlsbasierte Entdeckung**: Wenn `tools.toolDiscoveryCommand` in den Einstellungen konfiguriert ist, wird dieser Befehl ausgeführt. Es wird erwartet, dass er JSON ausgibt, das benutzerdefinierte Tools beschreibt, die dann als `DiscoveredTool`-Instanzen registriert werden. |
27 | | - - **MCP-basierte Entdeckung**: Wenn `mcp.mcpServerCommand` konfiguriert ist, kann die Registry sich mit einem Model Context Protocol (MCP)-Server verbinden, um Tools aufzulisten und zu registrieren (`DiscoveredMCPTool`). |
28 | | - - **Schemas bereitstellen**: Stellt die `FunctionDeclaration`-Schemas aller registrierten Tools für das Modell bereit, damit es weiß, welche Tools verfügbar sind und wie sie verwendet werden. |
29 | | - - **Tools abrufen**: Ermöglicht es dem Core, ein bestimmtes Tool anhand des Namens zur Ausführung abzurufen. |
| 24 | + - **Registrierung von Tools**: Hält eine Sammlung aller verfügbaren Built-in-Tools (z. B. `ListFiles`, `ReadFile`). |
| 25 | + - **Entdecken von Tools**: Kann auch dynamisch Tools entdecken: |
| 26 | + - **Befehlsbasierte Entdeckung**: Wenn `tools.toolDiscoveryCommand` in den Einstellungen konfiguriert ist, wird dieser Befehl ausgeführt. Es wird erwartet, dass er JSON ausgibt, das benutzerdefinierte Tools beschreibt – diese werden dann als `DiscoveredTool`-Instanzen registriert. |
| 27 | + - **MCP-basierte Entdeckung**: Wenn `mcp.mcpServerCommand` konfiguriert ist, kann sich die Registry mit einem Model Context Protocol (MCP)-Server verbinden, um Tools abzurufen und zu registrieren (`DiscoveredMCPTool`). |
| 28 | + - **Bereitstellung von Schemas**: Stellt die `FunctionDeclaration`-Schemas aller registrierten Tools für das Modell bereit, damit es weiß, welche Tools verfügbar sind und wie sie verwendet werden. |
| 29 | + - **Abrufen von Tools**: Ermöglicht es dem Kernsystem, ein bestimmtes Tool anhand seines Namens zur Ausführung abzurufen. |
30 | 30 |
|
31 | | -## Built-in Tools |
| 31 | +## Integrierte Tools |
32 | 32 |
|
33 | | -Der Core enthält eine Sammlung vordefinierter Tools, die sich typischerweise in `packages/core/src/tools/` befinden. Dazu gehören: |
| 33 | +Der Core enthält eine Sammlung vordefinierter Tools, die sich üblicherweise in `packages/core/src/tools/` befinden. Dazu gehören: |
34 | 34 |
|
35 | 35 | - **File System Tools:** |
36 | | - - `LSTool` (`ls.ts`): Listet den Inhalt eines Verzeichnisses auf. |
37 | | - - `ReadFileTool` (`read-file.ts`): Liest den Inhalt einer einzelnen Datei. Akzeptiert einen `absolute_path`-Parameter, der ein absoluter Pfad sein muss. |
38 | | - - `WriteFileTool` (`write-file.ts`): Schreibt Inhalte in eine Datei. |
39 | | - - `GrepTool` (`grep.ts`): Sucht nach Mustern in Dateien. |
40 | | - - `GlobTool` (`glob.ts`): Findet Dateien anhand von Glob-Patterns. |
41 | | - - `EditTool` (`edit.ts`): Führt Änderungen direkt in Dateien durch (oft mit Bestätigungsabfrage). |
42 | | - - `ReadManyFilesTool` (`read-many-files.ts`): Liest und verknüpft Inhalte aus mehreren Dateien oder Glob-Patterns (verwendet vom `@`-Befehl in der CLI). |
| 36 | + - `ListFiles` (`ls.ts`): Listet den Inhalt eines Verzeichnisses auf. |
| 37 | + - `ReadFile` (`read-file.ts`): Liest den Inhalt einer einzelnen Datei. Akzeptiert einen `absolute_path` Parameter, der ein absoluter Pfad sein muss. |
| 38 | + - `WriteFile` (`write-file.ts`): Schreibt Inhalte in eine Datei. |
| 39 | + - `ReadManyFiles` (`read-many-files.ts`): Liest und verknüpft Inhalte aus mehreren Dateien oder Glob-Patterns (verwendet vom `@` Befehl in der CLI). |
| 40 | + - `Grep` (`grep.ts`): Sucht nach Mustern in Dateien. |
| 41 | + - `Glob` (`glob.ts`): Findet Dateien anhand von Glob-Patterns. |
| 42 | + - `Edit` (`edit.ts`): Führt Änderungen direkt in Dateien durch (benötigt oft eine Bestätigung). |
43 | 43 | - **Execution Tools:** |
44 | | - - `ShellTool` (`shell.ts`): Führt beliebige Shell-Befehle aus (erfordert sorgfältige Sandbox-Konfiguration und Nutzerbestätigung). |
| 44 | + - `Shell` (`shell.ts`): Führt beliebige Shell-Befehle aus (erfordert sorgfältiges Sandboxing und Nutzerbestätigung). |
45 | 45 | - **Web Tools:** |
46 | | - - `WebFetchTool` (`web-fetch.ts`): Ruft Inhalte von einer URL ab. |
47 | | - - `WebSearchTool` (`web-search.ts`): Führt eine Websuche durch. |
| 46 | + - `WebFetch` (`web-fetch.ts`): Ruft Inhalte von einer URL ab. |
| 47 | + - `WebSearch` (`web-search.ts`): Führt eine Websuche durch. |
48 | 48 | - **Memory Tools:** |
49 | | - - `MemoryTool` (`memoryTool.ts`): Interagiert mit dem Gedächtnis des KI-Modells. |
| 49 | + - `SaveMemory` (`memoryTool.ts`): Interagiert mit dem Gedächtnis des KI-Modells. |
| 50 | +- **Planning Tools:** |
| 51 | + - `Task` (`task.ts`): Delegiert Aufgaben an spezialisierte Subagenten. |
| 52 | + - `TodoWrite` (`todoWrite.ts`): Erstellt und verwaltet eine strukturierte To-do-Liste. |
| 53 | + - `ExitPlanMode` (`exitPlanMode.ts`): Beendet den Planungsmodus und kehrt zum Normalbetrieb zurück. |
50 | 54 |
|
51 | 55 | Jedes dieser Tools erweitert `BaseTool` und implementiert die erforderlichen Methoden für seine jeweilige Funktionalität. |
52 | 56 |
|
53 | | -## Tool Execution Flow |
| 57 | +## Ablauf der Tool-Ausführung |
54 | 58 |
|
55 | | -1. **Model Request:** Das Modell entscheidet auf Basis des User-Prompts und der bereitgestellten Tool-Schemas, ein Tool zu verwenden, und gibt einen `FunctionCall`-Teil in seiner Response zurück, der den Tool-Namen und die Argumente angibt. |
56 | | -2. **Core empfängt Request:** Das Core parsed diesen `FunctionCall`. |
57 | | -3. **Tool-Abruf:** Es sucht das angeforderte Tool in der `ToolRegistry`. |
58 | | -4. **Parameter-Validierung:** Die `validateToolParams()`-Methode des Tools wird aufgerufen. |
59 | | -5. **Bestätigung (falls nötig):** |
60 | | - - Die `shouldConfirmExecute()`-Methode des Tools wird aufgerufen. |
61 | | - - Falls diese Details zur Bestätigung zurückgibt, kommuniziert das Core dies zurück an die CLI, welche den User dann zur Eingabe auffordert. |
62 | | - - Die Entscheidung des Users (z. B. fortfahren, abbrechen) wird an das Core zurückgesendet. |
63 | | -6. **Ausführung:** Falls validiert und bestätigt (oder keine Bestätigung nötig), ruft das Core die `execute()`-Methode des Tools mit den übergebenen Argumenten und einem `AbortSignal` (für mögliche Abbrüche) auf. |
64 | | -7. **Ergebnisverarbeitung:** Das `ToolResult` aus `execute()` wird vom Core entgegengenommen. |
65 | | -8. **Antwort an das Modell:** Der `llmContent` aus dem `ToolResult` wird als `FunctionResponse` verpackt und an das Modell gesendet, damit es mit der Generierung einer nutzerseitigen Antwort fortfahren kann. |
66 | | -9. **Anzeige für den User:** Das `returnDisplay` aus dem `ToolResult` wird an die CLI gesendet, um dem User anzuzeigen, was das Tool ausgeführt hat. |
| 59 | +1. **Modell-Anfrage:** Das Modell entscheidet auf Basis des Benutzerprompts und der bereitgestellten Tool-Schemas, ein Tool zu verwenden, und gibt einen `FunctionCall`-Teil in seiner Antwort zurück, der den Tool-Namen und die Argumente angibt. |
| 60 | +2. **Core erhält Anfrage:** Der Core parst diesen `FunctionCall`. |
| 61 | +3. **Tool-Abruf:** Er sucht das angeforderte Tool in der `ToolRegistry`. |
| 62 | +4. **Parameter-Validierung:** Die Methode `validateToolParams()` des Tools wird aufgerufen. |
| 63 | +5. **Bestätigung (falls erforderlich):** |
| 64 | + - Die Methode `shouldConfirmExecute()` des Tools wird aufgerufen. |
| 65 | + - Falls diese Details zur Bestätigung zurückgibt, kommuniziert der Core dies an die CLI zurück, welche den Benutzer dann zur Eingabe auffordert. |
| 66 | + - Die Entscheidung des Benutzers (z. B. fortfahren, abbrechen) wird an den Core gesendet. |
| 67 | +6. **Ausführung:** Wenn validiert und bestätigt (oder keine Bestätigung nötig), ruft der Core die Methode `execute()` des Tools mit den übergebenen Argumenten sowie einem `AbortSignal` (für mögliche Abbrüche) auf. |
| 68 | +7. **Ergebnisverarbeitung:** Der `ToolResult` aus `execute()` wird vom Core entgegengenommen. |
| 69 | +8. **Antwort an das Modell:** Der `llmContent` aus dem `ToolResult` wird als `FunctionResponse` verpackt und an das Modell gesendet, damit es seine benutzerseitige Antwort fortsetzen kann. |
| 70 | +9. **Anzeige für den Benutzer:** Der `returnDisplay` aus dem `ToolResult` wird an die CLI gesendet, um dem Benutzer anzuzeigen, was das Tool ausgeführt hat. |
67 | 71 |
|
68 | | -## Erweitern mit Custom Tools |
| 72 | +## Erweitern mit benutzerdefinierten Tools |
69 | 73 |
|
70 | | -Auch wenn die direkte programmatische Registrierung neuer Tools durch Benutzer nicht explizit als primärer Workflow in den bereitgestellten Dateien für typische Endnutzer beschrieben ist, unterstützt die Architektur die Erweiterung durch: |
| 74 | +Auch wenn die direkte programmatische Registrierung neuer Tools durch Benutzer nicht explizit als primärer Workflow in den bereitgestellten Dateien für typische Endbenutzer beschrieben ist, unterstützt die Architektur Erweiterungen über: |
71 | 75 |
|
72 | | -- **Command-basierte Discovery:** Fortgeschrittene Benutzer oder Projektadministratoren können einen `tools.toolDiscoveryCommand` in der `settings.json` definieren. Dieser Befehl sollte bei Ausführung durch den Core ein JSON-Array von `FunctionDeclaration`-Objekten ausgeben. Der Core stellt diese dann als `DiscoveredTool`-Instanzen zur Verfügung. Der entsprechende `tools.toolCallCommand` ist dann dafür verantwortlich, diese Custom Tools tatsächlich auszuführen. |
73 | | -- **MCP Server:** Für komplexere Szenarien können ein oder mehrere MCP-Server eingerichtet und über die `mcpServers`-Einstellung in der `settings.json` konfiguriert werden. Der Core kann dann Tools erkennen und nutzen, die von diesen Servern bereitgestellt werden. Wie bereits erwähnt: Wenn mehrere MCP-Server verwendet werden, werden die Tool-Namen mit dem Server-Alias aus der Konfiguration vorangestellt (z. B. `serverAlias__actualToolName`). |
| 76 | +- **Befehlsbasierte Erkennung:** Fortgeschrittene Benutzer oder Projektadministratoren können einen `tools.toolDiscoveryCommand` in der `settings.json` definieren. Dieser Befehl sollte bei Ausführung durch den Core ein JSON-Array von `FunctionDeclaration`-Objekten ausgeben. Der Core stellt diese dann als `DiscoveredTool`-Instanzen zur Verfügung. Der entsprechende `tools.toolCallCommand` ist dann dafür verantwortlich, diese benutzerdefinierten Tools tatsächlich auszuführen. |
| 77 | +- **MCP Server:** Für komplexere Szenarien können ein oder mehrere MCP-Server eingerichtet und über die Einstellung `mcpServers` in der `settings.json` konfiguriert werden. Der Core kann dann Tools erkennen und nutzen, die von diesen Servern bereitgestellt werden. Wie bereits erwähnt: Wenn Sie mehrere MCP-Server verwenden, werden die Tool-Namen mit dem Servernamen aus Ihrer Konfiguration vorangestellt (z. B. `serverAlias__actualToolName`). |
74 | 78 |
|
75 | 79 | Dieses Tool-System bietet eine flexible und leistungsstarke Möglichkeit, die Fähigkeiten des Modells zu erweitern und macht Qwen Code zu einem vielseitigen Assistenten für eine breite Palette von Aufgaben. |
0 commit comments