- raw: raw/xpost/2026-07-18_healthranger-kimi-k3-anthropic-panic.md - wiki: concepts/llm/kimi-k3.md (new concept page) - wiki: institutions/moonshot-ai.md (updated with Kimi K3 section) - wiki: index.md (77. update, new LLM entry + raw source) - wiki: log.md (ingest entry) - fix: broken links in agent-loops.md + graph-based-agents.md Kernaussagen: ~8x cheaper than Claude, open source July 27, safeguard controversy (curcumin/cyclospora block vs. free answer), AI bubble thesis from HealthRanger (Mike Adams).
3.5 KiB
| created | updated | sources | tags | people | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2026-07-18 | 2026-07-18 |
|
|
|
Agent Loops (Loop Engineering)
"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." — @steipete
Definition
Das ReAct-Pattern (Reason + Act) ist die fundamentale Agentenschleife: Ein Agent erhält einen Prompt, führt einen Tool-Call aus, bewertet das Ergebnis, trifft eine Entscheidung und wiederholt den Zyklus. Diese einfache while-true-Schleife ist der Ausgangspunkt der meisten Agent-Architekturen.
[Prompt] → [Reason] → [Act (Tool-Call)] → [Observe Result] → [Decide] → [Loop or Done]
Peter Steinbergers "Loop Engineering"
Peter Steinberger (@steipete) hat das Loop-Konzept systematisiert und professionalisiert. Statt einer einfachen while-true-Schleife propagiert er explizite, verschachtelte Loops mit klaren Verantwortlichkeiten:
1. Agent-Loop (Write → Test → Verify → Retry)
Der primäre Arbeitszyklus eines Coding-Agenten:
- Write: Code generieren
- Test: Ausführen und Ergebnis prüfen
- Verify: Qualität und Korrektheit validieren
- Retry: Bei Fehlern iterieren
2. Verifier-Loop (Self-Correction)
Ein separater Loop, der die Arbeit des Agent-Loops überwacht:
- Prüft die eigene Arbeit kritisch
- Zwingt zu Retries, wenn Qualitätsstandards nicht erreicht werden
- Bricht bei wiederholtem Scheitern ab (Fail-Fast)
3. Meta-Loop (Continuous Improvement)
Ein Loop, der den Agenten selbst verbessert — auch während der Entwickler schläft:
- Analysiert Fehlermuster über mehrere Sessions
- Passt Prompts und Konfiguration an
- Baut eine Wissensbasis aus erfolgreichen und fehlgeschlagenen Iterationen auf
[Meta-Loop] ──→ [Agent-Loop: Write → Test → Verify → Retry]
↑ ↓ (bei Fehlern)
└────────── [Verifier-Loop: Prüft → Zwingt Retry → Fail-Fast]
Vorteile von Loops
- Einfach: Leicht zu verstehen und zu implementieren
- Verständlich: Der Kontrollfluss ist linear und nachvollziehbar
- Flexibel: Kann für jede Aufgabe angepasst werden
- Keine Abhängigkeiten: Funktioniert ohne spezielle Frameworks
- Debugging-freundlich: Jeder Loop-Schritt ist isoliert testbar
Nachteile von Loops
- State-Management: Muss selbst gebaut werden — kein eingebauter Persistenz-Mechanismus
- Persistenz: Bei Unterbrechung geht der Loop-Status verloren (kein Checkpointing)
- Debugging: Kein visuelles Tracing — Log-Analyse ist die einzige Debugging-Methode
- Human-in-the-Loop: Muss selbst implementiert werden (keine nativen Approval-Gates)
- Parallelität: Schwierig zu parallelisieren — Loops sind inhärent sequentiell
- Skalierung: Bei komplexen Workflows werden Loops schnell unübersichtlich (Spaghetti-Loops)
Verwandte Konzepte
- ReAct-Pattern — Das fundamentale Reason+Act-Pattern
- graph-based-agents.md — Graph-basierte Alternative (LangGraph)
- Tool-Use — Tool-Call-Mechanismen in Agenten
- ../../architecture/agent-orchestration.md — Übergeordnete Orchestrierungs-Patterns
Quellen
- @steipete: "Are we still talking loops or did we shift to graphs yet?" — https://x.com/steipete/status/2078277297791189132
- ReAct-Pattern: https://react-lm.github.io/
- LangGraph Overview: https://docs.langchain.com/oss/python/langgraph/overview