Agent Loop

Erklärung für den Block Agent Loop.

Kategorie: KI | Quelldatei: agentLoopBlock.js

---

Kurzbeschreibung

Agent Loop – LLM-gesteuerter Agent mit Tool-Calling. Das LLM entscheidet selbstständig welche Tools aufgerufen werden. Fehler bei Tool-Aufrufen werden intelligent behandelt – das LLM sieht den Fehler und kann reagieren (alternatives Tool, User informieren). Features: • LLM Function Calling (OpenAI, xAI Grok, Claude, Gemini, Mistral, DeepSeek, Ollama) • Iterativer Agent-Loop (max. N Schritte) • Tool-Calls, Reasoning und Ergebnisse im Chat • Konfigurierbare Tool-Auswahl • Streaming-Antworten • Genehmigungsmodus: Plan-First, Critical-Tools oder beides • Context-Trim: HTML-Bodies und grosse Tool-Ergebnisse werden gekürzt bzw. als Artifact ausgelagert (read_artifact) • Verifier: vor dem Abschluss prüft der Loop die Tool-Evidence; bei «Ziel prüfen» zusätzlich ein Verify-Turn und Replan • Aufgaben-Echo: kurzer Satz vor den Tools, sonst Fallback «Verstanden: …»

Typische Verwendung

• Block in den Agent-Flow ziehen
• Wichtige Felder konfigurieren
• Mit Test-Input ausführen und Ergebnis prüfen

Rechner und Browser

Computer bedienen erlaubt Browser, Apps und Terminal, soweit Profil → Dieser Computer diese freigibt. Neue Agenten starten ausgeschaltet. Bestehende Agenten behalten ihre bisherigen Rechte unter Erweiterte Freigaben; die App-Freigabe aktiviert keine Terminalrechte.

Der LLM-Block verwendet bei aktivierter Computerfreigabe intern einen Agent Loop. Das ? erklärt die gemeinsame Freigabe. Alles anhalten sperrt weitere Agentaktionen, während du Browser und Oberfläche selbst bedienen kannst.

Browserziele sind pro Chat gebunden. Standard ist ein Uella-Tab; ausdrücklich gewünschte und geteilte Chrome-Tabs können ausgewählt werden. Das manuelle Öffnen im Split View erteilt keine Agentrechte.

Mehr dazu: Computer bedienen und Browser.

Hinweise

• Prüfe Berechtigungen und API-Keys, falls der Block externe Dienste nutzt.
• Nutze klare Eingaben für reproduzierbare Ergebnisse.
• Im Chat steuert der Berechtigungs-Chip in der Leiste über dem Eingabefeld (neben Bibliothek) denselben Genehmigungsmodus zur Laufzeit (ohne den Block zu speichern). Default: Genehmigung anfordern (Datei-Writes + Internet). Für mich genehmigen = unsichere Writes/Sends. Vollzugriff = Dateien und Internet ohne Nachfrage, Schreiben in verbundenen Apps weiter bestätigen. Lesen/Suchen in Apps nie. Kein permanentes Ja, keine Rechte pauschal pro Integration — der Builder begrenzt allowedOperations. Plan-First bleibt eine Builder-Option.
• Mit gebundenem Projekt gelten Ask / Plan / Agent als Overlay: File Manager kommt dazu, andere Loop-Tools bleiben. Ask nur lesen, Plan wartet auf Freigabe, Agent schreibt.
• Grosse Webseiten oder API-Listen landen nicht mehr roh im Prompt. Bei Bedarf holt der Agent Details mit read_artifact.
• Ziel prüfen im Block: der Loop akzeptiert finish nur, wenn die Tools das Ziel stützen. Sonst plant er nach (Status «Prüfung …» / «Neu geplant»).
• Erster Tool-Lauf: ein kurzer Satz, dass die Aufgabe verstanden wurde. Bleibt das Modell stumm, erscheint «Verstanden: …». Plan-First und Rückfragen (ask_user) brauchen das nicht.
• Mehrere Schritte: update_todos (Liste im Chat, Stand bleibt im Prompt). «Merke dir» / remember → immer save_memory (einziger Speicherkanal im Chat). Auto-Gedächtnis speichert zusätzlich unaufgefordert. Uhrzeit-Erinnerungen bleiben propose_task.
• Inspector (Klick auf den Block) zeigt dieselben drei Zeilen wie die Node: Dokumente hinzufügen, Tools & Apps, MCP-Server.
• Am Feld Instruktion (System-Prompt): Ordner lädt eine Vorlage aus der Prompt-Bibliothek, Diskette speichert den aktuellen Text als Vorlage (Kategorie System).
• In Tools & Apps können Google, YouTube, Microsoft, Meta, WhatsApp, GitHub, LinkedIn, Bexio und NinjaOne per Mit … anmelden verbunden werden. Auf Personal Desktop läuft der Login mit PKCE (ohne Secret in der App). Token / API-Key blendet die alten Felder wieder ein (lokales Token überschreibt OAuth für dieses Tool). Search/Maps/Veo brauchen weiter einen API-Key.