Thema: Teil 15. Austauschbarkeit von Agenten
Schwierigkeitsgrad: Mittelstufe
Geschätzte Studienzeit: 4-6 Stunden (Theorie + Praxis)
Voraussetzungen: Verständnis der Grundlagen von SDD (Specification-Driven Development)
Erfahrung mit Markdown und der Grundstruktur von Projekten
Vertrautheit mit mindestens einem KI-Agenten für die Entwicklung (Qwen Code, Claude Code, Cursor usw.)
Grundkenntnisse in Git und der Arbeit mit Repositories
Verständnis von JSON-Formaten und Konfigurationsdateien
Lernziele: AGENTS.md und QWEN.md als portable Verträge für KI-Agenten erstellen und pflegen, um die Unabhängigkeit des Projektgedächtnisses vom konkreten Werkzeug zu gewährleisten
Fähigkeitsaudits (SKILL.md) im Hinblick auf die Loslösung von schnittstellenspezifischen Merkmalen eines bestimmten Agenten durchführen und diese erfolgreich zwischen verschiedenen KI-Werkzeugen migrieren
Die Notwendigkeit der Anbindung von MCP-Servern kritisch bewerten und Szenarien der Effizienzsteigerung von einer übermäßigen Risikoflächenerweiterung unterscheiden
Die Prüfung „neuer Agent“ zur Validierung der Austauschbarkeit durchführen: einen Agenten ohne Chat-Verlauf starten und die Korrektheit der Bestimmung der nächsten sicheren Aktion anhand der Projektartefakte bestätigen
Sich mit der Kompatibilität von ACP-Protokollen bei der Integration von Agenten mit IDEs auskennen und typische Versionsprobleme beheben
Überblick: Die Austauschbarkeit von Agenten ist eine fundamentale Eigenschaft eines reifen SDD-Prozesses, die die Fähigkeit gewährleistet, die Entwicklung mit einem beliebigen KI-Agenten oder in einer beliebigen IDE fortzusetzen, ohne das Projektgedächtnis zu verlieren. In der modernen Entwicklung migrieren Teams periodisch zwischen Werkzeugen: Heute wird Qwen Code CLI verwendet, morgen Codex, Claude Code, Gemini CLI, Cursor, Kiro oder GitHub Spec Kit. Wenn die Absicht in Markdown-Dateien festgehalten und der Prozess als Fähigkeiten und Befehle formuliert ist, wird der konkrete Agent zu einer austauschbaren Ausführungsumgebung. Dieses Modul systematisiert Ansätze zur Erstellung von agentenunabhängigen Artefakten, zur Organisation von Verträgen über AGENTS.md, zur Übertragung von Fähigkeiten, zum verantwortungsvollen Einsatz von MCP, zum Verständnis von ACP-Integrationen und zur praktischen Prüfung der Austauschbarkeit.
Schlüsselkonzepte: Austauschbarkeit von Agenten: Die Fähigkeit, den Entwicklungsprozess mit einem anderen Agenten oder in einer anderen Umgebung fortzusetzen, ohne das Projektgedächtnis zu verlieren. Wird erreicht durch die Auslagerung aller Entscheidungen, Absichten und Prozesse in menschenlesbare Repository-Dateien statt in die Schnittstelle oder den Verlauf eines konkreten Werkzeugs.
Agentenunabhängige Artefakte: Dateien, die alle notwendigen Informationen zur Fortsetzung der Arbeit enthalten müssen: README.md, AGENTS.md/QWEN.md, specs/ mit mission.md, tech-stack.md, roadmap.md, Feature-Spezifikationen, CHANGELOG.md, Tests und Skripte. Diese Artefakte sind für jeden Agenten ohne zusätzlichen Kontext verständlich.
Agents.md: Universeller Vertrag für jeden KI-Agenten, der die Arbeitsregeln mit dem Projekt beschreibt: Verpflichtung zu Spezifikationen, Lesereihenfolge der Dateien, Verzweigungsregeln, Prüfungen vor dem Zusammenführen, Einschränkungen. Ist die Grundlage der Portabilität zwischen Werkzeugen.
Qwen.md: Schlanke agentenspezifische Datei, die nur werkzeugliche Besonderheiten von Qwen Code enthält (Verwendung von /clear, Verweise über @file, Befehle über !). Sollte auf AGENTS.md verweisen statt allgemeine Regeln zu duplizieren.
Skill.md und Fähigkeitenportabilität: Format der Fähigkeiten von Qwen Code, basierend auf Markdown-Anweisungen mit optionalen Skripten. Bei der Migration zwischen Agenten wird der Inhalt von SKILL.md mit minimalen Anpassungen der werkzeuglichen Details übertragen, wobei der Kern des Prozesses erhalten bleibt.
Mcp (model context protocol): Protokoll zur Anbindung externer Werkzeuge und Datenquellen an einen Agenten. Wird in settings.json oder über CLI konfiguriert. Jeder angeschlossene MCP-Server erweitert die Aktionsfläche des Agenten — folglich auch die Fläche potenzieller Risiken.
Acp (agent client protocol): Protokoll der standardisierten Interaktion zwischen einem Agenten und einem Client/IDE. Ermöglicht den Austausch der Schnittstelle bei gleichzeitiger Beibehaltung des Prozesses im Repository. Die Versionskompatibilität ist kritisch: Die Nichtübereinstimmung der ACP-Versionen v1/v2 zerstörte Anfang 2026 die Integration von Qwen Code mit JetBrains.
Github spec kit: Externes SDD-Framework, das den Prozess formalisiert: Absicht → Spezifikation → Plan → Aufgaben → Implementierung → Prüfung. Ist nicht an einen konkreten Agenten gebunden und dient als Orientierung für die Standardisierung eigener Prozesse.
Prüfung „neuer Agent“: Praktisches Experiment der Austauschbarkeit: Löschung des Verlaufs (/clear), Simulation eines Agenten ohne Kontext, Lesen der Schlüsseldateien und Prüfung der Fähigkeit, die nächste sichere Aktion korrekt zu bestimmen, ohne Dateien zu ändern.
Wichtige Daten: Anfang 2026: JetBrains 2025.3+ wechselten zu ACP v2 mit dem Format prompt.turn, was eine Inkompatibilität mit Qwen Code verursachte, das nur v1 unterstützte
Jahr 2026: Wiederherstellung der Kompatibilität in PR #1521 des Repositories qwen-code nach Issue #1502. Kritisches Ereignis zum Verständnis der Bedeutung der Versionskontrolle von Integrationsprotokollen
Übungsaufgaben: Titel: Erstellung eines zweistufigen Vertragssystems
Problem: In Ihrem Projekt hat sich gemischte Dokumentation angesammelt: Ein Teil der Regeln in QWEN.md, ein Teil in README.md, ein Teil nur in Ihrem Kopf. Erstellen Sie ein sauberes zweistufiges System: ein universelles AGENTS.md und ein schlankes QWEN.md. Dabei darf QWEN.md nicht mehr als 8 Zeilen enthalten und muss über die Konstruktion „Lies zuerst @AGENTS.md“ auf AGENTS.md verweisen.
Lösung: 1. Analysieren Sie das aktuelle QWEN.md und extrahieren Sie universelle Regeln (keine Features ohne Spezifikation implementieren, mission/tech-stack/roadmap lesen, Branches nach specs/YYYY-MM-DD-feature, npm test vor dem Merge, keine Geheimnisse im Repo). 2. Übertragen Sie die universellen Regeln in AGENTS.md mit klarer Struktur: Überschrift, Regelliste mit Aufzählungszeichen. 3. Erstellen Sie ein neues QWEN.md: Zeile 1 — Verweis auf AGENTS.md, Zeilen 2-8 — nur Qwen Code-Spezifika (/clear zwischen Phasen, @file für Spezifikationen, ! für lokale Befehle). 4. Entfernen Sie Duplikate. 5. Prüfen Sie: Starten Sie qwen, geben Sie den Befehl „lies @QWEN.md“ und stellen Sie sicher, dass der Agent @AGENTS.md korrekt auflöst.
Schwierigkeitsgrad: mittel
Titel: Fähigkeitsaudit auf Portabilität
Problem: Sie haben eine Fähigkeit zur Feature-Spezifikation in .qwen/skills/feature-spec/SKILL.md. Führen Sie ein Audit durch: Finden Sie alle Bindungen an die Qwen Code-Schnittstelle (Erwähnungen von /clear, @file, !, qwen-spezifische Befehle) und bestimmen Sie, welche davon verallgemeinert werden können und welche in der agentenspezifischen Ebene verbleiben müssen.
Lösung: 1. Lesen Sie SKILL.md und markieren Sie jeden werkzeuglichen Detail. 2. Klassifizieren Sie: (a) Kern des Prozesses — Phase in der Roadmap finden, Grenzen, Entscheidungen, Kontext abfragen, requirements/plan/validation erstellen — dies bleibt; (b) Aufrufweise — /clear, @file, ! — dies ist Agentenspezifika. 3. Restrukturieren Sie SKILL.md: Abschnitt „Prozess“ ohne Bindungen, Abschnitt „Werkzeugliche Details für Qwen Code“ mit dem Hinweis „bei Migration für Zielagenten anpassen“. 4. Erstellen Sie einen Testtransfer: Kopieren Sie SKILL.md in einen hypothetischen Ordner .cursor/skills/ und beschreiben Sie, was sich für Cursor ändern würde (Cmd+K statt /clear, @ für Kontext statt @file).
Schwierigkeitsgrad: mittel
Titel: Risikobewertung einer MCP-Anbindung
Problem: Ihr Team möchte drei MCP-Server anbinden: (1) lokaler Server für Projektdokumentation über stdio, (2) externer HTTP-Server für Code-Analytik, (3) Drittanbieter-MCP aus einem ungeprüften Repository „zur Bequemlichkeit“. Führen Sie eine Risikobewertung durch und formulieren Sie eine Empfehlung.
Lösung: 1. Analysieren Sie jeden Server nach Kriterien: Notwendigkeit, Vertrauenswürdigkeit der Quelle, Aktionsfläche, Auditierbarkeit. 2. Server 1 (lokaler stdio, node ./tools/mcp-server.js): hohe Vertrauenswürdigkeit, eingeschränkte Fläche, notwendig für Projektdokumentation — empfehlen mit Timeout 15000ms. 3. Server 2 (externer HTTP): Authentifizierung prüfen, HTTPS, Scope einschränken, VPN/Whitelist-IP in Betracht ziehen — bedingt empfehlen mit Vorbehalten. 4. Server 3 (ungeprüfter Drittanbieter): ablehnen, begründet mit dem Prinzip „binden Sie MCP nicht für alle Fälle an“ — jedes Werkzeug erweitert die Aktionsfläche des Agenten und damit die Fläche potenzieller Fehler und Bedrohungen. 5. Formulieren Sie die Entscheidung als Eintrag in AGENTS.md: Bewertungsregel für MCP und Liste der genehmigten Server.
Schwierigkeitsgrad: mittel
Titel: Prüfung „neuer Agent“ in Aktion
Problem: Führen Sie einen vollständigen Zyklus der Austauschbarkeitsprüfung Ihres Projekts durch. Simulieren Sie eine Situation, in der ein Entwickler in Urlaub gegangen ist und ein neues Teammitglied (oder ein anderer Agent) die Arbeit ohne persönlichen Kontakt fortsetzen muss.
Lösung: 1. Führen Sie /clear in Qwen Code zum Zurücksetzen des Kontexts aus. 2. Formulieren Sie den Prompt: „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. Sage, welche nächste Aktion im Projekt sicher ist. Ändere keine Dateien." 3. Dokumentieren Sie die Antwort des Agenten. 4. Prüfen Sie die Korrektheit: Vergleichen Sie mit Ihrem Verständnis der Prioritäten — sollte die aktive Phase der Roadmap bestimmen, eine unvollständige Spezifikation finden, das Lesen des entsprechenden requirements.md vorschlagen. 5. Wenn die Antwort falsch ist — identifizieren Sie die Lücke in der Dokumentation (nicht genug Details in der Roadmap? keine expliziten Prioritäten? AGENTS.md beschreibt nicht den Prozess zur Bestimmung der „nächsten Aktion"?). 6. Korrigieren Sie und wiederholen Sie bis zum stabilen Erfolg.
Schwierigkeitsgrad: mittel
Titel: Diagnose einer ACP-Integration
Problem: Die Integration von Qwen Code mit JetBrains funktioniert nach einem IDE-Update plötzlich nicht mehr. Nutzen Sie Ihr Wissen über ACP-Versionierung, um eine Diagnose durchzuführen und einen Wiederherstellungsplan zu erstellen.
Lösung: 1. Erster Diagnoseschritt — Versionen prüfen: qwen --version und Version der JetBrains-IDE (Hilfe → Über). 2. Mit historischem Kontext vergleichen: JetBrains 2025.3+ verwenden ACP v2 (prompt.turn), ältere Qwen Code-Versionen unterstützten nur v1 — Issue #1502. 3. Wenn die Qwen Code-Version vor PR #1521 (Jahr 2026) liegt — auf aktuelle Version aktualisieren. 4. Wenn die Versionen kompatibel sind — Konfiguration der agent_servers in den IDE-Einstellungen prüfen: Korrektheit des Pfads, Argument --acp, Umgebungsvariablen. 5. Logs prüfen: in der IDE (Hilfe → Log im Explorer/Finder anzeigen) und in der Ausgabe von qwen --acp --verbose. 6. Plan formulieren: (a) Agenten aktualisieren, (b) IDE zurücksetzen, (c) vorübergehenden CLI-Modus verwenden, (d) auf Patch warten. 7. Vorfall in der Projektdokumentation für zukünftige Austauschbarkeit festhalten.
Schwierigkeitsgrad: fortgeschritten
Fallstudien: Titel: Migration eines Startups von Qwen Code auf Claude Code ohne Kontextverlust
Szenario: Ein Technologie-Startup mit 12 Mitarbeitern nutzte 8 Monate lang Qwen Code CLI für die Entwicklung einer SaaS-Plattform. Die Projektstruktur umfasste specs/, SKILL.md für Feature-Spezifikationen, QWEN.md mit detaillierten Anweisungen. Das Team musste auf Claude Code wechseln aufgrund der besseren Integration mit ihrem CI/CD und Unternehmenssicherheitsanforderungen.
Herausforderung: Hauptproblem: QWEN.md enthielt 200+ Zeilen, die universelle SDD-Regeln mit tiefen Bindungen an die Qwen Code-Schnittstelle vermischten (/clear, @file, !, spezifische Workflows). Neue Entwickler, die an Claude Code gewöhnt waren, fanden sich in nicht anwendbaren Anweisungen nicht zurecht. Fähigkeiten in .qwen/skills/ enthielten direkte Verweise auf qwen-spezifische Befehle. Das Projektgedächtnis war de facto in die „Sprache“ eines Werkzeugs eingebettet, nicht in die Struktur des Repositories.
Lösung: Das Team führte eine zweiwöchige Audit nach der Methodik der Agentenaustauschbarkeit durch: 1) Universelle Regeln aus QWEN.md in ein neues AGENTS.md extrahiert — Spezifikationsprozess, obligatorische Prüfungen, Branch-Struktur. 2) QWEN.md auf 6 Zeilen Referenzdatei gekürzt. 3) CLAUDE.md mit analoger Struktur für Claude Code erstellt (Cmd+Enter statt /clear, Kontext-Erwähnungen statt @file). 4) Alle SKILL.md restrukturiert: Abschnitt „Prozess" (portabel) und „Werkzeugliche Details" (agentenspezifisch). 5) Prüfung „neuer Agent" für beide Werkzeuge durchgeführt — sichergestellt, dass Claude Code die nächsten Schritte korrekt anhand AGENTS.md + specs/ bestimmt.
Ergebnis: Die Migration erforderte 2 Wochen Vorbereitung + 3 Tage Umschaltung des Teams. Das Projektgedächtnis wurde vollständig erhalten. Neue Entwickler waren nach 1-2 Tagen eingebunden statt der bisherigen 1-2 Wochen. Nach 3 Monaten experimentierte das Team mit Cursor für Frontend-Entwicklung unter Verwendung desselben AGENTS.md — die Adaptionzeit sank auf wenige Stunden.
Erkenntnisse: Frühe Investition in AGENTS.md zahlt sich bei Werkzeugwechsel exponentiell aus — dies ist eine Absicherung, kein Overhead
Fähigkeiten müssen explizit zwischen Prozesskern und werkzeuglichen Details trennen; sonst erfordert jede Migration einen Reengineering
Die Prüfung „neuer Agent" sollte eine regelmäßige Routine sein, kein einmaliges Übung — sie deckt „Degradation" der Dokumentation im Entwicklungsprozess auf
Eine Multi-Agenten-Umgebung (verschiedene Werkzeuge für verschiedene Aufgaben) wird Realität; die Architektur muss dies vorsehen
Verwandte Konzepte: AGENTS.md und QWEN.md
Portabilität von Fähigkeiten SKILL.md
Prüfung „neuer Agent"
Agentenunabhängige Artefakte
Titel: Vorfall mit MCP-Server: Wann „Bequemlichkeit" zur Bedrohung wurde
Szenario: Ein Team aus 5 Entwicklern band einen MCP-Server für die automatische Generierung von API-Dokumentation aus einem externen Dienst an. Der Server erforderte Zugriff auf das interne Netzwerk und hatte weitreichende Leserechte für das Repository „zur Kontextanalyse". Nach 2 Monaten wurde ein Leck entdeckt: Der Server protokollierte Codefragmente auf einen externen Analytikserver.
Herausforderung: Das Problem lag im grundsätzlichen Ansatz: MCP wurde „für alle Fälle" ohne Risikoflächenbewertung hinzugefügt. Die Konfiguration in settings.json war nicht in AGENTS.md dokumentiert. Bei dem Weggang des ersten Entwicklers, der MCP eingerichtet hatte, gingen Kenntnisse über dessen Existenz und Risiken verloren. Neue Teammitglieder verstanden nicht, warum der Agent Zugriff auf das interne Netzwerk hatte.
Lösung: Nach dem Vorfall implementierte das Team eine strenge MCP-Politik: 1) Jeder MCP erfordert einen Eintrag in AGENTS.md mit Begründung der Notwendigkeit, Beschreibung der Aktionsfläche und Risiken. 2) Lokale MCP über stdio sind externen HTTP vorzuziehen. 3) Externe MCP erfordern Sicherheitsaudit und Einschränkung nach IP/VPN. 4) Regelmäßige Überprüfung: Quartalsweise werden alle MCP auf Aktualität geprüft. 5) Nicht genutzter Dokumentationsserver entfernt; ersetzt durch ein lokales Skript, das Markdown im Repository ohne externe Aufrufe generiert.
Ergebnis: Der Vorfall führte nicht zur Kompromittierung der Produktion, kostete aber 2 Wochen Audit und Überprüfung der Richtlinien. Das neue System verhinderte 3 ähnliche „bequeme" Anbindungen in den folgenden 6 Monaten. Das Team erkannte, dass Agentenaustauschbarkeit auch die Austauschbarkeit/Löschbarkeit seiner Werkzeuge ohne Prozessverlust umfasst.
Erkenntnisse: Das Prinzip „binden Sie MCP nicht für alle Fälle an" hat einen konkreten Verletzungspreis — jedes Werkzeug erweitert die Aktionsfläche des Agenten und die potenzielle Angriffsfläche
Undokumentierte Integrationen sind ein Antipattern der Austauschbarkeit; sie schaffen versteckte Abhängigkeiten, die das Projektgedächtnis bei Personen- oder Werkzeugwechsel „töten"
Lokale Alternativen (Skripte, Markdown-Generierung) sind oft externen Diensten vorzuziehen, wenn das Ziel langfristige Austauschbarkeit ist
Regelmäßige Überprüfung von Integrationen sollte Teil des Prozesses sein, keine Reaktion auf Vorfälle
Verwandte Konzepte: MCP als externe Werkzeugschicht
MCP-Sicherheitsregel
Agentenunabhängige Artefakte
AGENTS.md als Vertrag
Titel: Kompatibilität ACP v1/v2: Lektion aus der Integration mit JetBrains
Szenario: Ein Unternehmensteam aus 20 Entwicklern nutzte Qwen Code über ACP-Integration mit JetBrains-IDE (IntelliJ IDEA, PyCharm). Anfang 2026 funktionierte die Integration nach einem planmäßigen IDE-Update auf Version 2025.3 nicht mehr: Der Agent verband sich nicht, Befehle wurden nicht ausgeführt, Logs zeigten Protokollfehler.
Herausforderung: Die Diagnose wurde durch fehlende explizite Dokumentation über ACP-Versionierung in den Projektartefakten erschwert. Das Team wusste nicht, dass es ACP v1 nutzte, während die neue IDE v2 mit dem Format prompt.turn erforderte. Die Lösungssuche kostete 3 Tage Ausfallzeit: Lesen von Issues auf GitHub, Analyse von PRs, Experimente mit IDE-Downgrade und verschiedenen qwen-Flags. Das Wissen über die Inkompatibilität war nicht in der Projektdokumentation festgehalten, daher wiederholte es sich bei jedem Arbeitsplatzupdate.
Lösung: Nach der Wiederherstellung der Kompatibilität durch Aktualisierung von Qwen Code (PR #1521) fügte das Team hinzu: 1) In AGENTS.md einen Abschnitt „Integrationen und Protokolle" mit expliziter Angabe der ACP-, MCP- und anderer Protokollversionen. 2) Ein Skript zur Umgebungsprüfung (check-env.sh), das Versionen von Agent, IDE, Protokollen und Kompatibilitätsflags ausgibt. 3) Monitoring von Issues des Repositories qwen-code für kritische Protokolländerungen. 4) Dokumentation des Rollback-Verfahrens: vorübergehender Wechsel in den CLI-Modus bei IDE-Inkompatibilität.
Ergebnis: Das nächste JetBrains-Update (2026.2) erforderte Anpassungen, aber das Team reagierte in 2 Stunden statt 3 Tagen. Die Umgebungsprüfung wurde Teil des Onboardings neuer Entwickler. Die Architektur „Prozess im Repository, Schnittstelle austauschbar" erhielt konkrete Umsetzung: Bei ACP-Ausfall wechselte das Team ohne Arbeitsfähigkeitsverlust auf CLI.
Erkenntnisse: Versionsübereinstimmung von Protokollen ist eine kritische, aber oft ignorierte Komponente der Austauschbarkeit; sie muss explizit dokumentiert sein
Abhängigkeit von der IDE-Integration schafft einen Single Point of Failure; CLI-Modus als Fallback ist eine obligatorische Strategie
Monitoring von Upstream-Änderungen der Protokolle sollte Teil des DevOps-Prozesses sein, keine Ad-hoc-Aktivität
Umgebungsprüfung („health check") ist ein praktisches Werkzeug zur Gewährleistung der Austauschbarkeit: Es macht versteckte Abhängigkeiten sichtbar
Verwandte Konzepte: ACP und IDE
Versionskompatibilität von Protokollen
Prüfung „neuer Agent"
Prozess im Repository, Schnittstelle austauschbar
Studientipps: Beginnen Sie die Praxis mit dem eigenen Projekt: Nehmen Sie das aktuelle Repository und führen Sie ein Audit auf Austauschbarkeit durch, unter Verwendung der Checkliste aus den praktischen Aufgaben — Theorie wird durch persönlichen Kontext tiefer verankert
Nutzen Sie die Methode des „parallelen Agenten": Arbeiten Sie eine Woche mit einem Werkzeug, notieren Sie alle impliziten Abhängigkeiten, dann versuchen Sie, die Aufgabe mit einem anderen Agenten anhand Ihres AGENTS.md zu wiederholen — die Lücke zeigt reale Defizite
Erstellen Sie Vorlagen, keine fertigen Dateien: Bereiten Sie Boilerplate-AGENTS.md, QWEN.md, SKILL.md für den schnellen Start neuer Projekte vor — dies verwandelt Austauschbarkeit von Anstrengung in Gewohnheit
Führen Sie ein „Vorfallstagebuch der Austauschbarkeit": Dokumentieren Sie jeden Fall, in dem ein Agenten-, IDE- oder Entwicklerwechsel Reibung verursachte — nach 3-6 Monaten zeigen Muster systemische Probleme in der Dokumentationsarchitektur
Studieren Sie GitHub Spec Kit als Maßstab: Auch wenn Sie es nicht implementieren, vergleichen Sie Ihr .qwen/skills/feature-spec mit deren Prozess — dies ist eine Kalibrierung des Verständnisses „reifer" Austauschbarkeit
Üben Sie die „Blackbox": Bitten Sie einen Kollegen, der das Projekt nicht kennt, nur AGENTS.md + specs/ zu lesen und zu beschreiben, was er als Nächstes tun würde — die externe Perspektive deckt das für Sie „Offensichtliche" auf, das für andere nicht so ist
Dokumentieren Sie Ablehnungen: Wenn die Prüfung „neuer Agent" ein falsches Ergebnis liefert, korrigieren Sie nicht sofort — notieren Sie zuerst, was genau schiefging, dies trainiert die Erkennung von Problemkategorien
Zusätzliche Ressourcen: Repository qwen-code und Issue #1502/#1521: https://github.com/QwenLM/qwen-code/issues/1502 — Primärquelle des ACP v1/v2-Vorfalls, obligatorisch zum Verständnis der realen Dynamik von Protokollen
Github spec kit: https://github.com/github/spec-kit — Externes SDD-Framework zum Vergleich mit eigenen Prozessen, studieren Sie die Struktur Absicht→Spezifikation→Plan→Aufgaben→Implementierung→Prüfung
Dokumentation mcp (model context protocol): https://modelcontextprotocol.io — Protokollspezifikation, Beispielserver, Best Practices für Sicherheit
Acp specification: Interne Dokumentation von JetBrains und Qwen Code zum Agent Client Protocol — verfolgen Sie Changelogs für Versionskontrolle
Vorlage agents.md für den Start: Erstellen Sie eine eigene auf Basis des Kursbeispiels, passen Sie sie an den Team-Stack an und veröffentlichen Sie sie als interne Vorlage
Katalog skill.md von Open-Source-Projekten: Analysieren Sie .qwen/skills/ in öffentlichen Repositories, die Qwen Code nutzen, um Portabilitätsmuster zu sammeln
Werkzeuge zur statischen Markdown-Analyse: markdownlint, vale — zur Aufrechterhaltung der Qualität und Konsistenz der Projektdokumentation, kritisch für das Verständnis durch jeden Agenten
Zusammenfassung: Die Austauschbarkeit von Agenten ist keine technische Luxus, sondern eine Notwendigkeit in einer Welt schnell evolvierender KI-Werkzeuge. Schlüsselprinzipien: Der Prozess lebt im Repository, der Agent ist eine austauschbare Ausführungsumgebung. Praktische Stützen: AGENTS.md als universeller Vertrag, schlanke agentenspezifische Dateien (QWEN.md, CLAUDE.md), portable Fähigkeiten mit expliziter Trennung von Kern und werkzeuglichen Details, begründeter Einsatz von MCP mit Risikodokumentation, Verständnis der Protokollversionierung (ACP), regelmäßige Prüfung „neuer Agent". Erfolgreiche Austauschbarkeit wird nicht an der Anzahl unterstützter Werkzeuge gemessen, sondern an der Geschwindigkeit und Vollständigkeit der Übertragung des Projektgedächtnisses zwischen beliebigen Agenten und Menschen ohne Kontextverlust.