An Agent ist die Einheit, die AiHummer vor ein Gespräch stellt. Jeder Agent hat eine Persona, ein eigenes Modell, einen strukturierten Prompt und einen Satz von Fähigkeiten, und jede Änderung daran wird versioniert. Agenten werden über die Web-Admin-Oberfläche und über die Admin-API unter verwaltet /v1/admin/agents/*.
Diese Seite behandelt, woraus ein Agent besteht, wie der strukturierte “G3”-Prompt zusammengestellt wird und wie ein Agent sein eigenes Profil sicher bearbeiten kann.
Das Agentenregister
Das Register ist ein vollständiger CRUD-Katalog von Agenten. Für jeden Agenten definieren Sie eine Identität, eine Persona, das Modell, auf dem er läuft, und die Fähigkeiten, die er nutzen kann. Da das Gateway mandantenfähig ist, leben Agenten innerhalb eines Arbeitsbereichs und sind wie alle anderen Mandantendaten isoliert.
Persona — die Stimme und das Verhalten des Agenten, in einen Stall umgesetzt,
Cache-freundliche Schicht des System-Prompts.
Pro-Agent-Modell — jeder Agent kann sein eigenes Modell und seinen eigenen Anbieter festlegen, sodass ein
Ein billiger Agent und ein Flaggschiff-Agent können im selben Arbeitsbereich koexistieren.
Fähigkeiten — pro Agent und gemeinsame Fähigkeiten rendern einen “Fähigkeiten”-Block in die
Aufforderung; sie beschreiben Fähigkeiten, nicht Gewichte.
[!NOTE]
Ein Pro-Agent-Modell ist unabhängig vom Routing. Modell-Ebenen-Routing (einfach /
standard / komplex) wählt eine Modellklasse für einen Zug, während der pro-Agent
Modell ist das eigene Standardmodell des Agenten. Siehe
Routing.
Versionen, Rücksetzung und Klonen
Jede bedeutende Änderung an einem Agenten wird als eine erfasst Version. Dies macht die Agenten-Konfiguration prüfbar und umkehrbar: Sie können überprüfen, was sich geändert hat, zurückrollen zu einer früheren Version, oder Klon ein Agent, der es als Ausgangspunkt für einen neuen verwendet. Versions- und Profilressourcen befinden sich unter /v1/admin/agents/* (Profil, Abschnitte, Fähigkeiten, Versionen).
[!TIP]
Klonen Sie einen funktionierenden Agenten, bevor ein großes Persona- oder Prompt-Update durchgeführt wird. Wenn der neue
Wenn die Richtung nicht aufgeht, ist das Original immer noch einen Rückschritt entfernt.
Die strukturierte „G3“-Eingabeaufforderung
Anstatt eines einzelnen Freitext-Systembefehls verwendet AiHummer ein strukturiertes Agentenprofil (intern intern „G3“). Die Identität ist in Felder zerlegt statt in Prosa vergraben zu sein, und der Rest der Aufforderung wird aus benannten Elementen aufgebaut Abschnitte plus ein Einarbeitung block. Der Orchestrator rendert diese in das geschichtete System-Prompt, wobei die stabilen Teile (Identität, Persona, Abschnitte) in einem zwischenspeicherbaren Präfix behalten und die volatilen Daten zuletzt angehängt werden.
Die Struktur macht es einfach, ein Profil feldweise zu bearbeiten, einfach, Unterschiede zwischen Versionen zu erkennen, und vorhersehbar zu rendern — es gibt keine versteckte Prompt-Suppe.
Ein Agent kann erlaubt werden zu sein eigenes Profil bearbeiten Verwendung von Selbstbearbeitungstools — zum Beispiel, um einen Abschnitt zu verfeinern oder dessen Einarbeitung zu aktualisieren. Dies ist bewusst geschützt:
Selbstbearbeitungen durchlaufen die Genehmigungstor: eine vorgeschlagene Änderung wird aufgezeichnet und
muss von einem Menschen genehmigt werden, bevor es in Kraft tritt. Eine abgelehnte Änderung wird niemals
angewendet.
Die Änderung wird als neu erfasst Version, sodass eine Selbstbearbeitung ebenso überprüfbar ist
und so umkehrbar wie jede manuelle Bearbeitung.
[!WARNING]
Selbstbearbeitung ist mächtig. Halte sie hinter dem Genehmigungstor zurück, damit ein Agent es nicht kann.
schreibt stillschweigend seine eigene Identität neu. Überprüfen Sie vorgeschlagene Selbständerungen auf die gleiche Weise wie Sie
jede privilegierte Änderung überprüfen.
E-Mail-Passwörter gehen in den Tresor
Wenn die Konfiguration eines Agenten E-Mail-Zugangsdaten enthält (für die mail Werkzeug), das Passwort wird in die verschlüsselter Anmeldeinformationen-Safe, werden nicht im Profil gespeichert oder in die Eingabeaufforderung eingefügt. Geheimnisse gelangen niemals in den Modellkontext.
Laufzeitrichtlinie: Kontext, Sitzungen und Kind-Agenten
Seit Version 1.3 hat ein Agent eine Laufzeitrichtlinie — das Feld
runtime_policy in der Admin-API (/v1/admin/agents beim Erstellen und
Aktualisieren). Es ist ein streng geprüftes JSON-Objekt mit "version": 1:
ein leeres {} stellt die Voreinstellungen wieder her, das Weglassen des
Feldes beim Aktualisieren behält die bisherige Richtlinie, und unbekannte
Felder oder Werte außerhalb der Grenzen werden abgelehnt. Die Richtlinie
vergibt keine Werkzeuge und erweitert keine Rechte — sie setzt nur Budgets und
Fristen. Das Klonen eines Agenten und die Übergabe eines Zuges an ihn erben sie.
context — das Verlaufsbudget: max_tokens, reserve_tokens und
history_share bestimmen, wie viel Verlauf in eine Anfrage gelangt;
max_history_messages begrenzt das Nachrichtenfenster, bootstrap_max_chars
die Größe des Profilblocks. Bei explizitem Kontext werden ältere Nachrichten
portionsweise zu einer Zusammenfassung verdichtet, bevor die aktuelle Anfrage
zusammengestellt wird.
pruning — Bereinigung veralteter Werkzeugergebnisse: nach Alter
(ttl_seconds), mit Schutz der letzten Antworten (keep_last_assistants),
weiches Kürzen (soft_trim_ratio, head_chars, tail_chars) und
vollständiger Ersatz durch den placeholder-Text oberhalb von
hard_clear_ratio. Benutzertext, Bilder und der vollständige Verlauf in
der Datenbank bleiben unberührt.
memory_flush — vor der Verdichtung schreibt ein Agent ohne Werkzeuge
eine kurze Notiz zu Zielen, Entscheidungen und offenen Punkten
(soft_threshold_tokens); die letzten drei Notizen desselben Dialogs werden
als ungeprüfte Referenz in den Kontext eingemischt.
session — der Lebenszyklus des Dialogs: idle_reset_minutes beginnt
nach einer Pause einen neuen Kontext (der Rohverlauf bleibt erhalten),
index_prune_after_days und index_max_entries nehmen alte Dialoge aus der
Standardliste, ohne sie zu löschen. scope = per-peer (ein Dialog je
verifiziertem Benutzer über alle Kanäle) oder per-channel-peer (ein eigener
Dialog je Kanal).
children — Kind-Agenten: max_depth (bis 4), max_concurrent (bis 8
je Laufbaum), max_per_parent (bis 5), timeout_seconds (bis 48 Stunden,
nie länger als der Elternteil) und archive_after_minutes — wann beendete
Läufe aus der Standardliste verschwinden. Die Werte überschreiben für diesen
Agenten die globalen AIHUMMER_SUBAGENT_MAX_DEPTH und
AIHUMMER_SUBAGENT_TIMEOUT_SEC.
max_iterations (1–256) — die Schrittgrenze der Funktionsaufrufschleife
für geprüfte Szenarien mit vielen Delegationen.
app — nur für die AiHummer-App: reasoning_effort, service_tier und
der Kurzantwortmodus direct_completion (auto oder always mit
max_tokens bis 4096 und timeout_ms bis 60 000).
interaction — ausdrückliche Sitzungsfreigaben: user_ids,
session_agent_ids, spawn_agent_ids, die Sichtbarkeit
session_visibility (self, agent oder granted), session_send,
Werkzeugverbote für Kind-Aufrufe (child_tool_deny, child_leaf_tool_deny)
und elevated_telegram_user_ids — eine Teilmenge von user_ids, die
ausdrücklich erhöhte code_exec-Ausführung anfordern darf (Freigaben werden
dabei nicht umgangen). Platzhalter und mandantenweite Freigaben gibt es nicht.
Admin-API
Agenten und ihre strukturierten Profile werden über die Admin-API verwaltet, die OIDC-gesichert und überprüft ist:
An **Agent** ist die Einheit, die AiHummer vor ein Gespräch stellt. Jeder Agent hat eine Persona, ein eigenes Modell, einen strukturierten Prompt und einen Satz von Fähigkeiten, und jede Änderung daran wird versioniert. Agenten werden über die Web-Admin-Oberfläche und über die Admin-API unter verwaltet `/v1/admin/agents/*`.
Diese Seite behandelt, woraus ein Agent besteht, wie der strukturierte "G3"-Prompt zusammengestellt wird und wie ein Agent sein eigenes Profil sicher bearbeiten kann.
## Das Agentenregister
Das Register ist ein vollständiger CRUD-Katalog von Agenten. Für jeden Agenten definieren Sie eine Identität, eine Persona, das Modell, auf dem er läuft, und die Fähigkeiten, die er nutzen kann. Da das Gateway mandantenfähig ist, leben Agenten innerhalb eines Arbeitsbereichs und sind wie alle anderen Mandantendaten isoliert.
- **Persona** — die Stimme und das Verhalten des Agenten, in einen Stall umgesetzt,
Cache-freundliche Schicht des System-Prompts.
- **Pro-Agent-Modell** — jeder Agent kann sein eigenes Modell und seinen eigenen Anbieter festlegen, sodass ein
Ein billiger Agent und ein Flaggschiff-Agent können im selben Arbeitsbereich koexistieren.
- **Fähigkeiten** — pro Agent und gemeinsame Fähigkeiten rendern einen "Fähigkeiten"-Block in die
Aufforderung; sie beschreiben Fähigkeiten, nicht Gewichte.
> [!NOTE]
> Ein Pro-Agent-Modell ist unabhängig vom Routing. Modell-Ebenen-Routing (einfach /
> standard / komplex) wählt eine Modellklasse für einen Zug, während der pro-Agent
> Modell ist das eigene Standardmodell des Agenten. Siehe
> [Routing](/de/v1.0/concepts/routing).
## Versionen, Rücksetzung und Klonen
Jede bedeutende Änderung an einem Agenten wird als eine erfasst **Version**. Dies macht die Agenten-Konfiguration prüfbar und umkehrbar: Sie können überprüfen, was sich geändert hat, **zurückrollen** zu einer früheren Version, oder **Klon** ein Agent, der es als Ausgangspunkt für einen neuen verwendet. Versions- und Profilressourcen befinden sich unter `/v1/admin/agents/*` (Profil, Abschnitte, Fähigkeiten, Versionen).
> [!TIP]
> Klonen Sie einen funktionierenden Agenten, bevor ein großes Persona- oder Prompt-Update durchgeführt wird. Wenn der neue
> Wenn die Richtung nicht aufgeht, ist das Original immer noch einen Rückschritt entfernt.
## Die strukturierte „G3“-Eingabeaufforderung
Anstatt eines einzelnen Freitext-Systembefehls verwendet AiHummer ein **strukturiertes Agentenprofil** (intern intern „G3“). Die Identität ist **in Felder zerlegt** statt in Prosa vergraben zu sein, und der Rest der Aufforderung wird aus benannten Elementen aufgebaut **Abschnitte** plus ein **Einarbeitung** block. Der Orchestrator rendert diese in das geschichtete System-Prompt, wobei die stabilen Teile (Identität, Persona, Abschnitte) in einem zwischenspeicherbaren Präfix behalten und die volatilen Daten zuletzt angehängt werden.
Die Struktur macht es einfach, ein Profil feldweise zu bearbeiten, einfach, Unterschiede zwischen Versionen zu erkennen, und vorhersehbar zu rendern — es gibt keine versteckte Prompt-Suppe.
```text
G3 profile
├── identity fields (decomposed: name, role, ...)
├── sections (named, ordered prompt blocks)
└── onboarding (first-run guidance)
```
## Selbstbearbeitung hinter einem Genehmigungstor
Ein Agent kann erlaubt werden zu **sein eigenes Profil bearbeiten** Verwendung von Selbstbearbeitungstools — zum Beispiel, um einen Abschnitt zu verfeinern oder dessen Einarbeitung zu aktualisieren. Dies ist bewusst geschützt:
- Selbstbearbeitungen durchlaufen die **Genehmigungstor**: eine vorgeschlagene Änderung wird aufgezeichnet und
muss von einem Menschen genehmigt werden, bevor es in Kraft tritt. Eine abgelehnte Änderung wird niemals
angewendet.
- Die Änderung wird als neu erfasst **Version**, sodass eine Selbstbearbeitung ebenso überprüfbar ist
und so umkehrbar wie jede manuelle Bearbeitung.
> [!WARNING]
> Selbstbearbeitung ist mächtig. Halte sie hinter dem Genehmigungstor zurück, damit ein Agent es nicht kann.
> schreibt stillschweigend seine eigene Identität neu. Überprüfen Sie vorgeschlagene Selbständerungen auf die gleiche Weise wie Sie
> jede privilegierte Änderung überprüfen.
### E-Mail-Passwörter gehen in den Tresor
Wenn die Konfiguration eines Agenten E-Mail-Zugangsdaten enthält (für die `mail` Werkzeug), das Passwort wird in die **verschlüsselter Anmeldeinformationen-Safe**, werden nicht im Profil gespeichert oder in die Eingabeaufforderung eingefügt. Geheimnisse gelangen niemals in den Modellkontext.
## Laufzeitrichtlinie: Kontext, Sitzungen und Kind-Agenten
Seit Version 1.3 hat ein Agent eine **Laufzeitrichtlinie** — das Feld
`runtime_policy` in der Admin-API (`/v1/admin/agents` beim Erstellen und
Aktualisieren). Es ist ein streng geprüftes JSON-Objekt mit `"version": 1`:
ein leeres `{}` stellt die Voreinstellungen wieder her, das Weglassen des
Feldes beim Aktualisieren behält die bisherige Richtlinie, und unbekannte
Felder oder Werte außerhalb der Grenzen werden abgelehnt. Die Richtlinie
vergibt keine Werkzeuge und erweitert keine Rechte — sie setzt nur Budgets und
Fristen. Das Klonen eines Agenten und die Übergabe eines Zuges an ihn erben sie.
- **`context`** — das Verlaufsbudget: `max_tokens`, `reserve_tokens` und
`history_share` bestimmen, wie viel Verlauf in eine Anfrage gelangt;
`max_history_messages` begrenzt das Nachrichtenfenster, `bootstrap_max_chars`
die Größe des Profilblocks. Bei explizitem Kontext werden ältere Nachrichten
portionsweise zu einer Zusammenfassung verdichtet, bevor die aktuelle Anfrage
zusammengestellt wird.
- **`pruning`** — Bereinigung veralteter Werkzeugergebnisse: nach Alter
(`ttl_seconds`), mit Schutz der letzten Antworten (`keep_last_assistants`),
weiches Kürzen (`soft_trim_ratio`, `head_chars`, `tail_chars`) und
vollständiger Ersatz durch den `placeholder`-Text oberhalb von
`hard_clear_ratio`. Benutzertext, Bilder und der vollständige Verlauf in
der Datenbank bleiben unberührt.
- **`memory_flush`** — vor der Verdichtung schreibt ein Agent ohne Werkzeuge
eine kurze Notiz zu Zielen, Entscheidungen und offenen Punkten
(`soft_threshold_tokens`); die letzten drei Notizen desselben Dialogs werden
als ungeprüfte Referenz in den Kontext eingemischt.
- **`session`** — der Lebenszyklus des Dialogs: `idle_reset_minutes` beginnt
nach einer Pause einen neuen Kontext (der Rohverlauf bleibt erhalten),
`index_prune_after_days` und `index_max_entries` nehmen alte Dialoge aus der
Standardliste, ohne sie zu löschen. `scope` = `per-peer` (ein Dialog je
verifiziertem Benutzer über alle Kanäle) oder `per-channel-peer` (ein eigener
Dialog je Kanal).
- **`children`** — Kind-Agenten: `max_depth` (bis 4), `max_concurrent` (bis 8
je Laufbaum), `max_per_parent` (bis 5), `timeout_seconds` (bis 48 Stunden,
nie länger als der Elternteil) und `archive_after_minutes` — wann beendete
Läufe aus der Standardliste verschwinden. Die Werte überschreiben für diesen
Agenten die globalen `AIHUMMER_SUBAGENT_MAX_DEPTH` und
`AIHUMMER_SUBAGENT_TIMEOUT_SEC`.
- **`max_iterations`** (1–256) — die Schrittgrenze der Funktionsaufrufschleife
für geprüfte Szenarien mit vielen Delegationen.
- **`app`** — nur für die AiHummer-App: `reasoning_effort`, `service_tier` und
der Kurzantwortmodus `direct_completion` (`auto` oder `always` mit
`max_tokens` bis 4096 und `timeout_ms` bis 60 000).
- **`interaction`** — ausdrückliche Sitzungsfreigaben: `user_ids`,
`session_agent_ids`, `spawn_agent_ids`, die Sichtbarkeit
`session_visibility` (`self`, `agent` oder `granted`), `session_send`,
Werkzeugverbote für Kind-Aufrufe (`child_tool_deny`, `child_leaf_tool_deny`)
und `elevated_telegram_user_ids` — eine Teilmenge von `user_ids`, die
ausdrücklich erhöhte `code_exec`-Ausführung anfordern darf (Freigaben werden
dabei nicht umgangen). Platzhalter und mandantenweite Freigaben gibt es nicht.
## Admin-API
Agenten und ihre strukturierten Profile werden über die Admin-API verwaltet, die OIDC-gesichert und überprüft ist:
| Ressource | Zweck |
|---|---|
| `/v1/admin/agents` | Agenten auflisten, erstellen, aktualisieren, löschen (CRUD) |
| `/v1/admin/agents/.../profile` | Das strukturierte G3-Profil (Identitätsfelder) |
| `/v1/admin/agents/.../sections` | Benannte Aufforderungsabschnitte |
| `/v1/admin/agents/.../skills` | Pro-Agent-Fähigkeiten |
| `/v1/admin/agents/.../versions` | Versionsverlauf, Rücksetzen und Klonen |
## Wohin als Nächstes
- Verstehen, wie Agenten eine Runde ausführen und Helfer erzeugen
[Orchestrierung & Unteragenten](/de/v1.0/concepts/orchestration-subagents).
- Sehen Sie, wie eine eingehende Nachricht einen bestimmten Agenten erreicht in
[Routing](/de/v1.0/concepts/routing).
- Geben Sie Ihren Agenten ein langfristiges Gedächtnis mit
[Gedächtnis (Einstein)](/de/v1.0/concepts/memory-einstein).
