diff --git a/APM Package Model-2026-08-22-213643.png b/APM Package Model-2026-08-22-213643.png new file mode 100644 index 0000000..4801041 Binary files /dev/null and b/APM Package Model-2026-08-22-213643.png differ diff --git a/APM Paket Skill-2026-08-22-213610.png b/APM Paket Skill-2026-08-22-213610.png new file mode 100644 index 0000000..470931d Binary files /dev/null and b/APM Paket Skill-2026-08-22-213610.png differ diff --git a/MCP Package Dependencies-2026-08-22-204525.png b/MCP Package Dependencies-2026-08-22-204525.png new file mode 100644 index 0000000..b198ca1 Binary files /dev/null and b/MCP Package Dependencies-2026-08-22-204525.png differ diff --git a/apm-omos-agent-teams-v3.md b/apm-omos-agent-teams-v3.md index 01cb359..1cdecd1 100644 --- a/apm-omos-agent-teams-v3.md +++ b/apm-omos-agent-teams-v3.md @@ -1,46 +1,99 @@ # APM, Agent-Teams und das kleine Problem namens Realität -*Wie APM-Packages Team-Empfehlungen ausliefern können – mit oh-my-opencode-slim als erstem konkretem Target.* +## Wie APM-Packages um Agent Team-Empfehlungen erweitert werden können – mit oh-my-opencode-slim als erstem konkretem Target. -Der Agenten-Stack entwickelt sich gerade mit der Geschwindigkeit eines explodierenden Werkzeugschuppens. Jeden Monat erscheint ein neues Manifest, ein neues Plugin-Format oder eine neue Orchestrierungsebene. Alles löst einen legitimen Teil des Problems. Fast nichts passt nahtlos zusammen. +SNES-Cartridge in klassischem Grau mit lila Etikett. Das Etikett zeigt den Text "Tour Planer Agent 3000" in fettem, retro-weißen und gelben Schriftzug. Die Cartridge ist leicht nach rechts geneigt, mit subtiler Reflexion auf der Kunststoffoberfläche. Neutraler, sauberer Hintergrund. -Das ist kein Vorwurf. Es ist der normale Zustand eines jungen Ökosystems. Der interessante Teil beginnt dort, wo die bestehenden Stücke bereits ausreichen, um eine sinnvolle Brcke zu bauen. +Ein Austauschformat so selbsterklärend wie in die Videospiele der 90er. Einfach Einlegen und Abspielen. Aktuell hat diese Vision mit der Realität des AI-Agenten-Ökosystems wenig zu tun. Nur die Gefahr des Vendor-Lock-Ins bleibt bestehen. +Heute beginnt das Abenteuer zunächst als Textadventure. +> Was willst du tun? (Instruktionen) +> +> Wie soll es erledigt werden? (Skills) +> +> Womit soll es erledigt werden? (Werkzeuge, MCP-Abhängigkeiten) +> +> Wie soll das Agenten-Team zusammengesetzt sein? +> +> Welche Modellkonfiguration sollen die Agenten erhalten? (Modell, Variante, Temperature, … pro Subagent) +> +> Welche Untermenge der Werkzeuge erhalten die jeweiligen Agenten? (MCP-per-Subagent) +> +> Welches Orchestrierungsmuster soll verwendet werden? -Diese Brcke kann so aussehen: +Was folgt, ist der klassische _programmer Move_: Man automatisiert (mittlerweile AI-unterstützt) in nur 10 Stunden erfolgreich eine Aufgabe die man händisch in 10 Minuten hätte erledigen können. +Selbstverständlich ist all das praktisch nicht portabel, denn will man seinen mühsam definierten Workflow mit Freunden und Kollegen teilen muss +alles passen. Welcher Harness soll verwendet werden? Sind die Modelle verfügbar und falls nein, kann ich sie substituieren? ... -> Ein APM-Package liefert Skills, Instructions, MCP-Abhngigkeiten und eine deklarative Empfehlung fr ein Agenten-Team. Ein Harness-spezifischer Adapter übersetzt diese Empfehlung in die lokale Team- und Modellkonfiguration. +## Harnesskonfiguration + -Fr oh-my-opencode-slim nenne ich diesen Adapter im Folgenden **`omos`**. +### Kann das nicht jemand anderes erledigen? + +Bevor es apt, yum oder pacman gab, war Software-Installation unter Unix vor allem eins: Handarbeit. Man lud sich den Quellcode als Tarball herunter, entpackte ihn irgendwo, konfigurierte, tippte make und hoffte auf das Beste. + +Bevor es Docker gab, war das Ausrollen von Software ein heilloses Durcheinander aus Versionskonflikten, fehlenden Bibliotheken und dem klassischen _„Runs on my Machine“_. + +Genau das machen wir heute mit Agenten-Frameworks. Wir kopieren Prompt-Templates per Hand in `.codex/` oder `.opencode/` Ordner, passen JSON-Dateien an und beten, dass das verwendete Modell die System-Prompts versteht. +Ein Package soll mehr sein als ein Ordner voller Prompts. Wenn ich ```apm install ``` ausführe, will ich nicht nur Dateien in `.opencode/` oder `.codex/` kopiert bekommen – ich will ein funktionierendes Setup, +das weiß, wie es arbeiten soll. Welche Rollen braucht diese Aufgabe? Welcher Agent recherchiert, welcher schreibt, welcher misstraut? Und welches Modell darf welche Rolle übernehmen, ohne dass ich das nach jeder Installation +von Hand in einer Config zurechtbastle? Kann ich nicht einfach einen ACP-Client meiner Wahl auf meinen Agenten richten und mich darauf verlassen, dass MCPs, Skills, Dependencies, Orchestrierung usw. mit dem Auschecken eines Pakets bereits erledigt sind? + +```mermaid +graph LR + subgraph Package Registry + A[Skills] --> B[Package] + C[Instructions] --> B + D[MCP-Abhängigkeiten] --> B + end + + subgraph Bridge + B -->|deklarative Empfehlung| E[Adapter] + end + + subgraph Harness + E --> F[Agenten-Team] + E --> G[Modellkonfiguration] + end + + style B fill:#f9f,stroke:#333 + style E fill:#bbf,stroke:#333 +``` +> Ein Package Registry liefert Skills, Instructions, MCP-Abhängigkeiten und eine deklarative Empfehlung für ein Agenten-Team. Ein Harness-spezifischer Adapter übersetzt diese Empfehlung in die lokale Team- und Modellkonfiguration. -`omos` ist dabei ein Design fr eine Erweiterung bzw. ein Sidecar-Tool. Es ist heute kein offiziell eingebautes APM-Target. ## Das Ökosystem heute + -Die vorhandenen Formate lassen sich grob in fnf Gruppen einteilen. +Der Agenten-Stack entwickelt sich gerade mit der Geschwindigkeit eines explodierenden Werkzeugschuppens. Jeden Monat erscheint ein neues Manifest, ein neues Plugin-Format oder eine neue Orchestrierungsebene. Alles löst einen legitimen Teil des Problems. Fast nichts passt nahtlos zusammen. +Das ist kein Vorwurf. Es ist der normale Zustand eines jungen Ökosystems. Der interessante Teil beginnt dort, wo die bestehenden Stücke bereits ausreichen, um eine sinnvolle Brücke zu bauen. -| Ebene | Beispiele | Zustndigkeit | + +Die vorhandenen Formate lassen sich grob in fünf Gruppen einteilen. + +| Ebene | Beispiele | Zuständigkeit | |---|---|---| -| Portable Komponenten | Agent Plugins | Skills und MCP-Server verteilen | -| Dependency Management | APM | Packages, Lockfile, Policies, Deployment | -| Team-Komposition | Spawnfile, Harness-Configs | Rollen, Delegation, Agentenbeziehungen | -| Runtime-Profile | oh-my-opencode-slim Presets | Modelle und Optionen je Agent | -| Governance | Agent Manifest | Identitt, Grenzen, Verantwortung, Auditierbarkeit | +| Portable Komponenten | [Agent Plugins](https://agent-plugins.org/) | Skills und MCP-Server verteilen | +| Dependency Management | [APM](https://microsoft.github.io/apm/) | Packages, Lockfile, Policies, Deployment | +| Team-Komposition | [Spawnfile](https://github.com/noopolis/spawnfile), Harness-Configs | Rollen, Delegation, Agentenbeziehungen | +| Runtime-Profile | [oh-my-opencode-slim Presets](https://ohmyopencodeslim.com/community-presets) | Modelle und Optionen je Agent | +| Governance | [Agent Manifest](https://agent-manifest-spec.org/) | Identität, Grenzen, Verantwortung, Auditierbarkeit | -Das Problem ist nicht fehlende Funktionalitt. Das Problem ist die Lcke zwischen diesen Schichten. +Was fehlt, ist ein allumfassendes YAML-Format. +## Ein paar Worte zu CrewAI +https://xkcd.com/927/ + +One Standard to rule them all? Ja genau das scheinen sich die Entwickler von [CrewAI](https://crewai.com/) gedacht zu haben und tatsächlich: "CrewAI is rapidly becoming the standard for production-ready agentic automation". So steht es jedenfalls auf ihrer Website wobei >50.000 GitHub Sterne zeigen, dass das Projekt durchaus über Momentum verfügt. +CrewAI löst die fehlende Standardisierung nicht durch Übersetzung zwischen Harnessen, sondern indem es die komplette Ausführungsschicht selbst besitzt: Agenten, Tasks, Tool-Aufrufe, State, Prozesse und Delegation laufen in der CrewAI-Runtime. + +Damit scheidet es für unsere weiteren Überlegungen allerdings aus, denn CrewAI integriert die Welt in eine Runtime und nicht umgekehrt. Unser Ziel ist ein Format zu finden, dessen Pakete sich in die vorhandene Welt integrieren. ### Agent Plugins - -Agent Plugins 1.0 definiert ein bewusst kleines, portables Plugin-Format. Im Kern enthlt ein Plugin eine `plugin.json` und kann Skills sowie MCP-Server bereitstellen. Erweiterungen sind mglich, mssen aber im `extensions`-Block ber einen Reverse-Domain-Namespace isoliert werden. - -Das ist sehr gut fr Interoperabilitt. Ein Skill bleibt ein Skill. Ein MCP bleibt ein MCP. Der Standard versucht nicht, die Laufzeit eines jeden Agentenframeworks zu regieren. - +[Agent Plugins 1.0](https://agent-plugins.org/) definiert ein bewusst kleines, portables Plugin-Format. Im Kern enthält ein Plugin eine `plugin.json` und kann Skills sowie MCP-Server bereitstellen. Erweiterungen sind möglich, müssen aber im `extensions`-Block über einen Reverse-Domain-Namespace isoliert werden. +Das ist sehr gut für Interoperabilität. Ein Skill bleibt ein Skill. Ein MCP bleibt ein MCP. Der Standard versucht nicht, die Laufzeit eines jeden Agentenframeworks zu regieren. Offen bleiben jedoch Dependencies, getestete Versionen, Teamrollen, Modellprofile und die Aktivierung im konkreten Harness. - ### APM - -APM besetzt die nchste Ebene: Package- und Dependency-Management fr Agent-Kontext. - -Ein APM-Manifest kann Abhngigkeiten auf andere APM-Packages, MCP-Server und LSP-Server beschreiben. APM verwaltet Auflsung, Lockfile und Installation. ber Targets kompiliert es Primitives in Harness-spezifische Dateien. Das native `opencode`-Target installiert Skills, Agents und Commands in die passenden `.opencode/`-Pfade. +[APM](https://microsoft.github.io/apm/) besetzt die nächste Ebene: Package- und Dependency-Management für Agent-Kontext. +Ein APM-Manifest kann Abhängigkeiten auf andere APM-Packages, MCP-Server und LSP-Server beschreiben. APM verwaltet Auflösung, Lockfile und Installation. Über Targets kompiliert es Primitives in Harness-spezifische Dateien. Das native `opencode`-Target installiert Skills, Agents und Commands in die passenden `.opencode/`-Pfade. ```yaml name: acme/research-assistant @@ -49,6 +102,7 @@ type: hybrid targets: - opencode + - omos dependencies: apm: @@ -61,54 +115,119 @@ dependencies: tools: [search_code, read_file] ``` -APM beantwortet damit: Welche Artefakte gehren zusammen? Welche Versionen wurden zusammen getestet? Welche MCPs werden bentigt? Wohin werden Skills und Instructions installiert? +APM beantwortet damit: Welche Artefakte gehören zusammen? Welche Versionen wurden zusammen getestet? Welche MCPs werden benötigt? Wohin werden Skills und Instructions installiert? Was APM aktuell nicht standardisiert beschreibt, ist Team-Semantik: Rollen, Delegation, Modell-Empfehlungen und Aktivierung eines Team-Profils. ### Spawnfile -Spawnfile adressiert die Teamachse. Agenten und Teams knnen deklarativ mit Rollen, Zustndigkeiten, Kommunikationswegen und Subagenten beschrieben werden. Die offene Stelle liegt bei Dependencies und Verteilung: Ein Team-Manifest installiert keine versionierten Skills, MCPs und Policies. +[Spawnfile](https://github.com/noopolis/spawnfile) adressiert die Teamachse. Agenten und Teams können deklarativ mit Rollen, Zuständigkeiten, Kommunikationswegen und Subagenten beschrieben werden. Die offene Stelle liegt bei Dependencies und Verteilung: Ein Team-Manifest installiert keine versionierten Skills, MCPs und Policies. Gültige Ziele sind momentan +Spawnfile v0.1 ist ausdrücklich für autonome, langlebige Agent-Runtimes gedacht. Spawnfile listet OpenCode als Runtime – aber mit Status exploratory: Kein Adapter, kein generiertes opencode.json, kein `.opencode/`. Tatsächlich wird in v0.1 für keine Runtime ein natives Team-Artifact compiliert; Teams degradieren immer zu Kontext-Dokumenten in Agent-Workspaces. -### oh-my-opencode-slim +### Oh My Opencode Slim + -oh-my-opencode-slim sitzt nahe an der Runtime. Sein Preset-System kann je Agent Modell, Temperatur, Variante und provider-spezifische Optionen umschalten. Presets werden ber `/preset ` whrend einer laufenden Session aktiviert. +## Die wilde Welt der Agent-Harnesses + +Wenn es um Multi-Agent-Orchestrierung geht, sieht die aktuelle Landschaft aus wie ein Experimentierfeld nach einem Chemieunfall. Jeder Harness hat seine eigene Vorstellung davon, wie Subagenten funktionieren sollten – und keine davon ist mit den anderen kompatibel. + +Claude Code kennt Custom Subagents als Markdown-Dateien und experimentiert mit Agententeams, bei denen mehrere Claude-Instanzen über eine gemeinsame Task-List kommunizieren. GitHub Copilot definiert Custom Agents als SDK-Konfiguration mit TypeScript oder Python und bietet Fleet Mode für parallele Ausführung. Codex setzt auf ein Coordinator-Pattern, bei dem ein Hauptagent Tasks an spezialisierte Subagents delegiert. oh-my-opencode-slim wiederum arbeitet mit Presets und Custom Agents, die zur Laufzeit umgeschaltet werden können. + +Das Ergebnis: Vier verschiedene Formate, vier verschiedene Delegationsmechanismen, vier verschiedene Wege, Modelle und MCPs pro Agent zu konfigurieren. Niemand hat sich auf ein gemeinsames Protokoll geeinigt. Jeder baut sein eigenes Ding. + +| Harness | Subagenten-Typ | Team-Unterstützung | Modell pro Agent | MCP pro Agent | Skill pro Agent | Delegation | +| ------------------- | ---------------------------- | ---------------------------------- | ----------------- | ---------------------- | ------------------- | ------------------------------- | +| oh-my-opencode-slim | Custom Agents + Built-in | ❌ Nein (nur Presets) | ✅ Ja (pro Preset) | ✅ Ja (mcps-Array) | ✅ Ja (skills-Array) | Automatisch via Orchestrator | +| Claude Code | Custom Subagents (.md-Files) | ✅ Ja (Agent Teams, experimental) | ✅ Ja (model-Feld) | ✅ Ja (mcpServers-Feld) | ✅ Ja (skills-Feld) | Automatisch + explizit | +| GitHub Copilot | Custom Agents (SDK) | ⚠️ Teilweise (Fleet Mode) | ✅ Ja (model-Feld) | ✅ Ja (mcpServers-Feld) | ✅ Ja (skills-Feld) | Automatisch via Intent-Matching | +| Codex | Multi-Agent V2 | ⚠️ Teilweise (Coordinator-Pattern) | ✅ Ja | ✅ Ja | ✅ Ja | Explizit via Coordinator | + +Genau dafür hat Microsofts [APM das targets-Feld](https://microsoft.github.io/apm/reference/targets-matrix/) vorgesehen. Es ist die ehrliche Antwort auf die Frage: „Wie deployen wir Agent-Kontext in eine Welt, in der jeder Harness seine eigenen Regeln hat?" Die Antwort lautet: Wir definieren Targets für jeden Harness und übersetzen das Package in das jeweilige Format. + +Oder, weniger diplomatisch: **Weil sich kein einziger der großen Player die Mühe gemacht hat, mit den anderen zu reden, bevor sie ihr Agenten-System gebaut haben, müssen wir jetzt für jeden von ihnen einen eigenen Übersetzer schreiben**. + +Claude Code macht es so. Copilot macht es anders. Codex hat wieder eine eigene Vorstellung. Und der Rest? Macht sein eigenes Ding. Das targets-Feld ist damit ein Eingeständnis: Niemand wird sich einigen. Also bauen wir Brücken zu allen. +Stand August 2026 sieht APM laut Schema folgende Werte als Ziele vor: `copilot`, `claude`, `grok-build`, `cursor`, `opencode`, `codex`, `gemini`, `antigravity`, `windsurf`, `kiro`, `agent-skills`. + +Damit klafft hier bereits die erste Lücke, denn **was fehlt, ist ein allumfassendes YAML-Format.** +Wir können also warten bis dieser Standard definiert ist, oder wir bauen uns selbst eine kleine Kompositionsschicht. Für Oh My Opencode Slim nenne ich diesen Adapter im Folgenden **`omos`**. `omos` ist dabei ein Design für eine Erweiterung bzw. ein Sidecar-Tool. Es ist heute kein offiziell eingebautes APM-Target. + +[//]: # () +[//]: # (```mermaid) + +[//]: # (flowchart LR) + +[//]: # ( AP[Skills und MCPs] -->|Agent Plugins| PK[Package-Inhalt]) + +[//]: # ( APM[Dependencies, Lockfile, Installation] -->|APM| PK) + +[//]: # ( SF[Rollen und Teamstruktur] -->|Spawnfile| TM[Team-Modell]) + +[//]: # ( PK -. fehlende Verbindung .-> TM) + +[//]: # (```) + +[//]: # () + + +```mermaid + +flowchart LR + + AP[Skills und MCPs] -->|Agent Plugins| PK[Package-Inhalt] + + APM[Dependencies, Lockfile, Installation] -->|APM| PK + + SF[Rollen und Teamstruktur] -->|Spawnfile/OMOS Community Presets| TM[Team-Modell] + + OMOS[oh-my-opencode-slim] -->|OMOS Community Presets| RT[aktive Runtime] + + PK -. fehlende Verbindung .-> TM + + TM -. fehlende Verbindung .-> RT + +``` + + +## Die APM-OMOS-Idee + +[Oh My Opencode Slim](https://ohmyopencodeslim.com/) ist ein schlankes, optimiertes Open-Source-Plugin für OpenCode, das auf Multi-Agenten-Orchestrierung ausgelegt ist und sitzt nahe an der Runtime. Sein Preset-System kann je Agent Modell, Temperatur, Variante und provider-spezifische Optionen setzen. Presets werden in der Config definiert und über den `/preset`-Befehl ausgewählt. ```jsonc { "presets": { "deep-review": { - "orchestrator": { "model": "provider/strong-generalist" }, - "oracle": { "model": "provider/high-reasoning", "variant": "thinking" }, - "librarian": { "model": "provider/fast-research" } + "orchestrator": { "model": "ollama/qwen3.6:35b-a3b-q4_K_M" }, + "oracle": { "model": "ollama/qwen3.6:35b-a3b-q4_K_M", "variant": "thinking" }, + "librarian": { "model": "ollama/qwen3.5:9b" } } } } ``` -Das beantwortet die Frage, wie unterschiedliche Rollen unterschiedliche Modellprofile erhalten. Es fehlt die Herkunft: Welches Package empfiehlt dieses Team? Welche Skills und MCPs gehren dazu? Welche Version wurde getestet? +[//]: # (Wichtig für das Verständnis, wie die Aktivierung tatsächlich funktioniert:) -## Die Lcke +[//]: # () +[//]: # (1. Der `/preset`-Befehl öffnet einen TUI-Manager. **Apply** schreibt ausschließlich den Namen des gewählten Presets in die Config-Datei.) -```mermaid -flowchart LR - AP[Agent Plugins] -->|Skills und MCPs| PK[Package-Inhalt] - APM[APM] -->|Dependencies, Lockfile, Installation| PK - SF[Spawnfile] -->|Rollen und Teamstruktur| TM[Team-Modell] - OMOS[oh-my-opencode-slim] -->|Presets, Modelle, Runtime-Switching| RT[aktive Runtime] - PK -. fehlende Verbindung .-> TM - TM -. fehlende Verbindung .-> RT -``` +[//]: # (2. Die Agent-Registry wird bewusst **nicht** mid-session umgeschaltet. Ein Hot-Swap würde Kontext truncieren, laufende Subagents auf veraltete Definitionen lassen und Tool-Verfügbarkeit verschieben.) -Die Lcke verlangt kein zehntes allumfassendes YAML-Format. Sie verlangt eine kleine Kompositionsschicht. +[//]: # (3. Erst nach einem **Reload von OpenCode** (oder dem Start einer neuen Konversation) greift das Preset.) -## Die APM-OMOS-Idee +[//]: # (4. Beim Laden angewendet werden `model`, `temperature`, `variant` und provider-spezifische `options`. Änderungen an `prompt`, `skills`, `mcps` oder `displayName` benötigen ohnehin einen Neustart.) -Ein APM-Package bleibt Source of Truth fr Skills, Instructions, MCP-Abhngigkeiten, Versionen, Dependency-Closure und Policies. Zusstzlich enthlt es ein Team-Profil als Empfehlung fr Harness-Adapter. +[//]: # () +[//]: # (Ein Neustart von opencode ist also by Design. Für Team-Wechsel zwischen Aufgaben ist das vollkommen ausreichend – und es hält die Runtime vorhersehbar.) + +Das beantwortet die Frage, wie unterschiedliche Rollen unterschiedliche Modellprofile erhalten. Es fehlt die Herkunft: Welches Package empfiehlt dieses Team? Welche Skills und MCPs gehören dazu? Welche Version wurde getestet? + + +Ein APM-Package bleibt Source of Truth für Skills, Instructions, MCP-Abhängigkeiten, Versionen, Dependency-Closure und Policies. Zusätzlich enthält es ein Team-Profil als Empfehlung für Harness-Adapter. ```yaml schema: acme.team-profile/v1 id: acme.document-research -description: Team-Profil fr Recherche, Erstellung und Qualittsprfung quellenbasierter Dokumente. +description: Team-Profil für Recherche, Erstellung und Qualitätsprüfung quellenbasierter Dokumente. roles: - id: orchestrator @@ -118,61 +237,63 @@ roles: purpose: Sammelt und bewertet Quellen model_class: fast-research capabilities: - mcps: [web-research, repository-search] + mcps: [websearch, openviking] skills: [job-matching] - id: writer - purpose: Erstellt strukturierte Dokumententwrfe + purpose: Erstellt strukturierte Dokumententwürfe model_class: strong-writing capabilities: - mcps: [document-write] + mcps: [sharelatex] skills: [application-writing] - id: checker - purpose: Prft Quellenbezug, Konsistenz und Vollstndigkeit + purpose: Prüft Quellenbezug, Konsistenz und Vollständigkeit model_class: high-reasoning capabilities: - mcps: [document-read] + mcps: [openviking] skills: [application-review] ``` -Das Profil verwendet Modellklassen wie `high-reasoning` statt konkreter Modell-IDs. Der Nutzer hinterlegt in einer lokalen Mapping-Tabelle, welche Modell-IDs fr welche Modellklasse verwendet werden sollen. +Das Profil verwendet Modellklassen wie `high-reasoning` statt konkreter Modell-IDs. Der Nutzer hinterlegt in einer lokalen Mapping-Tabelle, welche Modell-IDs für welche Modellklasse verwendet werden sollen. ```yaml # ~/.config/apm-team/model-mapping.yaml model_classes: - strong-generalist: anthropic/claude-sonnet-4-6 - fast-research: openai/gpt-5.4-mini - strong-writing: anthropic/claude-sonnet-4-6 - high-reasoning: openai/gpt-5.5 + strong-generalist: ollama/qwen3.6:35b-a3b-q4_K_M + fast-research: ollama/qwen3.5:9b + strong-writing: ollama/qwen3.6:35b-a3b-q4_K_M + high-reasoning: ollama/qwen3.6:35b-a3b-q4_K_M ``` +Diese Tabelle ist bewusst trivial. Sie ist kein intelligentes Routing und keine Policy-Engine. Der Nutzer entscheidet einmal, welches Modell seine Klasse „schnelle Recherche" oder „starkes Reasoning" erfüllt – und der Adapter übersetzt nur noch nach. + ## Was `omos` macht -`omos` ist der Übersetzer zwischen Team-Profil und oh-my-opencode-slim. Er liest installierte APM-Packages, findet Team-Profile, schlägt Modellklassen gegen die lokale Mapping-Tabelle nach und generiert namespacete Presets fr das Projekt. +`omos` ist der Übersetzer zwischen Team-Profil und oh-my-opencode-slim. Er liest installierte APM-Packages, findet Team-Profile, schlägt Modellklassen gegen die lokale Mapping-Tabelle nach und generiert Presets unter einem entsprechenden Namespace für das Projekt. ```mermaid flowchart TD P[APM Package: team-profile.yaml] --> O[omos liest] M[~/.config/apm-team/model-mapping.yaml] --> O - O -->|Prfe| X{Alle Modellklassen gemappt?} - X -->|Nein| E[Fehler: fehlendes Mapping fr Rolle Y] + O -->|Prüfe| X{Alle Modellklassen gemappt?} + X -->|Nein| E[Fehler: fehlendes Mapping für Rolle Y] X -->|Ja| G[Generiere OMOS-Preset mit konkreten Modell-IDs] - G --> V[Validiere: Modelle in OMOS verfgbar?] + G --> V[Validiere: Modelle in OMOS verfügbar?] V -->|Nein| F[Fehler: Modell Z nicht im OMOS-Setup] V -->|Ja| C[Schreibe .opencode/oh-my-opencode-slim.json] C --> D[Fertig] ``` -`omos` rtt nicht. Er übersetzt deterministisch: +`omos` rät nicht. Er übersetzt deterministisch: 1. Team-Profil lesen (Modellklassen + MCP/Skill-Capabilities). 2. Lokale Mapping-Tabelle laden (Modellklasse → konkrete Modell-ID). 3. OMOS-Preset generieren (konkrete Modell-IDs + MCP/Skill-Allowlists). -4. Validieren: Sind die Modelle im OMOS-Setup verfgbar? +4. Validieren: Sind die Modelle im OMOS-Setup verfügbar? 5. Preset in `.opencode/oh-my-opencode-slim.json` schreiben. ## Mehrere Packages, ein Projekt -Jedes Profil erhlt eine globale, stabile ID wie `acme.job-applications`, `acme.security-audit` oder `acme.code-review`. `omos` merged Presets anhand dieser IDs. Das aktive Team wird nicht durch die letzte Installation gewhlt. +Jedes Profil erhält eine globale, stabile ID wie `acme.job-applications`, `acme.security-audit` oder `acme.code-review`. `omos` merged Presets anhand dieser IDs. Das aktive Team wird nicht durch die letzte Installation gewählt. ```mermaid flowchart LR @@ -181,12 +302,19 @@ flowchart LR C[Package: Code Review] --> M M --> P[Projekt-Preset-Registry] P --> U[Nutzer oder expliziter Workflow] - U --> S[/preset acme-job-applications] + U --> S[/preset acme-job-applications + Reload] ``` ## Beispiel: Autobewerber als Team-Package -Ein Bewerbungsassistent eignet sich gut als Beispiel: Web-Recherche, personenbezogene Daten, Dokumentenproduktion, Qualittsprfung, Benachrichtigungen und externe Aktionen treffen zusammen. Der Mechanismus bleibt derselbe fr Code-Review, Sales Research, Compliance oder Incident Response. +Ein Bewerbungsassistent eignet sich gut als Beispiel, weil er alle Ebenen gleichzeitig berührt: Web-Recherche, personenbezogene Daten (das Kandidatenprofil), Dokumentenproduktion in LaTeX, Qualitätsprüfung und Benachrichtigungen. Der Mechanismus bleibt derselbe für Code-Review, Sales Research, Compliance oder Incident Response. + +Konkret arbeite ich hier mit einem real existierenden Setup: Das Package `job-application` bringt eine Skill für Stellenrecherche und maßgeschneiderte Bewerbungsunterlagen mit. Es nutzt zwei MCP-Server: + +- **OpenViking** als Langzeitgedächtnis für das Kandidatenprofil (Skills, Erfahrungen, persönliche Daten) +- **ShareLaTeX** zur Erstellung und Kompilierung der Anschreiben und Lebensläufe + +Dazu kommen OpenCodes native Tools für Web-Recherche (`websearch`, `webfetch`). ### Rollen und OMOS-Mapping @@ -195,52 +323,55 @@ Ein Bewerbungsassistent eignet sich gut als Beispiel: Web-Recherche, personenbez | Koordination | `orchestrator` | Zerlegt Aufgaben, delegiert, integriert | | Recherche | `librarian` (Alias `researcher`) | Sucht und bewertet Stellen | | Schreiben | Custom Agent `writer` | Erstellt Anschreiben und Unterlagen | -| Prfung | `oracle` (Alias `checker`) | Prft Fakten, Ton, Vollstndigkeit | +| Prüfung | `oracle` (Alias `checker`) | Prüft Fakten, Ton, Vollständigkeit | | Benachrichtigung | Custom Agent `notifier` | Informiert den Nutzer | -### Was OMOS tatschlich begrenzen kann +### Was OMOS tatsächlich begrenzen kann -OMOS bietet pro Agent zwei brauchbare Kontrollflchen: +OMOS bietet pro Agent zwei brauchbare Kontrollflächen: 1. **MCP-Zugriff** (`mcps`-Array) 2. **Skill-Zugriff** (`skills`-Array) -Beides kann je Agent in einem Preset als Allowlist formuliert werden. `[]` bedeutet keine Freigabe, `["!*"]` verweigert alles; bei Konflikten gewinnt die Verweigerung. +Beides kann je Agent in einem Preset als Allowlist formuliert werden. `[]` bedeutet keine Freigabe; bei Konflikten gewinnt die Verweigerung. + +Das generierte OMOS-Preset für unser Beispiel sieht dann so aus: ```jsonc { + "$schema": "https://unpkg.com/oh-my-opencode-slim@latest/oh-my-opencode-slim.schema.json", "presets": { "acme-job-applications": { "orchestrator": { - "model": "anthropic/claude-sonnet-4-6", + "model": "ollama/qwen3.6:35b-a3b-q4_K_M", "mcps": [], - "skills": ["job-orchestration"] + "skills": ["job-application"] }, "librarian": { "displayName": "researcher", - "model": "openai/gpt-5.4-mini", - "mcps": ["job-search", "candidate-profile-read"], - "skills": ["job-matching"] + "model": "ollama/qwen3.5:9b", + "mcps": ["websearch", "openviking"], + "skills": ["job-application"] }, "writer": { - "model": "anthropic/claude-sonnet-4-6", - "mcps": ["candidate-profile-read", "overleaf"], - "skills": ["application-writing"] + "model": "ollama/qwen3.6:35b-a3b-q4_K_M", + "mcps": ["openviking", "sharelatex"], + "skills": [] }, "oracle": { "displayName": "checker", - "model": "openai/gpt-5.5", - "variant": "high", - "mcps": ["candidate-profile-read", "overleaf"], - "skills": ["application-review"] + "model": "ollama/qwen3.6:35b-a3b-q4_K_M", + "variant": "thinking", + "mcps": ["openviking"], + "skills": [] }, "notifier": { - "model": "openai/gpt-5.4-mini", - "mcps": ["notification-draft"], + "model": "ollama/gemma4:12b", + "mcps": [], "skills": [] } } @@ -248,24 +379,24 @@ Beides kann je Agent in einem Preset als Allowlist formuliert werden. `[]` bedeu } ``` -Damit erhlt der Researcher keinen Overleaf-Zugang. Der Writer sieht keine Job-Suchtools. Der Notifier bekommt keinen Browser und keinen Schreibzugriff auf die Bewerbung. +Damit erhält der Researcher keinen ShareLaTeX-Zugang. Der Writer sieht keine Job-Suchtools, darf aber auf Profilfakten zugreifen und in ShareLaTeX arbeiten. Der Checker kann Fakten gegen das Profil prüfen, aber nichts produzieren oder senden. Der Notifier bekommt gar keine externen Zugriffe. -### Die wichtige Einschrnkung +### Die wichtige Einschränkung -`mcps` und `skills` schtzen nur den Zugriff auf genau diese zwei Ebenen. Die Aussage „der Agent darf niemals eine Bewerbung absenden" bentigt Verteidigung in mehreren Schichten: +`mcps` und `skills` schützen nur den Zugriff auf genau diese zwei Ebenen. Die Aussage „der Agent darf niemals eine Bewerbung absenden" benötigt Verteidigung in mehreren Schichten: | Schicht | Durchsetzung | |---|---| | OMOS-Rollenprompt | Klare Verhaltensregel: nie einreichen | -| OMOS MCP-Allowlist | `application-submit` MCP gar nicht zuweisen | +| OMOS MCP-Allowlist | Submission-MCP gar nicht zuweisen | | MCP-Server selbst | Submission-Tool verlangt Approval-Token | | Workflow-State | `submit` nur aus Zustand `user_approved` erlaubt | | OpenCode-/Sandbox-Policy | Schreib-, Shell- und Browserrechte begrenzen | -| User Interface | Explizite, sichtbare Freigabe vor jeder Auenwirkung | +| User Interface | Explizite, sichtbare Freigabe vor jeder Außenwirkung | -Die echte Autorisierungsgrenze muss am **MCP beziehungsweise Backend** liegen. Ein Prompt ist eine Verhaltensanweisung. Eine MCP-Allowlist ist Capability Scoping. Ein Server, der ohne gltiges Freigabe-Token keine Submission annimmt, ist die harte Grenze. +In unserem Beispiel existiert der Submission-Schritt schlicht nicht: Der Workflow endet bei kompilierten ShareLaTeX-Projekten und Projektlinks für den Nutzer. Die Bewerbung wird vom Menschen selbst abgeschickt. Damit ist die härteste Grenze bereits durch Architektur gezogen – nicht durch Prompt-Hoffnung. -Fr deinen Use Case wrde ich den Notification-MCP so schneiden: +Sobald man automatisches Absenden möchte (z. B. über ein Bewerbungsportal), braucht es einen eigenen Submission-MCP mit Approval-Token: ```text notification-draft → darf Entwurf erzeugen @@ -283,8 +414,8 @@ sequenceDiagram participant S as Submission MCP C->>N: createDraftNotification(applicationDraftId) - N-->>U: Stelle gefunden, Entwurf geprft - U->>U: Prft PDF und Fakten + N-->>U: Stelle gefunden, Entwurf geprüft + U->>U: Prüft PDF und Fakten U->>S: approve(applicationDraftId) S-->>S: issue userApprovalId U->>S: submit(applicationDraftId, userApprovalId) @@ -298,7 +429,7 @@ Der Notifier kann dann technisch niemals eine Bewerbung absenden, weil er keinen ```yaml schema: acme.team-profile/v1 id: acme.job-applications -description: Human-in-the-loop-Team zur Recherche, Vorbereitung und Prfung individueller Bewerbungsunterlagen. +description: Human-in-the-loop-Team zur Recherche, Vorbereitung und Prüfung individueller Bewerbungsunterlagen. roles: - id: orchestrator @@ -306,34 +437,38 @@ roles: model_class: strong-generalist capabilities: mcps: [] - skills: [job-orchestration] + skills: [job-application] - id: researcher - purpose: Sucht und bewertet Stellenausschreibungen + purpose: Sucht und bewertet Stellenausschreibungen gegen das Kandidatenprofil + omos_agent: librarian model_class: fast-research capabilities: - mcps: [job-search, candidate-profile-read] - skills: [job-matching] + mcps: [websearch, webfetch, openviking] + skills: [job-application] - id: writer - purpose: Erstellt auf Fakten basierende Anschreiben + purpose: Erstellt auf Fakten basierende Anschreiben und Lebensläufe in ShareLaTeX + omos_agent: custom model_class: strong-writing capabilities: - mcps: [candidate-profile-read, overleaf] - skills: [application-writing] + mcps: [openviking, sharelatex] + skills: [] - id: checker - purpose: Prft Fakten, Ton und Vollstndigkeit + purpose: Prüft Fakten, Ton und Vollständigkeit gegen das Profil + omos_agent: oracle model_class: high-reasoning capabilities: - mcps: [candidate-profile-read, overleaf] - skills: [application-review] + mcps: [openviking] + skills: [] - id: notifier - purpose: Informiert den Nutzer ber geprfte Entwrfe + purpose: Informiert den Nutzer über fertige Entwürfe + omos_agent: custom model_class: cheap-reliable capabilities: - mcps: [notification-draft] + mcps: [] skills: [] ``` @@ -342,112 +477,69 @@ Die lokale Mapping-Tabelle: ```yaml # ~/.config/apm-team/model-mapping.yaml model_classes: - strong-generalist: anthropic/claude-sonnet-4-6 - fast-research: openai/gpt-5.4-mini - strong-writing: anthropic/claude-sonnet-4-6 - high-reasoning: openai/gpt-5.5 - cheap-reliable: openai/gpt-5.4-mini + strong-generalist: ollama/qwen3.6:35b-a3b-q4_K_M + fast-research: ollama/qwen3.5:9b + strong-writing: ollama/qwen3.6:35b-a3b-q4_K_M + high-reasoning: ollama/qwen3.6:35b-a3b-q4_K_M + cheap-reliable: ollama/gemma4:12b ``` -Das generierte OMOS-Preset: +Das generierte OMOS-Preset wurde oben bereits gezeigt. Die Aktivierung läuft dann so: -```jsonc -{ - "presets": { - "acme-job-applications": { - "orchestrator": { - "model": "anthropic/claude-sonnet-4-6", - "mcps": [], - "skills": ["job-orchestration"] - }, - "librarian": { - "displayName": "researcher", - "model": "openai/gpt-5.4-mini", - "mcps": ["job-search", "candidate-profile-read"], - "skills": ["job-matching"] - }, - "writer": { - "model": "anthropic/claude-sonnet-4-6", - "mcps": ["candidate-profile-read", "overleaf"], - "skills": ["application-writing"] - }, - "oracle": { - "displayName": "checker", - "model": "openai/gpt-5.5", - "variant": "high", - "mcps": ["candidate-profile-read", "overleaf"], - "skills": ["application-review"] - }, - "notifier": { - "model": "openai/gpt-5.4-mini", - "mcps": ["notification-draft"], - "skills": [] - } - } - } -} +```bash +apm install tbi/APM-Packages +omos render --harness omos # schreibt .opencode/oh-my-opencode-slim.json +opencode # Start lädt die Projekt-Config ``` -Das Ganze lsst sich ber ein OMOS-Preset aktivieren: +Im TUI: ```text /preset acme-job-applications +# Apply → schreibt Preset-Namen in die Config +# Reload OpenCode → Team ist aktiv ``` -Der Nutzer erhlt danach keine unsichtbare Bewerbungsmaschine. Er erhlt ein explizit aktiviertes, nachvollziehbares Team mit klaren Zustndigkeiten. +Der Nutzer erhält danach keine unsichtbare Bewerbungsmaschine. Er erhält ein explizit aktiviertes, nachvollziehbares Team mit klaren Zuständigkeiten. ## Wie das heute beginnen kann -Die Idee muss nicht auf eine APM-Spec-nderung warten. +Die Idee muss nicht auf eine APM-Spec-Änderung warten. Ein erster Prototyp braucht nur drei Bausteine: -1. **Ein normales APM-Package** - Skills, Instructions und MCP-Abhngigkeiten werden ber APM installiert. +1. **Ein normales APM-Package** + Skills, Instructions und MCP-Abhängigkeiten werden über APM installiert. -2. **Ein Team-Profil als zustzliche Package-Datei** +2. **Ein Team-Profil als zusätzliche Package-Datei** Zum Beispiel `team-profile.yaml`, mit versioniertem Schema und eindeutiger ID. -3. **Ein `omos` Sidecar-CLI** +3. **Ein `omos` Sidecar-CLI** Es liest die installierten Packages, generiert namespacete OMOS-Presets und validiert Konflikte. -Der Ablauf wre: +APM selbst muss dafür zunächst keine unbekannten Targets akzeptieren. Tatsächlich kennt das aktuelle Manifest nur einen festen Satz dokumentierter Targets; unbekannte Zielnamen führen zu einem Fehler. -```bash -apm install acme/job-application-team -apm-team render --harness omos -opencode -``` - -Dann: - -```text -/preset acme-job-applications -``` - -APM selbst muss dafr zunchst keine unbekannten Targets akzeptieren. Tatschlich kennt das aktuelle Manifest nur einen festen Satz dokumentierter Targets; unbekannte Zielnamen fhren zu einem Fehler. - -Das Sidecar ist daher der pragmatische Anfang. Es kann als externes Tool reifen, Daten ber realistische Nutzung liefern und spter als offizieller APM-Adapter oder als Erweiterung im APM-Ö´kosystem landen. +Das Sidecar ist daher der pragmatische Anfang. Es kann als externes Tool reifen, Daten über realistische Nutzung liefern und später als offizieller APM-Adapter oder als Erweiterung im APM-Ökosystem landen. ## Der Kern Die Idee lautet nicht: „APM wird jetzt ein Multi-Agent-Framework." -APM soll sein, was es gut kann: Package-Management fr Agent-Kontext. +APM soll sein, was es gut kann: Package-Management für Agent-Kontext. oh-my-opencode-slim soll sein, was es gut kann: konkrete Rollen, Modelle und Laufzeit-Presets verwalten. -Dazwischen liegt ein kleines, wertvolles Stck Infrastruktur: +Dazwischen liegt ein kleines, wertvolles Stück Infrastruktur: -> Ein APM-Package beschreibt nicht nur, welche Fhigkeiten installiert werden. Es kann auch erklren, welches Team diese Fhigkeiten sinnvoll verwendet. +> Ein APM-Package beschreibt nicht nur, welche Fähigkeiten installiert werden. Es kann auch erklären, welches Team diese Fähigkeiten sinnvoll verwendet. Damit wird ein Package vom Ordner voller Skills zu einem reproduzierbaren Arbeitsmodell: - versionierte Rollen; -- berprfbare Tool-Zugriffe; +- überprüfbare Tool-Zugriffe; - lokale Modell-Policies; - mehrere Teams pro Projekt; - explizite Aktivierung; - menschliche Freigabe an kritischen Grenzen. -Und das ist wesentlich ntzlicher als ein weiterer „autonomer Agent", der nach drei Minuten Browserzugriff beschliet, dass er nun Personalabteilung spielen darf. \ No newline at end of file +Und das ist wesentlich nützlicher als ein weiterer „autonomer Agent", der nach drei Minuten Browserzugriff beschließt, dass er nun Personalabteilung spielen darf. diff --git a/blog-review.md b/blog-review.md new file mode 100644 index 0000000..5114c61 --- /dev/null +++ b/blog-review.md @@ -0,0 +1,581 @@ +# Blog-Draft Review – Source of Truth + Änderungsvorschläge + +> **Aufbau dieser Datei:** Teil 1 = aktueller Stand des Ghost-Blogposts (Source of Truth, kopiert von https://blog.corentic.eu/p/fe4a29af-7a76-4e59-8264-016a8ea0c60e/). Teil 2 = meine Änderungsvorschläge basierend auf dem Perplexity-Fact-Check. Wir gehen Vorschlag für Vorschlag durch und entscheiden. + +--- + +# TEIL 1: Aktueller Blogstand (Source of Truth) + +# APM, Agent-Teams und das kleine Problem namens Realität + +**Wie APM-Packages um Agent Team-Empfehlungen erweitert werden können – mit Oh-my-Opencode-slim als erstem konkretem Target.** + +*(Bild: SNES-Cartridge „Tour Planer Agent 3000")* + +Ein Austauschformat so selbsterklärend wie in die Videospiele der 90er. Einfach Einlegen und Abspielen. Aktuell hat diese Vision mit der Realität des AI-Agenten-Ökosystems wenig zu tun. Nur die Gefahr des Vendor-Lock-Ins bleibt bestehen. +Heute beginnt das Abenteuer zunächst als Textadventure. + +> Was willst du tun? (Instruktionen) +> +> Wie soll es erledigt werden? (Skills) +> +> Womit soll es erledigt werden? (Werkzeuge, MCP-Abhängigkeiten) +> +> Wie soll das Agenten-Team zusammengesetzt sein? +> +> Welche Modellkonfiguration sollen die Agenten erhalten? (Modell, Variante, Temperature, … pro Subagent) +> +> Welche Untermenge der Werkzeuge erhalten die jeweiligen Agenten? (MCPs pro Subagent) +> +> Welches Orchestrierungsmuster soll verwendet werden? + +Was folgt, ist der klassische *programmer Move*: Man automatisiert (mittlerweile AI-unterstützt) in nur 10 Stunden erfolgreich eine Aufgabe die man händisch in 10 Minuten hätte erledigen können. + +Selbstverständlich ist all das praktisch nicht portabel, denn will man seinen mühsam definierten Workflow mit Freunden und Kollegen teilen, dann muss alles passen. Welcher Harness? Welche Modelle? Sind sie verfügbar und falls nein, kann ich sie substituieren? ... + +Dies mag zwar der eigenen Arbeitsplatzsicherheit kurzfristig nützen, aber aus technischer Sicht ist der aktuelle Zustand dennoch unbefriedigend. + +## Harnesskonfiguration + +*(Bild: Homer)* + +### Kann das nicht jemand anderes erledigen? + +Bevor es Docker gab, war das Ausrollen von Software ein heilloses Durcheinander aus Versionskonflikten, fehlenden Bibliotheken und dem klassischen _„Runs on my Machine"_. + +Bevor es apt, yum oder pacman gab, war Software-Installation unter Unix vor allem eins: Handarbeit. Man lud sich den Quellcode als Tarball herunter, entpackte ihn irgendwo, konfigurierte, tippte make und hoffte auf das Beste. + +Genau das machen wir heute mit Agenten-Frameworks. Wir kopieren Prompt-Templates per Hand in `.codex/` oder `.opencode/` Ordner, passen JSON-Dateien an und beten, dass das verwendete Modell die System-Prompts versteht. +Ein Package soll mehr sein als ein Ordner voller Prompts. Wenn ich `apm install ` ausführe, will ich nicht nur Dateien in `.opencode/` oder `.codex/` kopiert bekommen – ich will ein funktionierendes Setup, das weiß, wie es arbeiten soll. Welche Rollen braucht diese Aufgabe? Welcher Agent recherchiert, welcher schreibt, welcher misstraut? Und welches Modell darf welche Rolle übernehmen, ohne dass ich das nach jeder Installation von Hand in einer Config zurechtbasteln muss? Kann ich nicht einfach einen ACP-Client meiner Wahl auf meinen Agenten richten und mich darauf verlassen, dass MCPs, Skills, Dependencies, Orchestrierung usw. mit dem Pull eines Pakets bereits erledigt sind? + +```mermaid +graph LR + subgraph Package Registry + A[Skills] --> B[Package] + C[Instructions] --> B + D[MCP-Abhängigkeiten] --> B + end + + subgraph Bridge + B -->|deklarative Empfehlung| E[Adapter] + end + + subgraph Harness + E --> F[Agenten-Team] + E --> G[Modellkonfiguration] + end + + style B fill:#f9f,stroke:#333 + style E fill:#bbf,stroke:#333 +``` + +> Ein Package Registry liefert Skills, Instructions, MCP-Abhängigkeiten und eine deklarative Empfehlung für ein Agenten-Team. Ein Harness-spezifischer Adapter übersetzt diese Empfehlung in die lokale Team- und Modellkonfiguration. + +## Das Ökosystem heute + +Der Agenten-Stack entwickelt sich gerade mit der Geschwindigkeit eines explodierenden Werkzeugschuppens. Jeden Monat erscheint ein neues Manifest, ein neues Plugin-Format oder eine neue Orchestrierungsebene. Alles löst einen legitimen Teil des Problems. Fast nichts passt nahtlos zusammen. +Das ist kein Vorwurf. Es ist der normale Zustand eines jungen Ökosystems. Der interessante Teil beginnt dort, wo die bestehenden Stücke bereits ausreichen, um eine sinnvolle Brücke zu bauen. + +Die vorhandenen Formate lassen sich grob in fünf Gruppen einteilen. + +| Ebene | Beispiele | Zuständigkeit | +|---|---|---| +| Portable Komponenten | [Agent Plugins](https://agent-plugins.org/) | Skills und MCP-Server verteilen | +| Dependency Management | [APM](https://microsoft.github.io/apm/) | Packages, Lockfile, Policies, Deployment | +| Team-Komposition | [Spawnfile](https://github.com/noopolis/spawnfile), Harness-Configs | Rollen, Delegation, Agentenbeziehungen | +| Runtime-Profile | [oh-my-opencode-slim Presets](https://ohmyopencodeslim.com/community-presets), [Roo Code custom models](https://roocodeinc.github.io/Roo-Code/features/custom-modes/) | Modelle und Optionen je Agent | +| Governance | [Agent Manifest](https://agent-manifest-spec.org/) | Identität, Grenzen, Verantwortung, Auditierbarkeit | + +Was fehlt, ist ein allumfassendes YAML-Format. + +## Ein paar Worte zu CrewAI + +One Standard to rule them all? Ja genau das scheinen sich die Entwickler von [CrewAI](https://crewai.com/) gedacht zu haben und tatsächlich: "CrewAI is rapidly becoming the standard for production-ready agentic automation". So steht es jedenfalls auf ihrer Website wobei über 50.000 GitHub Sterne zeigen, dass das Projekt durchaus über Momentum verfügt. +CrewAI löst die fehlende Standardisierung nicht durch Übersetzung zwischen Harnessen, sondern indem es die komplette Ausführungsschicht selbst besitzt: Agenten, Tasks, Tool-Aufrufe, State, Prozesse und Delegation laufen in der CrewAI-Runtime. + +Damit scheidet es für unsere weiteren Überlegungen allerdings aus, denn CrewAI integriert die Welt in eine Runtime und nicht umgekehrt. Unser Ziel ist ein Format zu finden, dessen Pakete sich in die vorhandene Welt integrieren. + +### Agent Plugins für portable Komponenten + +[Agent Plugins 1.0](https://agent-plugins.org/) definiert ein bewusst kleines, portables Plugin-Format. Im Kern enthält ein Plugin eine `plugin.json` und kann Skills sowie MCP-Server bereitstellen. Erweiterungen sind möglich, müssen aber im `extensions`-Block über einen Reverse-Domain-Namespace isoliert werden. +Das ist sehr gut für Interoperabilität. Ein Skill bleibt ein Skill. Ein MCP bleibt ein MCP. Der Standard versucht nicht, die Laufzeit eines jeden Agentenframeworks zu regieren. +Offen bleiben jedoch Dependencies, getestete Versionen, Teamrollen, Modellprofile und die Aktivierung im konkreten Harness. + +### APM Dependency Management + +[APM](https://microsoft.github.io/apm/) besetzt die nächste Ebene: Package- und Dependency-Management für Agent-Kontext. +Ein [APM-Manifest](https://microsoft.github.io/apm/reference/manifest-schema/) kann Abhängigkeiten auf andere APM-Packages, MCP-Server und LSP-Server beschreiben. APM verwaltet Auflösung, Lockfile und Installation. Über Targets kompiliert es Primitives in harnessspezifische Dateien. Das native `opencode`-Target installiert beispielsweise Skills, Agents und Commands in die passenden `.opencode/`-Pfade. + +```yaml +name: acme/research-assistant +version: 1.0.0 +type: hybrid + +targets: + - opencode + - omos + +dependencies: + apm: + - acme/base-engineering + mcp: + - name: repository-search + registry: false + transport: stdio + command: repository-search-mcp + tools: [search_code, read_file] +``` + +*Ein APM-Manifest* + +APM beantwortet damit: Welche Artefakte gehören zusammen? Welche Versionen wurden zusammen getestet? Welche MCPs werden benötigt? Wohin werden Skills und Instructions installiert? + +Was APM aktuell nicht standardisiert beschreibt, ist Team-Semantik: Rollen, Delegation, Modell-Empfehlungen und Aktivierung eines Team-Profils. + +### Spawnfile + +[Spawnfile](https://github.com/noopolis/spawnfile) adressiert die Teamachse. Agenten und Teams können deklarativ mit Rollen, Zuständigkeiten, Kommunikationswegen und Subagenten beschrieben werden. Die offene Stelle liegt bei Dependencies und Verteilung: Ein Team-Manifest installiert keine versionierten Skills, MCPs und Policies. Gültige Ziele sind momentan ggfdfjfdgv +Spawnfile v0.1 ist ausdrücklich für autonome, langlebige Agent-Runtimes gedacht. OpenCode wird als Runtime gelistet, allerding mit Status exploratory: Kein Adapter, kein generiertes `opencode.json`. Tatsächlich wird in v0.1 für keine Runtime ein natives Team-Artifact compiliert; Teams degradieren immer zu Kontext-Dokumenten in Agent-Workspaces. + +Insgesamt ein sehr junges Projekt bei dem sich noch zeigen wird, ob eine separate Teamdeklarationsschicht sich durchsetzen wird. + +### Oh My Opencode Slim + +## Die wilde Welt der Agent-Harnesses + +Wenn es um Multi-Agent-Orchestrierung geht, sieht die aktuelle Landschaft aus wie ein Experimentierfeld nach einem Chemieunfall. Jeder Harness hat seine eigene Vorstellung davon, wie Subagenten funktionieren sollten – und keine davon ist mit den anderen kompatibel. + +Claude Code kennt Custom Subagents als Markdown-Dateien und experimentiert mit Agententeams, bei denen mehrere Claude-Instanzen über eine gemeinsame Task-List kommunizieren. GitHub Copilot definiert Custom Agents als SDK-Konfiguration mit TypeScript oder Python und bietet Fleet Mode für parallele Ausführung. Codex setzt auf ein Coordinator-Pattern, bei dem ein Hauptagent Tasks an spezialisierte Subagents delegiert. Oh-my-Opencode-slim wiederum arbeitet mit Presets und Custom Agents, die zur Laufzeit umgeschaltet werden können. + +Das Ergebnis: Vier verschiedene Formate, vier verschiedene Delegationsmechanismen, vier verschiedene Wege, Modelle und MCPs pro Agent zu konfigurieren. Niemand hat sich auf ein gemeinsames Protokoll geeinigt. Jeder baut sein eigenes Ding. + +| Harness | Subagenten-Typ | Team-Unterstützung | Delegation | +|---|---|---|---| +| oh-my-opencode-slim | Custom Agents + Built-in (7 Spezialisten) | ✅ Ja (Hub-and-Spoke Team) | Automatisch (Background) + Explizit (via `@agent`) | +| Claude Code | Custom Subagents (.md-Files) | ✅ Ja (Agent Teams, experimental) | Automatisch + explizit | +| GitHub Copilot | Custom Agents (SDK) | ⚠️ Teilweise (Fleet Mode) | Automatisch via Intent-Matching | +| Codex | Multi-Agent V2 | ⚠️ Teilweise (Coordinator-Pattern) | Explizit via Coordinator | + +Genau dafür hat Microsofts [APM das targets-Feld](https://microsoft.github.io/apm/reference/targets-matrix/) vorgesehen. Es ist die ehrliche Antwort auf die Frage: „Wie deployen wir Agent-Kontext in eine Welt, in der jeder Harness seine eigenen Regeln hat?" Die Antwort lautet: Wir definieren Targets für jeden Harness und übersetzen das Package in das jeweilige Format. + +Oder, weniger diplomatisch: **Weil sich kein einziger der großen Player die Mühe gemacht hat, mit den anderen zu reden, bevor sie ihr Agenten-System gebaut haben, müssen wir jetzt für jeden von ihnen einen eigenen Übersetzer schreiben**. + +Claude Code macht es so. Copilot macht es anders. Codex hat wieder eine eigene Vorstellung. Und der Rest? Macht sein eigenes Ding. Das targets-Feld ist damit ein Eingeständnis: Niemand wird sich einigen. Also bauen wir Brücken zu allen. +Stand August 2026 sieht APM laut Schema folgende Werte als Ziele vor: `copilot`, `claude`, `grok-build`, `cursor`, `opencode`, `codex`, `gemini`, `antigravity`, `windsurf`, `kiro`, `agent-skills`. + +Damit klafft hier bereits die erste Lücke, denn **was fehlt, ist ein allumfassendes YAML-Format.** +Wir können also warten bis dieser Standard eines Tages definiert ist, oder wir bauen uns selbst eine kleine Kompositionsschicht. Für Oh-my-Opencode-slim nenne ich diesen Adapter im Folgenden `omos`. `omos` ist dabei ein Design für eine Erweiterung bzw. ein Sidecar-Tool. Es ist heute kein offiziell eingebautes APM-Target. + +Hier ist der detaillierte Deep Dive in die Orchestrierungs-Modelle. Wenn man unter die Haube schaut, offenbaren sich fundamentale Unterschiede darin, **wie** die Arbeit verteilt wird, **wer** die Kontrolle behält und **wie** du als Entwickler den Prozess überwachst. + +### Vergleich der Multi-Agent-Orchestrierung - Die 4 großen Paradigmen der Orchestrierung + +#### 1. Die Agentur: Asynchrone Spezialisten (`oh-my-opencode-slim`) + +Dieses Modell funktioniert wie eine echte Entwickler-Agentur. Der Orchestrator ist dein Projektmanager. Wenn du ein Dashboard in einer fremden Codebase anfragst, blockiert er dich nicht mit Ladebalken. Stattdessen schickt er den `Explorer` los, um die Auth-Pattern zu mappen, während der `Librarian` die Dokumentation aus einer Kontextdatenbank lädt. Da das System asynchron läuft, kannst man sich währenddessen weiter mit dem Orchestrator unterhalten. Das `@council` ist hier eine Besonderheit: Es feuert eine Frage parallel an mehrere _unterschiedliche_ LLMs (z. B. GPT-4o, Claude 3.5 und Gemini) und zwingt sie, einen Konsens zu finden. + +#### 2. Das Kanban-Board: Task-Pulling (`Claude Code Agent Teams`) + +Anthropic nutzt für seine Agent Teams ein "Pull-Modell", das an ein Kanban-Board erinnert. Der Lead-Agent analysiert das Problem und schreibt eine Liste mit Aufgaben (inklusive Abhängigkeiten). Sobald ein Subagent hochfährt, schaut er auf die Liste, markiert eine Aufgabe als "in progress" und arbeitet sie ab. Das ist extrem mächtig für Fleißarbeiten (wie "Schreibe Tests für jedes Modul"), skaliert aber auf UI-Ebene manchmal schlecht, da man schnell den Überblick verliert, welcher Agent gerade in welchem Tmux-Pane festhängt. + +#### 3. Der Schwarm: File-basiertes Dispatching (`Copilot /fleet`) + +Copilot wählt mit dem `/fleet`-Kommando einen pragmatischen, stark Code-zentrierten Ansatz. Der Orchestrator analysiert nicht zwingend konzeptionelle Rollen, sondern zerlegt die Arbeit primär nach Dateien und Modulen. Wenn du eine API refactorst, feuert der Orchestrator eine "Welle" von Agenten auf die Controller ab, wartet, bis diese fertig sind, und schickt dann die nächste Welle auf die dazugehörigen Test-Dateien. Die Agenten kommunizieren hier nicht untereinander; der Orchestrator baut am Ende alles zusammen. + +#### 4. Die Pipeline: Handoff-Orchestrierung (`Codex Multi-Agent V2`) + +Dieses Modell funktioniert nicht wie eine wuselige Agentur oder ein paralleler Schwarm, sondern eher wie ein **Staffellauf** oder ein streng getaktetes Fließband. Codex setzt in seinem Multi-Agent V2 Setup stark auf das sogenannte Coordinator-Pattern. + +Anstatt Aufgaben gleichzeitig an viele Agenten zu verteilen, orchestriert der Meta-Agent (Coordinator) einen sequenziellen, strikt kontrollierten Workflow. + +- **Die Mechanik (Context Passing):** Der Coordinator hält den übergeordneten Status des Tasks. Wenn du ein neues Feature anfragst, aktiviert er Agent A (z. B. für das Schema-Design). Erst wenn Agent A _komplett fertig_ ist, nimmt der Coordinator dessen Ergebnis, packt es isoliert in den neuen Kontext und reicht den Staffelstab an Agent B (z. B. für die API-Routen) weiter. +- **Kontrolle statt Chaos:** Die Agenten arbeiten hier in der Regel nicht asynchron und parallel an denselben oder benachbarten Systemen. Der Handoff (die Übergabe) ist explizit programmiert und wird vom Coordinator überwacht. +- **Zentrale Sichtbarkeit:** Der gesamte Prozess läuft zentralisiert ab. Alles passiert transparent in deinem primären Chat-Stream, was das Debugging im Vergleich zu versteckten Hintergrund-Prozessen oder verteilten Tmux-Panes erheblich erleichtert. + +**Der Trade-off:** Was Codex durch dieses Handoff-Pattern an Stabilität, Vorhersagbarkeit und Fehlervermeidung (keine Race-Conditions auf Dateiebene) gewinnt, opfert es bei der reinen Geschwindigkeit. Während `oh-my-opencode-slim` Forschungs- und Programmieraufgaben gleichzeitig erledigen kann, wartet bei Codex der nächste Agent in der Kette zwingend auf den Abschluss seines Vorgängers. + +**Vergleichstabelle:** + +| Feature | oh-my-opencode-slim | Claude Code (Agent Teams) | GitHub Copilot CLI (/fleet) | Codex (Multi-Agent V2) | +|---|---|---|---|---| +| Architektur-Pattern | **Hub-and-Spoke:** Orchestrator steuert 7 spezialisierte Agenten (Explorer, Fixer, Council etc.) | **Orchestrator-Worker:** Ein Lead-Agent verwaltet dynamisch erzeugte "Teammates" | **Dispatcher-Modell:** Zentraler Orchestrator feuert Sub-Agenten auf Dateisystem-Ebene ab | **Coordinator:** Ein Meta-Agent reicht den Kontext an nachgelagerte Agenten weiter | +| Orchestrierungs-Flow | **Async Push:** Orchestrator plant, delegiert im Hintergrund und bleibt im Main-Chat reaktiv | **Task-Pull:** Orchestrator erstellt eine geteilte Task-Liste; Worker "claimen" freie Tasks | **Synchronous Push:** Orchestrator zerlegt Tasks nach Abhängigkeiten und pusht sie in Wellen an Agenten | **Handoff:** Explizite Übergabe von State und Kontext an den nächsten Agenten | +| Parallelität | **Sehr hoch:** Spezialisten arbeiten parallel (z. B. `Librarian` liest Docs, während `Fixer` Code schreibt) | **Hoch:** Mehrere Worker bearbeiten unabhängige Sub-Tasks aus der Liste | **Hoch:** Stark optimiert für parallele Datei-Operationen im Workspace | **Niedrig:** Meist sequenzielle Abarbeitung oder enge Bündelung | +| Spezialisierung | Fixes Team mit zugewiesenen Rollen und optimalen Modellen (z. B. billiges Modell für Code-Search, teures für Architektur) | Teammates sind primär identische Klone des Orchestrators, die isolierte Kontexte erhalten | Sub-Agenten sind Instanzen des Basis-Modells, spezialisiert durch den zugewiesenen Pfad/Kontext | Custom Agents, die je nach Workspace-Rolle definiert werden | +| Sichtbarkeit / UX | **Multiplexer-Nativ:** Öffnet Agenten live in Tmux, Zellij oder Kitty-Panes. Main-Prompt bleibt frei | **CLI / Tmux:** Worker laufen in eigenen Sessions. Kann bei vielen Sub-Tasks schnell zu "Pane-Cluttering" führen | **CLI-Polling:** Hintergrundausführung mit Fortschrittsanzeige im Terminal ("Welle 1 beendet") | **Zentral:** Alles passiert im primären Chat-Stream | +| Stärken | Komplexe Architektur-Refactorings, parallele Research- & Coding-Tasks | Massive, kleinteilige Fleißarbeiten (z. B. Unit-Tests für 50 Files schreiben) | Schnelles "Suchen & Ersetzen" oder Refactorn über viele Dateien hinweg | Geführte, streng kontrollierte Workflows | + +## Die APM-OMOS-Idee + +Oh my Opencode slim erweitert den Harness um einen Multi-Agent-Orchestrator + +[Oh my Opencode slim](https://ohmyopencodeslim.com/) ist ein schlankes, optimiertes Open-Source-Plugin für OpenCode, das auf Multi-Agenten-Orchestrierung ausgelegt ist und sitzt als Plugin naturgemäß nahe an der Runtime. Sein Preset-System kann je Agent Modell, Temperatur, Variante und providerspezifische Optionen setzen. Presets werden in der Config definiert und über den `/preset`-Befehl ausgewählt. + +*(Community-Preset created by alexandru – Beispiel-JSON mit orchestrator, oracle, council, librarian, explorer, designer, fixer)* + +Das beantwortet die Frage, wie unterschiedliche Rollen unterschiedliche Modellprofile erhalten. Es fehlt die Herkunft: Welches Package empfiehlt dieses Team? Welche Skills und MCPs gehören dazu? Welche Version wurde getestet? + +Ein APM-Package bleibt Source of Truth für Skills, Instructions, MCP-Abhängigkeiten, Versionen, Dependency-Closure und Policies. Zusätzlich enthält es ein Team-Profil als Empfehlung für Harness-Adapter. + +```yaml +schema: acme.team-profile/v1 +id: acme.document-research +description: Team-Profil für Recherche, Erstellung und Qualitätsprüfung quellenbasierter Dokumente. + +roles: + - id: orchestrator + purpose: Zerlegt Aufgaben, delegiert, integriert Ergebnisse + model_class: strong-generalist + - id: researcher + purpose: Sammelt und bewertet Quellen + model_class: fast-research + capabilities: + mcps: [websearch, openviking] + skills: [job-matching] + - id: writer + purpose: Erstellt strukturierte Dokumententwürfe + model_class: strong-writing + capabilities: + mcps: [overleaf] + skills: [application-writing] + - id: checker + purpose: Prüft Quellenbezug, Konsistenz und Vollständigkeit + model_class: high-reasoning + capabilities: + mcps: [openviking] + skills: [application-review] +``` + +### Ein paar Handgriffe verbleiben + +Das Profil verwendet Modellklassen wie `high-reasoning` statt konkreter Modell-IDs. Der Nutzer hinterlegt in einer lokalen Mapping-Tabelle, welche Modell-IDs für welche Modellklasse verwendet werden sollen. + +```yaml +# ~/.config/apm-team/model-mapping.yaml +model_classes: + strong-generalist: ollama/qwen3.6:35b-a3b-q4_K_M + fast-research: ollama/qwen3.5:9b + strong-writing: ollama/qwen3.6:35b-a3b-q4_K_M + high-reasoning: ollama/qwen3.6:35b-a3b-q4_K_M +``` + +Diese Tabelle ist bewusst trivial. Sie ist kein intelligentes Routing und keine Policy-Engine. Der Nutzer entscheidet einmal, welches Modell seine Klasse „schnelle Recherche" oder „starkes Reasoning" erfüllt – und der Adapter übersetzt nur noch nach. + +## Was `omos` macht + +`omos` ist der Übersetzer zwischen Team-Profil und oh-my-opencode-slim. Er liest installierte APM-Packages, findet Team-Profile, schlägt Modellklassen gegen die lokale Mapping-Tabelle nach und generiert Presets unter einem entsprechenden Namespace für das Projekt. + +`omos` übersetzt deterministisch: + +1. Team-Profil lesen (Modellklassen + MCP/Skill-Capabilities). +2. Lokale Mapping-Tabelle laden (Modellklasse → konkrete Modell-ID). +3. OMOS-Preset generieren (konkrete Modell-IDs + MCP/Skill-Allowlists). +4. Validieren: Sind die Modelle im OMOS-Setup verfügbar? +5. Preset in `.opencode/oh-my-opencode-slim.json` schreiben. + +## Mehrere Packages, ein Projekt + +Jedes Profil erhält eine globale, stabile ID wie `acme.job-applications`, `acme.security-audit` oder `acme.code-review`. `omos` merged Presets anhand dieser IDs. Das aktive Team wird nicht durch die letzte Installation gewählt. + +## Beispiel: Autobewerber als Team-Package + +Ein Bewerbungsassistent eignet sich gut als Beispiel, weil er alle Ebenen gleichzeitig berührt: Web-Recherche, personenbezogene Daten (das Kandidatenprofil), Dokumentenproduktion in LaTeX, Qualitätsprüfung und Benachrichtigungen. Der Mechanismus bleibt derselbe für Code-Review, Sales Research, Compliance oder Incident Response. + +Konkret arbeite ich hier mit einem real existierenden Setup: Das Package `job-application` bringt eine Skill für Stellenrecherche und maßgeschneiderte Bewerbungsunterlagen mit. Es nutzt die beiden MCP-Server für OpenViking und Overleaf. + +**OpenViking** als Langzeitgedächtnis für das Kandidatenprofil (Skills, Erfahrungen, persönliche Daten) + +**Overleaf** zur Erstellung und Kompilierung der Anschreiben und Lebensläufe + +Dazu kommen OpenCodeunds native Tools für Web-Recherche (`websearch`, `webfetch`). + +### Rollen und OMOS-Mapping + +| Fachliche Rolle | OMOS-Rolle | Zweck | +|---|---|---| +| Koordination | `orchestrator` | Zerlegt Aufgaben, delegiert, integriert | +| Recherche | `librarian` (Alias `researcher`) | Sucht und bewertet Stellen | +| Schreiben | Custom Agent `writer` | Erstellt Anschreiben und Unterlagen | +| Prüfung | `oracle` (Alias `checker`) | Prüft Fakten, Ton, Vollständigkeit | +| Benachrichtigung | Custom Agent `notifier` | Informiert den Nutzer | + +### Was OMOS tatsächlich begrenzen kann + +OMOS bietet pro Agent zwei brauchbare Kontrollflächen: + +1. **MCP-Zugriff** (`mcps`-Array) +2. **Skill-Zugriff** (`skills`-Array) + +Beides kann je Agent in einem Preset als Allowlist formuliert werden. `[]` bedeutet keine Freigabe; bei Konflikten gewinnt die Verweigerung. + +Das generierte OMOS-Preset für unser Beispiel sieht dann so aus: + +```jsonc +{ + "$schema": "https://unpkg.com/oh-my-opencode-slim@latest/oh-my-opencode-slim.schema.json", + "presets": { + "acme-job-applications": { + "orchestrator": { + "model": "ollama/qwen3.6:35b-a3b-q4_K_M", + "mcps": [], + "skills": ["job-application"] + }, + + "librarian": { + "displayName": "researcher", + "model": "ollama/qwen3.5:9b", + "mcps": ["websearch", "openviking"], + "skills": ["job-application"] + }, + + "writer": { + "model": "ollama/qwen3.6:35b-a3b-q4_K_M", + "mcps": ["openviking", "sharelatex"], + "skills": [] + }, + + "oracle": { + "displayName": "checker", + "model": "ollama/qwen3.6:35b-a3b-q4_K_M", + "variant": "thinking", + "mcps": ["openviking"], + "skills": [] + }, + + "notifier": { + "model": "ollama/gemma4:12b", + "mcps": [], + "skills": [] + } + } + } +} +``` + +Damit erhält der Researcher keinen ShareLaTeX-Zugang. Der Writer sieht keine Job-Suchtools, darf aber auf Profilfakten zugreifen und in ShareLaTeX arbeiten. Der Checker kann Fakten gegen das Profil prüfen, aber nichts produzieren oder senden. Der Notifier bekommt gar keine externen Zugriffe. + +### Die wichtige Einschränkung + +`mcps` und `skills` schützen nur den Zugriff auf genau diese zwei Ebenen. Die Aussage „der Agent darf niemals eine Bewerbung absenden" benötigt Verteidigung in mehreren Schichten: + +| Schicht | Durchsetzung | +|---|---| +| OMOS-Rollenprompt | Klare Verhaltensregel: nie einreichen | +| OMOS MCP-Allowlist | Submission-MCP gar nicht zuweisen | +| MCP-Server selbst | Submission-Tool verlangt Approval-Token | +| Workflow-State | `submit` nur aus Zustand `user_approved` erlaubt | +| OpenCode-/Sandbox-Policy | Schreib-, Shell- und Browserrechte begrenzen | +| User Interface | Explizite, sichtbare Freigabe vor jeder Außenwirkung | + +In unserem Beispiel existiert der Submission-Schritt schlicht nicht: Der Workflow endet bei kompilierten ShareLaTeX-Projekten und Projektlinks für den Nutzer. Die Bewerbung wird vom Menschen selbst abgeschickt. Damit ist die härteste Grenze bereits durch Architektur gezogen – nicht durch Prompt-Hoffnung. + +Sobald man automatisches Absenden möchte (z. B. über ein Bewerbungsportal), braucht es einen eigenen Submission-MCP mit Approval-Token: + +```text +notification-draft → darf Entwurf erzeugen +notification-send → braucht userApprovalId +application-submit → braucht userApprovalId + applicationDraftId +``` + +Und im Backend: + +```mermaid +sequenceDiagram + participant C as Checker + participant N as Notifier MCP + participant U as Nutzer + participant S as Submission MCP + + C->>N: createDraftNotification(applicationDraftId) + N-->>U: Stelle gefunden, Entwurf geprüft + U->>U: Prüft PDF und Fakten + U->>S: approve(applicationDraftId) + S-->>S: issue userApprovalId + U->>S: submit(applicationDraftId, userApprovalId) + S-->>U: Bewerbung eingereicht +``` + +Der Notifier kann dann technisch niemals eine Bewerbung absenden, weil er keinen Submission-MCP besitzt und das Submission-Backend einen vom Nutzer stammenden Freigabenachweis verlangt. + +### Das Team-Profil + +```yaml +schema: acme.team-profile/v1 +id: acme.job-applications +description: Human-in-the-loop-Team zur Recherche, Vorbereitung und Prüfung individueller Bewerbungsunterlagen. + +roles: + - id: orchestrator + purpose: Zerlegt Aufgaben, delegiert, integriert Ergebnisse + model_class: strong-generalist + capabilities: + mcps: [] + skills: [job-application] + + - id: researcher + purpose: Sucht und bewertet Stellenausschreibungen gegen das Kandidatenprofil + omos_agent: librarian + model_class: fast-research + capabilities: + mcps: [websearch, webfetch, openviking] + skills: [job-application] + + - id: writer + purpose: Erstellt auf Fakten basierende Anschreiben und Lebensläufe in ShareLaTeX + omos_agent: custom + model_class: strong-writing + capabilities: + mcps: [openviking, sharelatex] + skills: [] + + - id: checker + purpose: Prüft Fakten, Ton und Vollständigkeit gegen das Profil + omos_agent: oracle + model_class: high-reasoning + capabilities: + mcps: [openviking] + skills: [] + + - id: notifier + purpose: Informiert den Nutzer über fertige Entwürfe + omos_agent: custom + model_class: cheap-reliable + capabilities: + mcps: [] + skills: [] +``` + +Die lokale Mapping-Tabelle: + +```yaml +# ~/.config/apm-team/model-mapping.yaml +model_classes: + strong-generalist: ollama/qwen3.6:35b-a3b-q4_K_M + fast-research: ollama/qwen3.5:9b + strong-writing: ollama/qwen3.6:35b-a3b-q4_K_M + high-reasoning: ollama/qwen3.6:35b-a3b-q4_K_M + cheap-reliable: ollama/gemma4:12b +``` + +Das generierte OMOS-Preset wurde oben bereits gezeigt. Die Aktivierung läuft dann so: + +```bash +apm install tbi/APM-Packages +omos render --harness omos # schreibt .opencode/oh-my-opencode-slim.json +opencode # Start lädt die Projekt-Config +``` + +Im TUI: + +```text +/preset acme-job-applications +# Apply → schreibt Preset-Namen in die Config +# Reload OpenCode → Team ist aktiv +``` + +Der Nutzer erhält danach keine unsichtbare Bewerbungsmaschine. Er erhält ein explizit aktiviertes, nachvollziehbares Team mit klaren Zuständigkeiten. + +## Wie das heute beginnen kann + +Die Idee muss nicht auf eine APM-Spec-Änderung warten. + +Ein erster Prototyp braucht nur drei Bausteine: + +1. **Ein normales APM-Package** + Skills, Instructions und MCP-Abhängigkeiten werden über APM installiert. + +2. **Ein Team-Profil als zusätzliche Package-Datei** + Zum Beispiel `team-profile.yaml`, mit versioniertem Schema und eindeutiger ID. + +3. **Ein `omos` Sidecar-CLI** + Es liest die installierten Packages, generiert namespacete OMOS-Presets und validiert Konflikte. + +APM selbst muss dafür zunächst keine unbekannten Targets akzeptieren. Tatsächlich kennt das aktuelle Manifest nur einen festen Satz dokumentierter Targets; unbekannte Zielnamen führen zu einem Fehler. + +Das Sidecar ist daher der pragmatische Anfang. Es kann als externes Tool reifen, Daten über realistische Nutzung liefern und später als offizieller APM-Adapter oder als Erweiterung im APM-Ökosystem landen. + +## Der Kern + +Die Idee lautet nicht: „APM wird jetzt ein Multi-Agent-Framework." + +APM soll sein, was es gut kann: Package-Management für Agent-Kontext. + +Oh-my-Opencode-slim soll sein, was es gut kann: konkrete Rollen, Modelle und Laufzeit-Presets verwalten. + +Dazwischen liegt ein kleines, wertvolles Stück Infrastruktur: + +> Ein APM-Package beschreibt nicht nur, welche Fähigkeiten installiert werden. Es kann auch erklären, welches Team diese Fähigkeiten sinnvoll verwendet. + +Damit wird ein Package vom Ordner voller Skills zu einem reproduzierbaren Arbeitsmodell: + +- versionierte Rollen; +- überprüfbare Tool-Zugriffe; +- lokale Modell-Policies; +- mehrere Teams pro Projekt; +- explizite Aktivierung; +- menschliche Freigabe an kritischen Grenzen. + +Und das ist wesentlich nützlicher als ein weiterer „autonomer Agent", der nach drei Minuten Browserzugriff beschließt, dass er nun Personalabteilung spielen darf. + +--- +--- + +# TEIL 2: Änderungsvorschläge (nacheinander durchgehen) + +Quelle: Perplexity-Fact-Check vom 23.08.2026 (`https___blog.corentic.eu_ghost_#_editor_post_6a89e.md`) + eigene Review. + +## Status-Liste + +| # | Vorschlag | Kategorie | Entscheidung | +|---|---|---|---| +| R1 | Placeholder-Rest „ggfdfjfdgv" im Spawnfile-Absatz entfernen/schreiben | Bugfix | ☐ offen | +| R2 | Tippfehler „allerding" → „allerdings" | Bugfix | ☐ offen | +| R3 | Tippfehler „OpenCodeunds" → „OpenCodes" | Bugfix | ☐ offen | +| R4 | ShareLaTeX vs. Overleaf konsistent machen (Text sagt Overleaf, Preset nutzt sharelatex, Repo heißt sharelatex) | Konsistenz | ☐ offen | +| R5 | Leere Sektion „### Oh My Opencode Slim" füllen oder entfernen | Struktur | ☐ offen | +| R6 | APM-Targetliste vervollständigen + versionsabhängig referenzieren | Fact-Check | ☐ offen | +| R7 | LSP-Server-Behauptung in APM-Absatz belegen oder streichen | Fact-Check | ☐ offen | +| R8 | Agent-Plugins-Absatz: primäre Quelle (Spec) verlinken | Fact-Check | ☐ offen | +| R9 | Spawnfile-OpenCode-Formulierung präzisieren („derzeit kein gebündelter Adapter", exploratory) | Fact-Check | ☐ offen | +| R10 | Copilot-/fleet-Absatz: „Wave"-Dispatching und „kommunizieren nicht untereinander" durch dokumentierte Beschreibung ersetzen | Fact-Check | ☐ offen | +| R11 | **Codex-Absatz komplett neu schreiben**: Codex unterstützt parallele Subagenten; Handoff ist mögliches Design, kein Laufzeitmodell | Fact-Check (größte Korrektur) | ☐ offen | +| R12 | Vergleichstabelle Codex-Spalte korrigieren (Parallelität, Sichtbarkeit) | Fact-Check | ☐ offen | +| R13 | Claude Code: „Kanban" als Metapher kennzeichnen | Fact-Check | ☐ offen | +| R14 | Disclaimer vor erstem omos-Codeblock: „vorgeschlagenes Adapterformat, keine Referenzimplementierung" | Fact-Check | ☐ offen | +| R15 | `omos render --harness omos` als Design-Syntax markieren | Fact-Check | ☐ offen | +| R16 | `schema: acme.team-profile/v1` als projektspezifischen Vorschlag kennzeichnen | Fact-Check | ☐ offen | +| R17 | JSON-Block prüfen (gültiges JSON, öffnende Klammern) | Bugfix | ☐ offen | +| R18 | Checker-Aussage einschränken: „nichts produzieren oder senden … über die dort konfigurierten MCPs und Skills hinaus" | Präzision | ☐ offen | +| R19 | `.opencode/oh-my-opencode-slim.json` Pfad verifizieren (projektlokal vs. global) | Verifikation | ☐ offen | + +## Detailbeschreibungen + +~~### R1 – Placeholder-Rest +Im Spawnfile-Absatz steht: „…installiert keine versionierten Skills, MCPs und Policies. Gültige Ziele sind momentan ggfdfjfdgv" +→ Satzfragment löschen. Optional ersetzen durch: „Gültige Ziele sind momentan OpenClaw, PicoClaw und Pi."~~ Done + +### R6 – APM-Targetliste +~~Aktuell: „copilot, claude, grok-build, cursor, opencode, codex, gemini, antigravity, windsurf, kiro, agent-skills" +→ Empfohlene Fassung: „Die zulässigen Targets sind versionsabhängig. Die aktuelle Schema-Referenz nennt unter anderem `agents`, `copilot`, `claude`, `cursor`, `opencode`, `codex`, `gemini`, `antigravity`, `windsurf`, `kiro`, `vscode` und `all`." + Link auf Manifest-Schema.~~ +Done + +### R11 – Codex-Absatz neu schreiben +Ersatzfassung laut Fact-Check: +> „Codex unterstützt sowohl parallele Subagent-Workflows als auch explizite Handoffs. +> Ein Coordinator-Pattern mit artefaktgebundenen Übergaben ist ein sinnvoller, +> kontrollierter Entwurf für abhängige Arbeitsschritte, aber kein zwingendes Codex-Laufzeitmodell." +Zu streichende Aussagen: „setzt stark auf das Coordinator-Pattern", „nicht asynchron und parallel", „Parallelität: niedrig", „alles passiert transparent im primären Chat-Stream". + +### R10 – Copilot-/fleet-Absatz +Ersatzfassung: +> „Copilot CLI `/fleet` zerlegt einen Implementierungsplan in unabhängige Teilaufgaben. Ein Orchestrator verwaltet Abhängigkeiten und führt geeignete Subagenten parallel aus; die Koordination nutzt expliziten Todo-Zustand statt implizitem Shared Memory." +Satz „Die Agenten kommunizieren hier nicht untereinander" streichen. + +### R14 – Disclaimer +Direkt vor dem ersten team-profile-Codeblock (Abschnitt „Die APM-OMOS-Idee"): +> „Die folgenden YAML- und JSON-Beispiele sind ein vorgeschlagenes Adapterformat, keine APM- oder OMOS-Referenzimplementierung." + +### R9 – Spawnfile-Formulierung +Ersatzfassung: +> „Spawnfile v0.1 besitzt derzeit keinen gebündelten OpenCode-Adapter. OpenCode wird als explorativer Runtime-Kandidat geführt; ein natives OpenCode-Artefakt wird daher aktuell nicht erzeugt." +Zusätzlich (aus unserer Code-Analyse): In v0.1 implementiert kein Adapter `compileTeam()` – Teams degradieren überall zu Kontext-Dokumenten. diff --git a/homer.jpg b/homer.jpg new file mode 100644 index 0000000..be710fd Binary files /dev/null and b/homer.jpg differ diff --git a/incompatible.jpg b/incompatible.jpg new file mode 100644 index 0000000..e3ad4c5 Binary files /dev/null and b/incompatible.jpg differ diff --git a/oh-my-opencode-slim.png b/oh-my-opencode-slim.png new file mode 100644 index 0000000..3633e89 Binary files /dev/null and b/oh-my-opencode-slim.png differ diff --git a/omos-deep-dive.md b/omos-deep-dive.md new file mode 100644 index 0000000..1199bb5 --- /dev/null +++ b/omos-deep-dive.md @@ -0,0 +1,256 @@ +# Was oh-my-opencode-slim wirklich kann – und was `omos` daraus machen sollte + +*Von Modell-IDs bis Sandboxing: Die OMOS-Konfiguration ist mächtiger, als man denkt.* + +Im ersten Teil haben wir beschrieben, wie ein APM-Package sein empfohlenes Team deklarieren kann. Dort haben wir `omos` als Übersetzer zwischen `team-profile.yaml` und OMOS-Presets vorgestellt – und dabei nur zwei Konfigurationsflächen genutzt: Modell-IDs und MCP/Skill-Allowlists. + +Das war bewusst minimal. Aber OMOS kann deutlich mehr. Und `omos` sollte das nutzen. + +## Was OMOS alles kann + +Die vollständige Konfiguration von oh-my-opencode-slim geht weit über Presets hinaus. Hier die wichtigsten Features, die für Team-Pakete relevant sind: + +### Custom Agents mit eigenen Prompts + +OMOS kann unter `agents` eigene Subagenten definieren. Jeder braucht ein `model`, einen `prompt` und optional einen `orchestratorPrompt`, der dem Orchestrator sagt, wann er delegieren soll: + +```jsonc +{ + "agents": { + "writer": { + "model": "ollama/qwen3.6:35b-a3b-q4_K_M", + "prompt": "Erstelle faktenbasierte Bewerbungsunterlagen. " + + "Nutze nur freigegebene Profilfakten. " + + "Erfinde keine Erfahrung. " + + "Lege Entwürfe in ShareLaTeX ab. " + + "Reiche niemals eine Bewerbung ein.", + "orchestratorPrompt": "@writer\n" + + "- Rolle: Anschreiben und CV-Anpassungen erstellen\n" + + "- Delegiere nach qualifiziertem Stellen-Match\n" + + "- Liefere einen ShareLaTeX-Entwurf und offene Fragen" + } + } +} +``` + +Der `orchestratorPrompt` ist der Schlüssel: Er wird direkt in den Orchestrator-Prompt injiziert und bestimmt, **wann** der Orchestrator diesen Agenten aufruft. Ohne ihn weiß der Orchestrator nicht, dass es den Agenten gibt. + +### Tool-Permissions: Echte Sandboxing + +OMOS bietet pro Agent ein `permission`-Objekt, das auf Tool-Ebene durchgesetzt wird – nicht nur MCP-Allowlists, sondern auch OpenCode-Core-Tools: + +```jsonc +{ + "agents": { + "researcher": { + "model": "ollama/qwen3.5:9b", + "permission": { + "edit": "deny", + "bash": "deny", + "task": "deny", + "webfetch": "allow", + "websearch": "allow" + } + } + } +} +``` + +Das ist eine **echte Sandbox**. Der Researcher darf suchen und lesen, aber keine Dateien bearbeiten, keine Shell-Befehle ausführen und keine Subagenten spawnen. Das geht über `mcps` und `skills` hinaus und ist das, was wir im ersten Blogpost als „mehrere Schichten der Verteidigung" beschrieben haben. + +Verfügbare Permission-Keys: + +| Key | Was es kontrolliert | +|-----|-------------------| +| `read` | Dateien lesen | +| `edit` | Dateien bearbeiten | +| `bash` | Shell-Befehle ausführen | +| `task` | Subagenten delegieren | +| `webfetch` | Web-Inhalte abrufen | +| `websearch` | Websuche | +| `glob` | Dateisuche nach Pattern | +| `grep` | Inhaltsuche | +| `skill` | Skill-Ausführung | + +Jeder Key akzeptiert `"allow"`, `"deny"` oder `"ask"` (fragt den Nutzer). Für `bash` gibt es zusätzlich Pattern-basierte Regeln: + +```jsonc +"bash": { + "*": "deny", + "git status*": "allow", + "git diff*": "allow" +} +``` + +### Fallback-Ketten + +OMOS unterstützt Modell-Failover bei 429-Errors (Rate Limiting). In der Mapping-Tabelle könnte man das so abbilden: + +```yaml +# ~/.config/apm-team/model-mapping.yaml +model_classes: + fast-research: + primary: ollama/qwen3.5:9b + fallback: + - openai/gpt-4o-mini +``` + +`omos` würde daraus ein OMOS-Array generieren: + +```jsonc +"librarian": { + "model": ["ollama/qwen3.5:9b", "openai/gpt-4o-mini"] +} +``` + +OMOS versucht das erste Modell und wechselt bei Fehlern automatisch zum nächsten. + +### Prompt-Dateien statt Inline-Prompts + +Statt lange Prompts inline in die Config zu schreiben, kann man sie als Markdown-Dateien ablegen: + +``` +.opencode/oh-my-opencode-slim/ + ├── acme-job-applications/ + │ ├── writer.md # Preset-spezifisch + │ └── researcher.md + └── writer.md # Fallback für alle Presets +``` + +Die Lookup-Reihenfolge ist: +1. `.opencode/oh-my-opencode-slim//.md` (projektspezifisch, preset-spezifisch) +2. `.opencode/oh-my-opencode-slim/.md` (projektspezifisch, preset-übergreifend) +3. `~/.config/opencode/oh-my-opencode-slim//.md` (global, preset-spezifisch) +4. `~/.config/opencode/oh-my-opencode-slim/.md` (global, preset-übergreifend) + +`omos` könnte die `purpose`-Felder aus dem Team-Profil in solche Dateien schreiben – versionierbar im Package, geteilt über Presets. + +### Weitere relevante Features + +| Feature | OMOS-Feld | Nutzen für Teams | +|---------|-----------|-----------------| +| **Council** | `council.presets` | Mehrere Modelle parallel für kritische Entscheidungen (z.B. Checker) | +| **ACP Agents** | `acpAgents.` | Externe Agent-CLIs (Claude Code, Gemini) als Subagent einbinden | +| **Multiplexer** | `multiplexer.type` | tmux/zellij-Panes für Live-Beobachtung arbeitender Agenten | +| **displayName** | `displayName` | Alias für den Orchestrator (bereits im ersten Blogpost genutzt) | +| **description** | `description` | Beschreibung, die dem Orchestrator bei der Routing-Entscheidung hilft | +| **disabled_agents** | `disabled_agents[]` | Agenten global deaktivieren (z.B. Observer) | +| **Background Jobs** | `backgroundJobs.*` | Orchestrator-Wake, Wall-Timeout für Hintergrundaufgaben | + +## Was `omos` daraus machen sollte + +Im ersten Blogpost haben wir `omos` als Übersetzer von Modellklassen und MCP-Allowlists beschrieben. Das war Phase 1. Hier ist, was Phase 2 und 3 aussehen: + +### Phase 2: Custom Agents + Permissions + +`omos` liest das Team-Profil und generiert für jeden Custom Agent (also jeden, der nicht auf einen eingebauten OMOS-Agenten mapped) einen vollständigen Agent-Block: + +**Input** (team-profile.yaml): +```yaml +- id: writer + purpose: Erstellt auf Fakten basierende Anschreiben und Lebensläufe in ShareLaTeX. + Nutze nur freigegebene Profilfakten. Erfinde keine Erfahrung. + omos_agent: custom + model_class: strong-writing + capabilities: + mcps: [openviking, sharelatex] + skills: [] + permissions: + edit: deny + bash: deny + task: deny +``` + +**Output** (OMOS-Preset): +```jsonc +"writer": { + "model": "ollama/qwen3.6:35b-a3b-q4_K_M", + "prompt": "Erstellt auf Fakten basierende Anschreiben und Lebensläufe in ShareLaTeX. Nutze nur freigegebene Profilfakten. Erfinde keine Erfahrung.", + "orchestratorPrompt": "@writer\n- Rolle: Anschreiben und CV erstellen\n- Delegiere nach qualifiziertem Stellen-Match", + "mcps": ["openviking", "sharelatex"], + "skills": [], + "permission": { + "edit": "deny", + "bash": "deny", + "task": "deny" + } +} +``` + +### Phase 3: Prompt-Dateien + Fallback + Council + +`omos` schreibt zusätzlich: +- `.opencode/oh-my-opencode-slim/acme-job-applications/writer.md` mit dem vollständigen Prompt +- Fallback-Ketten aus der Mapping-Tabelle +- Optional: Council-Preset für den Checker (zwei Modelle parallel prüfen lassen) + +## Die erweiterte Mapping-Tabelle + +Für Phase 2 und 3 wird die Mapping-Tabelle reichhaltiger: + +```yaml +# ~/.config/apm-team/model-mapping.yaml +model_classes: + strong-generalist: + primary: ollama/qwen3.6:35b-a3b-q4_K_M + fallback: + - openai/gpt-4o-mini + + fast-research: + primary: ollama/qwen3.5:9b + fallback: + - openai/gpt-4o-mini + + strong-writing: + primary: ollama/qwen3.6:35b-a3b-q4_K_M + + high-reasoning: + primary: ollama/qwen3.6:35b-a3b-q4_K_M + variant: thinking + options: + thinking: + type: enabled + budgetTokens: 10000 + + cheap-reliable: + primary: ollama/gemma4:12b +``` + +`omos` übersetzt das deterministisch: +- `primary` → erstes Modell im Array +- `fallback` → weitere Einträge im Array +- `variant` → wird direkt übernommen +- `options` → wird direkt übernommen + +## Was das für den Blogpost-Workflow bedeutet + +Der erweiterte Flow sieht so aus: + +```mermaid +flowchart TD + P[APM Package: team-profile.yaml] --> O[omos liest] + M[~/.config/apm-team/model-mapping.yaml] --> O + O -->|Modellklassen| G[Generiere OMOS-Preset] + O -->|purpose-Felder| PR[Generiere Prompt-Dateien] + O -->|permissions| PE[Generiere Permission-Objekte] + O -->|fallback| FB[Generiere Fallback-Ketten] + G --> C[Schreibe .opencode/oh-my-opencode-slim.json] + PR --> C + PE --> C + FB --> C + C --> D[Fertig] +``` + +## Fazit + +OMOS ist nicht nur ein Preset-Switcher. Es ist ein vollständiges Agent-Konfigurationssystem mit Custom Prompts, Tool-Permissions, Fallback-Ketten und Multi-Model-Synthese. `omos` als Adapter sollte diese Möglichkeiten nutzen – nicht nur Modell-IDs übersetzen. + +Die drei Phasen: + +| Phase | Was omos generiert | OMOS-Features | +|-------|-------------------|---------------| +| **1** | Modell-IDs + MCP/Skill-Allowlists | `presets...model`, `mcps`, `skills` | +| **2** | + Custom Prompts + Permissions | `agents..prompt`, `orchestratorPrompt`, `permission` | +| **3** | + Fallback-Ketten + Prompt-Dateien + Council | `model[]`, `.md`-Dateien, `council.presets` | + +Phase 1 ist der Minimalprototyp. Phase 2 macht die Agenten wirklich arbeitsfähig. Phase 3 macht sie resilient. diff --git a/skilldependencygraph.png b/skilldependencygraph.png new file mode 100644 index 0000000..a38472b Binary files /dev/null and b/skilldependencygraph.png differ diff --git a/snes.jpg b/snes.jpg new file mode 100644 index 0000000..383ed35 Binary files /dev/null and b/snes.jpg differ diff --git a/standards_2x.png b/standards_2x.png new file mode 100644 index 0000000..e04c4b6 Binary files /dev/null and b/standards_2x.png differ