Ein kopfloser Zwei-Agenten-Code-Loop mit OpenCode und Ollama
Wie man Planung und Überprüfung in OpenCode mit Ollama auf zwei Agenten aufteilt, inklusive Berechtigungen, Fähigkeiten, Redaktionsregeln, Screenshots sowie Commit-Vorgängen ausschließlich für Menschen.
Quellen: Ollama on Steroids with OpenCode: A Headless Multi Agent Coding Workflow
Die meisten KI-Programmier-Demos beeindrucken bis zum Moment, in dem jemand eine langweilige technische Frage stellt: Was ist genau passiert, wer hat es überprüft, welche Tests wurden ausgeführt, und kann das Ganze morgen wiederholt werden?
Der unten beschriebene Workflow versucht, diese Fragen zu beantworten. Anstelle eines Chat-Fensters, das gelegentlich einen guten Patch erzeugt, betrachtet er das KI-Programmieren als einen kleinen technischen Kreislauf:
- ein Agent plant und implementiert
- ein zweiter Agent überprüft und gibt seine Zustimmung
- jeder Prompt erhält seine eigene lokale Session-Ordner
- jede Ausführung hinterlässt Protokolle sowie Beweise dafür, dass Tests durchgeführt wurden
- ein Mensch, niemals ein Agent, entscheidet, wann der Code gespeichert oder hochgeladen wird
- private Prompts und Session-Ausgaben bleiben privat
Die Arbeitsteilung: MiniMax erstellt Pläne und schreibt Code, GLM prüft und genehmigt, OpenCode steuert den Workflow und Ollama leitet Anfragen an die Modelle weiter. Das Ergebnis ist keine magische Autonomie – es handelt sich um einen wiederholbaren Kreislauf, der Pläne, Überprüfungen, Tests, Screenshote, Sicherheitsprüfungen erzeugt und von einer Person kontrolliert wird.
Was die Tools angeht, bietet OpenCode eine nicht-interaktive opencode run-Funktion, benannte Agenten, die Auswahl von Modellen, ein --dir-Flag sowie die Möglichkeit, einen Lauf an eine headless opencode serve-Instanz anzuhängen. Sessions können mit --sanitize exportiert werden. Ollama dokumentiert die Integration mit OpenCode über ollama launch opencode, und OpenCode liest Konfigurationen, Agenten, Berechtigungen, Fähigkeiten sowie MCP-Server auf Projektebene.
Die Beispieldatei benennt ihre Ollama Cloud-Modelle minimax-m3:cloud und glm-5.1:cloud; MiniMax ist für Programmierung und agentbasierte Aufgaben vorgesehen, während GLM als Flaggschiff für agentbasiertes Engineering beschrieben wird. Das Muster selbst hängt nicht von diesen spezifischen Modellen ab. Betrachten Sie die Modellnamen als Beispiele und prüfen Sie vor dem Kopieren das aktuelle Ollama-Katalog. Rohdaten wie Prompts, Sitzungsausgaben, lokale Pfade, Schlüssel sowie Screenshote aus dem ursprünglichen Projekt werden hier nicht geteilt, nur die Methode.
Hören Sie auf, KI-Programmierung als einziges Chat-Gespräch zu betrachten
Ein einzelner Programmieragent teilt eine Schwäche mit einem allein arbeitenden Entwickler unter Druck: Er kann sich selbst davon überzeugen, dass die Arbeit abgeschlossen ist. Das Wiederholen desselben Modells löst dieses Problem nicht. Ein Prozess hingegen schon:
Prompt -> Plan -> Review -> Implement -> Test -> Review -> Fix -> Signoff -> Human commit
Die Gestaltung sieht so aus:
control-workspace/
AGENTS.md
opencode.json
.opencode/
agents/
minimax-builder.md
glm-reviewer.md
skills/
opencode-ollama-agent-guardrails/
SKILL.md
agent-sessions/
project-slug/
promptNN/
PROMPTNN_CODER.md
PROMPTNN_REVIEWER.md
PROMPTNN_PLAN.md
PROMPTNN_PLAN_REVIEW.md
PROMPTNN_IMPLEMENTATION.md
PROMPTNN_TEST_RESULTS.md
PROMPTNN_IMPLEMENTATION_REVIEW.md
PROMPTNN_SIGNOFF.md
redacted logs
screenshot references
product-repo/
Warum mit einem übergeordneten Steuerungsarbeitsbereich beginnen? Allein im Produkt-Repository kann der Agent möglicherweise keine Prompt-Dateien, Sitzungsdateien, gemeinsam genutzte Regeln oder den umfassenderen Workflow sehen. Absolute Pfade hingegen können maschinenbezogene Details in die Protokolle aufnehmen. Deshalb gilt die Regel: Starten Sie OpenCode vom übergeordneten Arbeitsbereich aus, verwenden Sie relative Pfade, bewahren Sie Produktanpassungen im Produkt-Repository auf und lagern Sie Sitzungsergebnisse außerhalb davon. Das klingt langweilig – genau deshalb funktioniert es.
Zwei Agenten mit getrennten Aufgaben
Die entscheidende Gestaltungsentscheidung liegt nicht im genauen Modell, sondern in der Trennung der Aufgaben.
Der Ersteller
minimax-builder kann Code planen, bearbeiten, Befehle ausführen und Implementierungsnotizen schreiben. Zu seinen Aufgaben gehören das Lesen der Anweisung sowie von AGENTS.md, das Erstellen eines Plans, die Berücksichtigung der Rückmeldungen des Reviewers, die Implementierung nur des genehmigten Umfangs, das Ausführen von Validierungen, das Aufzeichnen dessen, was geändert und was fehlgeschlagen ist, sowie das Anhalten zur menschlichen Freigabe jedes Commits. Verboten sind: Committing, Pushen, Rebasen, Force-Pushing, Übergang zur nächsten Anweisung, Abschwächen von Tests sowie das Bearbeiten von für den Reviewer vorgesehenen Dateien.
Der Reviewer
glm-reviewer ist aus Designgründen streng. Seine Überprüfungspunkte sind: Passt der Plan zur Anweisung? Bleibt die Implementierung im vorgegebenen Umfang? Sind die Tests aussagekräftig? Wurden die generierten Dateien absichtlich geändert? Untermauern die Browser-Screenshots die Angaben? Wird das Verfahren mit sensiblen Daten angemessen umgegangen? Übertreibt der Builder seine Ergebnisse?
Sein Entscheidungswortschatz bleibt sehr begrenzt:
APPROVED
CHANGES_REQUESTED
SIGNED_OFF
NOT_SIGNED_OFF
Ein kleines Wortschatzvolumen lässt kaum Spielraum für Kreativität. „Im Großen und Ganzen gut“ ist kein Endgültigkeitsurteil.
Die OpenCode-Konfiguration
So sieht die Struktur der Konfiguration aus:
{
"$schema": "https://opencode.ai/config.json",
"model": "ollama/minimax-m3:cloud",
"default_agent": "minimax-builder",
"share": "disabled",
"instructions": ["AGENTS.md"],
"enabled_providers": ["ollama"],
"permission": {
"read": {
"*": "allow",
"*.env": "deny",
"*.env.*": "deny",
"*.env.example": "allow"
},
"glob": "allow",
"grep": "allow",
"webfetch": "ask",
"websearch": "ask",
"external_directory": "deny",
"skill": {
"*": "allow"
}
},
"agent": {
"minimax-builder": {
"description": "Main planning and implementation agent.",
"mode": "primary",
"model": "ollama/minimax-m3:cloud",
"temperature": 0.2,
"permission": {
"edit": {
"*": "deny",
"product-repo/**": "allow",
"agent-sessions/project-slug/**": "allow"
},
"bash": {
"*": "ask",
"cd product-repo && *": "ask",
"git status *": "allow",
"git diff *": "allow",
"git log *": "allow",
"git commit *": "deny",
"git push *": "deny",
"git rebase *": "deny",
"rm *": "deny"
}
}
},
"glm-reviewer": {
"description": "Strict reviewer. Must not edit product code.",
"mode": "primary",
"model": "ollama/glm-5.1:cloud",
"temperature": 0.1,
"permission": {
"edit": {
"*": "deny",
"agent-sessions/project-slug/**": "allow"
},
"bash": {
"*": "ask",
"git status *": "allow",
"git diff *": "allow",
"git log *": "allow",
"grep *": "allow",
"rg *": "allow",
"git commit *": "deny",
"git push *": "deny",
"git rebase *": "deny",
"rm *": "deny"
},
"task": "deny"
}
}
}
}
Zwei Aspekte verdienen besondere Aufmerksamkeit. Der Austausch ist standardmäßig deaktiviert, und da OpenCode eine share-Option bietet, führt die Einstellung auf "disabled" dazu, dass ein Weg für versehentliche Datenlecks verschlossen wird. Der Prüfer verfügt außerdem nicht über umfassende Bearbeitungsrechte: Er kann Bewertungs- und Freigabedateien in das Sitzungsfenster schreiben, sollte aber keinen Produktionscode ändern. OpenCode bietet fein abgestimmte Berechtigungsregeln für edit, bash, read, grep, glob, skill und weitere Funktionen, sodass die Konfiguration selbst den Arbeitsablauf durchsetzen sollte.
Passen Sie die Pfade für Ihr eigenes Repository an. Das Prinzip bleibt unverändert:
builder can edit product code;
reviewer can write review notes;
neither agent can commit or push;
external directories are denied;
dangerous shell commands ask or deny.
Fähigkeiten als tragbare Schutzbegrenzung
Der am häufigsten wiederverwendbare Bestandteil ist nicht nur die Konfigurationsdatei – es sind die Fähigkeiten. Die OpenCode-Fähigkeiten sind wiederverwendbare SKILL.md-Definitionen, die in Projekt- oder globalen Fähigkeitsordnern gespeichert werden. Der kanonische Speicherort auf Projektebene ist:
.opencode/skills/<skill-name>/SKILL.md
Es existieren auch fähigkeitsbasierte Wege, die mit Claude und Agent kompatibel sind, aber für diesen Workflow ist es sinnvoll, es einfach zu halten. Legen Sie die Guardrail-Fähigkeit hier hin:
.opencode/
skills/
opencode-ollama-agent-guardrails/
SKILL.md
Jedes SKILL.md muss mindestens Frontmatter mit einem name und einer description enthalten. Der Name muss in Kleinbuchstaben sein, mit Bindestrichen getrennt und identisch mit dem Ordnernamen sein. Eine Schutzregel-Fähigkeit kann den Agenten Regeln wie folgende mitteilen:
- Do not publish raw prompts.
- Do not publish raw session logs.
- Do not use absolute local paths.
- Do not edit outside the approved product directory.
- Do not claim success without test output.
- Do not weaken tests to make validation pass.
- Do not commit, push, rebase, or force-push.
- Store review notes separately from production code.
- Treat screenshots as sensitive evidence.
- Stop for human approval after signoff.
Die Regeln scheinen einfach zu sein, aber sie verhindern echte Fehler. Wenn sie nur im AGENTS.md eines Repositoriums vorhanden sind, bleiben sie dort. Als Fähigkeit verpackt, begleiten sie einen überallhin.
Der headless-Modus sorgt für Wiederholbarkeit
Interaktives Programmieren eignet sich zur Erkundung. Der headless-Modus ist besser für wiederholbare Ausführungen. Der Builder-Pass sieht so aus:
opencode run \
--model ollama/minimax-m3:cloud \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
Und der Prüfer bestätigt:
opencode run \
--model ollama/glm-5.1:cloud \
--agent glm-reviewer \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_REVIEWER.md)"
Für umfangreichere Konfigurationen mit MCP-Servern sollte man zunächst einen lokalen OpenCode-Server starten und spätere Ausführungen daran anschließen, um wiederholte Neustarts zu vermeiden:
opencode serve --hostname 127.0.0.1 --port 4096
opencode run \
--attach http://localhost:4096 \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
Binden Sie den Server an 127.0.0.1 fest. Jeder, der ihn einer anderen Maschine zugänglich macht, sollte OPENCODE_SERVER_PASSWORD setzen und ihn wie einen echten Entwicklungsdienst betreiben, da die CLI-Dokumentation die HTTP-Basisauthentifizierung über diese Variable beschreibt. Das Modell ist nicht intelligenter geworden – der Workflow ist nur schwieriger zu täuschen.
Halten Sie Anfragen und Ausgaben geheim
Das Lokalisieren von Anfragedateien und Sitzungsausgaben ist zum Debuggen des Agentenverhaltens sinnvoll. Die Veröffentlichung von Rohanfragen oder Rohexporten hingegen nicht. In den Logs der Agenten können sich lokale Pfade, Shell-Anfragen, Branchennamen, interne TODOs, Implementierungsgeheimnisse, Umgebungsnamen, Screenshot-Pfade, verlorene Anmeldeinformationen sowie Formulierungen von Anfragen befinden, die man lieber privat wiederverwenden würde.
Die Regel lautet: Speichern Sie alles lokal und veröffentlichen Sie nur redigierte Zusammenfassungen sowie wiederverwendbare Vorlagen. OpenCode’s opencode export [sessionID] mit --sanitize unterstützt die interne Überprüfung, sollte aber als erste Durchgangsprüfung und nicht als Veröffentlichungsknopf angesehen werden. Alles, was öffentlich zugänglich sein soll, muss einer zweiten Redaktionsprüfung unterzogen werden.
Für ein öffentliches Repository sollten Sie Folgendes speichern:
AGENTS.md
opencode.json
.opencode/agents/*.md
.opencode/skills/*/SKILL.md
templates/*.md
scripts/*.zsh
scripts/redact_sessions.py
docs/publication-redaction-checklist.md
und ignoriere diese:
agent-sessions/**
screenshots/**
.env
project.local.env
*.raw.log
*.events.jsonl
opencode-session-*.json
Das Ergebnis sind teilebare Berichte, ohne dass der Repository zu einer Quelle von Lecks wird.
Wo MCP-Tools geholfen haben
Modelle sind nur ein Teil des Systems, und die Benutzeroberfläche der Tools spielt eine sehr wichtige Rolle. Eine nützliche Art, MCPs und eingebaute Tools zu betrachten, ist als spezialisierte Sinne und Hände:
| Workflow stage | Useful tool or MCP category | What it helped with |
| ---------------- | ------------------------------------------------------- | -------------------------------------------------- |
| Planning | repo search, docs lookup, issue/context reader | understand current architecture before changing it |
| Coding | filesystem, shell, language server, package manager | edit code, inspect symbols, run targeted commands |
| Review | git diff, grep, test reports, generated artifact reader | catch scope creep and weak tests |
| Unit tests | test runner, coverage | prove the patch did not only compile |
| Browser tests | Playwright/browser automation | validate real UI routes and flows |
| Security tests | secret scan, dependency audit, SAST | catch obvious unsafe output before publish |
| Docs/site checks | static-site build, route checks, smoke tests | catch generated-output drift |
Die beste MCP-Einrichtung aktiviert nicht alles. Sie stellt dem Agenten nur die wenigen Werkzeuge zur Verfügung, die er benötigt, und zwingt riskante Werkzeuge dazu, zuerst um Erlaubnis zu bitten. OpenCode definiert MCP-Server unter dem Schlüssel mcp in opencode.json und bietet CLI-Befehle zur Verwaltung dieser Server. Behandeln Sie diese Definitionen wie Produktionsabhängigkeiten: Festlegen Sie konkrete Versionen, überprüfen Sie sie und entfernen Sie die ungenutzten.
Warum Screenshots einen Platz verdient haben
Browser-Tests liefern nur ein Ergebnis von „erfolgreich“ oder „fehlschlägig“. Screenshots liefern visuelle Beweise. Sie halfen den Prüfern, Dinge aufzudecken, die Unit-Tests übersehen: ein kaputtes Layout nach einem erfolgreichen Build, falscher Inhalt auf einer Route, leere generierte Seiten, Regressionen in der Navigation, ein Fehlerbanner, für das kein Test bestimmt war, sowie den Nachweis, dass eine Static-Site-Route existiert und korrekt dargestellt wird.
Auch sie bergen Risiken: Benennungen von Browserprofilen, private Tab-Seiten, localhost-Pfade, Titel von Problemen, URL-Tokens sowie Ausgaben der Entwicklertools können alle in dem Frame landen. Die Richtlinie besagt, nur Screenshots der localhost-Oberfläche anzufertigen, diese streng zuzuschneiden, vor der Veröffentlichung zu überprüfen und auf keinen Fall Authentifizierungsseiten, Produktions-Dashboards, private Tab-Seiten oder Terminals, die Umgebungsvariablen anzeigen, aufzunehmen. Ein Screenshots gilt als Beweismittel und zählt standardmäßig nicht als öffentliches Artefakt.
Eine Fallstudie zu einem privaten Wiki-Projekt
Der Autor wendete dies auf eine private LLM-Wiki- und Static-Site-Projektanwendung an und veröffentlichte nur eine aufbereitete Zusammenfassung. In den abschließenden Validierungsnotizen wurden 977 erfolgreiche Python-Tests, ein Neubau der Static-Site mit Aktualisierung, Smoke-Tests sowie Domain-Validierungen, ein Dokumentenbauvorgang, Route-Prüfungen sowie 150 erfolgreiche Playwright-Tests aufgeführt. Für die abgeschlossenen, definierten Funktionen hatte der Autor ein hohes Selbstvertrauen – etwa 8 bis 9 von 10 – gestützt auf wiederholbare Tests, Prüfungen der generierten Seite, Route-Prüfungen sowie Browser-Validierungen. Diese Bewertung ist subjektiv und sollte nicht auf andere Projekte übertragen werden.
Der Schwachpunkt lag nicht im Produktcode. Ein headless-Automatisierungs-Skript fehlgeschlagen, weil die Agentennamen falsch konfiguriert waren. Es wurden allgemeine Namen verwendet:
planner
coder
tester
reviewer
während die konfigurierten Agenten tatsächlich waren:
minimax-builder
glm-reviewer
Dieser Unterschied führte dazu, dass der Ablauf auf das falsche Verhalten zurückfiel, wodurch die beabsichtigte Bestätigung durch mehrere Agenten nicht abgeschlossen werden konnte. Der Fehler war nützlich, da er den Wert einfacher Namen, exakter Konfigurationen, relativer Pfade sowie der Überprüfung des Sitzungsfolders aufzeigte. Das korrigierte Muster sieht wie folgt aus:
opencode run \
--model ollama/minimax-m3:cloud \
--agent minimax-builder \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_CODER.md)"
opencode run \
--model ollama/glm-5.1:cloud \
--agent glm-reviewer \
--dir . \
"$(cat agent-sessions/project-slug/promptNN/PROMPTNN_REVIEWER.md)"
Das bedeutet keine absoluten Pfade, keine erfundenen Agentennamen und keine Prompt-Dateien, die außerhalb des Arbeitsumfangs versteckt sind.
Wie nahe an einem Frontier-Workflow?
Hier ist es leicht, überzuschlagen. Eine MiniMax-Plus-GLM-Konfiguration auf OpenCode und Ollama ist nicht dasselbe wie das Direktlaufen des besten Frontier-Programmiermodells. Frontier-Modelle verfügen weiterhin über stärkeres Roh-Reasoning, besseres Verhalten bei langen Kontexten sowie eine bessere Standardbefolgung von Anweisungen, weshalb ein direkter Vergleich der Modelle nicht fair wäre. Der entscheidende Vergleich betrifft die Qualität des Workflows: Planung, Überprüfung, Tests, Screenshots, Sicherheitschecks und menschliche Freigabe.
Der Workflow hat große Bedeutung. Bei auf begrenzte Aufgaben beschränkten Projekten, die durch gute Tests gestützt werden, kann die Struktur fast wie eine starke Frontier-Struktur wirken, da sie separate Rollen, vorabige Planung, Überprüfungen auf beiden Seiten der Implementierung, verpflichtende Validierungsmechanismen, lokale Sitzungsspeicher, Screenshot-Beweise, Sicherheitsprüfungen sowie von Menschen kontrollierte Commit-Vorgänge vorsieht.
Er kommt bei deterministischer Funktionsentwicklung, der Erstellung statischer Websites, der Abfrage- und Suchfunktionstechnik, testschwierigen Aufgaben, der Überprüfung der erzeugten Ausgaben, dem Erkennen von Scope-Creep sowie der Verpflichtung der Beteiligten zur Dokumentation von Fehlern nahe an diese Struktur heran. Frontier-Modelle gewinnen jedoch weiterhin bei unklaren Architekturauswahlentscheidungen, tiefgreifenden Refaktorisierungen in schlecht getestetem Code, bei Geschmacks- und Produkturteilen, bei langfristiger Selbstkorrektur, bei geringerer Notwendigkeit für Wiederholungsversuche, bei der standardmäßigen Befolgung von Anweisungen sowie bei der Analyse komplexer Screenshote.
Bedrohungsmodell
Mehrere bekannte Gefahren beim Einsatz von KI zum Programmieren verringern sich durch diesen Arbeitsablauf: unbegründete Erfolgserklärungen, Entwickler, die sich außerhalb des vorgesehenen Repositoriums aufhalten, Reviewer, die zu Implementierern werden, rohe Anfragen, die in öffentliche Repositorien gelangen, Logs, die Pfade oder Geheimnisse preisgeben, Screenshote, die private Tab-Seiten oder Token zeigen, stille Änderungen an generierten Dateien sowie Agenten, die vor dem Blick Dritter commiten oder pushen.
Eine menschliche Überprüfung bleibt notwendig. Vollständige Autonomie ist nicht das Ziel – ein engerer Kreislauf, bei dem jede Behauptung mit Beweisen untermauert wird und jede risikoreiche Aktion Grenzen hat, schon.
Vorteile und Nachteile
Vorteile
- Reproduzierbarkeit. Anfragen erzeugen Ordner, Ausführungen hinterlassen Notizen und Freigabestimmen können nachverfolgt werden.
- Verwaltung. Der Entwickler kann die Tests nicht heimlich überspringen, wenn der Reviewer die Freigabe ohne Validierungsbelege blockieren muss.
Nachteile
- Mehr Formalitäten. Es ist aufwendiger als eine einfache Chatanfrage – das ist der Preis dafür.
- Umsetzung erfordert Konfiguration. Dem Prüfer mitzuteilen, er solle den Produktionscode nicht ändern, ist weniger wirksam als die Durchsetzung durch Berechtigungen und CI-Prüfungen.
- Schlechte Anfragen ergeben weiterhin schlechte Ergebnisse. Der Zyklus verringert das Chaos, ersetzt aber keine klare Aufgabenbeschreibung.
- Berechtigungen erfordern Sorgfalt. MCP-Server und Shell-Zugriff sind mächtig, daher sollten sie wie Produktionszugriff behandelt werden.
- Logs sind sensibel. Je detaillierter die Logs sind, desto sorgfältiger muss die Bearbeitung erfolgen.
Die haltbare Behauptung
Die Konfiguration wird weder MiniMax noch GLM zu einem Spitzenmodell der neuesten Generation machen. Stattdessen sorgt sie dafür, dass günstigeres, über Ollama gesteuertes agentes-basiertes Programmieren disziplinierter, überprüfbarer und für gezielte Ingenieurarbeiten nützlicher wird. Das ist die einzige Behauptung, die man ehrlich aufstellen kann.