Teil 15. Austauschbarkeit des Agenten

Austauschbarkeit des Agenten ist die Fähigkeit, den Prozess durch einen anderen Agenten oder in einer anderen IDE fortzusetzen, ohne den Projektspeicher zu verlieren. In SDD ist dies ein natürliches Ziel: Wenn die Absicht in Markdown-Dateien festgehalten und der Prozess als Fähigkeiten und Befehle strukturiert ist, wird der konkrete Agent zur austauschbaren Ausführungsumgebung.

Heute nutzen Sie Qwen Code CLI. Morgen kann ein Teil des Teams Codex, Claude Code, Gemini CLI, Cursor, Kiro oder GitHub Spec Kit verwenden. Je weniger Entscheidungen ausschließlich in der Oberfläche eines einzelnen Werkzeugs leben, desto robuster ist der Prozess.

Was unabhängig vom Agenten sein sollte

README.md
QWEN.md / AGENTS.md
specs/
  mission.md
  tech-stack.md
  roadmap.md
  YYYY-MM-DD-feature/
    requirements.md
    plan.md
    validation.md
CHANGELOG.md
tests/
package.json-Skripte

Wenn diese Dateien verständlich sind, kann ein anderer Agent die Arbeit fortsetzen.

QWEN.md und AGENTS.md

Qwen Code verwendet QWEN.md, kann aber auch AGENTS.md lesen. Wenn Sie Portabilität wünschen, erstellen Sie AGENTS.md als allgemeinen Vertrag und gestalten Sie QWEN.md als dünnen Verweis.

AGENTS.md:

# Anweisungen für den Agenten

In diesem Repository wird SDD verwendet.

- Implementiere keine Produktfeatures ohne Feature-Spezifikation.
- Lies vor der Planung specs/mission.md, specs/tech-stack.md und specs/roadmap.md.
- Jeder Feature-Branch muss specs/YYYY-MM-DD-feature-name/ enthalten.
- Halte Änderungen innerhalb der Grenzen der aktiven Spezifikation.
- Führe vor dem Merge npm test und npm run typecheck aus.
- Speichere keine Geheimnisse im Repository.

QWEN.md:

Lies zuerst @AGENTS.md.
Hinweise für Qwen Code:
- Verwende /clear zwischen Planung, Implementierung und Überprüfung.
- Verweise auf Spezifikationen mit @file.
- Verwende Befehle mit ! für lokale Überprüfung.

Portabilität von Fähigkeiten

Qwen Code-Fähigkeiten verwenden SKILL.md. Dieses Format ähnelt einer allgemeinen Konvention für Agentenfähigkeiten: Markdown-Anweisungen plus optionale Skripte und Vorlagen. Selbst wenn ein anderer Agent Fähigkeiten an anderer Stelle speichert, kann der Inhalt übertragen werden.

Bei der Übertragung:

.qwen/skills/feature-spec/SKILL.md

kann in das Fähigkeitenverzeichnis eines anderen Agenten kopiert und nur die werkzeugspezifischen Details angepasst werden. Der Kern des Prozesses bleibt derselbe: Phase in der Roadmap finden, Grenzen, Entscheidungen und Kontext erfragen, requirements.md, plan.md und validation.md erstellen.

MCP als externe Werkzeugschicht

MCP ermöglicht die Anbindung externer Werkzeuge und Datenquellen. In Qwen Code wird MCP in settings.json oder über qwen mcp add konfiguriert.

Beispiel für einen lokalen MCP über stdio:

{
  "mcpServers": {
    "projectTools": {
      "command": "node",
      "args": ["./tools/mcp-server.js"],
      "timeout": 15000
    }
  }
}

Beispielbefehl:

qwen mcp add --transport http docs http://localhost:3000/mcp
qwen mcp

Sicherheitsregel: Schließen Sie MCP nicht „für alle Fälle" an. Jedes Werkzeug erweitert die Handlungsoberfläche des Agenten.

ACP und IDE

Agent Client Protocol (ACP) dient dazu, dass Agent und Client/IDE standardisiert interagieren können. Qwen Code kann mit JetBrains im ACP-Modus arbeiten:

{
  "agent_servers": {
    "qwen": {
      "command": "/path/to/qwen",
      "args": ["--acp"],
      "env": {}
    }
  }
}

Selbst wenn Sie CLI verwenden, ist es nützlich, die Richtung zu verstehen: Der Prozess sollte im Repository leben, die Schnittstelle sollte austauschbar sein.

Historischer Hinweis: Anfang 2026 wechselten JetBrains 2025.3+ zu ACP v2 (prompt.turn), während Qwen Code eine Zeit lang nur v1 unterstützte, was die Integration brach (Issue QwenLM/qwen-code#1502). Die Kompatibilität wurde in PR #1521 noch 2026 wiederhergestellt. Wenn die Integration mit JetBrains plötzlich nicht mehr funktioniert, ist das Erste, was zu prüfen ist, die Version von Qwen Code und die IDE-Version: Sie müssen in derselben ACP-Version kommunizieren.

GitHub Spec Kit als externes SDD-Framework

GitHub Spec Kit bietet einen formaleren Prozess: Absicht beschreiben, planen, in Aufgaben zerlegen, implementieren. Es ist nicht an einen bestimmten Agenten gebunden und kann mit verschiedenen Agenten zusammenarbeiten, die Code schreiben. Es muss nicht unbedingt in AgentClinic eingeführt werden, aber es ist nützlich zu wissen, dass Ihr manueller SDD-Zyklus mit der allgemeinen Richtung übereinstimmt:

Absicht → Spezifikation → Plan → Aufgaben → Implementierung → Überprüfung

Wenn das Team mehr Standardisierung wünscht, können Sie Ihr .qwen/skills/feature-spec mit Spec Kit vergleichen und entscheiden, ob ein separates Framework benötigt wird.

Überprüfung der Austauschbarkeit

Führen Sie ein Experiment durch:

/clear
Stell dir vor, du bist ein neuer Agent ohne Chat-Verlauf.

Lies @AGENTS.md, @QWEN.md, @specs/mission.md, @specs/tech-stack.md und @specs/roadmap.md.
Sag, welche nächste Aktion im Projekt sicher ist.
Ändere keine Dateien.

Wenn die Antwort korrekt ist, funktioniert der Projektspeicher.

Praxis

1. Erstellen Sie AGENTS.md.
2. Gestalten Sie QWEN.md als kurze Datei nur für Qwen Code.
3. Prüfen Sie, ob die Feature-Spezifikationsfähigkeit keine überflüssigen, an Qwen Code gebundenen Details enthält.
4. Beschreiben Sie MCP nur für wirklich benötigte Werkzeuge.
5. Führen Sie die „neuer Agent"-Überprüfung durch.

Kontrollfragen

1. Welche Artefakte machen den Prozess portabel?
2. Warum sollten Fähigkeiten nicht an eine einzelne Schnittstelle gebunden werden?
3. Wann ist MCP nützlich, und wann erhöht er nur das Risiko?