Add OpenCode TensorX experiment adapter
This commit is contained in:
Christoph Schwörer
@@ -1,8 +1,8 @@
|
||||
---
|
||||
name: run-experiment
|
||||
description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf mit Claude Code, Codex CLI oder dem Python-API-Adapter (GLM/Qwen/Kimi) aus und schreibt ein Messprotokoll mit Start-/Endzeit, Modell, Tokenverbrauch und weiteren Metriken. Verwenden bei "/run-experiment <Pfad-zur-Prompt-Datei>" oder wenn der User einen Versuch/ein Experiment ausführen und tracken will.
|
||||
description: Führt einen Versuchs-Prompt aus einer Prompt-Datei als messbaren Headless-Lauf mit Claude Code, Codex CLI oder OpenCode über TensorX aus und schreibt ein Messprotokoll mit Start-/Endzeit, Modell, Tokenverbrauch und weiteren Metriken. Verwenden bei "/run-experiment <Pfad-zur-Prompt-Datei>" oder wenn der User einen Versuch/ein Experiment ausführen und tracken will.
|
||||
argument-hint: <Pfad zur Prompt-Datei> <Root-Verzeichnis>
|
||||
version: 9.3.0
|
||||
version: 10.0.2
|
||||
---
|
||||
|
||||
# RunExperiment – Versuchslauf mit Messprotokoll
|
||||
@@ -101,7 +101,8 @@ Der Skill ist zweigeteilt:
|
||||
- **`## Prozess`** beschreibt werkzeugneutral, **was** je Lauf zu tun und zu erheben ist. Dieser
|
||||
Teil gilt unabhängig davon, mit welchem LLM oder welcher CLI gearbeitet wird.
|
||||
- **`## Werkzeugadapter`** beschreibt **wie** das mit einem konkreten Werkzeug umgesetzt wird.
|
||||
Ausgearbeitet sind Adapter für Claude Code, Codex CLI und den Python-API-Adapter (GLM/Qwen/Kimi). Konkrete Flags und Rohfelder sind
|
||||
Ausgearbeitet sind Adapter für Claude Code, Codex CLI und OpenCode über TensorX. Der frühere
|
||||
direkte Python-API-Adapter bleibt nur als ausdrücklich gewählter Legacy-Fallback erhalten. Konkrete Flags und Rohfelder sind
|
||||
ausschließlich dem gewählten Adapterabschnitt zu entnehmen.
|
||||
|
||||
**Arbeitsteilung mit der Prompt-Datei:** Der Prompt enthält ausschließlich die *Analyseanweisung*
|
||||
@@ -125,7 +126,7 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
||||
2. Aus dem Metadaten-Block der Prompt-Datei (falls vorhanden) Versuch/Prompt-Version übernehmen.
|
||||
3. **Werkzeugadapter bestimmen und CLI-Pfad auflösen.** Die Modell-ID entscheidet eindeutig:
|
||||
`claude-*` verwendet Claude Code, OpenAI-IDs wie `gpt-*` oder `o*` verwenden Codex CLI,
|
||||
`z-ai/*`, `qwen/*` und `moonshotai/*` verwenden den Python-API-Adapter über den TensorX-Gateway.
|
||||
`z-ai/*`, `qwen/*` und `moonshotai/*` verwenden OpenCode über den TensorX-Gateway.
|
||||
Keine Modell-ID an eine CLI übergeben, die sie nicht unterstützt.
|
||||
|
||||
Unter Windows liegt `claude` in der Regel **nicht im PATH**. Erst
|
||||
@@ -143,6 +144,12 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
||||
`$env:USERPROFILE\.vscode\extensions\openai.chatgpt-*-win32-x64\bin\windows-x86_64\codex.exe`
|
||||
wählen. Findet sich die benötigte ausführbare Datei nicht: abbrechen und den User informieren.
|
||||
Adapter und aufgelösten Pfad fürs Protokoll festhalten.
|
||||
|
||||
Für TensorX-Modelle `Get-Command opencode -ErrorAction SilentlyContinue` versuchen. Der
|
||||
Adapter löst zusätzlich die globale npm-Installation unter
|
||||
`$env:APPDATA\npm\node_modules\opencode-ai\bin\opencode.exe` auf. Fehlt OpenCode, mit
|
||||
`npm install -g opencode-ai` installieren; fehlt die TensorX-Anmeldung, `opencode auth login`
|
||||
ausführen. Niemals dafür Cline-Konfigurationsdateien oder Cline-Credentials lesen.
|
||||
4. **Modell beim User erfragen.** Hat der User das Modell nicht bereits im Aufruf genannt,
|
||||
**immer** per `AskUserQuestion` nachfragen – auch dann, wenn frühere Läufe derselben
|
||||
Versuchsreihe ein bestimmtes Modell verwendet haben. Es gibt bewusst keinen Default.
|
||||
@@ -288,7 +295,7 @@ per stdin übergebenen Text angehängt (siehe Schritt „Prompt zusammenstellen"
|
||||
Sort-Object { [int]($_.Name -replace '\D','') }
|
||||
$iteration = if ($iterationen) { $iterationen[-1].Name } else { 'Iteration 1' }
|
||||
$zelle = Join-Path (Join-Path (Join-Path $iteration $modell) $modus) $effort
|
||||
$skillVer = 'v9.3.0' # entspricht version: im Frontmatter dieses Skills
|
||||
$skillVer = 'v10.0.2' # entspricht version: im Frontmatter dieses Skills
|
||||
do {
|
||||
$id4 = '{0:x4}' -f (Get-Random -Maximum 65536)
|
||||
$lauf = Join-Path "<promptverzeichnis>\$zelle" "<NN>_Lauf_$(Get-Date -Format 'yyyy-MM-dd_HHmmss')_${skillVer}-$id4"
|
||||
@@ -441,8 +448,8 @@ und unter `content` den vollständigen Dateiinhalt. `summary` enthält nur eine
|
||||
### 3. Ausführung (Headless-Lauf)
|
||||
|
||||
Den Adapter anhand der Modell-ID wählen. Der folgende Aufruf ist **ausschließlich der
|
||||
Claude-Code-Adapter**. Der Codex-Aufruf steht vollständig unter `Adapter: Codex CLI` und darf
|
||||
nicht mit Claude-Flags vermischt werden.
|
||||
Claude-Code-Adapter**. Der Codex-Aufruf steht vollständig unter `Adapter: Codex CLI`, der
|
||||
TensorX-Aufruf unter `Adapter: OpenCode`; beide dürfen nicht mit Claude-Flags vermischt werden.
|
||||
|
||||
Den kombinierten Prompt per stdin an `claude -p` übergeben. `--add-dir` gibt dem
|
||||
Headless-Lauf Schreibrecht auf das Laufverzeichnis außerhalb seines Arbeitsverzeichnisses.
|
||||
@@ -602,7 +609,9 @@ Regeln:
|
||||
|
||||
`RawResult.json` im Laufverzeichnis lesen und defensiv parsen. Beim Claude-Adapter ist dies die
|
||||
unveränderte CLI-Antwort; beim Codex-Adapter erzeugt `normalise-codex-result.py` diese Datei aus
|
||||
`RawEvents.jsonl` und `_meta\final_response.json`. Relevante Claude-Felder:
|
||||
`RawEvents.jsonl` und `_meta\final_response.json`; beim OpenCode-Adapter erzeugt
|
||||
`opencode-tensorx-adapter.py` sie aus dem Sessionexport und `OpenCodeEvents.jsonl` gemäß der
|
||||
TensorX-Referenz. Relevante Claude-Felder:
|
||||
|
||||
| Feld | Bedeutung |
|
||||
|---|---|
|
||||
@@ -1082,9 +1091,30 @@ die angeforderte ID; da `codex exec --json` sie im Ereignisstrom nicht wiederhol
|
||||
Modellkontrolle im Protokoll `nicht prüfbar`. Temperatur und weitere Sampling-Parameter sind in
|
||||
diesem CLI-Ablauf nicht steuerbar; Effort und Service-Tier werden dagegen explizit festgelegt.
|
||||
|
||||
### Adapter: Python API / GLM-, Qwen- und Kimi-Modelle über TensorX
|
||||
### Adapter: OpenCode / GLM-, Qwen- und Kimi-Modelle über TensorX
|
||||
|
||||
Dieser Adapter wurde für Modelle entwickelt, die über den **TensorX API-Gateway**
|
||||
Dies ist der **primäre Adapter für alle TensorX-Modell-IDs**. Er verwendet OpenCodes
|
||||
OpenAI-kompatiblen Custom Provider und das Skript `opencode-tensorx-adapter.py`. OpenCode
|
||||
verwaltet Authentifizierung, Agenten-Loop und Session; der Wrapper erzeugt eine isolierte
|
||||
Konfiguration, streamt die Rohereignisse, erzwingt Berechtigungen und normalisiert das Ergebnis
|
||||
nach `RawResult.json`. Es besteht keine Abhängigkeit zu Cline.
|
||||
|
||||
Vor jedem TensorX-Lauf die vollständige Referenz
|
||||
[`references/opencode-tensorx.md`](references/opencode-tensorx.md) lesen und deren Aufruf,
|
||||
Timeouts, Artefakte und Pflichtprüfungen anwenden. Die Provider- und Modellvorlage liegt in
|
||||
`opencode-tensorx.json`; API-Keys gehören ausschließlich in OpenCodes Credential-Store.
|
||||
|
||||
Referenzstand bei Einführung: **OpenCode 1.18.25**. Ein Live-Smoke-Test mit
|
||||
`qwen/qwen3.8-flash-next`, Variante `low`, bestätigte Headless-Ausführung, Sessionexport,
|
||||
Reasoning-/Cache-Metriken und die erwartete Textantwort.
|
||||
|
||||
### Legacy-Adapter: direkte Python API / GLM-, Qwen- und Kimi-Modelle über TensorX
|
||||
|
||||
Dieser frühere Adapter darf nur verwendet werden, wenn der User ihn ausdrücklich verlangt oder
|
||||
OpenCode nach dokumentierter Diagnose technisch nicht einsetzbar ist. Die Abweichung ist im
|
||||
Messprotokoll festzuhalten; Läufe beider Adapter sind verschiedene Versuchsbedingungen.
|
||||
|
||||
Der Legacy-Adapter wurde für Modelle entwickelt, die über den **TensorX API-Gateway**
|
||||
(`https://api.tensorx.ai/v1`) erreichbar sind. Er nutzt das Skript `glm-kimi-adapter.py`,
|
||||
das einen minimalen Agent-Loop mit Tool-Calling direkt gegen die OpenAI-kompatible
|
||||
REST-API implementiert. Referenzstand bei Einführung: **Python 3.13, requests 2.34**.
|
||||
@@ -1283,6 +1313,9 @@ der Historie unten – im selben Arbeitsschritt.
|
||||
|
||||
| Version | Änderung | Grund | Verwendet in |
|
||||
|---|---|---|---|
|
||||
| **10.0.2** | Ergebnis-Allowlist zusätzlich relativ zur per Git ermittelten Worktree-Wurzel; Adapter-Version 1.0.2. | Der erste Fix deckte den aktiven Root und den kanonischen Pfad ab. OpenCode 1.18.25 matcht ein Ziel innerhalb desselben Repositories jedoch gegen den Pfad relativ zur Worktree-Wurzel. PATCH: weitere Normalisierungsform desselben bereits autorisierten Zielverzeichnisses. | ab dem ersten OpenCode-V2-Lauf |
|
||||
| **10.0.1** | Der OpenCode-Adapter autorisiert Ergebnisziele zusätzlich mit einem zum aktiven Root relativen Pfad, einschließlich notwendiger `..`-Segmente; Adapter-Version 1.0.1. Regressionstest für Root und Laufverzeichnis in verschiedenen Unterordnern desselben Windows-Git-Worktrees. | OpenCode normalisiert solche Ziele intern worktree-relativ. Die alleinige kanonische Allow-Regel griff daher nicht, obwohl der absolute Werkzeugpfad exakt im erlaubten Ergebnisordner lag. Ein Custom/max-Preflight startete den vorgesehenen Subagenten erfolgreich, konnte anschließend aber keine Ergebnisdatei schreiben. PATCH: korrigiert nur die beabsichtigte Schreibfreigabe. | ab dem ersten OpenCode-V2-Lauf |
|
||||
| **10.0.0** | **OpenCode wird primärer TensorX-Adapter.** Neue keyfreie Provider-/Modellvorlage `opencode-tensorx.json`, Wrapper `opencode-tensorx-adapter.py`, Unit-Tests und Detailreferenz. Der Wrapper startet `opencode run --pure` mit einer isolierten Laufkonfiguration, streamt JSONL und stderr, exportiert die Session, normalisiert Token-, Tool- und Subagentenmetriken und beendet bei Inaktivität oder Benutzerabbruch den Prozessbaum. `solo`, `builtin` und aus `03_Agents.json` übersetztes `custom` werden unterstützt. Der direkte Python-Adapter bleibt als ausdrücklich gewählter Legacy-Fallback erhalten. | Der direkte Adapter hing bei `qwen/qwen3.8-flash-next` in einem nicht gestreamten HTTP-Aufruf ohne lokalisierbaren Fortschritt. OpenCode liefert inkrementelle Ereignisse, eine persistierte Session und einen klaren Prozesslebenszyklus; außerdem entfällt die Kopplung der TensorX-Authentifizierung an Cline. MAJOR, weil Agentenlaufzeit, Werkzeugsemantik und Metrikquelle eine neue Versuchsbedingung bilden. Live-Smoke-Test am 31.08.2026 mit Qwen/low: Exitcode 0, erwartete Antwort, Sessionexport und vollständige Tokenfelder. | ab dem nächsten TensorX-Lauf; vorherige direkte Python-Läufe bleiben Legacy-Bedingung |
|
||||
| **9.3.0** | **TensorX-Modellkatalog für Versuch 2 erweitert:** `qwen/qwen3.8-flash-next` und `z-ai/glm-5.3-flash`; Qwen erhält explizit das `thinking.level`-Effort-Mapping. Der TensorX-Aufruf dokumentiert nun `--agents`. Im Adapter stellt `custom` wie `builtin` das Werkzeug `spawn_subagent` bereit; Adapter-Version 2.1.0. | Beide IDs wurden am 31.08.2026 über `GET /v1/models` des konfigurierten TensorX-Gateways bestätigt. Ein Qwen-Smoke-Test bestätigte `thinking`, Reasoning-Tokens und Tool-Calling. Bei der Konfigurationsprüfung fiel außerdem auf, dass `custom` trotz geladener Rollen das Delegationswerkzeug ausblendete und der dokumentierte Aufruf die Agentendatei nicht übergab; damit wäre Versuch 2 über TensorX ohne spezialisierte Rollen gelaufen. MINOR für die Modellauswahl, funktionale Korrektur für V2. | ab dem ersten TensorX-Lauf in Versuch 2 |
|
||||
| **9.2.0** | **Delegationstiefe als Option im Modus `custom`.** Zwei gehashte Fassungen der Agentendatei: `verschachtelt` (Rollen dürfen selbst delegieren, bisheriges Verhalten) und `unverschachtelt` (Abschnitt *Keine Weiterdelegation* in jedem Rollenprompt). Die Fassung wird wie Modell, Modus und Effort vor dem Lauf beim User erfragt. Neues Protokollfeld *Delegationstiefe* mit Kontrolle über `subagent_stats.max_depth` und `spawned_by_subagents`. | Im ersten V2-Lauf (`v9.1.0-0c39`) entfielen 26 von 86 Subagenten auf Starts durch Subagenten (`max_depth` = 3). Das war nicht beabsichtigt – der `iso29148-orchestrator` ist als nicht-delegierende Rolle entworfen – und ist ein erheblicher Kostentreiber: Jede zusätzliche Ebene liest ihren Kontext erneut, und Cache-Reads stellten 46 % der Laufkosten. Es verwischt zudem die Zuständigkeit, weil ein von einer Rolle gestarteter Subagent keiner Teilaufgabe der Bindungstabelle mehr zuzuordnen ist. MINOR: neue Option und neue Messgröße; die Bedingung bestehender Läufe ändert sich nicht, sie gelten rückwirkend als `verschachtelt`. | ab dem zweiten V2-Lauf |
|
||||
| **9.1.0** | **Zuständigkeitsbindung im Modus `custom`.** Block 1 (Werkzeugkontext) wird bei `custom` um eine Tabelle `Teilaufgabe → vorgesehener Bearbeiter` ergänzt, abgeleitet aus der `--agents`-Datei. Der Prompt formuliert die Bindung abstrakt und nennt weiterhin keine Rolle, damit dieselbe Prompt-Datei für `solo` und `builtin` gültig bleibt. Neues Protokollfeld *Zuständigkeitsbindung*: Aufrufe je Rolle aus `subagent_stats.by_type`, Rollen mit null Aufrufen namentlich, Abgleich gegen die Dokumentationspflicht im `Analysebericht.md`. | V2 untersucht die Wirkung rollenspezialisierter Agentendateien. Bleibt die Nutzung freigestellt, wird die Bedingung nicht hergestellt: Im Smoke-Test vom 26.08. nutzte der Agent von acht beigestellten Rollen nur zwei (`modulinventar`, `konsistenzpruefer`) — der Lauf hätte die Rollen mitgeführt, ohne sie einzusetzen. Die Bindung ist statisch deklariert, in `_meta\combined_prompt.md` archiviert und über den SHA-256 der `--agents`-Datei versioniert; sie unterscheidet sich damit von den in 9.0.0 entfernten laufzeitabhängigen Adaptereingriffen. Anzahl der Aufrufe, Zerlegungstiefe, Reihenfolge und Turn-Anzahl bleiben unvorgegeben. MINOR, weil bislang **kein** Lauf im Modus `custom` existiert und deshalb keine Läufe unpoolbar werden; der erste V2-Lauf eröffnet ohnehin eine neue Iteration. | ab dem ersten V2-Lauf |
|
||||
|
||||
Reference in New Issue
Block a user