Agenten-Architektur

Dies ist eine an Entwickler gerichtete Tech-Spec-Seite. Sie verwendet Apothems internes Vokabular — Adapterklassen, Materializer, Propagation-Manifest, Geschwister-Konventions-Konvergenz — ohne es für ein allgemeines Publikum abzuschwächen.

Apothem liest ein gemeinsames Profil (~/.config/apothem/profile.yaml) und materialisiert die tool-native Konfiguration für siebzehn registrierte Adapter. Die Harnesses teilen sich kein agentisches Fähigkeitsmodell: Manche stellen Pre-Tool-Call-Hooks bereit, manche führen Regeln aus flachen .md-Dateien aus, manche betten jede Regel in eine einzige Anweisungsdatei ein, und manche rendern eine profilgesteuerte Konfiguration zur Installationszeit. Diese Seite kartiert diese Divergenz und die Disziplin, die Apothem darüber hinweg anwendet.

Agentische Fähigkeitsmatrix je HarnessCopy Anchor Link

Die Matrix unten deckt alle siebzehn Harnesses ab. Spalten: die PreToolUse-Hook- Oberfläche, die der Adapter anbindet (wo ein Harness Hooks dokumentiert, die der Adapter nicht registriert, sagt die Zelle das), das Format, das Apothem zur Aktivierung von Regeln verwendet, die Adapterklasse (siehe Adapterklassen), und ob der Adapter über einen Materializer eine native Konfiguration rendert.

Anmerkungen zur Matrix:

• claude-code ist der Adapter mit der breitesten nativen Oberfläche. Er trägt native PreToolUse-, PostToolUse-, Stop- und SessionStart-Hooks und liefert Vendor-Settings-Templates. Er schreibt einen durch Sentinel-Marker abgegrenzten verwalteten Block in CLAUDE.md und lässt die Prosa des Operators außerhalb der Sentinel-Marker unverändert.
• codex installiert native Lebenszyklus-Hooks über hooks.json, konvertiert Agenten nach TOML, verpackt Command-Prompts als Codex-Skills und belässt config.toml in der Hoheit des Operators.
• antigravity behält ~/.gemini/GEMINI.md als globalen Kontextanker und installiert ein Apothem-Plugin unter ~/.gemini/antigravity-cli/plugins/apothem/. Hook-Dateien bleiben als Unterstützungsmaterial erhalten, bis der Adapter die Übersetzung des Antigravity-Hook-Schemas übernimmt.
• cursor aktiviert Regeln über eine .mdc-Datei, die das Vendor-MDC-Frontmatter (description, globs, alwaysApply) tragen; der Adapter schreibt keine Einzeldatei .cursorrules.
• windsurf verwendet .devin/rules/; der Adapter schreibt keine Einzeldatei .windsurfrules.
• hermes und open-claw rendern native Konfigurationsdateien und binden Apothem-Unterstützungs-Skill-Verzeichnisse über die dokumentierte Skill-Verzeichnis-Einstellung jedes Harness an. Nicht unterstützte gemeinsame Kohorten bleiben unter Apothem-eigenen Unterstützungs-Teilbäumen.
• qwen-code rendert dokumentierte settings.json-Schlüssel für Kontext und Hook-Dispatch und verwendet anschließend die Qwen-nativen Verzeichnisse für Commands, Skills und Agenten.

Disziplin der tool-übergreifenden OrchestrierungCopy Anchor Link

Apothem wendet Geschwister-Konventions-Konvergenz an: derselbe vom Betreiber aufrufbare Workflow wird in das native Idiom jedes Harness projiziert, statt in ein einziges gemeinsames Format gezwängt zu werden. Eine Regel, die unter claude-code als flache .md-Datei aktiviert wird, wird unter cursor zu einer .mdc-Workspace-Regel, unter gemini-cli zu einem eingebetteten Abschnitt von GEMINI.md und unter qwen-code zu einer verketteten Referenz in QWEN.md plus nativen Discovery-Verzeichnissen — dieselbe Absicht, der Dialekt jedes Harness.

Die kanonische Master-Kohorte liegt unter:

src/apothem/{rules,commands,skills,agents,output-styles,hooks,conformity,statuslines}/

Jeder Adapter propagiert eine Teilmenge dieser Kohorte. Die Teilmenge je Harness ist in src/apothem/lib/propagation-manifest.yaml deklariert; das Manifest ist die einzige Quelle der Wahrheit dafür, welche Artefakte welchen Harness in welcher Form erreichen. Ein Adapter erfindet niemals Artefakte außerhalb des Manifests, und das Manifest weist niemals ein Artefakt einem Harness zu, dem die Oberfläche zum Beherbergen fehlt.

Adapterklassen erklärtCopy Anchor Link

Apothem sortiert Adapter in drei Klassen danach, wie sie das gemeinsame Profil in tool-native Ausgabe übersetzen.

• Klasse I — Roh-Propagation. Der Adapter kopiert die kanonischen Master-Artefakte (eine im Manifest deklarierte Teilmenge) ohne Rendering-Schritt direkt an den Konfigurationsort des Harness. Es gibt keinen Materializer. antigravity, codebuddy, codex, cursor, gemini-cli, github-copilot, glm, kimi-code, kiro, trae, windsurf und zed sind Klasse I.
• Klasse II-A — Roh + vendor-gebundene Settings-Templates. Der Adapter propagiert Artefakte roh und verwaltet zusätzlich vendor-spezifische Settings-Templates, die an das Schema des Vendors gebunden sind. claude-code ist Klasse II-A.
• Klasse II-B — profil-gerenderter Einzeloberflächen-Materializer. Der Adapter rendert das gemeinsame Profil über einen Materializer in eine einzige native Konfigurationsoberfläche. hermes, open-claw, opencode und qwen-code sind Klasse II-B.

Verhalten zur Materializer-ZeitCopy Anchor Link

Die Klassenunterscheidung tritt zur Materializer-Zeit zutage — wenn ein Betreiber die CLI gegen einen Harness ausführt:

• apothem install --harness <H> propagiert die Manifest-Teilmenge für <H> und rendert für Adapter der Klasse II-A / II-B die tool-native Konfiguration.
• apothem verify --harness <H> prüft, ob die verwalteten Dateien existieren und sich parsen lassen. Mit --profile PATH prüft es sie zusätzlich gegen das, was dieses Profil erzeugen würde, und schlägt bei Drift fehl.
• apothem status meldet, ob jeder Harness installiert ist und ob er vom aktuellen gemeinsamen Profil abgedriftet ist.
• apothem doctor meldet den Zustand je Harness über jeden registrierten Adapter hinweg: ok, not_installed, needs_project, verify_failed, hook_failed oder error.

Siehe die CLI-Referenz für die vollständigen Command-Oberflächen.

Divergenz-TaxonomieCopy Anchor Link

Die siebzehn Harnesses divergieren entlang dreier Achsen. Jeder Unterschied je Harness in der Matrix lässt sich auf eine davon zurückführen.

Apothems Aufgabe ist es, eine kohärente Betreiberabsicht konstant zu halten, während diese drei Achsen je Harness variieren. Das Propagation-Manifest und der Adapterklassen-Vertrag sind die beiden Mechanismen, die diese Absicht über die Divergenz hinweg stabil halten.