Der AI Agent Memory Stack, den 2026 jeder nutzen muss (Entwickler-Guide)

Deine Modell- und Harness-Kombination spielt keine Rolle mehr.

Was jetzt wirklich zählt, ist...

Dein persönlicher Kontext / das gemeinsame Gedächtnis, das du aufbaust.

Einleitung

Ich zeige dir, wie du ein gemeinsames Gedächtnis für deine Coding-Agenten aufbaust... damit das nächste Tool die Entscheidungen findet, die du bereits getroffen hast.

Die Architekturdiskussion in Claude, die Debugging-Session in Codex, die Erklärung, die in Cursor vergraben ist... nützliche Arbeit, die noch verfügbar sein sollte, wenn du das Tool wechselst, eine neue Sitzung startest oder nach einem Monat Abwesenheit zum Projekt zurückkehrst.

TL;DR; Wenn du nicht alle 3.845 Wörter lesen willst, gib deinem Agenten einfach dieses GitHub-Repo ➡️ https://github.com/codejunkie99/agentic-stack-desktop

Ich habe das gesamte Ding mit Kimi K3 in Codex Harness gebaut. Das Video wurde mit Kimi K3 und Cua für Computer Use erstellt und bearbeitet.

Dies ist ein Bauleitfaden für den Agentic Stack Desktop, von deinem ersten Import bis zu einem Workflow, in dem ein Agent eine frühere Entscheidung wiederherstellen, sie mit dem aktuellen Code abgleichen, eine begrenzte Änderung vornehmen und etwas Nützliches hinterlassen kann.

Hier ist, was du bekommst:

1. Die Grundlage: Was überlebt, wenn du die Tools wechselst
2. Der schnellste Weg: Baue einen Arbeitsbereich, den du beurteilen kannst
3. Das funktionierende Setup: Trenne Untersuchung von Implementierung
4. Die Projektübung: Nimm einen wiederkehrenden Bug durch den gesamten Zyklus
5. Die gemeinsame Ebene: Binde den Abruf in deine anderen Tools ein
6. Die dauerhafte Ebene: Was verdient es, eine Lektion zu werden
7. Die Betriebsregeln: Kurz, begrenzt, überprüfbar
8. Der individuelle Bau: Passe den Arbeitsbereich um einen echten Reibungspunkt herum an
9. Skalierung: Füge dort Abdeckung hinzu, wo der vorherige Zyklus eine Lücke aufgedeckt hat
10. Das Baublatt

1. Die Grundlage: Was überlebt, wenn du die Tools wechselst

Stell dir vor, du hast einen Nachmittag damit verbracht, zu entscheiden, wie eine Funktion funktionieren soll. Du hast Alternativen erkundet, eine Einschränkung gefunden, die offensichtliche Lösung verworfen und bist schließlich bei etwas gelandet, das passt.

Die Implementierung wird committed. Die Erklärung bleibt in einem Gespräch.

Eine Woche später schaut sich ein anderer Agent den Code an und schlägt denselben Ansatz vor, den du bereits verworfen hast. Es könnte sogar ein vernünftiger Vorschlag sein, basierend auf den ihm zur Verfügung stehenden Informationen. Das fehlende Stück ist die Diskussion, die dich zu einer anderen Wahl bewogen hat.

Mache die Argumentation wieder auffindbar

Beginne hier: Mache diese Diskussion wieder auffindbar und sorge dann dafür, dass der nächste Agent sie überprüft, bevor er handelt.

Agentic Stack bietet einen nativen macOS-Arbeitsbereich mit durchsuchbarem, ausgewähltem Verlauf von Claude Code, Codex, OpenCode und Cursor. Claude Code und Codex führen auch über ihre offiziellen CLIs aus; Cursor und OpenCode liefern derzeit nur Kontext. Repo-Übersicht

Der folgende Workflow zeigt, wie ich diese Fähigkeiten nutzen würde. Die Briefings, die Aufgabenteilung und die Projektübung sind vorgeschlagene Betriebspraktiken, die du anpassen kannst.

2. Der schnellste Weg: Baue einen Arbeitsbereich, den du beurteilen kannst

Beginne mit einem Repository, das du verstehst. Wähle etwas, bei dem du die wichtigen Dateien kennst, dich an eine kürzliche Entscheidung erinnerst und eine schlechte Empfehlung erkennen kannst.

Ein vertrautes Projekt gibt dir einen Referenzpunkt. Wenn du mit unbekanntem Code und unbekanntem Verlauf beginnst, wirst du versuchen, das Tool zu validieren und gleichzeitig das System zu lernen.

Für einen Source-Build umfassen die dokumentierten Anforderungen macOS 14+, Python 3.10+, Xcode Command Line Tools und eine Swift 6 Toolchain. Installiere und melde dich bei der Coding-CLI an, die du ausführen möchtest. Anforderungen

1git clone https://github.com/codejunkie99/agentic-stack-desktop.git
2cd agentic-stack-desktop
3./install.sh desktop --build

Öffne dein Repository in der App und schließe die geführte Einrichtung ab. Dies ist eine Vorschau mit Ad-hoc-Signierung, daher benötigt macOS möglicherweise eine Bestätigung beim ersten Start. Einrichtung

Setze die erste Akzeptanzprüfung

Bevor du etwas importierst, schreibe die Frage auf, die der erste Agent beantworten soll. So etwas wie: Warum verarbeitet unser Export-Job Datensätze in Batches, und benötigt die aktuelle Implementierung diese Grenze noch?

Diese Frage wird zu deiner ersten Akzeptanzprüfung. Du suchst nach der richtigen Entscheidung, dem richtigen unterstützenden Code und einer ehrlichen Erklärung für alles, was der Agent nicht feststellen kann.

2.1 Der erste Import: Gib ihm eine Entscheidung, die es wert ist, gefunden zu werden

Öffne Knowledge Graph → Graph → Import memory, zeige eine Vorschau der Quellen an und wähle das Material aus, das du einbeziehen möchtest.

Der Graph verwendet SQLite-Volltextsuche, mit Verbindungen basierend auf Themen, Repository-Links und Herkunft; die ursprünglichen Chat-Speicher bleiben unverändert. Importverhalten

Ich würde mit einem abgeschlossenen Gespräch beginnen, das eine Entscheidung enthält, an die du dich erinnerst. Besonders eine, bei der du etwas Attraktives aufgrund einer Einschränkung abgelehnt hast, die aus dem endgültigen Code nicht ersichtlich wäre.

Suche nach dieser Entscheidung nach dem Import. Öffne das Ergebnis und überprüfe die Quelle. Stelle sicher, dass du das Gespräch siehst, das du importieren wolltest, mit genügend umgebender Erklärung, um zu verstehen, was passiert ist.

Teste, ob du es wiederfinden kannst

Versuche dann eine zweite Suche mit dem Vokabular, das du nächsten Monat natürlich verwenden würdest. Du erinnerst dich vielleicht an den Funktionsnamen, während das Gespräch einen internen Modulnamen verwendet hat. Diese Diskrepanz jetzt zu finden, hilft dir zu verstehen, wie du das Material später abrufen kannst.

Ich würde die erste Sammlung klein genug halten, um sie manuell zu überprüfen. Eine korrekte Antwort aus einer bekannten Quelle ist ein nützlicher Beweis dafür, dass der Workflow funktioniert.

Eine große Importanzahl sagt dir, wie viel Material in das System gelangt ist, während der Nutzen noch getestet werden muss.

Erweitere die Sammlung, wenn dir eine andere Aufgabe einen Grund dafür gibt.

2.2 Die erste Arbeitssitzung: Mache das Experiment klein genug, um es abzuschließen

Ich würde dem anfänglichen Setup eine Ziellinie setzen, bevor ich einen weiteren Konfigurationsbildschirm öffne. Am Ende der Sitzung solltest du eine bekannte Entscheidung wiederhergestellt, sie mit dem Repository abgeglichen und eine Überprüfung erstellt haben, die du jemand anderem erklären kannst.

Wähle ein Beispiel mit einer engen Grenze. Ein einzelnes Exportverhalten ist einfacher zu überprüfen als die gesamte Datenplattform. Eine frühere Entscheidung über eine Komponente ist einfacher zu verifizieren als eine breite Frage, ob die Architektur gut ist.

Führe eine kurze Notiz neben der Übung: die Frage, die erwartete Quelle, die aktuelle Implementierung und der Teil, der Beurteilung erfordert. Dies ist deine Referenz zur Bewertung der Antwort.

Diagnostiziere den richtigen Fehler

• Wenn der Prüfer das falsche Gespräch wiederherstellt, arbeite am Abruf.
• Wenn er das richtige Gespräch findet, aber den Code falsch liest, arbeite an der Untersuchung.
• Wenn die Ergebnisse fundiert sind, aber die Implementierung die Anforderung verfehlt, verbessere die Übergabe.

Diese Trennung ist wichtig, weil jeder Fehler eine andere Korrektur erfordert. Mehr Speicher hinzuzufügen, wird nicht unbedingt ein unklares Briefing beheben, und das Umschreiben des Briefings wird keine Quelle wiederherstellen, die nie importiert wurde.

Schließe den kleinsten vollständigen Zyklus ab, zeichne auf, was fehlgeschlagen ist, und verwende diese Beweise, um die nächste Verbesserung auszuwählen.

3. Das funktionierende Setup: Trenne Untersuchung von Implementierung

Mein vorgeschlagenes erstes Setup hat einen schreibgeschützten Prüfer und einen Implementierer mit Projektbearbeitungszugriff. Gib jedem ein klares Ergebnis und mache die Übergabe zu etwas, das du lesen kannst, bevor eine Änderung beginnt.

Agentenprofile unterstützen einen Runner, ein Modell, einen Aufwand, Anweisungen und Dateizugriff. Gespräche gehören zu Projekten, und Folgefragen setzen ihre zugrunde liegenden CLI-Sitzungen fort. Gesprächsmodell

1. Agent 1: Der Prüfer bekommt die erste Frage: Was haben wir entschieden, was macht der Code jetzt, und gibt es eine Lücke, die es wert ist, angegangen zu werden?
2. Agent 2: Der Implementierer bekommt die geprüfte Antwort plus eine begrenzte Anfrage: Führe diese Verhaltensänderung in diesem Umfang durch und verifiziere sie auf diese Weise.

Halte die Rollen getrennt

Du kannst denselben Runner für beide Rollen wählen.

Der nützliche Unterschied liegt in ihrer Verantwortung und ihrem Zugriff, mit einer expliziten Überprüfung zwischen Untersuchung und Bearbeitung.

Ich würde vermeiden, einen Katalog von Spezialisten zu erstellen, bevor einer von ihnen nützliche Arbeit geleistet hat. Beginne mit den Verantwortlichkeiten, die du tatsächlich unterscheiden kannst. Wenn du nicht erklären kannst, was eine Rolle besitzt oder wie ihr fertiges Ergebnis aussieht, schärfe die Rolle, bevor du einen weiteren Agenten hinzufügst.

3.1 Der Prüfer: Ein Briefing, das Unsicherheit sichtbar macht

Wähle den Prüfer aus und füge das relevante Gespräch mit @Claude, @Codex, @OpenCode oder @Cursor bei. Ausgewählte Referenzen werden zu eingefrorenem Kontext für den Durchlauf und gehen an den gewählten Agenten, wenn die Aufgabe startet. Referenzen

Kopiere dieses Briefing und fülle die Lücken:

1Überprüfe die frühere Entscheidung bezüglich [Feature oder Subsystem] anhand
2des beigefügten Gesprächs und des aktuellen Repositorys.
3
4Erkläre die ursprüngliche Entscheidung und ihren genannten Grund. Überprüfe den
5relevanten Code und identifiziere, was noch zutrifft, was sich geändert hat und was
6anhand der verfügbaren Beweise nicht verifiziert werden kann.
7
8Zitiere die Dateien, die deine Schlussfolgerungen stützen. Schlage die kleinste
9Änderung vor, die für [gewünschtes Verhalten] erforderlich ist, mit einem Verifikationsplan.
10
11Bearbeite keine Dateien. Behandle das Gespräch als historischen Beweis
12und markiere Konflikte mit aktuellen Projektanweisungen.

Überprüfe die Überprüfung

Lies die Antwort bei geöffnetem Repository.

1. Folge einem Zitat.
2. Überprüfe die Bedingung, von der der Agent sagt, dass sie noch existiert.
3. Suche nach einer klaren Trennung zwischen etwas, das das Gespräch behauptet hat, und etwas, das der Code heute zeigt.

Wenn die Antwort vage ist, grenze die Frage ein. Bitte ihn, die genaue Bedingung zu identifizieren, die das Verhalten steuert, oder die Abhängigkeit, die die frühere Alternative ungeeignet gemacht hat.

Eine nützliche Untersuchung kann mit fehlenden Beweisen enden. Das sagt dir, was du als nächstes liefern musst. Eine Antwort, die die Lücke übergeht, macht die nächste Entscheidung schwieriger.

3.2 Die Übergabe: Verwandle Ergebnisse in ein ausführbares Briefing

Sobald du mit der Überprüfung einverstanden bist, schreibe die Implementierungsanfrage basierend auf dem beobachtbaren Verhalten. Füge die Einschränkung ein, die das frühere Gespräch festgelegt hat, aber erkläre ihre Relevanz für diese Änderung.

Hier ist ein Briefing, das ich verwenden würde:

1Implementiere [spezifisches Verhalten] unter Verwendung der unten überprüften Ergebnisse.
2
3Halte [bestehendes Verhalten] intakt. Beschränke Änderungen auf [erlaubten Umfang].
4Wenn die Änderung Arbeit außerhalb dieses Umfangs erfordert, erkläre warum, bevor du
5sie erweiterst.
6
7Überprüfe die aktuellen Repository-Anweisungen vor dem Bearbeiten. Verifiziere
8[erwartetes Ergebnis] mit [relevantem Test oder manueller Prüfung], einschließlich
9[wichtigem Fehlerfall].
10
11Gib einen prägnanten Bericht darüber zurück, was geändert wurde, welche Prüfungen tatsächlich
12durchgeführt wurden und welche ungelösten Einschränkungen bestehen. Veröffentliche oder deploye nicht.
13
14Überprüfte Ergebnisse:
15[füge die von dir geprüften Ergebnisse ein]

Mache die Übergabe spezifisch

Diese Klammern verdienen echte Antworten. „Mach es besser“ überlässt es dem Agenten, das Ziel zu erfinden. „Zeige den fehlgeschlagenen Export mit einer Wiederholungsaktion, während der ursprüngliche Fehler erhalten bleibt“ gibt euch beiden etwas Konkretes zum Überprüfen.

Halte das überprüfte Ergebnis nahe an der Aufgabe. Wenn die wichtige Einschränkung in einem langen Transkript vergraben ist, führe sie im Briefing aus und füge das unterstützende Gespräch bei.

Die Quelle erklärt, woher die Einschränkung kam. Deine aktuelle Anfrage erklärt, wie sie die heutige Arbeit bestimmt.

4. Die Projektübung: Nimm einen wiederkehrenden Bug durch den gesamten Zyklus

Hier ist eine hypothetische Übung, um den Workflow konkret zu machen. Stell dir vor, dein Projekt erstellt gelegentlich doppelte Exporte nach einer Netzwerkunterbrechung, und ein älteres Gespräch enthält eine Untersuchung des Wiederholungsverhaltens.

1. Schritt 1: Rufe zuerst dieses Gespräch ab. Bitte den Prüfer zu identifizieren, was die frühere Untersuchung festgestellt hat, und überprüfe dann den aktuellen Wiederholungspfad dagegen.
2. Schritt 2: Angenommen, die alte Diskussion besagt, dass Anfragen nach einer unsicheren Antwort wiederholt werden können. Der Prüfer sollte feststellen, ob die aktuelle Implementierung dies immer noch zulässt, welcher Code es steuert und ob es bereits einen Mechanismus gibt, der Duplikate verhindern soll.
3. Schritt 3: Wenn die Beweise eine Änderung unterstützen, briefe den Implementierer bezüglich des Fehlerfalls. Gib an, was eine wiederholte Anfrage tun soll, welches bestehende Exportverhalten erhalten bleiben muss und wie du eine unterbrochene Antwort verifizieren wirst.
4. Schritt 4: Überprüfe dann die Änderung und führe den relevanten Pfad aus. Überprüfe sowohl den erfolgreichen Export als auch die Wiederholung nach Unsicherheit. Wenn die Umgebung die Unterbrechung nicht reproduzieren kann, zeichne diese Einschränkung auf und entscheide, welche weitere Verifizierung erforderlich ist.
5. Schritt 5: Überprüfe schließlich die Lektion, die du behalten könntest: die Bedingungen, die das Duplikat verursacht haben, der Mechanismus, der es adressiert, und die Beweise, die den Fix unterstützen.

Dieses Beispiel ist eine vorgeschlagene Übung, keine Behauptung über einen Bug im Agentic Stack. Ersetze einen echten Fehler aus deinem eigenen Projekt und behalte dieselbe Reihenfolge bei.

5. Die gemeinsame Ebene: Binde den Abruf in deine anderen Tools ein

Der Desktop kann die Integration über Tools → Connections → Use @ in tools → Enable in all four tools installieren. Der entsprechende Befehl ist:

1agentic-stack context install

Starte die Tools danach neu. Der MCP-Eintrag macht die Gesprächssuche, das Lesen ausgewählter Chats und die gemeinsame Gedächtnissuche verfügbar. Integration

Das Picker-Verhalten hängt vom Client ab; wo die Ressourcenvervollständigung nicht verfügbar ist, kann der Agent suchen und passende Gespräche präsentieren. Client-Verhalten

Teste die Kontinuität über Tools hinweg

Meine erste Prüfung wäre, ein anderes Tool zu bitten, dieselbe Entscheidung zu finden, die du gerade überprüft hast. Gib ihm das Thema, bitte es, die passende Quelle zu präsentieren, und bestätige die Auswahl, bevor du um eine Analyse bittest.

Vergleiche dann das Ergebnis mit der Quelle, die du im Desktop überprüft hast. Du testest die Kontinuität des Kontexts über Tools hinweg, also halte die Frage stabil, während du den Ort änderst, an dem du sie stellst.

Ich würde die Quelle auch dann in das endgültige Aufgabenbriefing aufnehmen, wenn eine Entscheidung die Arbeit materiell beeinflusst. „Das haben wir schon mal besprochen“ gibt dem Agenten ein Suchproblem. „Verwende dieses überprüfte Gespräch und verifiziere diese Bedingung“ gibt ihm eine spezifische Verantwortung.

6. Die dauerhafte Ebene: Was verdient es, eine Lektion zu werden

Der Abruf bringt altes Material wieder in den Blick. Du musst immer noch entscheiden, welche Autorität dieses Material haben soll.

Ein Gespräch kann einen aufgegebenen Plan, eine falsche Diagnose oder eine Antwort enthalten, die vernünftig war, bevor sich das Projekt geändert hat. Es aufzubewahren, erlaubt dir, die Argumentation später zu überprüfen; eine Lektion zu akzeptieren, ist eine separate Entscheidung.

Tasks enthält Ausführungsaufzeichnungen. Knowledge → Lessons unterstützt das Staging, Akzeptieren, Ablehnen und erneute Überprüfen von Lektionen mit Gründen, während der importierte Verlauf von akzeptierten Lektionen getrennt bleibt. Überprüfungslebenszyklus

Schreibe eine Lektion, die du anfechten kannst

Ich würde eine vorgeschlagene Lektion mit genügend Details schreiben, um angefochten zu werden: die Bedingung, für die sie gilt, das Verhalten, das sie empfiehlt, der Grund und die Beweise.

Für den hypothetischen Export-Bug ist „immer sicher wiederholen“ zu vage, um zu helfen. Eine nützliche Notiz identifiziert, was eine Wiederholung unsicher macht und wie die Implementierung dieses Projekts wiederholte Arbeit erkennen sollte.

Frage dann, was die Lektion obsolet machen würde. Ein anderes Backend, ein geänderter Vertrag oder ein ersetztes Subsystem könnten die ursprüngliche Einschränkung aufheben. Füge diese Grenze ein, damit eine zukünftige Überprüfung einen Ausgangspunkt hat.

So würde ich verhindern, dass eine nützliche Korrektur zu einer Regel wird, die ihren Grund überlebt.

6.1 Die Speicherstruktur: Platziere jede Art von Wissen an ihrem Platz

Unter dem Desktop trennt die portable .agent/-Architektur den Arbeitsstatus, frühere Episoden, dauerhafte Muster und persönliche Präferenzen. Skills bieten wiederverwendbare Prozeduren, während Protokolle Berechtigungen und Delegation beschreiben. Architektur

• Die aktuelle Untersuchung gehört zur laufenden Arbeit.
• Ihr abgeschlossener Bericht wird zum Beweis dafür, was passiert ist.
• Ein verifiziertes Muster kann zu einer dauerhaften Lektion werden.
• Eine Präferenz darüber, wie du Ergebnisse präsentiert haben möchtest, gehört zu deinen Präferenzen.

Diese Bedeutungen klar zu halten, erleichtert spätere Überprüfungen. Ein temporärer Workaround sollte erklären, wann er entfernt werden kann. Eine persönliche Schreibpräferenz sollte nicht versehentlich zu einer Architekturregel werden.

Verwandle eine verifizierte Prozedur in einen Skill

Das Gleiche gilt für Skills. Ich würde einen Skill erstellen, wenn eine Prozedur nützlich genug ist, um wiederholt zu werden, und spezifisch genug, um ihr zu folgen. Füge die benötigten Eingaben, die wichtigen Schritte, die erwartete Ausgabe und die Bedingungen ein, die eine weitere Entscheidung erfordern.

Für das Export-Beispiel könnte die Untersuchung eine nützliche Regressionsprüfungsprozedur hervorbringen. Speichere diese erst, nachdem du bestätigt hast, dass die Schritte in deinem Projekt funktionieren. Ein kopiertes Transkript gibt dem nächsten Agenten eine Geschichte; eine überprüfte Prozedur gibt ihm eine Methode, die du bewerten kannst.

7. Die Betriebsregeln: Kurz, begrenzt, überprüfbar

Hier sind die Regeln, die ich um den Workflow ab dem ersten Projekt setzen würde.

1. Regel 1: Jedes Briefing nennt das Ergebnis. Eine Überprüfung liefert Ergebnisse mit Beweisen. Eine Implementierung liefert eine Verhaltensänderung mit Prüfungen. Ein Lektionsvorschlag liefert eine Behauptung, die du akzeptieren oder ablehnen kannst.
2. Regel 2: Zugriff folgt der Aufgabe. Die Untersuchung beginnt mit schreibgeschütztem Zugriff; die Implementierung erhält den Umfang, der für die vereinbarte Änderung benötigt wird. Halte Veröffentlichung, Deployment und andere folgenreiche Aktionen explizit in der Anfrage.
3. Regel 3: Bitte um tatsächliche Verifizierung. Der Bericht sollte sagen, was ausgeführt wurde und was passiert ist. Wenn eine Prüfung nicht verfügbar war, mache das sichtbar, anstatt das fehlende Ergebnis stillschweigend als Erfolg zu behandeln.
4. Regel 4: Halte den historischen Kontext den aktuellen Beweisen und anwendbaren Projektanweisungen untergeordnet. Ein abgerufenes Gespräch kann eine frühere Entscheidung erklären, während es dennoch veraltet ist.
5. Regel 5: Überprüfe das Ergebnis, bevor du die Schlussfolgerung behältst. Die Erklärung eines Agenten über seine eigene Arbeit ist etwas, das man zusammen mit dem Diff und dem beobachteten Verhalten überprüfen sollte.

Dies sind Betriebspraktiken für das Setup, das ich beschreibe. Passe sie an dein Projekt an, aber halte die Verantwortlichkeiten klar genug, dass eine andere Person sagen könnte, ob eine Aufgabe ihr Briefing erfüllt hat.

7.1 Die Überprüfungswarteschlange: Mache die Arbeit leicht zu akzeptieren oder zurückzuschicken

Ich würde jede Implementierung bitten, in derselben Form abzuschließen:

• was geändert wurde,
• was verifiziert wurde,
• was unsicher bleibt,
• und ob sie eine wiederverwendbare Lektion vorschlägt.

Das gibt dir eine konsistente Möglichkeit, abgeschlossene Arbeiten zu lesen, ohne jedes Mal das gesamte Gespräch rekonstruieren zu müssen. Die unterstützenden Details können für den Teil, den du überprüfen musst, verfügbar bleiben.

Wenn du etwas zurückschickst, füge die Korrektur an die Anforderung an, die es verfehlt hat. „Das ist falsch“ startet eine weitere Ratespielrunde. „Die Wiederholung erstellt unter dieser Bedingung einen zweiten Export; bewahre die ursprüngliche Anfrageidentität und führe diese Prüfung erneut aus“ identifiziert die Lücke.

Entscheide, was überleben soll

Nachdem die Korrektur bestanden ist, entscheide, ob sie eine wiederkehrende Einschränkung oder ein Detail dieser Aufgabe darstellt. Speichere Ersteres, wenn es Beweise dahinter hat. Letzteres kann in der Historie der Aufgabe bleiben.

Ich würde widerstehen, jeden Überprüfungskommentar in permanenten Speicher zu verwandeln. Einige Korrekturen sind einmal nützlich. Andere offenbaren eine Regel, die spätere Arbeiten prägen sollte. Diese Unterscheidung zu treffen, ist Teil der Wartung des Systems.

Die nützliche Frage am Ende einer Überprüfung ist: Was sollte ein zukünftiger Agent wissen, bevor er eine ähnliche Aufgabe versucht, und wo kann er dieses Wissen verifizieren?

7.2 Die Kostendisziplin: Gib jedem Durchlauf eine Abbruchbedingung

Ich würde eine Abbruchbedingung in jede Aufgabe aufnehmen, die sich weiter ausdehnen könnte. Für eine Überprüfung könnte das ein schriftlicher Bericht über das relevante Verhalten und ungelöste Fragen sein. Für die Implementierung könnte es die vereinbarte Änderung sein, die ihre benannten Prüfungen besteht.

Wenn der Agent ein größeres Problem entdeckt, bitte ihn, den Befund und seine Beziehung zur ursprünglichen Aufgabe zu erklären, bevor du diese Arbeit in die aktuelle Änderung aufnimmst.

Entscheide, ob dies in die aktuelle Aufgabe gehört.

Vergleiche Ergebnisse und setze Grenzen durch

Wähle den Runner und das Modell mit den tatsächlich in deinem Konto verfügbaren Optionen und beurteile sie dann anhand deiner eigenen begrenzten Beispiele. Ich würde die Qualität der Ergebnisse, die erforderlichen Korrekturen und die gelieferte Verifizierung vergleichen, bevor ich eine Konfiguration zum Standard mache.

Halte das Experiment fair, indem du die Aufgabe und das Quellmaterial stabil hältst. Wenn jeder Versuch die Frage, den Kontext und die Akzeptanzkriterien ändert, wird der Vergleich schwer zu interpretieren sein.

Und setze alle Ausgabenkontrollen dort, wo sie tatsächlich von deinen Tools oder deinem Anbieter durchgesetzt werden. Ein Satz, der einen Agenten bittet, wirtschaftlich zu sein, ist eine Präferenz; überprüfe die verfügbaren Kontrollen, bevor du dich auf ein Limit verlässt.

8. Der individuelle Bau: Passe den Arbeitsbereich um einen echten Reibungspunkt herum an

Sobald du den grundlegenden Zyklus abgeschlossen hast, wirst du eine bessere Vorstellung davon haben, was du vom Desktop selbst willst. Vielleicht stört dich ein wiederholter Navigationsschritt, oder eine Aufgabenansicht macht ein Feld schwerer zu überprüfen, als es sein müsste.

Schreibe die Reibung auf, bevor du ein Feature vorschlägst. Beschreibe die Aktion, die du ausführen möchtest, wo du Zeit verlierst und was das verbesserte Verhalten dir ermöglichen würde.

Öffne dann das Quell-Repository und gib deinem Agenten eine begrenzte Änderungsanfrage. Füge hinzu, wie du beabsichtigst, das Ergebnis in der App zu überprüfen.

Baue und überprüfe die Änderung

Das Repository dokumentiert diese Entwicklungs- und Paketierungsbefehle:

1python3 -m pytest -q
2swift build --package-path apps/macos -c release
3python3 scripts/check-desktop-connection.py
4bash scripts/build-macos-app.sh --output ./apps/macos/dist

Entwicklungsbefehle

SwiftUI-Änderungen erfordern einen Neubau und Neustart, um überprüft zu werden. Desktop-Workflow

Ich würde die Interaktion testen, die die Änderung motiviert hat, und einen nahegelegenen Fall, der brechen könnte. Wenn du die Aufgabenfilterung verbesserst, überprüfe die gefilterten Ergebnisse, einen leeren Ergebnissatz und den Weg zurück zur vollständigen Liste.

Verwende denselben Standard, den du auf die Export-Übung angewendet hast: Ein konkretes Vorher, eine begrenzte Änderung und ein beobachtetes Nachher.

8.1 Die Remote-Option: Entscheide, wo die Arbeit leben soll

Nachdem der lokale Workflow funktioniert, möchtest du vielleicht die Ausführung auf einem persistenten Server. Der Self-Hosting-Pfad verbindet die native App mit einem Service mit einem einzigen Besitzer, der seine Projekte, seinen Speicher, seinen Aufgabenverlauf und seine CLI-Anmeldungen besitzt; das Wechseln des Hosts überträgt nicht automatisch die Daten oder Anmeldeinformationen deines Macs. Hosting-Leitfaden

Ich würde diesen Schritt nur aus einem konkreten Grund machen, z. B. um ein Projekt und seine Ausführungsumgebung auf einem Rechner zu behalten, den du bereits wartest. Halte diesen Grund schriftlich fest, bevor du die Bereitstellungsarbeit übernimmst.

Befolge die Hosting-Anleitung für die unterstützte Konfiguration, Authentifizierung und Verifizierungsschritte. Behandle den Server wie eine weitere Arbeitsumgebung mit eigenem Zustand, den es zu überprüfen gilt.

Überprüfe die ausgewählte Umgebung

Führe dann dort eine vertraute Aufgabe aus. Überprüfe das ausgewählte Projekt, bestätige, dass der Agent auf die gewünschte Quelle zugreifen kann, und verifiziere, dass das Ergebnis zur von dir gewählten Serverumgebung gehört.

Die Verwendung einer bekannten Aufgabe erleichtert die Bewertung des Übergangs. Wenn du Host, Projekt und Workflow gleichzeitig änderst, wird es schwieriger zu erkennen, welche Änderung ein überraschendes Ergebnis verursacht hat.

Lokal reicht aus, um das grundlegende Muster zu erlernen. Erweitere die Infrastruktur, wenn die Arbeit dir einen Grund dafür gibt.

9. Skalierung: Deckung dort hinzufügen, wo der vorherige Zyklus eine Lücke offenbart hat

Ich würde dieses Setup basierend auf dem fehlenden Kontext erweitern, der bei realen Aufgaben auftritt.

• Wenn eine Überprüfung eine frühere Architekturdiskussion benötigte, importiere diese Diskussion.
• Wenn die Implementierung wiederholt dasselbe Verfahren erforderte, entwickle und verifiziere eine Fähigkeit (Skill).
• Wenn eine Entscheidung immer wieder neu aufgerollt wird, schreibe eine abgegrenzte Lektion mit den Belegen, die sie stützt.

Behalte eine kleine Sammlung von Fragen, deren Antworten du bereits kennst. Verwende sie, nachdem du deine Importe oder deinen Workflow geändert hast: Finde diese Entscheidung, erkläre diese Einschränkung, identifiziere den Code, der sie implementiert, und markiere den Teil, der nicht mehr aktuell ist.

Erweitere, wenn die Arbeit es rechtfertigt

Ich würde nur dann eine weitere Agentenrolle hinzufügen, wenn ihre Verantwortung aus der Arbeit klar hervorgeht. Eine wiederkehrende Dokumentationsüberprüfung kann ein dediziertes Briefing rechtfertigen. Eine einmalige Anfrage passt möglicherweise perfekt in eine bestehende Rolle.

Erweitere die Teile, die sich ihren Platz verdient haben. Halte den Rest einfach genug, um zu verstehen, was schiefgeht, wenn etwas schiefgeht.

9.1 Die Wartungsgewohnheit: Überprüfe das Wissen, wenn sich das System ändert

Ich würde die relevanten Lektionen immer dann überprüfen, wenn sich ein Subsystem so weit ändert, dass seine Annahmen beeinflusst werden. Nutze die Änderung selbst als Auslöser: eine neue Abhängigkeit, eine ausgetauschte Speicherschicht, eine andere Bereitstellungsumgebung oder eine überarbeitete Produktanforderung.

Frage, welche bestehenden Lektionen vom alten Verhalten abhängen, und überprüfe dann diese Quellen zusammen mit der Änderung. Behalte, was weiterhin gültig ist, überarbeite, was einen engeren Geltungsbereich benötigt, und entferne, was nicht mehr zutrifft, über den verfügbaren Überprüfungs-Workflow.

Der wichtige Teil ist die Bewahrung der Erklärung. Ein zukünftiger Entwickler sollte verstehen können, warum die frühere Regel existierte und was sich genug geändert hat, um sie zu ersetzen.

Prozeduren aktualisieren und Konflikte auflösen

Führe bei Fähigkeiten (Skills) die Prozedur erneut aus, nachdem eine Änderung ihre Eingaben oder Befehle beeinflusst hat. Wenn ein Schritt nicht mehr funktioniert, aktualisiere die Prozedur basierend auf dem beobachteten Fehler und wiederhole die entsprechende Überprüfung.

Dies hält die Wartung mit realen Ereignissen im Projekt verbunden. Du überprüfst das Wissen, das am wahrscheinlichsten veraltet ist, mit aktuellen Belegen direkt vor dir.

Wenn bei einer Aufgabe widersprüchliche Notizen auftauchen, mache die Lösung dieses Konflikts zu einem Teil der Überprüfung. Identifiziere, welche Aussage für die aktuelle Version gilt, und hinterlasse das Ergebnis klar genug, dass der nächste Agent der Argumentation folgen kann, ohne die gesamte Untersuchung zu wiederholen.

Hinterlasse eine nützliche Übergabe

Hinterlasse vor der nächsten Sitzung eine kurze Übergabe, die das verifizierte Ergebnis, die offene Frage und die Quelle beschreibt, die ein anderer Agent zuerst lesen sollte. Halte es spezifisch für den Projektzustand, den du tatsächlich überprüft hast.

Das gibt der morgigen Arbeit einen nachvollziehbaren Ausgangspunkt, besonders wenn du über ein anderes Tool oder nach einer längeren Pause zurückkehrst, wobei die ursprüngliche Argumentation noch verfügbar ist.

10. Der Bauplan

1. Wähle ein vertrautes Repository und eine Entscheidung, die du erkennen kannst.
2. Baue den Desktop, schließe das Setup ab und importiere ein abgeschlossenes Gespräch, das diese Entscheidung enthält.
3. Suche danach, überprüfe die Quelle und hänge sie an eine schreibgeschützte Überprüfung des aktuellen Codes an.
4. Überprüfe die Ergebnisse selbst, briefe dann eine abgegrenzte Implementierung mit einer sichtbaren Akzeptanzbedingung.
5. Überprüfe den Diff und führe die entsprechende Verifizierung durch, einschließlich des Fehlerfalls, der die Arbeit motiviert hat.
6. Erstelle eine Lektion nur dann, wenn das Ergebnis sie unterstützt, mit festgehaltenem Umfang und Grund.
7. Verwandle eine Prozedur in eine Fähigkeit (Skill), wenn du verifiziert hast, dass sie sich zu wiederholen lohnt.
8. Versuche denselben Abruf mit einem anderen Tool und erweitere dann deinen Kontext oder deine Infrastruktur, wenn eine reale Aufgabe es erfordert.

Beginne diese Woche mit einer Entscheidung und führe sie durch den gesamten Zyklus, bevor du deine gesamte Historie importierst.

Der nächste Agent sollte dein Urteilsvermögen erben.