---
title: "Leitfaden für Claude Code Loop Engineering: 4 Loops und sichere Automatisierung"
locale: de
category: tutorial
category_name: "Tutorial"
translation_status: reviewed
license: cc_by
author: "naikeu"
source_url: https://injoys.com/en/articles/claude-code-loop-engineering-guide
published_at: 2026-07-17T09:40:17+09:00
---

# Leitfaden für Claude Code Loop Engineering: 4 Loops und sichere Automatisierung

> Ein Loop in Claude Code ist eine Kontrollstruktur, die einen Agent Beobachtung, Aktion und Validierung bis zum Erreichen einer Abbruchbedingung wiederholen lässt. Erläutert werden die Unterschiede zwischen den vier Loop-Typen sowie praxisnahe Entwurfsmethoden, die Validierungsnachweise, Zwangsabbruch, Idempotenz, Kosten und minimale Berechtigungen berücksichtigen.

## Key Points

- Ein Loop in Claude Code ist keine Programmierschleife, sondern eine Ausführungsstruktur für Agents, die Beobachtung, Aktion und Validierung bis zu einer Abbruchbedingung wiederholt.
- Turn-based übergibt dem System das Validierungsverfahren, Goal-based die Entscheidung über den Abschluss, Time-based den Zeitpunkt der erneuten Ausführung und Proactive den Arbeitsbeginn sowie die Orchestrierung.
- Ein guter Loop benötigt messbare Abschlussbedingungen, externe Validierungsnachweise, einen Zwangsabbruch, Idempotenz und minimale Berechtigungen.
- Da das Bewertungsmodell von `/goal` nur die im Gespräch ersichtlichen Nachweise beurteilt, müssen Testausgaben, Exit-Codes und der Änderungsumfang eindeutig angegeben werden.
- Deterministische Transformationen sollten mit einem Script verarbeitet werden; Dynamic Workflow und mehrere Agents sollten nur bei umfangreichen Aufgaben eingesetzt werden, die echte Parallelität erfordern.

Der Loop von Claude Code ist nicht einfach eine Funktion, mit der ein Modell länger ausgeführt wird. Im Kern geht es darum, rund um einen probabilistisch handelnden AI Agent **Trigger, Verifier, Success condition, Hard stop und Permission boundary** zu platzieren und so wiederkehrende Aufgaben in ein kontrollierbares System zu verwandeln. Dieser Artikel fasst die Unterschiede zwischen Turn-based, Goal-based, Time-based und Proactive Loop sowie praktische Gestaltungsprinzipien zusammen.

## 1. Was ist ein Loop in Claude Code?

Ein Loop ist hier keine `for`- oder `while`-Anweisung einer Programmiersprache. Der vom Claude Code-Team beschriebene Loop ist eine Ausführungsstruktur, in der ein Agent den aktuellen Zustand beobachtet, handelt, das Ergebnis überprüft und die Arbeit wiederholt, bis die Abbruchbedingung erfüllt ist.

```text
Aufgabe starten
  ↓
Zustand und Code erfassen
  ↓
Plan erstellen
  ↓
Code ändern oder Tool ausführen
  ↓
Testen und überprüfen
  ↓
Abschlussbedingung erfüllt?
  ├─ Nein: nächste Wiederholung
  └─ Ja: beenden und Ergebnis melden
```

Zur Unterscheidung von Loops sind die folgenden vier Fragen hilfreich.

1. Was löst die Aufgabe aus?
2. Was beendet die Aufgabe?
3. Welche Funktion von Claude Code steuert die Wiederholung?
4. Für welche Art von Aufgabe eignet sie sich?

Nicht jede Aufgabe muss in einen komplexen Loop umgewandelt werden. Bei Aufgaben, deren Ergebnis sofort überprüfbar ist, etwa der Korrektur eines Tippfehlers in einer Datei oder einer einfachen Umbenennung, ist ein normaler Prompt effizienter. Ein Loop sollte nur gewählt werden, wenn tatsächlich mehrere Beobachtungs-, Änderungs- und Überprüfungsdurchläufe erforderlich sind.

## 2. Vergleich der vier Loop-Typen

| Typ | Startbedingung | Abbruchbedingung | Hauptsächlich verwendete Funktionen | Geeignete Aufgaben | Vom Menschen übertragene Verantwortung |
|---|---|---|---|---|---|
| Turn-based | Prompt des Benutzers | Wenn Claude die Aufgabe für abgeschlossen hält oder zusätzliche Informationen benötigt | Normale Konversation, Skills, Test- und Browser-Tools | Kurze, einmalige Implementierungen und Änderungen | Wiederholter Überprüfungsprozess |
| Goal-based | Benutzer legt Abschlussbedingungen fest | Evaluierungsmodell bestätigt die Erfüllung oder Benutzer bricht ab | `/goal`, bei Bedarf Auto mode | Aufgaben mit messbarem Abschlusszustand wie Tests, Builds und Migrationen | Entscheidung über den Abschluss |
| Time-based | Festgelegte Zeit, Intervall oder Zeitplan | Benutzer bricht ab oder externe Aufgabe endet | `/loop`, `/schedule` | Überwachung von PR, CI und Deployments, regelmäßige Zusammenfassungen, Status-Polling | Zeitpunkt der nächsten Ausführung |
| Proactive | Zeitplan, API, GitHub-Event usw. | Ziel der einzelnen Aufgabe erfüllt, Routine deaktiviert | Routines, `/goal`, Skills, Dynamic Workflows, Auto mode | Laufende Aufgaben wie Issue-Klassifizierung, Fehlerbehandlung und umfangreiche Migrationen | Erkennung von Aufgaben, Prompt-Ausführung, Orchestrierung |

Der Kern dieser Einteilung ist nicht, „wie intelligent die AI ist“, sondern **welche Kontrollverantwortung der Mensch an das System überträgt**. Bei Turn-based erstellt der Mensch den nächsten Prompt, bei Goal-based überträgt er die Entscheidung über den Abschluss und bei Time-based den Zeitpunkt der erneuten Ausführung. In der Proactive-Stufe geht auch die Verantwortung dafür, das Auftreten einer Aufgabe zu erkennen und den passenden Prompt auszuführen, auf das System über.

## 3. Turn-based Loop: Den Überprüfungsprozess übertragen

Der Turn-based Loop ist die grundlegende Form, in der die meisten Entwickler Claude Code verwenden.

```text
Mensch → Claude → Mensch → Claude
```

Wenn der Benutzer eine Anfrage stellt, sucht Claude die relevanten Dateien, ändert den Code, führt Tests aus und meldet das Ergebnis. Intern können mehrere Beobachtungs-, Handlungs- und Überprüfungsschritte stattfinden, doch die Befugnis, die nächste Aufgabe zu starten, bleibt beim Benutzer.

### Codeänderung und Funktionsabschluss sind nicht dasselbe

Auch wenn Claude meldet, „Implementierung und Tests abgeschlossen“ zu haben, können im tatsächlichen Produkt noch folgende Probleme bestehen.

- Nach einem Klick auf eine Schaltfläche ändert sich der Zustand nicht.
- In der Browserkonsole tritt ein Fehler auf.
- Das mobile Layout ist beschädigt.
- Attribute für die Barrierefreiheit fehlen.
- Die Tests bestehen, aber der tatsächliche Ablauf im Browser schlägt fehl.
- Es wurden auch Dateien geändert, die nichts mit der Änderung zu tun haben.

Das Abschlusskriterium sollte daher nicht lauten „Der Code wurde geändert“, sondern „Die Funktion wurde anhand externer Nachweise bestätigt“.

### Überprüfungen mit `SKILL.md` wiederverwenden

Ein Skill ist eine Methode, wiederholt verwendete Anweisungen und Abläufe in `SKILL.md` zu speichern. Claude kann einen Skill automatisch laden, wenn es ihn für relevant hält, oder er kann direkt mit `/skill-name` ausgeführt werden. Statt lange Betriebsabläufe immer in `CLAUDE.md` aufzunehmen, lässt sich der Context effizienter nutzen, wenn sie getrennt und nur bei Bedarf als Skill geladen werden.

```markdown
---
name: verify-ui-change
description: Überprüft UI-Änderungen in der tatsächlichen Ausführungsumgebung, bevor sie als abgeschlossen gelten.
---

# Überprüfung von UI-Änderungen

1. Den Entwicklungsserver starten.
2. Die geänderte Ansicht im Browser öffnen.
3. Das neue Steuerelement tatsächlich bedienen.
4. Prüfen, ob die erwartete Zustandsänderung eintritt.
5. Browserkonsole auf neue Fehler und Warnungen prüfen.
6. Barrierefreiheit und wichtige Leistungskennzahlen prüfen.
7. Bei einem Fehlschlag korrigieren und die Überprüfung von vorn beginnen.
8. Nachweise wie ausgeführte Befehle, Ergebnisse und Screenshots melden.
```

Ein guter Skill enthält keine abstrakten Ermahnungen, sondern eine ausführbare Checkliste. „Sorgfältiger prüfen“ ist eine wesentlich schwächere Regel als „Prüfen, ob `npm test` mit Exit-Code 0 endet“.

### Aussagekraft von Überprüfungsnachweisen

| Nachweis | Vertrauenswürdigkeit | Grund |
|---|---:|---|
| Erklärung des Agent „Es scheint ordnungsgemäß zu funktionieren“ | Niedrig | Nur eine Schlussfolgerung, kein Ausführungsergebnis |
| Code-Diff und statische Prüfung | Mittel | Die Änderungen sind sichtbar, das Runtime-Verhalten wird jedoch nicht bestätigt |
| Tatsächliche Testausgabe und Exit-Code | Hoch | Es liegt ein reproduzierbares externes Ergebnis vor |
| Browserinteraktion, Screenshots, Konsolen- und Leistungsergebnisse | Sehr hoch | Benutzerpfad und Runtime-Zustand werden direkt überprüft |
| Unabhängiger Review Agent und CI kommen zum gleichen Ergebnis | Sehr hoch | Verringert den Selbstbestätigungs-Bias des implementierenden Agent |

In der offiziellen Dokumentation von Claude Code werden auch bundled Skills wie `/run` zur Prüfung einer laufenden Anwendung und `/verify` zur Überprüfung von Änderungen in der tatsächlichen Ausführungsumgebung erläutert. Wenn die Ausführung eines Projekts komplex ist, ist es sicherer, den exakten Startbefehl, die Umgebungsvariablen und den Ablauf der Datenvorbereitung in einem teamspezifischen Skill festzuhalten.

## 4. Goal-based Loop: Die Entscheidung über den Abschluss übertragen

Bei einem Goal-based Loop entscheidet der Benutzer nicht jedes Mal, ob „noch ein weiterer Durchlauf“ erfolgen soll. Der Benutzer definiert den Abschlusszustand, und Claude setzt die Arbeit über mehrere Turns fort, bis diese Bedingungen erfüllt sind.

```text
Benutzer legt Goal fest
  ↓
Arbeits-Turn von Claude
  ↓
Separates Evaluierungsmodell prüft Abschlussbedingungen
  ├─ Nicht erfüllt: Grund wird an den nächsten Turn übergeben
  └─ Erfüllt: Goal wird beendet
```

`/goal` ist laut Dokumentation ab Claude Code v2.1.139 verfügbar. In einer Session kann nur ein Goal aktiv sein.

### Was das Evaluierungsmodell tatsächlich sieht

Am Ende jedes Turns prüft ein separates small fast model die Abschlussbedingungen und den Inhalt der Konversation und entscheidet zwischen `erfüllt` und `nicht erfüllt`. Standardmäßig wird ein Evaluierungsmodell der Haiku-Familie verwendet. Eine wichtige Einschränkung besteht darin, dass das Evaluierungsmodell Dateien nicht direkt liest und Tests nicht separat ausführt.

Claude, das die Aufgabe ausführt, muss daher die folgenden Nachweise deutlich in der Konversation hinterlassen.

- Ausgeführte Befehle
- Anzahl der Tests und Ergebnisse zu Erfolg oder Fehlschlag
- Exit-Code
- Build-Ergebnis
- Liste der geänderten Dateien
- Ursachen verbleibender Fehler
- Bestätigung, dass die Bereichsbeschränkungen eingehalten wurden

Das Evaluierungsmodell beurteilt nicht, „was tatsächlich geschehen ist“, sondern „welche Nachweise in der Konversation sichtbar sind“.

### Die vier Elemente eines guten Goal

Ein gutes Goal enthält die folgenden vier Elemente.

1. **Messbare Erfolgskriterien**: bestandene Tests, erfolgreicher Build, geleerte Queue, erreichter Schwellenwert
2. **Überprüfungsmethode**: Festlegung, mit welchem Befehl oder Tool der Erfolg nachgewiesen wird
3. **Beschränkung des Änderungsbereichs**: veränderbare Verzeichnisse, verbotene Dateien, zulässige Side effects
4. **Erzwungene Abbruchbedingungen**: maximale Anzahl von Turns, maximale Dauer, Anzahl aufeinanderfolgender Fehlschläge, Abbruch bei Berechtigungsfehlern

```text
/goal Alle auth-bezogenen Tests und lint müssen erfolgreich sein,
und git diff darf nur src/auth und die zugehörigen Testdateien enthalten.
In jedem Turn werden Ausführungsergebnisse und Exit-Codes gemeldet.
Beim Erreichen von maximal 12 Turns oder 45 Minuten abbrechen
und die verbleibenden Fehler zusammenfassen.
```

Die zentralen Abbruchbedingungen von `/goal` selbst sind die Erfolgsentscheidung des Evaluierungsmodells oder `/goal clear` durch den Benutzer. Um ein Turn- oder Zeitlimit zu erzwingen, muss es ausdrücklich in den Goal-Bedingungen angegeben werden.

### Gute und schlechte Bedingungen

| Gute Bedingung | Schlechte Bedingung |
|---|---|
| `npm test` endet mit Exit-Code 0 | Den Code perfekt machen |
| Alle 48 Authentifizierungstests bestehen | Die Benutzererfahrung so weit wie möglich verbessern |
| Alle API-Aufrufstellen wurden auf das neue Interface umgestellt und der Build ist erfolgreich | Zu einer besseren Struktur refaktorieren |
| Die Queue der zu bearbeitenden Issues ist leer und für jedes Issue wurde das Ergebnis erfasst | So viele Issues wie möglich bearbeiten |

Mehrdeutige Ziele können zu früh beendet werden oder endlose Verbesserungsdurchläufe auslösen.

### Statusprüfung und Abbruch

- `/goal`: Aktive Bedingungen, Ausführungsdauer, Anzahl der Evaluierungs-Turns, Token-Nutzung und jüngste Evaluierungsgründe prüfen
- `/goal clear`: Aktives Goal abbrechen
- Neues Goal festlegen: Bestehendes Goal ersetzen
- `--resume` oder `--continue`: Unvollständiges Goal wiederherstellen

Bei der Wiederaufnahme bleiben die Bedingungen erhalten, doch Turn-Anzahl, Zeit und Token-Basiswert können zurückgesetzt werden. Daher sollte der Hard stop zusammen mit Betriebskennzahlen verwaltet werden.

### `/goal` und Berechtigungen sind getrennte Aspekte

`/goal` startet lediglich automatisch den nächsten Turn und erweitert keine Tool-Berechtigungen. Wenn das Schreiben von Dateien, Testbefehle oder Git-Aktionen genehmigungspflichtig sind, kann auch während eines Goal eine Genehmigung erforderlich sein.

Für eine unbeaufsichtigte Ausführung kann zusätzlich Auto mode verwendet werden. Auto mode bedeutet jedoch nicht, dass „alle Tools bedingungslos erlaubt“ sind. Ein Klassifikator blockiert Aktionen, die destruktiv, schwer rückgängig zu machen oder auf Ziele außerhalb der Vertrauensgrenze gerichtet sind. Explizite `ask`- und `deny`-Regeln werden vor dem Klassifikator angewendet.

## 5. Time-based Loop: Den Zeitpunkt der erneuten Ausführung übertragen

Während ein Goal-based Loop die Frage „Wann soll die Arbeit enden?“ behandelt, befasst sich ein Time-based Loop mit der Frage „Wann soll sie erneut ausgeführt werden?“. Er eignet sich für Aufgaben, bei denen sich der Zustand eines externen Systems mit der Zeit verändert.

- Prüfen, ob ein PR neue Reviews erhalten hat
- Prüfen, ob CI oder Deployment abgeschlossen ist
- Status eines lang laufenden Builds prüfen
- Tägliche Zusammenfassung von Slack-Nachrichten
- Prüfung neuer Einträge in einer Issue-Queue

### `/loop`: Wiederholte Ausführung innerhalb der aktuellen Session

```text
/loop 10m Aktuellen PR prüfen und neue Reviews berücksichtigen.
Falls CI fehlgeschlagen ist, Ursache analysieren und beheben.
```

Die wichtigsten in der aktuellen Dokumentation beschriebenen Formen sind folgende.

| Eingabe | Verhalten |
|---|---|
| `/loop 5m <prompt>` | Prompt in einem festgelegten festen Intervall ausführen |
| `/loop <prompt>` | Claude wählt bei jeder Wiederholung das Intervall |
| `/loop` | built-in Wartungs-Prompt oder `loop.md` des Projekts ausführen |
| `/loop 20m /review-pr 1234` | Zulässigen Skill im festgelegten Intervall erneut ausführen |

`/loop` ist an die aktuelle Claude Code-Session gebunden. Computer und Session müssen weiterlaufen; beim Start einer neuen Konversation gehen die Aufgaben im Session-Umfang verloren. Nicht abgelaufene Aufgaben können mit `--resume` oder `--continue` wiederhergestellt werden, wiederkehrende Aufgaben laufen jedoch standardmäßig 7 Tage nach ihrer Erstellung ab. Verpasste Intervalle werden nicht vollständig nachträglich ausgeführt.

Da der Session-Scheduler Jitter anwenden kann, eignet er sich möglicherweise nicht für betriebliche Anforderungen, bei denen eine Ausführung „zwingend zur exakten Uhrzeit“ erfolgen muss.

### `/schedule`: Von Anthropic verwaltete Cloud Routine

`/schedule` erstellt eine Routine, die Prompt, Repository, Connector und Trigger kombiniert und auf einer von Anthropic verwalteten Infrastruktur ausgeführt wird. Sie kann auch bei geschlossenem Notebook ausgeführt werden und wird in der offiziellen Dokumentation als Research Preview bezeichnet.

Eine Routine unterstützt folgende Trigger.

- Wiederkehrender Zeitplan
- Einmaliger Termin zu einem bestimmten zukünftigen Zeitpunkt
- Authentifizierter API-Aufruf
- GitHub Pull request- oder Release-Event

Mit einer Routine können mehrere Trigger verbunden werden. Beispielsweise kann eine PR Review Routine jede Nacht ausgeführt werden und zugleich auf das Event `pull_request.opened` reagieren.

### Vergleich von `/loop` und `/schedule`

| Kriterium | `/loop` | `/schedule` Routine |
|---|---|---|
| Ausführungsort | Aktueller Computer und aktuelle Session | Von Anthropic verwaltete Cloud |
| Ausführung nach Ausschalten des Computers | Im Allgemeinen nicht möglich | Möglich |
| Offene Session erforderlich | Erforderlich | Nicht erforderlich |
| Lokale nicht committete Dateien | Zugriff möglich | Kein Zugriff, Repository wird bei jeder Ausführung neu geklont |
| Mindestintervall | Laut offizieller Dokumentation 1 Minute | Laut offizieller Dokumentation 1 Stunde |
| Persistenz | Session-zentriert, wiederkehrende Aufgaben laufen nach 7 Tagen ab | Im Konto gespeicherte Routine |
| Berechtigungs-Prompt | Übernimmt Richtlinie der aktuellen Session | Autonome Ausführung ohne interaktive Genehmigung |
| Geeigneter Einsatz | Kurzzeitige Überwachung von PR und Deployment | Kontinuierliche Betriebsautomatisierung |

### Wann Events besser sind als Polling

Wird ein PR, der sich nur selten ändert, jede Minute geprüft, enden die meisten Ausführungen, ohne dass etwas geschieht. Wenn das externe System Events senden kann, ist folgende Struktur effizienter.

```text
CI-Fehler oder PR-Aktualisierung
  ↓
GitHub Trigger oder Routine API
  ↓
Claude nur bei Bedarf ausführen
```

Ein Event-basiertes Design verringert Verzögerungen sowie unnötige Modellaufrufe und Token-Verbrauch. Wenn Polling unvermeidbar ist, sollte das Intervall an die tatsächliche Änderungshäufigkeit angepasst und bei längerer Inaktivität Backoff angewendet werden.

### Unverzichtbare Bedingungen für zeitbasierte Aufgaben

1. **Idempotenz**: Auch wenn dasselbe Event mehrfach empfangen wird, dürfen keine doppelten Kommentare, PRs oder Deployments entstehen.
2. **Verarbeitungsstatus**: Die zuletzt verarbeitete Event ID, Commit SHA, Review Comment ID usw. müssen erfasst werden.
3. **Abschlusszustand**: Der Abschluss muss anhand von Zuständen wie PR merge oder close, Queue empty, Deploy success oder rollback bestimmbar sein.
4. **Schreibbereich**: Side effects müssen eingeschränkt werden, etwa Kommentare erlaubt, Merge verboten und Push nur auf einen `claude/*` Branch.
5. **Fehlerbehandlung**: Bei Ausfällen externer Dienste, abgelaufener Authentifizierung, Rate limit oder unzureichenden Berechtigungen sind Regeln für Wiederholungsversuche und Escalation erforderlich.

## 6. Proactive Loop: Aufgabenerkennung und Orchestrierung übertragen

Ein Proactive Loop ist kein einzelner Befehl, sondern eine Architektur für kontinuierliche Automatisierung, die mehrere Funktionen kombiniert.

```text
Trigger
+ Goal
+ Skills
+ Dynamic Workflow
+ Auto mode
+ Repository-, Connector-, Browser- und CI-Tools
```

Auch ohne dass ein Mensch in Echtzeit einen Prompt eingibt, werden neue Aufgaben erkannt, verarbeitet und überprüft sowie die Ergebnisse gemeldet.

### Beispiel: Automatische Verarbeitung von Fehlerfeedback

```text
GitHub Issue oder Slack-Feedback empfangen
  ↓
Duplikat, Priorität und Reproduzierbarkeit klassifizieren
  ↓
Reproduktionstest erstellen
  ↓
Lösungskandidaten untersuchen
  ↓
Ausgewählte Lösung implementieren
  ↓
Unabhängiger Review Agent sucht Gegenbeispiele
  ↓
Tests, Build und Sicherheitsprüfung
  ↓
Draft PR und Ergebnisbericht
```

Die Zuständigkeiten der einzelnen Komponenten sind folgende.

| Komponente | Verantwortung |
|---|---|
| Trigger oder `/schedule` | Bestimmen, wann eine neue Aufgabe gestartet wird |
| `/goal` | Definieren, was bei dieser Ausführung als abgeschlossen gilt |
| Skill | Abläufe für Reproduktion, Implementierung, Überprüfung und Berichterstattung standardisieren |
| Dynamic Workflow | Parallele Ausführung mehrerer Subagents und bedingte Verzweigung |
| Auto mode | Zulässige Tool-Aufrufe ohne Warten auf eine Genehmigung ausführen |
| Permission policy | Verbotene, genehmigungspflichtige und automatisch erlaubte Bereiche festlegen |

### Dynamic Workflow und Worktree

Bei einem Dynamic Workflow führt die Runtime ein von Claude erstelltes JavaScript-Orchestrierungs-Script aus. Bei normalen Subagent-Aufrufen wählt Claude in jedem Turn den nächsten Agent aus. In einem Workflow werden Loop, Parallelverarbeitung, Verzweigungen und Speicherung von Zwischenergebnissen dagegen in das Script verlagert.

```text
Workflow Script
  ├─ Agent A: Anforderungsanalyse
  ├─ Agent B: Testentwurf
  ├─ Agent C: Untersuchung von Implementierungskandidaten
  ├─ Agent D: Sicherheitsprüfung
  └─ Judge: Evidenzbasierter Vergleich
```

Da Zwischenergebnisse nicht im Context der Hauptkonversation, sondern in Script-Variablen verbleiben, lassen sich umfangreiche Aufgaben reproduzierbarer organisieren. In der aktuellen Dokumentation werden Runtime-Grenzen von gleichzeitig bis zu 16 Agents und bis zu 1.000 Agents pro Ausführung genannt. Einschränkungen in der Preview-Phase des Produkts können sich jedoch ändern.

Wenn mehrere Implementierungskandidaten gleichzeitig getestet werden müssen, können die Arbeitsbereiche mit Git Worktree getrennt werden.

```text
repo/
worktree-solution-a/
worktree-solution-b/
worktree-solution-c/
```

Wenn jeder Agent in einem unabhängigen Branch und Verzeichnis arbeitet, sinkt das Risiko, dass dieselben Dateien gleichzeitig überschrieben werden. Der Judge Agent sollte die Kandidaten anhand der Erfüllung der Anforderungen, der Testergebnisse, des Regressionsrisikos, des Änderungsumfangs, der Komplexität, der Leistung, der Sicherheit und der Konsistenz mit der bestehenden Architektur vergleichen.

### Mehr Agents sind nicht immer besser

Wenn bei einer Aufgabe keine Parallelität möglich ist, erhöhen zusätzliche Agents lediglich Kosten und Verzögerungen. Teilen mehrere Agents dieselbe falsche Annahme, können sich Fehler sogar verstärken.

Ein Dynamic Workflow eignet sich für folgende Fälle.

- Migration, bei der dieselbe Transformation auf Hunderte Dateien angewendet wird
- Sicherheits- oder Qualitäts-Audit der gesamten Codebasis
- Vergleich von Plans aus mehreren unabhängigen Perspektiven
- Research, bei dem viele Elemente aufgeteilt verarbeitet und gegenseitig überprüft werden müssen
- Aufgaben, bei denen nicht alle Zwischenergebnisse in den Context eines einzelnen Agent passen

Für kleine Fehlerkorrekturen, Refaktorierungen einer einzelnen Datei oder einfache Ergänzungen von Tests sind ein normaler Turn-based Loop oder `/goal` besser geeignet.

## 7. System zur Wahrung der Codequalität in Loops

Die Qualität der Loop-Ergebnisse hängt nicht nur vom Modell selbst, sondern in hohem Maße auch vom Überprüfungssystem rund um das Modell ab.

### 7.1 Die Codebasis aufräumen

Claude orientiert sich stark an Mustern des bestehenden Codes. Wenn veraltete APIs, doppelte Implementierungen, unklare Teststrukturen, riesige Module oder inkonsistente Regeln für die Ausnahmebehandlung vorhanden sind, kann ein Loop diese Probleme schnell vervielfältigen.

Folgende Grundlagen sind unverzichtbar.

- Formatter und lint
- Klare Verzeichnis- und Modulgrenzen
- Vertrauenswürdige Unit-, Integration- und E2E Tests
- Unterscheidung zwischen verwendeten APIs und Deprecated APIs
- Projektspezifische Entwicklungsregeln
- Reproduzierbare Build- und Dev-Umgebung

### 7.2 Definition of Done nach Änderungstyp erstellen

| Änderungstyp | Mindestüberprüfung |
|---|---|
| API | Vertragstests, Abwärtskompatibilität, Aktualisierung von Schema und Dokumentationsbeispielen |
| Frontend | Tatsächliche Browserbedienung, Konsolenfehler, Barrierefreiheit, responsive Darstellung |
| Database | Forward- und Rollback Migration, Lock-Umfang, Ausführungsplan |
| Dependency | Build, wichtige Regressionstests, License- und Security-Prüfung |
| Infrastructure | Plan Diff, geringstmögliche Berechtigungen, Rollback, Prüfung auf Offenlegung geheimer Informationen |

Statt diese Kriterien in jedem Prompt ausführlich zu wiederholen, sollten sie besser in Skill, Hook, Script oder CI Rule festgeschrieben werden.

### 7.3 Aktuelle Dokumentation und exakte Versionen bereitstellen

Ein Loop kann falsche Annahmen mehrfach wiederholen. Die im Projekt verwendete exakte Version, offizielle Dokumentation, interne Architecture-Dokumentation, API-Spezifikationen, Migration Guide und genehmigte Beispiele müssen leicht auffindbar sein.

### 7.4 Implementierenden Agent und Review Agent trennen

Ein Agent, der etwas implementiert hat, ist bereits durch das gewählte Design und die zugrunde liegenden Schlussfolgerungen beeinflusst. Ein Review Agent mit neuem Context kann folgende Fragen unabhängiger stellen.

- Wurden Tests abgeschwächt, damit sie bestehen?
- Wurden Dateien außerhalb des vorgesehenen Bereichs geändert?
- Wurde eine Sicherheitsgrenze verletzt?
- Fehlen Tests für Fehlerpfade und Grenzwerte?
- Sind Regressionen bestehender Funktionen entstanden?

Ein Review Prompt ist wirksamer, wenn er statt „Fasse die guten Aspekte zusammen“ etwa lautet: „Gehe davon aus, dass die Implementierung falsch ist, suche Gegenbeispiele und füge jedem Kritikpunkt reproduzierbare Nachweise hinzu.“

### 7.5 Einzelne Fehlschläge in Systemverbesserungen überführen

Wenn derselbe Fehler wiederholt auftritt, reicht es nicht, nur das jeweilige Ergebnis zu korrigieren. Damit sich diese Fehlerart schwerer wiederholen kann, muss eines der folgenden Elemente geändert werden.

- Regression Test hinzufügen
- Überprüfungsprozess des Skill verschärfen
- Regel zu `CLAUDE.md` hinzufügen
- Hook oder lint Rule hinzufügen
- Berechtigungsregel `deny` hinzufügen
- Abschlussbedingungen des Goal verschärfen
- Review Checklist ergänzen

Gutes Loop Engineering bedeutet nicht, einen einzelnen Fehler zu beheben, sondern **ein System zu schaffen, in dem diese Art von Fehler schwerer erneut auftreten kann**.

## 8. Token- und Kostenmanagement

Die Kosten eines Loop können deutlich höher sein als die eines einzelnen Prompt.

```text
Gesamtkosten ≈
Kosten der Turns des Haupt-Agent
+ Kosten der Goal-Evaluierung
+ Kosten der Subagents
+ Kosten der Workflow-Wiederholungen
+ Context-Kosten für das Lesen von Tool-Ergebnissen
+ Häufigkeit zeitbasierter Ausführungen
```

Die genaue Abrechnung hängt von Plan, Model und Provider ab, die Prinzipien zur Bestimmung der Kostenstruktur bleiben jedoch gleich.

### Praktische Prinzipien zur Kostensenkung

1. **Für kleine Aufgaben keinen Loop verwenden.** Tippfehler, Umbenennungen und Typfehler in einer Datei in einem einzelnen Turn bearbeiten.
2. **Erfolgskriterien und Hard stop gemeinsam definieren.** Erfolg, maximale Anzahl von Turns, maximale Dauer, aufeinanderfolgende Fehlschläge und Berechtigungsfehler berücksichtigen.
3. **Umfangreiche Workflows zunächst in kleinem Rahmen testen.** Kosten und Qualität mit 5 Dateien, einem Verzeichnis oder einigen Issues überprüfen und den Umfang erst danach erhöhen.
4. **Deterministische Aufgaben mit einem Script bearbeiten.** AST-Ersetzungen, JSON-Transformationen, Formatting und die Erstellung fester Formate sind mit einem überprüften Script günstiger und reproduzierbarer.
5. **Polling-Intervall an die tatsächliche Änderungshäufigkeit anpassen.** Wenn möglich, Event Trigger verwenden.
6. **Laufende Nutzung beobachten.** In `/usage`, `/goal` und `/workflows` die Nutzung von Skills, Subagents, MCP, Turns und Tokens prüfen.
7. **Bei wiederholtem Auftreten desselben Fehlers nicht unbegrenzt weiter versuchen.** Ein Limit für aufeinanderfolgende Fehlschläge festlegen und an einen Menschen eskalieren.

### Model und Effort sind unterschiedliche Stellhebel

- **Model** verändert die grundlegende Schlussfolgerungsfähigkeit und den Bereich lösbarer Probleme.
- **Effort** verändert die Anzahl gelesener Dateien, die Anzahl verwendeter Tools, die Breite der Überprüfung und wie konsequent mehrstufige Aufgaben bis zum Ende ausgeführt werden.

Wenn Claude alle erforderlichen Dateien und Tests geprüft hat, die Entscheidung selbst aber weiterhin falsch ist, kann ein stärkeres Model erforderlich sein. Wenn dagegen wichtige Dateien nicht gelesen, Tests übersprungen oder Refaktorierungen vorzeitig beendet werden, kann eine Erhöhung von Effort sinnvoller sein.

## 9. Berechtigungen und Sicherheitsgrenzen

Das gefährlichste Design eines Proactive Loop besteht darin, einem Agent weitreichende Berechtigungen zu geben und Erfolgskriterien sowie Abbruchbedingungen locker zu definieren.

Auto mode reduziert normale Berechtigungs-Prompts. Tool calls, die schwer rückgängig zu machen oder destruktiv sind beziehungsweise auf Ziele außerhalb der Vertrauensgrenze gerichtet sind, können jedoch vom Klassifikator blockiert werden. Außerdem haben explizite `permissions.ask` und `permissions.deny` Vorrang vor Auto mode.

### Beispiel einer Berechtigungshierarchie

| Stufe | Beispiel |
|---|---|
| Automatisch erlaubt | Code lesen, Tests, lint und Build ausführen, analysieren, `claude/*` Branch erstellen, Draft PR erstellen |
| Genehmigung durch Menschen | Übernahme in den Default Branch, Deployment in die Produktion, Anwendung einer DB Migration, Versand von Nachrichten an externe Kunden |
| Immer verboten | Force push, Ausgabe von Secrets, Löschen von Produktionsdaten, Umgehen von Berechtigungen, Entfernen von Audit-Logs |

Es ist sicherer, dauerhafte `ask`- und `deny`-Regeln festzulegen, als in der Konversation einmal „Nicht pushen“ zu sagen. Durch Context-Komprimierung oder einen Session-Wechsel können Regeln aus der Konversation an Wirkung verlieren.

Eine Cloud Routine klont das Repository bei jeder Ausführung neu und arbeitet mit den verbundenen GitHub- und Connector-Berechtigungen. Folgende Bereiche müssen minimiert werden.

- Zugängliche Repositorys und Branches
- Zulässige Network Domains
- Zu verwendende Connectoren
- Umgebungsvariablen und Secrets
- Schreibberechtigungen für externe Systeme
- Umfang von PR-Erstellung, Push und Merge

Der Status „ordnungsgemäß beendet“ in der Ausführungsliste einer Routine kann lediglich bedeuten, dass die Session ohne Infrastructure-Fehler beendet wurde. Er garantiert nicht, dass das fachliche Ziel erfolgreich erreicht wurde. Transcript, Test evidence und der erzeugte Diff müssen separat geprüft werden.

## 10. Vorlage zur Loop-Gestaltung für Entwicklungsprojekte

Das folgende YAML ist keine tatsächliche Syntax von Claude Code, sondern ein Template für die Designprüfung.

```yaml
trigger:
  type: manual | interval | schedule | github_event | api_event

scope:
  repositories:
    - target-repository
  allowed_paths:
    - src/**
    - tests/**
  prohibited_paths:
    - production/**
    - secrets/**

task:
  objective: Zu änderndes oder zu bearbeitendes Ziel
  input: Neu eingehendes Issue, Event, File oder neuer Zustand

verification:
  commands:
    - unit-test
    - integration-test
    - lint
    - build
  runtime_checks:
    - browser-interaction
    - console-errors
    - accessibility
  evidence:
    - command-output
    - exit-code
    - test-summary
    - screenshots

success:
  condition: Abschlusszustand, der als wahr oder falsch bewertet werden kann

stop:
  max_turns: 12
  max_duration_minutes: 45
  max_consecutive_failures: 3
  stop_on_permission_error: true
  escalate_on_external_outage: true

side_effects:
  idempotency_key: event-id-or-commit-sha
  allow_branch_push: claude/*
  require_human_for_merge: true
  require_human_for_deploy: true

review:
  independent_agent: true
  adversarial_review: true

observability:
  report_progress: true
  report_token_usage: true
  report_changed_files: true
  report_remaining_failures: true
```

Wichtiger als die Formulierung des Prompt selbst sind die folgenden fünf Elemente.

```text
Trigger
Verifier
Success condition
Hard stop
Permission boundary
```

## 11. Welcher Loop sollte gewählt werden?

| Situation | Empfohlene Methode |
|---|---|
| Aufgabe, die mit einer einzelnen Änderung und Überprüfung endet | Turn-based |
| Aufgabe, die mehrere Versuche erfordert, aber einen klaren Abschlusszustand hat | `/goal` |
| Aufgabe, bei der kurz auf den Zustand von externer CI, PR oder Deployment gewartet werden muss | `/loop` |
| Aufgabe, die auch bei geschlossenem Notebook wiederholt ausgeführt werden muss | `/schedule` Routine |
| Aufgabe, die sofort auf GitHub-Events oder Alerts reagieren muss | Event-triggered Routine |
| Aufgabe, bei der Hunderte Elemente parallel verarbeitet und gegenseitig überprüft werden müssen | Dynamic Workflow |
| Transformation mit vollständig deterministischen Ein- und Ausgaberegeln | Script oder CI Job |

Die Auswahl sollte sich nicht nach der „leistungsstärksten Funktion“, sondern nach der „einfachsten Kontrollstruktur, die das Ziel erreicht“ richten.

## 12. Sichere Einführungsreihenfolge

1. Eine Engpassaufgabe auswählen, die ein Mensch wiederholt kontrollieren muss.
2. Zunächst den Überprüfungsprozess als Skill, Script oder CI umsetzen.
3. Die Qualität der Überprüfung im Turn-based-Verfahren stabilisieren.
4. Wenn der Abschlusszustand eindeutig ist, `/goal` ergänzen.
5. `/loop` nur verwenden, wenn auf einen externen Zustand gewartet werden muss.
6. Wenn eine langfristige Ausführung erforderlich ist, zu einer `/schedule` Routine wechseln.
7. Erst nach Überprüfung von Idempotenz, Berechtigungen und Kosten auf Dynamic Workflow und Proactive Loop erweitern.

## 13. Häufige Missverständnisse

| Missverständnis | Korrekte Interpretation |
|---|---|
| Ein Loop läuft unendlich | Es handelt sich um eine begrenzte Wiederholungsstruktur mit Erfolgskriterien und Hard stop |
| Die Abschlussmeldung eines Agent ist eine Überprüfung | Externe Befehlsausgaben, Exit-Codes und Runtime-Ergebnisse sind erforderlich |
| `/goal` erlaubt automatisch alle Berechtigungen | Es startet nur automatisch den nächsten Turn; die Berechtigungsrichtlinie ist davon getrennt |
| `/loop` ist ein langfristiger betrieblicher Scheduler | Es ist Session-zentriert und unterliegt einer Ablaufzeit von 7 Tagen sowie Einschränkungen der Ausführungsumgebung |
| Mehr Agents führen zu besseren Ergebnissen | Parallelisierung ist nur wertvoll, wenn Rollen, Perspektiven und Überprüfungen unterschiedlich sind |
| Alle wiederkehrenden Aufgaben müssen von einem LLM ausgeführt werden | Deterministische Teile sind mit einem Script günstiger und besser reproduzierbar |

## Fazit

Loop Engineering ist keine Technik, um AI länger laufen zu lassen, sondern die **Gestaltung eines Kontrollsystems, das dafür sorgt, dass AI eigene Fehler erkennt, sie innerhalb eines Kostenlimits korrigiert und an riskanten Stellen stoppt**.

LLM sind stark bei Exploration, Schlussfolgerung, Implementierung, Ausnahmeanalysen und dem Vergleich von Alternativen. Das System muss den Ausführungszeitpunkt, den Änderungsumfang, die Überprüfungsmethode, die Abbruchkriterien, das Kostenlimit und die Genehmigungsgrenzen verwalten. Je klarer diese Rollenverteilung ist, desto mehr entwickelt sich die Automatisierung mit Claude Code von einem einfachen Tool zur Codegenerierung zu einem reproduzierbaren und auditierbaren System für den Entwicklungsbetrieb.

## FAQ

### Wie unterscheidet sich der Loop von Claude Code von gewöhnlichen for- und while-Schleifen?
Gewöhnliche Schleifen wiederholen die im Code definierten Anweisungen deterministisch. Der Loop von Claude Code ist eine Agenten-Kontrollstruktur, bei der der Agent den Code und den externen Zustand beobachtet, die nächste Aktion ableitet, Werkzeuge ausführt, die Ergebnisse überprüft und die Arbeit abhängig von der Abbruchbedingung erneut aufnimmt.

### Wann ist ein Turn-based Loop am besten geeignet?
Er eignet sich für kurze, einmalige Aufgaben, deren Ergebnisse der Benutzer sofort überprüfen kann. Wenn sich jedoch Prüfabläufe etwa für eine UI, API oder Datenbank wiederholen, empfiehlt es sich, diese Abläufe als Skill oder Script anzulegen, damit Claude sie selbst nach denselben Kriterien überprüfen kann.

### Prüft das Bewertungsmodell von `/goal` Dateien und Testergebnisse direkt?
Nein. Das Bewertungsmodell ruft keine Werkzeuge auf und liest Dateien nicht direkt, sondern beurteilt die Goal-Bedingungen und die aus dem Gespräch ersichtlichen Nachweise. Der ausführende Claude muss Testbefehle, Exit-Codes, geänderte Dateien und Fehlerursachen im Ergebnis eindeutig festhalten.

### Was sollte eine gute `/goal`-Bedingung enthalten?
Erforderlich sind ein messbarer Abschlusszustand, Befehle oder Werkzeuge zum Nachweis dieses Zustands, zulässige und verbotene Änderungsbereiche sowie Hard Stops wie eine maximale Anzahl an Turns, eine maximale Dauer oder eine maximale Anzahl aufeinanderfolgender Fehlschläge. Statt „sauber refaktorieren“ ist „Tests und lint enden mit Exit-Code 0 und es gibt keinen Diff außerhalb des angegebenen Pfads“ eine gute Bedingung.

### Gibt es bei `/goal` automatisch eine maximale Anzahl an Turns oder ein Zeitlimit?
Goal läuft weiter, bis das Bewertungsmodell den Erfolg feststellt oder der Benutzer es mit `/goal clear` abbricht. Um das Ausführungsbudget zu begrenzen, müssen Turn- und Zeitvorgaben wie „nach maximal 12 Turns oder 45 Minuten abbrechen“ direkt in die Goal-Bedingungen aufgenommen werden.

### Werden bei Verwendung von `/goal` auch Werkzeugberechtigungen automatisch erteilt?
Nein. `/goal` startet den nächsten Turn automatisch, doch die Berechtigungsrichtlinien für das Schreiben von Dateien, Shell, Git und externe Connectoren bleiben unverändert. Wenn eine unbeaufsichtigte Ausführung erforderlich ist, sollte der Auto mode erwogen werden; riskante Vorgänge müssen dabei jedoch separat durch `ask`- und `deny`-Regeln kontrolliert werden.

### Was ist der größte Unterschied zwischen `/loop` und `/schedule`?
`/loop` ist ein kurzfristiges Polling-Mittel, das wiederholt in der aktuellen Claude Code-Sitzung und auf dem aktuellen Computer ausgeführt wird. `/schedule` speichert Prompt, Repository, Connector und Trigger als Cloud Routine und führt sie auf der von Anthropic verwalteten Infrastruktur aus, sodass weder eine geöffnete Sitzung noch ein eingeschalteter Laptop erforderlich ist.

### Wird `/loop` weiter ausgeführt, wenn der Computer ausgeschaltet wird?
Im Allgemeinen nicht. `/loop` ist eine auf die Sitzung beschränkte Aufgabe, und Claude Code muss ausgeführt werden. Für langfristige Automatisierungen sollte ein dauerhaft verfügbarer Scheduler wie Cloud Routine, eine geplante Desktop-Aufgabe oder GitHub Actions verwendet werden.

### Warum ist ein Event Trigger besser als zeitbasiertes Polling?
Weil dadurch bei ausbleibenden Änderungen keine unnötigen Modellaufrufe entstehen und die Ausführung unmittelbar nach einer tatsächlichen Änderung erfolgen kann. Systeme, die Ereignisse wie CI-Fehler, PR-Aktualisierungen oder Alerts ausgeben können, lassen sich besser über einen GitHub Trigger oder eine Routine API anbinden, da dies sowohl bei den Kosten als auch bei der Latenz vorteilhaft ist.

### Warum sollte der Prüfablauf in `SKILL.md` statt in `CLAUDE.md` abgelegt werden?
`CLAUDE.md` eignet sich für kurze Regeln, die stets für das gesamte Projekt gelten, während ein Skill geeignet ist, um nur für bestimmte Aufgaben erforderliche Abläufe und unterstützende Dateien zusammenzufassen. Wird eine lange Prüfcheckliste in einen Skill ausgelagert, kann sie nur bei relevanten Aufgaben geladen und direkt erneut ausgeführt werden.

### Wie unterscheidet sich ein Dynamic Workflow von einem gewöhnlichen Subagent-Aufruf?
Beim gewöhnlichen Subagent-Ansatz wählt Claude in jedem Turn den nächsten Bearbeiter aus, und die Ergebnisse sammeln sich im Context an. Bei einem Dynamic Workflow verwaltet ein JavaScript Script die parallele Ausführung, Verzweigungen, Wiederholungen und Zwischenergebnisse, sodass sich umfangreiche Migrationen, Audits und Kreuzprüfungen reproduzierbarer organisieren lassen.

### Verbessert der Einsatz mehrerer Agenten immer die Qualität?
Nein. Wenn sich Rollen und Perspektiven überschneiden, können dieselben Fehler wiederholt werden, während lediglich die Kosten steigen. Der Wert paralleler Agenten entsteht erst, wenn die Verantwortlichkeiten etwa in Implementierung, Testkonzeption, Sicherheitsprüfung, Regressionsanalyse und Judge aufgeteilt und für jede Schlussfolgerung unabhängige Nachweise verlangt werden.

### Wie lassen sich doppelte Arbeiten in einem Time-based oder Proactive Loop verhindern?
Idempotency Keys wie Event ID, Commit SHA und Review Comment ID sowie der letzte Verarbeitungsstatus müssen gespeichert werden. In die Prüfphase muss eine Regel aufgenommen werden, die verhindert, dass bereits beantwortete Nachrichten, bereits erstellte PRs und bereits verarbeitete Commits erneut verarbeitet werden.

### Welche Aufgabe eignet sich für den ersten zu automatisierenden Loop?
Geeignet sind Aufgaben, die von Menschen wiederholt überprüft werden, aber nur wenige riskante Side Effects haben und deren Abschlussstatus sich eindeutig messen lässt. Sicher ist es beispielsweise, zunächst die Ursachen fehlgeschlagener CI in PRs zusammenzufassen, Abweichungen zwischen Dokumentation und Code zu erkennen und festgelegte Tests und lint-Prüfungen durchzuführen und anschließend die Berechtigungen zum Ändern und Pushen schrittweise zu erweitern.

## Sources

- [Loop-Engineering: Erste Schritte mit Schleifen | Claude von Anthropic](https://claude.com/blog/getting-started-with-loops)
- [Claude mit Skills erweitern – Claude Code-Dokumentation](https://code.claude.com/docs/en/skills)
- [Claude kontinuierlich auf ein Ziel hinarbeiten lassen – Claude Code-Dokumentation](https://code.claude.com/docs/en/goal)
- [Prompts nach einem Zeitplan ausführen – Claude Code-Dokumentation](https://code.claude.com/docs/en/scheduled-tasks)
- [Arbeit mit Routinen automatisieren – Claude Code-Dokumentation](https://code.claude.com/docs/en/routines)
- [Subagenten in großem Maßstab mit dynamischen Workflows orchestrieren – Claude Code-Dokumentation](https://code.claude.com/docs/en/workflows)
- [Auswahl eines Claude-Modells und einer Aufwandsstufe in Claude Code | Claude von Anthropic](https://claude.com/blog/claude-model-and-effort-level-in-claude-code)
- [Automatikmodus konfigurieren – Claude Code-Dokumentation](https://code.claude.com/docs/en/auto-mode-config)

## Images

![Automatisierungsstruktur mit einem AI-Roboter und einer Codeanzeige im Zentrum, verbunden mit Wiederholungspfeilen sowie Symbolen für Ziel, Zeit, Sicherheit und Kosten](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp)
![Automatisierungsstruktur, in der ein AI-Agent innerhalb von Schutzvorkehrungen Aufgaben über Validierung, Abbruchmechanismus, Berechtigungsschranke und Kostenmessung ausführt](https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp)