Bis hierhin kannst du die Serie mit Obsidian, einem Chat im Browser und einigen lokalen Skripten nachvollziehen. Das ist bereits ein vollständiger Arbeitsablauf. Ein Assistent im Terminal wird dann interessant, wenn du Notizen häufiger durchsuchen, Entwürfe als Dateien ablegen oder mehrere Arbeitsschritte verbinden möchtest.
Die Serie als Video
Das Video zur Serie zeigt in gut sechs Minuten, wie alle fünf Teile zusammenpassen. Die Angaben im Umzugsbeispiel sind erfunden.
Dieser letzte Teil zeigt einen möglichen Einstieg mit OpenCode 1. Die offizielle Dokumentation unterscheidet inzwischen Version 1 und 2; beide können denselben Befehl opencode verwenden. Prüfe deshalb vor der Einrichtung die installierte Hauptversion. Die Beispielkonfiguration hier bezieht sich auf Version 1. Du probierst zunächst eine reine Leseaufgabe am gemeinsamen Umzugsbeispiel aus. MCP und tmux kommen anschließend als optionale Ergänzungen dazu. Sie sind keine Voraussetzung für dein Notizbuch und müssen nicht alle am ersten Tag eingerichtet werden.
Die Anleitung und Beispiele zu diesem Teil findest du im Serienordner auf GitHub. Das gesamte Repository als ZIP enthält auch das Material der anderen Teile. Für die Befehle öffnest du innerhalb des entpackten Repositorys den Serienordner serien/obsidian-und-ki. Dort liegt die zugehörige README.md.
Vier Bausteine mit unterschiedlichen Aufgaben
Obsidian ist die Oberfläche für deine Notizen. Das KI-Modell formuliert und verarbeitet die ihm übergebenen Inhalte. Der Assistent organisiert den Dialog und Werkzeugaufrufe. Werkzeuge lesen oder verändern Dateien und verbinden gegebenenfalls weitere Dienste.
OpenCode ist ein solcher Assistent. Es kann unterschiedliche Modelle verwenden und besitzt bereits eingebaute Werkzeuge. Über MCP lassen sich weitere Werkzeuge anschließen. Für die eingebauten Dateilesewerkzeuge brauchst du diesen Anschluss nicht. tmux hält unter Linux eine Terminalsitzung im Hintergrund verfügbar; es macht weder das Modell zuverlässiger noch repariert es eine abgebrochene Anfrage.
Eine Testkopie vorbereiten
Entpacke das Beispielpaket zur Serie. Darin liegt der fiktive Vault unter beispiele/umzug. Kopiere diesen Ordner für deinen ersten Versuch an einen eigenen Ort. Verwendest du nur die Beispieldaten, brauchst du dafür keine privaten Dokumente oder Zugangsdaten.
Unter Linux kannst du beispielsweise so eine Testkopie anlegen, wenn du im Serienordner serien/obsidian-und-ki stehst:
mkdir -p ~/ki-serie-test
cp -R beispiele/umzug ~/ki-serie-test/umzugDie Entscheidung für einen Startordner ist eine Orientierung, keine Betriebssystem-Sandbox. Je nach Einrichtung können Werkzeuge auch außerhalb dieses Ordners zugreifen. Prüfe deshalb die Berechtigungseinstellungen des Assistenten und arbeite zunächst mit einer Kopie.
OpenCode installieren und ein Modell verbinden
Die aktuellen Installationswege stehen in der OpenCode-Dokumentation. Nutze dort die Anleitung für dein Betriebssystem und prüfe anschließend im Terminal:
opencode --versionUnter Windows beschreibt das Projekt sowohl Windows- als auch WSL-bezogene Möglichkeiten. Wenn du den Linux-Weg verwenden möchtest, findest du die zusätzliche WSL-Anleitung bei dieser Serie. Für Obsidian, den Browserchat und die Python-Beispiele aus den vorherigen Teilen brauchst du WSL nicht.
Wechsle in deine Testkopie und starte OpenCode:
cd ~/ki-serie-test/umzug
opencodeWähle ein Modell über die Oberfläche. Über /connect kannst du einen Anbieter verbinden, wenn dein gewählter Zugang das verlangt. Preise, kostenlose Kontingente und Verfügbarkeit können sich ändern. Prüfe sie beim Anbieter; für die Artikelserie wird kein bestimmtes Gratis-Modell vorausgesetzt.
Wenn du ein Cloud-Modell nutzt, kann der Assistent gelesene Notizen als Teil seiner Anfrage an den Anbieter senden. Ein lokal gestarteter Assistent bedeutet also nicht automatisch eine vollständig lokale Datenverarbeitung. Der Beispiel-Vault enthält deshalb ausschließlich erfundene Daten.
Die erste Aufgabe liest nur
Bevor du die Aufgabe eingibst, prüfe die Berechtigungseinstellungen. Der mitgelieferte Ordner 05-terminal enthält eine Beispielkonfiguration für eine Leseübung: Lese- und Suchwerkzeuge bleiben nutzbar, Dateiänderungen, Shell-Befehle und weitere Werkzeuge sind zunächst gesperrt. Es handelt sich um Einstellungen des Assistenten, nicht um eine vollständige Betriebssystem-Isolation.
Kopiere die Konfiguration in die Testkopie und kontrolliere im Programm, welche Regeln tatsächlich geladen wurden. Vorhandene globale oder agentenspezifische Einstellungen können das Verhalten beeinflussen. Verlangt ein Dialog bei dieser Leseübung Schreibrechte, prüfe erst den Grund.
Gib dann diese Aufgabe ein:
Lies Start.md und die für die Transportplanung relevanten Notizen.
Nenne die relative Datei und Belegstelle für jede Angabe.
Was ist entschieden, was ist nur erwartet und was ist noch offen?
Behandle „zu prüfen“ nicht als bestätigte Tatsache.
Ändere keine Dateien und führe keine Shell-Befehle aus.
Wenn du eine Datei nicht lesen darfst, melde die Grenze.Kontrolliere die Antwort selbst. Im Beispiel ist ein Transporter vorgesehen; ein verbindliches Angebot und Helferzusagen fehlen. Prüfe außerdem, ob Dateien unverändert geblieben sind. Wenn ein Werkzeugzugriff abgelehnt wird, kläre die konkrete Regel, statt pauschal alle Rechte zu erlauben.
Was ein Skill hier verändert
Im vierten Teil hast du brief-schreiben kennengelernt. Für einen ersten Test kannst du den Inhalt der Anleitung wie im Browserchat gezielt mitgeben. Bei unterstützter automatischer Skill-Erkennung richtet sich der Ablageort nach der Dokumentation des Assistenten.
Auch mit Skill braucht der Assistent einen konkreten Auftrag und passende Fakten. Ein Skill schafft keine Buchung, bestätigt keinen Termin und verleiht keine zusätzlichen Rechte. Prüfe bei der fertigen Anfrage, ob offene Angaben erkennbar geblieben sind.
MCP erst hinzufügen, wenn ein Werkzeug fehlt
MCP steht für Model Context Protocol. Der Standard beschreibt, wie ein Assistent mit einem bereitgestellten Werkzeugdienst kommunizieren kann. Dafür braucht es einen passenden Client, einen passenden Server und eine funktionierende Konfiguration. Nicht jede KI-Anwendung unterstützt jeden Dienst gleichermaßen.
Für den ersten Test brauchst du keinen zusätzlichen MCP-Server: OpenCode besitzt bereits Dateilesewerkzeuge. Ein Server, der nur zum technischen Testen gedacht ist, würde dein Umzugsproblem nicht automatisch besser lösen. Ergänze später einen konkreten Dienst, wenn eine nachvollziehbare Aufgabe ihn benötigt.
In der OpenCode-Dokumentation zu MCP findest du lokale und entfernte Verbindungen. Ein lokaler Server läuft als Prozess auf deinem Rechner. Ein entfernter Dienst kann übertragene Daten auf einem anderen System verarbeiten. Weder „lokal“ noch „MCP“ ist an sich eine Sicherheitszusage; prüfe Herkunft, benötigte Zugriffe und die Daten, die ein Werkzeug weitergibt.
tmux bei längeren Terminalsitzungen
Wenn du unter Linux oder in WSL arbeitest, kann tmux eine Sitzung vom sichtbaren Terminalfenster lösen. Unter Ubuntu oder Debian installierst du es bei Bedarf mit:
sudo apt install tmuxEin kleiner Test braucht kein Modell und keinen Anbieter:
tmux new -s obsidian-testStarte darin eine kurze Zählung:
for i in $(seq 1 30); do echo "Sekunde $i"; sleep 1; doneLöse dich mit Strg+b, dann d. Mit tmux ls siehst du die Sitzung; mit dem folgenden Befehl kehrst du zurück:
tmux attach -t obsidian-testDie Zählung kann während des gelösten Zustands weiterlaufen. Wenn sie beendet ist, kannst du die Testsitzung mit exit schließen. Den Assistenten kannst du später auf dieselbe Weise in einer benannten Sitzung starten.
tmux ist keine Pausentaste für die Aufgabe. Ein wartender Dialog wartet weiter; eine fehlerhafte Modellanfrage bleibt fehlerhaft. Ein Rechnerneustart beendet die Sitzung, und bei einem schlafenden Rechner läuft die Verarbeitung nicht einfach weiter. tmux schützt vor allem davor, dass das Schließen der sichtbaren Terminalverbindung die zugehörige Sitzung beendet.
Erst nach einem guten Lesetest schreiben lassen
Wenn die Leseaufgabe nachvollziehbar funktioniert, kannst du auf der Testkopie einen begrenzten Schreibauftrag vorbereiten: etwa einen Briefentwurf in einer neuen Datei. Prüfe vorher, welche Änderung erlaubt werden soll, und danach die tatsächliche Datei. Erteile keine pauschalen Rechte nur deshalb, weil das Programm danach fragt.
Eine Anweisung wie „Lösche nichts“ gehört in den Auftrag. Sie verhindert aber technisch keine Löschung. Technische Einschränkungen kommen aus Werkzeugregeln und gegebenenfalls Betriebssystemrechten; deine Kontrolle kommt durch Vergleich, Sicherung und nachvollziehbare Ergebnisse hinzu.
Wann du bei der einfachen Variante bleiben kannst
Wenn du nur gelegentlich eine Frage zu drei Notizen stellst, genügt das manuelle Übergeben aus Teil 1. Der Router aus Teil 2 spart dir Sucharbeit. Teil 3 hilft bei veralteten Angaben, Teil 4 bei wiederkehrenden Abläufen. Der Terminal-Assistent verbindet diese Schritte dort, wo der zusätzliche Einrichtungsaufwand sich lohnt.
Der abschließende Test bleibt derselbe wie am Anfang: Kannst du für eine konkrete Antwort zeigen, welche Notizen und welche Anleitung vorlagen, welche Angabe offen blieb und welche Dateien tatsächlich verändert wurden? Wenn du das nachvollziehen kannst, ist aus der Sammlung ein kontrollierbarer Arbeitsablauf geworden.